开源鸿蒙今日发布 EmbodiedAI 1.0.1，集成 MuJoCo 和 Gazebo，兼容 ROS 生态，已在人形机器人、机器狗、服务机器人三类本体上完成验证。这是一次工程性升级，不是噱头。

开源鸿蒙押注机器人：EmbodiedAI 1.0.1 的真实进度

6 月 5 日，开源鸿蒙开发者大会现场，具身智能 PMC（筹）委员刘小飞把 EmbodiedAI 1.0.1 推到了台上。版本号小步迭代，但内容并不小：导航规划、运动控制、仿真开发、硬件适配四条主线都做了升级，原生模拟器、MuJoCo、Gazebo 三套仿真环境一次性整合进来，ROS 兼容继续保留，人形机器人、四足机器狗、商用服务机器人三类本体的适配验证全部走完。源码当天开放。

这个动作的信号比版本号要响。开源鸿蒙过去几年一直在做"全场景设备 OS"这件事，从轻量无屏一路打到带屏标准设备，再到现在把具身智能单独立项。把机器人当成一个独立的设备品类来运营，意味着它不再只是"鸿蒙能跑在机器人上"，而是要做一套面向机器人形态的工具链和运行时。

开源鸿蒙开发者大会现场，EmbodiedAI 1.0.1 发布主题演讲

1.0.1 到底升级了什么

先看技术底座。EmbodiedAI 这条线在 1.0 阶段更多是把基础能力搭起来，1.0.1 的重点是把每一块往可用的方向再推一步。

导航规划这块，过去开源机器人栈里的痛点是从全局路径到局部避障的衔接经常断裂——在仿真里跑得漂亮，搬到真机上一遇到动态障碍就抖。1.0.1 在规划层补了能力，配合下面会讲的仿真链路，让规划算法在不同动力学模型下的表现更可预期。

运动控制部分的升级是和本体形态绑定的。人形机器人的 WBC（全身控制）、四足机器狗的步态切换、轮式底盘的差速控制，三套范式差异巨大。EmbodiedAI 没有走"造一个通用控制器"的路线，而是把控制接口抽象出来，让不同形态可以挂自己的控制后端。这个设计是对的——具身智能现阶段最大的现实是没有银弹，能做好抽象接口已经赢一半。

硬件适配层面，开源鸿蒙的优势开始显现。它本身就是个带 HDF（硬件驱动框架）的 OS，传感器、电机、IMU 这些设备的驱动模型有现成的范式可以套。这跟把 ROS 直接架在 Linux 上、每家厂商各自适配驱动的局面比，是有架构红利的。

三套仿真环境同时塞进来，这个决定值得说道

1.0.1 最值得展开聊的是仿真这一块。版本同时集成了开源鸿蒙原生模拟器、MuJoCo 和 Gazebo。

这三个东西的定位完全不同：

MuJoCo 是物理仿真精度的事实标准，强项是接触动力学和高频控制仿真，强化学习训练机器人策略基本绕不开它
Gazebo 是 ROS 生态里的老搭档，强项是传感器仿真和场景搭建，对多机器人协同、SLAM 验证更友好
原生模拟器则是开源鸿蒙自己的盘子，可以和系统调用、IPC、应用框架直接打通，仿真出来的不只是物理过程，还包括应用层的行为

把三套同时打进来，听起来像是"我全都要"，但仔细想这个组合是有逻辑的。开发者实际工作流大概是这样：先在 MuJoCo 里训练或调优控制策略，然后在 Gazebo 里做完整任务级的场景验证，最后用原生模拟器跑一遍上层应用和系统集成，再上真机。EmbodiedAI 1.0.1 把这条链路打通，意味着开发者不用在三套工具之间手动倒腾接口、转换坐标系、对齐时间戳。

这件事比表面看起来重要。具身智能开发者最痛的不是单点工具不够好，而是仿真到真机（sim-to-real）的差距和工具间的胶水代码。能把这部分摩擦降下来，对生态的吸引力是实在的。

和 ROS 的关系：兼容，而不是替代

这一点开源鸿蒙拿捏得比较克制。

ROS（尤其是 ROS 2）在机器人开发者群体里的位置类似前端世界的 React——不是最完美的方案，但事实标准就是它，迁移成本高到没人愿意动。任何想进入这个生态的新玩家，第一步都得先表态：我兼容 ROS。

EmbodiedAI 1.0.1 继续保持对 ROS 中间件的兼容，意思是开发者已经写好的 ROS 节点、消息定义、launch 文件，理论上可以在开源鸿蒙的环境里继续跑。这是一个非常现实的选择。如果上来就要求开发者抛弃 ROS 用一套全新的通信机制，那这个版本根本不会有人理。

