AI 工程师不再写代码了？「Harness Engineering」到底是什么

正文

最近 AI 工程圈里有个词突然火了：Harness Engineering。从 X 到 LinkedIn，从硅谷开发者到国内技术社区，大家都在聊这个。它到底是什么？为什么偏偏在 2026 年初爆发？更重要的是，它会不会改变你未来写代码这件事？

一个词是怎么火起来

故事要从 2026 年 2 月 5 日说起。

Mitchell Hashimoto，Terraform 和 Ghostty 的作者，在个人博客发了一篇文章，记录他从 AI 怀疑论者到重度用户的转变过程。整篇文章有 6 个步骤，其中第 5 步他用了一个自己造的词——"harness engineering"（马具工程）。

他写道：

"I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this 'harness engineering.' It is the idea that 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."

意思是：每次发现 agent 犯错，不是去手动改那个错误，而是花时间造一个工程解决方案，让 agent 从此永远不再犯这个错 。

这个词当时没多少人注意。

六天后，2 月 11 日，OpenAI 官方博客发了一篇重磅文章，标题直接叫「Harness engineering: leveraging Codex in an agent-first world」。

事情就这样被引爆了。

OpenAI 的那个实验

OpenAI 的文章揭示了一个真实的内部实验：他们用 3 名工程师、5 个月时间，用 Codex（他们的 coding agent）从零构建了一个内部产品，最终交付了将近 100 万行代码。

关键在于：整个过程没有一行代码是人工手写的 。

从应用逻辑、测试、CI 配置、文档，到可观测性、内部工具，全部由 Codex 生成。3 名工程师平均每人每天处理 3.5 个 Pull Request，相当于传统开发效率的 10 倍左右。

这个数字在开发者圈子里炸了。

但更重要的不是这个数字，而是他们是怎么做到的。

那 3 名工程师干了什么？他们没在写代码，他们在建造一个让 agent 能可靠工作的环境 ：

• 写 AGENTS.md，告诉 agent 这个仓库的规矩和架构约束
• 设计严格的分层架构，用自定义 linter 强制执行（linter 的报错信息里直接写着「怎么改」）
• 给 agent 接入 Chrome DevTools 协议，让它能自己截图验证 UI
• 建立完整的可观测性堆栈，让 agent 能用 LogQL/PromQL 查日志排错
• 定期跑「垃圾回收 agent」扫描代码库里的坏模式，自动发起修复 PR

这才是 harness engineering 的核心：工程师的工作不再是写代码，而是设计系统、定义约束、构建反馈回路 。

「马具」这个比喻是什么意思

harness 这个词本意是给马套上的马具、缰绳。把一匹马套上马具，它能拉货、能跑路，而且不会乱跑。

把这个比喻放到 AI agent 上：harness 就是给 agent 套上的一套约束和工具体系。有了这套东西，agent 才能像被驯服的马一样，跑得快、不犯错、走正确的方向。

具体包括什么：

组成部分| 作用 ---|--- AGENTS.md| 告诉 agent 仓库规则、架构约束、禁止做的事 自定义 linter| 机械化强制执行代码风格，报错信息直接给 agent 修复指引 自动化测试| 让 agent 能自验证工作结果 可观测性工具| 让 agent 能看日志、查指标、找 bug 架构文档| 给 agent 一张地图而不是一部百科全书

Mitchell 在博客里说得很直接：这两种形式，一种是「更好的隐式提示」（改 AGENTS.md），另一种是「真正写出来的工具」（写脚本、写 linter）。当你发现 agent 反复犯同一个错，不是去 prompt 里加一句「不要这样做」，而是工程化一个解决方案，把这个约束固化下来。

这个逻辑翻转了很多人的直觉。以前大家都在优化 prompt，以为 prompt 越好 agent 就越准。现在这个理念说：真正的杠杆不在 prompt，在环境 。

为什么这个词偏偏在现在火

这个概念之所以在 2026 年初引爆，背景是 2025 年底到 2026 年初 coding agent 的大规模成熟。

Claude Code、Codex、Amp 这些工具让「一个人跑多个 agent 同时干活」从概念变成了日常实践。有人开始每天用 5-10 个 agent 并行，有人让 agent 在自己睡觉的时候跑通宵。

问题也随之出现：agent 会重复犯同样的错。它没有记忆，没有审美，没有对这个仓库的历史感知。它一遍一遍地做出一样蠢的决定，让你一遍一遍地去修。

harness engineering 给了这个问题一个答案：把你脑子里的判断力，写下来，变成系统。

