人工升级
当智能体检测到自身无能为力时（置信度低、重复失败、存在歧义或敏感情况），将整个任务移交给人类，并传递完整的上下文，以便人员无需重新调查即可接管。与暂停单个操作以等待签字批准的审批关卡不同，升级会转移所有权，使智能体停止主导。难点在于校准触发器，以避免过度升级和升级不足。
问题
自主智能体不可避免地会遇到其无法妥善处理的情况：超出其训练分布的输入、持续无法满足的请求、真正模糊的目标，或者在情感和法律上敏感的时刻。如果它仍然强行推进，就会产生看似自信却错误的答案、陷入死循环或采取有害的操作，而用户发现失败时为时已晚。然而，将所有事情都路由给人类又违背了自动化的初衷，并会让员工不堪重负。系统需要一种规范的方法来识别其能力的边界，并在造成损害之前转移任务。
适用场景
只要智能体在进行具有实质自主性的操作，且错误结果的成本超过人类快速浏览的成本，就可以使用此模式：例如客户支持、索赔和案件处理、财务或医疗分诊、内容审核以及运营 Copilot。它假设存在人工队列或值班机制来接收升级，并且智能体能够观察到有关自身表现的信号。当失败是隐性的时候（即看似自信却错误的答案比没有答案更糟糕），以及已知某些子集案例属于困难、罕见或受监管的情况时，该模式最具价值。
解决方案
定义明确的升级触发器，并将其作为一等公民（first-class）退出条件接入智能体的主循环中，而不是事后补救。常见的触发器包括置信度低于阈值（来自模型评分、自我批判或验证器）、死循环或重复失败检测（智能体在没有进展的情况下重试同一步骤）、结构性歧义（对目标有多种有效解释）以及敏感性信号（负面情绪、安全关键词、高价值账户或受监管的主题）。每个触发器都应映射到一个路由决策：路由给哪个人员或团队，以及具有什么优先级。将阈值视为由团队拥有的可调参数，并根据实际结果进行审查，因为它们体现了自动化率与错误率之间的权衡。\n\n当触发器激活时，智能体必须执行干净的交接：停止操作，打包完整的上下文——原始请求、尝试过的操作、中间结果、当前的最佳猜测以及升级原因——并通过工单或实时交接将其路由到正确的队列。接收的人员应该能够直接接管，而无需从头开始重新调查；上下文的质量决定了升级是真正提供帮助，还是像一次搞砸的交接。始终向终端用户提供友好的回退消息（“我正在为您引入专家”），以便体验平稳降级。最后，记录每次升级及其触发器和解决结果，以便衡量其合理性并重新调整触发器。
组件
优势
- 棘手的案例会在智能体产生看似自信却错误的结果之前到达人类手中，从而限制了错误的影响范围。
- 仅将真正困难的案例进行交接，从而使常规工作保持自动化，让员工专注于需要判断力的事务。
- 带有上下文的清晰交接意味着用户能得到切实帮助，而不是被推诿，且人工客服可以直接继续处理而无需重新开始。
- 记录在案的触发因素和解决方案提供了监管机构和风险所有者所期望的证据链，以实现有意义的人工监督。
风险
- 阈值设置过于保守会将简单的案例推给人工，从而抹杀自动化带来的收益，并使员工淹没在噪音中。
- 阈值设置过于宽松会导致智能体强行处理本应交接的案例，从而引发隐性的不良后果。
- 如果传递的数据（payload）过于单薄，人工人员就必须从头开始重新调查，这会让升级感觉像是被丢弃的任务，而不是协助。
- 模型的置信度往往与实际准确率不一致，因此简单的分数阈值会导致双向的错误升级。
不适用场景
- 如果没有配备人员的队列或值班功能来接管，升级将无处可去；此时应转而投资于安全停止或恢复路径。
- 当您只需要对某个特定的高影响步骤进行审批，而智能体仍保留该任务时，请使用人工审批关卡，而不是完全转移所有权。
- 对于成本低、易于逆转且错误答案无需付出代价的任务，升级带来的开销和延迟将大于其收益。
技术
示例
- 支持智能体负责解答常规问题，但在检测到用户沮丧情绪、重复出现无用回答或涉及账户敏感的请求时，会升级到人工队列，并传递完整的对话内容。
- 保险智能体自动处理明确的理赔，并将含糊不清、高价值或标记为欺诈的理赔升级给理赔员，并附带其调查结果和原因。
- 自主编码智能体在重复失败于同一个测试时会停止运行，总结已尝试的操作和受阻的位置，并将任务移交给工程师，而不是无休止地无效循环。
KPI
- 升级率
- 移交给人工的任务比例。应关注趋势和分布，而不是单一的目标数值——突然的飙升或下降表明触发器校准有误或输入组合发生了变化。
- 升级合理性
- 在升级的案例中，有多少是真正需要人工处理的（真阳性），有多少是本可以自动处理的。对升级案例进行人工抽样审查是最可靠的评估方式。
- 漏升级率
- 在自动解决的案例中，事后证明有多少是错误的且本应升级的。这是最难也最重要的信号；可通过挖掘投诉、重新打开的工单和审计来发现它们。
- 交接上下文充分性
- 接收人员在无需重新联系用户或重新调查的情况下即可接管工作的频率。通过人工对交接包是否完整提供的反馈来进行跟踪。
已观测到的失效模式
- 一次性调优后便不再维护的触发器会随着输入和模型的改变而脱节，从而在无形中打破自动化与错误之间的平衡。
- 案例被路由到无人负责或已超负荷的队列中，导致升级的用户无限期等待——这比得到错误的答案还要糟糕。
- 为了避免升级而进行优化的智能体会学会表达虚假的置信度，从而抑制了该模式所依赖的关键信号。
- 交接过程丢失了格式、中间推理或附件，迫使人工重新构建场景，从而抹杀了速度优势。
经验教训
- 在根据置信度信号设置阈值之前，先验证其是否与实际准确率相关；将模型评分与验证器或自我批判相结合。
- 好升级与坏升级之间的区别几乎完全取决于交接的数据（payload）；在调整阈值之前，应先在这方面进行投入。
- 将阈值视为动态参数，根据抽样的升级和漏升级案例进行审查，由团队共同维护，而不是在发布后便一成不变。
- 即使是完美的触发器有时也会失效；友好的等待提示和专人负责的队列可以防止失败演变成用户流失。
常见问题
- 这与人工审批关卡有什么不同？
- 审批关卡会暂停某个特定的高影响操作，并要求人工进行审批，通过后智能体继续执行。而升级则会转移整个任务的所有权——智能体停止主导，因为它根本不应该继续进行。对于“我是否应该做这一件事？”使用关卡；对于“我无能为力了，请接管”，则使用升级。
- 合适的升级率是多少？
- 没有一个通用的数值；这取决于任务难度的组合和错误的成本。应针对合理性进行优化，而不是针对目标率：将真正需要人工的案例进行升级，并尽量减少不必要的交接和漏升级。将升级率视为校准失误的信号，而不是其本身的目标。
- 我可以在模型置信度低时直接进行升级吗？
- 这是一个有用的触发因素，但仅凭这一点很少足够，因为模型的自我置信度往往与实际准确率不一致。应将其与循环检测、歧义检查和敏感性信号相结合，并在信任某个阈值之前，先验证您的置信度度量是否确实与正确的结果相关。