RobotWorld 团队专访：Astra 仅得 19%，这可能是目前最难刷的机器人 Benchmark

原创 十字路口 2026-10-23 10:30 美国

大模型想“接管”物理世界，先过了这一关

👦🏻 采访: 壹小姐

🥷 整理编辑: 十字路口

🧑‍🎨 排版: NCon

当通用大模型已经能在数字世界熟练写代码、做分析，它们距离真正“接管”物理世界，到底还有多远？有没有一个统一的评测基准？

最近，一个来自具身和基模复合背景的团队，做了一个 Benchmark。累计花费约合1.35万美元，把五大主流模型 Astra、Opus、Kimi、DeepSeek、Gemini拉上了同一个测试场。

它就是——RobotWorld^[1]。

这可能是目前达成率最具挑战性的一场机器人测试：就连现在最强的 AI 操控机器人模型Astra，在它设置的84项任务中，也只能完成16项——得分仅19%；整体成功率仅7.9%。

10月7日，RobotWorld 论文发布的第二天，它直接登上 Hugging Face Papers 和 AlphaXiv 热榜；代码仓库同步开源，所有任务的录像和可交互结果面板同步在主页显示，全程420个评分轨迹清晰可见。

84 项任务中有 63 项没能被任何模型解决，是选题bar 设定过高还是其他原因？为什么强如GPT-6也只能完成19%？实测下来，他们认为 Astra 会降维打击所有的具身基座模型吗？从Computer Use 到 Robot Use，什么能力是当前最稀缺的？

带着这些问题，我们和 RobotWorld 团队核心成员——杨智钦、李宸鑫、胡晓萌聊了聊，其中宸鑫和晓萌是项目发起人。三位一同复盘了这项 Benchmark 的构建初衷、选题原则、面对的Challenge、一些关键发现和思考，以及下一步想做的事。Benchmark 只是起点。

下面是十字路口与 RobotWorld 团队的完整对话实录。

具身+Agent+基模复合团队

🚥 十字路口

首先，请先介绍一下RobotWorld团队的情况吧，也请大家简单介绍一下自己。

👨🏻‍🚀 胡晓萌

我们团队的背景比较多元。有的同学主要做具身智能，有具身领域头部初创公司的经历；也有不少同学主要做 Agent 和基础模型，有大家耳熟能详的头部基模团队的经历。

这种背景上的互补，让我们能把机器人和通用模型两个方向的视角结合起来：既理解机器人任务本身的要求，也思考如何从通用模型的角度切入这些问题。

我是 RobotWorld 项目共同第一作者、项目负责人，我的研究方向是大语言模型与通用智能体。曾在月之暗面 Kimi 强化学习团队和阿里巴巴 Qwen 后训练团队参与多项基础模型研发工作。

目前我主要关注：基础智能体模型的迭代自进化（RSI）、面向科学与工程问题的自动化研究智能体（Auto Research），以及面向机器人使用（Robot Use）的通用物理智能体。

👨‍🔧 杨智钦

我是 RobotWorld 项目共一第一作者，现在香港科技大学博士在读。曾在腾讯及具身智能初创公司从事研究工作。研究方向包括大语言模型推理、Robot Use Agent，以及不同物理智能体（Physical Agent）之间的协同。

曾主要研究模型偏好对齐，及语言表征（例如：code，formal语言）对模型及其在Robot上性能的影响，NeurIPS’26 LP4FM workshop主要组织者。目前重点探索模型能力的自迭代机制，以及大语言模型推理能力与具身智能的融合，推动 Physical Agent 新范式。

👨 李宸鑫

我是 RobotWorld 项目共同第一作者、也是项目负责人，香港中文大学博士，现任腾讯混元基础模型研究员。曾在字节跳动 Seed、Meta Superintelligence Labs（MSL）从事研究和实习。

我主要研究方向是代码智能体与 Computer Use，关注如何通过数据、执行环境和评测设计，提升通用模型解决实际任务的能力。曾参与视觉工具调用、电脑与手机智能体，以及训练数据生成与自进化等研究，关注如何利用执行轨迹和反馈提升模型能力。

近期通过 RobotWorld 探索 Computer Use 向 Robot Use 的能力迁移，并结合失败案例研究机器人任务所需的数据、训练方法与评测体系。

从Computer Use到Robot Use的跨界实验

🚥 十字路口

起初，你们怎么想到要做这个工作的？

👨‍🔧  杨智钦

最初推动我们做这件事的，是一个越来越值得追问的问题：大模型已经能理解图像、写代码、使用工具，这些能力到了物理世界里，究竟还能发挥多大作用？

Astra 这类模型的出现，让这个问题变得更具体。

面对一个陌生的机器人任务，模型是否可以先理解目标和接口，再通过观察、计算、编程以及执行反馈，逐步找到解决办法？我们想知道，这种方式能走多远，又会在哪里遇到困难。

