具身智能的Harness来了量子位

当机器人已经能够完成越来越多单点动作，下一步不只是让每台机器人单独变得更“聪明”，而是让它们像一个团队一样被组织、被调度、被检查、被扩展。

让一台机器人执行“把三明治递给我”，今天已经不再稀奇；让一组机器人协作完成“做一个三明治”，仍然是一件难事。

难点并不只是“机器人会不会抓取”，而是多台机器人之间如何分工、如何并行、如何等待、如何交接，以及如何把一次演示沉淀为可以复用的系统能力。

OMEGA，全称Orchestration system for Multiple Embodied Generalist Agents，是一套面向真实世界多机器人协作的embodied agent harness，由中国科学技术大学张举勇教授团队联合上海人工智能实验室共同完成。

它把一个high-level mission goal转成一张可执行的任务图（task graph），再把任务分配给多个机器人worker并行执行，同时保留完整的执行记录、任务报告和运行证据。

过去两年，VLA（Vision-Language-Action）模型让单台机器人完成抓取、分拣、移动、放置等动作的能力明显提升。我们已经能看到越来越多令人印象深刻的机器人demo：机器人能看懂场景，能响应语言指令，也能把视觉输入转成动作输出。

但VLA主要回答的是“一台机器人的感知如何变成一次动作”，它通常不回答另一个问题“多台机器人的动作如何组成一次协作”。

两台机器人一起做三明治时，它们并不是简单地“各做各的”。以OMEGA的kitchen demo为例，一台机器人可以先取面包和牛排，另一台机器人可以同时取面包和生菜；有些步骤可以并行推进，有些步骤必须等待前一步完成；一个机器人的产出，可能正是另一个机器人下一步的输入。真正困难的不是把任务拆开，而是拆开之后还能正确收拢。

今天的一些多机器人演示，看起来是“机器人团队”在工作，实际上屏幕外常常还有一位最忙的人：工程师。

他盯着两块屏幕，确认A机器人执行完了，再手动触发B机器人；确认B到位了，再回头触发A；一旦某一步延迟、失败、位置不对，就靠人来判断下一步怎么办。机器人数量越多，任务步骤越长，这个人就越像整个系统真正的“调度器”。

这会带来一个很现实的问题：投入的是两台甚至更多机器人的成本，获得的却常常是接近一台机器人的吞吐。大量本来可以同时进行的动作，因为需要人工确认和逐台触发，最后退化成串行执行。更重要的是，这种协作方式很难沉淀。为一次演示写的胶水脚本，换一个任务、换一台机器人、换一个场景，往往就要重写。

真正的团队协作需要两条原则同时成立：

可并行的步骤绝不串行。

相互独立的动作应该在不同机器人上同时推进。

有依赖的步骤绝不抢跑。

一个机器人的产出如果是另一个机器人的输入，就必须在正确的时间点准确汇合。

OMEGA要解决的，正是这两件事如何从“工程师脑中的经验”变成“系统中可执行的流程”。

从Coding Agent到Robot Team：机器人也需要Harness

如果你使用过Claude Code、Codex或类似的coding agent，应该已经熟悉一种新的协作模式：你只描述一次需求，主agent会把任务拆成若干子任务，分给不同的subagent并行执行；有的子任务先跑，有的子任务等待依赖；最后主agent把结果汇总、校验、提交。

使用者通常不需要关心这些subagent之间如何通信、如何等待、如何汇报。因为在模型之外，已经存在一层看不见但非常重要的harness：它负责任务拆解、并行调度、状态追踪、结果汇总和过程记录。

OMEGA想把类似的系统能力带到机器人协作中。对机器人来说，harness要解决的不是代码文件如何修改，而是现实世界中的任务如何被执行：哪些机器人在线，每个worker能做什么，哪些步骤可以同时做，哪些步骤必须等待，谁的输出要交给谁，任务完成后如何知道每一步到底发生了什么。

这就是OMEGA的基本定位：它不是再做一个机器人动作模型，而是为多机器人团队提供一层可执行的协作系统。

OMEGA是什么

OMEGA的核心，是把机器人协作拆成三层清晰分工：Skills说明每个worker能做什么，A2A定义orchestrator与worker之间如何派发任务、同步状态、返回结果，MCP负责worker内部如何连接真实机器人runtime、模型和控制栈。这样，orchestrator不需要知道每台机器人的内部实现，只需要根据公开的Skills调度任务，并通过A2A接收执行结果。

从使用者视角看，流程非常直接：你描述一个mission goal，OMEGA负责发现可用机器人、规划任务步骤、安排并行执行、处理依赖关系、收集执行报告，并把整次运行留下可检查的证据。从系统视角看，这条链路可以概括为五步：

Discover：发现当前有哪些worker在线，以及它们声明了哪些Skills。

Plan：把mission编译成一张task graph。

Schedule：找出当前可以并行执行、且不会抢跑的任务。

Dispatch：把具体任务派发给对应worker。

Observe：收集worker reports，更新mission state，并推进下一轮调度。

上图展示的是OMEGA在真实机器人验证中的部署结构：控制主机运行orchestrator，多个worker连接各自机器人。orchestrator不直接进入机器人内部控制栈，而是通过A2A与worker协作；worker再在自己的边界内通过MCP连接机器人执行引擎。这个结构的重点不是把所有东西集中到一个“大脑”里，而是把团队协作和机器人执行分成清晰的两层。

