本文永久链接 – https://tonybai.com/2026/09/17/openmind-om1-android-for-robots

大家好，我是Tony Bai。

【导读】

具身智能赛道正在被重新分层——有人做大模型，有人做机器人本体，有人做仿真，却很少有人关注“大脑和身体之间”那层看不见的胶水。硅谷公司OpenMind要做的正是这一层：OM1，一个用Go语言重写、号称要成为“机器人界安卓”的开源AI运行时。它不训练模型，不生产机器人，却试图让同一套AI能力跨越人形机器人、四足机器人、手机App乃至仿真环境自由迁移。

【文章要点】

  • OM1不是具身智能模型，而是“AI Agent Runtime ＋ 硬件抽象层（HAL）”，类比对象是Android系统，而不是某个App；
  • 核心机制是“自然语言数据总线”（NLDB）——传感器数据被压缩成人类可读的自然语言，在多个LLM之间流转、决策；
  • 技术路线上完成了从Python到Go的整体重写，换来更低延迟、更小内存占用、单二进制部署；
  • 通过JSON5配置文件加插件化的Input/Action/LLM机制，理论上一套Agent逻辑可以跨人形机器人G1、四足机器人Go2、Gazebo/Isaac Sim仿真环境运行；
  • OpenMind已获Pantera Capital领投的2000万美元融资，并在向“机器人App Store”和FABRIC机器间协作协议扩展野心。

具身智能赛道，也要有一次“安卓时刻”？

生成式大模型和Agent浪潮把人们的注意力拉向了虚拟世界——写代码的Agent、订机票的Agent、做研究的Agent。但智能显然不会被关在屏幕里。具身智能被普遍认为是下一个万亿级赛道，而这条赛道正在迅速分化出清晰的产业分工：

  • 有人做具身智能大模型（VLA、世界模型、多模态基座）；
  • 有人做机器人本体（人形、四足、轮式的“身体”）；
  • 有人做仿真平台（Isaac Sim、Genesis、MuJoCo，负责在虚拟世界里“练技能”）；
  • 也需要有人做连接层——把上面这些五花八门的大脑和身体粘合起来。

OpenMind要做的正是最后这一层。它给自己的定位是“机器人界的Android”：把机器人平台看成手机，OM1就是跑在这些平台上的操作系统。这个类比出自公司自己的口径，也被TechCrunch等外媒直接采用做了标题。

先纠正一个容易踩的坑：OM1不是“具身智能模型”

很多人第一次听到OM1，会下意识把它和某个具体的机器人控制算法或VLA模型划等号。这是最大的误解。

官方对OM1的定义非常克制：

Modular AI Runtime / AI HAL for Robots（面向机器人的模块化AI运行时／硬件抽象层）

翻译能懂的话就是：OM1本身不生产智能，它负责调度和编排智能。它站在AI模型（LLM、VLM、VLA、Policy）和机器人硬件（ROS2、Zenoh、机器人SDK）之间，把“用什么模型思考”、“用什么身体行动”这两件事解耦开。

这里有一个更关键、也更容易被忽略的事实：给一台裸机器人装上OM1，它不会突然学会走路。

OM1假设机器人下层已经存在一套成熟的硬件抽象层（HAL）——运动轨迹执行、电池与温控管理、IMU／LIDAR／磁力计标定，这些传统机器人工程的活儿，OM1完全不碰。如果你的机器人没有这样的HAL，官方文档明确写道，你仍然需要通过强化学习、仿真训练、自定义VLA等传统机器人学手段先把它做出来。

换句话说：OM1不是机器人控制器的替代品，而是在已有控制基础设施之上，再叠加一层多模态AI智能。

把具身智能拆成五层，OM1到底站在哪一层

理解OM1定位最有效的方式，是把“具身智能”这个笼统的词拆成一个技术栈：

OM1稳稳地站在第③层：向上对接LLM／VLM／VLA／Policy这些“思考能力”，向下对接ROS2／Zenoh／DDS／机器人SDK这些“执行能力”。

