基于六篇核心文献的综合分析：OpenAI (Ryan Lopopolo)、Anthropic (Justin Young)、Martin Fowler (Birgitta Böckeler)、LangChain、Latent Space、Cassie Kozyrkov

一、什么是 Harness Engineering？

治理工程（Harness Engineering） 是 2025-2026 年 AI 工程领域最重要的新概念之一。它不是一个工具，不是一个框架，而是一套围绕 AI 智能体（Agent）构建的约束、反馈与控制系统——让智能体（Agent）在人类设定的边界内自主、可靠、可持续地工作。

用一个核心公式表达：

治理工程（Harness Engineering） ≠ 优化模型 → 优化模型运行的“环境”

这个概念的命名可能源自 Mitchell Hashimoto（HashiCorp 创始人）的博客文章。Birgitta Böckeler 在 Martin Fowler 网站上指出：“我喜欢 'harness' 这个词来描述我们用于管控 AI 智能体（Agent）的工具和实践。”

与前两代范式的关系

关键跃迁：提示词工程（Prompt Engineering）和上下文工程（Context Engineering）本质上仍是“人给输入，AI 给输出”的范式。

治理工程（Harness Engineering）的质变在于——人不再直接干预 AI 的每一步操作，而是构建一整套系统来约束、引导和验证 AI 智能体（Agent）的自主行为。

交互模式从“你问我答”变成了“赛道设计”。

二、为什么需要 Harness Engineering？

2.1 智能体（Agent）的“翻车”规律

Anthropic 的 Justin Young 通过长期观察 Claude 的行为，发现了一个核心规律：给智能体（Agent）一个复杂的全栈项目，它的第一反应是试图在一个会话里把所有功能都做完。结果：

  • 做到一半 上下文窗口（context window）耗尽

  • 留下半成品代码——功能写了一半没测试，模块间接口对不上

  • 没有任何记录——下一个智能体（Agent）会话不知道前一次做了什么

  • 更糟糕的情况：智能体（Agent）过早宣布完成，实际上大量功能未经验证

这不是某个模型的个别问题，而是所有智能体（Agent）的结构性缺陷。

2.2 “信任债务”（Trust Debt）概念

Cassie Kozyrkov（前 Google 首席决策科学家，现 Data Scientific CEO）提出了一个极具洞察力的概念——信任债务（Trust Debt）：

AI 就像一个极其听话但缺乏背景知识的实习生。它倾向于填补你指令中的空白，进行“自信的即兴发挥”。如果你不审计它的假设，这些假设就会变成“信任债务”——目前看起来没问题，但在未来某个时刻会爆炸。

信任债务的危险在于：

  1. 不可见性：AI 做了你没要求的决定，但当时看起来合理

  2. 累积性：每一次未审计的决定都在叠加风险

  3. 爆发性：到出问题时，你得逆向工程那些你从未意识到的假设，代价极高

2.3 范式错位

问题的根源在于：

我们已经从“人写代码”进入了“AI 写代码”的时代，但配套的工程体系还停留在“人写代码”的范式里

传统软件工程的所有实践——代码审查（Code Review）、架构规范、文档维护——都假设人类是代码的创作者。当智能体（Agent）一天生成几百个拉取请求（PR）时，这些假设全部崩塌：

  • 人工代码审查（Code Review）变成瓶颈

  • 靠人记住架构规范不现实

  • 文档更新跟不上代码变化速度

治理工程（Harness Engineering）就是为了填补这个空白而生的。

三、OpenAI 百万行代码实验深度分析

3.1 实验设计

Ryan Lopopolo 在 2026 年 2 月 11 日发布的文章披露了一个为期 5 个月的内部实验：

3.2 工程师角色转变

最深刻的发现不是数字，而是工程师角色的根本改变：

工程师不写代码之后，80% 的时间花在了构建治理系统（Harness）上——那套让 AI 能够自主、可靠、可持续工作的基础设施。

Ryan Lopopolo 用八个字概括核心理念：人类掌舵，智能体执行。

当智能体（Agent）遇到困难时，工程师的思考不是“我该怎么帮它写完这段代码”，而是追问：“智能体（Agent）缺乏什么能力？需要什么工具、什么抽象层、什么结构？” 然后由人类补充这些基础设施。