OMEGA背后的三个判断

OMEGA的设计不是从“我要加哪些功能”开始的，而是从三个判断开始。

第一个判断是，协调是刚需，不是锦上添花。真实世界的机器人任务不是一次孤立的模型调用。做三明治、整理厨房、搬运物品、协作装配，这些任务天然包含多个步骤、多个角色、多个依赖。就像装修一套房子：有的工序可以同时进行，有的必须严格等待；水电没完成不能封墙，墙面没干不能进家具，关键节点还需要多个工种同时就绪。机器人长程任务也是如此。如果协作关系没有被系统表达出来，多机器人系统就会退化成“多台机器人轮流执行”。

第二个判断是，协调必须为扩展而设计。为一次demo写的脚本，可以让机器人成功运行一次；但如果换一个任务就要重写，换一个机器人就要重接，换一个场景就要重配，那么这套协作能力就没有真正沉淀下来。OMEGA的目标不是把某一次演示写死，而是让协作层本身成为可复用的系统：机器人数量可以增加，Skills集合可以扩展，部署环境可以变化，但mission、task graph、worker Skills 和 execution reports仍然走同一套协作链路。

第三个判断是，具身智能落地的瓶颈不只是模型能力。demo证明的是“能做到一次”，部署要求的是“能被重复组织、重复执行、重复检查”。这两者之间缺少的往往不是一个更大的模型，而是一条工程化路径：如何把机器人能力接入任务系统，如何把任务拆成可执行步骤，如何在多机器人之间调度依赖，如何记录每一步发生了什么。

让生成的计划必须落地

用大模型把一句自然语言任务拆成步骤，并不是最难的地方。真正困难的是：生成出来的计划能不能执行。

很多看起来合理的自然语言计划，到了机器人系统里会出现各种问题。计划中可能使用了机器人并不具备的能力，两个步骤之间的依赖可能没有写清楚，一个机器人需要的输入可能根本没有被前一步产生，执行记录也可能无法对应回原始任务。OMEGA对大模型的使用非常克制：大模型不是自由生成任意机器人代码，而是在已声明、已校验的Skills catalog中组合task graph。规划器可以负责“怎么组合”，但不能凭空发明一个系统并不支持的机器人能力。

OMEGA会把mission编译成一张task graph。每个任务节点都要说明任务内容、assigned worker、使用哪个Skill、依赖哪些前置任务、需要哪些输入、成功后产生什么输出，以及超时、失败、取消时如何处理。

上图是OMEGA在厨房任务中实际生成并执行的task graph。它展示的重点不是“把任务拆成很多步”，而是把并行关系和等待关系明确写进系统。Agent B和Agent C可以先各自推进取料分支；当装配步骤需要双方的状态或结果汇合时，orchestrator才会触发下一步。这就是“可并行的步骤绝不串行，有依赖的步骤绝不抢跑”的具体体现。

错误处理也被放在这条执行链路里，而不是写成另一套临场救火逻辑。每个任务可以提前声明超时、重试、取消和失败后的处理方式；worker执行任务后，把状态和结果报告回orchestrator；orchestrator再根据这些报告继续调度、重试当前任务，或者终止mission。这并不意味着OMEGA替代底层机器人安全控制器，也不意味着它解决了所有真实世界异常恢复问题。它解决的是编排层的一件关键事：任务失败后，系统至少知道失败发生在哪一步、对应哪个worker、应该按什么策略处理。

让不同机器人接入同一套协作流程

OMEGA关注的不是让所有机器人变成同一种系统，而是让不同机器人的能力能够进入同一套协作流程。每个worker对外公开自己的Skills，通过A2A接受任务、同步状态、返回结果；至于它内部如何调用机器人runtime、模型和控制栈，则留在MCP侧完成。

机器人内部可以有自己的VLA模型、控制器、执行程序、厂商runtime和调试工具。这些细节不需要暴露给OMEGA的orchestrator。orchestrator只需要知道三件事：

这个worker是否在线；

它公开声明了哪些Skills；

它执行任务后如何返回结果。

在OMEGA中，每个worker对外公开一张Agent Card，可以理解为“机器人团队成员的名片”。这张名片告诉orchestrator：我是谁，我支持哪些Skills，我是否准备好接任务。而worker内部真正如何驱动机器人动作，则留在worker自己的边界内。OMEGA当前的真实机器人验证中，worker背后连接的是LIFT2机器人侧执行引擎；未来不同机器人厂商也可以在自己的私有侧接入不同runtime。

上图展示了A2A与MCP在一次执行中的关系。A2A负责orchestrator和worker之间的公开协作：发现、派发、观察、取消。MCP负责worker内部如何接入机器人执行引擎。对OMEGA来说，A2A是团队协作面，MCP是机器人执行面。把这两层分开，才能让机器人能力像插件一样加入团队，同时又不把厂商内部runtime、模型路径、工具名称和诊断信息暴露到公共调度层。

这也是OMEGA对机器人接入方式的核心设计：不要求所有机器人使用同一种内部实现，而是把差异收束在worker/MCP边界内；只要公开协作接口保持一致，不同机器人能力就可以进入同一套任务图和调度流程。