摘要

Google 的核心押注是能力汇流：专业研究分支最终应回流到一个主 Gemini 模型。 Google 内部嘉宾以 Gemini 2.5 Pro 为例：加入推理能力后，模型“开箱即用”地展现出意外强的视频理解能力，这并非专门投入视频研发的结果，而是多种能力组合后的产物。真正的上行空间就在这些能力的叠加上。
通过思考预算、思考摘要和自动缓存，Gemini 的开发者经济性正变得更可控。 Gemini 2.5 Pro 的思考预算预计将在两周左右随 GA 模型推出；关闭思考功能则希望在6月初上线。2.5 Flash 已支持预算控制，思考摘要也已上线。隐式缓存无需管理：“现在就能直接用，而且还能省钱。”
如果 Google 能将 Gemini Diffusion 按其质量标准产品化，动态生成界面或将变得实用。 讨论提到，一些应用对网站没有“预编译的概念”，而是随着用户操作生成代码、重绘界面。Swyx 认为生成式 UI 很可能是一个“杀手级用例”，但也承认距离落地仍有大量工作。
实时语音正在走向生产环境，但会话时长、延迟、工作流状态和供应商绑定仍是约束。 Live API 早期的限制大约是15–20分钟音频和5分钟视频。Google 正在加入滑动窗口和视频分辨率控制，同时持续改善函数调用和 Search；工具链早已支持 Search 与 Code Execution 等组合。实时技术栈比文本 API 更定制化、互操作性更弱，开发者因此需要更深地绑定单一供应商。
随着模型进步，原生音频到音频可能会吸收大量用例，但组件化语音技术栈仍有生命力，也受到开发者重视。 Google 还发布了2个可控、可提示的文本转语音模型，但当时尚未通过 Live API 提供。外围系统仍需处理语音活动检测和网络传输，同时将延迟控制在约500–700毫秒。
框架与 API 的边界正在迁移，而不是简单消失。 随着模型进步，轮次检测、上下文管理等能力可能从框架迁入 API；与此同时，用例扩张也会增加框架侧的工作量。实验性的主动音频模式可以忽略无关语音；说话人区分尚未获得官方支持；在级联架构上，异步函数调用可以非阻塞地执行。结尾的愿望清单要求支持更多语言；Google 表示 Gemini 已正式支持24种语言，而 Klingon 仍可进行实验性尝试。

精读

1. Gemini 正开放更多推理与成本控制能力

Logan 给出的发布节奏非常明确：思考摘要已上线；Gemini 2.5 Pro 的思考预算预计将在两周左右随 GA 模型推出；关闭思考功能则希望在6月初上线。Gemini 2.5 Flash 已支持预算控制。
Google 正在测试摘要能否满足那些声称想要完整思考过程的开发者，Cursor 成为了早期反馈窗口。更大的目标，是让开发者在模型之上“尽可能获得更多控制权”。
隐式缓存会把重复上下文自动转化为成本节省——“你什么都不用做，它现在就能直接运行”——而显式缓存仍适用于开发者需要确保固定上下文持续处于缓存状态的场景。缓存还涉及延迟、Google 成本以及缓存材料规模之间的权衡。

2. 新模型入口瞄准语音、研究与生成式界面

Shrestha 个人最看重的是原生音频输出，尤其是模型能够在 Bengali 和 English 等语言之间切换。Matt Boso 在 Twitter 演示中展示了模型讲 Klingon，尽管 Klingon 并未获得官方支持。
URL Context 单独使用或与 Search 搭配，旨在从网页中提取更深层信息，同时尊重出版商生态。潜在用例包括开发者构建研究代理。
Swyx 评选的“被低估之选”Gemini Diffusion 引发了生成式 UI 讨论：一个对自身网站“没有预编译概念”的应用，可以随着用户点击生成代码，再由1,000 tokens 生成下一版界面。Swyx 认为这很可能是一个“杀手级用例”，但也指出，要将 Gemini Diffusion 按 Google 的质量标准产品化，仍需大量工作。
结尾的愿望清单强调应支持更多语言，以服务全球用户。文字记录显示，Gemini 已正式支持24种语言；对于 Klingon 等未获支持的语言，用户仍可进行实验性尝试。

3. Google 希望让专业能力回流到一个 Gemini

Google 内部嘉宾转述 DeepMind 管理层的观点：目标是打造一个主 Gemini 模型，即使专业分支必须先独立爬坡、避免对其他能力造成附带损害。真正困难、也最有价值的一步，是把这些能力重新合并回来。
Gemini 2.5 Pro 就是一个例子：整合推理能力后，多模态视频理解能力意外增强。这一提升被描述为能力组合的产物，而不是专门针对视频开展独立研发的结果。
讨论仍然保留了限定条件：即便 Gemini 正在引入交错式文本与图像能力，开发者仍会使用 Imagen 进行高质量、写实图像的生成与编辑。

4. Live API 进入生产环境后暴露出时长、工作流与供应商绑定成本

早期进入生产环境时最明显的缺口是会话时长：用户最初只能获得约15–20分钟音频和5分钟视频。Google 表示自己率先将视频输入推向市场，并正在加入滑动窗口和视频分辨率控制，目标是延长会话时长。
工具链是 Live API 早期就具备的能力，包括 Search 与 Code Execution 等组合。此后，Google 仍需改善函数调用和 Search 的表现，并持续推进这两项能力。
Google 内部的警告指向整个生态：文本生成在不同供应商之间切换相对轻量，但实时基础设施高度定制化，且并不具备良好的互操作性。未来，模型无关的基础设施或许能降低这种异常高的绑定程度。
有状态应用会进一步放大问题。游戏代理需要在多个状态之间切换，客服通话可能持续数小时，而屏幕引导工作流——例如 Shopify 使用 Cloudflare 演示 DNS 设置——可能需要修改系统指令，或在多个代理之间交接控制权。

5. 实时语音智能正在沿技术栈逐层推进

最初的 Live API 架构采用原生音频输入配合文本转语音输出，因为 NotebookLM 使用的 TTS 模型达到了理想的质量和延迟标准。这套架构仍然可用，同时 Google 也推出了音频到音频架构。开发者仍然“非常喜欢”组件化系统；Google 新发布的2个可控、可提示 TTS 模型当时尚未通过 Live API 提供。
语音活动检测体现了外围基础设施的负担：开发者可以调节灵敏度和前缀填充，也可以关闭 Google 的检测器、接入自己的方案。在延迟约500–700毫秒的目标下，把所有组件组合起来，仍是 Live API “最难的事情之一”。
Quinn 对 Pipecat 的描述体现了一个不断迁移的边界：框架负责轮次检测、上下文管理等问题；随着模型进步，一些成熟能力会迁入 API。与此同时，用例不断扩展，也会给框架带来更多工作。
在推理层之下，数据包路由必须以对话级延迟在互联网上传输音频，并且越来越多地传输视频。人类预期大约500毫秒内得到回应，与 AI 交互并不会放宽这一假设。
原生音频的实验性主动模式目前仅限于音频到音频架构，并经过训练，不会回应无关音频。模型可能能够通过声音区分2个人，但这一行为尚未获得官方支持。在级联架构上，异步函数调用允许工具在后台非阻塞执行；Google 希望最终也将这一能力带到原生音频架构中。

Marc Andreessen 揭示其在 a16z 最大的成功与失误世界加速分化下，我们的机会在哪里？ | 对谈绿洲资本合伙人张津剑