先明确任务与结果
把后台任务状态与播报时机分开设计：进度只描述已发生的阶段，完成必须有可验证结果；说话被打断不等于任务取消。先用有固定答案的模拟事件验证状态规则，再接入真实Live会话。
先确认官方教程的适用边界
Google官方完整教程讨论ADK中的流式工具、后台执行和结果播报调度，示例要求google-adk≥2.10.0、Gemini Enterprise上的gemini-3.8-live及双向run_live会话。它不是把普通文字提示词换成“边做边说”就能获得的能力。
官方还区分了用户插话与停止后台工具。本文以下事件、数据和参考答案均为编辑设计，没有运行Gemini账户或复现厂商延迟数字；用途是让开发者在接入前明确可验收行为。
先准备一份答案完全已知的材料
任务是“汇总试验批次Q7的已完成记录”。原始四行如下：R1数量8、已完成；R2数量12、已完成；R3数量5、待处理；R4数量9、已取消。成功条件是数量20、记录数2，并明确排除待处理与已取消。这里的数量只是合成计数，不是销售额。
给任务分配稳定编号Q7-A1。用户追问“好了没有”时应查询同一任务状态，不另起一份相同汇总。换一批输入则新建编号，不能把上一份报表的晚到结果当作新任务结果。
汇总批次Q7。输入：R1=8/已完成；R2=12/已完成；R3=5/待处理；R4=9/已取消。仅统计已完成记录。任务ID=Q7-A1。给出数量、纳入ID、排除ID及原因；收到完成事件之前不要宣布最终数字。重复询问只报告同一任务状态。用事件表验收，而不是看它是否一直说话
下表是预期状态序列。时间顺序是模拟流程，不是性能测试。进度事件没有最终数字；用户的另一问题也不改变报表的筛选条件。把“正在聚合”直接播成“已完成20”属于提前宣告，即使最后恰好算对也失败。
| 事件 | 内部状态 | 可接受行为 |
|---|---|---|
| 请求到达 | pending | 确认已收到，不报最终值 |
| 数据读取完成 | running | 只描述读取阶段完成 |
| 用户询问另一概念 | running | 回答新问题，保留原任务身份 |
| 最终结果到达 | done：R1、R2，数量20 | 按合适时机交付结果与排除项 |
| 旧任务结果晚到 | ID不匹配当前任务 | 不覆盖当前报表 |
“先别说”和“取消查询”需要两个分支
编辑设计的第一分支：用户说“等一下，我先问另一个问题”。停止当前语音输出，并保留后台任务；之后仍可交付Q7-A1结果。第二分支：用户明确说“取消这次汇总”。发出真实取消请求，等待可确认的任务状态，不只是口头说取消。
取消事件与完成事件可能竞争。若后台已完成，不能声称它从未执行；若取消已确认，之后到达的旧完成包不应自动播报为新的任务成功。把状态、任务ID和结果ID共同保存，能帮助复现这个边界错误。
在ADK的具体取消机制上，按官方教程配置stop_streaming并处理资源清理。界面上的静音按钮不能自动承担数据库查询、文件操作或连接清理；若工具本身不可取消，应准确报告实际状态。
把打断当取消的错误
用户插话后，界面显示“已取消”，但后台仍继续且稍后播出结果
分别记录speech_interrupted与task_cancelled；只有真实任务状态才能改变取消标记
选择播报时机，并检查交付内容
在不紧急的报表场景，编辑建议让最终结果在自然停顿时交付；确实需要中断的任务应另行定义，不把每条进度都当紧急通知。官方的调度选项解决的是结果何时进入对话，不会让耗时后端本身变快。
验收时比较输入ID、筛选状态与数量20，并确认重复追问没有制造第二个请求。可沿用多仓库任务边界中的范围意识；若任务是口头练习而非后台操作，则参考Gemini Live演练选择更合适的流程。
接入真实服务后，还要单独检查账户访问、权限、网络失败和实际取消反馈。本文的合成事件只能验证设计规则，不能证明模型在真实通话中一定遵守，也不能证明某个延迟目标已经达到。
模拟通过后再接真实服务
- R1与R2合计20，其余排除
- 重复追问保持一个任务ID
- 插话不会伪造已取消
- 取消后的晚到结果不会覆盖新任务
- 数字只在可信最终事件后交付
常见问题
提示词能解决阻塞等待吗？
不能替代执行架构。提示词描述行为，后台工具与会话配置决定是否能在等待中继续对话。
没有真实进度时该说什么？
确认请求已收到，并准确说明仍在等待结果；不要按定时器编造完成比例或步骤。
模拟案例通过能宣传低延迟吗？
不能。需要真实环境、配置和测量证据；本文没有运行模型或给出亲测性能。
