升级协议：构建不丢失状态的智能体到人工接管流程

当客服专员收到包含原始聊天记录的 AI 到人工移交时，准备解决问题所需的平均时间为 15 分钟。专员必须在 CRM 中查找客户、查询相关订单、计算购买日期，并重新推导 AI 已经确定的内容。而当同样的移交以结构化负载（Payload）的形式到达时——包含操作历史、检索到的数据以及触发升级的确切歧义点——准备时间会缩短至 30 秒。

这种手动工作量减少 97% 的情况并非极端案例。这正是能够真正支持人工监督的升级协议，与仅仅将上下文抛给恰好在值班人员的协议之间的区别。

大多数团队将升级（Escalation）视为一种错误状态：智能体（Agent）失败了，现在需要人类来修复。这种定性恰恰导致了上述破碎的移交体验。更好的理解是，升级是一个设计好的工作流——包含序列化格式、触发条件、监督界面以及返回智能体的路径。如果其中任何一个环节出错，“人机协同”（Human-in-the-loop）将不再是安全网，而会成为让你后悔最初构建智能体的瓶颈。

何时升级：信号堆栈

幼稚的做法是设置置信度阈值。如果模型报告的置信度低于某个临界值，就进行升级。问题在于，LLM 的置信度得分通常系统性地过于乐观。最近的研究发现，GPT 执行后的智能体预测任务成功率为 73%，而实际仅为 35%；Gemini 预测为 77%，实际仅为 22%。仅依靠原始模型的置信度作为主要的升级入口，意味着在你最需要人工审核的情况下，反而会漏掉升级。

校准方法有所帮助——如温度缩放（Temperature Scaling）、集成不一致性（Ensemble Disagreement）、共形预测（Conformal Prediction）——但它们增加了复杂性，且在分布偏移（Distribution Shift）时仍然会失效。一种更稳健的方法是将置信度视为堆栈中的一个信号，而不是唯一的关卡。

在生产环境中行之有效的信号堆栈包括：

任务级信号是最可靠的。当智能体遇到来自两个工具调用的矛盾数据、缺少必要字段、或者决策涉及财务阈值或合规标记的关键词时，应触发升级。这些是确定性的检查，完全不依赖于模型的自我评估。

行为信号可以捕捉到置信度无法发现的问题。死循环（重复调用相同的 API）、范围蔓延（智能体将任务边界扩展到原始请求之外）以及链式复杂性（在三智能体流水线中，虽然单步置信度为 90%，但累积可靠性已降至 73%），这些情况即使模型对每个步骤都报告高置信度，也值得升级。

集成不一致性虽然昂贵，但在高风险决策中非常强大。在相同的上下文中运行两个模型评估；如果它们的分歧很大，则进行升级，而不是随意选择其中一个。

一个重要的运营约束是：升级率超过 15-20% 将变得不可持续。如果你的信号堆栈触发范围过广，人类的时间将浪费在为低风险决策做“橡皮图章”上，而不是专注于真正的歧义。目标是将需要人工审核的案例控制在 10-15%，然后根据剩余案例的实际错误率进行微调。

一种专注于元认知（Metacognition）的架构——即在故障发生前进行预测而非在发生后检测的监控层——能显著提高任务成功率（一项研究发现基准从 76% 提升至 83%），但代价是延迟大约增加 12 倍。这是一种有意识的权衡，而非免费的午餐。

移交什么：状态序列化

移交负载（Payload）是大多数团队犯错最多的地方。他们只是将智能体的对话历史或原始工具输出进行序列化，然后就完事了。这就是“聊天记录问题”：你交给人类的是原始流，而不是决策简报。

一个设计良好的移交负载包含三个不同的层级：

操作历史记录了智能体做了什么以及为什么这么做——不仅是“调用了 CRM API”，而是“检索到了显示有 3 次退货记录的客户档案，其中 2 次被标记为违反政策”。每一步都应包括其背后的推理、检索到的数据以及该步输出的置信度。