但要回答这个问题，只看某一种机器人或几个成功案例是不够的。许多现有具身评测围绕特定机器人、任务分布和训练方式展开，而我们更关心同一个通用模型，面对不同形态和任务时，能否表现出一致的适应能力。

因此，我们逐渐把问题扩展到操作、移动、驾驶和飞行，形成了 RobotWorld。

我们希望通过这项工作，把“通用模型可能改变机器人”这个直觉，变成可以系统检验的问题：它已经具备哪些能力，还缺少哪些能力，下一步应该怎样改进。

👨 李宸鑫

我和晓萌之前都在做基础模型和通用 Agent。

早在 Astra 出来之前，我们就发现，仿真里的机器人操作与 Computer Use 有不少相近的地方：都是在环境里理解任务、调用工具，再根据反馈调整。Astra 的机器人演示让这个方向更受关注，也让我们觉得值得系统地验证一次。

真正确定要做这个项目，是我和晓萌吃饭时一起讨论的。

晓萌更关注后续的数据和训练，想探索怎样把具身能力训进下一代基模；我觉得短期内先做一个有难度、能接入基模评测流程的 benchmark 更合适。先把现有能力和缺口测清楚，后面讨论环境、数据和训练才有具体依据。

当时我们参考了 OSWorld。它为数字世界里的 Agent 提供了一个明确的评测参照，我们希望 RobotWorld 也能在机器人任务上承担这样的作用。

我们从一开始就把评测看作后续研究的起点，希望做出一套值得基模团队持续测试、也能启发下一步训练的任务。

🚥 十字路口

大家是如何组队配合起来的？

👨 李宸鑫

我和晓萌共同发起项目，也一起负责把控方向和进度。智钦有具身方向的研究和实践经验，我们之前就认识。

最初几次讨论以后，大家逐渐把想法落实到环境和任务上，也确定了核心团队，通用 Agent 和机器人两方面的经验就结合起来了。

具体实现上，智钦主要推进初步的 scaffold 和环境沙盒调试，以及适配Harbor这类更偏向Agent评测流程的规范；我更多负责批量实验、高并发运行。

后面的结果分析和材料，大家一起整理。环境能不能跑、模型怎样使用接口、任务到底有没有完成，这些问题我们都会一起讨论。

🚥 十字路口

你们是如何构建 RobotWorld Benchmark 的公正性和影响力的？

👨‍🔧  杨智钦

我们主要从两个方面考虑：公正性靠评测规则，影响力靠它能不能帮助社区回答重要问题。

在公正性上，我们首先明确模型能看到什么、能调用什么工具、获得多少控制辅助，以及可以使用多少步数和时间。

比如，同一任务下，不同模型遵循相同的观测、动作和预算设置；不同机器人之间，则保留各自合理的控制接口，并公开差异。任务是否完成，由环境中的可执行判据判断，而不是由模型自己宣称成功。我们也区分任务失败与接口、运行环境等基础设施故障，并保留交互记录和视频，让结果可以复查。

在影响力上，我们希望 RobotWorld 能回答一个越来越重要的问题：通用模型在数字世界中学到的能力，能否迁移到不同机器人和物理任务中？

因此，我们把操作、移动、驾驶和飞行器的操作放进同一个评测框架。除了成功率，我们还关注模型怎样利用反馈、什么时候能够恢复，以及不同模型为什么会在同一任务上表现不同。这些分析可以为后续训练和智能体设计提供更具体的方向。

我们也在降低使用门槛，让其他团队接入自己的模型或者harness，除此之外我们还在根据大家的反馈不断修正我们目前的框架，比如转向 Harbor 这种评测标准。

影响力最终要靠社区使用来建立：如果它能帮助研究者发现现有评测没有暴露的问题，并据此改进模型，这个 benchmark 才真正有价值。

🚥 十字路口

这个工作中最难的地方是什么？

👨‍🔧  杨智钦

实现中有三个关键点。

第一，是把不同机器人的任务接入一套统一的、可比较的评测流程。

机械臂、机器狗、车辆和无人机的动作空间、控制频率和终止条件都不同。我们需要统一任务描述、交互记录和评测流程，同时保留各类机器人的控制特点，把底层控制器提供了多少辅助交代清楚。

第二，是把模型的推理过程与物理执行区分开。

模型可以观察图像、做计算、写程序，再发出动作请求；动作执行后，环境返回新的观测和反馈。这里必须准确记录物理时间推进了多少、动作实际执行了多少，以及模型看到的是当前状态还是历史状态，否则评测结果很容易受到实现细节影响。

第三，是让结果可以解释、可以复查。

除了最终成功率，我们还要保留动作、错误、停止原因和视频，判断一次失败究竟来自模型决策、控制执行，还是运行环境本身。

