谷歌实践指南：做好这 6 层"驾驭工程"，Agent 才算能上线

• 谷歌这份内部指南，说透了为什么你的 AI Agent 总翻车

• 95% 的团队搞错了：Agent 靠不靠谱，看的是"外挂"不是"大脑"

• 谷歌出品的arness Engineering实践指南，系统了解驾驭工程

当下AI行业正陷入一个核心悖论：大模型能力持续迭代、参数与算力不断升级，但绝大多数企业AI智能体始终停留在演示与试用阶段，难以真正走入生产环境。

Google公开数据印证了这一残酷现状：市面上95%的AI智能体永远无法正式投产，问题并非模型智商不足，而是行业长期只关注模型本身，忽略了智能体运行所需的整套管控、约束、反馈与迭代工程体系。

2026年2月，一系列标志性行业实践集中爆发，彻底扭转了这一认知，正式确立了驾驭工程（Harness Engineering）这一年度核心AI工程范式。

当月初，HashiCorp创始人提出关键工程思想：智能体纠错不应依赖临时提示词修补，而要通过系统化设计，让每一次错误都被机制化根治，实现永不复现。

随后OpenAI公开重磅落地成果：其团队仅用五个月，零手写代码完成百万行规模生产级项目，人类仅负责设计与构建AI运行环境，由智能体自主完成全流程开发。

几乎同期，一项覆盖16款主流大模型的对照实验再次验证：无需升级模型本体，仅优化外部脚手架与运行配套体系，就能普遍大幅提升模型编程实战能力。

一连串实践共同证明：AI智能体的上限，早已不由模型单一决定，而是取决于外围工程体系。由此行业形成全新核心公式：Agent = Model + Harness（智能体 = 模型 + 挽具）。

LangChain与GAIA基准测试数据直观印证了这一点：同一模型在不同挽具体系下，排名实现跨越式跃升，性能分差最高可达43.64分。

所谓驾驭工程，就是一套包含前馈指南、传感反馈、智能体循环、持久化记忆、权限安全管控、全链路可观测的六层底层基建，并依靠棘轮原则持续迭代，将每次故障固化为系统能力，让智能体越用越稳。

这份集合OpenAI、HashiCorp、Martin Fowler、LangChain顶级经验的生产级实践指南，是目前最完整的AI智能体落地手册。王吉伟频道已完成全文翻译，后台回复Harness0919可获取中英文完整版文档。

以下是正文。

Google 2026 年生产级智能体工程实践 驾驭工程

Agent = Model + Harness:
六层生产级实战手册

基于米切尔·哈希莫托的工程方法论、OpenAI 的 Codex 实地报告、马丁·福勒的「指南与传感器」分类框架，以及 Anthropic、LangChain 和 Cursor 的工程资料独立编纂，2026 年 8 月。本手册与 Google、OpenAI、Anthropic 或 HashiCorp 均无关联，亦未获得其认可。

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 
 10 
 
 

 
 11 
 
 

 
 12 
 
 

 
 13 
 
 

 
 14 
 
 

 
 15 
 
 

 

 
 

 
 +------------------+   +------------------+   +------------------+ 
 
 
 |      指南        |   |    智能体循环     |   |     传感器       | 
 
 
 | AGENTS.md        |   |                  |   |    代码检查器     | 
 
 
 | 规则文件      +---->+ 规划 > 执行     +---->+    测试         | 
 
 
 | 约束条件         |   | 验证 > 修复      |   |    验证器        | 
 
 
 | 示例             |   | 重试 / 升级处理  |   |  大模型评判器     | 
 
 
 +--------+---------+   +--------+---------+   +--------+---------+ 
 
 
          |                       |                       | 
 
 
          v                       v                       v 
 
 
 +--------+---------+   +--------+---------+   +--------+---------+ 
 
 
 |      记忆        |   |      权限        |   |     可观测性     | 
 
 
 | 状态文件         |   | 工具预算         |   |    追踪日志       | 
 
 
 | 产出物           |   | 写入限制         |   |    成本追踪       | 
 
 
 | 决策日志         |   | 审批关卡         |   |    熔断警报       | 
 
 
 +------------------+   +------------------+   +------------------+ 
 
 

 

图 1.六层智能体挽具架构。指南与传感器共同构成「驾驭回路」（前馈加反馈）。记忆、权限与可观测性构成运行时基座，智能体循环位于中心，由其余五层共同支撑与约束。

摘要：95% 的企业 AI 智能体最终并未投入实际生产。这些智能体在演示阶段表现优异、通过了预算审批，随后却在预生产阶段悄然被弃用。这一现象有一个专业术语：Harness 工程（驾驭工程）。本文提出了区分「能够上线的智能体」与「被搁置的原型」的完整六层架构。公式是：智能体 = 模型 + 挽具。模型提供推理能力，而挽具提供其他一切：能够防止已知故障的指南、能够捕捉新故障的传感器、带有边界重试机制的智能体循环、持久化记忆、强制执行的权限，以及全面的可观测性。我们汇编了来自五个来源的证据，表明仅靠挽具的改动，其带来的增益就可以超过模型升级本身：同一模型在基准测试上出现 44 分的跳跃、在 Terminal Bench 上零模型改动实现 25 个名次的提升，以及在零人工编写代码的情况下构建出百万行级代码库。

索引词：驾驭工程、智能体挽具、AI 智能体、指南与传感器、智能体循环、AGENTS.md、CLAUDE.md、验证、可观测性、棘轮原则、能力预算。

一、问题所在：永远无法上线的演示 ** THE PROBLEM: DEMOS THAT NEVER SHIP**

聊天机器人产出的是回应。智能体产出的是结果。二者的差异不在模型本身，而在于把一个概率性的语言模型转化为可靠、有边界、可观测系统的基础设施。

如今，每一款 AI 编程工具都能生成代码。但代码更多，并不意味着代码更好。Faros 的研究发现，AI 的采用正带来规模更大、复杂度更高、影响范围更广的变更[8]。而 AI 生成内容那种令人信服的表面质量，恰恰让错误的发现在认知上变得代价高昂。

这些智能体在安全审查中不合格，遗漏可观测性要求，在边缘情形下产生幻觉，缺乏企业所需的治理机制。智能体在演示中能做什么，与它在生产环境中必须做到什么之间的这道鸿沟，已经成为 2026 年最核心的工程难题。

A. 三个时代The Three Eras

行业在 2023 至 2024 年将精力投入到提示词优化：措辞、示例、思维链。2025 年，重心转向上下文系统的设计：RAG、MCP、记忆、检索。

到 2026 年 2 月，从业者们汇聚共识，形成了包容前两者的第三门学科：驾驭工程。

表一：AI 工程的三个时代

时代

关注点

优化对象

局限性

提示工程（2023-24）

单轮对话

措辞、示例

仅限一次交互

上下文工程（2025）

系统上下文

RAG、MCP、记忆

模型能看到什么

驾驭工程（2026）

完整环境

执行、安全

整个运行时