当前上下文是人类做出决策所需的合成状态。这与操作历史不同。它是最小可行信息集：客户想做什么、智能体确定了什么、触发升级的具体歧义是什么，以及可能的解决路径有哪些。

结构化问题陈述明确了人类需要回答的问题。“客户申请 30 天退货政策的例外处理。政策文档对于订阅类商品是否符合条件存在歧义。智能体无法确定正确的分类。请决定：适用标准政策（拒绝）或准予例外（批准并记录）。”这是一个耗时 45 秒的决策。而“这是对话记录”则是一个耗时 15 分钟的研究项目。

负载格式也很重要。为你的 Schema 设置版本。包含一个 trace_id 以便将移交与完整的执行日志连接起来。使用原子检查点写入（先写入临时文件，成功后再重命名）以避免在移交过程中发生状态损坏。

一个对下游产生重大影响的架构决策是：使用有状态快照（Stateful Snapshot）还是无状态检查点（Stateless Checkpoint）。有状态快照在内存中保存完整的执行上下文，支持微秒级的恢复，但它们将恢复绑定在特定进程上，如果进程终止则会失败。无状态检查点仅序列化数据层状态，可跨进程和跨时间迁移，但恢复时需要智能体重新执行部分工作。对于大多数生产工作流，混合方案胜出：对于短时间的打断（分钟级解决的审批流）使用有状态快照，对于长时间的打断（可能需要数小时或数天的异步审批）使用无状态检查点。

监督界面

如果说序列化是升级（escalation）的后端，那么监督界面就是前端。这是团队经常掉入“聊天优先”陷阱的地方：他们之所以在对话线程中呈现交接，仅仅是因为智能体是这样交流的，而不是因为这对人类审核来说是正确的界面。

聊天记录是错误的监督媒介。它们要求审核者在脑海中重建状态。它们不显示发生了什么变化。它们没有提供批准、拒绝或修改智能体操作的控制。它们让人无法一眼看出智能体实际做了什么，而不仅仅是它说了什么。

在生产环境中有效的模式看起来更像任务管理软件，而不是聊天：

活动时间线（Activity timelines）按时间顺序显示智能体的决策，且详细程度可过滤。审核者可以查看摘要或深入了解特定步骤。每个条目都链接到它创建或修改的产物。

行动卡片（Action cards）以两阶段格式呈现建议的操作：先计划，后执行。审核者在操作发生前看到智能体的意图，可以修改参数，然后批准。执行后，他们会收到一张显示确切变化的收据。

自主级别控制（Autonomy level controls）允许操作员根据每个工作流调整智能体在暂停审核前可以做多少工作。“建议模式”显示选项但等待人类选择。“草稿模式”执行但需要确认。“执行模式”自主运行，仅在定义的检查点设置审核关口。不同的工作流需要不同的级别 —— 一个安排日历邀请的智能体需要的监督比一个发送客户邮件的智能体要少。

对于多智能体系统，显示每个智能体的范围、工具和权限的 角色卡片 变得至关重要。当智能体 B 向人类升级时，审核者需要知道他们正在审核系统的哪个子集，而不是整个编排图。

上下文转移原则也适用于界面级别：只呈现与当前决策相关的信息。置信度分数、内部工具参数和原始 API 响应属于审计日志，而不是审批界面。审核者应该看到决策框架，而不是实现细节。

回归路径

升级设计中被忽视的一半是恢复（resumption）。将状态传给人类是一个问题；在保持连续性完好的情况下将任务交还给智能体则是另一个问题。

像 LangGraph 等框架中的核心模式是 中断/恢复循环：智能体到达一个定义的检查点，执行暂停，人类进行审核和响应，智能体从该检查点恢复，并融入人类的输入。关键的实现细节是，恢复是重新运行暂停的节点，而不是之前的节点 —— 智能体不会重新执行已经完成的工作。

