Gemini 3.8 Live：后台查询时，AI 语音助手也能继续对话

Gemini 3.8 Live 如何让查询不再打断通话

AI 语音助手通常要同时完成两件事：一边保持自然对话，一边在其他系统里真正执行任务。

尴尬往往出在第二件事上。助手向预订 API 查询空档后只能等待，电话另一端随即陷入沉默。来电者可能重复需求、询问是否还在线，甚至直接挂断。如果应用把重复的话当成新指令，同一任务还可能被启动两次。

Gemini 3.8 Live 通过异步函数调用改变了这套流程。所谓异步，就是工具可以继续运行，而不必冻结整个实时会话。查询尚未返回时，来电者仍可补充背景、纠正细节，也能听到进度说明。

Gemini 3.8 Live Extended Thinking 更进一步：它可以推理多步骤任务，并在工具运行期间播报简短进度。Google 给出的示例是一套旅行预订流程，系统会查询多个服务，但实时对话不会因此中断。

这并不意味着 Gemini 会自行完成预订。函数调用仍由你的应用接收，日历或订单查询也由应用执行，随后再把结果传回模型。模型负责的是围绕这项任务维持对话。

最后一列正是生产环境最容易踩的坑。对 Extended Thinking 而言，turnComplete: true 可能只表示一条中间进度播报已经结束，查询本身仍在运行。如果此时关闭会话、启用预订按钮或把任务标记为完成，就会制造出并未真正完成的记录。

真正该看的业务指标：单次完成任务成本

后台继续说话，不等于成本自然下降。工具运行时，模型可能产生更多输出；对话拉长后，后续轮次也可能再次处理更多上下文。只有当这种连续交流带来更多完成的预订、更少的中途挂断，或减少人工清理工作时，这项能力才真正有价值。

Google 为两个新模型列出的标准费率相同：音频输入每分钟 $0.005，音频输出每分钟 $0.018；文本输入每 100 万 token 收费 $0.75，文本输出（包括 thinking token）每 100 万 token 收费 $4.50。

以一通 5 分钟的预订电话为例，模型共说话 2 分钟。由于 proactive audio 被永久启用，只计算新增音频时，5 分钟输入为 $0.025，2 分钟输出为 $0.036，原始音频小计就是 $0.061。

但这并不是整通电话的最终成本。

Live API 计费指南 指出，持久会话可能在后续轮次重新处理已累积的上下文。转写会增加文本 token 费用，Extended Thinking 也可能增加 thinking 输出。日历、CRM、电话运营商、托管、重试和人工升级处理，都不在 Google 的音频小计内。

因此应使用下面这条公式：

单次完成任务成本 = 模型、工具、电话、基础设施、重试和升级处理的全部支出 ÷ 已验证完成的任务数。

一段听起来顺畅的通话记录，不等于任务已经完成。对预约热线来说，完成意味着预订 ID 只写入一次、准确复述，并得到来电者确认；对订单支持来说，意味着正确操作落在正确账户上；对转接来说，则意味着电话连入目标队列，而且上下文没有丢失。

Google 会定期在 usageMetadata 中返回已消耗的 token 总量。把这条记录与工具调用 ID、运营商会话、最终业务结果及所有人工工作关联起来，才能得到可审计的单通电话账本，而不是只能选择相信的分钟成本估算。

发布时的基准数据不能替代这项试点。Google 报告称，Extended Thinking 在 tau-Voice 任务基准上的得分为 68.6%，在其银行场景版本上的得分为 35.1%。这些成绩说明该模型值得在智能体语音任务上测试，却无法告诉你：在你的日历、业务规则和电话连接条件下，究竟有多少来电者能完成预订。

4 类真正受益于后台等待的工作流

牙科诊所预约

运营负责人可以让助手先收集来电者偏好的日期，再查询可用时段；日历尚未响应时，助手会说明仍在查找。真正的收益不只是缩短沉默，而是增加已确认预约，同时减少员工回拨。

安全规则必须明确：口头进度不等于已经预约。只有来电者选定返回的时段后，系统才能创建预订；重试时还应复用同一个幂等键，避免一通电话重复创建同一预约。

电商团队查询订单

助手查询订单系统时，客服负责人可以让来电者留在同一段对话里。如果需求从“我的包裹到哪里了”变成“修改收货地址”，应用必须以新请求为准，并取消或忽略已经过期的任务。

收益是常规问题减少转接；风险则是来电者早已换了问题，系统却在之后给出了上一个问题的正确答案。

旅行团队处理改签

航班搜索、规则核验、酒店空房查询和票价比较，使这类任务更适合 Extended Thinking。多个非阻塞函数运行时，模型可以持续播报进度。

付款和票务变更仍应放在确认步骤之后。声音再自然，也不能降低不可逆操作的审批标准。

技术支持队列排查账户问题

