05-03 20:40 阿里巴巴集团_算法工程师 发布于北京
发布于北京 关注
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)
#我的求职进度条##AI求职记录##Harness##Agent##算法##算法岗实习#
最近看了几篇关于 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)
#我的求职进度条##AI求职记录##Harness##Agent##算法##算法岗实习#
全部评论
相关推荐
查看27道真题和解析