任务成功率从 6.7% 到 68.3%：10 倍差距来自 Harness，而非模型

Grok Code Fast 的编码基准成功率是 6.7%。不换模型，只替换一种编辑格式，成功率变成了 68.3%。模型参数一个比特都没动。

假期期间亲自跑 Agent 时，也有过类似的体验。模型发布速度快到令人窒息，但在实际工作中极端拉开性能差距的，并不是模型本身，而是包裹模型的 Harness，也就是系统提示词、工具配置和中间件的组合。

同一个模型，不同的排名

LangChain 团队用自研 Coding Agent 跑了 Terminal Bench 2.0。GPT-5.2-Codex 原封不动，只调整了系统提示词、工具配置和中间件。分数从 52.8 涨到了 66.5，从排行榜 30 名开外进入前 5。模型训练成本为零。

核心在于推理预算的分配。对所有任务统一使用 xhigh，成绩停留在 53.9%；按任务难度拆分为 xhigh-high-xhigh 后，成绩升至 66.5%。原本因超时失败的问题，通过这种分配策略得到了解决。同样的模型、同样的 token 预算，只是分配方式不同。

被编辑格式掩盖的真实能力

一位开源 Agent 开发者创造了一种叫 hashline 的编辑方式。读取文件时，每行都附加一个 2 到 3 字符的哈希标签，模型修改时只需引用该标签。

旧方式要求模型逐字逐句完整复现原始文本，哪怕一个空格出错就会失败。用过 Coding Agent 的人都体会过那种反复出现”String not found”报错的痛苦。hashline 从结构上绕开了这个问题。

结果相当惊人。Grok Code Fast 从 6.7% 跃升至 68.3%，Grok 4 Fast 的输出 token 减少了 61%。GPT-4 Turbo 仅凭格式切换就从 26% 变成 59%，Gemini 3 Flash 超过了此前的最高纪录 5 个百分点。没有任何模型训练成本，只是换了一个编辑接口。

没有验证循环，就停在第一个答案上

最常见的失败模式是这样的：Agent 写出代码，重新读一遍，觉得没问题，然后结束——一次测试都没跑。

LangChain 团队在 Agent 退出前加入了一个中间件，强制对照任务规格进行验证。对同一文件反复编辑的”宿命循环”，也通过另一个中间件进行检测，引导 Agent 重新考虑方案。没有这两个机制，分数提升幅度会小得多。向 Agent 预先注入目录结构和可用工具，以及通过时间预算警告引导进入验证阶段，同样起到了效果。

模型越弱，对 Harness 越敏感

MiniMax M2.5 和 Kimi K2.5 速度快，擅长使用 Agent 工具，价格也比大型模型低得多。代价是基础知识弱于美国头部模型。MiniMax 感觉从一开始就是为 Agent 特化训练的，资源有限所以选择专精而非通用，低廉的价格也让它在 Openclaw 等平台上的使用量快速增长。

从 hashline 基准结果来看，模型越弱，格式切换带来的性能波动越剧烈。MiniMax 在应用 hashline 后，成功率翻了两倍以上。整个基准测试的费用大约是 300 美元。

基准不等于生产

有一点需要注意。无论是 Terminal Bench 还是 hashline 基准，都是在受控环境下测量的数值。实际生产中，代码库规模、依赖冲突、模糊需求等变量要复杂得多。在基准上拿到 66.5% 的 Agent，能否在十万行的遗留项目中维持同样的表现，目前尚未得到验证。Harness 优化确实有效，但把基准排名直接换算成生产性能是危险的。

方向依然明确。在某些阶段，Harness 设计的 ROI 明显高于模型选型。我们现在看到的基准排名，相当大一部分反映的是 Harness 的质量，而不是模型的能力。