评测与工程
转人工与生成可核对的通话摘要
确认人工真正接管，再把有来源的摘要交给业务系统。
先做什么
转接需要四类确认：队列接受、上下文到达、人工接听以及话权移交。只收到转接信令成功，还不能向用户宣告坐席已经接管。
理解这条链路
转接请求排队确认上下文交接人工接听话权移交来源化摘要业务回执
AI 何时停止说话
排队中 AI 可以提供已确认的信息，但人工真正接听后应切换话权并清空旧语音。转接失败要明确返回可服务状态，防止双方都以为对方正在服务。重复转接请求使用同一业务幂等键，避免产生多个队列项目。
摘要由可核对的陈述构成
每条摘要事实绑定转写片段或业务回执，区分用户诉求、已执行动作和未解决问题。坐席建议作为可拒绝草稿；修改客户记录、承诺赔偿等动作按业务权限执行。重要数字使用原始来源校验，模型置信度不能替代核对。
按这个顺序操作
- 定义转接状态及每步确认的系统来源，设置失败和超时回退。
- 发送最小必要上下文：诉求、已核实信息、已完成动作与未确认事项。
- 用排队满、无人接听、坐席拒接、重复请求和用户挂断做流程回归。
- 生成可点击回源的摘要草稿，审核后幂等写入 CRM 并验证回执。
配套本地工具
以下工具位于 AI 学习工作区。先阅读对应说明，确认所需数据与依赖；本轮未重新运行这些实验。
- human-handoff-ops-bench/README.md
可直接复用的记录模板
handoff_id / queue_ack / context_ack / human_answered / ownership_ack 用户诉求： 已确认事实（附 source_span）： 已执行动作（附 operation_receipt）： 尚未解决： 摘要状态：DRAFT / REVIEWED / WRITTEN 写入幂等键与失败回退：
做到什么程度才算通过
- 人工接听与话权切换分别确认。
- 转接失败不会留下无人服务状态。
- 摘要事实均能回源。
- CRM 重试不会生成重复记录。
当前证据的限制
既有基准为模拟控制状态，未连接真实坐席或 CRM；本轮没有重新测转接成功率。
本轮确认的事实与来源
以下为公开资料支持的具体结论；操作流程和验收建议属于工程推导。仓库说明或厂商效果表述不等于独立实测。
[1] IETF RFC 5589 · SIP 呼叫转移
RFC 5589 描述基于 SIP REFER/NOTIFY 等机制的呼叫转移流程，并讨论转接失败的恢复灵活性。SIP 流程不是坐席业务状态的全部。
资料日期：2009-06 · 复核：2026-09-08
阅读原始来源 ↗[2] OpenAI · Function calling
工具调用流程要求应用实际执行并回传结果；通话后 CRM 写入也需要独立的执行与回执，而不是把模型文本当写入结果。
资料日期：页面未统一标注；以复核日期为准 · 复核：2026-09-08
阅读原始来源 ↗这次更新了什么
压缩平台罗列，保留四类转接确认、事实来源与幂等写入流程。
合并前的内容入口
以下旧地址仍可访问，并会带你来到本篇。完整重构前材料已留存本地备份。
- research-hub/human-handoff-assist-postcall.html