Harness Engineering：从驾驭百万行AI代码到软件工程的范式革命

引言 — 当AI写出百万行代码，真正的挑战才刚开始

3名工程师，5个月，零行手写代码，约100万行代码产出，开发速度提升10倍。

这不是科幻小说的设定，而是OpenAI团队在2026年初交出的真实成绩单。与此同时，LangChain团队做了一件更有意思的事——他们没有换模型、没有微调、没有改一行模型代码，仅仅通过调整外部的"驾驭系统"（Harness），就让自家编码代理在Terminal Bench 2.0基准测试中从30名开外一路飙升进入前5。

数据很漂亮。但漂亮数据的背后，藏着一个让人不安的问题。

Cassie Kozyrkov曾经打过一个很精准的比方：

"AI就像一个极其听话但缺乏背景知识的实习生，倾向于填补你指令中的空白，进行'自信的即兴发挥'。"

这种"自信的即兴发挥"就是所谓的信任债务——AI在你没有明确要求的地方做了大量决定。这些决定目前看起来没问题，代码能跑，测试能过。但它们就像埋在地基里的裂缝，某一天会以你意想不到的方式爆发。

问题的根源其实很清楚：我们已经进入了"AI写代码"的时代，但配套的工程体系还停留在"人写代码"的范式里。

Harness Engineering就是为填补这个空白而生的。

它不是去训练或微调模型本身，而是为模型构建一个强大的外部驾驭系统——包括约束、反馈与控制机制，让Agent在人类设定的边界内自主、可靠、可持续地工作。

核心哲学八个字：人类掌舵，智能体执行（Human Steer, Agent Execute）。

从Prompt Engineering到Harness Engineering — AI工程的三次范式跃迁

要理解Harness Engineering为什么重要，得先看看我们是怎么一步步走到这里的。

过去三年，AI工程经历了三次清晰的范式跃迁。每一次跃迁，都是因为上一个范式"不够用了"。

Prompt Engineering阶段，大家的核心焦虑是"怎么把话说清楚"。写好一个Prompt，AI就能给出好答案。解决的是单次对话的质量问题。

Context Engineering阶段，人们发现光靠Prompt不够。AI需要看到相关文档、代码片段、历史对话、工具调用结果——Shopify CEO Tobi Lutke在2025年把这个概念推到了风口浪尖。它解决的是信息输入的质量问题，但交互模式本质没变：你给信息，AI生成内容。

Harness Engineering阶段，发生了质的跃迁。我们不再优化"跟AI怎么说话"或"给AI什么信息"，而是构建一整套系统来约束、引导和验证AI Agent的自主行为。交互模式从"人给输入，AI给输出"变成了"人造环境，AI在里面跑"。

有一个比喻把三个阶段串联得很精妙：

• Prompt Engineering像教一匹马"左转""右转"的口令
• Context Engineering像给马一张地图让它自己看路
• Harness Engineering像给马装上缰绳、马鞍和护栏——它可以自己跑，但跑不出你划定的范围

这意味着工程师角色发生了根本性转变。从"逐行编写代码的工匠"变成了"系统设计师"和"环境的建筑师"。主要工作变成了三件事：

1. 设计环境
2. 指定意图
3. 构建反馈循环

代码还是要写的，但写的不再是业务逻辑，而是约束规则、验证流程和反馈机制。

OpenAI百万行代码实验 — Harness系统的五层核心架构拆解

OpenAI那个"3人5个月100万行代码"的实验，之所以能成功，不是因为模型有多强，而是因为他们搭建了一套精密的Harness系统。拆开来看，这套系统有五层。

第一层：结构化知识体系——代码仓库即唯一真理源

先说一个反面教训。

很多团队一开始的做法是写一个巨大的AGENTS.md文件，把所有指导信息塞进去。结果是灾难性的——文件臃肿到挤占上下文空间，内容迅速过时，维护成本极高。

正确做法是渐进式披露。OpenAI团队把AGENTS.md缩减到大约100行，只充当一个"目录"或"地图"，指向docs/目录下的深层文档：

docs/
├── architecture/    # 架构设计文档
├── domains/         # 领域知识文档
├── plans/           # 项目计划
├── specs/           # 技术规格
└── runbooks/        # 操作手册

Agent像新员工一样，从小入口逐步探索，按需深入，不会被信息淹没。

更关键的是，他们建立了一个"doc-gardening Agent"（文档园丁代理）。这个Agent在后台自动扫描文档与代码之间的不一致，发现过时内容就自动提交PR修复。Martin Fowler网站把这种机制称为"垃圾回收Agent"——持续清理知识体系中的"垃圾"。

第二层：强制执行的架构约束与工程品位

