夜雨聆风01 一个反直觉的核心哲学
Harness Engineering 的概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出。六天后，OpenAI 在百万行代码实验报告中正式采用这一术语。随后 Martin Fowler 撰文深度分析，一个月内成为开发者社区的高频词。
它的核心定义只有一句话：
不优化模型本身，而是优化模型运行的环境。
这句话背后有一个反直觉的哲学——
当 Agent 犯错的时候，大多数人的第一反应是：“换个更强的模型试试。”
但驾驭工程告诉你：Agent 的每一次失败，都是环境设计不完善的信号。 正确的回应不是换模型，而是重新设计它运行的环境。
五个独立团队——OpenAI、Anthropic、LangChain、Stripe、HashiCorp——得出了相同结论：
瓶颈不在模型智能，而在基础设施。
02 AI 工程的三次范式跃迁
要理解驾驭工程为什么重要，需要先看清楚我们是怎么一步步走到这里的。
第一次跃迁：提示词工程（Prompt Engineering）
核心问题是“怎么把话说清楚”。优化的是 Prompt 的措辞、格式、示例，交互模式是一问一答。
打个比方——这就像对马喊话的技巧。你说得越好，马越能听懂。
第二次跃迁：上下文工程（Context Engineering）
核心问题变成了“怎么给 AI 喂信息”。优化的是文档、代码片段、历史对话的组织方式。
这就像给马看一张地图——信息越准确，它越不容易迷路。
第三次跃迁：驾驭工程（Harness Engineering）
核心问题变成了“怎么让 Agent 可靠地工作”。优化的是约束、反馈回路和控制系统。
如果说前两次是喊话和看地图，那驾驭工程就是——给马造一条高速公路，配上护栏、限速牌和加油站。
注意这个演进方向：从“说什么”到“给什么”再到“怎么控”。控制的层次在不断升高。
03 Agent 的四种翻车姿势
在讲解决方案之前，先看看问题长什么样。
Anthropic 的工程师在长时间运行 Agent 的过程中，总结了三种典型的失败模式，加上一个危险特性：
翻车 1：试图一步到位（One-shotting）
Agent 倾向于在一个会话里把所有功能都做完。结果上下文窗口耗尽，留下一堆没有文档的半成品代码。下一个会话启动时，新 Agent 只能花大量时间去猜之前发生了什么。
翻车 2：过早宣布胜利
在项目后期，当部分功能已经完成后，Agent 看到已有进展就直接宣布“任务完成”——即使还有大量功能根本没有实现。
翻车 3：过早标记功能完成
Agent 写完代码就标记为完成，但它根本没做端到端测试。单元测试通过了不代表功能真正可用。
危险特性：模式复制放大
Agent 非常擅长模式复制。代码库里有什么模式，它就忠实地复制并放大——包括坏模式和架构漂移。不加约束的 Agent 会以惊人的速度积累技术债务。
这四种失败模式，正是驾驭工程要解决的核心痛点。
04 四根护栏：驾驭 Agent 的完整系统
综合 OpenAI、Anthropic、LangChain 和 Martin Fowler 的实践，驾驭工程可以归纳为四个核心组件——四根“护栏”。
护栏一：上下文工程——给 Agent 一本“活”的新员工手册
AGENTS.md 是 Agent 进入代码仓库时看到的第一份指南。
但这里有一个关键原则：上下文是稀缺资源。给 Agent 塞 1000 页的说明书，反而会挤掉任务和代码的空间，变成“陈旧规则的坟场”。
更好的做法是：提供一个稳定、小巧的入口点，然后教 Agent 按需检索更多上下文。
Mitchell Hashimoto 的 Ghostty 项目就是一个绝佳案例——他的 AGENTS.md 里每一行都对应一个历史 Agent 失败案例。文档是活的反馈循环，不是静态制品。Agent 犯了一个错，就在文档里加一条规则，下次就不会再犯。
护栏二：架构约束——用 Linter 给 Agent 套上“缰绳”
OpenAI 建立了严格的层级依赖模型：
Types → Config → Repo → Service → Runtime → UI
下层绝对不能反向依赖上层。所有规则被编码为自定义 Linter 规则，违反即 CI 阻止合并——不管代码是人写的还是 AI 写的，一视同仁。
有一个非常聪明的细节：Linter 的错误信息本身也是上下文工程。它不只说“你违反了规则 X”，而是解释“为什么这个规则存在”以及“正确做法是什么”。Agent 读到错误后就能自我修正，不需要人类介入。
| Types | interface User { id: string; name: string } | |
| Config | const API_TIMEOUT = 3000 | |
| Repo | getUserById(id): User | |
| Service | createOrder(userId, items): Order | |
| Runtime | ||
| UI |
护栏三：反馈循环——让 Agent 审查 Agent
传统开发中，代码审查由人类工程师完成。在驾驭工程中，这个工作变成了智能体对智能体。
Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。反馈钩子运行测试套件，失败时带着错误信息循环回到模型。
更厉害的是：如果 AI 写的测试用例通过了带有 Bug 的代码，Harness 会判定这个测试本身无效，强迫 Agent 重新思考测试边界。
护栏四：熵管理——像“垃圾回收”一样持续偿还技术债务
软件系统随时间推移会逐渐混乱，技术债务会积累。OpenAI 把它比作高息贷款——越拖越贵。
他们的策略是持续小额偿还，而非等问题严重了再集中处理，形象地称之为“垃圾回收”。
具体措施包括：
•定期运行后台 Codex 任务扫描偏差、发起重构 PR
•专门的 Doc-gardening Agent（文档园丁代理）自动扫描文档与代码的不一致，发现过时内容就自动提交 PR 修复
是的，Agent 为 Agent 维护文档——非常优雅的设计。
05 数据说话：只改环境，不动模型
说了这么多方法论，有没有硬数据支撑？
LangChain 的案例是最有说服力的实证。
底层模型一个参数都没动，仅仅通过优化外部驾驭环境（文档结构、验证回路、追踪系统），编码 Agent 在 Terminal Bench 2.0 的得分从 52.8% 飙升至 66.5%，全球排名从第 30 位跃升至第 5 位。
还有一个更夸张的数据：仅改变 Harness 工具的格式，就能让模型得分从 6.7% 跳到 68.3%。
模型没变，变的只是环境。
06 六大行业共识
综合 OpenAI、Anthropic、LangChain、Stripe、HashiCorp 等多个独立信息源，业界在以下六个方面已形成明确共识：
① 瓶颈在基础设施，不在模型智能。
五个独立团队得出相同结论。这不是某一家公司的观点，而是行业共识。
② 文档必须是活的反馈循环。
静态文档是坟场，动态更新的文档才有价值。让后台 Agent 定期清理过时文档并提交 PR。
③ 思考与执行分离。
复杂任务不可能在单个上下文窗口内完成，需要 Orchestrator + Worker 分层架构，状态持久化到外部存储。
④ 上下文不是越多越好。
上下文是稀缺资源。巨大的指令文件会挤掉任务空间，应按需检索、动态注入。
⑤ 约束必须自动化。
人工 Review 是瓶颈。护栏要编码为 Linter、CI、类型系统，让机器来执行。
⑥ 工程师角色在转变。
从代码的编写者变成环境的建筑师。最大的工程挑战不再是写代码，而是设计让 Agent 可靠工作的控制系统。
07 一个关于“护栏”的隐喻
最后，分享一段我认为最精辟的总结，来自 Birgitta Böckeler：
为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。
听起来有点反直觉，但仔细想想——
正是因为高速公路上有护栏，你才敢踩到 120 码。
Harness Engineering驾驭工程，不是某一家公司的实验，而是整个行业正在经历的范式转移。作为工程师，我们的价值正在从执行者转变为赋能者和系统思考者——从构建产品，转向构建能够构建产品的工厂。
这可能是 2026 年，每一个工程师都该认真思考的事情。
