什么时候停下来找人

一句话理解：好的 Agent 知道什么时候该停：重试到上限、证据不足、风险越线或规则冲突时，带着完整上下文把问题交给合适的人，而不是硬着头皮做下去，也不是悄无声息地失败。

Agent 在“找人”这件事上有两种典型的失败。一种是过于执着：日志接口连续超时，它换着花样重试了几十次，花掉一大笔 Token，最后编了个结论交差。另一种是过于胆怯：一点小事都弹窗确认，用户觉得“还不如我自己做”，很快弃用。

升级（Escalation）设计要在这两者之间找平衡：什么情况必须停，停下来之后交给谁、交什么，人处理完之后 Agent 怎么接着做。审批、确认、接管这些交互模式本身，见 Human-in-the-loop；这一课聚焦“触发条件”和“交接内容”。

四类升级触发条件

触发类别	含义	工单处理 Agent 的例子	可配置的参数（示例）
失败超过上限	重试、步数或预算达到上限，仍未完成	日志接口连续 3 次超时；任务已执行 25 步仍未得出结论	单工具重试次数、同类错误次数、最大步数、单任务预算
证据不足	关键数据缺失，或验证结果为“无法判断”	缺少关联订单，无法判断责任方	必需字段列表、缺失时的处理方式
风险越线	动作敏感、不可逆或金额超过阈值	建议退款金额超过 500 元；要取消订单	金额阈值、不可逆动作清单
规则冲突或超出范围	规则互相矛盾、没有覆盖，或请求超出 Agent 职责	企业客户同时命中“自动退款”和“人工审批”两条规则	冲突检测、职责范围定义

此外，用户主动要求转人工永远应该被立即满足。

把这些条件放在一起，就是每一步执行后都要过一遍的升级检查：

图 1 · 升级检查由 Harness 强制执行：任一条件命中就停下，按类别路由给能处理的人

这些触发条件在一手资料中也有对应。OpenAI 的《A practical guide to building agents》把需要人工介入的情况归纳为两类：超过失败阈值（例如多次尝试仍无法理解客户意图），以及高风险动作（敏感、不可逆或影响重大的动作，例如取消订单、大额退款、付款）。Anthropic 的《Building effective agents》也提到，Agent 可以在检查点或遇到阻碍时暂停，等待人的反馈，并通过最大迭代次数等停止条件保持可控。步数与预算上限的设计细节见停止条件，高风险动作的分级见操作分级。

置信度：不要直接相信模型报的数字

“置信度低于 0.8 就转人工”是很自然的想法。问题在于，如果这个 0.8 是让模型自己在输出里写的，你并不知道它是否经过校准：模型说 0.9 的结论，真实正确率可能远低于 90%。

更可靠的做法，是用可观测的信号合成置信度判断：

信号	怎么获取	说明
证据完整度	程序检查必需字段是否都已拿到	缺一个关键字段就降级为“低置信”
验证结果	上一章的验证层输出	任何关键验证“失败”或“无法判断”
多次采样一致性	同一案例独立运行 3 次，比较结论	3 次结论不一致，说明判断不稳定
规则命中情况	规则引擎返回命中规则数	命中 0 条或多条互斥规则
与历史案例的相似度	检索是否有相似的已处理案例	完全陌生的问题类型更容易出错
评审结果	模型评审是否通过	评审输出“无法判断”时视为低置信

把这些信号写成一份明确的策略，比一个模糊的“置信度阈值”更容易评审和调整（示例）：

escalation_policy:
  failures:
    per_tool_max_retries: 3
    same_error_max: 2
    max_steps: 25
    max_cost_usd: 0.50
  evidence:
    required_fields: [ticket_status, last_event_at, order_id]
    on_missing: undetermined_and_escalate
  consistency:
    samples: 3
    min_agreement: 2
  risk:
    refund_amount_gt_cny: 500
    irreversible_actions: [cancel_order, issue_refund]
  routing:
    rule_conflict: rule_owner
    environment_error: oncall_engineer
    data_missing: support_operator
    high_risk_action: team_lead

注意多次采样会成倍增加成本，一般只在高风险或高价值的任务上使用。

阈值怎么定：用评测数据调，而不是拍脑袋

阈值越严，转人工越多，自动处理中的错误越少；阈值越松，自动化率越高，但错误也越多。这个取舍不应该靠感觉，而应该在评测集上实际跑出来。

下面是在同一组 100 个客服工单案例上，比较三种升级策略的结果（示例数字）：

策略	Agent 自动给出结论	其中错误	转人工	自动结论的准确率
宽松：仅在工具连续失败时升级	95	8	5	约 92%
中等：加上关键字段缺失时升级	88	3	12	约 97%
严格：再加上 3 次采样不一致时升级	80	1	20	约 99%

