前言

如果你现在还停留在"怎么写一条更好的 Prompt"这个层面去做 Agent，那你可能已经落后了。

2025 年底到 2026 年初，Anthropic、OpenAI、Google DeepMind、Stripe、Vercel 这些公司几乎同时开始公开讲一件事——决定 Agent 能否上线的，不是你给模型喂了什么 Prompt，甚至不是你选了什么模型，而是你给模型搭了一套什么样的运行系统。 这个运行系统，就是他们说的 Harness。

今天我们就把这件事从头到尾拆清楚。

---

一、Harness Engineering 到底是什么？

Harness 这个词的原始含义是马具——缰绳、马鞍、嚼子——一整套控制马匹的装备。这个隐喻是刻意的：

• 马是模型，强大快速，但自己不知道该往哪儿跑；
• 骑手是人类工程师，提供方向；
• 马具就是 Harness，把这匹马的原始能力导向有用的工作。

翻译成技术语言就是一句话：

Harness Engineering 不是在教模型怎么回答，而是在设计模型怎么工作。

它处理的是模型外部那一整层东西：

• 任务怎么拆解？
• 上下文怎么管理？
• 工具怎么编排？
• 权限怎么设定？
• 状态怎么交接？
• 做完了怎么验证？
• 失败了怎么恢复？
• 什么时候该把控制权交回给人类？

这不是一条 Prompt 能搞定的事情，这是一个完整的运行系统设计问题。

概念的结晶时刻

• 2025 年 11 月：Anthropic 发布工程博客《Effective Harnesses for Long Running Agents》，将 Claude Agent SDK 定义为通用型 Agent Harness（实践在先）
• 2026 年 2 月 5 日：HashiCorp 联合创始人 Mitchell Hashimoto 发博客："每当你发现 Agent 犯了一个错误，你就花时间工程化一个解决方案，让它永远不再犯同样的错"（命名）
• 一周后：OpenAI 在官方博客直接发了一篇标题就叫《Harness Engineering》的文章（推广）

所以：Anthropic 是实践在先，Hashimoto 是命名，OpenAI 是推广。

---

二、Prompt → Context → Harness：三层演进

这三个概念形成了一条非常清晰的演进链条：

第一层：Prompt Engineering（2022-2024）

主导范式。关注的是怎么问——措辞、Few-shot 示例、思维链。本质上是单轮的、文本层面的优化。

第二层：Context Engineering（2025）

Karpathy 在 2025 年 6 月公开说"Context Engineering 比 Prompt Engineering 更重要"。Shopify CEO 也表达了类似观点。

Karpathy 有一个精彩的类比：把 LLM 看成 CPU，上下文窗口看成 RAM。Context Engineering 就是操作系统层面管理"工作内存"的技术，涵盖 RAG、记忆注入、工具定义、对话历史管理等动态组装模型输入的所有技术。

核心问题：让模型看到什么？

第三层：Harness Engineering（2026）

不仅管模型看到什么，还管模型能用什么工具、拥有什么权限、怎么保持状态、必须通过什么验证、产生什么日志、失败了怎么重试、什么时候该暂停让人来。

三者的包含关系：Harness ⊃ Context ⊃ Prompt。

用一个比喻来说：
- Prompt 是命令"右转"
- Context 给模型一张地图，让它理解右转是什么意思
- Harness 是整辆车——方向盘、刹车、车道边界、维护计划、警示灯，以及确保车门不会在高速公路上脱落的所有工程设计

Anthropic 在 2026 年 3 月的文章里直接挑明：Prompt Engineering 和 Harness Design 都能显著提升效果，但都会碰到上限。前沿 Agent Coding 的性能关键越来越落在 Harness Design 上。

---

三、为什么偏偏 2025 年底到 2026 年初爆发？

四个原因：

1. 模型能力抬高后，系统设计变成主要差异来源

模型够强了，但光强没用，你得给它一个好的工作环境，它才能把能力发挥出来。

2. 长任务暴露了裸模型的系统性缺陷

