Harness Engineering
定义
Harness Engineering，是指为一次 Agent 运行搭建完整执行环境的工程层，核心工作包括：配置可调用的工具、设定运行约束、接通反馈管道，并安排单次运行中的调用与验证方式。
用文中的话说，它解决的是 Agent “这一趟怎么跑”的问题。
它不是在优化一句提示词，也不只是补充上下文，而是在 Agent 真正开始干活之前，把它能用什么、不能做什么、做完如何检查、外部环境会返回什么信号，先工程化地准备好。
在四层演进模型中的位置
原文给出了一个四层演进心智模型，强调后层会包住前层，而不是简单替代：
- Prompt Engineering：优化一句话怎么写。
- Context Engineering：策划模型推理时能看到的全部信息。
- Harness Engineering：搭建 Agent 运行的完整环境。
- Loop Engineering：设计驱动自主工作的迭代循环。
对应口诀是：措辞 → 上下文 → 环境（harness）→ 循环（loop）。
因此，Harness Engineering 的位置非常明确：它在 Context Engineering 之后，在 Loop Engineering 之前。先有上下文，再有可执行环境，最后才谈循环控制与持续运转。
本文语境下的具体含义
在这篇文章里，Harness Engineering 不是泛指所有“Agent 基础设施”，而是特指单次运行层面的装备工作。原文明确把它定义为：
- 配置工具
- 设定约束条件
- 建立反馈管道
这里的“反馈管道”尤其重要，因为 Agent 是否真的完成任务，不能只听它自报结果，而要让真实环境返回可核验的信号。文中后面反复强调：可靠性不应建立在“赌模型这次够聪明”上，而应建立在可验证的系统设计上。虽然这句话主要落在 Loop Engineering 的验证循环，但它的前提正是 Harness 先把验证入口和环境反馈接好。
典型内容：单次工具调用与验证
原文在区分 Harness 与 Loop 时，给了一个很关键的例子：Harness 负责的是像单次工具调用、验证这样的内容。
这说明 Harness Engineering 的典型工作包括但不限于：
- Agent 这次运行能调用哪些工具
- 工具调用的输入输出如何组织
- 调用后从真实环境读回什么结果
- 用什么方式验证这一步是否成立
例如，验证可以是编译器结果、单元测试结果、命令执行输出等确定性反馈。虽然文章把“每一步都验证”“优先确定性验证”归入 Loop Engineering 的 8 大组件之一，但从工程分层看，要做到这些，Harness 必须先把调用链路和验证链路搭出来。没有 Harness，Loop 就无从控制。
与 Loop Engineering 的边界
这是本文引入 Harness Engineering 的主要目的：拿它与 Loop Engineering 做边界对比。
原文的区分非常直接：
- Harness 决定：这一趟怎么跑
- Loop 决定：什么时候跑、跑几趟、跑到什么算完
把这句话展开，可以更容易理解两者边界：
Harness 关注单次执行
Harness Engineering 关注的是一次运行内部的执行条件，例如：
- 这一趟能用哪些工具
- 这些工具怎么接到 Agent 上
- 运行时有哪些硬约束或安全边界
- 执行后有哪些反馈会返回给 Agent
- 单步结果如何被验证
它更像是在为一次任务出车前做整备：车有没有油、仪表是否工作、路线限制是否设好、到站回执如何拿到。
Loop 关注反复调度与终止
Loop Engineering 则更高一层，关注的是：
- 任务什么时候被触发
- 是否需要继续下一轮
- 是否派发子 Agent
- 是否进行自我喂料或状态更新
- 什么时候停止
- 卡住时是否升级给人
文中的表述是：Loop 会在 Harness 之上不停地“戳”Agent，去发现工作、派发子 Agent、自我喂料，并判断什么时候停。
所以，如果把 Agent 系统看成一台会持续运转的机器，Harness 更像单次运行的底座和工装，Loop 则是调度器、控制器与停机逻辑。
二者不是替代关系，而是上下层关系
原文特别强调四层模型是“包住前一层”，不是替代前一层。Harness Engineering 与 Loop Engineering 也是同样关系。
这意味着：
- 做了 Harness，不等于已经做了 Loop
- 做 Loop，也不能跳过 Harness
- Loop 的可靠运行，建立在 Harness 已把环境、工具、约束和反馈准备好的前提上
换句话说，Loop Engineering 不是拿来取代 Harness Engineering 的；它是建立在 Harness 之上的控制层。
如果没有 Harness，Loop 只是在空转，因为它既没有可靠工具，也没有可信反馈，更没有单步可验证的执行底座。反过来，如果只有 Harness 而没有 Loop，系统往往只能把某一趟跑好，却无法解决自动触发、持续重试、收敛停止、卡住升级等“持续运转”问题。
为什么这个概念重要
在本文中，Harness Engineering 的意义主要不是单独展开一整套方法论，而是帮助读者理解一个经常混淆的边界：很多人以为给 Agent 接好工具、写好校验、配好约束，就已经进入了 Loop Engineering。但原文的观点是，这还不够。
这些工作更准确地说，属于 Harness 层：它们让 Agent 能跑、知道边界、获得反馈。真正的 Loop 层，还要进一步决定：
- 何时启动
- 按什么节奏持续执行
- 如何检测无进展
- 预算耗尽怎么办
- 何时把任务交还给人
这也是文中“人的角色上移”的关键：不是只写一句 prompt，也不只是搭一个单次执行环境，而是开始设计完整控制系统。
边界与例外
它不负责决定循环触发时机
如果系统需要定时发现工作、在事件发生时自动启动，或让多个 Agent 并行运行，这属于 Loop Engineering 的自动化触发与并行能力，而不是 Harness Engineering 的定义范围。
它不单独定义完成标准
单次验证方法可以由 Harness 提供，但“跑到什么算完”、何时因无进展而退出、何时因预算耗尽而停机，属于 Loop Engineering 的停止条件与控制逻辑。
它不是 Prompt 或 Context 的同义词
Harness Engineering 不是改写提示词，也不是单纯补资料。前者偏措辞，后者偏信息组织；Harness 偏执行环境。三者层级不同，但会叠加。
与本文其他概念的关系
- Context Engineering：负责让模型在推理时看到合适的信息；Harness Engineering 则继续向下，把信息之外的工具、约束与反馈也接好。
- Loop Engineering：在 Harness 之上设计持续运行的循环系统，处理触发、重试、终止与升级。
- Human-in-the-Loop：危险操作的人类门控通常会在 Loop 中作为升级或审批机制出现，但其可执行边界往往需要 Harness 先设好。
- Loop Engineer：其工作不只包含 Harness，但若缺少 Harness 能力，就无法搭出可靠的循环系统。