为了使这种模式可靠运行，恢复触发器必须是显式的。智能体不应从一条新消息中推断交接已解决。回归路径应包含结构化信号：批准事件、带有原因的拒绝事件，或者覆盖智能体原始意图的修改参数事件。无状态检查点系统需要在智能体恢复之前，将人类的响应包含在检查点数据中。

连续性故障最常以三种方式发生：

上下文丢失（Context loss）发生在智能体恢复但未将人类决策纳入后续推理时。人类批准了一项政策例外，但智能体的下一个工具调用仍然检索标准政策。当恢复只是重新注入原始任务上下文而没有人类的处理结果时，就会发生这种情况。

依赖中断（Dependency breaks）发生在多步工作流中，当一个暂停的操作阻塞了其他不依赖它的操作时。一个设计良好的系统应该允许独立分支继续执行，而单个步骤则等待人类审核，而不是冻结整个管道。

会话过期（Session expiration）是异步升级问题。如果人类在 48 小时内没有响应，智能体需要一个定义的后备方案：默认操作、升级给二级审核员或中止任务并发送通知。这些都不应该是意外。SLA 行为应该在工作流定义中明确，而不是导致神秘故障的隐含超时。

交接 + 恢复模式要求从一开始就考虑恢复，而不是事后才想。具体而言：每个改变状态的工具调用都应该是幂等的（或跟踪其是否已被执行），每个暂停点都应捕获足够的状态，以便新的智能体实例可以在没有原始进程的情况下恢复，并且每个升级流程都应在你遇到第一个生产事故之前明确定义回归路径。

监管压力

对于在受监管行业中构建产品的团队来说，这已不再是可选的工程实践。《欧盟人工智能法案》（EU AI Act）对高风险人工智能系统的要求规定了三种监督模式：回溯性（发生了什么）、实时性（正在发生什么）和持续性（模式级监控）。带有记录在册的工具目录和政策绑定的版本化运行时状态、自动化行为偏移检测以及可审计的决策轨迹都是合规要求，而不仅仅是工程最佳实践。

运营上的含义是：如果你的智能体行为变化是不可追踪的 —— 如果你无法识别它何时开始做出不同的决策并重建原因 —— 你就无法满足这些要求。这意味着升级设计也是审计设计。支持人类恢复的检查点数据，与支持监管审查的数据是同一套。

为故障模式而设计

在生产环境中，最常重复出现的三种故障模式：

循环交接 (Circular handoffs) 发生在智能体 A 上报给智能体 B，B 上报给 C，而 C 又重新上报回 A 的时候。多智能体系统需要显式的循环检测：在每次上报的数据载荷中跟踪交接链，如果任务回到了之前处理过该任务的智能体，则将其路由给人工处理。

上下文污染 (Context contamination) 发生在人工错误地修改了智能体状态 —— 例如根据误读的上下文批准了某项操作、在审批表单中输入了格式错误的数据，或者选择了错误的解决路径。智能体随后带着错误的输入恢复运行，并发生静默失败。防御措施：在恢复运行时进行验证，而不只是在递交上报时。在智能体继续运行之前，检查人工提供的状态在内部是否一致。

过度自信的不上报 (Overconfident non-escalation) 是最难检测的，因为没有任何可以观察到的迹象 —— 智能体在应该上报的时候没有上报。其信号表现为下游失败、客户投诉或事后审计发现智能体做出了不应自主做出的决策。防御措施是监控上报率随时间的变化；如果你的上报率意外下降，请调查是你的智能体变得更强大了，还是你的信号堆栈发生了静默降级。

上报协议归根结底是你的自主系统与需要信任它的人类之间的一份契约。序列化出错会浪费审核人员的时间。阈值设定错误，要么会让审核人员不堪重负，要么会错过关键案例。返回路径出错，则会在恢复任务的时刻丢失任务的连续性。每一个都是可以解决的工程问题，但前提是你必须将上报视为一等公民 (first-class) 工作流，而不仅仅是一种回退状态 (fallback state)。