后一个时代对前者实现了向下兼容与范式跃升：挽具不仅涵盖了上下文管道与提示词，还纳入了验证机制、权限控制、可观测性与状态持久化。提示工程塑造模型说什么，上下文工程塑造模型看到什么，而驾驭工程塑造模型能做什么、什么能在失败中存活、什么被允许发生，以及什么构成成功的完成[3]。

B. 这份手册适合谁Who This Playbook Is For

本文写给已经在使用 AI 智能体、并希望它们能够可靠运作而无需持续监督的工程师、运营者、创始人与小团队。你不需要定制的智能体框架。

这套架构适用于编程智能体、研究智能体、运营智能体，以及任何需要 LLM 自主行动的工作流。

二、公式：智能体 = 模型 + 挽具 Agent = Model + Harness

2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform、Vagrant 与 Ghostty 的创造者米切尔·哈希莫托发表了一篇题为《我的 AI 采用之旅》的博客文章[1]。文中，他描述了自己在与 AI 编程智能体协作时形成的一种方法论：

「每当你发现智能体犯了错误，就要花时间设计一个解决方案，使得该智能体永远不再犯同样的错误。」（米切尔·哈希莫托[1]）

几天后，OpenAI 工程师瑞安·洛波波洛发表了一份实地报告[2]。他的团队花了五个月时间构建一个生产级产品，却没有手写一行代码。代码库规模达到百万行，跨越约 1,500 次自动化拉取请求。

人类没有写代码，而是在设计能够让可靠代码生成成为可能的环境。团队的标语是：「人类掌舵，智能体建造。」

这一公式由此定型：智能体 = 模型 + 挽具。马丁·福勒发表了一篇系统性分析[3]，伊森·莫利克则围绕「模型、应用与挽具」重新组织了他的框架[4]，「挽具」一词就此进入 AI 工程的核心词汇。

A. 挽具胜过模型的证据The Evidence That Harness Beats Model

表二：仅靠挽具改动带来的性能增益

模型

基准

改动前

改动后

差值

Masood [6]

Claude Sonnet 4.5

GAIA

30.91%

74.55%

+43.64 分

LangChain [7]

同一模型

Terminal Bench

第 30 名

第 5 名

+25 名

Hashline [9]

16 个大模型

编程基准

基线

有提升

仅靠挽具

OpenAI [2]

Codex 智能体

生产环境

0 行

100 万行

零手写

固定模型不变，只更换挽具。同样的 Claude Sonnet 4.5 在 GAIA 上的得分从 30.91% 跳升至 74.55%，43.64 分的差距完全归因于挽具[6]。这比大多数模型升级所能带来的增益还要大。

B. 内层挽具与外层挽具Inner Harness vs. Outer Harness

前沿 AI 实验室构建的是内层挽具：内置于基础模型中的基础安全层、原生工具调用能力与上下文窗口。而产品团队真正的工程护城河在于外层挽具：由你的团队围绕模型构建的定制化配置、环境路由、测试框架与场景化准则。

本手册聚焦于外层挽具[5]。

三、第一层：指南LAYER 1: GUIDES

指南是智能体在开始工作前阅读的指示。它们属于前馈控制：在执行发生之前塑造行为。

马丁·福勒与比尔吉塔·博克勒提出了「指南与传感器」分类框架，此后已成为描述挽具组件的通用词汇[3]。

A. 指南应包含的内容What Guides Contain

主要的指南文件是 AGENTS.md、CLAUDE.md 和 .cursorrules。每一行都代表一次被转化为永久预防机制的过往故障。

哈希莫托为 Ghostty 编写的 AGENTS.md 文件，是一行行积累起来的，每一行都对应一个具体的智能体错误[1]。

模板 1：最简指南文件Minimum Guide File

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 
 10 
 
 

 
 11 
 
 

 
 12 
 
 

 

 
 

 
 项目：[名称] 
 
 
 语言：[主要语言] 
 
 
 构建：[准确的构建命令] 
 
 
 测试：[准确的测试命令] 
 
 
 检查：[准确的检查命令] 
 
 
 规则： 
 
 
 - 未经询问不得修改 /config 
 
 
 - 每次代码变更后运行测试 
 
 
 - 针对[某种情形]使用[某种模式] 
 
 
 反模式： 
 
 
 - [具体的既往故障，注明日期] 
 
 
 - [其他已观察到的故障模式] 
 
 

 

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 
 10 
 
 

 
 11 
 
 

 
 12 
 
 

 

 
 

 
 PROJECT: [name] 
 
 
 LANGUAGE: [primary language] 
 
 
 BUILD: [exact build command] 
 
 
 TEST: [exact test command] 
 
 
 LINT: [exact lint command] 
 
 
 RULES: 
 
 
 - Never modify /config without asking 
 
 
 - Run tests after every code change 
 
 
 - Use [pattern] for [case] 
 
 
 ANTI-PATTERNS: 
 
 
 - [specific past failure, dated] 
 
 
 - [another observed failure mode] 
 
 

 

指南应包含可执行的动作和可观测的判断标准，而非励志性的语言。将「做充分的研究」替换为具名信息源、停止规则与引文要求。将「写出好代码」替换为具体的检查器命令、测试命令与具体模式。

B. 棘轮原则The Ratchet Principle

哈希莫托的方法论创造了一种棘轮效应：每一次故障都会永久性地改进系统。六步循环如下：

（1）智能体犯错。（2）识别故障类别，而非表面症状。（3）确定最强有力的修复层：指南、传感器、工具或权限。（4）将修复方案编码入系统。（5）验证其能防止复发。（6）监测是否出现回退。

一次提示词补丁只能修复一次对话；一条指南规则能修复未来的每一次运行；一个传感器能自动捕捉整个错误类别；一个环境约束能让该错误在结构上变得不可能发生[1]。

C. 指南卫生Guide Hygiene

指南会不断累积。若无维护，它们会变得相互矛盾、冗余或过时。对指南文件进行版本管理，每月审查一次，移除已由传感器自动执行的规则，按类别分组规则，并为每条条目标注日期，以便追溯何时添加、为何添加。

一份有 200 行未标注日期的指南文件不是挽具，而是技术债务。

指南质量检查问题Guide Quality Questions

• 智能体能否在无需主观判断的情况下验证每条规则？

• 每条规则是否都能追溯到一次已观察到的故障？

• 是否存在相互矛盾的规则？

• 是否有规则可以被替换为检查器或测试（传感器）？

• 每条规则最近一次针对当前行为进行验证是什么时候？

指南文件不仅是为智能体准备的。它是关于你的系统如何运作、过去出现过什么故障、以及什么绝不能再发生的编码化知识。新团队成员阅读 AGENTS.md，便能立即理解各项约束。

当一名工程师离职时，他们的修正意见仍会保留在指南文件中。棘轮机制保存了原本只存在于某个人脑中的机构知识。

OpenAI 的内部实践将指南文件视为记录系统[2]。这份文件不是建议，而是关于智能体在该项目中应如何行事的主要真相来源。当指南与对话内容发生冲突时，指南优先。

这种颠覆，赋予一份文件比一次对话更高的权威，正是挽具持久性的来源。

E. 没有指南的代价The Cost of Not Having Guides

