语音Agent最让人不耐烦的往往不是答错，而是“等它听完”。Google发布Gemini 3.5 Transcribe公开预览，把产品拆成两条明确通道：Live API负责连续双向流式音频，目标是亚秒级交互；Interactions API处理会议、呼叫记录等预录音频，并提供说话人区分和词级时间戳。它把语音识别从单一模型能力，推进成面向实时与离线流程的两套生产接口。

两套API不是重复，而是两种完全不同的产品承诺

实时语音要求模型尽早给出稳定片段，让后续意图识别、检索和合成语音及时启动。输出太晚，用户会打断；输出太早又容易反复改写。预录音频更看重完整性，可以利用后文纠正人名、标点和说话人。把两条路径拆开，有利于分别优化延迟与准确率，也避免企业用会议转写方案硬套实时客服。

Live API的双向流意味着Agent可以边听边规划，而不是上传整段录音后等待。Interactions API的词级时间戳则方便把摘要、质检结果和原始音频定位关联。对呼叫中心而言，这关系到争议复核；对会议和采访工具而言，它决定用户能否从结论准确跳回原话位置。

70%和5.04%说明方向，不代表所有企业口音

按Google披露并引用Artificial Analysis测量，最终转写完成时间相较上一代方案改善约70%。在覆盖多种语言与地区的FLEURS基准中，流式模式词错率为5.50%，非流式为5.04%。这组数据支持“实时更快、离线略准”的产品划分，也说明流式识别并未因为抢速度而出现巨大精度落差。

但公开基准无法覆盖企业现场的电话压缩、多人抢话、行业缩写、背景噪声和中英混说。一个词错率看似不高的系统，若把药名、金额或客户编号听错，业务后果仍然严重。企业必须建立自己的关键实体评测，并把总体词错率拆成数字、专有名词、说话人归属与时间戳偏差。

语音Agent的成本不只按分钟，还按错误链条计算

转写结果通常不是终点，而是后续Agent的输入。一个早期识别错误可能让意图分类选错流程、检索错误客户，再触发不必要的工具调用。FDE设计语音系统时，应保留分段置信度和原始音频引用，对金额、地址和操作指令设置复述确认；低置信片段则延迟执行或转人工。

同时要控制流式上下文的膨胀。若每个音频片段都带着全部历史反复送入后续模型，低延迟可能换来更高Token成本。合理做法是把稳定转写、临时假设和结构化状态分开，只在需要时触发大模型推理。语音前端越快，后端节流越重要。

编辑判断：亚秒响应只是入场券，闭环指标才决定上线

Gemini 3.5 Transcribe通过Gemini API、AI Studio和企业Agent平台进入公开预览，接入路径已经清晰。不过预览版仍可能调整配额、价格、地区覆盖和接口行为，生产系统需要版本锁定与降级模型，不能把单一服务当成唯一入口。

企业验收不应止于“听写看起来很准”。至少要记录首个稳定片段延迟、最终片段延迟、关键实体准确率、说话人错误率、人工修正率、任务完成率和每个成功任务成本。只有当实时速度没有把错误推得更快，且离线结果能够审计回放，这次模型升级才真正把语音Agent推向生产，而不是只让字幕滚动得更顺。

隐私边界也必须前置。客服、医疗和法务录音可能包含敏感信息，企业应明确音频保留时长、地区处理、访问审计与删除机制，并在转写进入下游模型前完成必要脱敏。实时接口缩短了等待时间，却也缩短了发现错误或阻止敏感内容外流的反应窗口。

声音越接近实时，权限、脱敏和纠错就越不能留到任务结束后再补。