这意味着工程师从 “代码的编写者” 变成了 “环境的建筑师”。

3.3 治理系统（Harness）的三大组件（Böckeler 归纳）

Birgitta Böckeler 在 Martin Fowler 网站上将 OpenAI 团队的治理系统（Harness）归纳为三个类别：

1 上下文工程（Context Engineering）

  • 代码库中持续增强的知识库

  • 智能体（Agent）访问动态上下文的能力（可观测性数据、浏览器导航等）

  • 不是一个巨大的全知文档，而是“地图式”的渐进式信息披露

2 架构约束（Architectural Constraints）

  • 不仅由大语言模型（LLM）智能体（Agent）监控

  • 更由确定性的自定义代码检查工具（linter）和结构化测试强制执行

  • 层级依赖模型：Types → Config → Repo → Service → Runtime → UI

  • 违反层级依赖的代码直接在持续集成（CI）中被拒绝

3 “垃圾回收”（Garbage Collection）

  • 后台定期运行的清理智能体（Agent）

  • 扫描文档与代码之间的不一致

  • 扫描架构约束的违规

  • 对抗熵增（Entropy）和腐烂——这是所有大型代码库的天敌

OpenAI 团队的迭代理念完美体现了治理系统（Harness）的核心思想：

“当智能体（Agent）遇到困难时，我们将其视为一个信号：识别缺少什么——工具、护栏、文档——然后将其反馈到代码仓库中，始终由 Codex 本身来编写修复。”

3.4 Böckeler 的批判性分析

Böckeler 并非全盘接受 OpenAI 的叙事。她指出了一个明显缺失：

“所有描述的措施都聚焦于提高长期内部质量和可维护性。我在文章中缺少的是对功能和行为的验证。”

她还提醒读者注意利益相关性：“OpenAI 在让我们相信 AI 可维护代码方面有既得利益。”

这是一个重要的平衡视角——治理工程（Harness Engineering）听起来很美，但验证功能正确性这个最关键的环节，在 OpenAI 的文章中并不充分。

四、Anthropic 的长跑方案：跨越上下文窗口的断裂

4.1 核心问题

Justin Young 解决的是一个更底层的问题：智能体（Agent）怎么跨越上下文窗口（context window）的限制，实现真正的长期运行？

AI 的上下文窗口（context window）有限，一个复杂项目不可能在单个窗口内完成。每次新开会话，智能体（Agent）就像失忆了——不知道之前做过什么。

4.2 双层智能体（Agent）架构

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

https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

4.3 三个精妙的设计

设计一：全标失败策略

所有功能的初始状态标记为 “失败”。智能体（Agent）只能通过修改状态字段来标完成，不允许删除或编辑测试用例。

这堵死了智能体（Agent）通过“降低标准”来“完成”任务的路。

设计二：每次只做一件事

Anthropic 发现智能体（Agent）有强烈的“贪多嚼不烂”倾向。强制 “做一个功能就停” 看起来效率低，但实际上总体完成率高得多。

这背后的逻辑是：与其让智能体（Agent）试图一次吃完蛋糕但半途而废，不如让它一块一块地吃，每块都吃完。

设计三：进度文件作为跨会话记忆

claude-progress.txt 不只是日志，它是智能体（Agent）的 “外部记忆”：

  • 每个新会话的第一件事：读进度文件 + git log

  • 搞清楚“上一个自己”做了什么

  • 从断点继续，而非从零开始

短期 / 简单任务 → 大模型（Big Model）胜出
  ↓ 复杂度增加
  ↓ 时间跨度增加  
长期 / 复杂项目 → 大治理系统（Big Harness）不可或缺

五、LangChain 的硬核定量验证

5.1 实验结果

LangChain 提供了整个治理工程（Harness Engineering）讨论中最有说服力的定量数据：

这是治理工程（Harness Engineering）最有力的证据：同一个模型，仅改变治理系统（Harness），排名从 30+ 跃升至 Top 5。

5.2 Trace Analyzer Skill：用智能体（Agent）优化智能体（Agent）的治理系统（Harness）

LangChain 最创新的贡献是 Trace Analyzer Skill——一套元（meta）层面的自动化工具：

  1. 从 LangSmith 获取上一轮运行的追踪数据

  2. 并行启动多个错误分析智能体（Agent），各自诊断失败原因

  3. 主智能体（Agent）综合所有发现，提出治理系统（Harness）改进建议

  4. 对治理系统（Harness）做针对性修改，进入下一轮

