深度拆解 Gemini 3.8 Live：一句插话，为什么会牵动整个 Agent 系统

2026-09-16公众号文章

从异步 Tool 到 KV Cache，实时语音进入了持续计算阶段。

作者丨郑佳美

编辑丨岑峰

刚刚，Google 发布了 Gemini 3.8 Live 和 Gemini 3.8 Live Extended Thinking。和过去的实时语音模型相比，这次变化已经不只是语音响应速度、自然度或者多模态输入，而是开始把语音、视觉、推理和 Tool Calling 放进同一条持续运行的链路里。

以前的 Voice Agent 更接近一套串行流程：用户说完，模型开始处理，需要时调用外部工具，等结果回来以后继续回答。

现在这条链路正在被拆开。用户还在继续说，模型已经可以处理前面的内容；模型正在回应时，后台 Tool 仍然可以运行；复杂 reasoning 也不必完全阻塞前台交互。整个会话开始从一次次独立请求，变成一个持续变化的执行环境。

不过问题也随之发生变化。实时语音要求前台几乎不能停，后台推理和工具任务却可能持续数秒，用户还可能随时插话、修改目标，甚至让几秒前启动的任务瞬间失去意义。

到了这一阶段，单纯把模型做得更快已经解决不了全部问题，系统还要处理并发任务怎么排、旧结果还能不能继续使用、后台计算什么时候该停，以及不同任务之间怎么分配计算资源。

Voice Agent 开始进入 Runtime 阶段。语音只是入口，真正复杂的部分正在往调度、状态一致性和持续计算这一层下沉。

这其实是给 AI 配了两套脑子：一套是毫秒级响应的‘脊髓’，管实时语音和情绪跟随；一套是秒级、分钟级运转的‘大脑皮层’，管深度推理和工具调用。Gemini 3.8 Live 的关键突破，是在工程上让这两套节奏完全不同的系统学会了同时工作。

实时语音为什么会变成一个调度问题

传统语音系统虽然也有流式输入，但核心执行链通常还是顺序的：用户完成一轮表达，模型处理这一轮输入，需要外部信息时等待 Tool 返回，然后继续生成结果。

Gemini 3.8 Live 把其中几个阶段拆开以后，一条 Session 内开始同时存在音频输入、模型生成、后台 reasoning 和外部 I/O，它们共享同一份会话状态，时间要求却完全不同。

语音输入运行在很短的时间尺度上。麦克风不断产生新的 audio chunk，VAD 持续判断说话开始和结束，模型输出的音频还要经过播放缓冲。

如果用户在模型回答过程中重新开口，客户端不能等完整回答生成结束再处理新的输入，因为缓冲区里哪怕多积累几百毫秒旧音频，人也会明显感到系统没有跟上当前对话。Google 的 Live API 已经把 interruption 放进实时链路，新的 client content 可以直接打断当前 generation。

后台 reasoning 和 Tool Calling 则运行在另一套时间尺度上。数据库查询可能几百毫秒返回，搜索和浏览器操作可能持续几秒，多步 reasoning 还会不断生成新的计算任务。如果把这些任务和语音生成放进同一个 FIFO 执行队列，一个耗时较长的后台任务很容易形成 head-of-line blocking，让后面的实时任务跟着等待。

因此 Voice Agent 需要的调度方式会逐渐接近 deadline-aware scheduler。实时音频输入和前台 decode 拥有较短的 deadline，后台 reasoning 可以获得更宽松的执行窗口，Tool 任务则根据当前会话状态动态调整优先级。

新的语音事件进入以后，Runtime 需要允许高优先级工作插入当前执行路径，旧的后台计算如果已经失去作用，还要及时释放资源。

这背后还有一个容易被忽略的 backpressure 问题。用户不断输入，Tool 不断返回，reasoning 同时产生新的 token，如果 Runtime 只是把这些内容不断塞回 Context，单个 Session 的状态会持续膨胀，随后带来更大的 prefill、更多 KV Cache 占用以及更长的 decode 排队时间。

Live API 已经提供 context window compression 和 session resumption，本质上说明实时会话已经不能按照一次请求结束后全部释放状态的方式运行，而需要长期维护、压缩和恢复 Session。

所以实时语音里的延迟已经不能只用 Time to First Token 描述。真正影响体验的是一整条 latency path：音频进入以后什么时候被调度，generation 什么时候获得 GPU 时间，后台任务是否阻塞前台，新指令进入以后旧任务多久能够退出。

模型本身可以很快，但只要 Runtime 的任务队列发生拥塞，Voice Agent 依然会显得迟钝。

异步 Tool Calling

难在结果什么时候还能生效

Gemini 3.8 Live 的异步 Function Calling 把另一个问题直接暴露了出来。

普通同步 Tool Calling 很简单，模型发起工具请求以后暂停，等 FunctionResponse 返回，再继续当前推理。异步模式取消了这层阻塞，工具运行期间模型仍然能够继续和用户互动。

标准 Gemini 3.8 Live 甚至允许 FunctionResponse 以 INTERRUPT、WHEN_IDLE 或 SILENT 的方式进入后续交互。这意味着 Tool Result 从一个函数返回值变成了一个异步事件。

问题在于，事件返回时，产生它的上下文可能已经不存在。用户让 Agent 搜索周五的航班，Tool 请求刚刚发出，随后用户把日期改成周六。几秒以后周五的查询正常返回，从 API 层面看没有任何错误，但它已经不再属于当前任务。

