「模型每想一次，机器人就停一次：中国移动把中间那层开源了」

一个机器人手臂要在桌上完成「抓杯、放杯、按键、等出品、取杯转移」这一串动作。模型想出这一步要花上百毫秒，可关节控制回路每 3.75 毫秒就要一次指令，两者差了三十到五十倍。同步方案下，这个差距会变成一个具体的物理结果：模型每「想」一次，机器人就得停一次。

9 月 16 日，中国移动面向全球开源了 Open-RAIL，定位是行业内首个连接 VLA / WAM 模型与机器人本体的通用工程底座。它的位置既不在模型侧，也不在本体侧，而在两者之间那层，此前每支团队都要自己重造一遍的工程链路。

⏱️ 先量一下这三个时钟差多少

具身智能行业眼下是一种很别扭的错位：一边是模型层的飞速迭代，π 系列、GR00T、Gemini Robotics，再加上世界模型你追我赶，VLA 模型几乎每个月都在刷榜；另一边是真机落地的静水，能在真实场景里稳定跑起来、跑得久的系统屈指可数。

展台上的机器人行云流水，走出展台问题就一个个冒出来。所有问题背后是同一件事：两个时钟不同频。

除了时钟差，还有三个同源的问题。

一个是接口。不同品牌的机器人，关节定义不同、通信协议不同、坐标系朝向也不同。同一个模型换一台机器人，接口映射要重做一遍；换一个模型，推理管线要重写一套。多数团队只覆盖一两种机型。

一个是接缝。模型一次吐出的是离散的动作点，点与点之间没有平滑过渡。上一段还没执行完，下一段的推理结果又到了，衔接处就是位姿和速度的突变。

一个是数据。传统做法里推理和数采是两条割裂的流程，采完还要手动整理格式、对齐时间戳，从采到用以周计。

四个问题拆开看都是工程细节，合起来却是同一道门槛：模型与真机之间那段没有名字的链路。

🧱 Open-RAIL 的架构：服务端与客户端分家

Open-RAIL 采用服务端-客户端分离的结构。服务端负责任务调度、模型推理和数据管理，机器人侧负责执行与感知。这么切有一个很实际的理由：模型要的深度学习环境和机器人驱动要的控制环境，本来会互相打架，分家之后两边互不干涉。

关键在于机器人侧把观测、推理、控制拆成三条并行流水线，三者互不等待，中间用一个动作缓存吸收两端的节奏差。模型每「想」一次，机器人不必再停一次。

异步只解决了「等不等」的问题。真正影响手感的还有两处：一段推理结果内部的稀疏采样，以及上一段执行轨迹与下一次推理结果之间的接缝。前者归「块内」，后者归「块间」。只做其中一级，另一类抖动依然存在。

Open-RAIL 两级一起做，而且全部在机器人侧实时计算，模型一个字都不改。

这个数字是整篇里最实在的一个。关节加速度标准差从 10+ rad/s² 降到 0.1 rad/s²，两个数量级。平滑真正要压住的是加速度的变化率，液面晃动、结构冲击、电机冲击电流都从那里来。硬件不再承受高频冲击。

☁️ 端边云：把算力从本体上解耦

面向真机部署的开源 VLA，参数量从几亿到几十亿不等，其中 3B 上下最为集中。这不是模型不需要更大。推理延迟要和毫秒级的控制回路抢时间，机器人端的嵌入式设备装不下更大的模型。

Open-RAIL 把推理统一放到服务端，机器人侧只负责执行和状态上报。服务端可以放在本体、边缘算力或云端。

「算力不够只能选小模型」这条限制被解开了，代价是网络可用性成了新的前提。云端部署的那条路，对链路稳定性的要求会比本体部署高一档。

🔌 异构适配：换机器人、换模型都不重来

Open-RAIL 在中间抽出一层轻量的硬件抽象层，把控制、状态读取、动作执行统一成一套约定：新机器人接入，只需补上底层驱动并完成注册，上层逻辑完全复用；模型侧同理，按统一约定实现推理接口即可。

四款已适配机型包括中国移动灵犀折叠轮臂机器人、智元精灵 G1、宇树 G1 和浙江人形 wa1。这四台车的自由度配置、关节命名和坐标系各不相同，能放在同一套上层逻辑下跑，是这层抽象是否真的成立的第一手证据。

🔄 数据闭环：执行的同时把数据收回来

Open-RAIL 与许多「推理库」的分界线，在数据这一侧。

