深色模式
Harness Engineering
概述
Harness Engineering 是最近在 AI Coding 圈里冒出来的一个词。它讨论的不是“提示词怎么写更花”，而是“怎样把 agent 放进一个能稳定工作的外部环境里”。
截至 2026 年 4 月 3 日，OpenAI、Anthropic 和 Martin Fowler 的相关文章都在强调同一件事：模型能力当然重要，但真正决定产出质量的，往往是模型外面的那套 harness，也就是文档、工具、权限、检查器、执行回路和反馈机制。
它到底在说什么
先把词拆开看。
Harness 原意接近“安全带”“束具”或“控制装置”。放到软件工程语境里，更接近“把某种能力接入真实环境，并且让它可控、可观测、可验证的外围系统”。
所以 Harness Engineering 关注的重点不是模型参数，而是下面这些东西怎么组织：
- agent 能读到哪些项目上下文
- agent 能调用哪些工具
- agent 做事时受哪些规则约束
- agent 产出之后，系统用什么方式检查它
- 失败后，下一轮如何带着反馈继续跑
一句话说，Harness Engineering 就是在给 coding agent 搭工作现场，而不只是给它发一句 prompt。
为什么这个词会出现
这个词出现，不是因为 prompt 没用了，而是因为 prompt 已经不够用了。
在简单问答场景里，一段提示词往往就够。但在真实开发里，agent 需要读仓库、查文档、改文件、跑命令、看报错、再修一次。任务一旦跨过单轮对话，成败就不再主要取决于“第一句怎么问”，而取决于整个执行回路是不是设计得合理。
OpenAI 在 2026 年 2 月 11 日发布的文章里，用 Harness Engineering 来描述这种变化：重点从“让模型回答得更像样”，转向“让模型在一套受约束、可验证、可迭代的系统里持续工作”。Martin Fowler 在 2026 年 4 月 2 日的文章里也沿用了这个说法，并明确把它面向 coding agent 的日常使用场景展开。
这个变化很像开发里从“写一个函数”走到“搭一套可运行系统”。模型只是引擎，harness 才是传动系统。只剩引擎，车通常开不远。
一个 harness 通常包含什么
不同团队实现方式会有差别，但高频组件基本差不多。
项目说明层
这是 agent 的长期背景知识，常见载体包括 AGENTS.md、CLAUDE.md、仓库内 docs/、脚本说明和目录约定。
这一层解决的是“项目是什么、边界在哪、默认应该怎么做”。如果这层缺失，agent 每次都像临时工进场，先靠猜。
工具接入层
只靠文本补全，agent 很难稳定完成真实任务。实际工作里通常还需要：
- Shell 命令
- 搜索与代码浏览
- 浏览器自动化
- 测试、构建、lint
- 设计稿、工单、文档系统
- 通过 MCP 接入的外部工具
这层决定 agent 到底有没有手和眼。没有工具，很多“智能”最后都会退化成一本正经地猜。
约束与权限层
agent 不是能干活就行，还要知道哪些能做、哪些不能碰。
例如：
- 哪些目录禁止修改
- 哪些命令需要审批
- 是否允许联网
- 是否允许删除文件
- 代码风格和提交约束是什么
这一层决定的是风险边界。很多团队对 agent 不放心，问题不在模型笨，而在外部约束太松。
验证与反馈层
这是 Harness Engineering 最容易和普通 prompt 使用拉开差距的地方。
可靠的 harness 往往不会只让 agent “写完就算”，而是会把结果继续送进检查回路，例如：
- 编译是否通过
- 测试是否通过
lint是否通过- 页面截图是否符合预期
- 自定义检查器是否触发规则
OpenAI 在相关文章里专门提到过自定义 linters、浏览器校验和基于真实反馈的迭代。Anthropic 也在长任务 agent 的实践里强调，真正有效的 harness 要能把环境信号重新喂回模型，而不是让 agent 在真空里连续输出。
它和 Prompt Engineering、Context Engineering 的关系
这三个词容易混在一起，但关注点不同。
| 概念 | 关注重点 | 典型问题 |
|---|---|---|
| Prompt Engineering | 单次输入怎么写 | 这句话怎样说更清楚 |
| Context Engineering | 给模型什么上下文 | 该把哪些文件、规则、历史带进去 |
| Harness Engineering | 整个执行系统怎么搭 | agent 怎样在工具、约束、验证回路里稳定工作 |
可以把它们看成递进关系。
Prompt Engineering 解决表达问题，Context Engineering 解决信息问题，Harness Engineering 解决执行问题。
如果任务只是问一个 API 用法，前两者通常够了；如果任务是“改这个模块，编译验证，失败后继续修，再给出变更说明”，第三层就开始变成主角。
在 AI Coding 里怎么落地
把概念落到仓库里，通常会看到下面几类做法。
把长期规则写进仓库
例如在仓库根目录或子目录放 AGENTS.md，明确说明：
- 目录结构怎么理解
- 哪些命令用于验证
- 哪些文件不能改
- 代码风格和提交流程
- 不同目录的局部规则
这样做的价值，不是“让 agent 更听话”，而是把团队经验外置成可复用的执行约束。
给 agent 可重复使用的工具链
高频任务最好不要每次靠自然语言重新描述，而是沉淀成稳定入口，例如：
- 固定的构建命令
- 固定的检查脚本
- 固定的浏览器验证流程
- 固定的 MCP 工具组合
这一步做完之后，agent 才更像在调用工作流，而不是每次现场 improvisation。
让验证尽量自动化
一个简单但很实用的原则是：凡是人类会在提交前手动检查的东西，尽量都想办法变成 harness 的一部分。
比如：
- 改 Go 代码后先编译
- 改前端页面后自动截图
- 改文档站后执行构建
- 改接口后跑一遍 smoke check
能自动回流成信号的检查，比“凭感觉看起来差不多”可靠得多。
给失败设计下一步
好的 harness 不把失败当终点，而把失败当下一轮输入。
编译报错、测试失败、截图不对、接口返回异常，这些都不是额外噪音，而是 agent 下一步最有价值的上下文。Anthropic 的文章里把这类结构称为对长任务 agent 很关键的反馈设计；Martin Fowler 也强调，harness 的价值之一就是把这些外部结果重新组织成可继续推进的工作流。
什么场景最值得投入
并不是所有任务都需要复杂 harness。
下面这些场景更值得认真做：
- 任务会跨多轮执行，不是一问一答就结束
- 需要调用多个工具或外部系统
- 输出结果必须经过客观验证
- 团队多人共用同一套 agent 工作流
- 同类任务会高频重复出现
如果只是临时问个概念，没必要上全套；如果已经开始让 agent 改真实仓库、碰 CI、连浏览器、读工单，那就已经进入 Harness Engineering 的地盘了。
常见误区
只优化提示词，不补环境
不少问题表面看像提示词不够精细，实际是 agent 缺文件、缺工具、缺验证。这个时候继续打磨 prompt，收益通常不大。
只有工具，没有边界
工具接得越多，越需要权限和规则。否则 agent 能力一放大，风险也一起放大。
让 agent 自己判断自己是否成功
这通常不太稳。更可靠的方式是让编译器、测试、浏览器、检查器、日志和返回值来说话。
把 harness 写成一堆散乱说明
如果规则、脚本、命令、验证方式分散在聊天记录和个人记忆里，团队几乎无法复用。真正有价值的 harness，一定要落到仓库文件、脚本和固定流程里。