若没有指南文件，每一次新会话都从零开始。智能体必须仅凭代码库本身来推断构建系统、编码模式、被禁止的操作和项目结构。

它会重犯上周才被纠正的错误，会使用上月才被禁止的模式，会修改本应只读的文件。在对话中做出的每一次纠正，都会随着会话结束而消失。而指南文件正是使这些纠正变得永久的关键。

四、第二层：传感器LAYER 2: SENSORS

传感器在执行之后验证输出。它们属于反馈控制：检测指南无法预防的问题。

前馈式指南与反馈式传感器的结合，构成了使持续改进成为可能的「驾驭回路」[3]。

表三：传感器类型与可靠性

类型

示例

速度

成本

确定性

计算型

代码检查器、类型检查器

确定性

计算型

单元测试套件

确定性

计算型

架构验证器

确定性

推理型

大模型评判器

昂贵

非确定性

推理型

AI 代码审查

昂贵

非确定性

计算型传感器在每一次变更时都会运行。推理型传感器增加了语义判断能力，但成本更高，且返回结果具有非确定性。设计原则：优先使用计算型传感器。

只在无法用确定性规则表达的检查项上添加推理型传感器[3]。

A. 自我验证模式Self-Verification Pattern

最强大的挽具模式是让智能体能够访问自身的传感器。每一步之后，智能体运行预定义的测试套件，将失败信息连同错误文本回传至循环中。

这不是模型在评判自己的质量，而是模型执行外部的确定性检查，并根据结果采取行动。

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 

 
 

 
 def 
  verified_step 
 ( 
 agent, task, sensors 
 ): 
 
 
     result = agent.execute(task) 
 
 
     for 
  sensor 
  in 
  sensors: 
 
 
         verdict = sensor.check(result) 
 
 
         if 
  not 
  verdict.passed: 
 
 
             result = agent.fix(result, verdict) 
 
 
             if 
  not 
  sensor.check(result).passed: 
 
 
                 return 
  escalate(task, verdict) 
 
 
     return 
  result 
 
 

 

一条代码检查规则的运行成本几乎为零，却能永久性地防止一整类审查意见。一项验证 API 响应结构的测试只需数毫秒的成本，就能防止集成崩坏。

而一个评估「代码质量」的大模型评判器则要消耗 token，且返回非确定性判定。应优先投资于计算型传感器，它们的复利效应更快，成本更低。

C. 何时添加推理型传感器When to Add an Inferential Sensor

只有当检查需要某种确定性规则无法捕捉的语义理解时，例如客户邮件的语气、法律摘要的准确性、设计决策的质量，才添加大模型评判器。

当你这样做时，应将其视为一种昂贵的咨询性信号，而非一道关卡。记录其判定，衡量其与人工审查的一致性，一旦某种模式清晰到足以编码为规则，就用确定性检查将其取代。

D. 传感器覆盖测试The Sensor Coverage Test

在让任何智能体工作流无人值守运行之前，请核实：智能体能否在无人工检查的情况下检验自身的输出？每个关键输出是否至少有一个计算型传感器？传感器结果是否被记录以供趋势分析？在智能体行为改变的同时，传感器本身是否保持稳定？是否存在某种静默的回归可能绕过所有传感器直达用户？

若任何一个问题的答案为「否」，就应在启用无人值守运行之前补上缺失的传感器。

E. 逐步构建传感器套件Building Sensor Suites Incrementally

从已有的传感器开始：项目现有的测试套件、代码检查器和类型检查器。将它们接入智能体的执行循环中，使智能体在每次变更后都运行它们。

只有当这些计算型传感器已经可靠地捕捉到错误后，才应考虑添加推理型传感器。成本曲线值得重视：一个每次运行费用为 10 美元的大模型评判器，如果每天运行 50 次，那就是每天 500 美元；而能捕捉同类错误的代码检查器是免费的。

五、第三层：智能体循环LAYER 3: THE AGENTIC LOOP

智能体循环是位于挽具中心的执行引擎。它不是单次模型调用，而是一个有边界的循环：规划行动、用工具执行、依据传感器验证结果、修复失败之处，然后决定推进或升级处理。

每一步都是可观测的，每一次重试都被计数。

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 
 10 
 
 

 
 11 
 
 

 
 12 
 
 

 

 
 

 
 def 
  agentic_loop 
 ( 
 task, agent, sensors, budget 
 ): 
 
 
     plan = agent.plan(task) 
 
 
     for 
  step 
  in 
  plan.steps: 
 
 
         for 
  attempt 
  in 
  range 
 (budget.max_retries): 
 
 
             result = agent.execute(step) 
 
 
             verdict = verify(result, sensors) 
 
 
             if 
  verdict.passed: 
  break 
 
 
             if 
  not 
  verdict.retryable: 
 
 
                 return 
  escalate(step, verdict) 
 
 
         else 
 : 
 
 
             return 
  escalate(step, 
  "预算耗尽" 
 ) 
 
 
     return 
  synthesize(plan.results) 
 
 

 

表四：循环的必要边界

边界

目的

默认值

每步最大重试次数

防止无限循环

3 次尝试

最大实际运行时间

防止执行失控

30 分钟

最大 token 预算

控制模型成本

10 万 token

最大财务成本

防止账单意外

每任务 5 美元

最大工具调用次数

防止工具滥用

50 次调用

停止条件

返回最可行的产出物

始终明确定义

当任何预算耗尽时，循环应返回当前最可行的产出物：已完成的工作、未解决的问题，以及停止的原因。它绝不能用一个流畅的最终答案来掩盖部分失败。

A. 升级处理不是失败Escalation Is Not Failure

一个能正确升级处理的智能体，比一个自信给出错误答案的智能体更有价值。升级处理的信息包应包含：需要人类做出的决策、推荐的方案、已经测试过的替代方案、等待所付出的成本，以及若无人响应时最安全的默认行动。

B. 后台智能体原则The Background Agent Rule

哈希莫托说：「我努力让智能体时时都在做点什么。如果我在写代码，我希望有智能体在做规划；如果智能体在写代码，我希望我自己在做审查」[1]。

循环在正常执行期间不应需要人类关注。人类提供意图、审查结果并处理升级事项。二者之间的一切，都是挽具的工作。

六、第四层：记忆与状态LAYER 4: MEMORY AND STATE

每一次模型调用都以空白的上下文窗口开始。挽具负责重建相关的状态。

这就是根本的不对称性：模型没有持久记忆，挽具通过明确的状态管理来提供连续性。

表五：状态持久化层级

层级

持久化内容

能否在何种情况下存活

实现方式

上下文窗口

当前对话轮

对话缓冲区

记事本

当前任务

工具调用

plan.md、todo.md

产出物存储

跨会话

重启

Git、文件系统、S3

决策日志

跨会话

重启

decisions.jsonl

知识图谱

永久

一切

实体关系存储

A. 文件系统即记忆The Filesystem as Memory

最简单的持久化记忆是文件系统。一份 plan.md 文件、一份 decisions.md 日志、一份 progress.json 检查点。智能体在会话开始时读取它们，并在每个有意义的步骤之后更新它们。

