The Harness Problem

Can Bölük 这篇 The Harness Problem 讨论的是一个容易被忽略的问题：我们评价 coding agent 时，常常把结果全部归因到模型本身，但模型真正工作的环境并不只是 prompt，还有 harness。

这里的 harness 可以理解成模型和真实工作区之间的整套外骨骼：文件读取方式、上下文组织、工具 schema、错误信息、编辑协议、状态管理，以及失败后如何恢复。模型知道要改什么，不等于它能稳定地把修改落到文件里；而这个中间层一旦设计得别扭，很多“模型不行”的失败其实是工具边界的失败。

文章里最有意思的是 edit tool 的对比。apply_patch 对 Codex 友好，但对没有专门适配过这种格式的模型可能很脆；str_replace 看起来简单，却要求模型精确复述旧文本，空格、缩进、多处匹配都会变成失败点；Cursor 选择再训练一个专门负责 apply 的模型，也侧面说明“把意图合并进文件”本身就是个难题。

作者提出的 hashline 思路很小，但切中要害：读文件或 grep 时，每一行都带一个短 content hash，之后编辑时用这些 line tag 作为锚点，比如替换某一行、某个范围，或者插入到某个 tag 之后。这样模型不需要重新背出旧文本，只需要引用它刚刚看见过的稳定标识；如果文件中途变了，hash 对不上就拒绝编辑，避免默默改坏。

这和人类编辑代码时的直觉也接近：我不是靠复述整段旧文本来证明自己知道在哪里改，而是靠位置、上下文和可验证的锚点来表达修改意图。对 LLM 来说，短 hash 像是把“我指的是这里”变成了一个工具协议，而不是让模型用脆弱的文本重构来碰运气。

benchmark 结果也强化了这个判断：同一批模型、同样的任务，只换 edit tool，成功率和 token 消耗就明显变化。弱一些的模型收益更大，因为它们原本可能不是不会修 bug，而是被 patch/replace 的机械失败卡住了。换句话说，harness 会遮蔽模型能力，也会释放模型能力。

最后作者 vendor 那段也很关键：如果每家公司都只优化自家模型和自家 harness，开放生态就很难把这些经验沉淀成公共基础设施。模型是护城河，但 harness 更像桥；桥修得越好，越能看清不同模型真实的能力边界。

References

I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed.