为什么 DeepSeek Harness 的 Benchmark 分数差这么多
DeepSeek Harness 的 benchmark 分数在不同环境下能差 30 多分——本文用可查证据梳理 Terminal-Bench 2.1 与 SWE-bench 的分歧来源，附 DeepSeek V4 Pro 的具体数字。
DeepSeek Harness 的 benchmark 分数会差出几十分，原因不是有人造了假数字，而是 agent 的工具调用策略对"用哪个 harness 跑"高度敏感。在 Terminal-Bench 2.1 上，DeepSeek V4 Pro（0813）在官方 DeepSeek Harness 下拿到 87.9 分——第三方换用另一个 harness（Terminus 2）复测，只拿到 54.68 分，同一个模型、同一个测试集，落差 33 分。这条落差背后的证据链指向的是 prompt 和工具 schema 的敏感性，而不是造假，而且它只是整个行业级 benchmark 报告问题里的一个案例。
这件事两周前还是一场"DeepSeek 是否说谎"的口水仗。现在它已经演变成一个更有用的东西：一个案例研究，说明为什么一个"不公开 harness"的 agent benchmark 分数,基本等于一个没有单位的数字。
33 分的落差：同一个模型，两个 harness
目前记录最清楚的一处分歧是 Terminal-Bench 2.1：
| 分数 | Harness | 口径 |
|---|---|---|
| 87.9 | 官方 DeepSeek Harness | 官方自报（vendor-reported） |
| 54.68 | Vals AI，用 Terminus 2 harness 复测 | 第三方 |
| "mid-fifties"（五十多分） | 另一个更严格的独立复测 | 第三方，转引 |
87.9 对 54.68 的对比、以及"87.9、78.7、mid-fifties"这套框架，均来自 @shmidtqq 广泛传播的分析（@ST4RHaze 转发），以及一篇更长的中文分析文章，由 @ZhihuFrontier 翻译转发，标题是《DeepSeek V4 Pro 是否过拟合了自家 Harness？真正问题可能是接口敏感性》。两者都是社区报告,不是 DeepSeek 官方声明——但目前是公开可查、对这条落差描述最详细的两份材料,且对落差的整体形状看法一致。
不是"锁死自家框架"——dsh 内部也有同样的模式
看到 87.9 对 54.68 的落差,最容易得出的解读是:DeepSeek 把 V4 Pro 调教得只擅长应付自家 harness,换个环境就现原形。知乎那篇分析用一个更有意思的数据点反驳了这个说法:同样的分数分布,在 DeepSeek Harness 内部自己的几种 agent 模式之间也存在,而且是同一个测试集:
- Minimal 模式：99 / 96
- Standard 模式：91
- PTC（Code）模式：92
如果模型只是单纯"锁死在自家框架"里,这三个数字——全都跑在同一个 harness 内——理应差不多。但它们并不一样。这就排除了最简单的"作弊"说法,把问题指向更具体的方向:起始 prompt 和工具 schema,而不是"harness 这个品牌"本身。
这篇分析还做了一个"锚定实验"来支撑这个结论:用 Minimal 模式的 prompt 和它的两个工具开局,然后——在第一次工具调用之后——把工具集恢复到完整的 25 个,让剩下的会话正常进行。分数几乎没变:仍然是 98/99。换句话说,模型在第一轮里做了什么,比会话余下时间里名义上有哪些工具可用重要得多。
Minimal 模式到底是什么
DeepSeek Harness 内置了一个 minimal agent 预设:系统提示固定为 You are a helpful software engineer assistant.,只挂载两个工具——bash 和 str_replace_editor——不带 Standard 或 PTC 模式那些额外的 prompt 段落和模型侧插件（完整的 agent 模式参考见 DeepSeek Harness 官方 GitHub 仓库）。知乎那篇分析认为,这不是事后加上去应付 benchmark 的小把戏——它很接近 DeepSeek 在 RL 后训练阶段大概率使用的固定 prompt/工具分布。按这个解读,V4 Pro 的 agent 训练产生了一个天花板更高、但跨框架鲁棒性更弱的模型:当运行环境看起来像它训练时见过的样子,表现出色;不像的时候,更容易掉链子。
不是 DeepSeek 独有:这是行业级 benchmark 问题
@shmidtqq 那条串更尖锐的说法引用了一项 Berkeley 4 月研究:对最常被引用的 8 个 agent benchmark 做压力测试,其中 7 个据称可以被"刷到 100% 分,但 agent 没有真正解决任何一个底层任务"。具体到 SWE-bench Verified,同一项研究据称发现,一处仅 10 行的改动就能让某个测试配置通过全部 500 个用例——而不是真的修好了那些用例本该检验的 bug。
这就是本周流传的一个更直白结论的背景:一个不公开 harness 的 agent benchmark 分数,基本等于一个没有单位的数字。 同一个模型,单纯因为 prompt 结构、工具 schema、verifier 宽松程度不同,就能表现得判若两人——而这些因素通通不会出现在那一个headline 百分比里。
一次五方 harness 横评,作为参照
目前最扎实的第三方跨 harness 数据点来自 @composio:他们用同一个 DeepSeek V4 Pro（0813）模型,跑了五种不同的 harness——Claude Code、DeepSeek Harness 0.1、Hermes、Pi Agent、OpenCode——做 30 个高难度 agentic 任务。一句话结论是:Pi Agent 解出的任务最多,而 DeepSeek 自家 harness 在成本上占优。 完整的方法论和各 harness 明细,我们放在姊妹篇《哪个 Harness 跑 DeepSeek V4 效果最好?》里详细拆解——这里想说明的重点更简单:只换 harness、不换模型,排名就变了。这和上面 Terminal-Bench 的落差是同一种现象,只不过这次是刻意测出来的,而不是无意中撞见的。
另一条批评:DeepSeek 自己的数字没法复现
还有一条更尖锐的独立批评值得如实写出来,它不会被上面"接口敏感性"的解释所化解:DeepSeek 自家 agentic benchmark 用的 harness——支撑其官方自报数字的那套具体 prompt/工具配置——一直没有公开。围绕 V4 Pro 0813 发布的部分第三方报道（在我们自己的调研笔记里被标注为未经我方独立核实）声称,DeepSeek 的 SWE-bench Verified 数字无法被外部评测机构用自己的 harness 复现出来,而某第三方评测机构自己复测得到的是一个完全不同的数字。我们刻意不在这里重复那些具体数字,因为支撑它们的信源还不够扎实——但"harness 不公开、无法复现"这条批评本身是站得住脚的,与任何一个具体第三方数字是否准确无关。
该怎么读一个 agent benchmark 分数
综合以上,下次再看到"某模型在某 benchmark 上跑出 Y% 分数"这类标题时,可以按下面几点核对:
- harness 有没有具名并标版本? "DeepSeek Harness"这个说法本身不够具体——上文 Minimal、Standard、PTC 三种模式在同一个 benchmark 上就能差出 8 分。
- harness 的代码是否公开、能否复跑? 如果不能,就把这个数字当成官方自报(vendor-reported)看待,不要把它和第三方数字直接拿来做平均——它们衡量的可能根本不是同一件事。
- verifier 是什么? benchmark 的判定标准和模型本身一样能左右结果;宽松的 verifier 会拉高分数,和任务是否真正完成无关。
- 有没有人报告过这个具体模型的跨 harness 方差? 如果没有,你看到的这一个数字,大概率只是一个从未被公开的更宽区间里的一个点。
如果是为自己的工作选 harness,唯一真正有意义的数字,是你自己在实际工作负载上跑出来的那个。可以先从一个能跑起来的安装开始——参见 DeepSeek Harness 快速上手——如果想找一个自带可复现 benchmark、而不是只喊营销口号的插件,dsh-plugin-bridge 是个不错的例子:它为自己的跨 preset 会话迁移功能记录了一套 26 轮 benchmark,代码就摆在旁边。
dsh plugin --profile web add github:Totoro-qaq/dsh-plugin-bridge
更多和 benchmark、开发工具相关的插件可以逛 Dev & Plugin Tools 分类,或者浏览 FindHarness 的完整插件目录。
FAQ
DeepSeek 伪造了 DeepSeek Harness 的 benchmark 数字吗?
没有可信证据支持这个说法。目前最详细的公开分析发现,同样大的分数落差同样出现在 DeepSeek Harness 自己的几种 agent 模式内部（Minimal vs. Standard vs. PTC），这就排除了简单的"锁死自家框架"作弊说法,而是指向 V4 Pro 的 agent 训练在泛化到不同 prompt/工具 schema 时表现出的敏感性。
为什么 Minimal 模式的分数比 Standard 模式还高?
有分析认为,Minimal 模式固定的系统提示和两个工具（bash + str_replace_editor）,很接近 DeepSeek 在 agent RL 后训练阶段使用的 prompt/工具分布,所以模型在这种条件下的表现更接近训练时的状态。Standard 和 PTC 模式加了更多工具和 prompt 结构,看起来会拉低 benchmark 峰值表现,尽管在其他方面可能有帮助。
我能不能直接把 DeepSeek Harness 的分数拿去和 Claude Code 或 OpenCode 的分数比?
只有当两者跑的是完全相同的任务集、完全相同的 verifier,并且你清楚每个 harness 具体的 prompt/工具配置时,才可以比。否则你比较的是两套不同的测量工具,而不是两个模型。
这是 DeepSeek 独有的问题吗?
不是——一项被引用的 Berkeley 压力测试研究发现,最常被引用的 8 个 agent benchmark 里有 7 个可以被刷到 100% 分而没有真正解决底层任务,并且报告称某个配置下仅 10 行改动就通过了全部 500 个 SWE-bench Verified 用例。接口/harness 敏感性是整个领域的 benchmark 方法论问题,不是这一个模型独有的。
哪里能找到真正的跨 harness 对比数据,而不是官方自报数字?
参见姊妹篇《哪个 Harness 跑 DeepSeek V4 效果最好?》,里面拆解了 Composio 的五方 harness 横评;同时请把任何单一 harness 的 benchmark 说法——包括我们这篇——当作一个数据点,而不是定论。
Next steps
阅读《哪个 Harness 跑 DeepSeek V4 效果最好?》查看完整的跨 harness 成本/速度/任务完成率拆解,到《DeepSeek Harness 两周回顾》追上本周其余的生态动态,或者从 DeepSeek Harness 快速上手开始——如果你更愿意直接在自己的工作负载上跑一遍,看那个真正有意义的数字。