这也解释了它和另一个常被并列讨论的项目——LeRobot——之间的关系。两者不是竞争关系，而是分工关系：

LeRobot教机器人“怎么学会一项技能”，OM1负责“怎么把已经具备的智能能力，稳定地运行在任意一台机器人上”。同理，OM1也不打算取代ROS2——它明确支持ROS2、Zenoh、CycloneDDS等多种中间件（官方目前更推荐轻量的Zenoh），机器人层面的通信基建仍然交给这些成熟方案。

“机器人安卓”这个类比，为什么这次相对贴切

先看今天Android解决的问题：

开发者写一个App，不需要关心它最终跑在三星还是小米的手机上——Android Framework和HAL替他们屏蔽了硬件差异。

OM1想复制的正是这套逻辑：

开发者理论上只需要写“去厨房”、“捡起红色的苹果”这样的高层指令，至于这句话最终要转译成Unitree Go2的cmd_vel速度指令，还是Isaac Sim里的虚拟关节角度，交给OM1下层的硬件插件去处理。这正是官方反复强调的hardware agnostic（硬件无关）——README里把人形机器人、四足机器人、TurtleBot教育机器人、Gazebo、Isaac Sim并列在同一张能力清单里，本身就是这个逻辑的体现。

这个类比之所以在人形机器人领域格外有市场，是因为行业正遭遇一个典型的“硬件趋同、软件破碎”困境：Unitree G1、H1，还有UBTech、Figure等各家机器人的SDK、通信协议、传感器数据格式彼此互不兼容。

如果每一家机器人都自建一套AI软件栈，AI能力就永远无法规模化复用。OpenMind创始人、斯坦福教授Jan Liphardt在接受TechCrunch采访时表达的核心逻辑正是：人形机器人正在从“重复执行固定任务”走向“需要理解人类意图的家庭／社会场景”，而这需要一套更像操作系统、而不是更像固件的软件层。

核心设计：让传感器和大模型“说同一种语言”

如果说“硬件无关”是OM1对外的定位，那么它内部真正有技术含量的设计，是一条叫做自然语言数据总线（Natural Language Data Bus，NLDB）的机制。

OM1的思路很反直觉：它不用向量、张量这类机器友好的中间表示做模块间通信，而是直接用自然语言。摄像头看到了什么、麦克风听到了什么、机器人电量还剩多少——所有这些原本是结构化数字信号的东西，先经过一层“AI压缩／captioning”，转成一句人话，再喂给决策层的LLM。

官方文档给出的示例消息大致是这种形态（内容为示意，非原文摘录）：视觉输入被描述成“看到一个人，正微笑着指向椅子”；声音输入被转写成具体的语音指令文本；里程计和电量则以简短的数值形式一并附上。这些片段汇总进一个叫做State Fuser的模块，被压缩成一段完整的情境描述，作为决策层的输入。

这套设计的合理性，OpenMind团队在其技术论文《A Paragraph is All It Takes: Rich Robot Behaviors from Interacting, Trusted LLMs》里做了论证：最基础的系统由四个LLM通过自然语言总线通信，即使数据融合周期只有1Hz，中枢数据总线的信息速率被压缩到接近人脑处理自然语言的水平（约40 bits/s），依然能在多种任务上跑出不错的机器人行为。用自然语言做总线还带来一个额外好处——人类可以直接读懂机器人的“内心独白”，这在调试和安全审计上价值不小。

在决策层，OM1的典型部署会同时挂载三个及以上的LLM，各自分工不同：

角色 部署位置 职责 典型响应时延
Fast Action LLM 本地或云端小模型 处理紧急、时间敏感的动作 约300毫秒
Cognition／Core LLM 云端大模型 复杂推理、长期规划 约2秒
Mentor／Coach LLM 云端模型 以“第三方视角”复盘人机交互质量，每30秒生成一次点评反馈给Core LLM 秒级到分钟级