对于大多数智能体工作流而言，这比向量数据库更廉价、更简单、更可靠。文件即记忆，产出物即状态。

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 

 
 

 
 def 
  checkpoint 
 ( 
 task, state, artifacts 
 ): 
 
 
     with 
  open 
 ( 
 f"state/{task.id}.json" 
 , 
  "w" 
 ) 
  as 
  f: 
 
 
         json.dump({ 
 
 
             "task_id" 
 : task. 
 id 
 , 
 
 
             "status" 
 : state.status, 
 
 
             "completed_steps" 
 : state.completed, 
 
 
             "artifacts" 
 : [a.path 
  for 
  a 
  in 
  artifacts], 
 
 
             "last_updated" 
 : datetime.now().isoformat() 
 
 
         }, f) 
 
 

 

当一个智能体运行数小时后，上下文窗口就会被填满。OpenAI 的工程指南将服务端压缩合并描述为一种关键的挽具基础机制：概括旧的上下文，保留近期的行动与决策，并将工作集保持在上下文预算之内[2]。

压缩合并本身是一次模型调用，但何时压缩、压缩什么的决策属于挽具，而非智能体本身。在 OpenAI 的 Skill 系统中，通过在压缩后的上下文中加入反例，路由准确率从 73% 提升到了 85%[14]。

C. 记忆与指南的区别Memory vs. Guides

记忆记录发生了什么。指南定义应该发生什么。当某条规则对未来每一次运行都至关重要时，不要指望智能体能记住一次旧对话中的一次纠正。

要将稳定的偏好、政策与流程升格为明确的指南文件条目，而将临时性事实、任务相关的讨论以及探索性推理留在记忆或任务记事本中。

D. 恢复测试The Recovery Test

在一个多步骤任务的中途关闭智能体会话，然后重新打开它。智能体应该读取其检查点，识别最后完成的步骤，并从下一步继续，而无需重复已完成的工作，也无需要求人类重新解释任务。

如果它做不到这一点，说明记忆层不够充分，需要添加检查点文件。

七、第五层：权限与预算LAYER 5: PERMISSIONS AND BUDGETS

模型无法约束自己。它会使用任何它有权访问的工具，写入任何它能够触及的文件，发送任何它能够组织出的消息。

权限不是模型的属性，而是挽具的属性。挽具是主要的安全边界[3]。