但兼容不等于没有自己的牌。开源鸿蒙原生模拟器和系统能力的整合，是 ROS 给不了的。开发者可以选择：纯 ROS 项目过来无痛迁移，新项目则可以用上更深度的系统能力。这个"双轨"策略和 HarmonyOS 应用层处理 Android 兼容时的思路一脉相承——先用兼容争取存量，再用原生争取增量。

三类本体适配完成，含金量几何

官方明确点名了三类已完成验证的设备：

人形机器人：自由度高、控制复杂、对实时性要求最苛刻
四足机器狗：步态规划是核心，户外动态场景多
商用服务机器人：通常是轮式底盘 + 机械臂，对长时间稳定性要求高

这三类基本覆盖了具身智能现阶段的主流形态。能跑通这三种，意味着 EmbodiedAI 的抽象层在不同动力学和控制范式下都站得住。当然，"完成适配与功能验证"和"生产级可用"之间还有距离，1.0.1 这个版本号本身就说明了项目自己的判断——基础能力跑通，离规模化部署还有路要走。

值得对比的是行业里的另外两个参照系：

NVIDIA Isaac 走的是"GPU 加速 + 高保真仿真 + 大模型预训练"的路子，门槛高、能力强，但绑定 NVIDIA 硬件
ROS 2 + Nav2 + MoveIt 是开源标准组合，灵活但碎片化严重，每家厂商都在重复造适配

开源鸿蒙的位置介于两者之间：比 ROS 2 多一层 OS 整合和工具链统一，比 Isaac 更开放、更轻量、不绑硬件。这个生态位有它的合理性——尤其在国内机器人厂商越来越多、各家都需要一个不被卡脖子的底座的当下。

18 个 SIG，组织力是真功夫

稍微不那么显眼但同样关键的信息：开源鸿蒙具身智能方向已经组建了 18 个专项 SIG 工作组。

SIG（Special Interest Group）是开源社区里负责具体技术领域的小组，18 个的体量不算小。横向比一下，Kubernetes 社区目前活跃的 SIG 大约 20 多个，撑起的是全球最大的容器编排项目。EmbodiedAI 这个数字说明项目方对治理结构是认真的，不是几个人写代码挂个开源协议就完事。

但 SIG 多也意味着风险——协调成本、接口对齐、版本节奏，每一项都需要稳定的项目管理。这部分能不能做好，是决定 EmbodiedAI 一年后是真生态还是"组件大杂烩"的关键。

留给开发者的几个现实问题

版本发布是好事，但作为想真上手的开发者，有几个问题要心里有数：

第一，文档和示例的完备程度。基础能力升级了不代表上手体验好，1.0.1 的实际开发体验需要拿到 SDK 跑过才知道。

第二，LLM/VLA 模型集成。现在的具身智能离不开多模态大模型做高层规划和语义理解，EmbodiedAI 1.0.1 的发布信息里没有重点提模型层的整合方案，这部分大概率要靠开发者自己接。需要在机器人上部署 GPT、Claude、Gemini 这类闭源模型做高层推理的话，可以走 OpenAI Hub 这类聚合 API，国内直连、兼容 OpenAI 格式，省去自己处理多家厂商鉴权的麻烦——但跑在端侧的小模型还得自己折腾。

第三，真机调试链路。三个仿真器整合是好事，但 sim-to-real 的真正难点在域随机化、传感器噪声建模、控制时延补偿这些细节，仿真打通只是第一步。

第四，社区响应速度。18 个 SIG 听着热闹，但开发者提 issue 后的响应时长、PR 合并节奏，才是衡量一个开源项目是否健康的硬指标。

一点判断

EmbodiedAI 1.0.1 不是一个会刷屏的版本，没有惊艳 demo，没有性能跑分，连发布会都只是开发者大会里一个分论坛的环节。但这种"工程师式"的迭代恰恰是机器人 OS 这种基础软件该有的样子——具身智能的难度在硬件、控制、感知、学习每一层都是深水区，靠一两个版本就讲完故事的项目，最后大概率讲不下去。

开源鸿蒙在终端 OS 这条主线之外，开辟具身智能这条副线，说明它对未来设备形态的判断已经把机器人列进了核心场景。这个判断本身没什么争议——人形机器人量产元年的话题已经讨论了两年——真正值得观察的是：等 1.1、1.2 版本出来时，社区里真正在用 EmbodiedAI 做项目的开发者有多少，第三方厂商的本体适配能不能突破到几十款这个量级。这两个数字会比任何 PPT 都说明问题。

源码已经放出，想看的开发者可以去拉一份回来跑跑。