这个流程类似机器学习中的 提升方法（Boosting）——每一轮聚焦上一轮的错误，迭代改进。

5.3 四个关键改动详解

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

智能体（Agent）最常见的失败模式：写完代码，自己看一遍觉得“看起来没问题”，然后就停了——不跑测试。

LangChain 的解法：PreCompletionChecklistMiddleware。在智能体（Agent）宣告完成之前，强制（mandatory）拦截，强制它跑验证。这类似 Ralph Wiggum Loop，在智能体（Agent）试图退出时用钩子（hook）强制它继续执行验证步骤。

四步工作流：

  1. 规划与探索（Planning & Discovery）：读任务、扫描代码库、建立初始计划

  2. 构建（Build）：实现计划，同时构建测试

  3. 验证（Verify）：运行测试，对照任务规格（不是对照自己的代码） 检查结果

  4. 修复（Fix）：分析错误，回溯原始规格，修复问题

改动二：环境上下文注入

LocalContextMiddleware 在智能体（Agent）启动时就注入：

  • 目录结构

  • 可用工具（如 Python 安装路径）

  • 超时时间

  • 测评标准

LangChain 的定义精辟：“治理系统（Harness）工程师的职责是：准备和投递上下文，使智能体（Agent）能够自主完成工作。”

改动三：死循环检测

LoopDetectionMiddleware 跟踪每个文件的编辑次数。当对同一文件编辑超过 N 次时，注入提示：“考虑重新审视你的方案”。

LangChain 诚实地承认：这是针对当前模型缺陷的设计启发式。随着模型改进，这些护栏可能会变得不必要。但今天，它们帮助智能体（Agent）正确且自主地执行。

改动四：推理三明治策略

不是“推理越多越好”。gpt-5.2-codex 有 4 个推理等级：low、medium、high、xhigh。

https://ghuntley.com/loop/

推理三明治（Reasoning Sandwich）策略：规划阶段用 xhigh（理解问题需要深度推理），执行阶段降档到 high（节省时间），验证阶段再回到 xhigh（抓 bug 需要深度推理）。

这个发现非常实用：推理资源是有限的，在正确的阶段投入正确量级的推理，比全程最高推理效果更好。

六、Cassie Kozyrkov 的管理者视角：12 条治理法则

Cassie Kozyrkov 从管理者和决策科学的角度提出了 12 条治理工程（Harness Engineering）法则，核心思想包括：

核心原则

  1. 人类掌舵，智能体（Agent）执行：工程师的角色是设计环境、明确意图、构建反馈回路

  2. 可读性优先（Legibility）：智能体（Agent）的行为和决策链路必须对人类可追溯

  3. 明确边界：越清晰的规矩 → 越大的智能体（Agent）自主权

  4. 全面文档化：不只是给人看，更是给下一个智能体（Agent）看

  5. 管理吞吐量：智能体（Agent）一天几百个拉取请求（PR）时，必须有自动化审查机制

  6. 持续清理：对抗代码库的熵增（Entropy）

  7. 知道何时升级：哪些决策必须由人类做

信任债务的管理策略

Kozyrkov 强调：即使智能体（Agent）表现优秀，也要像它是“Chris Careless”（最粗心的员工）一样建立安全网。

这不是对 AI 的不信任，而是工程上的审慎：

  • 对最好的情况保持预期

  • 对最差的情况做好防护

  • 永远不要假设 AI 是完美的

七、行业大辩论：大模型（Big Model）对比 大治理系统（Big Harness）

Latent Space 在 2026 年 3 月 5 日发起的文章将行业劈成两个阵营：

我的分析：时间尺度决定答案

这不是非此即彼的问题，而是任务复杂度和持续时间的函数：

https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness

  • 熵增（Entropy）：代码越多，模式越分裂

  • 上下文丢失：跨会话记忆断裂

  • 模式漂移：智能体（Agent）复现已有的坏模式

  • 信任债务：累积到不可逆

让一匹好马跑 100 米，不需要缰绳。让它拉着货物跑 100 公里穿越山路，没有缰绳不行。治理系统（Harness）的价值随着任务的复杂度和持续时间指数增长。

