用GPT-6 Astra就能直接控制机器人？可具身真机没那么简单

编辑｜冷猫 谁也没想到， AGI 随着 GPT-6 的到来竟然来得这么快。 GPT-6 Astra 的强大的基础通用模型能力有目共睹，大模型的 RSI 竟恐怖如斯。 几家欢喜几家愁。在此之前，谁也没有想到，这个基础模型能够在具身智能领域掀起一场巨大的浪潮。 就在 GPT-6 Astra 发布后的第二天，Robocurve 将它直接接入机器人执行任务，并惊奇的发现 GPT-6 Astra 在控制机器人方面强悍的夸张，Token 消耗也低的夸张。 GPT-6 Astra 在一项机器人控制任务中的 成功率达到 95%，高于 Fable 5.1 的 40% ；与此同时， 输出 Token 用量仅为后者的约 1/6.2 ，成本约为后者的 1/2.3 。 于是这一切开始一发不可收拾，用 GPT-6 基模控制机器人执行复杂操作的案例似雨后春笋。 好了好了，这下好了。我在具身智能领域很焦虑。 通用人工智能模型将接管具身智能领域的讨论越来越多，甚至大有「GPT-6 横扫具身」，具身智能将成为「这类模型的一个子领域」的趋势。 有知名具身智能企业的创始人表示，今天的具身智能还没有真正的护城河，通用模型公司在人才、算力和资金上占优，「未来一两年将是关键窗口」。Robocurve 提到，如果这一趋势持续，大语言模型最早可能在今年年底、最晚在 2029 年实现对机械臂的实时控制。 不过，亮眼的单项成绩，并不意味着基模已经能够在真实环境中安全、稳定地控制机器人。RoboDojo 团队在官方评测中指出， 「Astra 在真机测试中反复发出物理上不合理或不安全的动作，部分事故甚至造成了硬件损坏。」 出于安全考虑，团队提前停止测试，因此 Astra 未能完成 原定包含 18 项任务的 RoboDojo-Real 评测。 这也提醒我们： 基模能力的突破只是起点。 如何约束动作、处理失败，让机器人安全、稳定地持续工作，仍是系统层面必须解决的问题。 基模在变强，但通用是一把双刃剑。 正如打造智能体需要在基模之上构建 Harness 一样，具身智能上缺少的，是一套让经验积累、让能力持续生长的系统。 我们发现了这样一个研究工作： 近日， 穹彻智能发布 RoboRSI ，一个面向真实复杂场景的机器人多智能体自进化框架。 穹彻智能试图回答的正是这个问题：当基础模型已经具备强大的理解和推理能力后，如何在系统层面构建起持续执行、诊断、修订和复用的完整闭环。 技术博客：https://lab.noematrix.ai/blog/2-roborsi/ GitHub：https://github.com/nssmd/RoboRSI 多智能体自进化：为具身智能打造的 Harness 单次成功和长期稳定运行之间，隔着一整套系统级的能力。 两个核心难题： 第一，谁来处理执行过程中的各种异常？ 机器人报错停止、抓取失败、位置偏移之后，需要结果检查、异常恢复、进行安全决策。这些工作过去全靠工程师手动跟进。大模型可以理解任务目标，但它不能负责现场恢复，不判断执行是否成功，也不决定下一步从哪个节点继续。 第二，历史经验如何真正实现沉淀复用？ 如果每次都让 Agent 参考过去的完整执行记录，Token 消耗会持续增长，反而让模型难以聚焦。如果每次碰到局部失败就重写整套流程，系统也很难收敛。研究团队观察到一个关键现象：Coding 模型擅长处理局部细节，但在反复修改中容易偏离全局目标。缺少结构性约束的迭代，往往越改越乱。 Context 管理是新时代的代码管理。 过去，机器人系统的核心挑战是写出正确的控制代码。在 Agent 时代，代码可以由模型生成和迭代，真正的瓶颈转移到了如何管理 Agent 在持续运行中产生的海量上下文：轨迹、日志、视频、代码版本、失败记录。管理不当，系统就会在迭代中走向混乱。 穹彻智能的设计哲学由此展开，可以概括为一句话： 给人和 Agent 各自提供合适的接口。 对人，提供「高层引导」（Human-Friendly Steering）：无需深入底层实现，专注于目标设定、专业判断和安全边界，将日常执行交给多智能体。 对 Agent，提供「清晰结构」（Agent-Friendly Structure）：通过层级化技能树，明确修改范围、成功标准和失败反馈路径，让局部修订始终围绕全局目标展开。 所以，不管基模能力再强大，也需要一个系统级的 Harness 框架，使其能够适应具身智能的需求。RoboRSI ，正是围绕这两个问题构建的具身智能版的 Harness。 四个角色，一个闭环 具身的上下文可不是那么好管理的。 机器人的执行过程包含大量图像、轨迹、工具调用和失败细节，如果全部堆在一个上下文里，模型很快就会在信息膨胀和错误归因中失去方向。为此，多智能体是一个很好的解决方案。 RoboRSI 的做法是把规划、执行、诊断和修订拆分到不同的上下文中， 采用 Manager、Planner、Engineer、Reviewer 四类智能体协作的架构 。 Manager 是整个系统的调度中枢，负责任务队列管理、并发 worker 调度、断点恢复和技能版本管理。它把用户输入的高层目标分解成可执行的任务序列。 Planner 根据当前环境观察和已有技能库，生成具体的执行计划。它做的事情接近于「我看到了什么、手里有什么工具、所以这一步应该怎么做」。 Engineer 是真正动手的角色。它调用机器人 的底层工具（感知、导航、抓取、放置等），执行动作并生成候选能力。 Reviewer 在执行完成后登场，根据执行结果（日志、视频、轨迹）复盘问题、定位失败原因，并把修订建议返回给 Manager，推动下一轮迭代。 这四个角色围绕同一个任务和同一份执行证据接力运行，形成一个完整的「执行→诊断→修订→再执行」闭环。 关键在于，人类仍然保留着对目标、价值判断和安全边界的控制权。在真机上，人负责安全监管和方向调整；在仿真中，系统可以自动完成更多的复位和判定。 工程师的角色因此发生了根本转变：从逐行编写任务代码、跟进每一次底层执行，转向设定目标、审核结果和提供方向性指导。 TSR：给 Agent 一棵「技能树」 让机器人持续迭代，并不只是让 Agent 一遍遍尝试。最重要的是把尝试后的结果与经验沉淀下来。 穹彻智能为此提出了 TSR（Top-down Skill Refinem ent，自顶向下技能细化） 机制。它用一棵四层的技能树来组织机器人的全部能力： 任务族（Task Family） ：定义总体目标与约束，比如「家庭地面清理」。 复合技能（Compound Skill） ：组合多步能力，比如「搜索目标→移动→抓取→放置」。 原子任务（Atomic Task） ：边界明确、结果可验证的最小任务单元，比如「抓取地面上的黄色包装袋」。 基础技能（Base Skill） ：与机器人直接交互的底层能力，包括视觉感知、移动控制、抓取、放置等。 为什么需要这样一棵树？这棵技能树的作用，是为 Coding Agent 提供结构性约束。每次修 改都被限 制在清晰的技能边界内 ，Agent 可以专注于局部实现和修订，但不会因为连续调试而偏离全局任务目标。 历史经验由此从对话记录和日志，变成了下