Google I/O 2026:Gemini Omni、Gemini 3.5 以及驱动自主式AI的计算层

Google I/O 2026 将谷歌AI战略的计算层重新置于中心。主题演讲充满了智能体、开发者工具、可穿戴界面和产品集成,但所有这些层都依赖于两个模型方向:Gemini Omni 和 Gemini 3.5。一个推动多模态创作和编辑。另一个通过行动推动前沿智能,尤其是通过 Gemini 3.5 Flash。
本文是更大的 Google I/O 2026 架构中心 中的计算层分支。开发者工具方面在 Antigravity、AI Studio 和 Google DevTools 中介绍。设备表面故事在 Android XR 和智能眼镜 中介绍。产品表面故事在 搜索、工作空间和购物中的智能产品 中介绍。
重要的是要避免将 Gemini Omni 和 Gemini 3.5 解读为一个通用的“新AI模型”公告。它们解决不同的产品和基础设施问题。Omni 是关于任意输入的创意生成,从视频开始。Gemini 3.5 是关于面向智能体、编码和长周期工作流的快速、行动导向的智能。这种分离对开发者、产品团队和平台架构师来说很重要。
主题演讲背后的计算层
谷歌自己的 I/O 2026 集合将活动围绕两个新模型展开:Gemini Omni 和 Gemini 3.5。Gemini Omni 被描述为在世界理解、多模态和编辑方面的飞跃,能够从文本、图像、音频和视频的输入创建输出,从视频开始。Gemini 3.5 Flash 被介绍为 Gemini 3.5 系列中的第一个模型,结合了前沿智能与行动。
- Gemini Omni 专注于多模态创作和编辑,从视频开始。
- Gemini 3.5 Flash 专注于面向智能体、编码和复杂工作流的行动级速度。
- 模型分离反映了谷歌更广泛的平台分离:创建更丰富的媒体,然后在产品和工具中更快地行动。
- 当这些模型连接到 Antigravity、AI Studio、搜索、工作空间、Android XR 和 Gemini 驱动的设备时,真正的战略价值才会显现。
模型故事不仅仅是更大的上下文或更好的演示。它是角色专业化:一边是创作,另一边是行动。— 计算层解读
Gemini Omni:从任意输入进行创作
Gemini Omni 是谷歌将推理与创作融合的最直接尝试。官方定位很明确:它可以从任何输入创建任何内容,从视频开始。该模型接受文本、图像、音频和视频的组合,然后生成基于 Gemini 现实世界知识的高质量视频。它还支持对话式视频编辑,这在实际创意工作流中可能比一次性生成更重要。
最后一点很重要。创意AI的实际价值很少仅仅是“生成一个视频”。生产工作流需要修改、替换、时机、风格一致性以及围绕变化的对话。如果 Omni 能在保持上下文的同时使编辑更具对话性,它就会超越新奇生成器,成为一种创意界面。
// Gemini Omni 应被视为创意工作流模型
input = { text: "在雨中的赛博朋克城市展示产品发布", image: "品牌参考.png", audio: "旁白.wav", video: "粗剪.mp4"
} output = GeminiOmni.generateVideo(input)
revision = GeminiOmni.edit(output, "让光线更温暖,并保持相同的产品设计")
对于构建媒体工具、电商产品视觉、教育内容、游戏原型、广告工作流或社交视频管道的团队来说,这是 I/O 2026 中最相关的部分。界面从手动时间线编辑转向基于意图的多模态编辑。这并不会消除创意判断,但会改变创意劳动的投入点。
Gemini 3.5 Flash:具有行动能力的前沿智能
Gemini 3.5 Flash 是计算故事的另一半。谷歌将 Gemini 3.5 系列描述为结合前沿智能与行动,并将 3.5 Flash 定位为该系列的第一个版本。重点在于智能体、编码、复杂的长期任务和现实世界的实用性。这种措辞并非偶然。它直接指向能够执行操作的系统,而不仅仅是回答问题的系统。
对于开发者来说,“Flash”之所以重要,是因为智能体工作流对延迟敏感。一个聪明但缓慢的模型可以用于研究或仔细写作。但它很难融入终端原生自动化、IDE循环、多步骤工具使用、后台智能体以及需要即时反馈的产品体验中。谷歌显然试图让快速的前沿行为成为智能体工作流的默认引擎。
// 经典模型用法
answer = model.generate("解释这个函数") // 智能体模型用法
plan = model.plan(task)
toolResult = tools.run(plan.nextStep)
verification = model.verify(toolResult) if verification.failed: rollback()
else: continueExecution()
这种转变就是为什么 Gemini 3.5 与 Antigravity 属于同一集群。Antigravity 需要一个能够规划、执行、验证并持续前进而不将开发环境变成等待室的模型。这就是计算性能成为开发者体验的地方。
为什么速度和行动应该在一起
谷歌主题演讲中关于速度的表述并非仅仅是营销手段。智能体系统会成倍增加延迟。一个简单的答案只需要一次模型往返。而一个多智能体工作流可能需要多次:规划、工具选择、代码编辑、终端执行、验证、修复、总结和人工审核。如果每一步都很慢,整个系统将变得不可用。
- 快速输出能改善交互式编码循环。
- 低延迟让多步骤智能体感觉不那么脆弱。
- 当智能体在后台维护任务中运行时,高吞吐量很重要。
- 稳定的推理很重要,因为更快的错误操作仍然是错误操作。
- 验证仍然至关重要,因为速度本身并不等于信任。
有用的智能体不是只回答一次的模型。而是能够持续行动,而不会让工作流感觉像排队一样的模型。— 智能体运行时视角
Gemini Omni 与 Gemini 3.5:不同任务,相同堆栈
理解 I/O 2026 计算公告最清晰的方式是区分任务。Gemini Omni 是一个多模态创作和编辑模型。Gemini 3.5 Flash 是一个面向智能体和编码的行动导向模型。它们是互补的,不可互换。一个产品团队可能使用 Omni 生成媒体,并使用 Gemini 3.5 Flash 来编排围绕该媒体的工作流。
// 产品工作流示例
creativeAsset = GeminiOmni.generateVideo(brief) agentPlan = Gemini35Flash.plan({ task: "Publish launch campaign", asset: creativeAsset, channels: ["YouTube Shorts", "landing page", "email"]
}) Gemini35Flash.execute(agentPlan, tools)
这就是谷歌所指的更广泛架构。创意模型生成更丰富的工件。行动模型协调围绕这些工件的任务。产品界面将这些能力暴露给用户。开发者工具提供编排和验证。设备界面使助手在更多场景中可用。
这对开发者意味着什么
开发者不应将 Gemini 3.5 Flash 仅仅视为另一个模型选项。它改变了可以在谷歌堆栈之上构建的应用程序形态。如果一个模型能够处理更长的任务序列、可靠地使用工具,并且运行速度快到足以支持真实工作流,那么应用程序就可以从孤立的 AI 功能转变为模型中介的过程。
- 代码智能体可以重构、测试和验证更大的任务单元。
- 产品智能体可以帮助用户在单个流程中从意图转向行动。
- 媒体应用可以将 Omni 生成与 Gemini 3.5 编排相结合。
- 搜索和 Workspace 功能可以从回答问题转向执行任务。
- 移动和 XR 界面可以将 Gemini 用作实时上下文层,而不是遥远的云助手。
风险在于在运营模型成熟之前过度构建。开发者仍然需要版本控制、评估、日志记录、成本控制、回退行为以及针对高影响操作的人工确认。更强的模型并不能消除对工程纪律的需求。它反而增加了这种纪律的价值。
这对产品团队意味着什么
产品团队应将 Gemini Omni 和 Gemini 3.5 解读为一个信号:谷歌希望 AI 成为整个生态系统的执行层。这既带来了机遇,也带来了风险。机遇是从用户意图到最终输出的路径更快。风险在于,如果智能体决策隐藏在精美的界面背后,产品行为可能变得不那么透明。
agenticProductChecklist = { userIntent: "clear", modelRole: "defined", tools: "permissioned", outputs: "reviewable", failures: "recoverable", costs: "measured", userControl: "explicit"
}
如果一个产品团队无法回答模型被允许做什么、如何评估以及用户如何从错误操作中恢复,那么该集成尚未准备好投入生产。当 Gemini 连接到搜索、Workspace、购物、Android 或可穿戴界面时,这一点尤其重要。
现实检验:基准测试并非产品
每次模型发布的风险都是基准测试中毒。更好的性能很重要,但生产价值取决于集成质量。一个模型可能更快更强,但由于提示词薄弱、工具策略松散、评估肤浅或回滚路径缺失,仍然可能在特定工作流中失败。
- 创意模型需要一致性、可编辑性和输出控制。
- 行动模型需要工具纪律、验证和安全的失败模式。
- 开发者模型需要在真实代码仓库中具有可重复的行为。
- 产品模型需要用户信任和清晰的控制边界。
- 平台模型需要版本控制、监控和成本可观测性。
发布模型吸引关注。运营模型决定它能否在生产中存活。— 工程现实检验
这与 Google I/O 2026 集群的契合点
本文涵盖集群的模型层。Google I/O 2026 主枢纽解释了完整的架构转变。Antigravity、AI Studio 和 Google DevTools解释了模型如何进入开发者工作流。Android XR 和智能眼镜解释了相同的智能如何进入可穿戴设备表面。跨搜索、工作空间和购物的智能体产品解释了当这些能力到达消费者和生产力产品时会发生什么。
本集群相关文章
- 主枢纽: Google I/O 2026:架构转型、智能体 AI 与统一生态系统现实检验
- 开发者工具: Google I/O 2026:Antigravity、AI Studio 和 Google DevTools
- Android、XR 和设备表面: Google I/O 2026:Android XR 和智能眼镜
- 智能体消费者产品: Google I/O 2026:跨搜索、工作空间和购物的智能体产品
最终视角
Gemini Omni 和 Gemini 3.5 定义了 Google I/O 2026 背后的计算分工。Omni 是创作层:多模态输入、视频输出、对话式编辑和基于世界的生成。Gemini 3.5 Flash 是行动层:为智能体、编码和长期任务提供快速前沿智能。它们共同解释了为什么主题演讲的其他部分呈现出那样的面貌。Antigravity 需要行动级模型。搜索和工作空间需要能够推理和执行的智能体。Android XR 需要实时上下文理解。主题演讲不仅仅是一个模型故事,但没有这个计算层,其余的故事就无法成立。
Related Articles

