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

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

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

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 边界内；只要公开协作接口保持一致，不同机器人能力就可以进入同一套任务图和调度流程。

真实机器人验证：两台 LIFT2 的厨房任务

技术设计讲得再完整，最终仍然要看真实运行。OMEGA 已经在一个真实机器人厨房任务中完成验证：两台 ARX LIFT2 机器人作为 Agent B 和 Agent C，协作完成一次三明治相关任务。

这次验证不是在同一台机器上模拟两个进程，而是跨主机部署。控制主机运行 OMEGA orchestrator，两台 worker host 分别连接对应机器人；orchestrator 通过 A2A 与 worker 通信，worker 在本机边界内通过 MCP 接入机器人执行引擎；mission 执行过程保留 task graph、worker reports、event timeline 和运行证据。

在这次任务中，OMEGA 从一个high-level mission goal出发，生成跨两个 embodied agents 的 task graph。任务图中既有并行分支，也有跨 agent 的 rendezvous：一个 worker 的状态或输出，会成为另一个 worker 下一步执行的前置条件。抓取、装配、摆盘、朝向调整这些动作，由机器人侧模型和控制器执行；OMEGA 的角色，是把这些动作组织成一场可以被调度、被检查、被复盘的团队协作。

这次验证要说明的重点，不只是 " 机器人完成了一次任务 "，而是这四件事可以连成闭环：

一个 high-level mission goal 可以被转成 task graph；

task graph 可以跨多个 worker 并行调度；

机器人执行结果可以回流到 orchestrator；

整次运行可以被检查和复盘。

结语：从机器人 demo 到机器人团队系统

过去几年，具身智能最吸引人的画面，常常是一台机器人完成一个令人惊艳的动作。但当机器人真正进入厨房、工厂、仓库、实验室和家庭，问题会自然变成：不只一台机器人怎么办？不只一个动作怎么办？不只一次 demo 怎么办？

OMEGA 想回答的，正是这些问题。它的意义不只是又完成了一次机器人 demo，而是尝试把 " 从 demo 到可复现团队协作系统 " 的路径，沉淀成一套可以被检验、被扩展、被持续迭代的工程实践。

VLA 可以让机器人更好地把视觉和语言转成动作，LLM 可以帮助生成计划，但这些能力只有进入一条可校验、可调度、可观察的链路，才会变成稳定的任务执行能力。如果说 VLA 回答的是" 机器人怎样做动作 "，OMEGA 想回答的就是" 这些动作怎样组成一个团队任务 "。

在机器人项目落地中，OMEGA 提供的是一条渐进式路径，而不是要求团队推翻现有机器人栈。已有的 VLA 模型、控制器、厂商 runtime 和诊断工具，都可以留在 worker 自己的边界内；OMEGA 负责把这些能力包装成可声明、可调度、可观察的协作单元。可以先在一个场景里验证 task graph 和协作流程，再逐步增加 worker 数量和 Skills 集合，同时用统一的 mission evidence 复盘每一次运行，减少一次性脚本和人工盯屏带来的不可复制成本。

具身智能的下一阶段，当然仍然需要更强的模型、更好的数据、更稳定的控制。但除此之外，也需要一层系统能力：让机器人不只是能动，而是能被组织；不只是能完成动作，而是能完成团队任务；不只是能演示一次，而是能被复现、被检查、被扩展。这也是团队希望 OMEGA 传递出的核心信息：具身智能当然需要更强的模型，但从 demo 走向可复现系统，还需要一层能组织机器人团队的 harness。

项目主页：https://zheruiqiu.github.io/omega/

代码仓库：https://github.com/zheruiqiu/OMEGA

OMEGA kitchen demo：https://www.youtube.com/watch?v=6ZO_N9kbn_k

OMEGA Homepage：https://zheruiqiu.github.io/omega/

OMEGA GitHub：https://github.com/zheruiqiu/OMEGA

OMEGA Docs：https://zheruiqiu.github.io/omega/docs/

Skills：https://agentskills.io/home

A2A：https://a2a-protocol.org/latest/

MCP：https://www.anthropic.com/news/model-context-protocol

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

【学术投稿】请在工作日发送邮件至：ai@qbitai.com，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目 / 主页链接，以及联系方式。

  我们会 ( 尽量 ) 及时回复你 : )

点亮星标

科技前沿进展每日见