一文读懂 Harness Engineering 是什么
April 5th, 2026
Harness Engineering 并不是什么新的概念，也不是具体的范式。它从你开始 Vibe coding 的时候，其实你就接触到了。
你在 CLAUDE.md 或 AGENTS.md 里写的项目规范约定、上下文管理、架构约束、记忆管理、自我迭代、循环执行等等，全都是 Harness。它们用来约束引导 AI，让 AI 稳定可靠地工作。
什么是 Harness
Harness 的意思是马具，AI 就是马。没马具的马到处乱跑，套上马具才能被骑、被控制、被带到想去的地方。
一个简单的公式是 Agent = Model + Harness。
说白了，Agent 里除了模型本身，剩下的一切都是 Harness。
Harness 还分不同的层级，如下图：
图中从里到外：
- 最里面是 Model：被约束的核心
- 中间是内层 Harness：coding agent 构建者已经给你做好的那一层
- 最外面是外层 Harness：你针对自己项目搭的那一层
内层 Harness 是 Claude Code、Codex、Cursor 这些工具内置的，你改不了也不用改。它包括 query loop、工具调用的权限系统、上下文压缩、自动恢复机制等等，是工具开发者替你做好的工作。
外层 Harness 是你自己要搭的。CLAUDE.md、AGENTS.md、hooks、skills、项目里的 lint 规则、pre-commit 检查、自定义的 code review agent，都属于这一层。
作为用户，我们处理好项目层级的 Harness，来约束项目的方向；而开发上一层 Coding Agent 的人，是去约束 Agent 的方向。 两者各管一段。
Claude Code 和 Codex 的 harness 实现已经有不少相关文章了，我在文章末尾放了链接，感兴趣可以去参考。下面我们主要聊聊外层项目的 harness 该怎么搭。
项目层级 Harness 的核心机制
项目层级 Harness 由两种东西构成：引导和检查。
引导是在 AI 动手之前给它方向。比如你写的 CLAUDE.md，告诉它这个项目用什么技术栈、有什么约定、禁止用什么 API。
检查是在 AI 动手之后验证它。比如 AI 写完代码后自动跑的 lint、类型检查、单元测试，发现问题反馈回去让 AI 自己修。
这两个东西配合起来就形成了一个自纠偏循环：引导它做对，检查它做错没，错了就让它自己改。大部分时候不需要人介入。
检查又可以分成两种。
一种是确定性检查，比如 lint、类型检查、单元测试、结构测试。这类东西跑得快、结果固定，通常可以挂在 hook 里自动执行，也可以让 AI 调用它们去跑。成本低到可以每次修改都跑一遍。
另一种是需要 Agent 来判断的，比如让另一个 Agent 帮你做 code review、判断"这段代码有没有过度设计"、评估输出质量。慢一点贵一点，但能看懂语义，能给出判断。
这两种要搭配着用，不是二选一。 确定性检查做基础保底，Agent 判断做语义兜底。
项目层级 Harness 的实践
我们来看三个具体的实践。
AGENTS.md / CLAUDE.md 当索引
AGENTS.md / CLAUDE.md 只保留一百行左右，当作目录索引用。真正的文档放在结构化的 docs/ 目录里：
AGENTS.md
CLAUDE.md
docs/
├── design-docs/...
├── exec-plans/...
├── generated/...
├── product-specs/...
├── references/...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
这么做的好处是，避免把一大堆规则一次性塞进去让 AI 全读一遍、白白浪费 token。做成索引之后，Agent 进来先看地图，用到哪块再去读哪块，渐进式披露规则。
PS: 如何你的项目需要 AGENTS.md 和 CLAUDE.md 共存，你可以在 CLAUDE.md 的第一行写 @AGENTS.md，这样 Claude Code 会自动加载 AGENTS.md 的内容。
强化边界约束
给 API、组件、模块等等各种内容，限定一套复杂的规则。
对以前的开发者来说，这些规则执行起来非常繁琐，经常被当成过度设计。但对 Agent 来说恰恰相反，规则越清晰，它发挥的效率越高。
可以大幅减少代码返工的成本，你可以增加把这些规则写成文档让 Agent 来读。
反馈自动化
OpenAI 团队把 Chrome DevTools Protocol 接到 Codex 上，让 Agent 能启动 app、点击 UI、截图、看日志，自己验证自己的修改对不对。每个 Codex 任务跑在独立的 git worktree 里，日志和 metrics 都是临时的，跑完就销毁了。
他们经常看到 Codex 单次运行超过 6 小时（通常是人类睡觉的时候），干净利落。
这个思路你也可以在自己项目里用：
- 写 hooks，在 Agent 改完文件后自动跑 lint + typecheck
- 报错信息写清楚怎么修，让 Agent 能读懂
- 把常用的验证流程打包成 skill，Agent 需要时直接调
早期你可能都是自己手动跑这些步骤：自己开浏览器检查 AI 改的页面、自己运行 code review agent、自己去日志里翻错误。后期需要逐步把这些都自动化，做成工作流。
工程师的角色在变
搭外层 Harness 这件事，本质上就是从写代码转向设计环境。
OpenAI 那个团队只有三个人，五个月合并了 1500 个 PR，人均每天 3.5 个。后来团队扩到七个人，吞吐量不降反升。他们的秘密不是写代码写得快，而是把大量精力投在搭 Harness 上。
人类负责掌舵，Agent 负责执行。
你的工作从"实现这个功能"变成了"设计一个环境，让 Agent 能可靠地实现这个功能"。
早期的瓶颈不在模型能力，而在环境描述不充分。当你觉得 Agent 干得不好的时候，第一反应不该是换个更强的模型，而是问：这个环境里，Agent 缺了什么？
最后
Harness Engineering 不是一次性配置，是一个持续演进的工程实践。
Anthropic 的团队做过一个实验，用 Opus 4.5 搭了一套很复杂的多 Agent harness 来做长时间自主编码。后来 Opus 4.6 出来了，他们把 harness 里的 sprint 拆分机制去掉了，因为新模型已经能原生处理这个问题，不需要额外的脚手架。
Harness 里的每个组件都编码了一个假设：模型在某方面做不好。 模型进步了，这个假设就过时了，对应的组件也就过时了。
但这不意味着 Harness Engineering 会消失。恰恰相反，有价值的 harness 组合空间不会缩小，只会移动。模型能做的事情变多了，你就可以把 harness 往上搭，做更复杂的任务。
每次新模型发布，都值得回头看看你的 harness：哪些已经不再承重，可以拆掉；哪些是新模型才撑得起来的，可以加上。
这就是 Harness Engineering。你可能早就在做了，现在只是给它一个名字而已。
如果你觉得这篇文章对你有帮助，欢迎点赞、分享，你的支持是我持续创作的最大动力！