Runtime 因此不能采用 Tool 完成就写回 Context 的简单模型。更合理的实现是让每个后台任务携带自己的 task identity 和 session epoch，记录它是在怎样的会话状态下创建的。Tool Result 回来以后先经过一次 validity check，确认任务依赖的条件依然成立，再决定能否进入模型上下文。

这和数据库里的 optimistic concurrency control 很接近。系统不会为了一个慢 Tool 把整个 Session 锁住，而是允许用户输入、模型生成和多个 Tool 并行向前运行，在结果提交时再检查版本。如果任务创建之后用户目标已经改变，结果即使正确完成，也只能被视作 stale result。

这里真正需要管理的是 execution 和 commit 两个阶段。

模型产生 Function Call，只代表某项工作可以开始执行；任务执行结束，也不代表结果一定应该改变当前 Agent 状态。中间需要一层 commit gate，把当前 Session、任务版本、结果时效以及外部副作用放在一起判断。

读取型 Tool 相对容易处理，旧结果可以直接失效。涉及外部状态修改以后，Runtime 就会遇到分布式系统里熟悉的 retry ambiguity。网络超时只说明客户端没有收到响应，无法说明远端服务有没有执行请求。

如果直接重新调用，同一个动作可能发生两次，因此 Tool Runtime 还需要稳定的 operation id 和 idempotency semantics，把多次网络请求映射到同一个逻辑动作。

取消也会变得复杂。停止模型当前 generation、取消一个仍在运行的 HTTP 请求以及撤销已经在外部系统执行的动作，是三件不同的事情。

对于已经越过外部边界的任务，Runtime 可能只能记录其完成状态，再通过 compensating action 修正后续状态。这已经接近 Saga 处理长事务时采用的思路：没有统一 rollback，只能持续维护每一个外部动作的生命周期。

Extended Thinking 又让这个状态机继续拉长。Google 的协议里，turnComplete 已经不能代表整个任务结束，它只能说明当前一次输出结束；只要后台 reasoning 或异步 Tool 还在运行，interaction_status 仍然保持 IN_PROGRESS，直到整个任务真正完成才进入 IDLE。

这其实是一个很大的架构变化。一次用户输入已经不再严格对应一次模型输出，Turn 和 Task 被拆成了两个生命周期。前台可以完成多个 utterance，后台却仍然属于同一个 interaction。

Voice Agent 的核心状态单位开始从消息和回合，转向持续运行的任务图。

推理本身也变成了可调度资源

Extended Thinking 带来的另一层变化发生在 GPU serving。

Google 为 Gemini 3.8 Live Extended Thinking 提供 low、medium 和 high 三档 thinking level，后台 reasoning 可以在语音会话继续进行时运行。标准 Gemini 3.8 Live 则采用固定延迟特征的 interleaved reasoning，不开放 thinking level 配置。

从 Runtime 角度看，这意味着 reasoning 不再只是一次 Request 内部不可见的计算过程，而开始成为 Session 生命周期里的长期 workload。

实时语音生成和后台 reasoning 对 GPU 的需求并不相同。前台语音主要要求稳定的 inter-token latency，生成过程中任何明显抖动会直接变成声音停顿；后台 reasoning 可以接受较长执行时间，更在意总计算深度。

如果两类 workload 直接进入同一个 continuous batching 队列，大量 reasoning token 会占据 decode slot，长 prefill 也可能干扰前台请求的执行节奏。

因此实时 Agent serving 很可能需要做 latency isolation，让前台 decode 保有较高调度权重，后台 reasoning 则被切成较小的 execution quantum，在实时任务进入时允许 preemption。

问题随即落到 KV Cache。后台 reasoning 暂停以后，它此前产生的 KV 状态仍然存在。继续保留可以快速恢复计算，却会持续占据 GPU 显存；把 KV evict 到其他层级可以腾出空间，但恢复时会增加数据搬运成本；直接释放则可能意味着后续需要 recompute。

随着 Session 数量增加，Runtime 要不断权衡 cache residency、recompute cost 和前台 latency。

这也是为什么长时间 Voice Agent 的资源问题和普通 Chat 请求很不一样。Chat 请求结束以后，大量临时状态可以释放；Voice Agent 的 Session 可能持续存在，Context 继续增长，后台 Tool 尚未结束，reasoning 也可能随时恢复。

如果每条 Session 长时间保留较大的 KV working set，服务容量很快就会受到显存和 memory bandwidth 限制。

Thinking level 因此可以继续往下理解成一种 resource budget。系统可以根据任务复杂度决定 reasoning 使用多少计算窗口，根据当前 GPU 压力动态调整后台任务的执行节奏。当用户重新讲话或者修改目标以后，与旧目标绑定的 reasoning branch 也应该尽快退出，否则系统还会继续为已经失效的路径消耗算力。

再往前一步，实时语音天然适合 speculative execution。用户一句话还没有完整结束时，模型已经获得部分语义，Runtime 可以提前执行一些低成本 reasoning，甚至准备可能使用的 Tool。当后续输入与已有路径一致，就减少等待时间；如果用户改变方向，则丢弃错误分支。

这相当于用额外计算换交互延迟，但必须设置明确的 commit boundary。内部 reasoning 可以提前跑，可能涉及真实外部状态变化的 Action 不能跟着提前提交，否则一次错误 speculation 就会从计算浪费变成真实世界里的错误操作。

Google 并没有公开 Gemini 3.8 Live 内部采用怎样的 continuous batching、KV eviction 或 GPU preemption 策略，因此这些属于从公开 Runtime 行为向推理基础设施继续推演。不过只要后台 reasoning、实时 decode 和异步 Tool 长期共存在一条 Session 中，这些 serving 层问题就无法继续隐藏在单次模型调用之后。