1天前 今天我们谈谈Astra到底会对具身产生什么影响

出品：具身纪元

GPT-6 Astra 把红色方块放进碗里，20 次尝试成功了 19 次。同一项 Robocurve测试中，Fable 5.1 的成绩是 8 次，通用模型操作机器人的能力，又一次引起了具身领域的讨论。

Jim Fan 把 Astra 称为新的 VLA，并将多模态编程放在机器人 System 2，也就是较慢的推理系统的位置上。

Jim Fan 对多模态编程与机器人慢推理系统的判断(已经删帖），X，2026 年 9 月 9 日。

Phillip Isola 在 Robot-use agents 一文中讨论的，则是让通用 Agent 像使用电脑一样，通过接口使用机器人。模型升级带来的视觉理解、推理和编程能力，也就有机会直接用于物理任务。

与此同时，X 上出现了另一类演示。卡内基梅隆大学机器人研究所硕士生 Lingxiao Guo，将机器人演示数据交给 Astra，尝试让它完成场景重建、相机对齐和仿真试验，最终交付 MuJoCo 场景与 Blender 渲染。

通用模型正在使用机器人的身体，也开始帮助研究者准备和调试机器人工作的环境。

这些演示值得关注。但语言模型写机器人程序，早在 Code as Policies时就已经有人做了，这一次究竟多了什么？

Astra好像可以端到端控制机器人了

LLM 进入机器人，早就开始了

2022 年的 SayCan 提出了一个实际问题。语言模型知道一件事情应该怎么做，但它提出的步骤，这台机器人真的做得到吗？

比如，人说自己把饮料洒了，模型可以建议拿纸巾、擦桌面。可如果机器人够不到纸巾，或者没有擦拭技能，这份计划就无法落地。

SayCan 将两种判断结合起来。语言模型判断某个技能对任务是否有用，技能的价值函数估计它在当前状态下是否可行，系统据此选择下一项技能，再交给已有机器人策略执行。

同年的 Inner Monologue 又把反馈接了回来。物体识别、场景描述、动作是否成功，都可以转成语言放进模型上下文，让它更新计划。

如果机器人抓空了，模型需要知道抓空这件事，才能调整下一步。

Code as Policies，简称 CaP，进一步让语言模型直接编写机器人策略程序。

把红色方块放进碗里，和把所有方块按颜色分类，调用的底层能力可能相似，执行逻辑却不同。后者需要遍历物体、判断类别和选择目标，Python 可以表达这些关系。

CaP 给模型提供机器人 API 的用法、示例指令及对应代码，让它将新的自然语言要求组织成程序。程序读取感知结果，调用控制原语，也可以借助 NumPy、Shapely 等库计算几何关系。

Code as Policies 用策略代码连接任务指令、感知 API 与控制 API。

代码还可以包含条件、循环和反馈控制。假设程序反复读取物体位置，再根据新位置调整目标，反馈就能在程序运行时被处理，不必每一步都重新调用语言模型。

选技能、写程序、读反馈，这些工作都有了相当长的积累。 Astra 的表现，需要放在这段连续发展的历史中理解。

Astra 把看图、空间判断与位姿输出都包圆了

在 CaP 的典型管线里，模型先写代码。代码需要知道方块在哪里时，会查询感知 API，再根据返回的坐标计算抓取或放置目标。

假设任务是把物体摆成一排，模型负责写出查询、排序和计算间距的逻辑，程序负责把这些逻辑应用到当前场景。感知模块提供位置，控制接口执行移动，任务要求如何变成动作，仍然由模型生成的程序决定。

Robocurve 的 Astra 实验，让从视觉观察直接生成动作目标的端到端可能性变得具体。模型直接读取图像和机器人状态，给出末端目标位姿，承担了典型 CaP 管线中一部分依赖感知工具与策略代码的工作。

每一轮，模型收到顶视、左腕和右腕三路图像，以及机器人自身状态。它根据观察和交互上下文，决定下一次动作调用，其中包含末端执行器的位置、朝向和夹爪参数。

Robocurve 的方块入碗演示，模型提出动作目标，机械臂完成执行。

模型在这里需要把画面中的空间关系对应到机器人的动作坐标里。夹爪应该先靠近哪里、朝向怎样调整、执行后有没有偏离，都可能进入下一轮判断。

对机器人开发者来说，这意味着一部分任务不必先把画面转成结构化的物体坐标，再交给策略程序。模型可以结合当前观察与执行历史，直接提出下一步的目标位置和朝向；动作完成后的新画面，又成为它继续判断的依据。

Robocurve 的 Jay Chooi在回复中也提到了 Astra 的视觉与三维理解能力。Astra 将过去分散在感知工具与策略代码中的一部分判断纳入了模型推理。

Astra 调用的 move_to 接口接收末端目标，机器人端的逆运动学，也就是 IK，将其转换为关节目标，再由低层控制器驱动电机。

两种配置中目标的形成方式不同；图示中的 Astra 指 Robocurve 实验配置。

更有吸引力的变化，是通用模型在视觉、推理和编程上的进步，有机会直接进入机器人系统。部分工作可以通过更换模型、改善上下文和工具描述获得提升，不必全部从训练一个新的动作策略开始。

Astra 能端到端完成抓放，Robotics 的问题就解决了吗？

看到模型从图像直接给出位姿，并让机械臂完成抓放，很容易产生一个疑问，Robotics 的问题是不是快被通用模型解决了？Robocurve 的另一项测试给出了边界。把带中央旋钮的蓝色圆形拼块放进匹配凹槽，Astra 和 Fable 5.1 都只成功了 2/20 次。

同一个模型，面对容差较大的抓放和更精细的插入，表现有明显差距。

每个模型每项任务各测试 20 次；方块任务使用了不同设备，试验日期也不同，结果由知晓模型身份的操作员评分。

目标已经在眼前，仍然可能放不进去。插入需要更精确的对齐，也涉及接触后的调整；仅凭画面判断大致到位，还不能保证动作成功。

速度是另一项约束。即使动作判断正确，物体也不会等模型想完再开始滑落。

Anthropic的机器人研究提供了一个例子。在 Go2 的直接低层控制设置中，实时运行需要约 83 Hz 的更新，而当时非推理模型调用约为 0.2—0.4 Hz。[10]一个富接触的任务，可能需要至少30hz的实时速度，这对大模型来说还是困难的。

真实机器人没有这个暂停键。

Jitendra Malik 对这波讨论的回应主要落在灵巧性、动力学和高频控制上。

换成灵巧手，动作问题还会复杂得多。高维动作空间，让建模和解算都非常困难。让一个物体在掌中转过一定角度，除了手指关节的位置，还需要决定哪些手指保持接触、哪里允许滑动、每个接触点施加多大的力。

物体开始打滑时，抓紧一点还是换一个支撑点，也取决于形状、材质和当前接触状态。接触会随着运动改变，视觉又未必能看见所有接触点，执行系统需要持续处理触觉、力和运动反馈。

把目标位姿写出来，与稳定完成一段灵巧操作之间，仍有大量动作建模和物理交互问题。 这些能力需要由实际操作来检验，也让有针对性的接触与失败恢复数据继续具有价值。

更强的模型，其实指向了一个更强系统的机会

Google Robotics Max Fu 的评论提供了一种务实的判断。他认可多模态模型在机器人任务上的进步，同时认为配合更好的执行框架、工具调用和技能库，可以更快、更便宜、更可靠，VLA 和世界动作模型也可以成为这套能力库的一部分。

这给机器人系统留下了不少可做的工作。

通用模型可以理解任务、组织程序、检查执行结果。已经成熟的感知、规划和操作能力，可以继续以工具或策略的形式被调用，熟悉的动作不必每次都让模型从头安排。

过去藏在团队内部脚本和调试经验里的信息，也需要被更好地交给模型。目标使用哪个坐标系、单位是什么、机器人是否仍在运动、一次失败发生在哪里，都会影响下一步判断。

一个接口只返回 failed，模型很难分辨是目标不可达，还是夹爪没有夹住物体。更完整的状态和诊断，才能让它选择对应的恢复动作。

ASPIRE 将执行反馈与经验积累连接了起来。 它延续 code-as-policy 范式，Agent 编写机器人程序，执行系统返回多模态轨迹与反馈，模型定位失败、修复代码，再把有用的经验保存在技能库中。

ASPIRE 将程序执行、失败诊断、代码修复与可复用技能连接起来。

下一个任务到来时，这些经验可以作为上下文被检索使用。技能库保存的也可以是调试知识，例如什么现象对应哪类失败，哪种调整在什么条件下有效。

这类积累让 Agent 有机会减少重复试错，也让通用模型的编程能力更容易转成可复用的机器人经验。

Waddle 的公开软件栈则展示了另一种分工。底层 SDK 处理硬件通信与约束，中间的工具层提供 IK、轨迹规划和物体分割，上层 Agent 服务管理模型、上下文与执行循环。

Waddle 的模型、工具与硬件适配关系，根据其公开架构说明整理。

Anthropic 的 Model Hardware Standard，简称 MHS，也在尝试让物理设备以统一方式被发现、描述和调用。

其中一个激光对齐案例很能说明这种协作。Claude调整激光，通过相机观察变化，反复探索后把方法写进确定性程序，使后续对齐可以作为一条命令执行。

模型探索出的办法，由程序接着执行，运行速度就不必受每一步在线推理的限制。

更灵巧的机器人也需要这种时间尺度上的分工。较慢的推理系统决定任务和目标，快速的动作策略或控制器持续处理运动与接触，遇到需要重新判断的异常，再把信息交回上层。

一种可行的分层组织方式；快速执行仍需持续获得感知与接触反馈。

模型也开始帮助研究者搭建仿真

回到开头另外一个real to sim的例子，我们看到除了决定机器人下一步做什么，模型还可以参与机器人开发中大量耗时的准备工作。

Lingxiao Guo 的公开项目，包含 DROID 抓放、推动水龙头把手，以及 YAM 双臂安装麦克风三个任务。

DROID 笔抓放任务的多视角真实记录与仿真对比，来自 Lingxiao Guo 的公开项目。

这套重建用了现成的机器人模型、记录的关节角度和已有的相机标定信息，也需要人工在图像上标出一些位置。借助这些参照，模型可以调整相机和物体的位置，让仿真画面与真实拍摄的多个视角对得上。[17]

在这套流程里，MuJoCo 负责物理仿真，Blender 负责渲染（codex适配blender非常丝滑）。模型可以组织场景脚本和数值计算，检查真实与仿真的差异，再修改几何、参数或试验设置。

这种迭代已经能完成部分任务。DROID 的笔抓放实现了由接触产生的提起、转移和放下，水龙头把手也能通过夹爪接触带动被动铰链转动。

但仿真还不能准确还原所有物理过程。真实记录中，笔放下后发生了滚落，仿真没有重现；麦克风任务虽然画面接近真实，但四种接触仿真方案都没能完成安装。画面对齐了，物体也未必会按真实情况运动。

YAM 麦克风任务的真实记录与接触仿真对比，作者标明该物理回放未完成任务。

即便如此，开发过程已经出现了值得利用的变化。模型可以帮忙写场景、跑试验、检查差异和尝试修正，研究者有机会把更多精力放在判断误差来源、补充测量和设计下一项实验上。

反复调试仍然存在，但不必每一步都由人亲手完成。更容易制作场景，可以帮助训练和评测扩展。

机器人研究的工作，到底会怎样变化

回到 Astra 把红色方块放进碗里的那一刻。它背后有通用模型，也有相机、机器人接口、IK 和控制器，几层能力共同完成了一次物理操作。

大模型能否解决所有 Robotics 问题，我觉得现在还很难下判断。更值得关注的是大模型团队会成为行业非常有竞争潜力的力量。更聪明的大脑也可能学得更快。如果通用模型能更有效地吸收运动、触觉、力觉和失败恢复等数据，它在物理交互中的学习能力也可能随之增强。

同时，它的进步，正在帮我们看清哪些才是真正需要继续投入的真问题。

当通用视觉理解越来越强，机器人能否稳定完成任务，就会更直接地受制于物理接触能力。灵巧手、复杂接触、触觉和力觉，以及相应的动作建模与物理反馈，也就更值得投入。也就是说system 2依旧是robotics要解决的问题。

还有，我们怎么能让大模型更为机器人所用呢？我们在上次和穹彻的访谈中也谈到了这个问题。

我们更看重的，是通用模型的进步可以进入越来越多的机器人工作环节，服务于RobotRsiGPT-6 未必能当好机器人的大脑，却可能帮王兴兴加速RobotRSI

机器人团队值得继续改进分层系统。让模型获得足够的上下文和执行反馈，让找到的修正办法进入程序与经验库，也让成熟技能可以被稳定调用，通用能力才更容易变成持续工作的能力。

仿真开发则提供了另一种机会。模型帮助制作资产、对齐场景和组织试验，有望减少研究者反复处理工程细节的时间，让新的想法更快获得检验。

对依赖人工建模和对齐的部分工作来说，这可能意味着原有技术门槛在降低，研究价值需要向更难的几何、材质和物理一致性问题推进。

对需要大量仿真环境的 Robotics 来说，是个好消息。如果场景搭建和调试变得更容易自动化，机器人策略的迭代也有望随之加快。模型可以参与提出修改、运行试验和分析失败，让更多研究步骤连续执行。自动化研究（auto research）因此有了更大的实践空间，仿真也可能凭借更低的准备成本和更容易扩展的试验规模，在机器人研究中获得更重要的位置。

讨论了很多，还有非常多未尽的话，希望大家在评论区多多讨论交流。