Gemini Robotics 2 把大脑拆成三个模型：机器人通用智能仍然需要身体适配
作者：林岚｜OC 开发者生态编辑
林岚
据 Google DeepMind 发布，Gemini Robotics 2 并不是一个包办所有工作的单一模型，而是三层系统：Gemini Robotics 2 负责视觉、语言到动作的全身控制；Gemini Robotics ER 2 负责具身推理、任务规划和多机器人协调；Gemini Robotics On-Device 2 则面向本地低延迟运行和新硬件适配。
一句话结论：Google 展示的是一套更完整的机器人软件栈，不是已经完成的“通用机器人”；模型能规划和操作仍要依赖具体机身、传感器、控制频率、安全区域和大量适配数据。
把三个模型分开有明确工程理由。高层推理模型擅长理解“把房间整理好”这类模糊目标，却不适合以几十或几百赫兹直接控制关节。视觉语言动作模型把环境观察转换成动作序列，端侧模型则在网络不稳定或需要快速反馈时执行。分层能让昂贵推理低频运行，让实时控制留在本地。
Google 的演示包含移动、抓取、放置、整理和多机器人协作等任务。相比只控制机械臂，所谓“全身智能”强调机器人需要同时处理底盘、躯干、手臂和手指，并在移动时保持平衡、避障和视野。一个看似简单的弯腰捡物动作，背后可能涉及路径规划、碰撞检测、力控制和连续重规划。
但演示视频最容易隐藏的是环境约束。机器人是否在预先建图的场地、使用哪些物体、失败多少次、任务速度如何、遇到人类或透明物体会怎样，这些都决定系统能否从实验室进入真实生产。模型“看懂”任务，不等于硬件有足够精度和可靠性完成任务。
On-Device 版本尤其值得关注。机器人如果每个动作都等待云端响应，延迟和断网会成为安全问题，本地模型还能减少敏感视频上传。不过端侧计算受功耗和散热限制，能力通常低于云端模型，因此系统仍需要决定哪些动作可本地自主执行，哪些必须暂停并请求高层确认。
Google 还强调安全评测与人机协作机制。这里不能只看模型是否拒绝危险指令，还要看速度限制、紧急停止、力矩阈值、地理围栏和故障状态。机器人安全不是聊天模型增加一段系统提示，而是从机械结构到软件控制的完整冗余。
关键事实
- 来源：Google DeepMind 官方发布
- 涉及模型：Gemini Robotics 2、Gemini Robotics ER 2、Gemini Robotics On-Device 2
- 核心技术：视觉语言动作、具身推理、全身控制、多机器人协调与端侧推理
- 当前边界：官方展示和合作测试不等于大规模商业部署
OC 判断
三模型拆分比“一个大模型控制一切”的叙事更可信，因为它承认机器人系统有不同时间尺度。真正的难点会落在接口：高层计划如何变成可验证动作，端侧模型何时交回控制，硬件变化后需要多少数据重新适配。先别急着激动，能完成演示和能每天工作八小时仍是两件事。
为什么重要
- 对开发者：机器人应用会需要规划、控制和硬件适配之间的标准接口，而不只是调用一个模型 API。
- 对企业：采购时应要求任务成功率、人工接管率、循环时间和故障恢复数据。
- 对用户：端侧模型有助于降低延迟和隐私风险，但不能替代物理安全设计。
评论
围绕这篇文章补充信息、提出问题或分享观察。