本文面向项目管理员、架构师和技术负责人，系统说明 Harness 在 Agent 生产落地中的职责边界与工程实现框架。
摘要
Agent 进入生产环境后，主要问题不再是“模型是否能回答”，而是以下运行时问题：
任务一长就跑偏 遇到中断就只能重来 高风险操作没人拦 出了事故找不到原因 每次改完策略，都不知道有没有把原来的能力改坏
上述问题共同指向同一缺口：系统缺少 Harness，即面向执行回路、工具边界、状态恢复、审批控制、过程观测和评测发布的运行时控制层。
文档范围
维度 · 说明
文档类型
说明技术架构说明
目标读者
说明项目管理员、架构师、技术负责人、AI 应用工程师
关注对象
说明Agent 运行时控制层
重点内容
说明分层架构、关键对象、控制链路、事故映射、上线门禁
不含内容
说明具体框架 API 细节、单一厂商产品对比
核心结论
Harness 不是 SDK 包装层，而是 Agent 的运行时控制层。 Agent 是否可上线，取决于边界、状态、恢复、观测、评测和发布治理是否完整。 多数线上故障来自运行时缺口，而非模型单次回答能力不足。 评测与门禁不是附属流程，而是 Harness 治理层的组成部分。
Agent 的能力上限由模型决定，Agent 的可用下限通常由 Harness 决定。
一、概念界定：Harness 是运行时控制层，而非简单封装层
在实践中，Harness 经常被误解为以下任意一种：
一个 SDK 一个脚手架 一层工具封装
这些理解有局部合理性，但不足以覆盖其在生产系统中的职责范围。
从工程视角看，Harness 更准确的定义是：
当大模型开始连接真实工具、真实数据、真实副作用时，用来管理边界、状态、恢复、观测、审批和评测的那层运行时外壳。
上述定义中最关键的关键词不是“外壳”，而是“运行时”。
当系统进入持续运行状态后，团队需要处理的核心问题将转向系统设计与运行治理：
这次任务最多允许执行多少步 哪些工具可见，哪些工具可调用 哪些操作可以自动做，哪些必须停下来等人确认 中途失败后从哪里恢复，而不是整轮重来 长任务的上下文如何压缩，避免越跑越脏 线上 bad case 出现后，如何回放、归因、修复并生成回归样本
结合知识库中“Agent 运行时边界”的定义，Harness 至少还要把下面四条责任边界正式划清：
边界 · 应回答的问题
Decision Boundary
应回答的问题哪些判断可以交给模型
Runtime Boundary
应回答的问题哪些控制必须由 Harness 接管
Governance Boundary
应回答的问题审批、预算、权限在哪层执行
Recovery Boundary
应回答的问题失败恢复、回滚、续跑由谁负责
如果这些问题没有被正式设计，再强的模型也很难被称为“系统能力”。
因此，Harness 不是可选配件，而是 Agent 系统开始承担真实业务责任时必须具备的控制层。
二、问题来源：不稳定性的根因通常在运行时，而不在单次回答能力
系统不稳定的根因，通常不是模型本身不足，而是团队仍在以“单轮问答”的设计方式构建“多步执行系统”。
聊天模型的范式是这样的：
用户提问 -> 模型回答 -> 任务结束但真实 Agent 的基本单元，其实是一条执行回路：
接收目标-> 判断当前状态-> 决定下一步动作-> 调用工具或子流程-> 观察结果-> 更新状态-> 继续 / 暂停 / 切换 / 结束一旦系统出现以下场景，工程重点就会从语言质量转向执行回路稳定性：
读写文件 调 shell 或浏览器 调外部 API 跑多轮长任务 经过多阶段审批 需要多 Agent 交接 会对真实世界造成副作用
知识库在“Agent 最小闭环与状态管理”中还强调，稳定 loop 至少要显式定义 4 个控制点：
控制点 · 作用
Step Limit
作用防止无限循环或失控探索
Stop Condition
作用明确何时终止、交付或转人工
Retry Policy
作用处理工具失败、不稳定返回和临时超时
State Checkpoint
作用支持中断恢复、审计与回放
在缺少 Harness 的情况下，系统通常会出现以下四类失稳模式：
没有状态语义任务一断就得重来，或者恢复位置完全错乱。
没有边界语义模型知道怎么做，系统也就默认让它做，导致越权调用和误操作。
没有恢复语义所谓“继续执行”往往只是重新触发请求，而非从原有状态安全恢复。
没有治理语义缺少 Trace 与 Eval 时，问题定位和策略迭代将缺乏证据基础。
因此，Harness 的首要价值并非增加工具数量，而是将“执行回路”建模为可控制、可恢复、可观测的正式工程对象。
三、职责边界：Harness 管理的是运行边界，而非功能数量
在 Demo 阶段，工具数量往往被视为能力指标；在生产阶段，风险却更多来自“调用边界不清”，而不是“工具不足”。
因为只要系统开始连接真实资源，就必须先回答一组边界问题：
哪些目录允许访问 哪些接口允许写入 哪些动作必须审批 哪些结果允许自动外发 哪些中间数据不能进入模型上下文 哪些情况下必须停止并转人工
Harness 实际管理的并不是功能数量，而是系统可以承担责任的边界。
它真正做的，是把下面两件事拆开：
模型会不会做 系统允不允许它做
如果这两件事未被显式拆分，Agent 表面上能力更强，实际却更难治理。
进一步说，运行时边界不是一句“高风险要审批”就够了，还要明确哪些能力必须从模型手里收回到 runtime：
状态持久化与 Checkpoint 不能由模型自由组织 Pause / Resume 的状态续接必须由 runtime 统一管理 Tool 调用属于执行路径，但审批、预算、准入属于治理路径 一旦跨过 interrupt 或 replay 边界，side effect 必须满足幂等和可审计
四、参考架构：一个最小可用的 Harness 应具备哪些层
为统一概念说明与工程讨论，下文采用一个贯穿全文的业务示例：
AI 客服退款 Agent
它需要完成下面这条链路：
读取订单信息 判断用户是否满足退款条件 如果金额低且证据充分，自动通过 如果金额高或证据不足，暂停并转人工审批 审批后从原状态恢复执行 写回订单系统并通知用户 把整条过程留痕，供事故排查和回归评测使用
该示例同时覆盖读取、判断、写操作、审批、中断、恢复、审计与上线门禁等关键场景，适合作为 Harness 架构讨论的标准样本。
1. 最小六层结构
若将 Harness 抽象为最小可用闭环，通常至少包含以下六层：
层 · 作用 · 典型问题
Task Input Layer
作用接收目标、上下文、风险等级
典型问题请求进来后谁来定义任务边界
Agent Loop
作用决策、执行、观察、更新状态
典型问题下一步做什么，什么时候停
Tool & Permission Layer
作用工具注册、参数约束、权限拦截
典型问题哪些动作能做，哪些不能做
State Layer
作用Session、Checkpoint、Artifact、恢复点
典型问题中断后从哪里继续
Observation Layer
作用Trace、Metrics、分类、回放
典型问题出了事怎么定位
Governance Layer
作用审批、评测、发布门禁、人工接管
典型问题怎么保证可上线、可演进
其逻辑链路可概括如下：
用户目标进入-> 任务被标准化-> Agent Loop 决策下一步-> 访问 Tool Registry 选择工具-> 通过 Permission Gate 判断能否执行-> 执行结果写入 State / Artifact-> 关键事件进入 Trace-> 命中策略则 Interrupt-> 审批后 Resume-> 结果输出-> bad case 回流 Eval这一结构本质上已经不是“单纯的模型应用”，而是一套具备控制面和运行面的轻量运行时。只要系统需要执行长任务、连接真实资源并承受失败后果，就必须采用这一视角。
五、关键对象：除分层外，还必须显式建模的四类运行时对象
许多团队在实现 Harness 时，问题不在于组件数量不足，而在于关键状态对象没有被正式建模。
如果系统仅维护聊天记录而缺少结构化状态对象，运行状态将迅速失真。稳定的 Harness 至少需要显式定义以下四类对象。
1. Session State
Session State 不是消息列表，而是一次任务运行态的正式载体，至少应包含：
当前目标 已完成步骤 当前阶段 风险等级 最近一次决策 待处理审批 当前可恢复位置
如果进一步按知识库中的状态分层来校准，Session State 不宜混成一个“大对象”，而应至少区分三类状态：
状态类型 · 作用 · 典型内容
运行时状态
作用保存当前任务进度
典型内容当前步骤、剩余目标、失败次数
会话状态
作用保存本轮上下文
典型内容用户需求、已调用工具、观察结果
长期状态
作用保存跨轮可复用信息
典型内容用户偏好、历史任务、稳定事实
这样做的目的不是把状态做复杂，而是避免把当前工作状态、聊天上下文和长期记忆混在一起，导致恢复错位或行为漂移。
2. Checkpoint
Checkpoint 的本质不是简单备份，而是可重启的边界点。
它应该回答的问题是：
如果现在崩了，下一次从哪里继续 哪些步骤已经完成，不能重复执行 哪些副作用已经发生，不能再做一遍
3. Artifact
Artifact 是交接物，不应与聊天上下文混用。
例如：
已验证结论摘要 已处理订单列表 待人工确认的问题清单 中间文件路径 输出草稿
在长链路任务中，可靠交接依赖的不是模型记忆，而是结构化交接物。
4. Approval Ticket
很多系统表面上支持审批，但本质上只是增加了一个确认框，这不足以构成运行时级审批能力。
一个正式的审批对象，至少要知道：
为什么暂停 当前证据是什么 建议动作是什么 风险后果是什么 谁批准的 批准结果会恢复到哪一步
缺少这些字段时，审批只是一种手工补偿机制，而非正式的运行时对象。
六、落地顺序：优先构建最小闭环，再扩展复杂能力
对多数团队而言，直接追求“大而全”的框架化建设往往会放大复杂度。更可行的方式是按照风险优先级和收益密度分阶段推进。
阶段 1：先做边界，不做野生自动化
该阶段的目标是优先阻止高影响错误。
优先落地：
Tool Registry Permission Gate 风险分级 人工审批入口
这是最优先补齐的层。系统一旦接入真实工具，最大的成本通常不是能力缺失，而是错误执行且缺少拦截机制。
阶段 2：再做状态，让任务能中断和恢复
优先落地：
Session Store Checkpoint Artifact 持久化 Resume 语义
当系统开始跑长任务，这一层通常比模型调优更重要。
大量失败案例并非源于模型能力不足，而是源于执行状态断裂。
阶段 3：补可观测性，让问题能复盘
优先落地：
Trace Replay 错误分类 关键指标
缺少 Trace 时，问题定位高度依赖主观经验；具备 Replay 后，线上事故才可能被转化为工程资产。
阶段 4：最后接治理闭环，让系统能长期演进
优先落地：
Eval Harness 发布门禁 人工接管 版本对比 bad case 回流
这一层决定的是系统是否具备稳定迭代能力，而非依赖偶然的线上成功。
七、Tool Registry：其本质不是工具清单，而是责任清单
很多团队会把工具接入理解成“给模型一份可用函数列表”。
这种做法在 Demo 阶段可以工作，但无法覆盖生产环境中的控制需求。生产级系统需要建模的并不只是工具名称，而是工具责任属性。
一个成熟的工具定义，至少应该包括：
from dataclasses import dataclass@dataclassclass ToolSpec: name: str description: str risk_level: str side_effect: bool requires_approval: bool timeout_seconds: int retry_policy: str allowed_roles: list[str]这些字段的价值在于为控制层提供可执行语义：
risk_level决定是否要中断审批 side_effect决定是否允许自动重试 requires_approval决定 Resume 前置条件 timeout_seconds决定控制面怎么兜底 allowed_roles决定不同运行模式下的放权范围
因此，Tool Registry 管理的不是“能力目录”，而是“能力在何种责任边界内可以被调用”。
八、Permission Gate：关键不在于是否拦截，而在于拦截依据是否稳定
很多团队把权限控制做成 if/else：
if amount >500: ask_human()这种实现方式可以工作，但缺乏可扩展性与可审计性。
当系统规模扩大后，通常会出现以下问题：
不同业务线阈值不一样 不同用户等级阈值不一样 白天和夜间策略不一样 新策略上线后要不要回放老 case 谁改了规则，为什么改，是否验证过
因此，稳定的 Permission Gate 通常至少包含三层：
规则层例如金额阈值、操作类型、证据充分性、敏感级别。
决策层把规则计算成允许、拒绝、升级审批、降级执行等统一动作。
审计层记录这次为什么被拦、依据是什么、最终谁批准了。
再结合知识库中的“运行时准入架构”，生产级 Permission Gate 通常不会孤立存在，而是被放进更大的 Admission 架构里：
准入门 · 判断内容
Identity Gate
判断内容身份、租户、角色是否合法
Policy Gate
判断内容权限、审批、风险策略是否满足
Budget Gate
判断内容成本、并发、资源预算是否允许
State Gate
判断内容状态、前置条件、恢复点是否完整
也就是说，真正的 Gate 不只是“这步能不能做”，而是“这个请求、这个人、这份状态、这笔预算，是否允许这一步进入运行时”。
以 AI 客服退款 Agent 为例，一个基础策略可以写成：
退款金额 <= 100 元 且 订单状态明确 且 证据完整 -> 自动处理退款金额 100-500 元 或 证据存在缺口 -> 转人工审核退款金额 > 500 元 或 涉及异常账户 -> 必须高级审核此处真正重要的不是模型是否能做出判断，而是判断结果是否被纳入稳定、可审计的策略面。
九、长任务治理：主要问题不是 token 上限，而是状态断裂与上下文漂移
许多团队在处理长任务时，首先关注上下文压缩。这一方向正确，但不足以单独解决稳定性问题。
长任务中更关键的风险通常来自两类问题：
1. 状态断裂
比如一个 Coding Agent 已经改了 12 个文件，结果中途异常退出。如果没有 Checkpoint，系统只能从头再跑，轻则浪费时间，重则重复副作用。
2. 上下文漂移
任务跑得越久，历史尝试、旧假设、失败路径、临时判断会越积越多。在任务后期，问题往往不是“记不住”，而是“保留了过多不应继续携带的历史推理与失败路径”。
因此，成熟的 Harness 通常同时提供以下两类能力：
Context Compaction：提炼同一会话中的关键信息，保留连续性 Context Reset：在新的运行体里基于交接物重新开始，主动切断漂移
一个可操作的判断标准如下：
任务仍在同一问题空间内，只是信息变长：优先 Compaction任务已经进入新阶段，旧推理污染大于帮助：优先 Reset
稳定系统的关键，不是让模型持续记住一切，而是让系统知道何时保留连续性、何时切换到新的运行体。
十、Interrupt / Approval / Resume：Harness 中工程含量最高的控制链路
许多系统虽然提供“确认后继续”的交互，但这并不等同于正式的 Resume 机制。
正式的 Resume 机制要求系统从原状态点安全恢复，而非重新发起一轮请求。
这背后至少有 3 个正式语义：
Interrupt在满足某个条件时，运行体显式暂停。Approval由人工或策略给出继续、拒绝、修改后继续等决策。Resume带着原状态、原上下文、原交接物，从正确位置恢复执行。
可用如下伪代码说明其控制逻辑：
def run_refund_agent(state):whilenot state.finished: action = planner.next_action(state)decision = permission_gate.check(action, state)if decision.should_interrupt: ticket = approval_center.create_ticket(state, action, decision.reason) state.pending_ticket_id = ticket.id checkpoint_store.save(state)return"INTERRUPTED"result = executor.execute(action) state = reducer.apply(state, action, result) trace_store.append(action, result, state)return state.final_outputdef resume_refund_agent(ticket_id, approval_result): state = checkpoint_store.load_by_ticket(ticket_id) state = reducer.apply_approval(state, approval_result)return run_refund_agent(state)上述逻辑并不复杂，但在大量系统中恰恰缺失。没有这一机制时，人工介入只是业务层补偿；具备该机制后，人工接管才真正进入运行时主链路。
十一、Trace / Replay：其作用不是补充记录，而是问题定位入口
Agent 系统和传统问答系统最大的不同之一，是错误往往藏在过程里，而不是只体现在结果里。
同样一次退款误判，根因可能完全不同：
工具选错了 参数填错了 检索命中了错误证据 权限规则拦错了 Resume 恢复到了错误检查点 上下文压缩丢了关键条件
如果系统只保留最终结果，很多问题根本没法定位。
所以，一个最小可用的 Trace，至少应该记录：
用户目标 每一步决策 tool call 与 tool result 中断事件 审批事件 状态快照 最终输出
这里还需要补一个在知识库里被单独强调的区分：
Trace更偏结构化事件流，适合检索、审计、聚合和回放 Transcript更偏完整执行记录，适合复盘、评测、审批取证和人工阅读
在生产系统里，二者通常不是二选一，而是同一套底层运行数据的两种视图。
更进一步，成熟系统通常还会支持 Replay，用同一条失败样本回放不同版本策略，比较差异。
其重要性在于：
因为只有能回放，下面这些事情才真正成立：
复现线上 bad case 比较新旧策略差异 找到根因是在模型、工具还是策略 把事故沉成 Eval 数据集 在上线前阻止同类问题再次进入生产
缺少 Replay 时，优化通常依赖猜测；具备 Replay 后，优化才具备证据驱动基础。
从知识库“运行时证据架构”的角度看，Trace / Transcript 的价值不只在调试，还在于它们共同构成了上线治理需要的 4 类证据：
证据类型 · 典型内容
Decision Evidence
典型内容路由、策略、审批、降级决策
Data Evidence
典型内容检索结果、上下文片段、工具输入输出
Runtime Evidence
典型内容checkpoint、状态快照、事件轨迹
Governance Evidence
典型内容审计记录、门禁判定、放量结果
十二、Eval Harness：评测不应后置，而应作为治理层内生能力
很多团队习惯先实现流程，再补充评测。对于 Agent 系统，这一顺序通常应当反转。
因为 Agent 的错误并不稳定，今天能跑通的流程，明天可能因为模型版本、工具返回、上下文长度、策略变动而突然变差。
因此，Eval Harness 的位置不是附属测试，而是治理层的正式组成部分。
它至少应该做三件事：
1. 把线上 bad case 沉成样本
线上事故不应停留在口头复盘层面，更合理的做法是沉淀为结构化样本，例如：
{"case_id":"refund-high-risk-014","user_goal":"用户要求退款 899 元","expected_behavior":"进入高级审批，不得自动退款","risk_type":"financial_high_impact","source":"online_incident"}2. 在关键能力维度上做回归
例如：
风险操作是否正确中断 恢复后是否继续在原状态执行 输出是否带足够证据 高风险场景是否正确转人工 策略升级后是否影响低风险正常流转
这里还应明确两组最常见的评测权衡：
维度 · 左侧选择 · 右侧选择 · 含义
评测目标
左侧选择capability eval
右侧选择regression eval
含义前者看能力上限，后者守上线底线
评分方式
左侧选择只看结果
右侧选择过程 + 结果联合评分
含义后者更贴近 Agent 真实质量，但成本更高
3. 把评测接到发布门禁
这是最容易被忽略的一步。如果评测结果不影响发布决策，其治理价值将大幅下降。
更有效的做法是：
新版本策略提交-> 跑固定回归集-> 命中高风险失败则禁止发布-> 通过后才能进入灰度从系统工程视角看，Eval 的主要意义不是证明系统强大，而是阻止系统退化。
十三、事故映射：通过故障类型反推 Harness 缺口
前述概念可进一步收束为几类典型故障类型，以便将事故与控制缺口建立直接映射。
事故 1：AI 误删重要文件
缺的是：
工具风险分级 Permission Gate 审批中断
事故 2：任务做到一半崩了，只能从头重来
缺的是：
Checkpoint Artifact 持久化 Resume 语义
事故 3：系统越跑越偏，完全忘了原目标
缺的是：
目标回顾机制 Context Compaction Context Reset
事故 4：明明做了人工审批，恢复后却重复执行副作用
缺的是：
幂等性标注 Side effect 管理 恢复点设计
事故 5：改完策略后线上看起来正常，但高风险案例被放过
缺的是：
Eval Harness 固定回归集 发布门禁
这类故障的共性在于：问题并不主要来自模型语言能力，而是来自边界、状态、恢复与治理设计的缺失。线上环境首先考验的是责任边界，而不是单次回答质量。
十四、实施原则：七条优先落地的 Harness 建设原则
以下七条原则适合作为 Harness 建设过程中的持续检查项。
原则 1：先建边界，再谈自动化
不要在系统已经放权运行后再补风险控制。一旦接入真实工具，边界永远先于能力。
原则 2：把状态当一等资产，不要把它当聊天副产品
任务目标、检查点、审批状态和交接物都应采用正式存储，而不应依赖模型记忆。
原则 3：工具定义里必须包含风险语义
工具定义不仅应说明其功能，还应说明其副作用、审批要求与重试约束。
原则 4：中断和恢复必须成对设计
系统如果只支持中断而不支持安全恢复，稳定性仍然不足。真正有价值的是将“中断原因”和“恢复位置”成对建模。
原则 5：上下文管理的目标不是省 token，而是防漂移
上下文压缩的主要目标不是节省成本，而是保证后续决策仍基于干净事实。
原则 6：所有线上事故都应该变成评测资产
不应将 bad case 视为一次性事件。成熟系统会将事故样本转化为长期门禁资产。
原则 7：Harness 不是替模型背锅，而是替系统兜底
模型出错是常态。Harness 的价值不在于消除错误，而在于让错误可拦截、可恢复、可归因、可复盘。
十五、常见误区：采用某个框架并不等于具备 Harness 能力
不等于。
框架能提供很多有用能力，例如：
图式编排 状态容器 中断恢复接口 观测挂钩
这些能力都很重要，但框架解决的是“如何实现”，Harness 回答的是“系统要承担何种责任”。
团队可以在不依赖特定框架的情况下实现较好的 Harness；反之，也可能在使用先进框架的前提下依然缺乏真正的 Harness 能力。
判断标准只有一个：
这个系统在真实环境里，是否拥有明确的边界、稳定的状态语义、可恢复能力、可观测能力和可发布的治理闭环。
如果这些条件不成立，那么该系统更接近“带工具的模型应用”，而非“可托付的 Agent 系统”。
十六、角色视角：不同角色应重点关注的判断项
为便于项目协同，下面从三类典型角色给出关注重点。
1. 技术负责人
重点关注：
是否把 Agent 当成执行回路，而不是一次回答 是否明确了风险分级和人工接管边界 是否设计了 Checkpoint、Resume、Trace、Eval 闭环 是否把发布门禁接到了高风险能力上
2. AI 应用工程师
优先实现：
Tool Registry Permission Gate Session Store Checkpoint / Resume Trace / Replay Eval 回归集
在上述基础层能力稳定之前，不建议过早追求复杂编排能力。对大多数系统而言，这些基础层能力带来的稳定性收益高于单纯优化 Prompt。
3. 项目管理员或业务负责人
更应向团队追问以下问题：
这个系统在哪些情况下会自动执行 哪些情况下会停下来找人 如果执行出错，能不能定位原因 改了策略后，如何证明没有把高风险能力改坏 出了问题后，是不是能恢复，而不是只能重做
如果这些问题无法被清晰回答，说明系统尚未进入可经营阶段。
十七、上线标准：关键不在于单次跑通，而在于持续受控运行
很多团队对“可以上线”的判断仍停留在以下层面：
这个流程我跑通过 那个案例它答对了 关键演示流程未暴露明显问题
但系统工程中的上线标准从来不是一次成功，而是连续运行时仍然受控。
一个更合理的上线前检查表，至少应该包括：
是否有明确的高风险动作清单 是否有 Identity / Policy / Budget / State 四类准入门 是否有审批与人工接管机制 是否有可恢复的状态和检查点 是否有 Trace、Transcript 和最小 Replay 是否有固定 bad case 回归集 是否把评测结果接到发布门禁 是否保留了可复核的 Decision / Data / Runtime / Governance 证据 是否知道失败后谁负责接手
如果这些条件尚未具备，那么无论模型能力多强，系统都只能算实验性可用，而非生产级稳定。
3. 运行时 SLO 必须分层拆分，成本护栏必须前置到架构
上线标准只回答“能不能上线”还不够，还必须回答“上线后系统能不能持续受控运行”。这就要求 Harness 在两个量化维度上做出明确承诺。
3.1 五类运行时 SLO 必须分层，而不是只有“系统整体成功率”
如果所有性能和可靠性问题都汇总成一个全局成功率指标，事故复盘时几乎无法定位“到底是模型慢、工具失败、检索劣化，还是审批卡死”。一个最小可用的 SLO 地图至少应包含：
SLO 类型 · 关注指标 · 对应架构能力
入口 SLO
关注指标请求时延、可用性
对应架构能力API 层、队列、限流
推理 SLO
关注指标模型时延、输出成功率
对应架构能力模型路由、上下文预算
检索 SLO
关注指标召回时延、grounding 质量
对应架构能力RAG 链路、索引策略
工具 SLO
关注指标工具成功率、超时率
对应架构能力tool gateway、重试与降级
恢复 SLO
关注指标checkpoint 恢复时间、人工接管时间
对应架构能力状态存储、回放、审批通道
SLO 的核心价值，不是贴在监控大屏上的数字，而是反向塑造架构：
推理时延超预算，就要拆出独立的模型路由和上下文压缩层 工具成功率下降，就要在 tool gateway 层做超时隔离和重试预算 恢复时间过长，就要在状态存储层加入 checkpoint 和中断恢复机制
更进一步，审批等待时长本身也应纳入运行时 SLO。如果只强调安全，审批可能拖垮业务体验；如果只强调体验，高风险动作可能失控。两者必须在同一张 SLO 地图上被同时观察。
3.2 四类成本护栏必须前置到架构，而不是事后算账
成本失控是 Agent 上线后第二常见的失控路径，仅次于状态失控。一个最小可用的成本护栏，至少应在前置阶段就覆盖：
护栏 · 控制内容
Request Budget
控制内容单次请求预算
Tenant Budget
控制内容租户预算上限
Capability Budget
控制内容某类能力的成本配额
Retry Budget
控制内容重试与故障恢复预算
把这四类护栏前移到准入层，意味着系统在请求进入运行时之前就要回答：这一请求是否仍在该租户预算内、该类能力的配额还剩多少、重试预算是否已被消耗过半。如果准入层回答“否”，请求应直接被降级或拒绝，而不是带着不确定性进入 Agent Loop。
上线标准只回答“能不能上线”是不够的，必须同时回答“上线后能否持续被观察、被治理、被回收”。
十八、Harness 在多 Agent 场景的额外责任
前文主要按“单 Agent + 多步执行”的视角展开 Harness。生产系统一旦进入多 Agent 协作，会额外冒出一类常被低估的稳定性问题：不是模型不够强，而是 Ownership（任务所有权）不清，导致“谁在执行、谁拥有 trace、谁负责审批”在多个 Agent 之间游移。
多 Agent 的本质，不是“角色越多越强”，而是“控制权、状态和责任怎样流动”这个问题的结构化答案。
1. 三种常见 Multi-Agent 拓扑
拓扑 · 说明 · Harness 关注点
Supervisor-Worker
说明一个总控分配任务给多个执行者
Harness 关注点manager 是否成为新瓶颈、worker 边界
Router-Specialist
说明路由层把请求分发给不同 specialist
Harness 关注点路由决策是否进入 trace、specialist 权限是否被收敛
Review Loop
说明一个 Agent 执行，一个 Agent 审核
Harness 关注点审核是否真在执行前生效，而不是事后补救
Swarm / Mesh
说明多个 Agent 松散协同
Harness 关注点复杂度最高，生产极少使用
判断是否值得拆多 Agent，有一个简单问题清单：
为什么单 Agent 不够 每个 specialist 的边界是什么 失败后如何定位到底是哪一层出了问题
如果这三个问题不能被清晰回答，先不要急着拆多 Agent；更稳的做法是先优化单 Agent 的工具面、状态管理和 Trace。
2. 三种 Handoff 模式与 Ownership 五问
Handoff 指一个 Agent 把当前任务、上下文或对话控制权正式交给另一个 Agent。三种常见模式各有边界：
模式 · 特点 · 适用场景
Soft Handoff
特点只转交子任务，不转交最终答复权
适用场景manager + specialists
Full Ownership Handoff
特点对话控制权和后续决策权一起转交
适用场景客服分诊、销售接管
Artifact Handoff
特点通过结构化文件或状态对象交接
适用场景长任务、跨会话恢复
无论哪一种 Handoff，Ownership 至少必须回答五个问题：
当前由谁做最终决策 当前谁能调用哪些工具 当前谁维护主要状态 Handoff 后 trace 是延续还是分段 Approval 和 Guardrails 归谁管
缺少这五问的多 Agent 系统，几乎一定会出现：多个 Agent 都以为自己负责、specialist 共享所有工具失去边界、Handoff 事件未写进 Transcript 无法复盘。
3. Harness 在多 Agent 场景的额外责任
相比单 Agent，多 Agent 的 Harness 至少要补三件事：
第一，补“交接物”作为一等状态对象。Artifact 不应与聊天上下文混用，应包含已验证结论摘要、待人工确认问题清单、中间文件路径、输出草稿等结构化字段。长任务的稳定性，通常来自 Artifact 设计，而不是 Prompt 长度。
第二，把 Approval 责任随 Handoff 一起切换。Specialist 接管时，Approval 路由、Guardrails 边界、Trace 续接策略必须同步切换，而不是停留在上一任 Agent 的策略上。
第三，把 Trace / Transcript 设计为可跨 Agent 阅读。多 Agent 系统的最大调试成本是“不知道是哪个 Agent 在哪一步出了问题”，因此 Trace 必须保留 agent_id / ownership_segment / handoff_event 等字段，而不是只有 step_id。
4. 多 Agent 系统的常见失败模式
失败模式 · 根因 · Harness 缺失
多个 Agent 都以为自己在负责
根因Ownership 未建模
Harness 缺失没有显式记录当前 owner 与决策权
Specialist 越权调外部系统
根因Tool 边界共享
Harness 缺失没有按 specialist 收窄工具面
切换 Agent 后丢失上下文
根因Artifact 未沉淀
Harness 缺失没有结构化 handoff 交接物
Trace 读不出来到底卡在哪
根因trace 不分段
Harness 缺失缺少 ownership_segment / handoff_event
审批在 specialist 层失效
根因Approval 责任未随 Handoff
Harness 缺失Approval 路由与 Guardrails 未随 Owner 切换
5. 多 Agent 场景的最小稳定条件
每个 specialist 必须有显式边界（工具面、权限、审批） Handoff 必须生成 Artifact 并写进 Trace Ownership 必须能被外部系统在任一时刻查询到 Approval / Guardrails 责任必须随 Handoff 一起切换 评测必须能按 Agent 维度拆分，而不是只看整体分
当这些条件未满足时，多 Agent 系统不仅不会更强，反而会比单 Agent 更难治理。
十九、结论：Harness 不是附属配件，而是 Agent 的责任系统
如果说 Prompt 决定了模型怎么表达，Tool 决定了模型能做什么，那么 Harness 决定的，是这套系统是否值得被信任。
Harness 解决的不是“如何让模型更像人”，而是以下系统工程问题：
怎么防止系统越权 怎么让长任务不中途失忆 怎么在高风险节点正确暂停 怎么在人工介入后从原状态恢复 怎么把线上事故沉成长期改进资产 怎么让每一次发布都有最基本的安全底线
因此，Harness 不应被理解为“再包一层”的局部改造，而应被视为 Agent 承担真实业务责任时必须具备的运行时骨架。它同时承担边界控制、状态保持、风险中断、恢复续跑、事故审计和发布治理等职责，是 Agent 从 Demo 走向生产系统过程中最关键、也最容易被低估的一层能力。
可将本文结论概括为以下判断：
一个成熟的 Agent 系统，不仅要具备完成任务的能力，还必须具备边界清晰、可中断、可恢复、可审计、可评测和可发布的运行时治理能力。
当系统满足上述条件时，它才具备从“可演示能力”转化为“可运营能力”的基本前提。