Charlie Guo（OpenAI Developer Experience 团队）在 2 月 23 日发了一个长推文线程，把这个概念讲得更清楚：

他明确 credit 了 Mitchell Hashimoto，然后把 OpenAI 实验、Stripe 的 Minions 项目、solo 开发者跑多 agent 的案例全部串起来，解释了这套方法的通用性。

此后，Martin Fowler（软件架构领域的教父级人物）也专门写文章讨论 harness engineering，说它正在成为「让 AI agent 不失控」的代名词。

这跟「Context Engineering」有什么区别

同一时期还有另一个热词：context engineering（上下文工程），强调给 agent 输入高质量的上下文信息——知道该给什么信息，该给多少，在什么时机给。

harness engineering 可以理解为 context engineering 的一个子集和具体实践方向。

context engineering 更宏观：如何设计 agent 能看到的信息环境。 harness engineering 更具体：如何建造一套系统，让 agent 基于这个环境可靠地工作，并且每次犯错后环境都会进化。

两者的共同点是：都把重心从「怎么让模型更强」转移到「怎么让环境更好」 。

X 上有人用控制论来解读这个趋势——瓦特蒸汽机的调速器、Kubernetes 的自愈能力、现在的 harness engineering，都是同一种思维模式：你不再直接操控，而是设计一套反馈机制让系统自动收敛。

对工程师意味着什么

OpenAI 那篇博客里有一句话值得单独拎出来：

"当事情出错，解决方案基本上再也不会是'再努力一点'。取得进展的唯一方式是让 Codex 来完成工作，而人类工程师则介入并追问：究竟还需要什么样的能力，我们又该如何让这个能力对 agent 来说既清晰可读又可强制执行？"

这句话描述了一种角色转变：工程师从「写代码的人」变成了「设计 agent 工作环境的人」。

这个转变是真实的还是夸大的？老实说，现在还不好说，这取决于你在做什么类型的工作。对于那种有明确规范、高度模块化的业务代码，harness engineering 确实可以让 agent 大幅接管。但对于需要深度创造力和领域判断力的工作，人的角色短时间内不会消失。

不过有一点可以确定：以前只有大团队才需要的「严格架构约束 + 机械化 linter + 完善文档」这套东西，现在就算是一个人做项目也变得有价值了——因为不只是给人看，也是给 agent 看。

agent 的知识边界非常明确——存在 Google Docs 里的讨论、Slack 里的决策、人脑里的隐性知识，对 agent 来说都不存在。只有写进仓库里的、版本化的内容才真实。

这个图解释了 harness engineering 为什么必要：你不写下来，agent 就不知道。

未来会怎样

有几个方向是比较确定的：

AGENTS.md 这类文件会越来越标准化。就像 README.md 是每个仓库的必备，AGENTS.md 正在成为 agent-first 开发的标配。各种工具（Claude Code、Codex、Cursor 等）都在支持这个文件。

linter 和测试的设计逻辑会变：以前写 linter 的报错信息是给人看的，现在要考虑 agent 是否能直接理解并按照报错信息修复。「错误信息即 agent 指令」这个思路会渗透到很多工具设计里。

会出现专门的 harness engineering 工具。现在还是每个团队自己摸索，但已经有东京等地出现了 harness engineering 线下交流活动，这个方向迟早会有专门的工具链和方法论沉淀出来。

至于「工程师被 agent 取代」这个命题，harness engineering 其实给出了一个更有趣的回答：不是取代，而是升维 。从手写代码，到设计让 agent 能可靠写代码的系统。这个「让 agent 能可靠工作的环境设计能力」，本身就是一种需要深度工程经验的技能。

总结

• 词从哪来 ：Mitchell Hashimoto 2026 年 2 月 5 日博客首次提出，OpenAI 官方博客 2 月 11 日引爆
• 核心定义 ：每次 agent 犯错，就工程化一个解决方案，让它永远不再犯这个错
• OpenAI 实验 ：3 人 5 个月 100 万行代码，零手写，靠的就是这套方法
• 实践工具 ：AGENTS.md + 自定义 linter + 自动测试 + 可观测性 + 架构文档
• 趋势判断 ：工程师角色从「写代码」向「设计 agent 工作环境」转移，这个趋势是真实的

参考链接

• Mitchell Hashimoto 原文：https://mitchellh.com/writing/my-ai-adoption-journey
• OpenAI Harness Engineering 博客：https://openai.com/index/harness-engineering/