这一层的核心理念，Birgitta Böckeler总结得非常到位：

"为了获得更高的AI自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。"

说白了：你越想让AI自由干活，就越要把规矩定死。就像高速公路上的护栏——正是因为有护栏，你才敢踩到120码。

具体怎么做？OpenAI团队建立了严格的层级依赖模型：

Types → Config → Repo → Service → Runtime → UI

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

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

人类的工程品位——日志记录规范、命名约定、代码风格——一旦被编码为规则，就会被持续自动应用到每一行代码中。这种看似"死板的约束"，在AI世界里反而成了速度的倍增器。

第三层：运行时验证与可观测性

OpenAI团队做了一个相当激进的决定：让Codex直接接入应用的运行时环境。

具体来说：

• 通过git worktree为每个Agent启动独立的应用实例
• 接入Chrome DevTools Protocol，让Agent像人一样操作浏览器、查看UI渲染结果
• 用LogQL和PromQL查询日志和监控指标

Anthropic在这方面也有补充实践。他们强调截图验证——要求Agent用Puppeteer像真实用户一样操作应用，然后截图与预期结果对比。Anthropic的报告指出，这种做法"显著提高了性能，使Agent能够识别并修复仅从代码中看不出的Bug"。

这里有一个深刻的认知转变：传统软件工程中，可观测性是给人看的——仪表盘、报警、日志面板。但在Harness Engineering中，观测是给AI看的。日志、指标、UI状态都要设计成"机器可读"的格式。

第四层：自修复闭环与技术债务管理

AI写代码有一个很容易被忽视的问题：它会复现代码库中已有的坏模式。

一个不好的设计模式，人类可能写了3处。AI看到后觉得"这是项目的惯例"，于是在30个地方都用了同样的坏模式。技术债以前所未有的速度累积。

OpenAI的解法是建立自动化的垃圾回收机制：后台定期运行"清洁Agent"，扫描偏离"黄金标准"的代码，自动提交重构PR，CI验证通过后自动合并。

小额、高频、持续偿还技术债。就像持续支付高息贷款的利息，避免债务的灾难性累积。

第五层：AI互审的协作流程

当一天产出几百个PR的时候，传统的人工Code Review就成了严重瓶颈。

解法是引入AI Reviewer：Agent A写代码，Agent B审代码。有问题，Agent A改完再提交，直到Agent B通过。团队内部把这个流程戏称为"Ralph Wiggum循环"。

人类的角色缩减到只介入架构层面的重大决策。日常的代码审查，交给AI自己搞定。

LangChain硬核实验 — 不碰模型，纯靠Harness优化从30名开外进入前5

如果说OpenAI的实验展示了Harness的全貌（从0到1），那LangChain的实验就是最有说服力的定量验证（从1到100）。

核心数据：基于GPT 5.2 Codex的代理，在Terminal Bench 2.0上的得分从52.8%提升到66.5%。模型完全没变，纯靠Harness优化。

改动一：Plan-Build-Verify-Fix强制循环

模型最常见的失败模式是什么？写完一个看似合理的方案就停了，完全不做测试。

LangChain的解法是在系统提示词中强制四步工作流：规划→构建→验证→修复。尤其强调验证环节——要求Agent必须运行测试，并将结果与原始需求对比，而不是与自己的代码对比。

他们还设计了一个关键中间件：PreCompletionChecklistMiddleware。Agent宣告"我完成了"之前，必须先跑验证。不验证？不让退出。这是强制代理进行自我反思和改进的强大机制。

改动二：推理三明治策略（Reasoning Sandwich）

一个反直觉的发现：全程开最高推理模式（xhigh），得分反而只有53.9%。原因是超时了。"推理越多越好"是错的。

最优策略是一个"三明治"结构：

• 规划阶段：最高推理预算，充分理解问题、制定高质量计划
• 代码实现阶段：降档，工作相对直接，不需要那么多"思考"
• 验证和修复阶段：再次拉满，精确发现和修复错误

这个策略在性能和成本之间取得了绝佳平衡，是性能提升的关键因素之一。

改动三：环境上下文注入（LocalContextMiddleware）

Agent最浪费时间的事之一是"搞清楚自己在哪"——当前目录结构是什么样的？有哪些工具可以用？超时时间是多少？

解法很简单：启动时就把这些信息注入进去。省去Agent自己摸索的时间和由此产生的错误。

改动四：死循环检测（LoopDetectionMiddleware）

Agent有一个很典型的毛病：陷入"doom loop"。反复修改同一个文件，每次都觉得"这次应该好了"，但根本问题压根没解决。

LangChain的做法是跟踪编辑次数。对同一文件编辑超过N次时，自动注入一条提示："你是不是该换个思路了？"