八、五大核心组件深度拆解

综合六篇文献，治理系统（Harness）的核心组件可以归纳为五层：

组件一：结构化知识系统

核心原则：AGENTS.md 当地图，不当百科全书。

关键洞察：

  • 上下文窗口（context window）是稀缺资源——全塞进去反而淹没关键信息

  • 大而全的文档腐烂最快——过时信息比没有信息更危险

  • 需要文档园艺智能体（doc-gardening Agent）做自动文档维护

组件二：机械化架构约束

核心原则：把“品味”编码成机器可执行的检查。

这是最反直觉但最有效的部分。Birgitta Böckeler 精辟总结：

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

具体做法：

  • 层级依赖规则写成 代码检查（Linter）规则，不是写在文档里靠人记

  • 代码检查（Linter）错误信息本身就是教学材料——解释“为什么这个规则存在、正确做法是什么”

  • 智能体（Agent）遇到代码检查（Lint）错误时能自我理解并修正，无需人类介入

组件三：可观测性注入

核心认知转变：观测不再只是给人看的，而是给 AI 看的。

OpenAI 的做法：

  • git worktree 启动独立应用实例

  • 接入 Chrome DevTools Protocol，智能体（Agent）像人一样操作浏览器

  • 用 LogQL/PromQL 查询日志和监控

  • 执行可量化的验证任务：“确保服务在 800ms 内启动”

Anthropic 的做法：

  • 截图验证——用 Puppeteer 操作应用然后截图对比预期

  • “显著提高了性能，使智能体（Agent）能够识别并修复仅从代码中看不出的 Bug”

组件四：自修复闭环

核心问题：智能体（Agent）大量生成代码时，熵增（Entropy）速度放大十倍。

AI 会复现代码库中已有的坏模式——如果某处有烂代码，智能体（Agent）在相邻模块工作时可能模仿这种写法，导致坏模式扩散。

解法：代码库的“垃圾回收机制”

  • 后台定期运行清洁智能体（Agent）

  • 扫描偏离“黄金标准”的代码

  • 自动提交重构拉取请求（PR） → 持续集成（CI）验证 → 自动合并

  • 小额、高频、持续偿还技术债务

组件五：智能体（Agent）互审机制

核心问题：系统一天几百个拉取请求（PR）时，人工代码审查（Code Review）是严重瓶颈。

OpenAI 的 Ralph Wiggum Loop：

  • 智能体（Agent）A 写代码

  • 智能体（Agent）B 审代码

  • 有问题 → 智能体（Agent）A 改完再提交

  • 直到 智能体（Agent）B 通过

人类的角色缩减到只介入架构层面的重大决策。 日常代码风格、逻辑正确性、测试覆盖——全部智能体（Agent）互审。

九、Böckeler 的深层思考：被低估的未来影响

Birgitta Böckeler 在 Martin Fowler 网站上提出了几个被低估但极其重要的问题：

9.1 治理模板（Harness Template） = 未来的服务模板？

大多数组织只有两三种主要技术栈。未来的模板可能不只包含代码脚手架，还包含自定义代码检查工具（Linter）、结构化测试、基础文档、架构约束规则。

技术栈的选择标准会因此改变——过去看社区活跃度、文档质量、开发者体验。以后要加一条：“AI 友好性”——这个技术栈有没有好的治理系统（Harness）支持？

9.2 约束换自主的悖论

“为了可信赖的、AI 生成的大规模可维护代码，必须有所让步。所描述的治理系统（Harness）表明，增加信任和可靠性需要约束解空间：特定的架构模式、强制的边界、标准化的结构。这意味着放弃‘生成任何东西’的灵活性。”

换言之：“LLM 可以生成任何语言、任何模式”的早期炒作是误导性的。 要在规模上获得可靠结果，必须限制智能体（Agent）的行动空间。

9.3 两个世界的分裂

给遗留代码库改造治理系统（Harness），“就像在一个从未运行过静态分析（static analysis）的代码库上突然开启全部规则——你会被警报淹没”。

行业可能分裂为：

  • 新项目世界：从零开始用治理工程（Harness Engineering），高度 AI 自治

  • 旧项目世界：遗留代码库，继续以人工为主

两个世界需要的技能组合截然不同。

