跳至主要內容

受控样本统一模型版与不同模型差异对比

util6大约 7 分钟

受控样本统一模型版与不同模型差异对比

说明

这篇文档用于替换上一版《受控样本同任务请求与回复对比》中的一个关键缺陷：

  • 上一版里，Claude Code 样本在同一 session 中混入了不同 model 记录
  • 这次新增的 session 明确使用同一 API 提供商、同一模型重新执行了同一条任务

因此，这里分两部分写：

  1. OpenCode vs Claude Code：统一模型后的同任务对比
  2. Claude Code 旧样本 vs 新样本：相同任务下，不同模型/不同执行过程的差别

样本

OpenCode

  • session: ses_2756a886affeEuvyDTX7mgv598
  • 标题: Claude Code MCP与skill调用链路分析
  • 落盘: opencode.db

Claude Code 新样本

Claude Code 旧样本

任务本身

这次对比只看这一条 prompt：

当前仓库是claude code源码库，结合https://www.waylandz.com/diagrams/claude-code-architecture.html这张架构图，帮我分析其MCP和skill的调用时机和链路

OpenCode 真实请求

当前仓库是claude code源码库，结合https://www.waylandz.com/diagrams/claude-code-architecture.html这张架构图，帮我分析其MCP和skill的调用时机和链路

Claude Code 新样本真实请求

当前仓库是claude code源码库，结合https://www.waylandz.com/diagrams/claude-code-architecture.html这张架构图，帮我分析其MCP和skill的调用时机和链路

一、统一模型后的同任务对比

模型元数据

OpenCode

首条用户消息记录到：

{
  "role": "user",
  "agent": "build",
  "model": {
    "providerID": "modelscope",
    "modelID": "ZhipuAI/GLM-5"
  }
}

首轮 assistant message 也记录为：

{
  "providerID": "modelscope",
  "modelID": "ZhipuAI/GLM-5",
  "finish": "tool-calls"
}

Claude Code 新样本

首轮真正产出 assistant 内容的 message 记录为：

{
  "role": "assistant",
  "model": "ZhipuAI/GLM-5",
  "content": [
    { "type": "text", "text": "我来帮你分析这个Claude Code源码库中MCP和skill的调用时机和链路。首先让我获取架构图的内容，然后结合源码进行分析。" },
    { "type": "tool_use", "name": "WebFetch" },
    { "type": "tool_use", "name": "Glob" },
    { "type": "tool_use", "name": "Glob" }
  ]
}

这次和 OpenCode 的模型标识已经是统一的：

  • OpenCode: modelscope / ZhipuAI/GLM-5
  • Claude Code: ZhipuAI/GLM-5

OpenCode：完整回复结构

本次 OpenCode 的落盘统计很清楚：

  • message 总数：9
  • part 分布：
    • reasoning: 8
    • tool: 19
    • text: 2
    • step-start: 8
    • step-finish: 8

也就是说，这个任务在 OpenCode 里是：

  • 1 条 user message
  • 8 轮 assistant reasoning/tool 推进
  • 1 条最终 assistant text 总结

OpenCode 的中间推进

中间 reasoning 是连续推进式的，例如：

用户想让我分析当前仓库（claude code源码库）中MCP和skill的调用时机和链路。用户提供了一个架构图链接。我需要：
1. 先获取架构图内容
2. 结合代码库分析MCP和skill的调用链路
让我先获取架构图内容，同时探索代码库中MCP和skill相关的代码。

后续再逐步收缩到：

  • src/commands/mcp/mcp.tsx
  • src/skills/mcpSkills.ts
  • src/skills/mcpSkillBuilders.ts
  • src/tools/MCPTool/MCPTool.ts
  • src/tools/SkillTool/SkillTool.ts
  • src/services/tools/toolOrchestration.ts
  • src/services/tools/toolExecution.ts
  • src/services/mcp/client.ts
  • src/commands.ts

OpenCode 的 tool 链

19 个 tool part，核心类别是：

  • webfetch
  • glob
  • read
  • grep

顺序上是：

webfetch
glob
glob
read
read
read
glob
read
read
grep
read
read
glob
read
grep
read
read
read
read

这说明 OpenCode 的这次执行路径非常标准：

抓外部图 → 扫描本地候选文件 → 精读核心实现 → 汇总

OpenCode 的最终完整回复

最终总结开头是：

基于架构图和代码分析，以下是 **MCP 和 Skill 的调用时机和链路**：

正文包含：

  1. 调用时机
  2. MCP 调用链路
  3. Skill 调用链路
  4. 核心文件映射
  5. 四层扩展体系交互

所以在这个统一模型样本下，OpenCode 的最终回复非常完整，而且直接以 assistant text part 落盘。

Claude Code 新样本：完整回复结构

新样本总行数只有 64 行，明显比旧样本干净。

统计如下：

  • assistant: 14
  • user: 21
  • tool_use_blocks: 20
  • tool_result_blocks: 20
  • assistant_text_blocks: 5
  • system/api_error: 27

