Harness Engineering：让 AI 可靠执行长任务的系统工程学

模型之外的那个"执行环境"，才是决定任务能否跑完的真正变量。

大多数人谈论 AI 应用，谈的是模型——哪个更聪明、更快、更便宜。这个视角不算错，但它忽视了一个更关键的问题：

Harness Engineering（驾驭工程）正是为了回答这个问题而诞生的工程学科。它不是提示词技巧，不是模型微调，而是一套关于"如何为 AI 构建可靠运行环境"的系统性方法论。

这个词从哪里来

2026 年 2 月，HashiCorp 创始人、Terraform 作者 Mitchell Hashimoto 发表了一篇博文，描述了他在使用 AI Agent 时形成的一个习惯：每当 Agent 犯了一个错误，他不是在提示词里多加一条提醒，而是把这个错误的修复方案永久性地工程化进 Agent 的运行环境里。他把这种做法称为"engineering the harness"。

几周之内，OpenAI 和 Anthropic 相继发表工程博客，Martin Fowler 也在他的网站上深度展开了这一概念。一个新的工程学科的名字就此确立。

它能迅速引发共鸣，是因为它精准命名了每一个在生产环境中使用 AI Agent 的工程师都已经碰到过的问题——只是之前没有一个统一的词来描述。

三层模型：它填补的是哪个空白

要理解 Harness Engineering 的位置，先把 AI Agent 开发的三个层次区分清楚：

提示词工程优化的是单次交互的质量：如何提问，结构如何组织，给什么样的例子。它的作用域是一轮对话，一次输出。

上下文工程优化的是模型在单次任务中能看到什么：哪些文档被检索进来，历史对话如何压缩，什么信息放进上下文窗口，什么被舍弃。

Harness Engineering 则构建的是 Agent 运行的整个执行世界：能调用哪些工具，从哪里获取信息，如何验证自己的决策，什么条件下应该停止。它的作用域是数小时、数百次决策构成的自主执行过程。

前两层决定的是单次交互的质量。第三层决定的是 Agent 能否在无人监督的情况下可靠地跑完全程。当任务是回答一个问题，提示词就够了。当任务是自主运行六个小时并产出一百万行代码，你需要的是 Harness Engineering。

核心定义

Harness Engineering 是一门关于为自主 AI Agent 设计执行环境的工程学科。

它定义：Agent 能调用哪些工具、权限边界在哪里；Agent 从哪里获取信息、如何检索；Agent 如何验证自己的输出、错误如何被发现和修正；在什么条件下 Agent 应该暂停并等待人工介入。

如果模型是赛车手，Harness Engineering 就是赛道设计、护栏布置、赛程规则和维修站位置——是让赛车手能够发挥全力而不撞墙的整个体系。

四个核心机制

一、文档与标准：给 Agent 一张真正可用的导航地图

Agent 最大的盲点是上下文——它不知道你的项目历史、团队决策、命名约定，以及上周的架构讨论落脚在哪里。把这些东西写进文档是必要的，但文档的存在不等于 Agent 能用它；信息必须以可到达、可检索的方式组织，才能真正发挥作用。

OpenAI 工程团队曾经把所有规范和历史决策塞进一个大文件，希望 Agent 读完就能"懂事"。结果从四个方向失效：文件太大挤占了真正有用的上下文空间；所有内容同等优先级意味着没有优先级；项目演进让文档迅速过时；平铺的文字完全无法被机器验证。

他们最终的解法是把总入口文件压缩到一百行，让它只扮演一个角色：导航地图。它指向一个结构化的文档目录，包含设计决策、执行计划、产品规格和参考文档。CI 系统负责验证文档间的交叉引用是否完整，Agent 在运行时导航到它真正需要的内容。

这背后的原则直接而残酷：不在 Agent 运行时出现在上下文里的东西，对 Agent 来说就不存在。

二、约束与规则：先设边界，再给自由

没有约束的 Agent 不会变得更自由，它只会漂移——在没有边界的空间里不断重复它在训练数据里见过的模式，包括那些错误的模式。

OpenAI 工程团队的核心实践是强制分层架构：Types → Config → Repo → Service → Runtime → UI，单向依赖，不可逆转。这个规则不是写在文档里供 Agent 参考的，而是用自定义 Linter 机械化地强制执行的——违反规则时，Linter 的报错信息里直接包含了如何修正的指令，Agent 可以直接消费这个反馈并自我纠正。

这个洞察对人类工程团队同样适用，但在 Agent 上下文里格外关键：Agent 行动得越快，缺乏约束时架构漂移得就越严重。 对人类团队来说，这类规范往往在公司扩张到数百名工程师时才会被认真实施；对 Agent 来说，这是第一天就必须到位的前提条件。更多的约束，往往带来更高的可靠性，而不是更低。

三、反馈循环：让错误在到达人眼前就被消灭

