到这里你已经理解了 Agent 的核心工作原理------LLM 通过 ReAct 循环，在上下文的辅助下使用工具完成任务。前面的实验证明了这套基本机制是有效的，但同时也暴露了明显的脆弱点：模型可能产生幻觉（编造不存在的工具或参数）、选错工具、或在遇到错误时无法自我恢复。一个能跑的 Demo 和一个可靠的产品之间还有巨大的鸿沟，而这些脆弱点正是 Harness 工程要解决的问题。本章前半部分回答了 Agent 是什么，下半部分回答 Agent 如何在生产环境中可靠运行。
前面几节建立了 **Agent = LLM + 上下文 + 工具** 的核心公式。这个公式描述了 Agent 的**内部组成**，即大脑、眼睛、手脚分别由什么承担。从 Harness 工程的视角看，还需要一个**工程实现**层面的视角：把 LLM 当作一个核心组件（Model），围绕它构建的所有支撑代码统称为 Harness。两个视角并非替代关系，而是不同抽象层次上对同一系统的描述。之所以换用更通用的 "Model" 一词，是因为 Harness 工程的原则适用于任何具备推理和工具调用能力的模型，不限于某种特定模型类型。Harness 的核心就是原公式中的"上下文 + 工具"，再加上三层保障机制：**约束**（限定 Agent 能做什么、不能做什么）、**验证**（检查 Agent 做得对不对）和**纠正**（做错了怎么补救）。
用方程展开生产形态下的完整组成：
> **Agent = LLM + 上下文 + 工具 + 约束 + 验证 + 纠正 = Model + Harness**
最小可工作的 Agent 只需要 LLM、上下文与工具就能跑起来；而要让它在生产环境中长期可靠运转，还需要补全约束、验证、纠正这三层工程外壳------约束防止越界、验证发现错误、纠正恢复异常。这三层机制不是新增的"独立模块"，而是围绕"上下文 + 工具"构建的保障层。换句话说，最小公式是 Demo 视角，扩展公式是生产视角；后者完全包含前者，并在外围加了一圈安全网。
举个例子帮助理解：上下文中嵌入退款政策是"上下文"的范畴，而校验退款金额不超过订单金额则属于"约束"；工具执行 API 调用是"工具"的范畴，而 API 超时后自动重试则属于"纠正"。模型提供基础的理解和推理能力，而 Harness 将这些能力引导、约束和放大为可靠的任务执行。设计和优化这套模型之外的基础设施的工程实践，就是 **Harness 工程**（Harness Engineering）。
用一个具体的例子来理解 Harness 的价值。假设你让一个 Agent 帮用户退掉 3 天前的订单。**没有 Harness 时**：模型看不到退款政策（缺上下文），不知道该调哪个 API（缺工具），直接编造一个退款结果回复用户（缺验证），用户发现退款根本没发生（缺纠正）。**有了 Harness 后**：系统提示词写明了 7 天退款政策（上下文），Agent 调用 `query_order` 和 `process_refund` 工具完成操作（工具），框架校验退款金额不超过订单金额（约束），校验数据库状态确认退款成功（验证），如果 API 调用超时则自动重试（纠正）。同一个模型，有无 Harness，结果天壤之别。
回到本章前面给出的马具隐喻：没有 Harness 的模型就像脱缰的野马，能力惊人，但无法可靠地完成任务。
更精确地说，模型之外的全部基础设施都属于 Harness。Harness 的核心是上下文与工具，围绕它们构建了三类工程化保障机制：
| 功能 | 一句话职责 | 与上下文/工具的关系 |
|--------------------|----------------------------------------|-----------------------------------|
| **Context（上下文）** | 为模型提供感知信息 | 核心能力 |
| **Tools（工具）** | 为模型提供行动手段 | 核心能力 |
| **Constrain（约束）** | 设定行为边界------能做什么、不能做什么 | 围绕上下文和工具构建的安全边界 |
| **Verify（验证）** | 自动判断操作结果的对错 | 围绕工具执行结果构建的检查机制 |
| **Correct（纠正）** | 发现问题时自动修正或回退 | 围绕工具调用失败构建的恢复机制 |
上下文与工具让 Agent "能做事"------理解任务并采取行动；约束、验证与纠正让 Agent "不做错事"------它们不是独立于上下文和工具之外的东西，而是确保上下文和工具在生产环境中可靠运转的工程实践。在 Agent 产品的成熟度曲线上，两者的重要性是不对称的。
早期的 Agent 框架主要关注上下文与工具：给模型工具、给模型上下文，让它"能做事"。而生产级 Agent 系统的重心已经转向约束、验证与纠正：确保工具调用是安全的、上下文是经过管理的、错误是可恢复的。
以 Claude Code 为例，它的 Harness 中绝大部分代码都是约束、验证与纠正，而非上下文与工具------工具本身（文件读写、命令执行、搜索）只是一小部分，而围绕这些工具构建的保障机制才是真正的核心。这些机制包括：
-
**流程状态管理**：追踪 Agent 当前执行到哪一步
-
**多层上下文压缩**：当信息太多时自动精简
-
**权限分类**：控制哪些操作需要用户确认
-
**熔断器**（Circuit Breaker）：当错误连续发生时自动"断电"停止重试------就像家里电路短路时保险丝会自动跳闸，防止整个系统崩溃
-
**错误恢复机制**：捕获异常、回滚到上一稳定状态、重试或交还给人类
**行业正在从"能做事"向"可靠地做事"转变，Harness 工程因此成为 Agent 系统的核心竞争力。**