这些LLM共同受一套用自然语言写成的“系统宪法”约束——配置文件里的system_governance字段。比较有意思的是，OpenMind还支持把这类行为准则写入以太坊等公开、不可篡改的账本，用去中心化账本的透明性和可追溯性，为机器人行为约束提供额外的信任层。

架构全景：从传感器到动作的一条流水线

把上面几个模块串起来，就是官方文档给出的完整数据流：

值得一提的是HAL这一层的职责边界——它负责把“轻轻捡起红苹果”这样的高层意图，翻译成具体的机械臂舵机指令序列，很多时候这层代码是既有的ROS2功能，或者被Docker化后通过DDS／websocket和OM1对话，OM1并不越权替代它。

为什么放弃Python，用Go重写整个运行时

这是这次调研中最值得工程师关注的一个细节：OM1最初是纯Python实现，但目前官方新开发已经全面转向Go，Python版本被标记为deprecated（不再维护）。

官方给出的重写动机很直接：

  • 更低延迟：机器人决策链路里，每一环节的延迟都会累加成人机交互的“迟钝感”；
  • 更高效的并发：多路传感器输入、多个LLM调用需要并行处理；
  • 更小的内存占用：面向Jetson系列这类边缘计算设备，Python运行时的内存开销是明显负担；
  • 更简单的部署：Go可以编译成单一二进制文件（连Zenoh的C库都一并打包），不再需要在机器人上维护一整套Python虚拟环境。

这个选择本身也印证了OM1的定位——它不是一个追求算法灵活性、需要频繁调参调模型结构的训练框架（那种场景Python生态无可替代），而是一个要长期稳定运行在机器人边缘设备上的系统级运行时，这正是Go语言的舒适区。

类比一下就更清楚：Android选择Java／Kotlin，是因为手机App开发需要面向海量第三方开发者的生态友好性；而OM1选择Go，是因为机器人运行时更看重系统稳定性、并发效率和边缘部署的资源可控性——两者面对的工程约束并不相同，这也是“安卓类比”不能照搬到底的地方之一。

从项目结构也能看出这是一次相当彻底的系统级重写：

OM1/
├── cmd/                主入口
├── config/             JSON5配置文件
├── internal/
│   ├── runtime/        核心运行时管理
│   ├── fuser/          输入融合逻辑
│   ├── llm/            LLM集成
│   ├── mcp/            MCP客户端与编排
│   ├── zenoh/          Zenoh通信（CDR编解码、会话管理）
│   └── ...
└── plugins/
    ├── inputs/         ASR、VLM、人脸检测等输入插件
    ├── actions/        speak、emotion、navigation、unitree等动作插件
    └── llm/             OpenAI、Gemini、DeepSeek、Ollama等LLM插件

整个系统由一个以hertz字段设定的固定频率主循环驱动：每一拍都去抓取各路输入的最新数据，融合成一段文字，发给一个或多个LLM，再把LLM的响应转译成真实动作。

需要指出的是，这个主循环的频率通常在1Hz量级，负责的是机器人的“注意力和工作记忆”节奏；而真正的物理稳定控制——比如四足机器人的步态维持——仍然由50到500Hz的独立控制回路在底层硬件上运行，两者互不冲突。

模块化配置：一个JSON5文件定义一台机器人的“性格”

OM1把Agent的所有行为——用什么LLM、接入哪些传感器、拥有哪些动作能力、系统提示词是什么——都收敛进一份JSON5配置文件。这也是它“跨机器人复用”承诺能够落地的关键：换一台机器人，理论上只需要换配置文件里的Action插件，Agent的思考逻辑可以原样保留。

配置支持“单模式”和“多模式”两种写法。多模式配置尤其有意思，它允许一个Agent拥有多套“人格状态”，并通过关键词触发在状态之间切换，本质上是一台简化的状态机：

一份精简后的配置大致长这样（字段经简化，仅作示意）：