超越提示工程:一种更可靠的人工智能推理方法
大型语言模型未必是因为缺乏推理能力而失败。它们常常失败,是因为推理过程没有得到充分的约束、质疑或验证。本文提出一种与领域无关的方法论,将提示转化为一种结构化的认知过程:将事实与假设分离,生成相互竞争的假说,检验反证,应用证伪,并检查结论在替代性框架下是否仍然稳定。目标不是让模型“更少同意”,而是让它的结论更少依赖于用户最初的框架。

向量数据库、嵌入和重排序:检索的三个不同部分
嵌入表示含义,向量数据库检索候选结果,重排序器则精炼结果。了解这三个检索层在RAG中如何不同并协同工作。

托管代理框架与自托管代理循环:你得到什么,失去什么
“自托管代理”可能意味着截然不同的架构。本指南区分了托管式运行框架、自托管执行环境和完全自主运营的代理循环——并说明了团队实际需要哪种控制边界。

LLM从哪里获取数据?Python中的RAG数据源
LLM 并不会神奇地知道你的文件、数据库或 API。这个 RAG 系列的实用续篇用简单的 Python 展示了外部数据如何变成可检索的证据:从文本文件和 SQL 到全文搜索、嵌入、上下文组装以及最终的 LLM 调用。

人工智能何时应停止信任自身知识?——检索触发机制
AI 模型并非每个问题都需要检索。重要的问题在于知道何时其内部知识已不再足够。检索触发器是一个实用的决策边界,它决定 AI 系统何时应停止仅依赖模型知识,并在回答前获取外部证据。

