Google 发布 Gemini Robotics 2 与 ER 2
三类模型分担动作、端侧执行与高层编排，开放范围和评测边界各不相同。
本文要点
- Robotics 2 把同一 VLA checkpoint 扩展到全身控制、双手操作和多种机器人形态。
- On-Device 2 继承跨形态迁移能力，并用少量新数据适配不同双臂机器人。
- ER 2 从空间推理扩展到持续视频进度判断、工具编排和多机器人协作。
阅读辅助
先看数字、证据和来源，再读正文。
Gemini Robotics 2、On-Device 2 与 ER 2 承担不同系统层级，不能视为同一模型的三种部署模式。
2025-03-12 · Google 首次发布 Gemini Robotics VLA 与 Robotics-ER，区分动作执行和具身推理。
三个模型，一次系统级发布
Google DeepMind 在 2026 年 7 月 30 日连续发布两篇文章，把 Gemini Robotics 2、Gemini Robotics On-Device 2 与 Gemini Robotics ER 2 放进同一套机器人系统。新闻增量落在全身动作、本地执行、长程编排和异构机器人协作四个方向。
可以确认的范围很清楚：Robotics 2 与 On-Device 2 都是输出机器人动作的视觉—语言—动作模型；ER 2 是负责观察、规划、调用工具和追踪任务进度的高层视觉语言模型。它们的输入输出、运行位置和开放渠道并不相同。
性能证据仍主要来自 Google 自己的评测与视频。官方展示了 Apollo 2、Franka Duo、Spot 等平台，也披露部分视频理解指标，但没有给出跨现场总体成功率、连续运行故障率或人工接管率。演示可以证明接口打通，不能替代通用可靠性结论。
机器人开发者现在能直接试用的是 ER 2 的预览端点。需要电机控制能力的团队仍要申请早期访问，并把模型与本体控制器、硬件安全、网络和现场流程组合起来评估。
三层职责怎样衔接
Gemini Robotics 2 是动作层 VLA。它接收视觉和语言输入，输出电机控制，覆盖人形机器人的行走、下蹲、伸展、抓取和双手操作。Google 称同一 checkpoint 控制了 Apollo 2 的两种手部配置，以及带 Robotiq 夹爪的 Franka Duo。
On-Device 2 也是 VLA，但目标是本地推理。它面向网络延迟高或无法联网的场景，输入还包括机器人本体感知数值，输出为动作数值。模型卡把当前重点限定在双臂操作，并明确高自由度机器人控制和分布外任务仍是局限。
ER 2 位于高层。它从文本、图像、视频和音频理解环境，把低层 VLA、导航 API 或其他控制接口声明为工具，然后拆分任务、发起调用、监控连续视频，并在步骤失败时调整计划。它输出文本或工具调用，不直接等同于电机控制器。
| 模型 | 系统角色 | 主要输出 | 7 月 30 日开放状态 |
|---|---|---|---|
| Gemini Robotics 2 | 全身与灵巧动作 VLA | 电机控制 | 面向 early-access partners |
| Gemini Robotics On-Device 2 | 本地低延迟动作 VLA | 机器人动作数值 | 仅向 Trusted Testers 提供 |
| Gemini Robotics ER 2 | 高层具身推理与编排 VLM | 文本、计划与工具调用 | Gemini API、AI Studio 为 Preview |
| ER 2 企业入口 | 企业 Agent Platform 渠道 | 同一高层模型能力 | Private Preview |
这里最容易混淆的是“可用”。Google 的发布稿称 ER 2 已向开发者公开，但开发文档同时把 gemini-robotics-er-2-preview 与流式端点标为 Preview。因此准确表述是：开发者已有公开预览入口，产品状态仍不是稳定版承诺。
企业渠道也不能与 API 状态合并。Gemini Enterprise Agent Platform 明确处于 private preview。Robotics 2 与 On-Device 2 则没有同等公开 API；前者面向 early-access partners，后者模型卡写的是 select Trusted Testers。
长程任务的数字只属于 ER 2
Google 对 ER 2 的系统描述是：它观察房间，推理完成任务需要的步骤，协调 VLA 执行动作，并追踪进度直至结束。官方称更长任务序列可持续数分钟、涉及数百次决策。这两个量级描述的是该编排场景，不是模型的时长上限。
原文没有公布这些长程任务的样本数、总体成功率、最长无故障运行时间和人工接管比例。数分钟也不能外推为机器人可以稳定工作数小时；数百次决策同样没有说明每次决策的正确率，以及错误是否会沿工具链累积。
ER 2 新增的关键能力是持续视频理解。进度分类把每帧分进五个区间，Google 自报准确率为 57.4%。moment finding 用于定位关键事件发生的具体视频帧，官方给出的准确率是 91.3%，平均绝对时间距离为 0.96 秒。
| 厂商评测或描述 | Google 公布结果 | 适用范围 | 仍缺少什么 |
|---|---|---|---|
| 长程任务序列 | 数分钟、数百次决策 | ER 2 编排 VLA 与工具 | 成功率、重试率、接管率 |
| 视频进度分类 | 57.4% 准确率 | 五档任务进度判断 | 数据集规模与独立复现 |
| 关键时刻识别 | 91.3% 准确率 | 定位关键事件视频帧 | 跨相机与现场泛化 |
| 时间定位误差 | 0.96 秒 | moment-finding 平均绝对距离 | 分布、尾部误差和安全阈值 |
| 新本体适配 | 通常少于 200 例 | 新双臂机器人形态 | 每种任务的数据构成 |
Google 还称 moment finding 以更低计算量达到 4 倍执行速度。发布稿没有在正文中给出完整比较对象、硬件和成本口径，因此它只能作为厂商评测摘要，不能写成 ER 2 在所有机器人任务上统一快四倍。
动作层从上半身扩展到全身
2025 年 3 月的初代 Gemini Robotics 主要展示桌面操作与空间推理。到 Robotics 1.5，系统已形成 ER 高层规划、VLA 低层执行的分工，并强调跨机器人形态迁移动作。此次 Robotics 2 把动作范围扩展到整个人形机器人。
Apollo 2 的演示包含走向目标、取起浇水壶、移动到货架并放进底层绿色箱子。另一组演示使用五指、22 自由度的 SharpaWave 手完成打结和封闭密封袋，也用平行夹爪执行紧密装箱。
这些案例说明同一模型 checkpoint 可以连接差异明显的执行器，但官方图注同时承认，多指灵巧操作仍具挑战。正文也写明移动速度、精度和达到人类级灵巧度都需要继续推进。演示中完成任务不代表每次执行都成功。
Apptronik 的 Apollo 2 产品页补充了硬件边界：本体还有 Artemis 负责感知、规划、控制、安全和任务执行，Fleet Connect 承担机群运维。Gemini 模型只是完整机器人栈的一部分，现场可靠性还取决于执行器、低层控制和运营系统。
端侧模型解决延迟，仍有本体边界
On-Device 2 继承 Robotics 1.5 的 motion transfer，并针对本地设备优化。Google 称它能用数小时适配时间和通常少于 200 个示例迁移到新双臂平台，演示对象包括 Dexmate、SO101 和 Trossen。
这个口径与 2025 年初代 On-Device 的“用 50 至 100 个 demonstrations适配新任务”不相同。初代数字讲任务微调，二代的少于 200 例讲新机器人形态适配；两者不应拼成数据效率提升或退步的时间序列。
模型卡把 On-Device 2 定位为双臂机器人系统中的核心组件，并称它在域内任务上可接近更大的 Robotics VLA。相同页面也指出，它对分布外任务和高自由度机器人控制能力有限，移动平台与全身控制风险不在主要评测范围内。
因此，本地运行带来的确定收益是摆脱持续网络连接并减少云端往返。具体延迟、功耗、内存、支持芯片和热设计尚未公开。仅凭“on-device”无法判断它是否能在任意商用机器人计算平台上实时运行。
多机器人协作展示了编排接口
Google 用 Apollo 2 与 Franka Duo 整理杂乱车库，展示 ER 2 在高层拆分“做什么、去哪里、何时交接”，再把动作交给不同机器人。Spot 演示则把导航和机械臂动作作为 API，由 ER 2 通过 Live API 流式编排。
样例仓库为这项发布提供了可核查的工程锚点。Google 在 7 月 29 日 22:23 UTC加入 Live API 示例，并于 7 月 30 日 14:46 UTC把入门 notebook 更新到 ER 2。提交时间均与当日发布相邻，但仓库样例仍属于接入示范。
生产级协作还要回答身份、权限、状态一致性和故障隔离问题。某台机器人失联时，另一台是否能安全接管；两个本体争用同一空间时由谁仲裁；高层模型发出的自然语言计划如何映射为可审计动作，这些都没有由视频演示解决。
安全层有新评测，也有明确缺口
Google 同步发布 ASIMOV-Agentic，用来评估高层代理能否拒绝违反约束的任务、识别 VLA 无法执行的子任务、请求人工澄清，并在人靠近时调用停止工具。安全报告还在 Apollo 2 上测试了真实停止行为。
报告给出的边界很重要。它主要评估高层语义推理和编排，没有覆盖认证硬件、冗余机制、实时系统保证等功能安全架构。报告甚至显示，在某些人类接近评测中，降低漏停与减少误停之间存在明显权衡。
ER 2 模型卡进一步要求用户在生产、商业或公共环境使用前自行审慎判断，并禁止将 Robotics Models 用于医疗、交通等故障可能导致伤亡或财产损失的安全关键工作。预览入口不等于生产许可。
Google 这次最有价值的变化，是把机器人智能公开整理成可组合的三层：ER 2 处理语义、时间和工具编排，Robotics 2 负责高能力动作，On-Device 2 负责本地执行。每层可以单独评测，也暴露出层间错误传播的新问题。
这种分层对机器人公司有现实意义。硬件团队不必等待一个模型同时解决规划、动作、端侧算力和安全；它们可以先替换其中一层，并保留既有导航、控制器和机群平台。Google 也因此更容易让 ER 2 通过 API 接入不同厂商的机器人栈。
当前证据还不足以证明“一个大脑适配所有机器人”。同一 checkpoint 的多本体演示很有方向性，但多指操作仍弱，端侧硬件指标未公开，长程任务缺少总体成功率，多机器人协作也没有展示长期运行和故障降级。
竞争焦点会从单次抓取演示转向系统可靠性。谁能公开跨硬件成功率、长任务恢复率、端侧延迟与能耗，以及模型决策和功能安全之间的责任接口，谁才更接近可采购、可运维的机器人平台。
下一步用哪些指标判断进展
最先需要的是分母。Google 已公布若干成功演示和视频理解准确率，后续应披露每类动作的测试次数、任务分布、失败类型和置信区间。全身控制、多指手和普通夹爪应分别统计，避免用平均值掩盖最难的执行器。
长程编排应报告端到端完成率、平均重试次数、恢复后成功率、人工接管率和连续运行时长。ER 2 的单步视频指标只有与这些系统指标联动，才能说明“数百次决策”是否带来可控的累计错误。
On-Device 2 则需要公布目标芯片、模型占用、端到端动作延迟、功耗和断网运行结果。少于 200 例的本体适配也应拆出示例时长、采集成本、任务覆盖和新硬件改造量，才有可比较的数据效率。
多机器人协作最终要接受异常场景测试：通信中断、地图不一致、工具调用超时、空间冲突和单机故障。安全评测还需连接真实控制器与认证流程，使高层“应该停止”的判断能可靠转化为物理系统按时停止。