简单，但有效。

Meta层面的自动化——Trace Analyzer Skill

LangChain还做了一件更有意思的事：用Agent来优化Agent的Harness。

工作流程类似机器学习中的Boosting：

1. 从LangSmith获取上一轮失败运行的追踪数据
2. 并行启动多个错误分析Agent，各自诊断失败原因
3. 主Agent综合所有发现，提出Harness改进建议
4. 对Harness做针对性修改，进入下一轮

这是meta层面的自动化，使迭代和实验速度大大加快。

LangChain对Harness Engineering给出了一个很精准的定义：

"Harness Engineering是对模型智能的'塑形'——模型的能力参差不齐，Harness的工作就是把这些能力塑造成适合具体任务的形状。"

Anthropic的补充视角 — 长期运行Agent如何跨越上下文窗口限制

OpenAI和LangChain的实验解决了"怎么驾驭Agent"和"驾驭效果有多大"的问题。但还有一个更底层的问题没有触及：AI的上下文窗口是有限的。

复杂项目不可能在单个上下文窗口内完成。每次新开会话，Agent就像失忆了——不知道之前做过什么。

Anthropic工程师Justin Young观察到一个规律：给Claude一个复杂的全栈项目，它的第一反应是试图在一个会话里把所有功能都做完。结果呢？上下文窗口耗尽，留下一堆半成品。

Anthropic的解法是一个双层架构：

• Orchestrator（编排层）：负责任务分解和状态管理
• Worker（执行层）：负责具体任务的执行

状态被持久化到外部存储，Worker完成一个任务后，Orchestrator更新状态，再分配下一个任务。即使中间会话断了，状态也不会丢失。

这里有一个特别精妙的设计——功能列表的"全标失败"策略。

所有功能的初始状态都标记为"失败"。Agent只能通过修改状态字段来标记完成，不允许删除或编辑测试用例。这就堵死了Agent通过"降低标准"来"完成"任务的路——你不能把考试题删了然后说自己考了满分。

另一个关键约束是"每次只做一件事"。针对Agent"贪多嚼不烂"的倾向，强制单任务执行，避免上下文耗尽留下半成品。

三家公司的实践形成了很好的互补：

落地实践 — 在你的项目中应用Harness Engineering的五个核心原则

理论讲完了，怎么落地？以下五个原则可以立即上手。

原则一：做好上下文工程

不要指望Agent能自己搞清楚一切。主动提供清晰的目录结构、可用工具列表、编码最佳实践和问题解决策略。你为它准备得越充分，它犯错的可能性就越小。

对应OpenAI的渐进式披露实践——把AGENTS.md做成地图，而不是百科全书。

原则二：强制自我验证

模型天生自信。它写完代码后的默认行为是"我觉得没问题"，然后就停了。

必须通过提示词和工具强制它进入"构建→验证→修复"的循环。未经测试的代码，在AI时代和人类时代一样不可靠。

原则三：将追踪作为反馈信号

善用LangSmith这样的追踪工具。可见的输入输出是改进系统最宝贵的数据。通过分析追踪记录，你能精确知道Agent在哪个环节、因为什么原因失败，而不是靠猜。

原则四：为当前模型构建护栏

承认当前模型的不完美。它可能陷入死循环，可能过度自信，可能"贪多嚼不烂"。

通过设计简单的中间件——比如循环检测、超时控制、单任务约束——作为护栏，就能显著提升系统的鲁棒性。不需要多复杂，关键是要有。

原则五：为你的模型量身定制Harness

不同模型有不同的"脾气"。Codex、Gemini、Claude，各有各的强项和短板。

虽然很多原则是通用的，但针对你选择的具体模型进行几轮专门的Harness迭代，将能最大化其性能。正如LangChain所说，Harness是对模型智能的"塑形"——你得根据材料的特性来塑造。

结语 — 工程师的价值正在从执行者转变为赋能者

软件开发的未来，可能不再是关于"我们能写多快多好的代码"，而是关于"我们能设计多聪明多鲁棒的系统来驾驭AI代理的巨大能量"。

工程师的价值正在从执行者转变为赋能者和系统思考者。我们正在从"构建产品"转向"构建能够构建产品的工厂"。

看看时间线：

多方独立实践，汇聚成同一个方向。Harness Engineering不是某一家公司的实验，而是整个行业正在经历的范式转移。

回到开头的比喻：

Prompt Engineering教你怎么"跟AI说话"。Context Engineering教你怎么"给AI喂信息"。Harness Engineering教你怎么"给AI造一条高速公路，配上护栏、限速牌和加油站"。

马已经足够快了。现在的问题是——你的缰绳、马鞍和护栏准备好了吗？