Agent Harness 工程！被忽视的另一半

凌晨两点，AI工程群里弹出一条消息：这个AI Coding工具又双叒叕把测试代码注释掉了，commit了一个半成品。紧接着是一连串苦笑的表情。 这种场景，对AI技术圈的朋友来说，应该不陌生。 我们花了大量时间讨论哪个模型更聪明、哪个上下文窗口更大、哪个幻觉更少。但很少有人意识到，模型只是这个系统的一半。 另一半，是一个叫Harness的东西——它决定了你的AI Agent到底能帮你干活，还是只会添乱。 这个脚手架，才是拉开差距的关键。

当我们在讨论模型时，我们在忽视什么

过去两年，模型军备竞赛打得火热。

Claude、GPT、Gemini，一个比一个参数多，一个比一个上下文长。

技术圈聚会聊起这个，氛围像在讨论显卡跑分——激动、频繁、却漏掉了点什么。

Addy Osmani最近写了篇文章，把这个盲区戳得很准：一个coding agent，是模型加上你围绕它搭建的一切。

模型是发动机，但Harness是传动系统、方向盘、刹车片。没有后者，前者再强也只是实验室里的玩具。

Harness都包含什么？

Prompt本身、工具定义、上下文管理策略、hooks拦截器、沙盒环境、子agent编排、反馈循环和失败恢复路径。

这些东西加在一起，才让一个"能写代码的模型"变成"能帮你干活的agent"。

有意思的是Viv Trivedy提出的那个等式：Agent = Model + Harness。如果你不是模型，那你就是Harness。

这句话听起来简单，但把它当真的人不多。

大多数工程师遇到agent犯蠢，第一反应是"这破模型"，然后把issue丢给供应商等下一版本。

很少有人意识到，问题可能出在自己搭的那层脚手架上。

之前Claude Opus 4.6在Terminal Bench 2.0上的数据很有说服力。同一模型，跑在Claude Code里和跑在定制Harness里，分数差了一截。Viv的团队只调整了Harness，就把一个Top 30的coding agent推到了Top 5。

模型和它接受训练时的Harness是绑定的。把它挪到一个更适合你场景的脚手架里，给它更趁手的工具、更精准的prompt、更清晰的压力反馈机制，它就能释放出原Harness没激活的能力。

这就是所谓的Harness Gap。

你今天让某个模型"能做到"的事情，和它在你手里实际"做成"的事情之间，隔着一个Harness。

那些把错误当燃料的团队

Harness Engineering这个理念，真正有价值的地方在于：它把每一次失败都当成输入，而不是终点。

我见过两种团队。

一种的循环是：agent犯错 -> 骂模型垃圾 -> 忍着继续用。

另一种是：agent犯错 -> 分析为什么犯 -> 在Harness里加一条规则。

这两种团队的AI Agent使用体验，会在三个月后拉开巨大差距。

举个栗子。

假设你的agent提交了一个PR，里面测试代码被注释掉了，你没注意就merge了。

Harness Engineering的思维方式是这样运作的：

首先，这是AGENTS.md里缺少约束的信号。

下一版文件里会多一条："永远不要注释掉测试，要么删掉，要么修好。"

然后，pre-commit hook会加一个检查，在diff里grep .skip( 和 xit(。再然后，reviewer子agent会把被注释掉的测试标记为blocker。

这条规则从哪来的？

不是拍脑袋想出来的，是从真实发生过的失败里长出来的。

好的AGENTS.md，每一行都能追溯到某个具体的事故现场。

这不是一上来就能写完的，它是跟你的agent一起成长出来的文档。

用进化的方式做加法，用确认的方式做减法。 只有当一个足够强的模型让某条约束变得多余，你才能把它删掉。

HumanLayer总结的那句话很扎心：**"这不是模型问题，是配置问题。"**

把这句话认真当真的那一刻，Harness Engineering才真正开始。

结语

Harness Engineering不是某个框架，不是某套最佳实践文档，它是一门需要随着你的agent犯过的错一起生长的手艺。

你没法下载一个现成的Harness来适配你的代码库。 它必须从你的失败里长出来，从你真实的业务场景里长出来。

那些在AI Agent这件事上真正拉开差距的团队，不是手里握着最强模型的那批人，而是最懂自己的Harness在做什么、为什么这样做、哪里需要调整的那批人。

下一次你的agent又搞出什么幺蛾子，别急着骂模型。先看看，这个错误是不是在Harness层面就能解决。

如果是，那恭喜你，你刚刚找到了一个让整个系统变强的机会。

这个机会，只属于愿意认真对待脚手架的人