即使是 GPT-4.5，在跨多个上下文窗口运行时，如果只给一个高层级指令（比如"构建一个 Claude AI 的克隆"），它依然造不出生产质量的 Web 应用。典型失败模式：

• 试图一口气完成所有事情，导致上下文耗尽
• 下一个 Session 看到一部分进展就提前宣布完成而不验证

这些问题换一个更强的模型不会自动消失，必须靠 Harness 层面的机制来治理。

3. 串联步骤的可靠性数学

假设多步 Agent 流水线中每一步成功率是 95%（听起来很高了），但串联 20 步后端到端的任务完成率：

0.95^20 ≈ 36%

这就是为什么团队报告说"Agent 95% 的时间都在正常工作，但真实任务上仍然有三分之一的失败率"。这个问题不是靠更聪明的模型能解决的，必须靠系统层面的验证。

4. 模型趋于商品化

GPT 系列、Claude 系列、Gemini 系列在核心能力上的差距在缩小。当模型本身不再是差异化因素时，围绕模型的系统设计——也就是 Harness——就成了新的竞争壁垒。

旧护城河是模型质量，新护城河是 Harness 质量。

---

四、头部公司到底怎么做 Harness？

4.1 Anthropic：从双 Agent 到三 Agent 架构

Anthropic 的实践集中体现在两篇工程博客里（2025 年 11 月 & 2026 年 3 月），两篇之间能看到方法论的明显演进。

第一版：双 Agent 架构

• 初始化 Agent：只在第一个 Session 运行，负责建立环境、创建初始化脚本、写入进度日志文件、建立 Git 基线。关键操作——把用户的高层级指令扩展成数百条具体的、可测试的功能需求清单，以 JSON 格式存下来。
• 编码 Agent：在后续 Session 中逐个功能推进，每次启动先读进度文件、审查功能清单、跑已有测试。

核心设计思想：外部制品成为 Agent 记忆——进度文件、Git 历史、结构化需求清单跨 Session 持久化。

技术细节：这两个 Agent 其实共享相同的系统提示、工具集和整体 Harness，唯一区别只是初始用户提示不同。仅通过提示工程就能在单一 Harness 内创造专门化行为。

第二版：三 Agent 架构（2026 年 3 月）

• Planner：负责扩展需求
• Generator：负责实现
• Evaluator：用 Playwright 等工具做交互式验证和打分

最重要的发现——评估器分离：

当你让模型评估自己的工作时，它会倾向于自信地表扬自己的作品，即使在人类看来质量明显平庸。这不是哪个模型的问题，这是自评估的系统性缺陷。

结论：工程化一个独立的严格评估器 Agent，远比教会生成器 Agent 自我批评要容易得多。

另一个关键发现：早期 Harness 用的是 Sonnet 4.5，该模型有"上下文焦虑"倾向（上下文增长时变得不稳定），所以设计了上下文重置机制。但换成 Opus 4.5 后，模型自行消除了这个行为，上下文重置机制变得不再必要。

Harness 不是越复杂越好，它必须跟模型当前的能力边界相匹配。模型强了，有些 Harness 模块反而应该撤掉。

4.2 OpenAI：百万行代码的 Codex 实验

OpenAI 给出了非常具体的数字：

• 2025 年 8 月开始，最初 3 人、后扩展到 7 人的工程团队
• 用 GPT-5 驱动的 Codex Agent，约 5 个月生成约 100 万行代码
• 合并约 1500 个 PR
• 团队人均日吞吐量约 3.5 个 PR，且随团队扩大吞吐量反而上升
• 极端约束：禁止手写代码，所有应用逻辑、测试、CI、文档、可观测性和内部工具全部由 Codex 生成

三大支柱

Martin Fowler 网站上的 Becker 对 OpenAI 的 Harness 做了精炼归纳：

支柱	内容
Context Engineering	持续增强代码库中的知识库 + Agent 对可观测性数据和浏览器的动态访问
架构约束	不靠 Agent 自觉遵守，而是用确定性的自定义 Linter 和结构测试来执行
垃圾回收	定期运行后台 Agent 扫描文档不一致和架构违规，对抗系统的熵增