9.4 对 OpenAI 叙事的怀疑

Böckeler 保持了健康的批判态度：

  • OpenAI 花了 5 个月 建治理系统（Harness）——这不是一蹴而就的事

  • 文章缺少功能和行为的验证方面的讨论

  • OpenAI 有既得利益让人相信 AI 可维护代码

“令人耳目一新的是听到关于严谨性应去向何处的具体想法和经验，而不是仅仅寄希望于‘更好的模型’会神奇地解决可维护性问题。”

十、治理工程（Harness Engineering）的本质洞察

10.1 核心逻辑：约束换自主

这是整个治理工程（Harness Engineering）最深刻的思想：

规矩越明确 → 智能体（Agent）独立做的事越多；约束越严格 → 信任越高 → 自主权越大

听起来矛盾，但和人类社会的运转逻辑完全一致：

  • 法律越完善的社会，个人自由度越高

  • 高速公路有护栏，你才敢踩到 120 码

  • 手术室无菌规程越严格，手术越安全

10.2 工程师职业的重新定义

治理工程（Harness Engineering）正在重新定义“工程师”这个职业：

传统工程师 治理工程（Harness）时代工程师
价值 = 写代码的速度和质量 价值 = 设计系统的能力
核心技能 = 编码 核心技能 = 约束设计、反馈回路设计、控制系统设计
产出 = 代码 产出 = 智能体（Agent）可靠运行的环境
关注 = 代码本身 关注 = 支撑结构（工具、抽象、反馈回路）

“构建软件仍然需要纪律，但这种纪律更多地体现在支撑结构上——工具、抽象、反馈回路——而不是代码本身。” ——OpenAI

10.3 LangChain 的定义

治理工程（Harness Engineering）是对模型智能的“塑形”——模型的能力参差不齐，治理系统（Harness）的工作就是把这些能力塑造成适合具体任务的形状。

十一、落地指南：从今天开始

今天就能做

  1. 把 AGENTS.md 写成地图：列出项目结构、核心模块、关键约定，指向详细文档位置。智能体（Agent）需要的是“去哪里找信息”，不是“所有信息”。

  2. 把反复出现的审查（Review）意见变成代码检查（Linter）规则：ESLint 自定义规则、提交前钩子（pre-commit hook）、ArchUnit 结构化测试，把人的“品味”编码成机器可执行的检查。

一周内能做

  1. 给 AI 工具加“完成前必须验证”的规则：在系统提示中加一条——标记任务完成之前，必须跑测试、启动应用验证、UI 变更要截图检查。

  2. 建立进度追踪文件：为复杂任务创建智能体（Agent）可读写的进度文件，每个工作单元完成后更新。解决上下文断裂问题。

需要投入时间

  1. 让日志和指标对智能体（Agent）可查：关键日志输出到文件，智能体（Agent）工具列表加“查看最近 N 行日志”的能力。

  2. 定期跑“清洁智能体（Agent）”任务：每周一次，检查文档-代码一致性、架构违规、可抽象的重复模式。

十二、总结：三句话理解 Harness Engineering

  1. 解决的不是“怎么让 AI 更聪明”，而是“怎么让 AI 可控地持续工作”。 聪明是模型公司的事，可控是工程师的事。

  2. 核心逻辑是“用约束换自主”。 给 AI 设的规矩越明确，它能独立做的事就越多。

  3. 正在重新定义“工程师”。 你的价值不再取决于写代码的速度，而取决于你设计约束、反馈回路和控制系统的能力。

AI 已经是千里马。千里马没缰绳，跑得再快也到不了目的地。治理工程（Harness Engineering），就是这个时代最重要的缰绳。

参考文献

  1. Ryan Lopopolo, Harness Engineering: Working with Codex in an Agent-First World, OpenAI, 2026.02.11

  2. Birgitta Böckeler, Harness Engineering, MartinFowler.com, 2026.02.17

  3. LangChain, Improving Deep Agents with Harness Engineering, 2026

  4. Latent Space, Is Harness Engineering Real?, 2026.03.05

  5. Justin Young, Effective Harnesses for Long-Running Agents, Anthropic Engineering, 2025.11.26

  6. Cassie Kozyrkov, Harness Engineering: How to Supervise Code You Can't Read, Decision Intelligence, 2026.03.03