最难的其实是确认：我们测到的究竟是不是模型的能力。

一个看似简单的接口选择，就可能改变任务难度。例如，动作接口如果已经替模型完成了路径规划，成功可能主要来自控制器；如果反馈缺失或历史图像处理不当，失败也可能来自评测系统。

我们花了很多精力检查这些边界。把环境跑起来只是起点，让不同模型在清晰、一致、可追溯的条件下接受评测，才是更难的部分。

🚥 十字路口

最能体现你们品味 taste 的地方是什么？

👨‍🔧  杨智钦

我觉得最能体现我们 taste 的，是我们选择把“通用模型如何使用机器人”作为研究对象。

这决定了我们没有只围绕一种机器人或一类操作任务来设计评测，而是把机械臂、机械狗、人形机器人、车辆和无人机放到一起。

我们想追问的是：同一个模型面对不同的身体、动作接口和物理约束，能不能利用已有的知识，理解任务，再通过观察、计算和反馈把事情做成？这种跨任务、跨形态的能力，是我们最关心的。

另一个选择是，我们把模型解决问题的过程，也当成值得研究的结果。

模型是否会主动分析图像、估计几何关系、建立动力学模型、生成控制程序？执行出错以后，它能不能根据反馈修正判断？这些行为比一个总分更能帮助我们理解，通用智能进入物理世界时，哪些能力开始发挥作用，哪些环节仍然缺失。

所以，如果说我们带来了什么差异，我觉得是把这个 benchmark 做成了一个连接评测与训练的研究工具：既看模型能完成多少任务，也希望从它成功和失败的具体过程中，找到下一步应该训练什么、智能体应该怎样设计。

我们希望评测能够推动能力的发展，而不只是记录能力的排名。

5大主流模型PK：表现最好的Astra只有19%

🚥 十字路口

这次选题目的原则是怎样的？有哪些放弃的题目？

👨‍🔧  杨智钦

我们选题的核心原则是：这道题能不能让我们看清通用模型在物理交互中的能力，而且能不能把这种能力可靠地测出来。

具体会看三点：

第一是覆盖面，希望任务涉及不同机器人和物理约束。例如机械臂的接触操作、足式机器人的平衡、车辆的转向，以及无人机的飞行控制。

第二是任务是否需要模型根据观测作出判断、利用反馈调整动作，避免成功主要依赖底层控制器。

第三是能否稳定复现，有明确的初始条件、控制预算和可执行的成功判据。

我们会舍弃重复度很高、没有增加新能力维度的题，也会暂缓那些关键资产缺失、运行不稳定，或者成功条件难以核验的题。但难本身不是舍弃的理由；分不清失败来自模型还是环境，才是更大的问题。 我们也不要求每道题都必须展示复杂推理，一些简单任务可以帮助定位模型究竟在哪个基础环节出了问题。

比较纠结的是一些很有研究价值、但评测条件还不完整的任务。

例如，空中载荷平衡涉及动力学理解与控制，但我们接入的版本缺少关键原始资产，因此暂时没有纳入。另一个例子是无人机排球：双机对抗很有吸引力，但它还需要固定对手策略和运行条件，否则分数会同时受到对手变化的影响。目前我们优先验证了单机颠球，对原版对抗设置保持谨慎。

长远来看，我们也很希望加入无人机、机械臂和足式机器人之间的协作任务。

但这类任务还需要解决各机器人获得什么信息、如何协调，以及失败如何归因的问题。我们更愿意等这些条件定义清楚，再把它作为正式评测。

🚥 十字路口

Bench 设置得会不会有点高？目前表现最好的 Astra 完成率也只有 19.0%

👨🏻‍🚀 胡晓萌

我们选题的初衷不是压低基础模型的分数，而是想看通用模型面对不同机器人、不同任务时，究竟能做到什么程度。

选题时，我们重点考虑机器人形态和任务类型的覆盖，也关注任务是否提出了不同的能力要求：比如精确的空间定位、受约束的接触操作、多阶段任务的协调，以及保持平衡、追踪和接触运动中的目标。我们希望这些任务能够相互补充，而不是在同一种操作上反复出题。

目前的结果说明，模型距离成为可靠的通用物理智能体，还有不少欠缺。但不同模型之间的差距也很明显：Astra 和 Opus 的整体表现明显好于其他参评模型。

进一步看轨迹，这两个模型也不是以同一种方式解决问题，它们会调用不同的先验知识，表现出不同的行为模式，比如怎样利用观察、什么时候编写辅助程序，以及如何根据执行反馈调整动作。

比如同样是堆积木，Astra 一开始根据相机画面估计位置，先完成抓取，之后才引入相机参数拟合来辅助定位；Opus 则先写颜色分割程序，再通过机械臂的试探运动估计相机几何关系，计算抓取位置。