从研究协议到通用AI推理框架
为严谨的AI辅助研究而开发的一套方法论,其可推广范围远超研究本身。通过将证据与假设分离、检验相互竞争的假设、控制提示框架、搜寻反证并应用领域特定的验证器,同一推理架构可以改进调试、软件设计、战略、技术分析以及AI辅助决策支持。

ZBT Z8102AX OpenWrt 21.02 固件评测:足够稳定,但能否面向未来?
ZBT Z8102AX 运行的是厂商修改版 OpenWrt 21.02 固件,内核版本为 5.4.246。实际测试中,该固件运行稳定,可保持路由器连续数日正常工作,但老旧的基础版本引发了关于安全性、调制解调器控制、升级路径及长期可维护性的重要问题。

企业AI架构:当AI进入公司时会发生什么变化
企业AI架构阐释了AI如何在数据权限、身份、许可、提供商、风险、治理、评估、合规和运营方面改变公司系统。

RAG失败了——但究竟是哪一层真正失败了?一种诊断方法
当RAG答案出错时,将问题归咎于检索或模型过于笼统。这种诊断方法将来源覆盖、查询构建、检索、排序、上下文组装、生成、证据归因和时效性逐一隔离,从而使实际故障能够被复现并修复。

如何判断一个AI智能体是否真正使用了正确的证据
AI代理可以引用来源,却仍然使用错误的证据。本文介绍一种实用方法,用于核查主张支持、来源权威性、适用性、出处,以及证据是否实际影响了答案。

什么是AI解决方案架构师?系统边界、职责与权衡
AI解决方案架构师将业务需求转化为生产就绪的AI系统,涵盖数据、模型、工具、安全、运行时、评估和运维。

ADR 与 NFR:架构决策与系统质量并非同一回事
ADR 与 NFR 解析:了解系统质量需求如何驱动架构决策、ADR 如何记录权衡取舍,以及为什么验证保持独立。