11 月 11 日，2026 年 APEC 领导人会议周新闻中心在深圳会展中心（福田）2 号馆启用。约 1.5 万平方米、700 个工位、近 5000 名中外记者——这是它接下来十余天要承载的日常。

11 月 12 日，证券时报记者进去转了一圈，写了两个让我停下来看了两遍的细节。

第一个在"记者之家"科技服务区：一台双臂机器人现磨、萃取、打奶泡，最后在杯面拉出一个简洁的 APEC 标识。第二个就在几步之外：记者在电脑上点单，订单被系统拆解、分派，几台不同厂商的机器人各干各的活，一杯冰淇淋从下单到送到桌边，最快约一分钟。

一杯冰淇淋而已。但同一套方案，今年 9 月还摆在亚太媒体高端论坛的科技创新成果展上——那是"成果展示"，这是"会议保障"。

两个月，考场换了，考纲也换了。

一、现场：一边是会动的设备，一边是不会动的设备

先把这个新闻中心里的两条技术线分清楚，因为它们在报道里经常被混在一起说。

第一条线，是会动的设备。 据深开鸿 11 月 12 日的公开稿件，基于 M-Robots OS 的冰淇淋机器人、咖啡机器人与轮臂配送机器人，实现了"语言互通、任务编排与实时协同"，能完成从点单、制作到配送的全流程无人闭环。证券时报的现场侧记则给出了更细的链路：订单先由 MediaBuddy 拆解分派，再把天机机器人、节卡 Lumi 人形机器人、晨昏线 GCWM 认知模型这些不同厂商的"智能单元"串成一条链，最后由来自深圳大学创业公司创界智联的异构群体智能调度平台，用 AI Agent 把一群机器人连在一起。

请注意这句话里的厂商数量：调度平台、本体、人形、认知模型，至少四方。异构不是 PPT 上的形容词，是这张现场照片里的四家公司。

第二条线，是不会动的设备。 同一个新闻中心里，深圳广电联合深开鸿打造了国内首个基于开源鸿蒙的智慧广电演播室，用"1+1"开鸿安全数字底座做设备适配与统一管理，配多 Agent 协同制作中枢。按证券时报的描述，这里的"智慧大脑"能感知演播室内人员的位置和数量变化，实时自动调节灯光、摄像等设备，完成拍摄，效率提升约 60%；旁边的 XR 虚拟演播室可一键切换约十个深圳特色场景。

这条线用的不是 M-Robots OS，而是同源的开鸿底座，这点必须说清楚。但两条线背后的逻辑是同一个：把 N 台设备，变成一台设备。

会动的机器人靠任务编排做到这一点，不会动的灯和摄像机靠状态感知做到这一点。M-Robots 想占的位置，从来不只是"机器人的操作系统"，而是"空间里所有可被调用的能力，共用一套语法"。

二、真正变难的地方：三道"不能出错"的门

展会上的成功标准是"跑通一次，有人鼓掌"。会议保障场景的成功标准是"连续跑十几天，不出事，出了事 30 秒内有人接得住"。

这两者之间隔着的不是算法，是系统工程。我把公开报道里能看到的线索，整理成三道门（以下为笔者基于公开信息的判断框架，官方未披露具体实现细节）：

门	考的是什么	现场为什么变难
门一：接入的确定性	设备上线即被识别、任务可下发、状态可回传	展会可以提前三天联调；保障场景里设备一旦重启、断网、换固件，能不能自动回到任务图里，是另一回事
门二：编排的容错	某台设备忙、离线、出错时，任务能否重派	记者点单是典型的波峰流量——茶歇时间集中爆发，排队策略、优先级、人工接管入口都得提前设计
门三：长时运行的可观测性	日志、告警、耗材、远程重启	十余天无人值守，最致命的是"看不见的故障"：咖啡豆没了、奶泡打不出来、机械臂卡在某个姿态，系统知不知道

三道门里，没有一道能靠"模型更聪明"解决。它们分别是接口契约问题、调度策略问题和运维工程问题——恰好也是过去几年机器人项目最容易在 POC 之后死掉的地方。

"机器人产业正经历从'单体智能'走向'群体智能'、从固定场景走向物理 AI 与开放世界两大变革。"【王皓，深开鸿高级副总裁、研发体系总裁、M-Robots 社区技术指导委员会主席】

