Harness才是隐藏的王者：一下午让15个LLM编程能力提升的秘密

每个人都在问：GPT-5.3还是Opus？Gemini还是Claude？

这种问法本身就错了。

一位开发者在HN分享了一个令人震惊的发现：他只改了一个变量——编辑工具——就在一个下午让15个LLM的编程能力显著提升。模型还是那个模型，变的是中间的"harness"（工具链）。

这揭示了一个被整个行业忽视的真相：LLM编程的瓶颈，往往不在模型，而在工具。

那个改变一切的下午

故事的主角是oh-my-pi，一个开源编程助手框架。作者@can1357在这个项目上已经提交了约1300次代码，大部分是对harness的渐进式改进。

他这次做了什么？

只改了一个东西：编辑工具（Edit Tool）。

结果就是：15个不同LLM的代码编辑成功率大幅提升。Grok 4的patch失败率从50.7%降到几乎为零，GLM-4.7从46.2%的故障率变成了稳定输出。

同样的模型，不同的harness，天壤之别。

为什么Harness如此重要？

想象一下：你雇了一个超级聪明的程序员，但给他一台打字机、一个坏掉的键盘、和一套他看不懂的指令格式。他再聪明也发挥不出来。

Harness就是那个"工作环境"。它负责：

• 接收用户的第一印象——是疯狂滚动还是丝滑流畅？
• 构造每一个输入token——模型看到什么，取决于你怎么喂
• 桥接输出与实际修改——模型说"改这里"，harness负责真正去改

正如作者所说："模型知道要改什么"和"问题被解决"之间，就是harness的地盘。而这里，正是大多数失败实际发生的地方。

主流方案的困境

让我们看看目前主流的编辑工具方案，以及它们的问题：

OpenAI Codex: apply_patch

Codex使用一种OpenAI风格的diff格式。它假设模型会输出严格符合格式的patch字符串。

问题是：这种格式是Codex专属。

把这个patch格式丢给Grok 4？patch失败率50.7%。丢给GLM-4.7？46.2%。这些不是差模型——它们只是不会说这种"方言"。

Claude Code & Gemini: str_replace

Claude Code和大多数其他工具使用简单的"查找并替换"：找到完全匹配的旧文本，替换为新文本。

这听起来很合理，但模型必须逐字逐句完美复现原始文本，包括空格和缩进。多一个空格就匹配失败。多个匹配？直接拒绝。

GitHub上Claude Code的"String to replace not found"错误有自己的megathread，还有27个相关issue。这说明了什么？

Cursor: 再训一个模型

Cursor的解决方案最"暴力"——他们专门fine-tune了一个70B模型，唯一工作就是把草稿编辑正确合并到文件里。

Harness问题难到让一家资金充足的AI公司决定再扔一个模型去解决。

这反过来说明：如果harness没做好，再强的底层模型也白搭。

新方案：结构化编辑

oh-my-pi的作者采用了什么方案？

让子代理输出结构化数据，而不是原始文本。

不再指望模型生成完美格式的patch或精确匹配的字符串，而是定义清晰的数据结构：改哪个文件、第几行到第几行、新内容是什么。Harness负责把这个结构化指令翻译成实际的文件操作。

听起来简单？但行业主流至今还在用文本匹配方案。

这就像从"让对方猜你想吃什么"变成"直接告诉对方点菜单编号"。误差空间大幅缩小。

更深层的启示

这个案例给我们几个关键启示：

1. 模型竞赛的视角偏差

整个行业都在盯着基准测试排行榜，仿佛模型分数就是一切。但真实世界的表现是模型 × Harness的乘积。

一个90分的模型配60分的harness，可能打不过80分的模型配90分的harness。

2. 开源生态的机会

Cursor能解决harness问题是因为他们有钱训专用模型。但开源社区可以换条路：设计更好的协议和接口。

如果有一个标准化的"编辑指令格式"，所有模型都能适配，那就不需要每个模型都学一套方言了。

3. 评估基准的盲区

现在的编程能力评测（如SWE-Bench）测的是端到端结果。但"模型能力"和"harness效率"被混在一起了。

这意味着：排行榜上的分数，不完全是模型本身的功劳。

如果评测时给GPT-5.3配的是最优harness，给其他模型配的是通用harness，那比较本身就是不公平的。

给开发者的建议

如果你是AI编程工具的使用者或开发者：

不要只看模型名字。同样叫"Claude Code"，一个月前的版本和今天的版本可能天差地别——不一定是模型升级了，可能是harness改进了。

关注失败模式。是模型理解错了？还是harness执行错了？"Patch失败"和"逻辑错误"是完全不同的问题。

如果你是工具开发者：投资harness。一个好的harness能让中等模型发挥出上等表现，而一个差的harness能废掉最强模型。

行业的下一步

这个发现可能改变AI编程工具的竞争格局。

短期内：我们会看到更多项目关注harness优化，而不只是模型接入。

中期来看：可能出现标准化的"LLM编辑协议"，类似LSP（Language Server Protocol）对于IDE的意义。

长期来看：模型和harness的边界可能会模糊。就像Cursor用模型解决harness问题，未来可能出现"端到端训练"，直接让模型输出可执行的结构化指令。

但有一点是确定的：单纯堆模型参数的收益正在递减，而工具链的优化空间还很大。

结语：回到第一性原理

这位开发者的实验提醒我们：在追求更强模型之前，先看看手里的工具有没有拖后腿。

他花了一个下午，改了一个编辑工具，让15个LLM的表现都提升了。

这不需要10亿美元算力，不需要训练新模型。需要的只是对问题的深入理解，和一点点工程优化。

在AI竞赛的喧嚣中，这种"回归本质"的思考尤为珍贵。

毕竟，再聪明的脑子，也需要合适的手才能发挥作用。

---

感谢@can1357的分享和oh-my-pi项目。如果你想深入了解这个话题，可以查看原文和相关开源代码。