第一部分 ASPIRE: Agentic /Skills Discovery for Robotics

1.1 引言与相关工作

1.1.1 引言

如原论文所述，近期在软件工程智能体方面的进展表明

1. 语言模型可以自主检查执行轨迹、定位故障、修订实现，并通过与执行环境的反复交互不断改进 [Anthropic, 2025, OpenAI, 2025,anomalyco, 2025, Wang et al., 2025, Yang et al., 2024]
2. 在机器人领域，这一范式启发了 code-as-policy 系统，将感知模块、规划 API 和控制原语组合成可执行的机器人程序[Liang et al., 2023, Singh et al., 2023, Ahn et al., 2022, Huang et al., 2023, Mu et al.,2024, Fu et al., 2026]
   
   由于机器人行为以程序的形式被显式表示，它们原则上可以被检查、编辑、调试，并通过交互反馈加以改进

然而，现有的机器人编程智能体在本质上仍然受限于“幼稚”的执行环境，这类环境仅能提供粗粒度的任务级反馈。调试机器人程序本身就极具挑战性，因为失败可能源自许多相互作用的组件，包括多模态感知、运动规划、抓取生成、接触动力学以及长时程任务协调。一次执行失败或许只能表明任务没有成功，但无法说明其根本原因究竟是错误的感知、不稳定的抓取、规划错误，还是后续恢复阶段的失败

在缺乏细粒度诊断追踪的情况下，智能体在决定应检查哪些证据、如何定位故障，或应尝试何种修复策略方面能力有限

1. 此外，现有系统无法在不同任务之间累积经验。一旦某个任务完成，已发现的修复方法和恢复策略就会被丢弃，而不是被整合为可复用的技能
   因此，正在解决第一百个任务的智能体，实际上并不比解决第一个任务的智能体更有经验
2. 但人类机器人工程师采取的是一种根本不同的方法。当机器人程序失败时，他们会回放执行过程，检查感知输出和运动轨迹，定位出错的子系统，修改实现，并将可复用的恢复策略内化
   
   随着时间推移，调试经验会不断积累为可迁移的知识，包括抓取恢复启发式方法、导航策略、提示“配方”、以及能够在不同任务间泛化的过程性修复方案。这种可复用知识的累积，是人类机器人程序员随着时间推移变得越来越高效的关键原因之一

对此，来自的研究者提出了 Aspire，这是一种自我改进的持续学习机器人系统，它在“代码即策略”（code-as-policy）的范式下，能够自主编写和优化机器人控制程序，同时将经验不断积累到一个可复用的技能库中

与在固定的“感知—规划—执行”框架内运行的方式不同，在整个流程中，Aspire 运行于一个开放式学习循环中，在该循环中，智能体自主决定如何检查执行轨迹、诊断失败、综合生成修复方案、验证被纠正的行为，并将成功的恢复模式固化为可在不同任务间迁移的持久技能

图 1 给出了 Aspire 的整体概览。Aspire 由三个组件构成

1. 首先，一个闭环机器人执行引擎，用每个原语级别的执行轨迹替代粗粒度的 rollout 级反馈
   对于每一次感知、规划、抓取和控制调用，执行引擎都会记录其观测、输入、输出，以及在可能情况下的视觉证据
   这些丰富的多模态轨迹使得智能体可以有选择地检查关键的原语日志，逐步定位失败原因，并通过重新执行来验证修复效果
2. 其次，Aspire 维护一个不断扩展的技能库，将已经验证的修复提炼为可复用、可迁移的机器人知识，在未来任务中可作为 in-context 指导被检索
3. 第三，Aspire 采用一种进化搜索过程，生成多样化的任务序列和控制程序，通过迭代调试与并行改进，探索超越单一轨迹的自我提升空间

这三个组件共同构成了一个性能随经验而持续提升的机器人系统：Aspire 看到的任务越多，其技能库就越庞大，也就能越多地迁移到新任务、更长时间跨度的行为，以及现实世界中的机器人场景中，在不同具身形式下复现相似的故障恢复模式

