写于 2026 年 5 月 | 数据截至 2026 年 4 月
2026 年 2 月，一个新词突然出现在每个 AI 工程师的时间线里：Harness Engineering。
不是新模型，不是新框架，而是一种工程思路的命名。但就是这个命名，让无数工程师感到了某种如释重负——原来他们一直在做的那件事，终于有名字了。
我们为什么需要一个新词
要理解 Harness Engineering 是什么，得先讲清楚它的两个前任是什么，以及它们为什么不够用。
第一代：Prompt Engineering（2022—2024）
ChatGPT 出来之后，所有人的第一反应是：得学会”跟 AI 说话”。Few-shot、Chain-of-Thought、角色扮演、指令分解——一整套修辞学涌现出来。你精心打磨一段 prompt，递给模型，拿回一个答案。
这在单次问答场景里有效。但它有一个根本性的天花板：它是无状态的。
每次对话都是全新开始。模型不记得上次它犯了什么错，也没有任何机制阻止它下次犯同样的错。你每次都在期待一个奇迹，而不是在建一个系统。
第二代：Context Engineering（2025 年中）
Andrej Karpathy 和 Shopify CEO Tobi Lütke 先后提出了这个概念：单条 prompt 不够，你得为模型动态构建整个上下文窗口——相关代码、历史对话、工具定义、RAG 检索结果。模型做每一个决策时，都能看到它需要的信息。
这解决了”模型不知道该看什么”的问题。但随着 Agent 开始跑更长的任务，一个新问题暴露出来：
就算给了模型所有它需要看的信息，它还是会出错——而且是以重复的、可预测的方式出错。
一个被授权修改一个模块的 Agent，会去改整个代码库。一个被要求”修复 CI 失败”的 Agent，会在失败的 lint 检查上无限重试。一个跑了两小时的 Agent，会忘记它最初的目标。
更好的 prompt 解决不了这些问题，更丰富的 context 也解决不了。因为根源不在于模型”不知道”，而在于没有任何东西阻止它犯错，也没有任何机制把错误转化为系统的永久性改进。
命名时刻：2026 年 2 月的两周
Mitchell Hashimoto 的一个习惯
2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform 和 Ghostty 的作者 Mitchell Hashimoto 在博客里描述了一个自己用 AI Agent 时养成的习惯：
“每次 Agent 犯了一个错，我不会期待它下次做得更好。我会把环境改掉，让这个具体的错误在结构上不可能再以同样的方式发生。更新 AGENTS.md，加脚本、linter、检查工具，让 Agent 能验证和修复自己的工作。”
他把这个习惯叫做 “engineering the harness”。
Hashimoto 不是一个喜欢造概念的人。他只是在描述自己的工作方式。但这个词的出现时机恰到好处——整个社区里无数工程师都在做类似的事，却没有一个词来描述它。现在有了。
OpenAI 的百万行代码实验
六天后，2 月 11 日，OpenAI 工程团队发布了《Harness Engineering: Leveraging Codex in an Agent-First World》，彻底引爆了话题。
文章描述了一个内部实验：一个三人团队，从一个空 git 仓库起步，五个月里没有手写一行业务代码。所有代码全部由 Codex 生成。最终结果：100 万行生产代码，1500 个合并的 PR。
但这个实验真正重要的部分，不是”AI 写了一百万行代码”这个标题，而是他们花了大量篇幅描述的：为了让这件事成为可能，他们做了什么样的工程准备。
他们总结了五条规则：
- 仓库是 Agent 唯一的知识来源
- 代码不仅要对人类可读，更要对 Agent 可读
- 架构约束不靠 prompt，靠 linter
- 自主性要一步步给
- 如果一个 PR 需要大改才能合并，问题不在 Agent，在 Harness
团队对自己角色的总结很有意思：“我们现在最大的挑战，在于设计环境、反馈循环和控制系统。不写代码了。写规则。“
数据说话
理论可以争，数据很难争。
研究者 Nate B. Jones 做了一个实验，变量只有一个：模型外面包的那层运行环境。同一个模型，同一个提示词，换 Harness 前后，编程基准的成功率从 42% 跳到了 78%。
Anthropic 工程团队也做了验证，用同一个 prompt、同一个模型，分别跑了两种方式：
| 方式 | 运行时长 | 花费 | 结果 |
|---|---|---|---|
| 无 Harness | 20 分钟 | $9 | 核心功能坏的 |
| 完整 Harness | 6 小时 | $200 | 可玩的完整游戏 |
Harness 贵了 20 倍，但产出不是”更好”，而是”有质的差别”。
这两个数据点之后，“该不该做 Harness”的争论基本结束了。剩下的问题是”怎么做”。
各路实践者在做什么
Stripe：每周 1300 个 PR
Stripe 的内部 Agent 系统叫 Minions，每周合并超过 1300 个 PR，全部由无人值守的 Agent 完成。
他们有几个值得关注的设计：
Blueprint 编排系统：把工作流拆成两种节点——确定性节点（跑 linter、推送代码）按固定路径执行，不调用大模型；Agentic 节点（实现功能、修复 CI）交给模型判断。理性地把 AI 和非 AI 的边界画清楚了。
CI 两轮上限：第一轮失败，Agent 自动修复再跑一次。还失败，直接转交人类。不允许无限重试。这条规则很简单，但它解决了 Agent 的”死磕”问题。
工具精简原则：他们平台挂了约 500 个 MCP 工具，但给每个 Agent 的是精心筛选的子集。他们发现了一个反直觉的规律：更多工具不等于更好的表现。
Stripe 的核心理念：“What’s good for humans is good for agents.” 给人类工程师投资的 Devbox 和工具链，在 Agent 身上也直接产生了回报。
Anthropic：三 Agent 架构与 Context Reset
Anthropic 用三个独立 Agent 分工：规划 Agent、生成 Agent、评估 Agent。
评估 Agent 的存在基于一个清醒的结论：模型无法可靠地评估自己的工作。这让人想到 GAN 的设计哲学——生成器和判别器必须分离。
内存管理上，他们提出了 Context Reset 策略：不压缩上下文，而是在上下文接近饱和时，启动一个全新的”干净”Agent，通过结构化交接文档恢复状态。类似于用重启进程来解决内存泄漏——不优雅，但有效。他们建议上下文利用率控制在 40% 以内，超过之后 Agent 质量明显下降：幻觉增多，开始兜圈子。
Hashimoto：个人规模的极端实践
Hashimoto 自己的路线和 Stripe、OpenAI 完全相反。他明确说”我不打算跑多个 Agent，也不想跑”。坚持一次一个 Agent，保持深度参与，每次失败都亲手修改环境。
这代表了 Harness Engineering 里一个重要的张力：通用化 vs. 特化，单 Agent vs. 多 Agent，有人值守 vs. 无人值守。Hashimoto 的实践证明，即使在个人规模，这套思路也能带来显著的生产力提升——不需要复杂的系统，需要的是清晰的工程素养。
一个结构化视角：ETCLOVG 七层框架
前面的案例都在讲「谁做了什么」，但缺少一个通用框架来回答「Harness 到底包括什么」。
2026 年 5 月，CMU、Yale、JHU、Amazon 等机构联合发表了综述论文《Agent Harness Engineering: A Survey》，梳理了 170+ 个开源 Agent Harness 项目后，提出了一个七层分类框架——ETCLOVG：
| 层 | 职责 | 核心问题 |
|---|---|---|
| Execution | 执行环境 | Agent 在哪里跑？本地、容器、沙箱？边界在哪？ |
| Tooling | 工具接口 | 工具怎么描述、发现、调用？怎么防止误用？ |
| Context | 上下文和记忆 | 短期上下文、会话状态、长期记忆怎么管理？ |
| Lifecycle | 生命周期编排 | 单轮还是多轮？一个 Agent 干到底还是分工协作？ |
| Observability | 可观测性 | 每次调用、重试、token 成本、延迟能不能追踪？ |
| Verification | 验证评估 | 结果对不对？失败是模型的问题还是环境的问题？ |
| Governance | 治理和安全 | Agent 有什么权限？谁能审批？谁来审计？ |
回过头看前面的案例，会发现每个实践者都在解决这七层中的某几层：
- Stripe 的 Blueprint 编排（L）、CI 两轮上限（V）、工具精简（T）
- Anthropic 的三 Agent 分工（L）、Context Reset（C）、评估 Agent（V）
- Hashimoto 的 AGENTS.md（G）、自定义 linter（V）、环境工程（E + T）
大多数团队都是先解决 E/T/C 三层（让 Agent 跑起来），再补 V（验证结果），最后才意识到 O 和 G 不能少。Observability 和 Governance 经常被当作「附属功能」后补，但论文把它们拎出来作为独立层，理由很充分：Agent 不是聊天机器人，它在行动。一旦开始行动，你必须知道它做了什么（O），也必须控制它被允许做什么（G）。
这七层还有一个重要特征：它们不是独立的。 工具描述会占上下文窗口，影响模型行为（T → C）。执行环境会影响评估结果，因为包版本、重置机制、延迟都不一样（E → V）。可观测性 trace 如果没有记录身份和权限状态，就不能成为治理证据（O → G）。这就是 Harness 的耦合问题——改任何一层都不是局部优化，可能改变整个系统行为。
评估也要跟着变
这篇综述还提出了一个值得重视的判断：Agent 评估不能只看最终成功率。
一个 Agent 的最终结果背后混着很多变量：模型、提示词、工具、上下文、沙箱、重试策略、权限、评估器。同样一个成功率，可能代表完全不同的系统质量——可能靠疯狂重试刷过任务，可能走了危险路径但结果对了，可能利用了测试漏洞。
论文主张评估要 trace-native：把完整执行轨迹作为评估对象。记录模型输出、工具调用、环境状态变化、上下文快照、错误、重试、token 使用、延迟和成本。然后判断三件事：结果是否正确，路径是否合理，评估器本身是否可信。
这会把 Agent 评估从「排行榜机制」拉回「质量控制机制」。排行榜回答的是谁分高，质量控制回答的是为什么失败、该改哪一层。
一个重要的概念边界
很多人混淆了 Agent 框架和 Harness，值得讲清楚。
有一个例子说得很好：Cursor 是一个 App，不是一个 Harness。 Cursor 内部用于长时间自主编程会话的 Planner-Worker 机制——加上验证和完成逻辑——才是 Harness。同一个模型，截然不同的结果。
可以这样类比：Agent 框架是给 Agent 提供肌肉（能力），Harness 是给 Agent 提供骨骼和边界（约束与反馈）。 两者不对立，但侧重完全不同。
悬而未决的问题
Harness Engineering 发展极快，但目前还有几个核心分歧没有定论：
Harness 应该多重还是多轻？ 做通用 Agent 产品的追求最小化 Harness 以适应各种场景；做特定产品的可以高度定制。两者并不矛盾，但在通用 Agent 普及的方向下，哪个更对尚无定论。
单 Agent 还是多 Agent？ 有人用 16 个并行 Agent 构建 C 编译器，Hashimoto 明确拒绝多 Agent，Anthropic 自己承认这是 open question。目前的证据倾向于：任务复杂度和代码库规模是决定因素——小项目单 Agent 够，大项目几乎必然需要多 Agent。
Harness 的耦合性怎么管理？ 前面提到的 ETCLOVG 七层不是独立的。改工具描述会占上下文窗口，影响模型行为。改执行环境会影响验证结果。改可观测性会改变治理能力。这意味着 Harness 的迭代不能逐层独立优化——一次改动可能在其他层产生意外后果。目前还没有成熟的解耦方法，更多靠工程经验和大量测试。
好 Harness 不只加控制，还要知道什么时候删控制。 Anthropic 发现了一个有意思的现象：某些 Context Reset 策略对旧模型有用，但对更强的模型已经可以去掉——去掉之后成本下降，质量没有变差。每一个 wrapper、reset、verifier、permission gate 本质上都代表一个假设：「模型自己做不好，所以我在外面加一层控制。」当模型能力变了，这些控制可能不再必要，甚至会拖后腿。所以 Harness Engineering 不是越复杂越好，而是一个需要随模型能力持续评估的动态系统。
可维护性是更大的悬案。 OpenAI 坦承：“AI 代码的长期可维护性”和”棕地项目的改造”是两个”完全空白”的问题。当代码的作者是 Agent 集群，没有人真正理解每一行代码的决策逻辑，维护这些代码的责任怎么落到人身上？这不只是技术问题，也是组织问题。
现在在哪里，会去哪里
2026 年 2 月之前，很多工程师已经在做 Harness Engineering 这件事，只是没有这个名字。从 Hashimoto 的个人博客到 OpenAI、Anthropic、Stripe 的工程博客，再到 Martin Fowler 网站和 arXiv 论文，这个概念只花了不到两个月就完成了扩散。这是一个典型信号：它解决的是一个已经存在但无名的真实痛点。
短期（6—12 个月）：方法论标准化。AGENTS.md 类的配置规范、Harness 设计模式、企业级模板会大量涌现，类似早期 DevOps 时代的”最佳实践”积累阶段。
中期（1—2 年）：工具平台化。LangGraph、CrewAI、Inngest 都在布局 Harness 相关能力，最终可能形成”Harness as a Service”的产品形态——团队从预制模板里选，而不必从头搭建。
长期（2—4 年）：AutoHarness 方向的成熟与否——让系统自动生成能改善 Agent 行为的代码约束——将决定这个领域的人工成本能降多少。
如果你现在想开始
不需要一开始就搭 16 个并行 Agent 的复杂架构。Hashimoto 的案例证明，一个人、一个 Agent、一套清晰的环境规则，就能产生显著的效果。
优先级最高，投入产出比最高：
- 创建
AGENTS.md（或CLAUDE.md）——把项目规则、架构约束、不允许的操作写进去 - 加一条自定义 Linter 规则——把你最常见的 Agent 错误变成结构性约束
- 把关键知识文档化进仓库，而不是留在对话历史里
其次：
- 建立测试和 CI 验证闭环，让 Agent 能自己知道它做对了没有
- 设定明确的人工介入触发条件（比如 Stripe 的”CI 两轮上限”规则）
把所有内容压缩成一句话：
Harness Engineering 是在 Agent 外部构建一套机制——约束、反馈循环、工具链、验证逻辑——让 Agent 能在没有持续人工干预的情况下，稳定地完成跨越多步的自主任务。
它不是模型本身的改进，也不是提示词的技巧，而是环境工程。
马的力量是模型能力，马具（Harness）是让这个力量能稳定拉动车的结构件。没有马具，马很强，但无法稳定工作；马具设计得好，普通的马也能完成精确的任务。
参考来源：OpenAI Engineering Blog (2026.02)、Anthropic Engineering Blog (2026.03—04)、Mitchell Hashimoto Blog (2026.02)、Stripe Engineering (2026)、Martin Fowler / Birgitta Böckeler (2026.03)、arXiv 2603.25723、《Agent Harness Engineering: A Survey》(CMU/Yale/JHU/Amazon, 2026.05)