“转人工”不是机器人失败后的补救按钮，而是一条应被提前设计的服务路径。转得太早，人工坐席被简单问题占满；转得太晚，用户已经重复三遍信息，还要重新讲一次。

真正难的不是列一张关键词表，而是让系统在每一轮都能回答：这件事还能安全、清楚地继续自动处理吗？如果不能，转交给谁，带什么上下文，用户还需要重复什么？

目录

• 把转人工分成强制与酌情两类
• 四个必须立刻升级的信号
• 多次失败怎样避免机械计数
• 一个可测试的决策函数
• 交接包比“正在转接”更重要
• 不要把边界写成宣传语

把转人工分成强制与酌情两类

强制转人工由风险决定：用户明确要求人工、涉及高风险或敏感事项、系统权限不足、关键身份或金额无法可靠确认。酌情转人工由体验决定：同一目标已经多轮失败、用户明显需要跨系统协调、自动流程无法给出下一步。

两者不能混成一个“置信度阈值”。前者即使识别置信度很高也该转；后者则需要结合上下文，避免一处口误就中断流程。

四个必须立刻升级的信号

1. 用户清楚表达“转人工”“找客服”“不要机器人”。
2. 处理对象涉及投诉升级、资金、身份核验、重大权益或其他由业务与法务定义的高风险事项。
3. 当前机器人没有权限执行用户需要的动作，或无法准确说明权限边界。
4. 关键字段连续核验失败，继续猜测会带来错误订单、错误地址或错误承诺。

对敏感事项，产品应先由业务、合规和客服团队定义具体清单；系统只执行已经确认的边界，而不是自行判断法律结论。

多次失败怎样避免机械计数

“失败两次就转”看似简单，却会误伤用户只是纠正一次口误的情况。更好的做法是只累计同一任务、同一关键字段上的失败，并区分识别失败、工具调用失败与用户否定答案。用户改变目标后，旧计数应清零或降权。

例如地址确认失败两次且 ASR 质量低，可以转人工；查物流时一次接口超时，则可以明确告知正在重试，不必假装理解失败。

一个可测试的决策函数

def decide_handoff(user_requested_human, risk_level, key_field_failures,
                   permission_available, task_changed=False):
    if user_requested_human:
        return "handoff", "user_request"
    if risk_level == "high" or not permission_available:
        return "handoff", "risk_or_permission"
    failures = 0 if task_changed else key_field_failures
    if failures >= 2:
        return "handoff", "repeated_key_field_failure"
    return "continue", "safe_to_continue"

生产系统还需要记录规则版本和触发证据，避免出现“为什么给这个用户转了人工却查不到原因”。

交接包比“正在转接”更重要

转交时至少带上：用户目标、已核验字段、未解决字段、失败类型、已执行工具与结果、风险标记、最近几轮摘要。不要把原始整段录音当作默认交接内容；按最小必要原则提供坐席完成任务所需的信息。

用户侧的提示也应具体：说明正在转给何种支持、已保留哪些信息、还可能需要确认什么。这样人工接手才是服务连续性，而不是重新开始。

不要把边界写成宣传语

一套好的转人工机制不会承诺“永不出错”。它把高风险、无权限和反复失败明确地交给更合适的人，并把已知上下文交完整。对 Voice Agent 来说，这不是能力退让，而是可靠服务的一部分。