把三种策略下这 100 个案例的去向画在一起，取舍一目了然：

图 2 · 同一组 100 个案例：策略越严，转人工越多，自动结论越准

怎么选？算一笔账：一次错误结论的代价（错误退款、错误追责、客户投诉）和一次人工处理的代价（人工耗时）分别是多少。如果一次错误退款的损失远高于人工处理一单的成本，中等甚至严格策略更划算；如果错误影响很小、人工又很紧张，可以选宽松。上线后再根据线上数据持续调整。指标的定义方法见指标体系。

升级不是抛异常：设计交接包

最糟糕的升级是一条“任务处理失败，请人工处理”。接手的人要从头再查一遍，Agent 做过的工作全部浪费。好的升级应该交出一份交接包，让人在一两分钟内就能做出决定（示例）：

{
  "task": "判断工单 T-20260917-0042 的问题原因并给出处置",
  "escalation_reason": "rule_conflict",
  "summary": "客户为企业客户，工单已超时 80 小时，同时命中 SOP 第 3 条（自动退款）与第 7 条（企业客户须人工审批）",
  "completed_steps": [
    { "step": "get_ticket", "verified": true },
    { "step": "get_logs", "verified": true, "finding": "最后事件 2026-09-13T22:40:00+08:00，支付回调失败" },
    { "step": "calc_delay_hours", "verified": true, "result": 80 }
  ],
  "agent_suggestion": { "action": "refund", "amount_cny": 120, "verified": false },
  "decision_needed": "是否按第 3 条自动退款 120 元？",
  "options": ["批准退款", "修改金额后批准", "拒绝并转客户经理", "我来接管"],
  "resume_from": "step_4_execute_decision"
}

一份交接包至少包含：

为什么停下来，使用固定的升级类别；
已经做了什么，以及每一步是否验证过；
Agent 的初步判断，并明确标注“未验证”，避免人被误导；
需要人做的具体决定，最好给出选项，而不是开放式问题；
恢复点：人做出决定后，Agent 从哪一步继续。这依赖任务状态与 Checkpoint。

完整流程如下：

图 3 · 升级不是终点：人做出决定后，Agent 从恢复点继续，决定本身沉淀为评测与规则素材

升级给谁也很重要：规则冲突给规则负责人，环境异常给值班工程师，数据缺失给能补数据的一线支持人员，高风险动作给有审批权的人。全部推给同一个客服队列，结果就是队列堵死。审批界面怎么设计，见审批与接管。

常见误区

升级信息只有一句“处理失败”。 人要从头再查，Agent 做过的工作全部浪费，升级的成本被放大好几倍。
用模型自报的置信度做阈值。 未经校准的数字给人一种精确的错觉。用证据完整度、验证结果、采样一致性这些可观测信号。
人处理完，流程就断了。 人批准之后 Agent 不知道，任务卡在半路。升级必须设计恢复路径。
为了追求“自动化率”而压低升级。 自动化率高但错误多，是更糟糕的产品。把自动结论的准确率和自动化率一起看。
升级规则写在 Prompt 里，靠模型自觉。 重试上限、预算上限、金额阈值应该由 Harness 强制执行，模型只负责在规则之外发现“我拿不准”。

产品经理检查清单

升级触发条件是否覆盖了失败上限、证据不足、风险越线、规则冲突与用户主动要求这五种情况？
每个阈值是否有评测数据支撑，而不是拍脑袋定的？
不同类别的升级分别路由给谁？对方有没有能力和权限处理？
交接包是否包含原因、已完成步骤、未验证的初步判断、待决策问题与选项？
人做出决定后，Agent 能否从断点继续？
每天预计有多少任务会升级？人工团队接得住吗？
人的决定是否被记录下来，用于更新规则和评测集？

练习

为「发票审核 Agent」设计一份升级策略，用 30–60 分钟完成：

列出至少 6 种应该停下来找人的情况，按四类触发条件归类（例如：发票金额超过采购单批准金额 10% 以上；验真接口连续失败；购买方名称与税号不一致等）。
为每种情况指定接手人。
选其中一种情况，写出完整的交接包 JSON，包含待决策问题和 3–4 个选项。
估算一下：如果每天审核 1000 张发票，你的策略大约会让多少张进入人工？这个量是否可以接受？

下一步

本模块讲的是单次运行里的验证与恢复。要回答“这个 Agent 整体上好不好、改完有没有变好”，需要进入下一个模块：「为什么 Agent 必须做 Evals」。

什么时候停下来找人