AI 写代码之后，Harness Engineering 为什么会冒出来？最近看了几篇关于 Harness Engineering 的文章，感觉这个词虽然新，但背后的东西一点都不玄。它本质上不是一个新的框架，也不是一套提示词技巧，而是一个很普通的软件工程问题：当 AI Agent 真的开始参与开发，怎么让它在一个真实代码库里持续干活，并且别把项目搞乱？如果只是让模型写一个函数、补一个脚本，其实不用太多 Harness。但一旦任务变成连续开发一个功能、跨多轮上下文接力、修改真实业务代码、自己跑测试看日志修 bug，最后还要判断“是不是完成了”，问题就会变得很像团队协作问题，而不是单次代码生成问题。1. Anthropic 先碰到的是“接不上班”Anthropic 在 2025 年 11 月那篇文章里，讲的是 long-running agents。我觉得这里最值得看的不是它用了哪些 agent，而是它遇到的问题很真实：一个 Agent 做到一半，下一轮接手时不知道现场是什么状态。这其实就是工程团队里的交接问题。人类工程师交接时至少会留下：- 当前做到哪了- 哪些测试跑过- 哪些地方还没做- 哪些决策已经定了- 代码为什么这样改如果这些东西没有留下来，下一个人接手也会懵。Agent 也一样。所以 Anthropic 的做法不是单纯加长上下文，而是让系统显式保存现场，比如进度记录、git history、feature list、验证结果。这件事很关键：长任务的核心不是让 Agent 一口气干完，而是让它能被可靠接力。2. Mitchell Hashimoto 给了它一个名字Mitchell Hashimoto 后来把这套东西叫 Harness Engineering。我觉得这个名字好，是因为它把关注点从“模型聪不聪明”拉回到了“工程环境靠不靠谱”。他那篇文章里有个思路很值得借鉴：Agent 每次犯错，不要只归因于模型不行，而是看能不能把这次错误沉淀进系统。比如：- 它总是不知道项目约定，那就写进 `AGENTS.md`- 它老是忘记跑某个检查，那就做成脚本- 它改 UI 改歪了，那就加截图验证- 它跑全量测试太慢，那就准备更合适的测试入口这和传统工程里的 postmortem 很像。事故发生后，成熟团队不会只说“下次注意”，而是补监控、补测试、补流程、补自动化。Harness Engineering 对 Agent 做的是同一件事。3. OpenAI 把它放进 Codex 的工程叙事里OpenAI 讲 Codex 的时候，把 Harness Engineering 提到了一个更高的位置。我理解它想表达的是：AI 写代码之后，工程师不是消失，而是工作位置变了。以前工程师主要是直接写代码。现在一部分工作会变成：- 给 Agent 定义任务边界- 给它准备上下文- 给它提供工具- 给它设计验证路径- 判断它的结果是否可信- 把反复出现的问题固化到工程系统里这不是“不会写代码也能当工程师”。恰恰相反，这更吃工程经验。因为你要知道什么地方容易出问题，什么东西必须自动验证，什么上下文对修改代码真的有用，什么规则写了也没人看。4. Martin Fowler 那篇提醒了一件事：别把 Harness 做成文档堆我觉得 Martin Fowler 网站上那篇比较有价值的地方，是它提醒大家别走偏。很多人一听 Harness，就会开始写文档：项目规范、编码要求、Agent 使用指南、各种“你应该”。但文档不是没用，而是只靠文档不够。真实项目里，最有用的约束往往不是“请不要破坏架构”，而是：- 破坏架构时测试会挂- 越界依赖会被 lint 拦住- 类型系统会报错- CI 会失败- 日志能指出问题- review 能发现设计不对也就是说，Harness 更像一套反馈系统，而不是一份说明书。如果系统不能发现偏差，只是告诉 Agent “你要写好代码”，那基本等于许愿。5. Michael Bolin 的观点：Harness 不要做太重Michael Bolin 的方向我也挺认同。如果 Harness 做得太重，给 Agent 包一层又一层专用框架，最后它可能只是一个会点按钮的自动化脚本。但 Codex 这类 Agent 更像是要在真实开发环境里工作。所以它需要的是少量但通用的能力：- 终端- 文件系统- 沙箱- 测试命令- 上下文入口- 必要的记忆这里有个取舍：Harness 不能什么都不管，否则 Agent 会乱跑。但 Harness 也不能太厚，否则模型自己的推理和探索能力发挥不出来。比较理想的状态是：环境要稳，工具要少，反馈要快，边界要清楚。6. Anthropic 后来又提出两个很现实的问题Anthropic 后面那篇 long-running apps 里，我觉得两个问题特别有现场感。第一个是 context anxiety。上下文一长，Agent 会开始乱。它会反复翻旧信息，担心漏东西，最后判断质量下降。第二个是 self-evaluation distortion。Agent 自己评估自己时，容易过度乐观。这个也很符合日常体验。让一个 Agent 自己写、自己测、自己宣布完成，风险很高。所以更合理的方式是把角色拆开：- 一个 Agent 负责实现- 一个 Agent 负责检查- 系统负责跑测试- 人负责最终判断方向和取舍这其实就是软件工程里很老的东西：开发、测试、review、发布，不应该全靠同一个脑子。所以 Harness Engineering 到底在解决什么？我现在更愿意把 Harness Engineering 理解成：为 AI Agent 准备一个可交接、可验证、可恢复、可约束的软件工程环境。它不是 prompt engineering。Prompt engineering 解决的是“怎么和模型说”。Harness Engineering 解决的是“模型干活时，系统怎么兜底”。这两个层级差很多。AI Agent 越强，Harness 反而越重要。原因很简单：它写得越快，跑偏也越快。以前一个工程师一天写错一点代码，review 还能拦一拦。以后 Agent 半小时改几十个文件，如果没有测试、日志、边界、review 和交接记录，项目会坏得非常快。所以我不觉得 Harness Engineering 是一个短期热词。它更像是 Agentic Coding 真正进入工程现场之后，大家不得不重新重视的软件工程基本功。最后一句话总结：Harness 不是用来管人的，是用来约束代码生产过程的。或者说得更直接一点：AI 写代码之后，软件工程没有变轻，反而更工程了。参考文章- Anthropic: [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)- Mitchell Hashimoto: [My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey)- OpenAI: [Harness engineering](https://openai.com/index/harness-engineering/)- Martin Fowler: [Harness Engineering](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html)- Anthropic: [Harness design for long-running apps](https://www.anthropic.com/engineering/harness-design-long-running-apps)
