五个月，一百万行代码，三名工程师——没有一行是人工敲出来的。

这是 OpenAI 内部团队在 2026 年初发布的一份工程报告里的数据。他们用 Codex 构建了一个真实上线的内部产品，代码从应用逻辑、测试、CI 配置到文档全部由 AI 生成，人均每天处理 3.5 个 Pull Request。

听起来很爽？但报告的重点不是「AI 好厉害」。

报告的核心结论是：真正的挑战，不是怎么让模型写得更好，而是怎么让它稳定、可靠、不失控地工作。

这套围绕 AI 智能体构建约束、反馈与控制系统的方**，就是正在席卷工程圈的新概念——Harness Engineering（驾驭工程）。

先说说「Harness」这个词

Harness 是马具——缰绳、马鞍、嚼子。

驾驭工程的名字来自这里：不是去削弱马的力气，而是为它配上一整套装备，让它跑得又快又稳。

这个词最早出现在 2026 年 2 月 5 日。HashiCorp 联合创始人、Terraform 的创造者 Mitchell Hashimoto 在博客里写了一句话：

六天后，OpenAI 在百万行代码报告里正式采用了这个术语。随后 Martin Fowler 撰文深度分析。一个月内，它成了开发者社区最高频的词之一。

崛起速度之快，说明它触碰到了真实的痛点。

一组数据，让怀疑者闭嘴

先说说 LangChain 的案例——这个最能说明问题。

他们的编码 Agent 在 Terminal Bench 2.0（一个业界公认的 Agent 能力评测榜）上，得分是 52.8%，排名第 30。

然后工程师做了一件事：什么模型都没换，只改了驾驭层的工具格式、文档结构和验证回路。

结果得分跳到 66.5%，全球排名第 5。

这就是驾驭工程的核心逻辑：瓶颈不在模型，在基础设施。五个独立团队做了类似的实验，结论一模一样。

工程范式已经进化了三次

要理解驾驭工程为什么重要，得先看清楚我们经历了什么。

第一阶段：提示词工程——核心问题是「怎么把话说清楚」，优化对象是 Prompt 的措辞、格式、示例。一问一答，像跟人说话。

第二阶段：上下文工程——核心问题是「怎么给 AI 喂信息」，把文档、代码片段、历史对话塞进去。信息注入然后生成。

第三阶段：驾驭工程——核心问题是「怎么让 Agent 可靠工作」，优化的是约束、反馈回路和控制系统。人类掌舵，Agent 执行。

有个比喻很好记：

· 提示词工程 = 对马喊话的技巧

· 上下文工程 = 给马看的地图

· 驾驭工程 = 给马造一条高速公路，配上护栏、限速牌和加油站

Agent 是怎么翻车的？

Anthropic 工程师在长时间运行 Agent 后，总结了三种典型的「翻车」姿势：

翻车一：试图一步到位。 Agent 倾向于在一个会话里把所有事情都做完。结果是上下文窗口耗尽，留下一堆没文档的半成品代码。下一个会话启动时，它根本不知道之前发生过什么。

翻车二：过早宣布胜利。 当部分功能做完后，Agent 环顾四周，看到已有进展就宣布任务完成——即使还有大量功能没实现。

翻车三：只跑测试不验功能。 写完代码就标记「完成」，但没做端到端测试。单元测试通过了，不代表功能真的可用。

还有一个更隐性的问题：Agent 非常擅长**模式。代码库里有什么，它就忠实地**并放大——包括坏模式和架构漂移。不加约束的 Agent 会以惊人速度积累技术债务。

四根护栏：驾驭工程的核心结构

综合 OpenAI、Anthropic、LangChain 的实践，驾驭工程可以归纳为四个核心组件：

护栏一：上下文工程（新员工手册）

AGENTS.md 是 AI 进入代码库时看到的第一份指南。但有个反直觉的发现：塞得越多，效果越差。

OpenAI 踩过坑——他们试过把所有规则塞进一个超长的 AGENTS.md，结果智能体要么错过关键约束，要么开始针对错误的约束优化。当一切都「重要」时，一切都不重要了。

正确的做法是：AGENTS.md 保持简短（约 100 行），只作为目录，指向其他地方更深层次的真实信息。Agent 按需检索，渐进式获取上下文。Mitchell Hashimoto 的做法更直接：AGENTS.md 里每一行都对应一个历史失败案例。文档是活的反馈循环，不是静态制品。

护栏二：架构约束（缰绳）

OpenAI 团队建立了严格的层级依赖模型：

Types → Config → Repo → Service → Runtime → UI

下层不能反向依赖上层。所有规则被编码为自定义 Linter，违反即 CI 阻断合并——无论是人写的还是 AI 写的。

这里有个细节值得单独说：Linter 的错误信息本身也是上下文工程。它不只说「你违反了规则 X」，而是解释「为什么存在这个规则、正确做法是什么」。这样 Agent 读到报错后能自我修正，不需要人介入。

护栏三：反馈循环（Agent 审 Agent）

传统开发里，代码审查是人做的。驾驭工程里，这变成了「Agent 对 Agent」的方式：Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。

如果 AI 写的测试用例「通过」了带有 Bug 的代码，Harness 会判定测试无效，强迫它重新思考测试边界。验证是闭环的，不依赖人来发现问题。

护栏四：熵管理（垃圾回收）

随着时间推移，软件系统会逐渐混乱，技术债务积累。OpenAI 的策略是「持续小额偿还」，他们把这叫做「垃圾回收」：技术债就像****，每天还一点，比等到临界点再集中处理划算得多。

具体措施是后台定期运行 Codex 任务，扫描代码偏差、发起针对性重构 PR。还有一个「文档园丁 Agent」，自动扫描文档与代码的不一致，发现过时内容就提交 PR 修复。Agent 为 Agent 维护文档。

这和 LangChain、AutoGPT 那些框架有什么区别？

这个问题经常被问到。

简单说：那些框架解决的是「如何构建 AI 智能体」，驾驭层解决的是「智能体如何可靠地运行」——完全不同的问题。

LangChain 工程师 Vivek Trivedy 有句话总结得很干净：「如果你不是模型，你就是 Harness。」

模型正在逐渐吸收框架约 80% 的功能——智能体定义、消息路由、任务生命周期……但剩下的 20%，也就是持久化、确定性重放、成本控制、可观测性、错误恢复，这些框架覆盖不到，正是驾驭层存在的意义。

工程师的角色变了

OpenAI 团队在报告里有一个观察很有意思：随着 AI 代码吞吐量增加，人类工程师的工作重心从「写代码」转向了「设计环境、明确意图、构建反馈回路」。

当 Agent 遇到困难时，正确的反应不再是「换个更聪明的模型」，而是问：「这里缺了什么能力？工具、文档还是约束？」 然后把答案编码进去。

Birgitta Böckeler 有一句话总结得很精辟：

就像高速公路上的护栏——正是因为有护栏，你才敢踩到 120 码。

工程师的价值，正在从「执行者」变成「赋能者和系统思考者」。从「构建产品」转向「构建能够构建产品的工厂」。

Build with HAI｜portal.hai.network，一站接入全球顶尖 AI 模型。