{
  version: "v1.1.0",
  default_mode: "welcome",
  cortex_llm: {
    type: "OpenAILLM",
    config: { agent_name: "Bits", history_length: 10 },
  },
  modes: {
    welcome: {
      system_prompt_base: "你是Bits，一只友好的机器狗，正在第一次见到用户……",
      agent_inputs: [{ type: "VLMGemini" }, { type: "GoogleASRInput" }],
      agent_actions: [{ name: "speak", connector: "elevenlabs_tts" }],
    },
    conversation: {
      system_prompt_base: "你在对话模式，专注于有意义的交流……",
      agent_inputs: [{ type: "GoogleASRInput" }, { type: "VLMGemini" }],
      agent_actions: [{ name: "speak", connector: "elevenlabs_tts" }],
    },
  },
  transition_rules: [
    {
      from_mode: "welcome",
      to_mode: "conversation",
      trigger_keywords: ["talk", "chat", "tell me"],
    },
  ],
}

输入端（agent_inputs）、决策端（cortex_llm）、动作端（agent_actions）都是可插拔的注册机制——新增一种传感器、接入一个新的LLM厂商、或者对接一款新机器人的动作接口，本质上都是写一个新插件、注册进对应的目录即可，不需要改动核心运行时代码。这也是“模块化”这个词在OM1语境里的真实含义。

动手实践：不用买机器人，先在仿真里跑一只“数字机器狗”

具身智能最大的门槛之一是硬件成本。好消息是，OM1把仿真环境当作一等公民支持——不过需要先纠正一个常见的期待：OM1目前官方明确支持的仿真器是Gazebo和Isaac Sim，并没有原生的MuJoCo集成（MuJoCo更多被用在偏底层的强化学习训练场景，和OM1这种偏上层认知决策的定位不完全重叠）。因此下面的实操示例以官方文档给出的Gazebo＋Unitree Go2四足机器人仿真为例。

整体思路是：Gazebo负责物理仿真和视觉渲染，ROS2＋Zenoh桥负责把仿真里的机器人状态和OM1连接起来，OM1本身完全不知道自己控制的是真实机器人还是仿真机器人——这正是“硬件抽象”设计发挥作用的地方。

环境准备（Ubuntu 22.04）：

# 1. 安装ROS2 Humble及构建工具
sudo apt install ros-dev-tools
sudo apt install ros-humble-rmw-cyclonedds-cpp
sudo apt install ros-humble-rosidl-generator-dds-idl
source /opt/ros/humble/setup.bash

# 2. 安装uv（Python包管理器，仿真侧工具链使用）
curl -LsSf https://astral.sh/uv/install.sh | sh

拉取仿真工程并编译：

git clone https://github.com/OpenMind/OM1-sim.git
cd OM1-sim
sudo rosdep init      # 若本机首次使用rosdep，只需执行一次
rosdep update
rosdep install --from-paths . --ignore-src -r -y
colcon build

uv venv --python 3.10
source .venv/bin/activate
uv pip install .

启动Gazebo仿真环境：

source install/setup.bash
ros2 launch go2_gazebo_sim go2_launch.py

此时Gazebo和RViZ窗口会同时弹出，画面里是一只虚拟的Unitree Go2。

打通Zenoh桥（让OM1能“看见”仿真世界）：

zenoh-bridge-ros2dds -c ./zenoh/zenoh_bridge_config.json5

配置API Key并启动OM1本体：

export OM_API_KEY="<你的API Key>"    # 从OpenMind Portal获取
CONFIG=unitree_go2_autonomy USE_SIM=true make dev

跑起来之后，你可以打开新终端用键盘遥控虚拟机器狗，验证整条链路是否打通：

ros2 run teleop_twist_keyboard teleop_twist_keyboard
# i 前进  , 后退  j 左转  l 右转  k 停止

如果一切正常，你会看到：终端里持续打印OM1融合后的状态描述（类似“你看到一名用户，距离3米……”这样的自然语言日志）、LLM的决策输出，以及Gazebo里虚拟Go2随之做出的动作响应。这条链路完整验证了本文第六节那张架构图——从仿真传感器数据，到自然语言总线，到LLM决策，再到动作执行，全部跑通，且全程不需要一台真实机器人。

