语音智能体转人工的十五项上线验收

AI 电话客服能自然对话、快速响应、调用转接工具，仍然可能把客户送进无人接听的队列。作者提出的上线标准更具体：真人是否真正接起电话，拿到必要信息，并继续处理问题；如果没接通，系统是否创建了能追踪的后续任务。

这篇最有用的内容是一套验收思路，而不是供应商排名。它把「听起来完成了」拆成可以查证的状态，适合正在接入语音 Agent、电话队列和 CRM 的团队。但原文没有提供实测成功率，输入中也缺少完整的 15 场景矩阵，不能直接当作现成测试集。

转接工具返回成功，为什么还不能算成功

一次电话转接会经过多个系统：Agent 发出请求，电话系统接受路由，目标号码响铃，真人接听，音频桥接，上下文送达。任何一步成功，都不能自动代表后面完成。

「发起转接」只能计为尝试，「真人接听且能继续处理」才算完成交接。

作者要求至少区分四类结果：Agent 完成允许的任务、人工交接完成、安全兜底、状态未知。掉线、客户放弃、无人接听，都不能混进成功率。回拨也必须真正创建任务，而不是只说一句「稍后联系您」。

统计分母同样重要。原文举例：20 通符合条件的电话，8 通请求人工，6 通确认交接，那么：

• 按转接请求计算，成功比例是 75%。
• 按符合条件的全部来电计算，比例是 30%。

这些数字只是算术示例，不是实验结果。即便是那 6 通，也仍要检查上下文是否送达、客户是否被迫重述问题。

下面这段原始状态机说明了「完成交接」和「安全兜底」的不同路径：

stateDiagram-v2
    [*] --> ActiveCall
    ActiveCall --> AgentResolved: verified allowed action
    ActiveCall --> TransferRequested: person needed or requested
    TransferRequested --> DestinationRinging: downstream accepts route
    DestinationRinging --> HumanAnswered: answer event confirmed
    HumanAnswered --> ContextChecked: summary delivered and reviewed
    ContextChecked --> HandoffComplete: call connected and context adequate
    DestinationRinging --> NoAnswer: timeout or unavailable
    TransferRequested --> TransferFailed: error or disconnect
    NoAnswer --> FallbackOffered: accurate status told to caller
    FallbackOffered --> CallbackCreated: caller accepts, task ID returned
    FallbackOffered --> AlternateRoute: caller selects another option
    CallbackCreated --> SafeFallback
    AlternateRoute --> SafeFallback
    TransferFailed --> SafeFallback: recovery path actually created
    TransferFailed --> Unknown: no reliable downstream event
    AgentResolved --> [*]
    HandoffComplete --> [*]
    SafeFallback --> [*]
    Unknown --> [*]

要看的是 HumanAnswered --> ContextChecked：接听之后还有上下文检查，不能直接跳到完成。如果供应商只给一个成功布尔值，就需要追问它由哪个组件、什么事件触发，以及桥接后掉线会不会仍然保留成功状态。

验收要固定哪些条件，才能复现问题

作者于 2026 年 10 月 23 日设计了 15 类验收场景。它们不是 15 位真实客户，也不提供统计置信保证。建议每类先在测试号码跑两次，再进入经过同意的小规模试点。

但当前输入没有出现完整场景表，只留下 H04 的信息纠正、H05 的固定时点打断、H08 的无人接听等线索。不能据此补造其余案例。

测试首先要冻结配置：提示词或流程版本、语音模型、运营商线路、转接模式、队列、营业时间、CRM 连接、兜底行为和录音设置。演示号码与生产号码的线路不同，演示通过就不能作为生产验收证据。

其次，拨号前写好预期状态。H08 的示例是：

transfer_requested -> destination_ringing -> no_answer -> callback_offer -> callback_created

如果客户拒绝回拨，则记录拒绝并提供其他可用路径。两种结局都不是人工交接成功。

测试还必须听两端。客户听到等待音乐，并不能证明接收人员听清了声音、看到了摘要，或者原始来电号码得以保留。原文引用的 Retell 社区案例发生在 2026 年 7 月，报告冷转接后音质下降；它只能证明存在这种故障，不能说明发生频率。Assistable 在 2026 年 6 月的演示展示了转接体验，但明确没有单独呈现接收人的私下简报音频。

