2026 年 2 月，OpenAI 披露了一个实验数据：3 名工程师在 5 个月内通过 Codex Agent 生成了 100 万行生产级代码，合并约 1500 个 Pull Request，且没有一行代码是人类手写的。
这个数字本身并不令人震惊——模型的能力在过去两年里进步太快，大家已经对"AI 能写代码"这件事脱敏了。真正引发行业共振的，是 OpenAI 随之提出的一个全新工程范式：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 的百万行代码实验，还有另一个更有说服力的案例：LangChain。
LangChain 团队在 Terminal Bench 2.0 排名中，底层模型一个参数都没动，仅仅通过优化外部驾驭环境——调整文档结构、验证回路、追踪系统——编码 Agent 的得分从 52.8% 飙升至 66.5%，全球排名从第 30 位跃升至第 5 位。
这不是个例。五个独立团队在各自实验中得出了相同的结论：瓶颈不在模型智能，而在基础设施。
另一个关键数据来自 Anthropic 的实测：即使单步任务成功率达到 95%，当 Agent 需要连续执行 20 步时，端到端成功率会急剧衰减到 36%。每一步的微小误差都会累积，最终导致系统性失败。
三、AI 工程范式的三次跃迁
阶段 1：提示词工程（Prompt Engineering）
- 核心问题：怎么跟模型说话？
- 局限：单次交互、无状态、依赖个人经验，更像手艺而非工程
阶段 2：上下文工程（Context Engineering）
- 核心问题：模型应该看到什么？
- 行业共识：2025 年 6 月，Andrej Karpathy 明确表态"上下文工程比提示工程重要得多"
阶段 3：驾驭工程（Harness Engineering）
- 核心问题：整个环境应该如何运作？
- 通过设计完整的运行环境——约束、反馈回路、自动验证、熵管理、生命周期治理——让 AI 在受控边界内自主发挥
一个好记的类比：
- Prompt Engineering —— 对马喊话的技巧
- Context Engineering —— 给马看的地图
- Harness Engineering —— 给马造一条高速公路，配上护栏、限速牌和加油站
四、驾驭工程的四大护栏
护栏一：上下文工程（Context Engineering）——新员工手册
就像给新员工一本详细的工作手册，AGENTS.md 是 AI 智能体进入代码仓库时看到的第一份指南。更好的做法是：提供一个稳定、小巧的入口点，然后教 Agent 根据当前任务按需检索和拉取更多上下文。Mitchell Hashimoto 的 Ghostty 项目里，AGENTS.md 每一行都对应一个历史 Agent 失败案例——文档是活的反馈循环，不是静态制品。
护栏二：架构约束（Architecture Constraints）——缰绳
OpenAI 团队建立了严格的层级依赖模型：Types → Config → Repo → Service → Runtime → UI。
下层不能反向依赖上层。所有架构规则被编码为自定义 Linter 规则，违反即 CI 阻止合并——无论代码是人写的还是 AI 写的。关键细节：Linter 的错误信息本身也是上下文工程。它不只说你违反了规则 X，而是解释为什么这个规则存在、正确做法是什么。
护栏三：反馈循环（Feedback Loop）——智能体审智能体
传统开发中，人类工程师负责代码审查。在驾驭工程中，这个工作变成了Agent-to-Agent Review：Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。如果 AI 写的测试用例通过了带有 Bug 的代码，Harness 就会判定测试无效，强迫它重新思考测试边界。
护栏四：熵管理（Entropy Management）——垃圾回收
OpenAI 采用持续小额偿还的策略——他们把这个方法称为垃圾回收，并认为技术债务就像高息贷款。具体措施包括定期运行后台 Codex 任务扫描偏差、更新质量等级、发起针对性重构 PR。此外还有一个专门的 Doc-gardening Agent（文档园丁代理），在后台自动扫描文档与代码之间的不一致，发现过时就自动提交 PR 修复——Agent 为 Agent 维护文档。
五、Agent 的典型失败模式
失败模式 1：试图一步到位（One-shotting） — Agent 倾向于在一个会话里把所有功能都做完。结果是上下文窗口耗尽，留下一堆没有文档的半成品代码。
失败模式 2：过早宣布胜利 — 在项目后期，当部分功能已经完成后，Agent 会环顾四周，看到已有进展就直接宣布任务完成——即使还有大量功能未实现。
失败模式 3：过早标记功能完成 — 在没有明确提示的情况下，Agent 写完代码就标记为完成，却没有做端到端测试。
此外，智能体还有一个危险特性：它非常擅长模式复制。代码库里有什么模式，它就忠实地复制并放大——包括坏模式和架构漂移。这意味着不加约束的 Agent 会以惊人的速度积累技术债务。
六、六大行业共识
- 瓶颈在基础设施，不在模型智能 —— 五个独立团队得出相同结论
- 文档必须是活的反馈循环 —— 静态文档是坟场，后台 Agent 应定期清理过时文档
- 思考与执行分离 —— 需要 Orchestrator + Worker 分层架构，状态持久化到外部存储
- 上下文不是越多越好 —— 巨大的指令文件会挤掉任务空间，应按需检索、动态注入
- 约束必须自动化 —— 护栏要编码为 Linter、CI、类型系统，让机器来执行
- 工程师角色在转变 —— 从代码的编写者变成环境的建筑师
七、工程师角色的转变
Jeff Dean 在 2026 年初的一次访谈中预言："未来每个工程师可能会各自管理 50 个智能体'实习生'，完成大量并行任务。"
他认为，未来最重要的技能将会是"写清楚需求"，因为智能体的输出质量完全取决于你如何定义问题。工程师的核心价值不再是"怎么实现"，而是"实现什么"——用精确、无歧义的语言，定义清楚系统的目标、边界、约束、异常处理规则，把脑子里的隐性经验转化为智能体可以理解的显性规则。
传统软件团队本就是高度分工的——50 人的团队各自负责不同模块，大量的时间花在需求对齐和跨模块沟通上。未来由 5 名工程师各自管理 50 个智能体的模式，反而可能促使核心工程师之间形成更高效、更深入的协作。
八、总结
Birgitta Böckeler 的总结最为精辟：
为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。
就像高速公路上的护栏——正是因为有护栏，你才敢踩到 120 码。
软件开发的未来，可能不再是关于我们能写多快多好的代码，而是关于我们能设计多聪明、多鲁棒的系统来驾驭 AI 代理的巨大能量。工程师的价值正在从执行者转变为赋能者和系统思考者——从构建产品转向构建能够构建产品的工厂。
| 核心组件 | 解决的问题 | 代表实践 |
|---|---|---|
| 上下文工程 | Agent 不知道该看什么 | AGENTS.md 活文档、按需检索 |
| 架构约束 | Agent 复制并放大坏模式 | 分层依赖、自定义 Linter、CI 强制阻断 |
| 反馈循环 | Agent 不知道自己做错了 | Agent-to-Agent Review、自动测试套件 |
| 熵管理 | 技术债务和文档腐烂 | Doc-gardening Agent、持续垃圾回收 |