小贴士：如果你有NVIDIA GPU，也可以换成物理更精确的Isaac Sim路线，官方同样给出了Go2和G1两款机型的仿真支持，配置方式与上面大同小异，只是仿真侧换成了docs.openmind.com/simulators/isaac-sim.md里的流程。

生态与野心：从Robot OS，到Robot App Store，再到FABRIC

如果只把OM1理解成“给机器人接大模型的工具”，会低估OpenMind真正想做的事。把最近一两年的动作连起来看，它的路线图正在从“机器人操作系统”向更大的目标扩张：

第一步，是把自己做成事实标准的Runtime。OpenMind由斯坦福教授Jan Liphardt于2024年创立，2025年8月由Pantera Capital领投获得2000万美元融资，官方GitHub仓库目前有约2.9千星标、近千次Fork，社交媒体上曾出现三天内超过18万人报名等候名单的传播效应，短期内确实做到了在开发者圈层里“出圈”。

第二步，是往“机器人App Store”方向推进。据相关报道，OpenMind正尝试把机器人的行为、模型和任务逻辑打包成可以像手机App一样被安装、分发、更新的单元——如果这个方向走通，开发者未来面对的将不再是“开发一整台机器人”，而是“开发一个可以安装到任意兼容机器人上的技能包”。

第三步，是叠加一层叫FABRIC的协作协议。如果说OM1解决的是“一台机器人内部怎么调度AI”，FABRIC瞄准的则是“机器人之间怎么互相通信、协作、共享能力和身份验证”——这一层如果做成，OM1和FABRIC合起来就不只是单机的操作系统，而更接近一套面向多机协作的Physical AI基础设施。

这条演进路径，也让“安卓”这个类比开始显得不够用了——Android解决的是“一部手机怎么跑App”，而OpenMind真正想解决的问题更接近：“如果未来世界上有一百种人形机器人、一千种服务机器人，同一个AI Agent能不能像今天的手机App一样，一次开发、到处运行、彼此协作？”

写在最后：这个类比的边界在哪里

把OM1叫做“机器人安卓”是一个足够抓人眼球、也基本站得住脚的类比——模块化架构、硬件无关、开源生态、平台化野心，这些特征确实和Android的成功路径高度相似。

但至少有两点值得保留判断：

第一，Android面对的硬件差异，本质上是同一物理形态（手持屏幕设备）下的参数差异；而机器人之间的差异要深刻得多——四足和人形的自由度、传感器配置、运动学模型完全是两个物种，HAL这一层能屏蔽到什么程度，仍然要看实际工程落地情况，而不只是架构图上的一层方框。

第二，OM1还嵌入了不少Android所没有的独特设计，比如把系统宪法写入区块链、以及FABRIC这种去中心化机器间协作协议，这些选择背后有着相当鲜明的Web3基因，是否会成为主流机器人软件栈的标配，目前还是一个开放问题。

不过无论这场“安卓时刻”最终会不会真的到来，OM1本身提供的这套“自然语言数据总线＋多LLM协同决策＋模块化HAL”的设计范式，已经是当下理解“具身智能软件工程该怎么落地”的一个很好的样本——尤其是对习惯了从软件系统视角切入的工程师来说，比起直接一头扎进某个VLA模型的训练细节，从OM1这样一个运行时项目入手，可能是一条更平滑的入门路径。

参考资料

  • OpenMind/OM1 GitHub仓库：https://github.com/OpenMind/OM1
  • OM1官方文档：https://docs.openmind.com/
  • 技术论文《A Paragraph is All It Takes: Rich Robot Behaviors from Interacting, Trusted LLMs》：https://arxiv.org/abs/2412.18588
  • TechCrunch报道：“OpenMind wants to be the Android operating system of humanoid robots”
  • Pantera Capital投资博客：“Investing in OpenMind”

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。