一个先根据视觉判断行动，再补充计算；另一个先建立计算工具，再行动。这让我们直观地看到，模型可以用不同的方式，把视觉理解、编程和机器人知识组合起来解决同一个问题。

所以，我们关注的不只是最高分为什么只有 19%，也关注这 19% 是怎么做到的，以及成功和失败的轨迹反映出哪些能力差距、对应着怎样的训练数据需求。

🚥 十字路口

据你们了解，为什么 Astra 的分最高？

👨🏻‍🚀 胡晓萌

直观上，我们觉得可能有两个方面的原因：

一种可能是，OpenAI 在训练中加入了具身相关的数据，让模型获得了一些机器人任务所需的知识和能力。

另一种可能是，它在视觉理解、Computer Use、编程和 3D 建模等任务上积累的能力，泛化到了 Robot Use。比如视觉定位、理解空间关系、通过代码完成操作，再根据视觉反馈检查和修改结果，这些能力在机器人场景里也能发挥作用。

两种因素可能同时存在，但目前仅凭评测结果，我们还很难判断各自的贡献，更不能据此反推出具体的训练配方。

另外，Astra 在我们的测试里也没有展现出压倒性的优势。

它完成了 16 个任务，Opus 完成了 13 个，两者共同完成的只有 8 个，各自都有对方没有完成的任务。Opus 在四足移动、悬吊负载悬停、无人机颠球等任务上，也展示了很强的能力。

所以，Astra 的总分领先，说明它在这套任务上的成功覆盖更广，但并不意味着每一项能力都更强。我们更关注不同模型各自擅长什么、采用了怎样的策略，以及这些差异能为后续训练提供什么线索。

👨‍🔧  杨智钦

总分领先可能与模型能否更好地利用控制器有关。

比如在充电器插接任务中，Astra 会根据规划器的拒绝反馈调整机械臂配置，再尝试执行。

这说明，已有的运动控制能力要发挥作用，还需要模型提出合适的动作请求，并理解执行反馈。它体现的是推理与控制之间的配合，但单个案例还不足以解释全部分数差异，也不能据此推断训练数据。

🚥 十字路口

在你们的视野范围内，国内的 LLM 基础模型公司，开始重视它们具身相关的能力了吗？

👨🏻‍🚀 胡晓萌

整体上，我们接触到的国内基模团队，对这个方向的探索还处于比较早期的阶段。

Astra 出来之后，我们能明显感受到关注度在提高。从公开招聘信息中，也能看到一些头部团队开始招募相关方向的人才。

据我们了解，确实是有团队已经在新一代模型训练的较早阶段融入具身相关数据，不过我们接触到的大部分团队，目前仍处于预研、搭建评测体系的阶段。

当然，这也和各个团队的优先级有关。基模团队同时要推进很多方向，需要在不同能力和训练任务之间分配资源。

相比之下，我们更聚焦，因此进度更快一些。目前已经有一些团队和我们建立联系，表达了交流和合作的意愿。

模型“斩杀线”背后，什么能力是稀缺的？

🚥 十字路口

你提到，现在很多已有的 agent 能力，其实和具身相关的场景 gap 没有想象中那么大，门槛比想象中低一些。有哪些发现？

👨 李宸鑫

我说 gap 没有想象中那么大，是从做通用 Agent 评测和训练的角度看仿真场景。

我们接环境时发现，很多组件很熟悉：沙盒、Docker、工具接口、轨迹记录，以及动作执行后返回观测和分数。机器人的场景与资产变了，但不少运行和评测逻辑可以复用。

对模型来说，也有一些相近的解题过程。Computer Use 里，模型根据屏幕找按钮，操作后检查结果；机器人任务里，它根据图像和状态决定机械臂怎样动，再看有没有抓住、放对。积木堆叠中出现的颜色分割和相机几何计算，就是把视觉、编程方法用到新的任务上。

这让基模和 Agent 团队有了一个比较直接的切入点。

当然，物理交互会带来新的要求，接触、失稳、误差累积都需要处理；我们当前又允许仿真在推理时暂停，所以还没有解决真机场景的实时性问题。进入研究更容易，部署可靠性仍需要另外验证。

🚥 十字路口

在Paper 中，你们单独列了一个part “机器人闭环在哪里失效”，展开聊聊这个发现和思考？

👨🏻‍🚀 胡晓萌

我们在分析轨迹时，逐渐把 Robot Use 所需要的能力归纳为四类：视觉理解、物理与机器人知识、编程与计算，以及 Agent 能力。 “机器人闭环在哪里失效”，其实就是看这些能力在哪个环节没有发挥作用，或者没有衔接起来。

