从跑分到实战：你看到的分数，和模型真正能做的事，是两回事
一、一个让人困惑的现象
如果你关注 AI 领域，大概率见过这样的场景：
国产大模型比如 GLM-5.1 在 MMLU、HumanEval、GSM8K 等主流跑分榜单上，分数已经逼近甚至追平 GPT-5.4、Claude Opus-4.6。从智普股价，GLM 每天10点排队抢会员来看，国产模型确实很强了。
但当你真的把国产模型接入到 Claude Code、Codex 这类编程 Agent 中去用的时候，体验上的差距却非常明显——Claude Opus 能一次搞定的事，国产模型可能要来回折腾好几轮，有的甚至直接翻车。
"国产模型跑分不差，但实际效果不如 Claude Code"——这句话在开发者圈子里几乎成了共识。
为什么会这样？
一种很流行的解释是："国产模型是在蒸馏 Claude 的输出"。意思是说，国产模型之所以分数高，是因为它们"抄了作业"，但抄的是答案，不是解题思路，所以一到实战就不行。
1.1 "蒸馏"这个说法，对，但不全面
先说结论：蒸馏这个说法本身没错，但它不是问题的核心。
事实上，整个 AI 行业都在蒸馏。OpenAI 的模型蒸馏了人类知识，Claude 蒸馏了互联网语料，国产模型蒸馏了开源数据和合成数据。蒸馏是 AI 训练的标准技术手段，不是什么见不得人的事。
Anthropic 自己也承认，Claude 的训练数据中包含了大量互联网内容。如果按"蒸馏"的逻辑，Claude 不也是在"蒸馏"人类吗？
所以，"国产模型是蒸馏的"这句话，等于什么都没说。真正的问题是：为什么蒸馏出来的东西，在跑分上差不多，在实战中差距这么大？实际上国产模型也做了很多预训练、对齐（调教）。
1.2 跑分是怎么跑的？实战又是怎么打的？
要回答这个问题，得先搞清楚跑分和实战到底有什么区别。
| 维度 | 跑分测试 (Benchmark) | 真实工程场景 |
|---|---|---|
| 交互模式 | 单轮问答：给一个问题，给一个答案 | 多轮对话：理解需求、拆解任务、执行、验证、迭代 |
| 上下文长度 | 通常几百到几千 token | 可能达到数万甚至数十万 token |
| 工具使用 | 不需要，纯文本输入输出 | 需要调用文件系统、终端、搜索、浏览器等数十种工具 |
| 错误处理 | 错了就错了，不影响下一题 | 一步错可能导致整个项目崩溃，需要自我纠错 |
| 记忆管理 | 不需要记忆，每题独立 | 需要记住之前做了什么、为什么这么做、下一步做什么 |
| 评价标准 | 标准答案匹配，非黑即白 | 没有标准答案，"能用" "好用" "可维护" 都是模糊标准 |
看到这张表，问题就很清楚了：跑分测试的是模型的"单轮短文本能力"，而真实工程考验的是模型的"多轮长文本 + 工具链 + 记忆管理 + 自我纠错"的综合能力。
这就好比：跑分考的是百米冲刺，实战打的是马拉松 + 铁人三项 + 定向越野。你百米成绩和博尔特差不多，不代表你能跑完铁人三项。
但这还只是表面原因。更深层次的原因在于：模型在实战中的表现，不仅取决于模型本身，还取决于包裹在模型外面的那层"系统"——我们叫它 Harness。
二、Harness：被忽视的关键变量
什么是 Harness？
在软件工程里，harness 是"测试线束"的意思——你写了一段代码，要测试它，你需要一个框架来运行它、输入数据、收集结果、判断对错。这个框架就是 harness。
在 AI Agent 的世界里，Harness 的含义类似，但范围更广。
业界对 Harness 的核心共识是：
Agent Harness = 包裹 LLM 的运行时基础设施，管理工具调度、上下文工程、安全执行、状态持久化和会话连续性。LLM 只负责推理决策。
下面这张图，把 Claude Code 的 Harness 的核心组件展示出来了：
Agent = Model + Harness。 刚才有说到 LLM (Large Language Model) 本身只是一个推理引擎，它不能独立行动。
真正让它变成 Agent 的，是包裹在它周围的五个 Harness 组件：
2.1 Tools（工具系统）
模型的手脚，执行器。这些工具赋予模型与文件系统、终端、网络交互的能力。没有工具，模型只能说，不能做。
对应智能体经典模型： Perception（感知） → Reason（推理） → Action（行动） Tools 就是 Action
Claude Code 里的工具包括：
- 文件操作：Read、Write、SearchReplace、DeleteFile
- 代码搜索：Glob（按文件名匹配）、Grep（按内容搜索）
- 命令执行：RunCommand（运行终端命令）
- 子任务管理：Task（启动子 Agent 处理复杂任务）
- 用户交互：AskUserQuestion（向用户提问）
- 任务管理：TodoWrite（任务列表跟踪）
- 网络访问：WebSearch、WebFetch
- 浏览器控制：browser_navigate、browser_click 等十几个工具
这些工具不是随便设计的。Anthropic 的工程团队在博客中透露，很多工具经历了多轮迭代：
AskUserQuestion 经历了 3 次大改。最初的设计太简单，模型不知道什么时候该问用户、什么时候该自己做决定。经过反复调整，才变成现在这个带选项、带描述、带优先级的精细工具。
TodoWrite 最初是一个简单的任务列表工具，后来发现模型用它来"凑字数"——每做一步就更新一下进度，浪费大量 token。最终 Anthropic 用更强大的 Task 工具部分替代了它，让模型把精力放在真正重要的事情上。
RAG（检索增强生成） 最初 Anthropic 用的是传统的 RAG 方案，后来发现对于代码场景，直接用 Grep 搜索代码比 RAG 效果更好，于是做了切换。这个决策背后是对代码场景的深刻理解。
关键点来了：这些工具的设计和迭代，是和 Claude 模型同步进行的。工具的每一次调整，都考虑了 Claude 的行为模式；Claude 的每一次升级，也都考虑了工具的使用方式。
工具和模型是协同进化的，不是即插即用的。你把 Claude Code 的工具设计直接搬到国产模型上，效果一定打折扣。
2.2 Context（上下文管理）
context 就是我们常说的上下文，即模型当前思考的窗口。 CLAUDE.md、系统提示词、对话历史、工具定义——这些上下文在每一轮循环中被注入模型，决定了模型看到什么、知道什么。上下文管理的精妙之处是，它不仅是被动的信息传递，还包括主动的压缩和重注入策略
在真实工程中，一个任务可能涉及几十个文件、数千行代码、多轮对话。模型需要在一个"上下文窗口"内处理所有这些信息。
Anthropic 在工程博客中提到了一个很有意思的现象——"上下文焦虑"（Context Anxiety）：
当 Sonnet 4.5 的上下文窗口快用满的时候，它会开始"焦虑"——急于收尾、跳过验证、甚至直接放弃未完成的任务。但 Opus 4.5 就没有这个问题，它能冷静地管理剩余的上下文，把事情做完。
这说明什么？说明上下文管理不是简单的"塞进去多少信息"的问题，而是模型本身的行为模式问题。不同的模型在处理长上下文时的行为模式不同，Harness 需要针对不同模型做不同的适配。
Anthropic 的解决方案是 Context Reset（上下文重置）和 Context Compaction（上下文压缩）两种策略：
- Context Reset：当上下文快满时，清空当前上下文，用结构化的方式把关键信息传递给下一个会话。类似于你做完一阶段工作后，写一份交接文档给接手的同事。
- Context Compaction：在当前上下文中压缩信息，保留关键内容，去掉冗余细节。类似于你把一份 100 页的报告压缩成 10 页的摘要。
这两种策略的选择、时机的把握、信息的取舍，都需要对模型的行为有深入理解。国产模型的上下文行为模式和 Claude 不同，直接套用 Claude Code 的上下文管理策略，效果自然不好。
2.3 Memory（记忆系统）
memory 是模型的长期存储 解决的是"模型怎么记住之前发生了什么"的问题。
在 Claude Code 中，记忆分为几个层次：
- 会话内记忆：当前对话中，模型通过上下文窗口记住之前的交互。这是最基础的。
- 跨会话记忆：通过 CLAUDE.md 文件，模型可以记住项目的约定、偏好、架构决策等。这相当于给模型一个"笔记本"。
- 工具层记忆：文件系统本身也是一种记忆——模型可以通过 Read 工具重新查看之前写过的代码。
这些记忆机制的设计，同样是和 Claude 的行为模式深度绑定的。比如，Claude 知道什么时候该主动去查看 CLAUDE.md，什么时候该把新的发现写进去。国产模型可能没有这种"主动性"，因为它在训练时没有见过足够多的类似场景。
2.4 Hooks（钩子系统）
hooks 是模型的神经反射 解决自动化的事件驱动
简单来说，Hooks 允许在特定事件发生时自动执行预定义的操作。比如：
- 每次模型生成代码后，自动运行 lint 检查
- 每次修改文件前，自动创建备份
- 每次任务完成后，自动运行测试套件
Hooks 的价值在于：它让很多"好习惯"变成了自动行为，而不需要模型每次都"想起来"去做。这极大地提升了输出的稳定性和质量。
对于国产模型来说，即使你实现了类似的 Hooks 机制，模型是否能正确地配合这些 Hooks，仍然取决于模型的训练和行为模式。
2.5 Permissions（权限系统）
permissions 是模型的安全围栏，决定了模型能做什么、不能做什么，专业点可以称为能力边界控制系统。
Claude Code 的权限设计非常精细：
- 文件读写权限：可以限制模型只能操作特定目录
- 命令执行权限：可以限制模型只能运行特定类型的命令
- 网络访问权限：可以限制模型能访问哪些网站
- 用户确认机制：对于高风险操作（如删除文件、安装依赖），需要用户确认
权限系统看似是"限制"，实际上是一种"引导"。合理的权限边界能让模型更专注于它擅长的事，避免在不必要的地方浪费 token 或犯错。
更重要的是，权限系统和模型的行为是相互影响的。Claude 知道在什么情况下需要请求权限、怎么描述自己的意图以获得用户信任。这种"社交能力"同样是训练出来的。
2.6 Harness 不是工具箱，是操作系统
注意图中的空间关系：Model 在中心，五个组件围绕它排列，整体被一个名为 Harness 的边框包裹。这不是随意的布局，它精确表达了一个架构事实：模型不直接接触外部世界，所有交互都通过 Harness 的组件中转。Harness 是模型和现实之间的唯一接口。
看完上面这些组件，你应该能感受到：Harness 不是一个简单的"工具箱"，更像是一个"操作系统"。
工具箱是被动等待你拿工具去用，操作系统是主动管理资源、协调任务、处理异常。Claude Code 的 Harness 就是这样一个"操作系统"——它主动管理上下文、协调工具调用、处理错误、维护记忆。
而关键在于：这个"操作系统"是专门为 Claude 定制的。
2.7 小结
- Anthropic 定义的是 Agent = Model + Harness
- Tools 是模型的手脚,执行器， 解决行动能力
- Context 是模型的当前思考的窗口， 解决模型看到什么
- Memory 是模型的长期存储，解决持久化记忆
- Hooks 是模型的神经反射，解决自动化的事件驱动
- Permissions 是模型的安全围栏，解决安全底线问题
三、Claude Code 不是工具，是为 Claude 定制的系统
这是这篇文章最核心的观点，也是大多数人忽略的一点。
3.1 "工具"和"系统"的区别
我们通常理解的"工具"是什么？是一个通用的东西，谁都能用。比如锤子，张三用和李四用，效果差不多。
但 Claude Code 不是锤子。它更像是"为某个特定运动员定制的跑鞋"——鞋底的硬度、鞋面的包裹性、鞋钉的排列，都是根据这个运动员的脚型、跑姿、发力习惯量身定做的。你把这双鞋给另一个人穿，可能还不如一双普通跑鞋。
| 通用工具（如 Cursor） | 定制系统（如 Claude Code） | |
|---|---|---|
| 设计理念 | 支持多种模型，追求通用性 | 只为 Claude 服务，追求极致适配 |
| 工具设计 | 标准化接口，所有模型用同一套 | 根据 Claude 的行为模式专门设计 |
| 迭代节奏 | 工具和模型独立迭代 | 工具和模型协同进化 |
| 上下文管理 | 通用策略，不针对特定模型 | 针对 Claude 的上下文行为精细调优 |
| 错误处理 | 标准化的错误提示和重试机制 | 根据 Claude 的错误模式定制处理逻辑 |
| 优化深度 | 显性优化（可见的工具和配置） | 显性优化 + 隐性优化（预训练层面的适配） |
3.2 隐性优化：预训练层面的"默契"
这是最容易被忽略、但也最关键的一点。
Claude Code 的 Harness 之所以和 Claude 配合得这么好，不仅仅是因为工具设计得好、上下文管理做得好。还有一个更深层次的原因：Claude 在预训练阶段，就已经"见过"大量类似 Claude Code 使用场景的数据。
什么意思？
Anthropic 的工程师在开发 Claude Code 的过程中，会产生大量的"使用日志"——模型怎么调用工具、怎么处理错误、怎么管理上下文、怎么和用户交互。这些日志中的一部分，很可能以某种形式进入了 Claude 的训练数据。
这就形成了一种"默契"：
- Claude Code 的工具设计，参考了 Claude 的行为模式
- Claude 的训练数据，包含了 Claude Code 风格的交互模式
- 两者互相影响、互相强化，形成了一个正向循环
这种"默契"是隐性的，你看不到、摸不着，但它实实在在地影响着模型的输出质量。
打个比方：这就像一个乐队，主唱和吉他手一起排练了上千场演出。他们之间有一种默契——主唱一个眼神，吉他手就知道要切换节奏。你把同一个吉他手放到另一个乐队里，这种默契就不存在了。
国产模型没有这种默契。即使你把 Claude Code 的 Harness 完整地搬过来，国产模型也不会像 Claude 那样"自然地"使用这些工具，因为它在训练时没有建立这种隐性关联。
3.3 正向飞轮效应
更厉害的是，Claude Code 和 Claude 之间形成了一个"正向飞轮"：
- 开发者使用 Claude Code → 产生大量真实的使用数据和反馈
- Anthropic 收集这些数据 → 优化 Claude Code 的 Harness 设计
- Harness 的优化 → 提升 Claude 在 Claude Code 中的表现
- 更好的表现 → 吸引更多开发者使用
- 更多开发者 → 更多数据和反馈 → 回到第一步
这个飞轮每转一圈，Claude Code 和 Claude 之间的"默契"就更深一层，其他模型要追赶的差距就更大一层。
这不是"蒸馏"能解释的。蒸馏是静态的、一次性的；飞轮是动态的、持续迭代的。
3.4 一个真实的对照实验
之前的文章里，我们用 Trae 和 Claude Code 做了对比实验，通过 Skill 创建页面。同样的任务、同样的代码库，结果差异巨大：
- Claude Code：理解需求准确，代码结构清晰，一次通过率高，出错后能自我纠错
- Trae：经常理解偏差
回到这篇文章再来看这个实验：在真实工程场景中，"模型 + Harness"的组合效果，远比单独看模型跑分有意义。
而 Claude Code 的优势，恰恰在于 Claude 和 Harness 之间的深度协同——这种协同是经过长时间迭代、大量数据喂养、持续优化才建立起来的。
四、总结
回到开头的问题：为什么国产模型跑分不差，用起来却差很多？
答案不是"蒸馏"。蒸馏是表象，不是原因。
真正的原因是三层：
- 第一层（表面）：跑分测的是单轮短文本能力，实战考验的是多轮长文本 + 工具链 + 记忆管理 + 自我纠错的综合能力。这两个赛道本身就不一样。
- 第二层（中间）：模型在实战中的表现，很大程度上取决于包裹在模型外面的 Harness 系统——工具设计、上下文管理、记忆系统、钩子、权限，每一个组件都需要和模型深度协同。
- 第三层（深层）：Claude Code 不是"工具"，而是"为 Claude 定制的系统"。Claude 在预训练阶段就已经和 Claude Code 的交互模式建立了隐性关联，加上持续的正向飞轮效应，形成了其他模型难以复制的深度协同。
跑分接近了，但 Harness 的协同深度、预训练的隐性默契、正向飞轮的积累，这些才是真正的差距所在。
理解了这一点，你就能更清醒地看待 AI 领域的"跑分竞赛"，也能更理性地选择适合自己场景的模型和工具。
毕竟，我们最终要的不是分数，是能把活干好。