Martin Fowler 在他的 Harness Engineering 文章里提出了一个精炼的分类框架：Harness 由两种控制组成，它们方向相反但互补。

**前馈控制（Guides）**在 Agent 行动之前发挥作用，目标是提高第一次就做对的概率。它包括编码规范、架构规则、如何完成某类任务的操作指南——这些都以 Agent 可以直接消费的形式组织和呈现。

**反馈传感器（Sensors）**在 Agent 行动之后介入，目标是帮助 Agent 自我纠正。传感器分为两种：计算型的（测试、Linter、类型检查）确定性强、速度快，可以在每次变更后立即运行；推理型的（让另一个 LLM 做代码审查、语义分析）更慢更贵，但能处理测试无法覆盖的语义层面问题。

两者缺一不可。只有前馈，Agent 不知道规则是否真的被遵守了；只有反馈，Agent 会一遍遍重复同样的错误直到传感器响。两者配合，才能构成一个真正有效的自我修正闭环。

四、自我迭代：把债务偿还变成一个持续运行的系统

技术债务在 AI 生成内容的场景下会以更隐蔽的速度积累——Agent 不会主动抱怨质量问题，它只是继续执行。

OpenAI 团队的解法是把核心原则编码进仓库，然后定期在后台运行专门的 Agent 任务，扫描原则偏差并自动提交重构 PR。大多数 PR 在一分钟内自动合并。这不是一次性的大规模重构，而是把技术债务的清理变成一个持续运行的系统性过程——小额、高频、自动，而不是积累到无法承受时才爆发的大手术。

这揭示了 Harness Engineering 的一个深层观念：系统的健康不是靠一次性的好设计维持的，而是靠持续运行的自我修正机制维持的。

Human-in-the-Loop：把人类判断放在真正值得的地方

Harness Engineering 不是要消灭人类监督，而是要把人类的判断力放在真正值得的决策节点上。

全自主会在高风险操作处出错；全人工监督会让 Agent 的效率优势荡然无存。成熟的 Harness 设计通常把审批门放在不可逆操作之前，把周期性检查点放在长任务的关键里程碑，把运行时异常探测留给系统自动处理。

Martin Fowler 把人类在 Harness Engineering 里的角色定义为"驾驭者"（Steerer）：人的工作不是盯着 Agent 的每一步，而是观察 Agent 重复犯什么样的错误，然后把修复方案工程化进 Harness，让那类错误下次不再发生。人类在迭代系统，而不是逐一审查输出。

超越代码：这套思想能去哪里

Harness Engineering 发源于代码场景，但它的底层逻辑适用于任何需要 AI 长期自主执行的领域。能调用的工具、获取信息的方式、验证决策的机制、人工介入的节点——这四个要素在任何长任务场景里都成立。

知识与研究工作：负责文献综述的 Agent 需要知道哪些数据库可信、如何标记矛盾发现而不是武断合并、哪些结论需要人工确认再输出。这是 Harness，不是提示词。

法律与合规：合同审查 Agent 需要约束边界（哪些条款是红线）、验证机制（标记而不是自动修改）、以及审批门（超出阈值时强制上报）。同样的框架，不同的领域。

内容生产：长篇内容的生成和审核，需要风格指南以 Agent 可消费的方式组织、品牌约束以机械化方式强制执行、事实核查以传感器而非人工逐句审查的方式嵌入。

企业流程自动化：采购、报销、项目管理里的 AI 工作流，核心挑战是权限边界、验证逻辑和人工审批节点的设计——这是 Harness Engineering 最直接的迁移场景。

共同的规律是：任务越长、决策越多、后果越不可逆，Harness Engineering 的价值就越大。

一个会过期的系统，而非一套固定的架构

Harness Engineering 有一个反直觉的特性：它不是一套可以设计好、部署好、然后放在那里的固定架构。

Harness 里的每一个组件，都编码了一个关于模型当前局限性的假设。任务分解是必要的，因为模型在长任务上容易失去连贯性；上下文重置是必要的，因为模型在接近窗口限制时会退化；评判 Agent 是必要的，因为模型自我评估存在偏差。

但这些假设会过期。随着模型能力的提升，今天必要的某些 Harness 组件明天可能会变成不必要的开销。这意味着 Harness Engineering 是一个随每次模型迭代而需要重新校准的动态系统。

从另一个角度看，这也是它比提示词工程更有持久价值的原因：具体的提示词会随模型变化而失效，但关于"如何为 AI 构建可靠执行环境"的工程思维——文档的组织方式、约束的强制机制、反馈的闭环设计、人机协作的边界划定——作为工程学的基本原则，会随着 AI 能力的增长持续演进，而不是被淘汰。

延伸阅读

Harness Engineering 的本质命题很简单：聪明的 Agent 不是靠更好的模型跑出来的，而是靠更好的运行环境跑出来的。模型是赛车手，但让比赛发生的，是赛道。