走向开放世界，第一课不是更复杂的任务，而是更长的运行时间。

三、比"协同"更值得看的一件事：分工显形了

我一直觉得，判断一个产业是否成熟，看它的分工是否清晰，比看它的 Demo 是否惊艳更准。

这场新闻中心里的分工，其实已经排得很明白（以下分工关系为笔者依据公开报道的整理，非官方表述）：深开鸿提供操作系统与安全数字底座，深圳广电作为技术系统承建方定义场景，创界智联做异构调度平台，天机、节卡、晨昏线分别出本体、人形与认知模型，最后由新闻中心这个"甲方场景"验收。

没有一家公司试图把从芯片到冰淇淋全做完。

"我们今天 500 人的机器人厂家都不多，怎么可能做成商用？只有做到合理分工……才可能成功。而这一切的前提，是一个合理的共性平台。"【王成录，深开鸿 CEO、M-Robots 社区主席】

这段话在 2026 年被引用过很多次，但大多数时候是当作观点。这一次，它更像是一份现场施工图：共性平台在中间，专业公司在两边。

四、泼三盆冷水

第一，这是"体验场景"，不是"生产场景"。 官方稿件里的用词是"亮相""体验""智趣"，服务对象是茶歇间隙的记者。它能证明多机协同在真实人群密度下可用，但不能推导出规模化商用已经跑通。真正的考验在连续运行三十天后，而不是开幕第一天。

第二，"效率提升 60%"不能算在机器人 OS 头上。 这个数字出自证券时报对智慧演播室整体方案的描述，指的是灯光、摄像自动调节带来的拍摄效率，与机器人多机协同没有因果关系。把不同技术线的指标串起来讲，是这类报道最常见的失真方式。

第三，公开信息里没有故障率和协议细节。 "语言互通、任务编排、实时协同"是定性表述，具体用什么接口、跨厂商适配改了多少代码、这十余天出了几次告警，都没有公开。没有数据支撑的"稳定"，只能叫"目前没听说出问题"。

五、三类人，各拿一句话

给开发者： 异构调度和运维工具，是当下最缺人的两块。前者要处理"不同本体、不同自由度、不同状态机"的统一抽象，后者要把机器人从"能跑"变成"能被人管"。这类题目在社区的 Open-Source_Co-Creation_Challenge 任务仓里已经出现了雏形，从写一个设备状态的可视化小工具开始，比一上来啃实时内核更容易积累手感。

给机器人企业： 你的设备能不能被别人调度，决定了你有没有资格进别人的项目；你的设备出故障时别人能不能看见，决定了你能不能在项目里待满一年。前者是接入，后者是可观测性——第二件事，现在做的人还很少。

给观察者： 国产机器人操作系统的验证路径，可能不是"发一个大版本"，而是"进一个不能出错的场景"。数博会的展台、龙岗的赛场、APEC 的新闻中心，本质上是在给同一套能力换越来越难的考卷。

写在最后

回到那杯冰淇淋。它一分钟能送到桌边，靠的是四家公司的产品被一套语法串起来；而它能不能在这十余天里每天都送到，靠的是这套语法背后的工程能力——这部分没有画面，也不上镜，但恰恰是群体智能从"可看"走向"可用"的分水岭。

顺便提醒一句：今天中午 12:00，2026 机器人技能大赛——开源鸿蒙（M-Robots OS）竞技赛的报名就截止了。如果你昨天还在犹豫，这是最后的窗口；如果你只是想先看看这套东西长什么样，社区站永远开着。

去 M-Robots 官方社区 - Open source code hosting and collaboration - AtomGit 逛逛，从 Star 一个仓库开始，或者从一个"设备状态可视化"的小 Issue 开始。

---

关于 M-Robots：M-Robots 是开放原子开源基金会孵化的机器人操作系统开源社区，基于开源鸿蒙底座打造，截至本文写作当日（2026-11-13）社区站显示 558 位关注者，已设 13 个 SIG 技术组。社区站：M-Robots 官方社区 - Open source code hosting and collaboration - AtomGit 如果你也在关注机器人操作系统，欢迎去社区站逛逛，从 Star 一个仓库开始。

---