语音客服、现场助手和实时运营数字员工，最难的往往不是让模型说出一句正确的话，而是让一次持续数分钟甚至数小时的交互在网络抖动、浏览器刷新、服务重启和工具超时后仍能安全继续。只恢复聊天文本不够：系统还要知道用户说到哪里、哪些工具已经执行、哪些外部动作正在进行，以及断线前产生的后台任务是否已经停止。
Google 在 2026 年 8 月 17 日发布 ADK Python v1.39.0，把这组问题推到了更明确的工程边界。官方 Release 为 Live 会话打开阶段接入 RunConfig.session_resumption.handle，增加实时输入的 audio_stream_end 信号，并在 Live Agent 运行结束时停止后台工具任务。同日的 v2.7.1 还增加了会话初始化事件校验，并恢复 OpenTelemetry 1.42.1 的依赖上限。
这些变化值得企业关注，但不能被写成“实时数字员工已经自动可靠”。它们提供的是 SDK 级原语和修复；端到端连续性、工具幂等、业务补偿与审计仍属于应用和运行平台的责任。
实时会话有五种不同状态
企业常把“Session”理解成一段对话记录，实际至少要拆成五层：传输连接、音视频流、模型上下文、Agent 执行状态和业务系统状态。WebSocket 重连只恢复传输；模型恢复句柄只帮助延续模型侧会话；Agent 仍需知道工具调用进度；订单、工单、邮件等外部系统更不会因为模型重连自动回滚。
Google ADK Live 文档 将 RunConfig、会话恢复、上下文压缩、配额管理和 LiveRequestQueue 分开描述，本身就说明“实时”不是单一开关。audio_stream_end 也不是一个界面细节：如果客户端没有明确标记音频结束，服务端可能继续等待输入，转写、轮次切换和工具触发都会变得不确定。
因此，恢复凭证不能成为唯一状态。企业至少要持久化 tenant_id、user_id、session_id、恢复句柄、当前轮次、最近确认事件、工具调用 ID、业务幂等键和策略版本。恢复句柄应当按密钥管理：限定租户与会话、加密存储、设置有效期，不进入普通业务日志。
“至少一次”意味着可能重复扣款
Google 的 Runtime Resume 官方文档 明确说明，工作流通过事件记录已完成步骤并从部分完成状态继续；但工具执行提供的是“至少一次”语义，恢复时可能运行多次。官方还举例提醒，采购等重复执行会产生负面影响，工具必须自行检查并阻止重复运行。
这条限制比“支持恢复”更重要。数字员工调用只读搜索时，重复一次通常只是增加成本；发送邮件、创建工单、修改库存或发起付款时，重复一次就可能成为业务事故。正确做法不是要求模型记住“不要重复”，而是在工具契约中加入稳定幂等键，并由业务系统保存执行结果。
一次外部写入可以采用 tenant + workflow + step + business_object 生成幂等键。工具收到重复请求时返回首次结果，而不是再次执行。若目标系统不支持幂等，还应通过本地事务表、发件箱模式或人工审批建立防重层。对于无法撤销的动作，恢复流程应先查询真实外部状态，再决定继续、补偿或升级人工。
运行结束必须真正结束
v1.39.0 在 Live 运行结束时停止后台工具任务，修复的是另一类容易被忽略的风险：前台会话已经关闭，搜索、代码执行或外部 API 调用却仍在后台运行。它们可能继续消耗预算、持有凭证，甚至在用户离开后写入系统。
企业运行时应把“会话结束”定义为可验证的收尾协议：停止接收新输入；取消或隔离未完成工具；等待可安全结束的任务；记录最终状态；释放临时凭证和资源；把无法取消的外部操作交给补偿队列。还要为后台任务设置截止时间、预算和网络边界，不能只依赖 SDK 的取消信号。
OpenTelemetry 依赖上限修复同样不应被夸大为可观测性保证。它只是兼容性边界的修正。团队仍需验证 trace 是否能串联重连前后事件、工具调用与最终业务结果，避免恢复后生成两条无法关联的链路。
企业上线的参考架构
实时数字员工可以采用四层设计。接入层负责鉴权、音视频协议、序号和断线重连；会话层保存恢复句柄、事件游标与上下文策略；执行层负责任务状态、超时、取消、审批和工具调度；业务层通过幂等键、状态查询与补偿控制外部副作用。
高风险工具不应由 Live 会话直接持有长期凭证。更稳妥的方式是把工具调用变成有身份、有策略版本的短时请求，由独立执行服务再次校验权限。这样即使会话被错误恢复，模型也不能绕过业务授权。
这套结构与本站的 企业 Agent Runtime 选型清单 和 长时 Agent 评测方法 是同一件事的两个侧面：Runtime 决定能否恢复和收尾，评测则证明恢复之后没有重复、越权或丢失业务状态。Google ADK 的具体定位可在 生态观察页 继续核对。
发布前应做的六组故障演练
第一，用户说话中途断网，恢复后不得重复转写或遗漏已确认片段。第二，工具已经写入外部系统、响应却在返回前丢失，重试不得重复写入。第三，服务进程在多 Agent 交接时退出，恢复后只能从可证明的检查点继续。第四，会话主动结束，后台工具必须在时限内取消或进入受控补偿。第五，恢复句柄跨租户或过期使用必须失败。第六，恢复前后 trace、成本和审批记录必须能合并为一次业务任务。
验收指标也要从“能不能重新连上”升级为恢复成功率、重复副作用率、状态丢失率、孤儿任务数、人工接管率和每次成功任务成本。只要重复副作用率不是零，高风险写操作就不应自动放行。
研究限制与编辑判断
本文的官方事实来自 Google ADK Release 与官方文档；尚未看到独立生产评测证明这些版本在所有网络、模型和部署组合下都能无缝恢复。v1.39.0 与 v2.7.1 也属于不同版本线，企业必须按自身使用的版本核对迁移与兼容性。
我们的编辑判断是：这次更新达到架构研究门槛，不是因为新增了几个 API，而是它暴露了实时 Agent 生产化的核心事实——会话连续性和业务正确性不是同一个问题。真正可用的数字员工，必须把恢复句柄、事件日志、幂等工具、取消协议、最小权限和故障演练组成一个完整控制面。