北京
来电者想要一个周二的预约。日历请求要跑几秒，语音助手顺势填上空白：“我帮你找到一个时间了。”可这时候，请求还在跑。对话听起来很顺，来电者却拿到了一条系统并不掌握的信息。
这正是做语音代理产品时绕不开的一道坎。公开案例记录里，呼入呼出、日历集成、预约与确认、跟进、转人工、通话记录都在其中。一通对话可能落到好几种不同的业务结果上，每一种结果都得有自己的证据。
问题在于：当代理能在请求进行中开口说话，应用就必须决定，它在每一个时点被允许说什么。否则，多出来的这点响应性，就变成了编造进度的机会。
响应更快，也带来一条设计义务
2026年10月19日，谷歌发布了一份语音代理指南，讲的是长时间运行的工具执行期间，代理如何保持响应。其中的ADK示例用流式工具在任务继续时投递中间更新。谷歌还描述了如何围绕语音来安排这些更新，并区分哪些进度值得播报、哪些工作可以安静跑完。
有个细节值得记下：阻塞式工具会让模型无法继续自己的回合。在提示词里加一句安抚来电者的话，并不能消除这个执行瓶颈。流式改变的是对话何时能恢复，它本身并不会让底层的日历或数据库更早跑完。
案例记录并没有把ADK列为它的实现方案。这份指南是当前针对该问题的工程参考，不是关于某家供应商或某种架构的证据。
把进度做成一份小数据契约
就一个排期流程而言，可以从少数几个应用事件起步：
- 请求已接受事件，允许代理说“我正在查可用时间”；
- 可用性结果事件，允许代理描述返回的时段；
- 预约已确认事件，允许代理说出订到了哪个预约；
- 通知已送达事件，只有在供应商确实提供该证据时，才支撑“确认消息已送达”这类说法。
这些只是示意状态，不是对现有内部实现的描述。要点是给每一句口头声明配一个明确的前置条件。
事件要小：操作标识、阶段、事件序号，以及该阶段已确立的事实。不要为了生成一句短更新，就把整份日历响应塞进去。后端只知道“请求已接受”和“结果可用”时，也别硬编一个百分比。诚实的等待状态本身就是有用的信息。
模型可以变换措辞，应用则应当约束可供播报的事实。这样既留出了自然对话的空间，又不必让语言模型根据流逝的时间去推断任务是否完成。
准确的更新，也可能在说出口前就过期
设想日历查询还在跑，代理已经开始下一句。应用把“我还在查”排进队列。随后完整结果到达。如果语音队列按到达顺序出队，来电者会先听到一句等待提示，紧接着就听到结果。
进度消息应当有很短的存活期，并在播放前再核对一次操作阶段。终态结果应当让同一操作下排队中的中间更新失效。几个快速接连的里程碑，可以合并成当下最有用的那一句。
这也是为什么要把观测到的状态和已播报的状态分开存。“日历返回了”和“来电者听到了可用时段”是两件事。同时记录两者的通话记录，有助于解释一段尴尬的停顿究竟来自工具、播报策略，还是音频投递。
这份记录可以只聚焦操作元数据。排查一个队列，并不自动意味着要把来电者的完整对话复制进每一份日志。
测一测来电者实际听到了什么
后端测试通过，音频体验仍可能误导人。值得测的场景包括：延迟的成功查询、空结果、超时，以及结果在早先的更新还排队待播时到达。把发出的事件和实际播报的序列一起抓下来。
有用的断言都很具体：可用性结果出现之前，不播报任何时段；预约操作返回确认之前，不把预约说成已确认；排队中的等待消息绝不在终态结果之后播出；超时要给出未决状态的解释，而不是悄悄把它变成“没有可预约时段”。
小规模合成场景让这里成为低成本的迭代场所。生成变体、检查失败、打磨事件到语音的规则。在声称某项优化省了钱之前，先在这些运行里量一量token用量和延迟。更短的更新也许有帮助，但反复重试或不必要的模型回合会把这点收益抹掉。
对小团队来说，这是可控的基础设施：几个明确的里程碑、一套队列策略、可观测的语音。它也让交接更容易——另一个开发者能清楚看到，代理为什么被允许说那句话。
语音工具越像对话，企业在慢操作期间让来电者保持知情的机会就越多。有用的标准很简单：每一句进度声明，都应当能追溯到应用真正知道的东西。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
