网硕互联帮助中心2026 年初，AI 工程圈被一个词刷屏了——Harness Engineering。它不是又一个换皮概念，而是一场正在发生的范式革命。本文将结合 OpenAI、Anthropic、HashiCorp 等一线团队的实践，带你一次性搞懂：Harness 工程到底是什么、它和 Prompt/Context 工程是什么关系、以及为什么说"瓶颈不在模型智能，而在基础设施"。
目录
-
- 一个颠覆认知的事实
- 什么是 Harness Engineering？
- AI 工程范式的三次进化
- Agent 常见的四种翻车姿势
- Harness Engineering 的四大支柱
-
- 支柱一：上下文架构（Context Architecture）
- 支柱二：Agent 专业化（Agent Specialization）
- 支柱三：持久化记忆（Persistent Memory）
- 支柱四：结构化执行（Structured Execution）
- 四大护栏：OpenAI 的百万行代码实践
-
- 护栏一：上下文工程——AGENTS.md 活文档
- 护栏二：架构约束——用 Linter 做缰绳
- 护栏三：反馈循环——智能体审智能体
- 护栏四：熵管理——"垃圾回收"
- 工程师角色的转变：从写代码到设计环境
- 六大行业共识
- 还有哪些未解难题？
- 写在最后
一个颠覆认知的事实
先看两组数据：
OpenAI 的百万行代码实验：3 名工程师，5 个月，产出约 100 万行代码，手写代码 0 行，合并 PR 约 1,500 个，人均日提 3.5 个 PR——效率提升约 10 倍。
LangChain 的 Harness 优化实验：底层模型一个参数都没动，仅仅优化了外部驾驭环境（文档结构、验证回路、追踪系统），编码 Agent 在 Terminal Bench 2.0 的得分从 52.8% 飙升至 66.5%，全球排名从第 30 位跃升至第 5 位。
更有说服力的是 Can.ac 的实验：仅改变 Harness 的工具格式（编辑接口），就在 16 个模型上显著提升了编码基准分数。效果最显著的 Grok Code Fast 1 从 6.7% 跃升至 68.3%——没有修改任何模型权重。
五个独立团队得出了同一个结论：真正卡住 AI Agent 的不是写代码的能力，而是围绕它的结构、工具和反馈机制跟不上。瓶颈在基础设施，不在模型智能。
这就是 Harness Engineering 要解决的问题。
什么是 Harness Engineering？
Harness Engineering（驾驭工程） 是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。它的核心哲学可以浓缩为八个字：人类掌舵，智能体执行（Human Steer, Agent Execute）。
“Harness"一词来自马具——缰绳、马鞍、嚼子——这是一套引导强大但不可预测的动物的完整装备。驾驭工程不是去削弱 AI 的能力，而是为它打造一套"黄金缰绳”，让它跑得又快又稳。
这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次明确提出。他在博客中写道：
“Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.”
这句话的潜台词是：Agent 的每一次失败，都是环境设计不完善的信号。 正确的回应不是换一个更强的模型，而是重新设计它运行的环境。
六天后，OpenAI 在百万行代码实验报告中正式采用这一术语。随后 Martin Fowler 撰文深度分析，Ethan Mollick 以此重组了他的 AI 指南框架。一个月内，Harness Engineering 成为开发者社区的高频词。
AI 工程范式的三次进化
要理解 Harness Engineering 为何重要，需要先看清我们是怎么一步步走到这里的。
| 提示词工程 | 怎么把话说清楚 | Prompt 的措辞、格式、示例 | 一问一答 |
| 上下文工程 | 怎么给 AI 喂信息 | 文档、代码片段、历史对话 | 信息注入 → 生成 |
| 驾驭工程 | 怎么让 Agent 可靠工作 | 约束、反馈回路、控制系统 | 人类掌舵，Agent 执行 |
一个好记的类比：
- Prompt Engineering —— 对马喊话的技巧
- Context Engineering —— 给马看的地图
- Harness Engineering —— 给马造一条高速公路，配上护栏、限速牌和加油站
Phil Schmid 的比喻更技术化：模型是 CPU，Harness 是操作系统——CPU 再强，OS 拉胯也白搭。mtrajan 的区分则更直接：Context Engineering 管的是"给 Agent 看什么"，Harness Engineering 管的是"系统怎么防崩、怎么量化、怎么修"。
Harness 不优化模型本身，而是优化模型运行的环境。它不替代 SDK、脚手架或 Agent 框架，而是位于它们之上的驾驭层——解决持久化、确定性重放、成本控制、可观测性、错误恢复这些框架覆盖不到的问题。
Agent 常见的四种翻车姿势
Anthropic 工程师在长时间运行 Agent 的过程中，总结了四种典型的失败模式，正是 Harness Engineering 要解决的核心痛点：
失败模式 1：试图一步到位（One-shotting）
Agent 倾向于在一个会话里把所有功能都做完。结果是上下文窗口耗尽，留下一堆没有文档的半成品代码，下一个会话启动时只能花大量时间猜测之前发生了什么。
失败模式 2：过早宣布胜利
在项目后期，当部分功能已经完成后，Agent 会环顾四周，看到已有进展就直接宣布任务完成——即使还有大量功能未实现。
失败模式 3：过早标记功能完成
在没有明确提示的情况下，Agent 写完代码就标记为"完成"，却没有做端到端测试。单元测试或 curl 命令通过了不代表功能真正可用。
失败模式 4：环境启动困难
每次新会话启动时，Agent 需要花费大量 token 弄清楚如何运行应用、如何启动开发服务器，而不是把时间花在实际开发上。
此外，Agent 还有一个危险特性：它非常擅长模式复制。代码库里有什么模式，它就忠实地复制并放大——包括坏模式和架构漂移。不加约束的 Agent 会以惊人的速度积累技术债务。
Harness Engineering 的四大支柱
综合 OpenAI、Anthropic、Stripe、HashiCorp 等多个团队的实践，Harness Engineering 可以归纳为四个核心支柱。
支柱一：上下文架构（Context Architecture）
核心原则：Agent 应当恰好获得当前任务所需的上下文——不多不少。
每个团队都独立发现，将所有指令塞进一个文件无法扩展。解决方案是分层上下文与渐进式披露。Vasilopoulos 在 2026 年的论文中将上下文形式化为三层：
| Tier 1：会话常驻 | 每次会话自动加载 | AGENTS.md / CLAUDE.md，项目结构 | 最小 |
| Tier 2：按需加载 | 子 Agent 或技能被调用时 | 专业化上下文、领域知识 | 中等 |
| Tier 3：持久化知识库 | Agent 主动查询时 | 研究文档、规格说明、历史会话 | 按需 |
Dex Horthy 有个很实用的经验观察：上下文填得越满，LLM 输出质量越差。以 168K token 的上下文窗口为例，大约用到 40% 就开始走下坡路——超过这个阈值，Agent 会进入"Dumb Zone"，出现幻觉、循环、格式错误的工具调用和低质量代码。
支柱二：Agent 专业化（Agent Specialization）
核心原则：专注于特定领域、拥有受限工具的 Agent 优于拥有全部权限的通用 Agent。
Carlini 在 Anthropic 的 C 编译器项目中，将 Agent 专业化为编译器核心、去重、性能优化和文档四类角色。Vasilopoulos 部署了 19 个领域特定 Agent。专业化不仅是组织性的——它本身就是上下文管理策略。每个专家因为携带更少的无关信息，所以运行在"Smart Zone"内。
典型的角色分工包括：研究 Agent（只读探索）、规划 Agent（分解任务）、执行 Agent（限权实现）、审查 Agent（审计标记）、调试 Agent（修复问题）、清理 Agent（对抗熵增）。
支柱三：持久化记忆（Persistent Memory）
核心原则：进度持久化在文件系统上，而非上下文窗口中。每次新 Agent 会话从零开始，通过文件系统制品重建上下文。
Anthropic 解决这一问题的方案堪称经典：
初始化 Agent：首次会话建立初始环境——init.sh 脚本、claude-progress.txt 进度文件和初始 git 提交。从高级 prompt 生成综合 feature 列表，单个 Web 应用可能超过 200 个独立功能，每个都有明确的测试步骤，全部初始标记为 “failing”。
编码 Agent：后续每次会话的启动流程标准化——运行 pwd 查看目录 → 读取 git log 和进度文件 → 读取 feature list 选择最高优先级任务 → 启动开发服务器运行基础测试 → 确认一切正常后开始新功能开发 → 结束时提交 git 和进度更新。
关键发现：使用 JSON 格式追踪 feature 状态比 Markdown 更有效，因为 Agent 不太可能不恰当地修改或覆盖结构化数据。
支柱四：结构化执行（Structured Execution）
核心原则：将思考与执行分离。所有团队都施加了刻意的执行序列：理解 → 规划 → 执行 → 验证。
Cloudflare 的 Boris Tane 将此原则总结为一句话：
“永远不要让 Agent 在你审查和批准书面计划之前写代码。这种规划与执行的分离是我做的最重要的一件事。”
审查计划远比审查代码快。当规格正确时，实现自然可靠。当规格有误时，可以在 500 行代码生成之前及时纠正。这是驾驭工程中投入产出比最高的实践之一。
四大护栏：OpenAI 的百万行代码实践
OpenAI 三名工程师在 5 个月内用 Codex 构建了约 100 万行代码的产品，提炼出五大 Harness 原则。结合其他团队的实践，可以归纳为四根"护栏"：
护栏一：上下文工程——AGENTS.md 活文档
AGENTS.md 是一个新兴的开放约定——本质上是给 AI Agent 的 README。它不是一次性编写后遗忘的静态文档，而是活的反馈循环：每当 Agent 犯错时就更新。Mitchell Hashimoto 的 Ghostty 项目 AGENTS.md 里，每一行都对应一个历史 Agent 失败案例。
OpenAI 的进阶做法是：不维护一个巨大的指令文件，而是构建一个小型 AGENTS.md，指向更深层的事实源——设计文档、架构图、执行计划、质量评级——全部版本控制并维护在仓库中。甚至有一个专门的 Doc-gardening Agent（文档园丁代理），在后台自动扫描文档与代码之间的不一致，发现过时内容就自动提交 PR 修复——Agent 为 Agent 维护文档。
护栏二：架构约束——用 Linter 做缰绳
OpenAI 团队建立了严格的层级依赖模型：Types → Config → Repo → Service → Runtime → UI，下层不能反向依赖上层。所有架构规则被编码为自定义 Linter 规则，违反即 CI 阻止合并——无论代码是人写的还是 AI 写的。
有个关键细节：Linter 的错误信息本身也是上下文工程。它不只说"你违反了规则 X"，而是解释为什么这个规则存在、正确做法是什么。这样 Agent 读到错误后就能自我理解并修正，不需要人类介入。工具在 Agent 工作时同时"教会"它。
护栏三：反馈循环——智能体审智能体
传统开发中人类工程师负责 Code Review。在驾驭工程中，这个工作变成了智能体对智能体的方式：Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。反馈循环中的钩子可以运行预定义的测试套件，并在失败时带着错误信息循环回到模型，或者提示模型独立评估其代码。
如果 AI 写的测试用例通过了带有 Bug 的代码，Harness 就会判定测试无效，强迫它重新思考测试边界。
护栏四：熵管理——“垃圾回收”
OpenAI 团队最初每周五花 20% 的时间手动清理"AI Slop"（低质量生成物）。后来这被自动化为 Codex 运行的后台任务——清理吞吐量与代码生成吞吐量成正比扩展。定期运行后台任务扫描偏差、更新质量等级、发起针对性重构 PR。
工程师角色的转变：从写代码到设计环境
所有团队的实践都指向同一个结论：工程师的工作正在从"代码的编写者"变成"环境的建筑师"。
Greg Brockman 建议每个团队指定一名"Agent 队长"——负责思考 Agent 如何融入团队工作流。Peter Steinberger（OpenClaw 创作者）在一个月内完成了 6,600+ 次提交，同时运行 5-10 个 Agent。这不是一个人写了 6,600 次代码，而是一个人驾驭了 5-10 个 Agent 产出了 6,600 次提交。
正如 Addy Osmani 所言：“AI 编码的兴起并没有取代软件工程的工艺——它抬高了工艺的门槛。”
软件开发的未来，可能不再是关于我们能写多快多好的代码，而是关于我们能设计多聪明、多鲁棒的系统来驾驭 AI 代理的巨大能量。工程师的价值正在从执行者转变为赋能者和系统思考者——从构建产品转向构建能够构建产品的工厂。
六大行业共识
综合 OpenAI、Anthropic、LangChain、Stripe、HashiCorp、Martin Fowler 等 8 个独立信息源的交叉对比，业界在以下六个方面已形成明确共识：
还有哪些未解难题？
尽管共识已经清晰，但 Harness Engineering 领域仍有三大空白区亟待填补：
棕地项目的 Harness 改造。所有公开的成功案例——OpenAI、Carlini、Anthropic、Stripe、Hashimoto——全部是绿地项目或可控环境。对于十年历史的遗留代码库如何引入 Harness Engineering，目前零成功案例、零方法论。
功能验证的系统化方案。目前大家擅长的是"约束 Agent 不做错事"（架构约束、Linter、类型检查），但"验证 Agent 做对了事"这个问题远未解决。
AI 生成代码的长期可维护性。Greg Brockman 抛出的问题至今无人回答：怎么防止"功能没问题但维护性很差"的代码渗透进代码库？Agent 写的代码和人写的代码，积累技术债的方式不一样。
写在最后
Harness Engineering 标志着 AI 辅助开发从"让模型写代码"到"设计让模型可靠工作的系统"的范式转变。这不是等更强模型出来就能解决的事——模型越强，能给的自主权越大，护栏就得越好。
Birgitta Böckeler 的总结最为精辟：
“为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。”
就像高速公路上的护栏——正是因为有护栏，你才敢踩到 120 码。
如果只记一句话：瓶颈不在智能，而在基础设施。 每一次 Agent 的失败，都不是换更强模型的理由，而是重新设计它运行环境的信号。
评论前必须登录！
注册