快速账户查询适合交给 Gemini 3.8 Live；如果诊断需要汇总多份日志并检查配置，则可以考虑 Extended Thinking。

这种分流很重要，因为更深入的推理并非没有成本。应按任务复杂度路由，再比较问题解决率和升级率。不要只因模型名称听起来更稳妥，就让每一次密码重置都走更重的路径。

接入电话线路前，先跑通后台任务生命周期

先用文本触发会话，并接入一个 stub 工具。这样可以单独验证异步行为，避免运营商、麦克风、音频桥接和生产日历又带来 4 个需要排查的环节。

下面的示例采用 Google 当前的 Python SDK、Extended Thinking 配置、非阻塞函数声明、工具响应模式，以及 interaction_status 和 usageMetadata 字段。返回的 24 kHz 音频会写入 response.wav。工具结果来自本地 stub，因此不会访问真实日历。

pip install -U google-genai
export GEMINI_API_KEY="YOUR_API_KEY"

import asyncio
import wave

from google import genai
from google.genai import types

client = genai.Client()
model = "gemini-3.8-live-extended-thinking"

check_availability = types.FunctionDeclaration(
    name="check_availability",
    description="Checks the calendar for the next available appointment.",
    behavior="NON_BLOCKING",
    parameters={
        "type": "OBJECT",
        "properties": {},
    },
)

config = types.LiveConnectConfig(
    response_modalities=["AUDIO"],
    thinking_config=types.ThinkingConfig(thinking_level="low"),
    tools=[types.Tool(function_declarations=[check_availability])],
)


async def main():
    async with client.aio.live.connect(model=model, config=config) as session:
        await session.send_client_content(
            turns={
                "parts": [
                    {"text": "Find the next available appointment and keep me updated."}
                ]
            }
        )

        with wave.open("response.wav", "wb") as audio:
            audio.setnchannels(1)
            audio.setsampwidth(2)
            audio.setframerate(24000)

            async for message in session.receive():
                status = getattr(message, "interaction_status", None)

                if message.data is not None:
                    audio.writeframes(message.data)

                if message.usage_metadata:
                    print("Tokens:", message.usage_metadata.total_token_count)

                if message.tool_call:
                    replies = []
                    for call in message.tool_call.function_calls:
                        replies.append(
                            types.FunctionResponse(
                                id=call.id,
                                name=call.name,
                                response={"result": "Tuesday morning is available."},
                            )
                        )
                    await session.send_tool_response(function_responses=replies)

                if status == "IDLE":
                    print("Interaction complete")
                    break


if __name__ == "__main__":
    asyncio.run(main())

最容易出错的地方，是看到第一个 turnComplete 就退出。Extended Thinking 可能刚说完“正在查询”，此时仍在等待工具返回。应持续监听，直到 interaction_status 变为 IDLE，并始终把工具调用 ID 与最终业务结果关联起来。

开发生产级电话智能体时，先确保这个循环运行正确，再添加音频桥接。选择模型外围的运营商和编排层时，可以参考这份更全面的 AI 语音智能体成本对比。如果要把 Google 的 token 计费与更简单的前端语音费率对照，GPT-Live-1 通话成本拆解 说明了为什么两边都应以完成任务数作为分母。

试点要围绕账本，而不是演示效果

必须正视的边界

模型可以填补沉默，却不能让缓慢的日历变快，不能修复糟糕的电话连接，也无法替你的业务定义何为“完成”。

纯音频会话最长为 15 分钟；如需更长对话，必须加入会话管理技术。原生音频的上下文上限是 128,000 token。轮次多、持续时间长的通话，其成本也不同于简单的时长估算，因为旧上下文可能被再次处理。

安全仍由你的应用负责。浏览器若要直接连接，应使用临时 token，而不是标准 API key。预订、退款或账户变更仍然需要身份验证、校验、幂等机制和审计记录。

异步路径还带来一种生产风险：过期任务。如果来电者在工具运行时改变需求，旧结果可能稍后才返回。必须显式跟踪任务状态，并拒绝与当前意图不再匹配的结果。

本周行动：只为一个窄场景建立监测

如果工具静默等待正导致来电者重复表达、放弃预订或需要员工善后，就应在本周行动。直接查询交给 Gemini 3.8 Live，只挑一项真正的多步骤流程使用 Extended Thinking，并让两者接入同一套完成任务账本。

如果目前还无法在自有系统中证明任务完成、运营商链路尚未稳定，或流程包含没有确认关卡的不可逆操作，那就先等待。比起新模型，你更需要先建立记录。

这次发布与三类产品无关：纯文本产品；工具本就能立即返回的语音流程；以及已经达到完成率、升级率和成本目标的成熟电话助手。新模型本身，不足以成为替换一套经过衡量的系统的理由。

如果你希望继续看到这类用直白语言拆解运营成本和工作流变化的内容，可以订阅邮件通讯。