升级与温转接

在来电者开口之前就升级——过度坚持才是失败模式。

一个被训练去完成任务的智能体，会一直试到早该由人接手的那一点之后，因为对一个以"解决"为优化目标的模型来说，"放弃"看起来像失败。在语音里这比在聊天里更糟：来电者没法往下略读、也没法开第二个标签页，所以每一轮浪费都是一个人耐心的真实秒数。升级这个决定是一个产品决定、不是事后补丁，而且它该在"明确请求"之外的多种情形上触发：

• 任务置信度低。智能体不确定自己能解决这个意图——趁来电者还平静时交接，而不是等三次尝试失败之后。
• 多轮没有进展。两三轮没把任务往前推，就是一个循环；把它计数、跳出来。这是 voice-failure-modes 里那个失控循环的语音版。
• 检测到不满。上升的情绪信号、打断、反复换说法——把这些当作一个升级触发，而不只是遥测。
• 超出范围或高风险意图。任何策略保留给人工的事项（争议、超过阈值的取消、脆弱来电者信号）一见即升级，符合 human-in-the-loop 里的最小权限那条线。
• 明确的请求。当来电者要求找人，争论就结束了。绝不让来电者问第二次，也绝不把第二次请求又送回同一个失败流程里。

刻意挑选转接形态；温转接成为默认是有原因的。

有三种形态，它们之间的差别完全在于来电者在那道接缝处经历了什么：

• 冷转接。智能体把来电者甩到一个人工或一个队列上，什么也没附带。搭起来快，也正是客户痛恨电话树的原因——人工从零开始，代价由来电者来付。把它留给真正的最后手段（上下文系统宕了，替代方案是直接掉线）。
• 温转接。来电者短暂等待，人工在此期间接收上下文——一个屏幕弹窗、一段耳语简报，或两者兼有——然后已带着状况上线。任何要紧的事都以此为默认，因为这是唯一一种"让来电者的等待换回了点东西"的形态。
• 受监督交接。智能体作为一个沉默的参与者留在线上，随时可取数据，或在人工把通话交还时接手。对复杂账户有用，也可用真实升级来训练智能体，代价是每通电话占一个在线坐席。

接缝正是温转接成败之处：来电者等待时听到什么（品牌化的等待提示，或一句"正在把您转给 Maria，我们刚谈的一切她都看得到"）、这段等待允许持续多久，以及来电者能否在此期间插话。这里的插话处理遵循与 turn-taking-and-barge-in 里"轮次中途被打断"相同的规则——一个在等待中开口的来电者绝不能被无视。

上下文包才是真正的交付物。

其余一切都是管道；这一项才是产品。人工必须在向来电者问候之前收到、并已读过一个紧凑的包——否则他就会即兴发挥，来电者也就会重复自己。这个包携带：

• 已验证的身份与鉴权等级。caller-authentication 已经确立的一切随转接一起走。让一个已鉴权的来电者对人工重新验证一遍，是所有重复里最令人恼火、也最无可辩解的。
• 用来电者自己原话陈述的意图。引用那句请求；不要把它意译成一个类别。读到"想对 14 号那笔 240 美元的扣款提出争议"的人工，比读到"账单问题"的人工领先三步。
• 已经采取的动作及其副作用。智能体做了什么、改了什么，尤其是任何人工绝不能重跑的冻结、待写入或半截交易——这是 voice-tooling-and-state 里那本副作用账本，跨过接缝递了过去。
• 升级的原因。"来电者在两次退款尝试失败后感到沮丧"告诉人工该怎么开口；"升级"什么也没告诉他。

时机是规格的一部分：这个包必须在人工的第一个字之前送达并可读。一个在"你好"之后才到的屏幕弹窗已经失败了，因为人工已经押上了一句建立在虚无之上的开场白。

给转接自己的延迟预算，以及一条"没有人工"的分支。

交接不是瞬时的，而它的延迟在智能体自己的 latency-budget 里是不可见的，因为它住在电话层：找到一个有空、且技能匹配的人工、执行 SIP/PSTN 转接、递交简报。要显式地为它做预算，因为转接期间的死寂会被读成掉线：

• 填满等待，并给它设界。告诉来电者正在发生什么，并给等待一个上限。上限触发时，别把他撂在半空。
• 先设计"没有人工可用"的分支，而不是最后才想到它。用一个诚实的等待估计排队、提供一个能保住上下文包的预约回拨，或退回到一个装着同一个包的工单——什么都行，就是不能把来电者撂在一个永不完成的转接里。这整页最有破坏力的结局，就是那个等了半天却一个人也没等到的来电者。
• 让转接幂等。一次重试或重复触发的转接，绝不能生出两个会话或两个工单。带上一个转接 id，让电话侧与 CRM 侧能去重，呼应 telephony-and-pstn-integration 里的那套纪律。

只因循环里有个 AI 才存在的那些失败模式。

一次人对人的温转接有已知风险；插进一个智能体又添了四个，而每一个都比它本想改进的那个冷转接更糟：

• 夸大其词的摘要。一份幻觉出来的、或自信地错了的简报，比没有简报更危险，因为人工信了它、并据此行动。引用来电者与记录系统；把任何智能体推断出来的东西标为推断；绝不让一份生成的摘要断言一件对话记录并不支持的事实。
• 接缝处丢了上下文。包建好了，却在从语音平台跨到 CRM 或坐席桌面时丢了，人工于是悄无声息地退回到零。把"送达"当作要去确认、而不是去假设的事——如果包没到，人工应当知道自己是在盲飞。
• 转接循环。人工把来电者弹回给智能体，智能体又一次升级，来电者被来回踢。给跳数封顶、记录每一跳，并把一个被再次升级的通话路由给一位主管，绝不送回那个已经失败过的流程。
• 合规状态在转接中丢失。录音同意、披露状态与任何监管标记都必须挺过交接。一通开始时合规的电话，不能因为状态留在了接缝的智能体那一侧而变得不合规。

衡量重复，而不是转接。

转接成功率在这里是虚荣指标——它数的是"接通"，而那恰恰是从来不难的那部分。真正描述交接是否服务了来电者的数字是：

• 重复率。来电者有没有对人工把身份或问题重讲一遍？这是唯一一个能抓住"上下文包有没有干成它的活"的数字；把它往零里压。
• 升级的查准率与查全率。在本该升级的电话里，有多少升级了、又升级得多早——以及在升级了的电话里，有多少确实需要人工。一个抓着不放太久的智能体和一个把每通电话都甩出去的智能体，都在失败，只是方向相反。
• 到人工的时长，以及转接中的放弃。接缝持续多久，以及多少来电者在其中挂断——这直接衡量你那条"没有人工"的分支有没有在干活。
• 转接后解决率与二次升级。人工解决了吗，有没有电话又绕了回来？把这些喂进 evaluating-voice-agents，好让升级策略是按结果、而不是按直觉来调的。