Harness不是加一行规则那么简单——深度解析三家科技巨头的AI行为工程实践

2026年，Harness（缰绳工程）已成为AI开发领域的热门话题。各种社群中充斥着“缰绳工程”、“马鞍比马重要”等概念，似乎只要在配置文件中加一行“不要做XX”的规则，就掌握了Harness的精髓。但当我深入阅读Mitchell Hashimoto、OpenAI和Anthropic的原文后，发现一个关键问题：大多数文章都在解释Harness是什么，却很少有人回答一个更实际的问题——读完之后，我到底该做什么？

第一步：编写行为规则

Harness不是一个东西，是一条路。这条路分为三步，而大多数人只走了第一步。

第二步：打造自动化工具

Terraform和Vagrant的创始人Mitchell Hashimoto今年2月发表文章，讲述自己从AI怀疑者变成“缰绳工程师”的过程。他给Harness Engineering下了一个精辟的定义：“Anytime you find an Agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”（每次AI犯错，你都花时间建一个机制，让它永远不再犯同类错误。） Harness的第一种形态是文字规则：写进AGENTS.md或CLAUDE.md的行为约束。以他开源项目Ghostty为例——那个文件里的每一行，都对应着一次AI犯过的错。AI编造了一个你没经历过的故事？加一条“禁止编造困境”。AI总是不该改的地方改代码？加一条“只改指定文件”。这就是最简单的起步方式。 但如果停在这一步，会遇到一个明显的天花板：规则是被动的——AI读到了才生效，读不到就没用。

第三步：分离评估

Harness的第二种形态是自动化工具——脚本、linter、测试。换句话说，不是靠“跟AI说一声”来约束它，而是造一个工具让机器自动检查。OpenAI的团队把这件事做到了极致。 他们做了一个激进的实验：3个工程师，5个月，整个项目不允许任何人手写代码。结果合并了1500个PR，产出约100万行代码，做出了一个有真实用户在用的产品。但最值得关注的不只是结果，而是过程。工程师Ryan Lopopolo在文章里写道：“Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified.”（早期进展比预期慢，不是因为AI不行，而是因为环境缺乏定义——AI缺少完成任务所需的工具和结构。） 他们做了什么？给AI造工具。让AI能启动应用、截图、驱动浏览器来验证自己的工作；让AI能查询日志和监控指标来判断性能是否达标；让AI有一整套本地可观测性栈来调试问题。工程师的工作，从“写代码”变成了“让AI能验证自己的代

Anthropic的工程师Prithvi Rajasekaran发现了一个底层问题：让AI评估自己的产出，它永远会给自己打高分。“Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.”（让一个独立的评估器变得苛刻，远比让生成器自我批评容易得多。）这是系统性的偏差。即使在有客观标准的任务上（比如代码能不能跑通），AI自我评估时依然倾向于给自己开绿灯。 Anthropic的解法借鉴了GAN（生成对抗网络）的思路：把生成和评估分开。一个AI负责做事（generator），另一个独立的AI负责打分（evaluator）。evaluator用Playwright实际操作产品——点击、截图、检查功能——然后给出评分和具体的改进意见。generator根据这些反馈迭代。 结果：同样的任务，加上evaluator之后，产出质量有明显提升。一个4分钟生成的网页和一个经过15轮评估迭代的网

如有侵权，请联系删除。