验收应分别判定路由正确性、上下文充分性、客户重复陈述、音频可懂度、兜底正确性和副作用控制。证据不足就记为 unknown，不能判通过。平台、运营商和 CRM 的时钟若无法对齐，也不要据此宣称亚秒级延迟。

日志能查出矛盾，但不能替你证明服务完成

每通测试电话至少应留下匿名测试 ID、配置版本、场景 ID、转接请求时间、目标队列状态、接听与桥接确认、上下文送达状态、兜底记录 ID、结束原因和评审结论。

原文给出的 JSON Lines 记录展示了无人接听后成功创建回拨任务的情况：

{"case_id":"H08","transfer_requested":true,"destination_answered":false,"context_delivered":false,"outcome":"callback_created","callback_id":"TEST-001","transfer_counted_success":false}

这里最关键的是 transfer_counted_success:false：回拨任务创建成功，不等于转接成功。

作者还提供了 handoff_audit.py，运行命令为 python handoff_audit.py calls.jsonl。它检查成功记录是否缺少请求、接听或上下文确认，是否把 unknown、dropped、no_answer 算成成功，以及 callback_created 是否没有 callback_id。

这是日志一致性检查器。它不能判断接收人是否合适、摘要是否有用，也不能证明合规。更关键的是，destination_answered 和 context_delivered 必须有可信事件或人工评审支持；如果只是从 Agent 自述中推断，程序可能验证通过一段虚构叙事。

上下文也不宜整段倾倒。真人需要的是客户诉求、必要且已确认的身份信息、已尝试操作、未解决事项、紧急程度，以及事实来源和时间。客户确认与模型推断要分开。被打断的发言尤其不能按模型原计划输出的内容记账。

我的判断

我认同作者把「可核验结果」放在语音表现之前。对于电话业务，流畅回答只是入口，队列、音频桥接和 CRM 写入才决定交接能否成立。原文建议将故障定位到识别、模型决策、工具、队列、运营商、媒体桥接、上下文或 CRM，也比反复修改提示词更有操作价值。

但这套协议没有给出自身的对照实验，不能据此宣称它提高了多少可靠性。

作者对外部证据的限制交代得比较清楚。Cekura 测试了 9 个生产 Agent，以 10 类条件动作场景各重复 3 次，共 270 通电话；最快响应与最快停止说话并非同一指标。VAmoS Bench 首版聚焦金融服务模拟。AFRC–IPAG 的材料来自 14 次大型法国企业访谈，其中一个例子在客户要求人工或两次尝试失败后转接。这些材料能启发测试设计，不能直接预测小团队表现。

同样，PwC 的收益描述是早期预测，Microsoft 的建议是产品指导。Search Console 在 2026 年 10 月 13—20 日记录的 9 次展示、平均排名 9.6，只属于一个页面和七天窗口，与交接质量无关。

还有两个边界。第一，要求客户随时转人工，要以实际有人接听和存在兜底渠道为前提。第二，原文引用 CNIL 2026 年建议中的录音活跃使用最长六个月、分析文档中间存储最长一年，范围涉及工作电话和员工相关处理，不能照搬为国内客户录音规则。输入末尾关于「沉默不等于同意」的段落也已截断，无法补全作者具体要求。

能拿来做什么

1. 接入电话 Agent 时，先让后端分别记录请求、响铃、接听、桥接、上下文送达和结束事件，再让前端展示对应状态；不要把工具返回成功直接显示成「人工已接入」。
2. 将无人接听、用户纠正信息、固定时点打断做成可重复的验收脚本，固定线路和配置版本，并核对接收人员真正拿到的信息。
3. 在 Node 服务或现有日志流水线里加入与原文相同的一致性检查：没有接听证据不得计为交接成功，没有任务 ID 不得标记回拨已创建，同时保留 unknown。
4. 试点阶段单独复查失败、未知、升级和客户放弃的电话；更换运营商线路或转接实现后，重跑相关场景，不沿用旧配置的通过结论。