核心模式

当 Agent 遇到困难时，不要更努力地尝试，而是反问"缺少什么能力"，怎么让这个能力对 Agent 来说既可读又可执行。然后让 Codex 自己编写修复代码——形成 Harness 自我改进的闭环。

诚实度提醒：Becker 明确指出，OpenAI 在呈现这个案例时有既得利益。而且那篇文章标题虽然叫"Harness Engineering"，但正文里 harness 这个词只出现了一次。该学的学，该存疑的也得存疑。

4.3 Google DeepMind：AlphaProof 的 Generator-Verifier-Reviser 循环

2026 年 2 月，DeepMind 发布了 Aletheia，一个面向数学研究的自主 Agent。核心架构是三组件 Harness：

• Generator：提出候选解法和证明策略
• Verifier：用自然语言检查逻辑缺陷和幻觉
• Reviser：修正验证器发现的错误

三个组件循环迭代直到输出通过验证。

Generator → Verifier → Reviser，与 Anthropic 的 Planner → Generator → Evaluator 高度对应。两家公司独立走到了同一个设计模式上，这不是巧合。 这说明"生成-评估分离"正在成为 Agent Harness 设计的行业共识。

成果：在 IMO Proof Bench Advanced 上达到 95.1% 的准确率，自主解决了 IDOL 猜想数据库中 4 个此前未被解决的开放问题。但在更广泛的问题集上错了 68.5%。

Harness 在特定场景下可以非常强大，但泛化能力仍然受限于 Harness 的设计边界。

Google 在工具层面也有动作：Agent Development Kit（ADK）内置了 Evaluation Harness 做场景驱动测试；Gemini 在 2026 年 3 月引入 Salt Signatures 机制——模型在调用工具前生成加密的推理状态表示，传回对话历史后可恢复精确推理链路。这是在模型层面解决跨步骤的状态持续性问题，与 Anthropic 用 Harness 层面的外部制品（进度文件、Git 历史）来保持记忆形成了两条不同的路线。

4.4 Vercel：砍掉 80% 工具反而更好

Vercel 提供了一个完全反直觉的经验：

• 最初给 Agent 配了一个非常全面的工具库（搜索、代码、文件、API 全都有），效果很差——Agent 变得困惑，进行冗余调用，执行不必要的步骤
• 然后他们移除了 80% 的工具，结果反而获得了更好的效果——更少的步骤、更少的 Token 消耗、更快的响应、更高的成功率

约束 Agent 的解决空间，反而能提升它的表现。

Becker 将其提炼到更深层次：

为了获得更多 AI 自主性运行时，环境反而需要更多约束，而非更少护栏。这跟传统软件开发里给工程师更多自由度的理念完全相反。

4.5 Stripe & Devin

Stripe 的 Agent 运行在隔离的、预热好的 DevBox 环境里，跟人类工程师用的开发环境一样，但与生产环境和互联网隔离。Agent 通过 MCP 服务器访问超过 400 个内部工具。核心理念：Agent 需要跟人类工程师一模一样的上下文和工具。

Devin 在达到生产就绪前，经历了 6 个月 5 次完整的架构重写。说明 Harness 的成熟是一个高成本、迭代密集的过程，没有人是一次就做对的。

---

五、成熟 Harness 的六大核心模块

综合以上公司实践，归纳为六大模块：

模块 1：上下文工程与知识管理

• 项目指令文件（如 AGENTS.md、CLAUDE.md）
• 动态上下文注入（从日志、指标、追踪信息中获取实时信息）
• 上下文隔离（用子 Agent 作为上下文防火墙）
• 上下文压缩（自动丢弃或摘要无关信息）

OpenAI 的精辟观察：从 Agent 角度看，它在运行时无法访问的任何东西都等同于不存在。

模块 2：工具编排与权限设计

工具不是越多越好。成熟的 Harness 需要精心策划工具集、移除冗余选项，还包括 MCP 协议集成、文件系统访问管理、沙箱隔离等。

模块 3：验证机制与硬约束

这是 Harness 区别于简单 Scaffold 的核心特征：