推理的同时，多视角图像、关节状态、推理结果、平滑后的指令、时序信息全部自动归档，存成开箱即用的标准格式，无需转换就能直接进下一轮训练；写入在后台异步完成，不占用控制线程。评测侧同样留痕：推理、平滑、通信各环节的耗时分别记录，运行配置一并保存以便复现。「推」的每一环开销因此都能被拆开看，而不是只给一个端到端数字。

还有一种是「推理与遥操混合」的运行模式：模型跑偏时人可以随时介入纠偏，介入与退出之间自动做状态预对齐，把接管瞬间的位姿、速度突变消掉；纠偏轨迹与原始推理轨迹时间戳严格对齐、并行保存，可以直接作为训练样本回灌。

每一次人工纠偏，都变成一次定向的教学数据。这条设计把「数采」从一件需要专门开一场的活，变成运行本身的副产品。

这层跟现有工具的关系需要说清楚。 LeRobot 是训练库与数据格式标准，ROS 是底层通信与控制抽象，VLASH、RTC 是模型级或算法级的单点优化。它们都作用在「模型推理到动作输出」这一段，而且往往要在策略内部或训练流程里留下痕迹。Open-RAIL 切的是这段之外的工作：调度、平滑、采集、评估，做成一层不改模型的公共层。

🍳 底座上跑出了什么

一个底座有没有用，不看参数，看它上面长出了什么。

中国移动自研的移动星厨机器人跑在 Open-RAIL 之上。它已在数字峰会、上海 MWC、东盟博览会等场合亮相，并在杭州研发园区完成常态化落地，日均出杯量超过百杯。单杯拿铁从启动制作到成品出杯，全流程压到 90 秒；抓杯、放置、按键、等待出品、取杯转移一气呵成，也能开微波炉门、设定时间与温度。全程由模型自主决策，没有为其中任何一步单独编写控制逻辑。

端着满杯咖啡移动不洒不漏，关节加速度标准差稳定在 0.1 rad/s²，同时支持多订单并行处理。

需要留意的是，这些数字来自开源方的落地描述，没有第三方的产能或稳定性审计。90 秒这个节拍已经接近商用现制咖啡的出杯节奏，这是一个可对照的外部参照，也是这条验证最有说服力的地方：模型能规划这件事本身不算稀奇，稀奇的是规划出来的动作每一步都落得住。

🏛️ 开源方是央企，这件事本身值得看

具身智能是典型的工程活。很多卡住落地的不是算法，而是那些不产生论文、却非做不可的基础设施：投入大、周期长，短期很难看到回报。

中国移动把 Open-RAIL 放在自有的「焕新社区」开源，同时提供了 GitHub 与 Gitee 镜像。开源主体是一家央企，这件事的分量在于：这层东西的公共品属性很强，谁做都很难独占收益，所以最容易被所有参与者集体跳过。它和 LeRobot、ROS 的定位处在同一条线上：给生态铺路，而不是圈地。

另外，中国移动杭州研发中心参编了 5 项人工智能国家标准，这个背景也解释了为什么它愿意把工程约定做成公共接口。

❓ 剩下的问题是运维，不是技术

开源一个中间层，技术上最难的已经过去了；组织上最难的才刚开始。这层代码的价值来自「所有机器人和所有模型都遵守同一套约定」这个前提，而约定一旦被某一方改成自己的分叉版本，收益立刻折半。

判断这条路走不走得通，办法很朴素：看半年之后，仓库里的合并请求来自几家不同的公司，以及那 10 个模型适配里，有多少条是国内厂商自己提的。

📚 参考来源

1. 澎湃新闻《向全球开源！中国移动 Open-RAIL》，2026-09-16 — https://www.thepaper.cn/newsDetail_forward_34080569
2. 新浪财经 / IT之家《行业首个，中国移动开源连接 VLA / WAM 模型与机器人本体的通用工程底座 Open-RAIL》，2026-09-16 — https://finance.sina.com.cn/tech/digi/2026-09-16/doc-iniryvce3073201.shtml
3. 中华网《中国移动：向全球开源 Open-RAIL 打通具身智能「最后一公里」》，2026-09-16 — https://news.china.com/socialgd/10000169/20260916/49746085.html
4. Open-RAIL 项目主页（GitHub Pages），2026 — https://cmcc-tao.github.io/open-rail/
5. Open-RAIL 开源仓库（Gitee 镜像），2026 — https://gitee.com/cmcc-tao/open-RAIL

#具身智能 #VLA #开源