模板 2：能力预算Template 2—Capability Budget

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 

 
 

 
 允许读取：src/**, tests/**, docs/** 
 
 
 允许写入：src/**, tests/** 
 
 
 允许执行：npm test, npm run lint 
 
 
 须人工授权：git push, npm publish, deploy 
 
 
 禁止：rm -rf, DROP TABLE, send_email 
 
 
 速率：每任务最多20次写入 
 
 
 成本：每任务最多5美元 
 
 
 超时：每任务30分钟 
 
 

 

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 

 
 

 
 ALLOW read: src/**, tests/**, docs/** 
 
 
 ALLOW write: src/**, tests/** 
 
 
 ALLOW execute: npm test, npm run lint 
 
 
 ASK before: git push, npm publish, deploy 
 
 
 DENY: rm -rf, DROP TABLE, send_email 
 
 
 RATE: max 20 writes per task 
 
 
 COST: max $5 per task 
 
 
 TIMEOUT: 30 minutes per task 
 
 

 

表六：默认行动策略

行动

默认

原因

读取源文件

允许

可逆的观察行为

写入项目文件

允许并记录

可借助 git 恢复

运行测试/检查器

允许

无副作用

推送到远程仓库

须人工授权

外部可见性

部署到生产环境

仅限人工接管

难以逆转

发送外部消息

须人工授权

影响声誉

删除数据或文件

仅限人工接管

可能不可逆

A. 提示注入改变了风险模型Prompt Injection Changes the Risk Model

一个自主运行的智能体会阅读不受信任的内容：邮件、网页、文档、代码仓库中的问题条目、用户提交的文本。嵌入在内容中的恶意指令绝不能扩展智能体的权限、改变其系统策略、重定向机密信息，或触发外部行动。

挽具必须在每一个任务中，将可信的指令（指南文件、系统提示）与不可信的数据（用户输入、检索到的文档）区分开来[2][6]。

B. 四个预算维度Four Budget Dimensions

四个维度支配着每一个智能体的行动。范围：哪些账户、工具、文件与操作是可用的。速率：每个时间间隔内允许的最大写入、提交或外部调用次数。可逆性：该行动能否被安全回滚，不可逆的行动需要人类批准。可见性：谁会被通知，以及为审计而保留哪些证据。

在第一次无人值守运行之前，就要将这四者全部编码进系统。

 
 

 
 

 
 1 
 
 

 
 2 
 
 

 
 3 
 
 

 
 4 
 
 

 
 5 
 
 

 
 6 
 
 

 
 7 
 
 

 
 8 
 
 

 
 9 
 
 

 
 10 
 
 

 
 11 
 
 

 
 12 
 
 

 

 
 

 
 def 
  policy_gate 
 ( 
 action, target, task 
 ): 
 
 
     decision = policy.evaluate(action, target) 
 
 
     if 
  decision == DENY: 
 
 
         log_denial(action, target, task) 
 
 
         return 
  BLOCKED 
 
 
     if 
  decision == ASK: 
 
 
         return 
  request_human_approval(action, target) 
 
 
     if 
  rate_limit.exceeded(action): 
 
 
         return 
  trip_wire(action, task) 
 
 
     execute(action, target) 
 
 
     append_audit_record(action, target, result) 
 
 
     return 
  COMPLETED 
 
 

 

只给智能体完成任务所需的最小环境。如果智能体只需要读取源文件并运行测试，那就只授予恰好这些权限。

除非任务明确要求，否则不要授予对配置文件的写入权限、对外部服务的网络访问权限，或安装软件包的权限。每一项不必要的权限，都是提示注入的攻击面，也是智能体错误的爆炸半径。

八、第六层：可观测性LAYER 6: OBSERVABILITY

生产级挽具需要遥测数据。没有它，一个「更快」的智能体可能表面上看起来成功，实际却悄然遗漏了重要的工作。

必需的遥测数据包括：开始/结束时间戳、工具动作与结果、所用的指南版本与传感器、尝试次数与成本、产出的产出物，以及审批与升级处理记录。

表七：熔断警报的触发条件

熔断警报

触发条件

意味着

应对方式

外部写入激增

权限漂移

冻结写入

冻结写入

同一错误重复 3 次

指南或传感器存在缺口

升级处理

升级处理

成本超过平均值 2 倍

循环失控

暂停并检查

暂停并检查

传感器通过率下降

质量回退

回滚

回滚

联系了新的域名

范围蔓延

阻断并告警

阻断并告警

耗时超过 3 倍

智能体卡死

超时

超时

表八：挽具健康评分卡

指标

定义

方向

完成率

已验证运行数 / 已启动运行数

上升

返工率

需人工修正的运行数

下降

升级率

每任务人工提醒次数

下降

恢复时间

从故障到安全状态所需分钟数

下降

单任务成本

每个已验证结果所需的 token+工具成本

下降

指南增长量

每周新增规则数

递减

A. 真正重要的指标The Real Metric

不要计算模型调用次数、token 数或消息数。要计算那些未经人工干预且仍产出可接受证据的已完成任务数。

当完成率上升，而返工率、不必要的审批、单个已完成任务的成本以及恢复时间均下降时，说明系统在改善。这一指标能防止一个视觉上令人惊艳的智能体掩盖巨大的人力协调成本。

B. 可观测性作为调试基础设施Observability as Debugging Infrastructure

当智能体产出错误结果时，第一个问题是：错在哪里？没有结构化日志，答案就需要重放整个对话。

有了可观测性，你就能追溯到那个返回了异常数据的具体工具调用、那个本该失败却通过了的具体传感器，或那个智能体忽略了某条指南规则的具体步骤。可观测性不是负担，它是调试基础设施。

C. 成本归因Cost Attribution

按每任务而非每日统计成本。每日花费 50 美元这个数字，若不知道究竟完成了 100 个任务还是 2 个任务，就毫无意义。每个已验证结果的成本才是揭示挽具是否在改善的指标。

当一条新的指南规则将重试次数从 3 次减少到 1 次时，单任务成本就下降了 60%。当一个新的传感器捕捉到了以前需要人工审查的错误时，每个已验证结果的成本会进一步下降。当成本削减超过维护挽具的成本时，挽具就实现了自我偿还。

运营复盘问题

• 你能识别出本周成本最高的任务类型吗？

• 你能识别出哪个传感器捕捉到的错误最多吗？

• 你能识别出哪条指南规则被违反的次数最多吗？

• 你能从头到尾追溯任何一个已完成的任务吗？

• 如果智能体开始出错，你能在一小时内知道吗？

每一个在强层级上被修复的故障，都会减少后续运行中的故障总数。这就是棘轮机制创造的良性循环。

表九：故障分类

故障类别

弱修复方式（应避免）

强修复方式（应优先）

已知的坏模式

提示词提醒

代码检查规则（传感器）

缺失上下文

延长对话

指南文件条目

错误的工具使用

对话中纠正

权限边界

质量漂移

每次运行人工审查

自动化测试套件

状态丢失

重新解释一切

基于文件的检查点

不安全的行动

期望不再发生

能力预算+拒绝规则

成本超支

人工监控

Token 预算+熔断警报

「提示词引导行为。环境预防的是整整一类故障。」（劳伦·陈，Cursor[10]）

在挽具生命周期的早期，由于大量常见错误正在被发现，指南增长速度很快。随着最频繁出现的故障类别被覆盖，增长速度会下降。一个成熟的挽具，每周或许只增加一条新规则，而不是每天增加五条。这种增长率的下降，正是挽具正在发挥作用的最清晰信号。

A. 六步工程循环The Six-Step Engineering Loop

当智能体出错时，遵循以下循环：（1）用完全相同的输入重现故障。（2）对根本原因进行分类：缺失的指南、缺失的传感器、权限缺口、状态丢失，还是可观测性盲点。（3）确定修复该问题应归属的最强层级。（4）在该层级实施修复。（5）针对最初的失败案例验证修复效果。（6）运行回归测试套件，确保没有破坏任何既有能力。

不要跳过任何一步。跳过第 1 步意味着你可能修复的是一个幻影问题；跳过第 6 步意味着你可能在修复一个问题的同时破坏了另外三个。

B. 将审查意见转化为约束Converting Review Comments into Constraints

Cursor 的劳伦·陈描述了一种强大的模式：当人工审查员对同一件事写下超过三次相同的审查意见时，该意见就应该转化为一种结构性约束[10]。演进路径是：第一次出现，添加一条指南规则；第二次出现，验证该指南规则是否确实被读取；第三次出现，将其转化为一个能阻止智能体产出违规输出的传感器。第四次出现的情况，永远都不应该发生。

表十：控制可靠性阶梯

层级

示例

可靠性

添加成本

记忆

对话中的既往纠正

零

提示词

任务指令

低-中

数分钟

指南

AGENTS.md 规则

数分钟

传感器

自动化测试

数小时

环境

权限、架构、CI

最高

数小时至数天

十、构建路径：七天上线生产BUILD PATH: SEVEN DAYS TO PRODUCTION

只有在每一层证明可靠之后，才增加下一层。这是构建挽具的基本节奏。

表十一：七日构建路径

构建内容

通过测试

1

编写含构建/测试/检查命令的 AGENTS.md

智能体能正确运行三者

2

从故障中添加 3 条指南规则

智能体避免全部 3 种反模式

3

添加首个计算型传感器

智能体在每次变更后运行测试

4

接入智能体循环+重试预算

智能体先重试，再升级处理

5

添加基于文件的状态检查点

智能体在重启后能恢复

6

设置权限+成本预算

智能体无法超出范围

7

结构化日志+熔断警报

在模拟激增时触发熔断警报

A. 第 1-2 天：先做指南Days 1-2: Guides First

创建一份具备最小可行内容的指南文件：项目名称、语言、准确的构建/测试/检查命令，以及从已知故障中提炼的三条规则。运行智能体三次。每一次故障都变成一条新的指南规则。

此时还不要添加传感器。

B. 第 3-4 天：传感器与循环Days 3-4:Sensors and Loop

添加成本最低的计算型传感器：现有的测试套件。接入智能体循环，使智能体在每次变更后运行测试，失败时重试一次，两次尝试失败后升级处理。

验证智能体绝不会在未通过测试的情况下声称成功。

C. 第 5-6 天：记忆与权限Days 5-6:Memory and Permissions

添加一个智能体在每一步之后写入、并在会话开始时读取的 JSON 检查点。设置明确的权限边界。运行一个任务，关闭会话，重新打开，验证智能体能在不重复工作的情况下恢复。

D. 第 7 天：可观测性Day 7: Observability

为每一次工具调用和传感器结果添加结构化日志。设置一条熔断警报规则：当成本超过六天平均值的 2 倍时，自动发出警报。模拟一次成本激增，验证警报能否触发。

至此，挽具已在最小可行水平上完整就位。

E. 第 2 周及以后：扩展模式Week 2 and Beyond: The Expansion Pattern

七天之后，挽具已在最小可行水平上具备全部六层。此后的扩展遵循棘轮原则：让智能体在真实任务上运行。每一次发生的故障，都会揭示哪一层需要加强。

如果智能体重犯同一错误两次，说明指南缺少一条规则。如果智能体产出微妙的错误输出，说明缺少一个传感器。如果智能体超出范围，说明某项权限过于宽泛。如果你无法诊断出某次故障，说明可观测性不足。一次只改动一层，衡量效果，若任何一项评分卡指标出现回退，就回滚该改动。

扩展关口：所有条件均满足才可扩展Scale Gate：Expand Only When All Pass

• 未经人工修正的完成率不低于 80%

• 没有任何任务超出成本预算

• 智能体至少正确升级处理过一次

• 状态检查点至少经历过一次重启并存活

• 熔断警报至少在一次模拟异常中被成功触发

• 权限边界至少阻止过一次行动

当满足以下条件时，将一条指南规则升格为传感器：同一条审查意见出现超过三次；该规则可以在不涉及主观解释的情况下被检查；违规会造成实质性的返工或生产风险；且该检查能够说明如何修复违规。

这正是 Cursor 的劳伦·陈提出的原则：重复出现的人工纠正，正是将「品味」转化为「关卡」的信号[10]。

十一、决策框架DECISION FRAMEWORK

正确的起点，永远是能解决所观察到的故障的最简单的层级。运行智能体，观察故障，让挽具从真实证据中生长出来。

切不可在运行智能体之前就先构建一套复杂的挽具。

表十二：架构决策框架

问题

从此入手

尚不要添加

已知错误反复出现

指南规则

大模型评判器

输出质量参差不齐

计算型传感器

多智能体审查

智能体超出范围

权限边界

完整审批流程

会话之间状态丢失

JSON 检查点

知识图谱

成本不可预测

Token+成本预算

动态定价

故障不可见

结构化日志

完整可观测性栈

智能体无限循环

重试限制+超时

复杂编排

十二、生产就绪清单PRODUCTION CHECKLIST

表十三：生产就绪检查清单

要求

缺失时的后果

1

含构建/测试/检查命令的指南文件

智能体只能猜测环境

2

5 条以上源自故障的指南规则

已知错误反复出现

3

每个任务至少一个计算型传感器

错误将波及用户

4

有边界的重试+升级处理

无限循环、成本失控

5

写入文件系统的状态检查点

重启后进度丢失

6

权限边界

智能体超出范围

7

Token 与成本预算

无边界的支出

8

结构化日志

故障不可见

9

针对成本/错误率设置的熔断警报

回归无法被察觉

10

可信/不可信输入的区分

提示注入风险

11

紧急停止+状态保留

无法安全暂停

12

3 次成功的无人值守运行

部署了未经测试的系统

十三、挽具与其他方案的对比HARNESS VS. ALTERNATIVES

从提示工程到上下文工程再到驾驭工程的演进，并非一时的风潮，而是因为每一门学科都解决了前一门学科无法解决的局限。

表十四-B：三门学科对比

挑战

提示工程

上下文工程

驾驭工程

事实性错误

在提示词中纠正

RAG 检索

验证传感器

遗忘既往工作

在提示词中加摘要

记忆系统

文件检查点

错误的工具使用

在提示词中指示

限制工具清单

权限策略

质量参差不齐

添加示例

少样本示例

自动化测试

无限运行

「简明一些」

限制上下文

重试+成本预算

错误反复出现

重新添加纠正

存入记忆

指南规则（永久性）

生产事故

添加警告

护栏式检索

审批+熔断警报

这个模式很清晰：提示工程解决的是单轮对话内的表面症状。上下文工程解决的是信息缺口。而驾驭工程解决的是提示词和上下文都无法预防的结构性故障。提示词无法强制执行权限，检索管道无法约束重试次数，记忆系统无法触发一条警报，这些都是挽具的职责。

A. 复利效应The Compounding Effect

驾驭工程最重要的属性是复利。今天添加的每一条指南规则，都会在未来每一次运行中防止一整类错误。今天添加的每一个传感器，都会在未来每一次输出中捕捉一整类缺陷。今天添加的每一项权限边界，都会在未来每一次会话中阻止一整类事故。

提示词纠正不会复利，它们必须在每次对话中重新应用。上下文配置的复利速度很慢，因为随着语料库增长，检索质量会下降。而挽具的改进复利速度很快，因为它们是结构性的。

B. 何时三者都需要When All Three Are Needed

一个生产级智能体需要三门学科协同工作。提示词塑造智能体的推理风格与任务理解；上下文管道确保智能体拥有正确的信息；挽具确保智能体的行动是安全的、经过验证的、有边界的、可观测的、持久的。

移除任何一层都会削弱系统。但如果被迫选择将下一个工程小时投入到哪里，挽具几乎总能带来最大的边际改善。这正是基准数据给出的教训：模型和提示词是一样的，唯有挽具才是变量。

十四、局限性与常见错误LIMITATIONS AND COMMON MISTAKES

即便有了挽具，仍可能出错的地方，值得提前看清。

A. 过度工程化的挽具The Over-Engineered Harness

一个拥有 500 条指南规则、12 个推理型传感器、3 层大模型评判器审查以及一个 40 步审批流程的系统，不是生产系统，而是一个伪装成安全机制的瓶颈。挽具应该是使智能体可靠所需的最小基础设施。

每增加一层，都会增加延迟、成本和维护负担。如果智能体检查自己工作的时间超过了做工作本身的时间，说明挽具太重了。

B. 从不修剪的指南文件Guide Files That Never Get Pruned

指南文件是一行行积累起来的。若不修剪，它们会变得相互矛盾、冗余，最终被忽视。一个常见的故障是：智能体遵守了第 47 条规则（「始终添加错误处理」），却违反了第 183 条规则（「函数保持在 20 行以内」），因为错误处理增加了 10 行代码。

这些规则由不同的人在相隔数月的时间写下，从未被协调统一。应安排每月审查，移除已由传感器执行的规则，合并针对同一故障类别的规则。

C. 检查错误对象的传感器Sensors That Test the Wrong Thing

一个在每次智能体运行中都近乎全通过的测试套件是值得怀疑的。原因可能是测试太简单，或者智能体已经学会了产出能通过测试但并未真正解决问题的输出。

对抗性测试很重要：看起来正确但暗藏违规的输入、能通过架构验证但数据错误的输出、能构建通过检查但存在逻辑错误的代码。传感器套件应该能拒绝糟糕的工作，而不仅仅是确认良好的格式。

D. 未清理的记忆Memory Without Cleanup

状态检查点会不断占用磁盘空间并积累陈旧数据。三周前的检查点可能引用了已不存在的文件、已被撤销的决策，以及已被取代的产出物。智能体读取了这个陈旧的检查点，并基于过时的状态做出决策。

应为检查点设置过期时间，清理已完成任务的状态，只为每个活跃任务保留最新的检查点。

E. 挽具无法修复错误的目标The Harness Does Not Fix Bad Objectives

一个针对不良定义目标而完美设计的挽具，只会可靠地产出垃圾。如果验收标准本身是错的，传感器就会验证出错误的输出。如果指南规则编码了不正确的模式，智能体就会可靠地产出错误的结果。

挽具会放大构建者所选定的目标与评估方式。如果系统优化的方向本身错了，挽具只会让这个错误的规模变得更大。

表十五：常见的挽具错误

错误

症状

修复方式

规则太多

运行缓慢、相互矛盾

每月修剪

没有推理型传感器

微妙的错误通过检测

添加大模型评判器

没有计算型传感器

昂贵地依赖大模型评判器

先添加代码检查器、测试

陈旧的检查点

过时的状态

让旧检查点过期

没有熔断警报

回归无法被察觉

添加成本+错误告警

判断标准错误

可靠地产出错误结果

审查判断标准

全有或全无的权限

完全阻塞或完全无限制

分级授权

十五、真实世界的证据REAL-WORLD EVIDENCE

五个案例研究，共同证明同一个公式不是空谈。

A. OpenAI Codex：百万行代码，零手写OpenAI Codex: One Million Lines,Zero Manual Code

2026 年 2 月，OpenAI 工程师瑞安·洛波波洛报告称，一个小团队用了五个月，仅依靠 Codex 智能体构建出一个生产级产品[2]。代码库达到了百万行规模，跨越约 1,500 次自动化拉取请求。没有代码是手写的。

人类设计的是环境：指南文件、测试挽具、审查管道和部署关卡。团队的标语概括了这种新的分工：「人类掌舵，智能体建造。」

一个关键细节是：他们报告称，投入到挽具中的时间，超过了他们手写这些代码本应花费的时间。挽具，就是产品本身。

B. LangChain：模型不变，从第 30 名到第 5 名LangChain: 30th to 5th Without Changing the Model

2026 年 3 月，LangChain 工程团队将他们编程智能体在 Terminal Bench 2.0 上的排名，从第 30 名提升到了第 5 名[7]。模型没有任何改变。

这次提升完全来自挽具方面的优化：更好的指南规则、更紧密的传感器循环、更完善的错误恢复机制，以及更精确的工具配置。这个结果证明，驾驭工程不是纯理论上的改进，它在标准化基准测试中能带来可衡量的、有竞争力的增益。

C. GAIA 基准测试：模型不变，44 分的跳跃GAIA Benchmark: 44-PointSwing,Same Model

阿德南·马苏德博士使用完全相同的 Claude Sonnet 4.5 实例，在 GAIA 基准测试上记录了一次系统性对比[6]。在最简挽具下，模型得分为 30.91%；在包含结构化工具访问、验证循环和状态管理的生产级挽具下，同一模型得分达到 74.55%，43.64 分的改善完全归因于挽具。

这比大多数相邻模型代际之间的性能差距还要大。

D. Hashline：一个下午让 15 个模型全部提升Hashline: 15 Models Improved in One Afternoon

安全研究员 Can.ac 在 16 个不同的大模型上，针对一个编程基准进行了一次系统性实验[9]。仅通过改变挽具，具体而言是工具格式和编辑方式，几乎所有模型的得分都得到了提升。整个实验在一个下午内完成。

没有任何模型经过微调、重新训练或更换。挽具的改动是关于工具如何调用模型，而非模型知道什么。

E. Ghostty：每一次故障对应一条规则Ghostty: One Rule Per Failure

米切尔·哈希莫托为终端模拟器 Ghostty 编写的 AGENTS.md 文件，是在数月的智能体辅助开发中一行一行积累起来的[1]。每一行都能追溯到一次具体的智能体错误。

这份文件既是挽具，也是历史记录。新接入的智能体阅读这份文件，能在数秒内继承数月积累的纠错知识。棘轮机制在实践中的表现是：当出现新错误时，文件会增长；而随着最常见的故障类别被覆盖，增长速度会逐渐下降。

十六、何时不该构建挽具WHEN NOT TO BUILD A HARNESS

并非所有智能体交互都值得投入工程成本。

当智能体反复运行相同的工作流、故障会带来实际后果、智能体在没有人类监督的情况下运作，或多个会话必须保留状态时，构建挽具才值得投入的成本。单轮查询、创意头脑风暴、探索性对话和一次性任务，并不能从指南、传感器或检查点中获益。

表十六：挽具决策过滤器

场景

是否需要挽具？

原因

一次性提问

不会重复，无后果

创意头脑风暴

输出是探索性的，无法验证

每日代码审查智能体

每日重复，错误有后果

研究摘要智能体

每周运行，必须引用来源

客户支持分诉

面向外部，必须可靠

个人笔记记录

风险低，无外部影响

CI/CD 流水线智能体

每次提交都运行，故障会阻塞团队

探索性数据分析

视情况

若被复用，是；若一次性，否

判断标准：如果智能体悄然产出了一个错误结果，你会注意到吗？如果会，你需要一个传感器。你下次会话是否需要重新解释同样的上下文？如果会，你需要记忆。一个错误会造成外部后果吗？如果会，你需要权限约束。如果以上皆非，那么对话本身就是挽具。

十七、多智能体系统的驾驭工程HARNESS ENGINEERING FOR MULTI-AGENTSYSTEMS

六层挽具适用于单个智能体。当多个智能体协作时，挽具需要扩展以覆盖它们之间的边界。

每个智能体都需要各自的指南、传感器与权限。系统还额外需要：智能体间类型化的交接、共享的状态模型、路由策略，以及一个任何智能体都无法覆盖的独立验证者。

A. 类型化交接Typed Handoffs

当智能体 A 将工作交给智能体 B 时，这次交接应是一种类型化接口：哪个产出物已经就位、它存放在哪里、什么已经被验证、什么仍未解决。诸如「完成了，看起来不错」这样的自由文本摘要，绝不能推动生产工作流前进。

接收方应该能够打开该产出物并独立验证它。SpaceXAI 操作手册详细记录了这一模式：每次交接都包含任务标识、产出物指针、证据、假设和截止日期[11]。

B. 共享记忆与共享上下文的区别Shared Memory vs.Shared Context

多个智能体共享同一场对话会造成上下文污染：每个智能体的推理、错误与纠正，都会充斥进其他每一个智能体的上下文窗口。更好的模式是：智能体共享一个结构化的状态模型（一个账本、一个图、一个数据库），并只读取与自身当前任务相关的状态。

Anthropic 的知识图谱实践手册展示了这一模式：工作智能体读写共享图谱，而编排者的上下文保持干净[12]。

C. 验证者必须是独立的The Verifier Must Be Independent

产出某个产出物的智能体不应是其质量的唯一评判者。生产者偏差是真实存在的：生成智能体拥有会扭曲其判断的上下文和动机。

应尽可能使用确定性传感器，并对于重要工作使用独立的验证者智能体。验证者报告故障，而不应悄然重写输出。路由器随后将故障证据发回给生产者，或在重试预算耗尽后升级处理。

表十七：多智能体挽具扩展

多智能体层

单智能体对应物

新增内容

类型化交接

自我验证

智能体之间的契约

共享状态模型

文件检查点

跨智能体记忆

路由策略

智能体循环

任务分配规则

独立验证者

计算型传感器

生产者-消费者分离

升级处理协议

人工批准

系统级升级处理

十八、结论

模型提供智能，而挽具决定这份智能最终成为一个产品，还是永远停留在一个演示阶段。证据是实证性的：仅靠挽具改动带来的性能增益，与模型升级带来的增益一样大。

44 分的基准跳跃、25 个名次的提升、百万行零手写的生产代码，模型是同一个，唯一的变量是挽具。

「Agent = Model + Harness」这个公式，是一份工程规格说明。这六层是任何需要在没有持续监督情况下运作的智能体所需的最小可行基础设施。指南防止已知的故障，传感器捕捉新的故障，智能体循环约束执行边界，记忆保留状态，权限强制安全约束，可观测性使调试与改进成为可能。

实践中我更推荐的，是哈希莫托的棘轮原则：每当智能体犯错时，就设计一个解决方案，使该错误永不再发生。不要打补丁式地修改提示词，要修复挽具本身。

从一份指南文件开始，添加一个传感器，设置一条权限边界，记录一个指标，设置一条熔断警报规则。挽具不断积累，智能体不断改进。最终结果不是一个更聪明的模型，而是一个可以被信任、可以被检视、可以被改进的系统。

AI 工程的三个时代，提示工程、上下文工程和驾驭工程，不是彼此的替代品，而是层层叠加的关系。一个生产级智能体需要这三者。但挽具才是决定系统能否真正上线的那一层。

一个完美的提示词放在一个破损的挽具之中，只会产出不可靠的结果；一个平庸的提示词放在一个强大的挽具之中，却能产出一致、可持续改进的结果。挽具，才是最终的赢家。

前进的道路是渐进式的：先构建一个有度量的循环，让故障可逆，为一类错误添加一个工具，只在专业化能带来增量信号时才划分角色，在对话之前先存储产出物，只有在归纳器已明确定义时才扩大规模。每一种模式都解决了前一阶段的一个具体局限。这种演进并非强制的，但它确实有方向。

一个可靠的、经过驾驭工程打磨的系统，应该能让这句话成立：每一个重要的输出，都能追溯到塑造它的一条指南规则、验证它的一个传感器、约束它的一项预算、保存它的一个检查点，以及记录它的一份日志。当这句话不成立时，增加更多模型调用通常只会增加不透明度。而当它成立时，挽具就成为了一种可组合的工程机制，而不再是一种不可捉摸的行为。

「在 2026 年真正脱颖而出的工程师，不是写代码最多的人，而是那些为智能体写代码构建出更优环境的人。」

表十四：关键术语

术语

操作性定义

智能体（Agent）

模型+挽具：具备工具、记忆、执行循环的大模型

挽具（Harness）

模型周围的一切：指南、传感器、循环、记忆、权限、可观测性

指南（Guide）

前馈控制：执行前读取的指令

传感器（Sensor）

反馈控制：执行后运行的验证机制

棘轮（Ratchet）

每一次故障都在挽具中变成一次永久性修复

熔断警报（Trip wire）

针对整体行为漂移的自动化预警机制

能力预算（Capability budget）

对范围、速率、可逆性、可见性的限制

升级处理（Escalation）

附带决策信息包+证据的结构化交接

内层挽具（Inner harness）

AI 实验室内置于基础模型中的安全层

外层挽具（Outer harness）

产品团队构建的定制化挽具

REFERENCES

[1] M. Hashimoto, “My AI Adoption Journey,” mitchellh.com, Feb. 5, 2026.
[2] R. Lopopolo, “Harness Engineering: Leveraging Codex in an Agent-First World,” OpenAI, Feb. 11, 2026.
[3] B. Böckeler, “Harness Engineering for Coding Agent Users,”
martinfowler.com, Apr. 2026.
[4] E. Mollick, “A Guide to Which AI to Use in the Agentic Era,” 2026.
[5] V. Trivedy, “The Anatomy of an Agent Harness,” LangChain Blog, Mar. 10,
2026.
[6] A. Masood, “Agentic Harness Engineering,” Google Cloud / Medium, Jun.
2026.
[7] LangChain Eng., “Improving Deep Agents with Harness Engineering,” Feb. 17,2026.
[8] Faros AI, “AI Engineering Report 2026: Acceleration Whiplash,” Aug. 2026.
[9] Can.ac, “I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed,” 2026.
[10] L. Tan, “How Cursor Turned AI Agents Into Better Engineers,” Aug. 12,2026.
[11] Google Cloud, “Harness Eng. for Multi-Agent Systems Using Google ADK2.0,” Jul. 2026.
[12] Anthropic, “Building Effective AI Agents,” anthropic.com, Dec. 2024.
[13] A. Osmani, “Agent Harness Engineering,” addyosmani.com, Apr. 2026.
[14] OpenAI, “Codex Agent Best Practices,” 2026.
[15] P. Schmid, “Trajectory-Capture as Competitive Advantage,” 2026.

来源方法：本文件是对上述公开工程资料进行独立实际综合整理而成。产品行为可能发生变化。本文中的建议、模板、伪代码及决策规则均为作者为实际应用而进行的改编，不代表任何提及组织的官方规范。所有图表均为原创。

这篇文章真正的洞察，不在于六层架构清单本身，而在于揭示了一个被长期回避的事实：AI 能力的边界，早已不是模型参数或推理能力的边界，而是工程纪律的边界。

过去两年，行业几乎将全部注意力押在「更大的模型」「更长的上下文」上，仿佛模型足够聪明，工程问题就会自动消解。而哈希莫托的棘轮原则、LangChain 的挽具实验，以及那份零手写代码的百万行代码库报告，共同戳破了这个幻觉：同一个模型，换一套挽具，性能差距可以超过四十个百分点，这比大多数模型代际升级带来的提升都大。

这意味着，AI 能力的竞争正从「模型军备竞赛」转向「工程纪律竞赛」。谁能把每一次失败转化为永久的系统改进，谁就能率先跑通生产环境。

因此，驾驭工程不是取巧的方法论，而是一种诚实的工程态度：它承认模型会犯错，然后认真地把这份不完美关进笼子里。

这才是 2026 年真正值得被讨论的技术转向。

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。

全文完

王吉伟频道图书《一本书讲透Agentic AI》已出版，完整构建Agentic AI在企业应用中的全景式知识体系，内容跨越 “基础认知-技术原理-业务应用-组织战略-实操指南” 五大板块，为读者提供从认知共识、技术解构、业务对接到组织变革的端到端路线图，欢迎大家关注。

【赠书福利进行中】

感谢大家的长期关注与支持。欢迎小伙伴们在文末留言与转发，王吉伟频道会随机选取读者，《一本书讲透Agentic AI》包邮到家。

【 文末福利1 】：后台发消息研报2026，获取15篇 2026年 AI Agent研报 。

【文末福利2】： 后台发消息Workflow，获取 Agentic Workflow 相关25篇论文。

【文末福利3】：后 台发消息agentic，获取Agentic AI相关资源 。

【文末福利4】：后台发消息RPA Agent，获取 相关论文和研报。

1、

2、

3、

4、

5、

6、

7、

8、

8、

10、

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。

全文完

王吉伟频道图书《一本书讲透Agentic AI》已出版，完整构建Agentic AI在企业应用中的全景式知识体系，内容跨越 “基础认知-技术原理-业务应用-组织战略-实操指南” 五大板块，为读者提供从认知共识、技术解构、业务对接到组织变革的端到端路线图，欢迎大家关注。

【赠书福利进行中】

感谢大家的长期关注与支持。欢迎小伙伴们在文末留言与转发，王吉伟频道会随机选取读者，《一本书讲透Agentic AI》包邮到家。

【 文末福利1 】：后台发消息研报2026，获取15篇 2026年 AI Agent研报 。

【文末福利2】： 后台发消息Workflow，获取 Agentic Workflow 相关25篇论文。

【文末福利3】：后 台发消息agentic，获取Agentic AI相关资源 。

1、

2、

3、

4、

5、

6、

7、

8、

8、

10、