1.1.2 相关工作

1.2 Aspire的完整方法论

Aspire 由三个组件构成，这三者共同形成一个开放式的学习循环：

1. 一个机器人执行引擎（§2.1），用于暴露每个原语级别的多模态轨迹以便进行故障归因，并执行由智能体编写的修复方案以进行闭环验证
2. 一个技能库（§2.2），用于将通过验证的修复不断积累为可复用的技能
3. 一种进化搜索过程（§2.3），用于将探索范围扩展到单一轨迹修复之外
   随着Aspire 遭遇的任务不断增多，其技能库也持续增长，使得后续任务可以继承先前积累的修复方案和可复用策略

如图 1 所示，Aspire 采用协调器–执行体（actor）架构。中央协调器负责管理共享技能库，并将执行体编码代理分派到各个任务；同时，每个执行体在机器人执行引擎内编写、执行、诊断和修复机器人程序

各执行体之间不会交换完整的对话历史或原始 rollout 轨迹；相反，可迁移的经验会被提炼并存入技能库，从而使每个执行体的上下文窗口始终聚焦于任务规范、当前程序以及与当前失败相关的结构化执行轨迹

1.2.1 机器人执行引擎

具身编码智能体需要执行证据来调试机器人程序。以往的方法通过固定的、人工设计的接口暴露这些证据，通常形式为人工整理的场景级摘要或一组预定义观测。这导致了一种权衡：证据过少可能会隐藏失败的原语，而过多的原始视觉上下文则可能分散智能体对导致该失败的因果链的注意力

1. Aspire 将这种固定的反馈通道转化为一个开放式的调试环境。机器人执行引擎为感知、规划和控制调用记录逐原语的多模态轨迹，将这些轨迹暴露给编码智能体，并执行由智能体编写的修复代码以进行闭环验证
2. 对于每一次原语调用，轨迹都会存储被调用的 API、输入与输出、返回状态，以及相关的多模态证据，例如 RGB 关键帧、叠加层、抓取候选、物体位姿和运动规划结果
   
   智能体不会接收到完整的视频帧；执行引擎仅保留每次原语调用前后紧邻的帧，以及相应的叠加信息和返回值，从而使智能体能够专注于围绕被判定为导致失败的调用附近的证据

图 2 放大展示了一个 BEHAVIOR-1K 中的“navigate-and-pick-up-radio 调试”片段。自视角关键帧显示，机器人先找到收音机，多次尝试靠近都失败，随后在改变接近方向后才成功。原语轨迹将失败定位如下：感知模块工作正常并返回了收音机的位姿，但多次调用navigate_to_pose 都返回 PLANNING_ERROR

1. 通过检查导航返回值及相关日志，智能体发现生成的导航目标点距离桌子边界过近，大约在距离桌缘 20 厘米以内。这会触发避碰机制并导致规划器失败。因此，这次失败并不是因为检测或抓取收音机出了问题，而是由于在桌子碰撞约束下，该目标位姿本身不可行
2. 修复过程直接基于这一诊断结果展开。代理并未修改感知提示词或抓取基元，而是编写了一个多角度接近（multi-angle approach）的例程，该例程会在收音机周围采样多个备选导航目标，并执行一种能够清除碰撞缓冲区的接近方向
   
   执行引擎对外暴露证据、验证打过补丁的程序，并使代理能够分析由此产生的日志、形成假设，并做出有针对性的修复决策

1.2.2 技能库

程序故障会在不同任务间反复出现，但可复用的知识很少是完整的一段任务程序。Aspire的技能库存储的是异构的修复知识：定位启发式方法、感知提示、抓取约束、导航恢复策略、运动基元、场景理解例程以及调试工作流