首先是视觉理解。模型不仅要认出物体，还要理解位置、朝向、遮挡和运动变化，以及执行动作之后，环境到底发生了什么。比如抓取之后，物体是不是真的拿住了；插接时，看起来对齐了，是否真的插进去了。对状态的判断一旦有偏差，后续动作就可能建立在错误的前提上。

第二是物理与机器人知识。看清场景之后，还需要知道机器人应该怎样与它交互。比如四足移动涉及腿部运动学和步态设计，悬吊负载悬停涉及负载摆动和控制，无人机颠球则需要协调触球前后的运动状态。尤其在动态任务中，某一时刻位置正确还不够，还要考虑速度、动作时机，以及能不能持续保持目标状态。

第三是编程与计算。我们看到模型会自己写图像分割、相机标定、逆运动学和控制程序，把已有知识变成可以计算和执行的方法。但程序成功运行，不代表机器人任务就成功了。程序里的假设是否适合当前环境、算出的动作是否有效，仍然需要通过实际执行来检验。四足案例里，Opus 就在执行过程中又写了两版步态程序，调整腿的高度、步幅和转向方式。

第四是 Agent 能力，也就是把前面这些能力组织起来：维护任务目标和历史状态，选择什么时候观察、什么时候计算、什么时候行动，失败之后如何恢复，以及根据什么判断任务完成。我们看到，有的模型虽然还在不断调用工具，但已经不再针对未完成的目标做修正。它继续执行了，却没有继续推进任务。

所以，我们的一个核心判断是：Robot Use 的难点既在单项能力，也在这些能力能否通过执行反馈配合起来。

我们不能看到一个失败，就简单归因于视觉不行或者物理知识不够，而要沿着轨迹看：它有没有看对状态、选对方法、正确实现，以及在结果不符合预期时及时调整。

这也决定了后续的数据需求：既需要补充各类基础能力的数据，也需要完整的交互轨迹，让模型学习怎样在机器人任务中把这些能力用起来。

🚥 十字路口

不同模型之间有明显的“斩杀线”，在你们的观察中，背后的原因是什么？

👨 李宸鑫

“斩杀线”是大家交流时比较口语化的说法。

在这次 84 项任务的评测里，Astra 和 Opus 分别完成了 16 项、13 项任务，其他三个模型分别完成 2 项、1 项和 1 项，表现确实分成了两档。这里指的是当前模型和运行设置下的表现差距，还不能把它当成一条普适、严格的能力阈值。

让我印象比较深的，是模型对任务和接口的熟悉程度。

有些轨迹里，模型知道目标是什么，却一直没能把它落实成有效动作。比如 Kimi 的倒水任务，瓶子被碰倒后，多次抓取仍没有拿住，换机械臂也已经很晚了；Astra 在充电器插接时，能根据规划器拒绝调整机械臂配置，再重试动作。

所以我更关注模型能不能把指令、机器人接口、当前状态和执行反馈连起来。

它要知道下一步试什么，判断刚才有没有推进目标，失败后换一种办法。视觉、机器人知识、编程和 Agent 能力在这里都重要；哪一项拖了后腿，仍要沿着具体轨迹分析，再用消融实验验证。

🚥 十字路口

基模泛化到具身场景，什么能力是稀缺的？

👨‍🔧  杨智钦

从具身的角度，我想补充的是：稀缺的不只是规划能力，还有对身体约束和动作后果的理解。

比如，碰倒瓶子以后，抓取条件已经变了；规划器拒绝执行，也意味着当前动作可能超出了可达范围。模型需要把这些反馈，转化为新的判断。

借用 System 1、System 2 的说法，关键在于高层推理能否根据底层执行的实际情况及时调整，而不是反复尝试同一个方案。这可能是能力差异被放大的一个原因。

未来，Astra会降维打击具身模型吗？

🚥 十字路口

你们认为， Astra 会降维打击所有的具身基座模型吗？——降维打击的程度从轻到重如果是 1-10 分，你们给几分？

👨‍🔧 杨智钦

我比较看重的是，它让我们重新思考：机器人每学会一个新任务，是否都需要重新收集数据、训练一个策略？

通用模型提供了另一种可能——利用已有的视觉理解、推理和编程能力，在执行过程中观察反馈、调整方案，甚至生成控制程序。这也是我们做 RobotWorld 想研究的问题：数字世界里积累的能力，究竟能在多大程度上转化为通用的机器人使用能力。

但任务覆盖面广，不等于每个任务都做得更快、更稳。高频控制、精细接触，以及真实环境中的可靠性，仍然需要扎实的具身技术。

我更看好通用模型与专用控制能力逐步结合。

对具身团队来说，关键是判断：哪些能力会随着通用模型进步而获得，哪些仍需要从物理交互中学习。

未来的竞争，很可能会从“为一个任务训练一个模型”，转向“让已有能力适应更多任务和机器人”。

👨🏻‍🚀 胡晓萌

