Harness 到底是啥
当你花了一周把 Prompt 调得尽善尽美，把 RAG 上下文塞得满满当当，却在生产环境发现 Agent 还是偶尔会"发疯"——生成非法 SQL、调用不该调的工具、在循环里兜圈子出不来——你遇到的已经不是一个"提示词"问题了。
你需要的是 Harness。
一、Agent 工程的三阶段演进
AI Agent 的工程实践，过去两年走过了一条清晰的演进路径。这条路径不是技术的简单替代，而是关注焦点的层层递进：从单次调用，到单次上下文，再到整个系统的约束与治理。
阶段一：Prompt Engineering（提示工程）
这是大多数人接触 Agent 的起点。核心问题是：模型能不能听懂我在说什么？
我们学习怎么写更清晰的指令、怎么加 Few-shot 示例、怎么用 Chain-of-Thought 引导推理。这个阶段解决的是"单次调用"的质量问题——你给模型一个输入，它给你一个输出，输出好不好，基本取决于你的提示词功力。
但它有个天然的天花板：无论提示词写得多精妙，模型本质上还是在做一个无状态的单轮预测。它没有记忆、没有工具、没有纠错能力。一旦任务变复杂，提示词再长也兜不住。
阶段二：Context Engineering（上下文工程）
当 Prompt 不够用了，我们开始关注模型"当前时刻能看到什么"。这就是上下文工程。
RAG 检索、历史对话拼接、工具返回结果的格式化、记忆模块的读写——所有这些工作，本质上都是在回答一个问题：在这一次调用发生前，我怎么把最有价值的信息塞进模型的 context window？
Context Engineering 让 Agent 从"单轮问答"进化成了"多轮对话 + 外部知识"。但它依然有一个盲区：它只负责把信息喂给模型，不负责约束模型怎么用这些信息。
模型拿到了数据库连接工具，它可能生成一条删库 SQL；模型拿到了 10 个工具，它可能在一个死循环里反复调用同一个。上下文工程管的是"可见信息"，管不了"行为边界"。
阶段三：Harness Engineering（编排工程）
Harness Engineering 是 Agent 工程演进的第三个阶段，也是目前最关键的一步。
它的核心命题不再是"单次调用质量"，而是整个 Agent 系统在时间维度上的稳定性、可控性和可恢复性。
如果说 Prompt Engineering 是在写一个好剧本，Context Engineering 是在给演员提供完整的场景和道具，那 Harness Engineering 就是搭建整个剧组——导演负责调度（编排）、场记负责记录（状态）、保险绳负责兜底（约束与恢复）、监视器负责实时观测（评估）。
Harness 不是替代前两者，而是把前两者放进一个可控的系统里运行。
二、成熟 Harness 一定要包含三件事
理解了 Harness 在整个工程体系中的位置，接下来看看一个成熟的 Harness 到底要解决哪三类问题。
这三件事是 Harness 设计的核心目标，也是检验一个 Agent 系统是否"production-ready"的标准。
1. 约束：哪些能做，哪些不能做
约束是 Harness 的第一道防线。它回答的是"能力边界"的问题。
这个边界包括多个维度：
- 安全边界：Agent 不能调用删除类工具、不能访问敏感数据、不能执行未经审核的操作
- 资源边界：单次任务最多消耗多少 token、最多调用几次工具、最长执行多久
- 逻辑边界：在特定状态下，哪些工具是可用的、哪些是不可用的。比如"订单未支付"状态下，不允许调用"发货"工具
约束不是写在 Prompt 里的"请遵守以下规则"——那种约束太软，模型会遗忘、会误解。Harness 里的约束是系统级的硬编码，在工具调用前、在 API 请求发出前就被强制执行。
2. 校验：输出前怎么检查
约束管的是"输入侧"（什么能进），校验管的是"输出侧"（什么能出）。
Agent 的执行链路往往不是一步到位的。每一步的中间输出，Harness 都需要有能力进行校验：
- 格式校验：LLM 生成的 JSON 是否符合预期 schema？SQL 语法是否合法？
- 语义校验：生成的内容是否偏离了任务目标？检索召回的文档是否和问题相关？
- 一致性校验：多步执行的结果之间是否存在矛盾？
校验的意义在于在错误扩散之前拦截它。如果第三步的输出是错的，第四步、第五步会在这个错误的基础上继续累积，最后给出的结果可能面目全非。
3. 恢复：失败以后怎么办
这是 Harness 和前两个阶段最本质的区别。Prompt 和 Context 都是"事前准备"，而恢复是"事后治理"。
Agent 在复杂任务中失败是常态，不是意外。Harness 需要为各种失败场景设计恢复策略：
- 重试：网络超时、LLM 返回格式错误、工具临时不可用——这些可以自动重试
- 切路径：当前策略走不通时，降级到备选方案。比如"精确检索失败"→"扩大检索范围"
- 回滚：多步任务中，某一步失败后，回滚到上一个稳定状态，而不是从头再来
- 人工介入：当自动恢复都失效时，优雅地暂停任务，把上下文和当前状态呈现给人类操作员
恢复能力决定了 Agent 系统在真实业务场景中的可用性上限。一个没有恢复机制的 Agent，就像一个没有刹车的车，速度快但没人敢用。
三、六层架构：从理念到落地
三件事不是空泛的设计理念，需要落实到具体的架构层次上。下面这张六层架构图，展示了一个完整 Harness 的底层结构。
注意六层的排列顺序：从下到上，每一层都依赖其下所有层的能力。底层管输入，中层管执行，顶层管治理。
LAYER 1：上下文管理
这是整个 Harness 的根基。如果 Agent"看不到正确的东西"，上面所有层都白搭。
上下文管理层的职责包括：
- 上下文组装：把用户输入、历史对话、RAG 检索结果、记忆模块召回内容，按照优先级和格式拼成最终的 prompt
- 截断与压缩：当总长度超过模型 context window 时，按策略舍弃低优先级内容
- 路由决策：不同场景走不同的上下文策略。比如"闲聊"走短记忆，"深度分析"走长检索
如果没做好：Agent 看到的上下文要么信息过载（重要信号被噪声淹没），要么信息缺失（关键背景没放进去）。这不是模型能力差，是"喂料"出了问题。
LAYER 2：工具系统
工具是 Agent 伸向外部世界的"手"。工具系统层负责管理这些手能伸到哪里、怎么伸。
核心能力：
- 工具注册与发现：Agent 怎么知道有哪些工具可用？工具的输入输出 schema 是什么？
- 权限控制：不同 Agent 实例、不同用户、不同任务场景下，工具的可访问范围不同
- 调用封装：把 LLM 生成的工具调用意图，翻译成实际的外部 API 请求；把外部返回的结果，格式化后送回上下文
如果没做好：Agent 可能调用不该调的工具（权限泄漏）、传入错误的参数格式（schema 不匹配）、或者根本无法发现新接入的工具。
LAYER 3：执行编排
有了上下文和工具，接下来要回答的问题是：任务怎么一步步执行？
执行编排层是 Harness 的"中枢神经系统"，负责：
- 流程控制：把复杂任务拆成可执行的子步骤，决定每一步调用什么、等谁的结果
- 并行与串行：哪些步骤可以并发执行？哪些必须严格串行、有先后依赖？
- 超时与重试：单步执行的最长等待时间是多少？超时后怎么降级？
常见的编排模式包括 DAG（有向无环图）、状态机（State Machine）、以及更灵活的 ReAct 循环。Harness 不强制你用哪种模式，但要求编排过程可观测、可干预、可回滚。
LAYER 4：状态与记忆
Agent 不是无状态的函数，它是一个在时间长河中持续运行的系统。状态和记忆层负责让这个系统有"连续性"。
- 短期记忆：当前任务执行过程中的中间变量、中间结果、上下游依赖
- 长期记忆：跨任务、跨会话的知识沉淀，比如用户的偏好、历史决策、业务规则
- 状态持久化：任务执行到一半崩溃了，重启后能不能从断点续传？
状态和记忆的区别：记忆是"知识"（我知道什么），状态是"快照"（我现在在哪里）。两者缺一不可。
LAYER 5：评估与观测
前面四层让 Agent"能跑起来"，评估与观测层回答的问题是：它跑得对不对？
这层是 Harness 的"监视器"和"仪表盘"：
- 过程观测：每一步的输入、输出、耗时、token 消耗，都要被记录和可视化
- 质量评估：用规则或模型对中间输出打分，判断是否符合预期
- 反馈闭环：评估结果可以实时反馈给上层（比如触发重试、切换路径）
观测不是运维团队的事后行为，而是 Harness 运行时的一部分。没有观测，你就不知道 Agent 什么时候在"胡说八道"，更谈不上纠偏。
LAYER 6：约束与恢复
六层之巅，是 Harness 的"保险绳"和"刹车片"。这一层把"最重要的三件事"中的约束和恢复，落实为系统级的保障机制。
- 约束执行：在工具调用前检查权限、在输出返回前检查合规性
- 熔断与降级：当错误率超过阈值、token 消耗超过预算、执行时间超过上限时，自动熔断
- 回滚与恢复：当某一步失败时，回滚到上一个稳定状态，或切换到备选方案
这一层是 Harness 区别于普通 Agent 框架的分水岭。大多数框架做到了 L1-L3，少数做到了 L4，真正具备完整 L5-L6 能力的系统，才有资格被称为"生产级 Harness"。
四、一张图看懂三者的关系
最后，把三阶段、三件事、六层架构串起来看：
| 维度 | 内容 | 解决的问题 |
|---|---|---|
| 时间轴（演进） | Prompt → Context → Harness | 从单次调用质量，到单次上下文质量，再到系统级稳定性 |
| 目标轴（职责） | 约束、校验、恢复 | Harness 必须回答的三个核心命题 |
| 结构轴（落地） | 六层架构 | 从输入到治理的完整技术栈 |
三者不是孤立的，而是层层递进的关系：
三阶段告诉我们"为什么需要 Harness"，三件事告诉我们"Harness 要做什么"，六层架构告诉我们"Harness 怎么做"。
结语
Prompt Engineering 的时代，AI 从业者比拼的是"谁能写出更好的提示词"。
Context Engineering 的时代，比拼的是"谁能把更丰富的信息塞进上下文"。
而到了 Harness Engineering 的时代，比拼的是"谁能造出一个既聪明又可靠的系统"。
聪明是模型的天赋，可靠是工程的能力。Harness 做的不是让 Agent 更聪明，而是让聪明的 Agent 在复杂、真实、充满不确定性的世界里，始终运行在可控的轨道上。
这就是 Harness 的本质。