这说明这个新样本有两个特点：

  1. 主线比较短
  2. 中间掺了很多 API 重试事件

Claude Code 新样本的主线

第一轮 assistant 很直接：

我来帮你分析这个Claude Code源码库中MCP和skill的调用时机和链路。首先让我获取架构图的内容，然后结合源码进行分析。

随后马上发出：

  • WebFetch
  • Glob(**/*mcp*)
  • Glob(**/*skill*)

之后继续：

  • 读 mcpSkills.ts
  • 读 mcpSkillBuilders.ts
  • 读 src/cli/handlers/mcp.tsx
  • 读 src/commands/mcp/mcp.tsx
  • 继续读 loadSkillsDir.ts
  • 继续读其他关键调用链文件

Claude Code 新样本的中间特征

这个样本里最显眼的不是工具，而是大量 API 错误与重试：

  • 429: 5 次
  • 500: 20 次
  • 502: 1 次

也就是说，这次虽然模型统一了，但执行过程比 OpenCode 抖得多。

这不是任务本身逻辑差异，而是实际运行环境和 provider 返回质量差异。

Claude Code 新样本的最终完整回复

最终总结开头是：

现在我已经收集了足够的信息来分析 MCP 和 Skill 的调用时机和链路。让我整理并呈现分析结果。

## Claude Code MCP 和 Skill 调用时机与链路分析

正文包含：

  1. 整体架构概览
  2. MCP 调用链路
  3. Skill 调用链路
  4. MCP vs Skill 核心差异
  5. 关键代码位置总结

所以这次统一模型后的真实结论是：

Claude Code 也完全能本地还原完整请求和完整回复，只是它在这次运行里夹带了大量 system/api_error 重试事件。

统一模型后的真正结论

在这个样本下，不能再说：

  • OpenCode 才能看到完整回复
  • Claude Code 只能看到执行日志

更准确的说法是：

OpenCode

  • 完整请求：清晰
  • 完整回复：清晰
  • 中间过程：以 message + part 结构化保存

Claude Code 新样本

  • 完整请求：清晰
  • 完整回复：清晰
  • 中间过程：以 assistant/tool_use + user/tool_result + system/api_error 的事件流保存

所以这次统一模型后的最准确一句话是：

两边都能还原完整任务；OpenCode 更像结构化会话数据库，Claude Code 更像带重试事件的线性 transcript。

二、相同任务下，不同 Claude 样本的差别

这一节只比较：

旧样本的问题

旧样本的问题不是“看不懂”，而是它已经不适合作为严格受控比较样本。

原因有三个：

1. 模型不单一

旧样本里混有：

  • glm-5.1:cloud
  • ZhipuAI/GLM-5
  • <synthetic>

2. 会话污染更重

旧样本总行数 249，后面还混入了：

  • drawio 相关后续请求
  • /exit
  • local-command-caveat
  • synthetic 错误回复

3. 异步 agent / task 更重

旧样本里有：

  • Agent
  • TaskCreate
  • TaskUpdate
  • 异步子任务输出

因此旧样本更像“复杂协作任务的长 transcript”，不是最适合做受控对比的样本。

新样本的优点

1. 模型统一

所有真实 assistant message 都是：

  • ZhipuAI/GLM-5

2. 主线更短

总行数只有 64，且任务边界很清楚。

3. 更适合比较“同任务同模型”

它更像：

  • 一次 prompt
  • 若干工具调用
  • 一次最终答复

所以更适合跟 OpenCode 的同任务 session 做一对一比较。

但新样本也暴露了另一个问题

虽然模型统一了，但新样本的 provider 行为更不稳定：

  • 500 明显偏多
  • 429 也不少

这导致它的 transcript 比旧样本更“脏”，但这种“脏”不是会话污染，而是重试噪声。

换句话说：

  • 旧样本的问题是“变量没控住”
  • 新样本的问题是“变量控住了，但 provider 噪声更高”

三、最终结论

这次修订后，应该把结论写成下面这组更严格的话：

关于 OpenCode vs Claude Code

在同任务、同 prompt、统一模型的样本下：

  • 两边都能看清完整请求
  • 两边都能看清完整回复
  • 真正的差别不在“有没有完整回复”，而在“中间层怎么落盘”

关于 OpenCode

OpenCode 更像：

message(user/assistant) + part(reasoning/tool/text)

适合程序化分析。

关于 Claude Code

Claude Code 更像：

assistant(text/tool_use) + user(tool_result) + system(api_error)

适合顺序回看执行链。

关于不同 Claude 样本

  • 旧样本更复杂，变量没控住
  • 新样本更干净，模型控住了
  • 但新样本 provider 重试噪声更重

最后压成一句：

统一模型之后，OpenCode 和 Claude Code 的差别不再是“谁能不能看到完整回复”，而是“谁把中间过程保存成结构化会话，谁把中间过程保存成线性事件流”；而不同 Claude 样本之间，模型统一不等于执行噪声更低。

util6 knowledge hub
Copyright © 2026 util6