• 确定性约束：自定义 Linter、结构测试、Pre-commit Hooks（不依赖 LLM 判断的硬性规则）
• 生成-评估分离：Anthropic 已经证明了为什么这很必要
• 自动审查循环：Codex 在本地审查自己的更改，其他 Agent 审查并回应反馈，循环迭代直到所有审查者都满意

模块 4：状态管理与记忆持续性

LLM 是无状态的，每个新 Session 从零开始，这是长任务场景中最核心的挑战。解决办法：

• 外部化记忆（进度追踪文件、结构化功能清单）
• 增量 Git 提交
• 检查点与恢复机制

模块 5：可观测性与反馈闭环

• 执行追踪、质量分级、异常检测
• 反馈归因：把 Agent 在生产中的失败模式追溯到 Harness 的具体缺陷，驱动持续改进

模块 6：人类接管与生命周期管理

• 在关键决策点暂停（删数据库？扣费？发客户邮件？必须让人类确认）
• 升级路径、失败处理
• 完整的生命周期钩子

---

六、新瓶装旧酒？还是真正的创新？

坦率地说，Harness Engineering 里确实有很大一部分不是新发明：

• Test Harness 在软件工程里已有几十年历史
• CI/CD 管道是成熟的 DevOps 实践
• 任务分解与编排在分布式系统里早被充分研究
• 沙箱隔离是安全工程的基础概念
• 可观测性在 SRE 领域已高度成熟

但它在几个维度上确实产生了新的方法论贡献：

维度	新贡献
约束对象变了	传统约束确定性代码执行，Harness 约束概率性推理系统
约束即提升	约束 Agent 的解决空间反而提升生产力和可靠性（反直觉）
生成-评估分离	虽灵感可追溯到 GAN 架构，但被重新发现并工程化
代码库即 Harness	代码结构、命名约定、模块边界首先服务于 Agent 可推理性

就像 DevOps 重组了开发与运维实践，Harness Engineering 正在重组 Agent 系统的构建与运维实践。

---

七、风险与局限

1. 概念膨胀

当一个术语从 AGENTS.md 文件到完整的生产运维系统都能涵盖时，它的精确性和实用性就会被稀释。

2. 过度工程化

OpenAI 自己都强调 Harness 必须是"可撕裂的"——随着模型变强，之前需要复杂 Harness 补偿的问题可能被模型直接解决。

Harness 不是越复杂越好，过度工程化的 Harness 在模型升级后反而会成为包袱。

3. 证据基础不足

支持 Harness Engineering 价值的大多数证据来自 AI 工具厂商自身（OpenAI、Anthropic、LangChain），存在利益冲突。独立的、定量的、可复现的 Benchmark 验证目前仍然缺乏。

4. 可复现性缺口

OpenAI 的百万行代码案例是在极其特定条件下完成的（从空仓库开始、用自家工具、团队本身是 AI 系统专家），对普通工程团队的可复现性完全没被验证过。

5. 风险放大效应

Anthropic 自己发现：更强的 Harness 也可能放大新的风险。多 Agent 配置下非预期解法的发生率从单 Agent 的 0.24% 上升到 0.87%。

Harness 不只是性能放大器，也可能是风险放大器。

---

八、总结与行动路径

核心结论

层次	解决的问题
Prompt Engineering	怎么说
Context Engineering	给模型看什么
Harness Engineering	让模型在什么运行机制里干活，并确保它真的把活干成

三步走行动路径

立即能做的：
- 在项目根目录创建一个 AGENTS.md
- 每次 Agent 犯重复性错误就加一条规则

中期投入的：
- 构建确定性验证层：Linter、结构测试、Pre-commit Hooks
- 加上基本的可观测性

长期要做的：
- 设计模块化的、可替换的 Harness 架构
- 支持模型升级时平滑迁移

---

"Agent 不难，Harness 才难。" —— OpenAI Codex 团队

---

本文整理自 B 站 UP 主 唐国梁Tommy 的视频《为什么你的Agent总翻车？Harness Engineering全拆解》，原视频 BV1VBX9BrEon。