就 Astra 这个模型目前的能力而言，我觉得还谈不上降维打击所有具身基座模型，两者现阶段仍然有比较明显的赛道分野。

但如果把时间拉长，看未来 Astra 这一类基础 Agent 模型，我会给出更乐观的判断。随着模型能力持续提升，它们与具身基座模型之间的能力边界可能会逐渐变化。

如果说未来“降维打击”的程度达到 10 分，我觉得也不是不可能。

👨 李宸鑫

如果讨论长期趋势，我比较看好 Astra 这类通用基础 Agent 模型。

它们已经能把视觉理解、编程、工具使用和推理用到机器人任务里，随着这些能力继续增强，一部分具身任务的解决方式很可能会发生变化。

但今天说降维打击所有具身基座模型，我觉得还太早。

不同模型面对的任务、观测条件和控制频率不一样，我们这次也没有在统一协议下系统比较所有 VLA。仿真里的成功还不能直接等同于真机部署能力，实时控制、接触和可靠性仍然有很多问题要解决。

我觉得，具身团队需要同时考虑眼前和长期。眼前可以解决通用模型还不擅长的任务；长期则要持续判断基模会做到什么程度，自己的技术怎样与它结合。

今天的能力差距会提供机会，但不能假设这条边界永远不变。

仿真到真机，Gap怎样弥合？

🚥 十字路口

有很多具身的人也在做相关的工作，大家彼此之间的思路上有哪些不同点？

👨 李宸鑫

我常说，我们有一个“基模思维”的出发点：希望 Robot Use 以后像 Coding、Computer Use 一样，成为基础模型持续训练和评测的一项能力。

我们从一开始就在想，这套任务怎样进入基模团队已有的 Agent 流程，评测暴露的问题怎样转成后续的数据和训练目标。

有些工作更关注在一组机器人任务上，把控制方法或 harness 做得更好；有些工作更关注扰动下的稳定性，或者用程序解生成机器人训练数据。我们比较关心任务覆盖是否足够广、能力差距是否足够明确，以及结果能不能为基模下一轮训练提供有用的信号。

我们会花不少精力做沙盒、接口和并发实验的适配，让熟悉通用 Agent 的团队能较容易地开始测试。

任务本身仍然都是机器人任务，我们关注的是它们怎样服务于基础模型的能力评测和后续训练。针对具体任务优化控制、测试扰动鲁棒性也同样有价值，解决的是不同层面的问题。

🚥 十字路口

关于仿真榜单的“题库式刷分”的情况，RobotWorld 的设计，针对这种情形是怎么考虑的？

👨🏻‍🚀 胡晓萌

我们觉得，评测和模型需要共同进化，这是一个动态的过程。

我们并不排斥具身团队或者frontier lab针对 RobotWorld 暴露出来的问题做针对性的训练，因为评测的价值之一，就是帮助大家找到能力缺口，再推动模型补上这些能力。

RobotWorld 覆盖了不同的机器人形态和任务要求。如果一个模型能把这些任务都真正做好，即使提升来自有针对性的训练，我们也认为这是有价值的进步。要覆盖这么多任务，模型需要掌握空间理解、机器人知识、编程和闭环执行等多方面的能力，这些能力也有机会迁移到新的场景中。

当然，是否产生了泛化，最终还是要用新任务和新条件来检验。

模型在现有任务上做得越来越好，我们就继续扩展任务、改变场景和约束，看看它学到的方法能不能迁移。

接下来，我们也会根据模型的能力进展和社区需求，持续更新和维护 benchmark 与榜单。我们希望形成“评测发现问题、训练提升能力、再用新的评测检验能力”的循环，让评测持续推动模型进步。

🚥 十字路口

仿真环境测试的结果是一种理想状态，在真实工厂里其实是另一套难题，能不能完成任务，可能是 0 和 1 的区别。你们怎么看待这个问题？

👨‍🔧  杨智钦

我认同这个判断。

在真实工厂里，一次任务失败可能意味着停线、物料损坏，或者需要人工接管。除了能否完成，还要看节拍、连续运行的稳定性和异常处理能力。因此，仿真成绩不能直接等同于工业部署能力，接触误差、传感器噪声、设备磨损等问题，都需要在真实系统里验证。

不过，仿真的价值在于，它提供了一个可重复、可控制的比较条件。我们可以让不同模型面对相同任务、初始状态和预算，分析差异究竟来自哪里。

真机测试更接近最终应用，但要把它做成大家都能公平参与的 benchmark，困难很大：硬件、标定、场地和维护状态很难完全一致，每次重置、处理失败和检查安全也都需要人力。扩大任务和测试次数，还需要持续的资金投入。

我们希望后续结合真机验证，更现实的路径是：用仿真做广泛、可复现的评测，再用真机检验其中关键的能力和结论。