作者并不预先规定这一分类体系。技能是从已验证的修复中归纳出来的：编码代理根据执行轨迹诊断故障、对程序打补丁、在调试配置上验证修复效果，随后协调器仅将具有复用价值的模式纳入共享库中

每个技能都以紧凑的“上下文内指导”（in-context guidance）形式存储，其中包含失败特征签名、适用时机条件、修复策略，以及在有帮助时附带一个具有代表性的代码示意

• 图 3 展示了具有代表性的条目以及由此产生的技能库广度

  

• 对于图 2 中的收音机任务，被接纳的技能是一个导航恢复模式，而不是一个完整的“拾取收音机”程序：当规划器在障碍物边界附近反复出错，是因为采样到的目标位姿落在碰撞缓冲区内时，应在重新尝试感知与抓取之前，先在物体周围采样替代的接近方向
  这样的表示方式使后续的智能体可以复用已经验证过的修复方案，而不必在测试时推理中重新发明；它支持对更难的仿真任务进行零样本迁移，并为将部分在仿真中发现的技能跨不同机体进行泛化、并迁移到真实机器人上提供了机制

执行体会报告结构化的发现结果，其中总结了故障模式、经验证的修复方案，以及具有潜在可迁移性的修复模式。协调器对这些发现进行审查，核查其是否符合允许使用的 API策略，并且只将通过调试验证的、可复用的修复方案提升到共享技能库中。附录 E.1 给出了用于执行体报告和协调器引导技能准入的提示词

1.2.3 进化式搜索

仅依靠基于轨迹的调试，可能会陷入局部修补循环：智能体反复修补同一种失败的策略，而不是探索从根本上不同的任务求解方式。Aspire 采用进化式搜索来拓展对可执行机器人程序的探索空间，从而鼓励形成多样化的修复假设和任务策略

1. 在每一轮中，基于技能库，编码代理会在上一轮表现最好的程序以及先前评估中产生的失败轨迹的条件下，生成一个规模为 K 的候选程序种群。每个候选程序都会在机器人执行引擎中运行，产生任务结果以及新的诊断轨迹
   
   随后一轮则以上一轮中表现最好的程序及其剩余的失败模式为条件，从而使搜索能够探索不同的策略，而不是反复打磨同一个解决方案
2. 搜索的目标是机器人程序本身
   候选解通过闭环执行进行筛选，在搜索结束后，如果验证通过的修复能够在不同环境变化和任务中实现泛化，则被纳入技能库。当某个候选解成功解决调试配置，或搜索预算耗尽时，搜索终止

算法 1 概括了这一进化搜索过程。有关流程细节，参见附录 E.4

1.3 实验

1.3.1 实验设置

1. 在所有仿真基准测试中，作者使用 Claude Code [Anthropic, 2025] 搭配 Claude Opus 4.6 和 100 万token 的上下文窗口作为编码代理。该代理在 CaP-X [Fu et al., 2026] 中编写可执行的 Python 机器人程序
   
   CaP-X 是一个开源的 code-as-policy 框架，构建在 MuJoCo Playground [Zakka et al.,2025] 之上，提供用于感知、几何建模和运动规划的机器人编程 API。代理、本体环境以及 API 集在所有实验中都是固定不变的
2. 对于真实机器人技能迁移研究（§3.6），作者在一套双臂 YAM 操作工作站上使用 OpenAICodex GPT-5.5 的 reasoning-xhigh 模式
   
   作者从基于 Franka 的仿真环境中选择由 Aspire编译的三项技能：易拉罐抓取、碗放置到盘子上，以及抽屉推/拉。且将这些技能作为上下文示例提供给真实机器人代码代理。在真实机器人环境中，具身形式和 API 与仿真不同，但会公开 Aspire 的多模态执行轨迹，因此代理可以在调试循环中无需任务特定的人类指导，自主运行、检查和调试程序
   
   作者对比有无相应仿真中发现的技能两种设置下的运行表现，并测量达到首次成功所需的 token 数以及在保留任务上的真实机器人成功率

// 待更