2026 年 3 月 26 日Google 发布 Gemini 3.1 Flash Live。 同一天Google 还宣布 Search Live 全球扩展让用户在支持 AI Mode 的国家和语言里可以直接通过语音和摄像头与搜索进行实时对话。把这两个发布放在一起看重点其实不是“Google 又推了一个新模型”而是AI 交互范式正在换挡。过去几年主流使用方式还是“输入一段文字等模型生成一段回答”。 但这次 Google 明确押注的是另一条路线低延迟语音视觉上下文实时来回对话工具调用嵌入会话流更长时间的连续 session这意味着下一代 AI assistant 不再只是“回答器”而更像一个能实时观察、理解、检索、回应的交互系统。一、这次更新最值得注意的不是语音输出而是“会话模型”变了从 Google 官方说明看Gemini 3.1 Flash Live 的定位不是传统语音转文本组件也不是简单的 TTS 外挂而是面向 real-time dialogue 的 live model。官方给出的几个关键词非常值得关注更低延迟更自然的 rhythm更强的 tonal understanding更好的 task execution面向 voice-first agent这背后对应的其实不是单一能力提升而是整个交互回路被改写。旧的文本问答链路更像这样用户输入 - 模型读完整输入 - 生成完整输出 - 用户继续下一轮而实时语音视觉链路更接近音频流/图像流持续进入 - 模型持续更新理解 - 在合适时机即时回应 - 用户可以打断/补充 - 系统继续保持会话状态这两者最大的区别在于后者不是按“回合”工作而是按“流”工作。Google 在官方文档里对 Live API 的定义也非常直接它支持 continuous streams of audio, images, and text通过同一条持久连接返回低延迟响应。这已经不是标准 chat completion 的工作方式了。二、从官方文档看Google 实际上在公开一套“实时多模态会话架构”如果只看产品新闻容易把 Gemini 3.1 Flash Live 理解成“一个更自然的语音模型”。 但看完开发文档会发现它真正开放的是一套面向实时交互的接口模型。import asyncio from google import genai client genai.Client(api_keyYOUR_API_KEY) model gemini-3.1-flash-live-preview config {response_modalities: [AUDIO]} async def main(): async with client.aio.live.connect(modelmodel, configconfig) as session: print(Session started) # Send content... if __name__ __main__: asyncio.run(main())这段代码来自官方Get started with Gemini Live API using the Google GenAI SDK 文档。它看起来很简短但有两个信息量很大的点1. 会话是持久的这里不是一次请求一次响应而是 live.connect(...) 建立一条持续 session。这意味着模型运行方式正在从 stateless request 走向 stateful session。2. 输出模态是可配置的response_modalities允许直接指定音频输出这说明语音不再只是后处理层而是模型交互路径的一部分。这也是为什么 Google 在官方 Live API 文档里把输入规范写得非常明确 音频输入是16-bit PCM, 16kHz 图像按帧发送协议使用WebSocket 本质上就是把模型接进了实时流媒体场景。三、为什么“低延迟”在这里不是体验优化而是系统约束实时语音交互最容易被低估的是延迟对系统结构的影响。在文本产品里1 到 3 秒的响应很多用户都能接受。但语音对话不是这样。只要停顿稍长用户会立刻感知到系统没听懂、系统卡住了、对话不自然、打断和续接不顺等。所以 Google 这次反复强调 latency并不是单纯宣传“更快”而是在说明它针对的是另一种应用类型conversation-speed interaction。官方文档里发送音频流的示例也很直接# Assuming chunk is your raw PCM audio bytes await session.send_realtime_input( audiotypes.Blob( datachunk, mime_typeaudio/pcm;rate16000 ) )这里最关键的词是send_realtime_input 。它说明输入不是等用户说完之后统一提交而是边说边送。对于系统设计来说这会连带影响很多层前端采集粒度网络传输方式服务端缓冲策略语音检测机制模型推理触发时机工具调用插入点所以这波变化本质上不是“把输入框换成麦克风”而是把交互从离散式提交改成了流式协作。四、视觉进入会话之后输入不再是“问题”而是“现场”Search Live 的真正分水岭不只是可以说话而是可以打开摄像头继续问。Google 官方在 Search Live is expanding globally 的文章里写得很清楚用户可以在 Google app 里直接开启Live语音发问如果要询问眼前的东西比如安装一个架子也可以打开摄像头把视觉上下文一起给到系统。这意味着AI 交互的输入结构从过去系统只拿到一句话到现在现在系统拿到的是当前语音之前会话历史摄像头看到的场景搜索工具返回结果网页链接与结构化信息输入不再只是“query”而是“scene intent context”。Google 官方文档里发送视频帧的示例如下# Assuming frame is your JPEG-encoded image bytes await session.send_realtime_input( videotypes.Blob( dataframe, mime_typeimage/jpeg ) )这段代码本身不复杂但它把一个事实说得很清楚多模态不是把图片附件扔给模型而是把视觉流纳入会话。一旦进入这个阶段很多传统文本应用里的设计习惯就不够用了比如只围绕 prompt 设计上下文只按轮次组织状态只接文本型知识源只在回答前做一次检索这些在实时视觉会话里都会显得过窄。五、实时语音视觉为什么会把“会话管理”抬到更高优先级另一个常被忽视的点是 session 的长度和恢复能力。Google Live API 文档里专门有一章讲Session management 不压缩上下文时audio-only session 有时长限制audiovideo session 默认更短可以通过 context window compression 延长会话可以通过 session resumptio 在连接断开后恢复 session官方示例里context_window_compression 的配置是这样的from google.genai import types config types.LiveConnectConfig( response_modalities[AUDIO], context_window_compression( types.ContextWindowCompressionConfig( sliding_windowtypes.SlidingWindow(), ) ), )这段代码背后传达的信息是Google 已经默认开发者会遇到长会话、上下文膨胀、连接重建这些问题。也就是说实时 AI 交互不只是“识别音频然后回答”而是开始接近一个长期运行的交互进程。这和传统 chatbot 的差别非常大。 传统 chatbot 更像 request-response 服务 而实时多模态 agent 更像一个带状态的会话 runtime。六、工具调用在实时会话里开始变成“内嵌动作”而不是外挂步骤从官方文档看Live API 也支持 tool calling。Google 给出的 Python 示例是async for response in session.receive(): if response.tool_call: function_responses [ ] for fc in response.tool_call.function_calls: # 1. Execute the function locally result my_tool_function(**fc.args) # 2. Prepare the response function_responses.append(types.FunctionResponse( namefc.name, idfc.id, response{result: result} )) # 3. Send the tool response back to the session await session.send_tool_response(function_responsesfunction_responses)这一段的意义不在于“模型也能调函数”这件事大家已经不陌生了。 真正值得注意的是函数调用现在发生在 live session 里。这代表一种新的工作方式用户一边说系统一边判断是否需要外部工具工具结果返回后继续进会话对话不中断节奏尽量保持自然。这比“先说完、再检索、再生成”的线性链路更贴近真实互动。 同时也意味着上游工具和数据接口必须更稳定、更结构化因为它们已经被放进了实时路径。七、从这个热点往下看真正被重新定义的其实是“数据输入层”如果把 Gemini 3.1 Flash Live Search Live 看成一次交互升级那它向下游传导的第一个变化其实不是模型而是数据。原因很简单。 当用户开始问这类问题时“你看看我现在屏幕上的内容”“我正在看的这个商品值不值得买”“这条视频主要在讲什么”“现在这个关键词搜索里是谁排前面”“帮我结合画面和网页结果判断一下”系统就不可能只依赖模型内部参数了。 它必须有能力把外部世界里的内容接进来而且还要尽量保持实时。这时候数据输入层就会遇到新的要求不只是文本采集还要处理音视频与图像相关信息不只是拿原始页面还要返回结构化字段不只是一次性导入还要适应连续查询和热数据更新不只是“抓到内容”还要能进入语音/视觉 agent 的工作流也就是说交互升级会反过来推着数据基础设施升级。八、Dataify补足多模态数据入口如果顺着这个逻辑看Dataify 切入点是当 AI 交互变成实时、多模态、带外部上下文的系统之后公开数据如何以更可用的形式进入会话链路。结合 Dataify 官网公开的产品结构这条线其实很清晰SERP API 解决搜索结果页数据接入Web Scraper / Universal Scraping 解决网页正文与复杂页面结构化提取Video Scraping 处理视频、频道、播放列表、评论、互动指标、字幕和元数据这类更典型的多模态公开数据多领域数据集与相关处理能力则让音视频、社交媒体、电商等场景的数据准备更靠近 AI 应用本身Google 解决的是“模型如何实时听、看、说、调用工具”。 而 Dataify 更像是在补“这些实时系统要读什么外部数据数据怎么进来进来之后是不是结构化可用”。这尤其适合下面几类场景语音助手结合搜索结果和网页正文做即时答复视觉问答叠加视频评论、字幕、元数据进行补充判断多模态 agent 在会话中动态调用公开数据接口面向市场研究、内容洞察、竞品跟踪的实时分析系统也就是说交互层和数据层在这一轮不是平行关系而是开始直接耦合。九、这次事件真正值得记住的一点如果只把 Gemini 3.1 Flash Live 看成一次产品更新很容易低估它。 但如果把它和 Search Live 全球扩展放在一起就会看到一个更明确的趋势AI 正在从“文本生成接口”变成“实时多模态交互系统”。一旦进入这个阶段系统建设重点会发生位移从 prompt 优化转向 session 设计从一次性回答转向连续对话控制从纯文本知识源转向多模态外部输入从模型能力单点提升转向模型、工具、数据一起协作这也是为什么这条新闻值得单独拿出来分析。 它讨论的已经不是“语音好不好听”而是下一代 AI 系统的基本交互形态。结尾AI 的下一步不只是更会写而是更会听、更会看、更会在实时场景里持续互动。而一旦交互走向实时语音与视觉外部数据的组织方式也必须跟着改变。 系统需要的不再只是静态文本而是能被实时调用、能跨模态组织、能进入连续会话的数据输入层。Dataify 把搜索、网页、视频等公开数据做成结构化、多模态采集能力的平台会在这波趋势里变得更有意义。 它不是 Live API 的替代品但它可以成为这类实时 AI 系统背后的数据入口。