比如选择有代表性的操作和移动任务，在固定硬件与明确的人工干预规则下，检查模型在仿真中表现出的反馈利用、错误恢复等能力，到了现实中还能保留多少。

我们希望逐步建立两者之间可信的联系，而不是用几个成功的真机演示来证明整个 benchmark 的有效性。

👨🏻‍🚀 胡晓萌

我们认可仿真与真实世界之间存在 gap，感知误差、控制延迟、接触和摩擦变化都会影响执行，仿真中的成功率也不能直接等同于实际部署能力。

我们正在考虑选择一些表现较好、相对稳定的操作类场景做真机验证，但这还不是现阶段的最高优先级。

目前，模型在仿真中仍有不少基础能力需要补足，我们希望先把这些能力做扎实，同时让仿真条件更接近真实环境，再结合模型的进展逐步推进真机验证。

Agent做大脑，Code做小脑

🚥 十字路口

你们也发起了一个讨论社区，有哪些来自社区的普遍关注的话题？

👨🏻‍🚀 胡晓萌

RobotWorld 社区建立之后，关注和反馈比我们预期多。

很多朋友来找我们，说他们最近也在做相关的事情。比较让我们惊讶的是，这些同学之前大多不是具身背景，有些甚至也不是做 Agent 的。

大家的讨论也挺具体，有人提下一版可以做什么，有人指出目前设计里可以改进的地方，也有不少同学想直接参与后续迭代。这些反馈确实帮我们发现了一些之前没考虑到的问题。

我们最近正在逐条看这些建议，有些已经采纳，也在动手修改，近期会放出一个新版本。我们希望这个社区能让大家更方便地交流，一起参与 RobotWorld 后续的迭代。

🚥 十字路口

目前有收到哪些来自外界的 challenge？

👨🏻‍🚀 胡晓萌

目前一个比较集中的质疑是时延。

在一个叫 Agent Hub 的群里，大家讨论过我们的工作，第二天群里的机器人把这场讨论总结成了“具身控制延迟与泛化路线之争”，我觉得概括得挺准确。

一部分朋友认为，Agent 控制机器人到了真机场景，尤其是需要快速反应的任务，推理和交互延迟会成为很大的障碍。另一部分朋友则认为，随着基础模型、推理基础设施，以及模型编程和控制能力的提升，这条路线还有很大的想象空间。

我们整体更认同第二种观点。

从 ChatGPT 出来到现在，我们一直在参与基模相关的工作。Coding Agent、GUI Agent 早期也很慢，后来随着模型、harness 和 infra 不断改进，才逐步具备可用性。机器人当然有更严格的实时性要求，但我们不认为今天的时延就决定了这条路线的上限。

更关键的是，我们设想的并不是让大模型每一步都直接控制电机。

它可以负责理解任务、制定策略、编写和调整控制程序，由程序承担需要高频响应的执行，也就是“Agent 做大脑，Code 做小脑”。这样，大模型的推理频率和底层控制频率就不必绑定在一起。

前两天我们在深圳参加了一场具身相关的线下活动，交流中也有不少从业者跟我们不谋而合。

另外，在“小脑”的实现上，我们目前更倾向于代码，而不是再接一个小型 VLA 这样的模型。

一方面，引入另一个模型会增加系统的复杂性，需要额外考虑两个模型之间的配合。相比之下，我们更看好围绕单一模型+harness持续优化和 scaling 的路线。另一方面，代码有明确的执行逻辑，也更容易检查和修改。

🚥 十字路口

现在活跃的做 Benchmark 团队，可以分成哪几类？你们把自己归为哪一类?

👨🏻‍🚀 胡晓萌

我主要关注最近这一批 Coding Agent 和具身交叉的工作，我自己把它们看作“后 Astra 时代”的具身评测。大家都在关注 Coding Agent 和物理智能的交叉，但切入点不太一样。

比如 EmbodiedSWE，让 Agent 在仿真中编写机器人控制程序，通过运行反馈反复调试和修改，得到能够完成复杂任务的程序解，再把这些成功解扩展成 VLA 的训练数据。

它的主要设置允许访问完整仿真状态，也给了比较充分的程序开发时间。这个工作的侧重点还是如何利用 Coding Agent 来 scaling VLA 训练数据。在我们的 setting 下，Agent 也可以编写闭环机器人控制程序，但我们的用法是在 Agent 的大 loop 中，通过 Code Control 的小闭环解决一些实时性子问题。

Video2World 关注的是环境构建：让 Coding Agent 根据机器人或人类的演示视频，重建可交互的仿真场景和机器人行为。这也是一个出发点比较 fundamental 的工作，在探索如何为具身研究提供更多环境。

RLE-Bench 则更偏机器人领域的 Auto Research & Engineering 评测，看 Coding Agent 能不能像机器人工程师一样，完成控制、策略训练、感知估计和机械设计等工作。

