AI工程师革命：驯服Agent的六步法则

2026 年 2 月 5 日，HashiCorp 创始人 Mitchell Hashimoto 在博客里写下一篇《My AI Adoption Journey》，记录了一个老派工程师从不信 AI 到每天让 Agent 替他写代码的心路历程。

他把这个过程拆成六步。第一步就反直觉——扔掉对话框，直接用能自主执行的 Agent。第二步更狠，强迫自己用 Agent 重做已经手写过的代码，明明自己两下能写完的活儿，非要等 Agent 慢慢磨。他说这个过程 painful。

但最关键的是第五步。他给自己的做法起了个名字：Engineer the Harness——打磨马具。定义只有一句话：

每次当你发现 Agent 犯了一个错误，就花时间去工程化一个解决方案，让它永远不会再犯同样的错误。

这个表述很快在 AI 工程圈炸开。一周后 OpenAI 发了一篇官方博客《Harness engineering: leveraging Codex in an agent-first world》，讲一个三人小团队用 Codex Agent 在五个月内写出近百万行代码、合并了 1500 个 PR，全程零手写。从此 Harness Engineering 从一个个人实践变成了一个被行业认可的工程范式。

1. 不是又一个换皮概念

AI 工程的重心在过去三年里换了三次，每一次都对应一个不同的瓶颈。

Prompt Engineering 是 2023 年的主旋律。模型还笨，输出质量高度依赖提问方式。大家研究角色设定、思维链、few-shot——核心是"这句话怎么说，模型才听话"。

Context Engineering 在 2025 年前后接棒。模型变强了，窗口也大了，问题变成了"该喂什么信息、怎么组织这些信息"。RAG、AGENTS.md、知识库管理都在这一层。

Harness Engineering 是 2026 年的新瓶颈。模型已经足够好，Agent 也开始承担长链路、多步骤的自主任务。但执行过程会跑偏——同一个错误反复犯，同一个坑反复踩。问题不在模型本身，在模型外面那层运行环境。

三个阶段的递进逻辑很清楚：Prompt 教模型怎么说话，Context 保证它上班前装好信息，Harness 给它搭一个能持续干活的工作环境。不是替代，是层层叠加。

2. 马和缰绳

圈里有个流传很广的等式：Agent = Model + Harness。

模型是马。力量大、跑得快，但没有约束就是一匹在旷野上乱跑的纯种马。你可以让它干任何事，它也确实能干任何事——只是你不知道它这次能不能干对。

Harness 是缰绳和马鞍。它决定 Agent 能访问什么工具、有什么权限、能做到哪一步、什么时候停、出了错怎么回退、结果怎么校验。翻译成工程术语，一套 Harness 覆盖几个模块：系统提示词和执行规则、工具清单和权限边界、沙箱和运行环境、任务编排和状态管理、自动校验和错误恢复。

没有 Harness 的模型，是个博学但没法共事的超级聊天机器人。套上 Harness，它才能变成能交付成果的 AI 工程师。

3. Guides 和 Sensors：两套闭环

一个完整的 Harness 由两套机制构成。

Guides 是事前约束。Agent 动手之前，就已经设好了规则、权限、规范和边界。就像高速公路的护栏——不是等你撞上去再补救，是从源头让你撞不上去。AGENTS.md 里的禁止事项、代码规范里的 ESLint 规则、工具调用的权限白名单，都属于 Guides。

Sensors 是事后校验。Agent 干完活之后，自动检测、测试、审查、纠错。CI/CD 流水线里的自动化测试、pre-commit hook 里的格式检查、Agent 自己生成的日志回放——Agent 每犯一个错，Sensor 就多一条检测规则，下次再犯会自动被拦住。

两套机制合在一起，形成闭环。Agent 每失误一次，Harness 就变强一点。Harness 变强一点，Agent 下次就更少犯错。这是复利式的工程积累。

4. OpenAI 的实战数据

OpenAI 那篇博客里披露的数字很具体。

一个最初三人、后来扩展到七人的团队，从空 Git 仓库起步，完全禁止手写一行代码，所有产品功能全部由 Codex Agent 完成。五项月后，仓库积累近一百万行代码，合并了约 1500 个 PR，人均日处理 3.5 个 PR，整体效率比手写提升约十倍。

靠的不是模型又升级了一个版本，是 Harness 每次出问题就迭代一次。Agent 生成的代码跑不过 CI，就加一条 lint 规则。Agent 总在某个目录下写错文件，就在 AGENTS.md 里加路径约束。Agent 改 API 接口时不更新测试用例，就在 pre-commit hook 里强制检查。

把每次事故变成永久规则。这就是 Harness Engineering 的实操逻辑。

5. 不只是写代码的人的事

Harness Engineering 最容易让人误解的地方，是以为只有写代码的 Agent 才需要。Mitchell Hashimoto 和 OpenAI 的案例确实都在编程场景下，但 Harness 的思路对任何让 Agent 自主干活的场景都适用。

有人在 Claude Desktop 里用 MCP 接上 Slack、Confluence、Google Calendar，让 Agent 自动汇总会议纪要、整理项目进度。每次 Agent 忍不住直接往 Slack 里发消息而不是存草稿，就在规则文件里加一条禁止事项。每次 Agent 做财务判断翻了车，就加一条"涉及金额必须人工确认"的校验规则。

这些修补不需要写一行代码，只需要在 Markdown 文件里沉淀规则。Harness 的载体可以是 AGENTS.md、CLAUDE.md、ESLint 配置、CI 脚本、Git Hook——形式不重要，重要的是"每次都沉到环境里，而不是留在人脑子里"。

Mitchell Hashimoto 的原话值得再读一遍：take the time to engineer a solution such that the agent never makes that mistake again。

大多数工程师遇到 Agent 犯错，习惯手动改掉，祈祷下次不要再来。Harness Engineering 的思维是另一条路：停下来，把这次教训变成环境约束，让它下次在结构上就不可能再犯。Agent 每撞一次墙，你的系统就多一道护栏。

Prompt 解决怎么说，Context 解决看什么，Harness 解决怎么把活干稳。当 Agent 开始接手长链路任务，这三层缺一不可。