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

当客服专员收到包含原始聊天记录的 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）的后端，那么监督界面就是前端。这是团队经常掉入“聊天优先”陷阱的地方：他们之所以在对话线程中呈现交接，仅仅是因为智能体是这样交流的，而不是因为这对人类审核来说是正确的界面。

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

加载中…