如果一定要给自己一个定位，我想，相比之下，我们的步子更大一点。我们希望未来 Robot Use 能像 Coding、Computer Use 一样，成为基础模型持续训练和评测的一项能力。

🚥 十字路口

RobotWorld 想要嵌入基模训练评测的闭环，现在达到什么程度了？

👨🏻‍🚀 胡晓萌

我自己是基模背景，之前主要精力放在训练上。

在我的视角里，从评测接到训练，很多时候主要是 infra 的衔接问题。

RobotWorld 的交互范式，和基模团队熟悉的 Coding Agent、GUI Agent、General Agent 评测很接近。因此，把它接入已有的评测流程，进一步用于训练，在技术路径上没有特别大的障碍。

具体能推进到什么程度，更多取决于组织层面的因素：各个团队的优先级是什么，愿意投入多少资源。这需要他们根据自己的判断来决定。就像此前大家对 Coding Agent 的投入也不一样，当 ROI 逐渐清晰，团队自然会加码。

其实做一个好的benchmark，就已经向外界传达了我们对于这个方向training的看法了。

我们现阶段还是以打磨好自己的工作、持续跟进前沿进展为主。我们不会把推动每一家团队都将 RobotWorld 纳入训练闭环作为目标，而是希望通过工作的实际价值，为社区多做一些贡献。

关于信仰：等待具身的 Scaling 时刻

🚥 十字路口

你们提到，坚信 scaling law 在具身智能上会再发生一次，这也是 RobotWorld 的起因。这个长期大方向的赌注背后，你们看到了什么不一样的东西？

👨‍🔧  杨智钦

我的判断更多来自具身系统本身。

机器人既需要快速、稳定地响应环境，也需要理解目标、规划动作，并在出错后重新判断。如果借用 System 1 和 System 2 的说法，前者更接近熟练的运动技能和即时反应，后者更接近需要推理的决策。

我看好的，是这两类能力能够共同学习、相互促进。

比如机器人端着托盘走路，维持平衡需要持续、低延迟的控制，不适合每一步都交给大模型思考。但遇到狭窄通道时，要不要换路线、调整姿态，或者先把托盘放下来，就需要结合任务和环境作判断。真正困难的是两者如何配合：什么时候可以依赖已有技能，什么时候应该停下来重新观察，以及上层计划是否超出了身体的执行能力。

这也是我理解具身 scaling 的一个重要角度：随着经验积累，原本需要反复推理的动作，能不能逐渐变成快速、可靠的技能？这些技能能不能被重新组合，去解决更复杂的任务？同时，执行中的接触、失衡和失败，能不能反过来帮助模型形成更准确的物理判断？

如果这个循环能够成立，增长的就不只是模型知道多少，而是整个系统能够稳定做成多少事情。

RobotWorld 目前主要在测通用模型使用机器人的能力，还没有验证完整的双系统学习路线。但我希望通过跨机器人、跨任务的评测，分清哪些瓶颈来自理解和规划，哪些来自控制与身体约束，以及问题是否出在两者的衔接上。

👨 李宸鑫

我和晓萌都做过基础模型和通用 Agent，因此对这条路线比较兴奋。

我们看到，模型已经能在一些机器人任务中用到视觉理解、编程和推理能力。如果这些能力可以继续从数据和交互中学习，我愿意相信，具身也会受益于有效数据和算力规模的扩大。

我们也有一个可以动手的切入点。仿真场景里的沙盒、工具、执行反馈和评分机制，和通用 Agent 的评测有不少相似之处。先把能力测出来，再围绕失败设计数据，改进训练和交互方式，这条研究路径是具体的。RobotWorld 是我们先迈出的评测这一步。

接下来，我更想检验这些训练经验能迁移多少：增加什么数据能让模型更会使用机器人接口，怎样的交互训练能减少无效重试、提高完成度判断，换任务和初始条件以后，提升是否还存在。

严格的 scaling 规律需要受控实验来建立，这些问题也值得我们长期投入。

👨🏻‍🚀 胡晓萌

我们的出发点还是这件事在原理上是否可行。

我的一个基本判断是：如果一种能力可以通过数据和交互学习，那么持续扩大有效数据、算力的规模，就有机会推动它进一步提升。

我倾向于把 Robot Use 能力理解为：视觉理解能力 × 物理与机器人知识 × Agent 能力 × Coding 能力。

这里的乘号强调的是这些能力需要协同，任何一项不足都可能成为瓶颈。

我目前没有看到原则上的理由，说明这些能力不能通过学习获得。反过来，这些基础能力正在现有模型中不断增强，这也是我看好这条路线的原因。

参考资料

[1]RobotWorld：https://robotworldai.github.io/

推荐阅读

加入会员群

评论有奖

跳转微信打开