英伟达开源ASPIRE:机器人自己攒Skill
一份把「机器人怎么从试错里长出经验」讲明白的技术解读
目录
- 导语
- [一、先说清楚:ASPIRE 不是又一个 VLA 模型](#一、先说清楚:ASPIRE 不是又一个 VLA 模型)
- [二、它到底怎么让机器人"自己攒 Skill"](#二、它到底怎么让机器人"自己攒 Skill")
- 三、光说不练:基准与模型缩放进阶
- [四、真机跨本体迁移:从仿真到双臂真机的 token 账](#四、真机跨本体迁移:从仿真到双臂真机的 token 账)
- 五、现在就试:两条上手路径
- 六、冷静视角:标题里哪些话要打折
- 总结
2026年10月16日,英伟达 GEAR 实验室在 GitHub 开源了 ASPIRE V1.0(Apache 2.0),全称 Agentic Skill Programming through Iterative Robot Exploration。它想解决的不是「再训一个更大的具身模型」,而是一个更朴素也更难的问题:机器人能不能像人一样,在反复试错里把「踩过的坑」攒成可复用的经验,下次遇到类似情况直接调用,而不是每次都从零开始?对做具身智能、机器人模仿学习、Agent 落地的开发者来说,这件事的意义不在刷分,而在它把「经验积累」这件事工程化了。这件事对三类人影响不同:做机器人本体的关心它能不能少训模型、做 Agent 框架的关心「代码循环加记忆体」能不能搬到软件 Agent、做研究的关心它是否打开了「机器人自我改进」的新范式。
一、先说清楚:ASPIRE 不是又一个 VLA 模型
很多人看到「英伟达」「机器人」「开源」三个词摆在一起,下意识会当成又一个视觉-语言-动作(VLA)模型。ASPIRE 走的是另一条路,它把自己归到 code-as-policy 范式下:让大语言模型直接写出控制机器人的 Python 代码,而不是去拟合一个把图像和语言映射到动作的神经网络。
这里有个容易混的点要先掰开。强化学习那条老路(以 OpenAI 2019 年的 Dactyl 单手转魔方为代表)是为每个任务从头训一个策略,靠海量仿真加真机对齐,周期以年计,换任务基本要重训。VLA 路线把像素和语言端到端映射到动作,数据驱动但长尾失败很难定位和解释,改一处行为往往要重新收集与训练。ASPIRE 的做法是:代码本身就是策略,LLM 写一段 Python 控制程序,机器人去执行,系统把执行过程录成多模态轨迹,模型看着轨迹改 bug,改到能跑通,就把这次修复存进技能库。
所以准确的说法是:ASPIRE 选的不是「更大的模型」,而是「可累积的写法」。控制逻辑写成代码而非权重,意味着每次失败的修复都能沉淀成可检索、可复用的技能,而不是随训练结束一起被丢弃。这也是它和 Dactyl 那种强化学习路线最本质的分手点------一个在攒经验,一个在训权重。
为什么这件事比「又多一个模型」更值得写?因为代码即策略给了 VLA 给不了的两样东西:可解释、可调试。VLA 犯错了,你往往只能看到动作不对,却很难定位是哪一个视觉特征或哪一段语言理解出了偏差;ASPIRE 犯错了,你看到的是一段 Python------哪一行抛了异常、哪个抓取点算错了,都能直接读。对要在真机上排错的人,这种「错误是可读的」比「成功率高一两个点」实用得多。
把时间线拉长是另一个视角。机器人学习大概走过三代:第一代是 Dactyl 那种强化学习,为单任务训一个策略,贵但可以端到端;第二代是 VLA,把感知和动作压进一个大模型,泛化好但黑箱;第三代就是 ASPIRE 代表的 code-as-policy,把策略交还给可读、可改、可积累的代码。ASPIRE 不是说前两条路错了,而是把「经验怎么留下来」这个被前两代忽略的问题,第一次当成了系统的核心。
一个具体的画面有助于理解:机器人第一次抓苏打罐,因为抓取点算偏了掉了,闭环执行引擎记下「抓取点偏移加掉落」这个失败签名,技能库存入「先贴近再夹取」的修复草图;第二次遇到相似抓取,检索命中,直接套用,省掉一轮搜索。所谓 Skill,在这套系统里就是这样一个「失败签名到修复」的映射,而不是某个被训练出来的参数。换句话说,ASPIRE 把机器人的「脑子」从一块不可读的权重,换成了一本能翻看的笔记------这笔记平时你不会觉得多厉害,但当你第三次遇到同一个坑,它省下的时间就显出来了。

(图一:机器人学习的三种路线,ASPIRE 属于「代码即策略」这一类,核心差异在知识怎么积累)
二、它到底怎么让机器人"自己攒 Skill"
ASPIRE 把「试错攒经验」拆成了三层协同的闭环,缺一层都转不起来。
最底下是闭环执行引擎。它真正把 LLM 写出的代码跑起来,并采集细粒度的多模态轨迹:不仅记录画面,还记录抓取点、运动路径和碰撞反馈。这些反馈是下一轮修正的原材料------没有它,模型就只是在「想象」自己写对了。
中间一层是技能库。它存的是异构的修复知识,每一条修复都带着失败签名、适用条件、修复策略和代码草图四件套。只有验证通过的修复才允许入库,这保证了库里的东西是可信任、可检索的,而不是一团没整理过的报错日志。
最上面一层是进化搜索。它每轮同时生成 K 个候选程序,横向比较而不是在一个程序上单点修补。这一步专门用来跳出「改一处又错一处」的局部修补死循环------单点修 bug 很容易在 A 处修好、B 处又炸,进化搜索用多候选并行把这种循环摊开来看。
ASPIRE 采用的是 Coordinator-Actor 架构:协调者负责拆任务和调度搜索,执行者负责跑代码和采轨迹。三者合起来,一次典型的循环就是:写代码 → 执行 → 看轨迹找问题 → 改 bug → 验证 → 入库。
技能库不是简单的错误日志堆。它用「失败签名」做索引------把每次失败的观测压缩成一个可匹配的特征,下次遇到相似失败时先查库,命中就直接套用历史修复,不必再走完整搜索。这和人类「上次摔过跟头,这次绕开」是同一个机制,也是它跨任务复用经验的真正落点。那它和单纯把报错贴进 prompt 有什么不同?区别在于签名检索是结构化的、可去重的,库越大复用越便宜,而不是越长越乱。进化搜索的 K 个候选也不是随便生成,它们往往从一个通过了的修复做轻微变异,再用轨迹回放筛掉仍然失败的,留下真正进步的。

(图二:ASPIRE 的三层结构,闭环执行引擎打底、技能库居中、进化搜索在顶,知识沉淀在技能库而非权重里)
三、光说不练:基准与模型缩放进阶
光讲机制没用,得看它到底能不能把任务做对。据 NVIDIA GEAR 公布的官方数据,在几个具身基准上 ASPIRE 的表现是:LIBERO-Pro 80 项任务成功率约 99%、Robosuite 7 项约 100%、BEHAVIOR-1K 2 项约 100%。从数字看,跨三大基准基本落在 97% 到 100% 的区间。
但这里有个必须点破的地方。流传的说法把「一夜刷爆所有基准」直接挂在 GPT-6 Astra 头上,这个判断需要打折:跨基准那一档 97%--100% 的实测,主要由 Claude Opus 5.5 驱动完成;GPT-6 家族里被测试的 Luna 版本,在 10 项 LIBERO-Pro 任务上成功率只有 15%,而换成 Claude Opus 5.5 则跳到 99%。GPT-6 Astra 真正出场的,是真实魔方等少数演示性场景,不是那张基准成绩单的主角。
为了不把推断包装成事实,我把这次开源的事实、推断和未知分开摆清楚:
- 已证实(来自 NVIDIA 官方 README 与论文 arXiv:2607.00272):开源日期、Apache 2.0 协议、三大组件的存在、上面那组基准数字,以及模型缩放里 Luna 15% 对 Opus 5.5 99% 的对比。
- 作者的推断:ASPIRE 真正的价值不在单次成功率,而在「技能库让经验可跨任务复用」这一点------它把具身学习的瓶颈从「训模型」挪到了「管知识」。
- 目前未知:技能库在长期运行后会不会膨胀到难以检索、跨本体的修复经验能泛化到多大范围、真实工厂环境里的噪声会不会让闭环执行引擎频繁失效,这些官方都还没给出长期数据。
顺带看一组消融,能更清楚每个组件贡献了多少:在 LIBERO-Pro 上,仅用基线(无执行引擎、无进化搜索)成功率约 14%;加上闭环执行引擎升到约 62%;再加进化搜索升到约 72%。剩下那一段到 99% 的跃升,主要来自底层 LLM 本身的能力(也就是上面的模型缩放结论)。
这里有必要把数字放回语境:LIBERO-Pro 测的是「在已知结构化场景里完成长程操作」的能力,99% 说明闭环在这类任务上已经相当稳;但 BEHAVIOR-1K 只报了 2 项就写 100%,样本太少,不足以得出「它已经通吃家庭任务」的结论。把 99% 直接等同于「什么都能做」,是另一种常见的过度解读,和把成绩记在 GPT-6 头上是同一类错误------都是拿一个好看的数字,盖住它真实的能力边界。

(图三:同一组 10 项 LIBERO-Pro 任务,只替换驱动 ASPIRE 的底层模型,成功率从 15% 跳到 99%)
四、真机跨本体迁移:从仿真到双臂真机的 token 账
基准跑分之外,更值得工程人员关心的是它能不能从仿真搬到真机,以及这个过程要烧多少推理算力。NVIDIA GEAR 给了一组跨本体迁移的数字:把在 Franka 仿真里练出来的技能,迁移到 YAM 双臂真机上,三类任务的推理 token 消耗和成功率都出现了明显变化。
| 任务 | 来源本体 | 目标本体 | 推理 token 消耗(万) | 降幅 | 成功率 |
|---|---|---|---|---|---|
| 苏打罐抓取 | Franka 仿真 | YAM 双臂真机 | 6194 → 658 | -90% | 同步提升 |
| 抽屉开关 | Franka 仿真 | YAM 双臂真机 | 33491 → 8167 | -76% | 同步提升 |
| 碗抓取放置 | Franka 仿真 | YAM 双臂真机 | 865 → 511 | -41% | 同步提升 |
这张表最反直觉的地方在于:迁移到真机后,推理 token 不是变多,而是大幅变少。原因大概率是技能库里已经攒下了可复用的修复经验,真机遇到的情况更多走「查库调用」而非「从头搜索」,于是搜索循环的次数被压了下来。苏打罐这一类降幅接近九成,说明高频、结构化的抓取任务最受益于这种经验复用;碗这类降幅只有四成,可能因为它的姿态变化更连续、可复用签名更稀疏。
需要提醒的是,这组数字来自官方公布的迁移示例,任务样本量不大,能不能在更多本体、更多任务上稳定复现,仍要打一个问号。但它至少说明了一件事:code-as-policy 的经验复用,在跨本体场景下是真实减了算力的,不只是成功率好看。
跨本体迁移之所以是具身领域的硬骨头,是因为仿真里练出的策略常常死死绑定某一款机器人的关节数和动力学参数,换一台机器往往要从头再来。ASPIRE 能搬到 YAM 双臂真机,说明技能库存的不是「某台机器的动作」,而是「与本体无关的修复经验」------这恰恰是它比单纯在单机上刷分更有想象力的地方。如果这条路能跑通,未来给新机器人接入技能库,可能比重新训练一个策略便宜得多。
五、现在就试:两条上手路径
ASPIRE 是开源仓库,不是候补制服务,所以上手路径比很多「等邀请」的项目直接。下面两条,一条走官方仓库,一条现在就能在本地把循环跑起来。
路径 A(官方仓库):克隆 NVlabs/ASPIRE,按 README 装好依赖,用 Codex 或 Claude Code 打开仓库里的 iterative-debugging 技能,直接跑 LIBERO-Pro 的 Goal-Swap 示例。官方推荐的就是让编码型 Agent 当「写代码的人」,ASPIRE 当「跑代码、看轨迹、攒技能」的闭环。跑官方示例前先确认你有可用的 GPU 与 LIBERO 仿真环境------Goal-Swap 这类任务对仿真和渲染依赖较重,纯 CPU 笔记本大概率跑不动完整闭环,本地玩具版骨架(路径 B)反而更适合先建立直觉。
路径 B(现在就能跑的最小闭环):即便不想碰完整仿真环境,也可以先在本地用一个玩具版循环把 code-as-policy 的骨架跑通------下面这段 Python 不依赖机器人硬件,只演示「写代码 → 执行 → 看反馈 → 改 → 存」的核心结构:
python
# 一个不依赖真机的 code-as-policy 最小闭环骨架
# 目的:演示「写代码→执行→看反馈→修复→入库」的循环,而非真去控机器人
skill_library = [] # 技能库:存验证通过的修复(失败签名, 修复代码)
def write_control_code(task):
# 真实 ASPIRE 里这一步由 LLM 生成 Python 控制程序
return f"def solve_{task}(): pass"
def execute(code, env):
# 真实 ASPIRE 里由闭环执行引擎跑代码并采多模态轨迹
try:
exec(code, env)
return "ok", None
except Exception as e:
return "fail", str(e) # 异常即「失败签名」
def refine(code, feedback, llm):
# 进化搜索:每轮生成 K 个候选,这里简化为单步修复
return llm.fix(code, feedback)
for task in ["pick_can", "open_drawer"]:
code = write_control_code(task)
for _ in range(5): # 最多 5 轮自我修正
status, fb = execute(code, {})
if status == "ok":
skill_library.append((task, code)) # 验证通过 → 入库
break
code = refine(code, fb, llm=object())
print(f"已沉淀技能数:{len(skill_library)}")
把这段骨架接上真实的 LLM 调用和一个能返回异常的环境,你就拥有了一个 ASPIRE 式的迷你闭环。它最大的提醒是:所谓「机器人自己攒 Skill」,本质是给代码循环配上一个会记录失败、会复用修复的记忆体。
六、冷静视角:标题里哪些话要打折
作为一篇技术解读,我有几处想替读者按住不急着鼓掌的地方。
第一,标题里的「一夜刷爆所有基准」要打折。 跨基准 97%--100% 的实测主要由 Claude Opus 5.5 完成,GPT-6 Astra 只驱动了魔方等少数演示。把成绩记在 GPT-6 头上,是标题化的说法,不是工程结论。更关键的是,基准成绩依赖的具体是哪个模型版本、哪份 prompt,官方披露得并不完整,外部很难独立复跑那张 99% 的表。
第二,它高度依赖冻结的前沿 LLM。 官方列出的局限里明确写了依赖 Claude Opus 4.6 这类前沿模型,底层模型一换,成功率能从 15% 跳到 99%------这意味着 ASPIRE 的上限被「租来的大脑」卡着,自己并不生产智能。
第三,它受限于预定义的原语 API。 机器人能做的动作被锁在给定接口里,超出原语范围的灵巧操作,ASPIRE 目前没有能力自己扩展。它聪明,但聪明在「组合已知动作」,不是「发明新动作」。
第四,技能库的长期管理仍是悬而未决的问题。 官方也承认,修复经验怎么长期归档、怎么防止库膨胀到难以检索,还没有答案。短期攒技能很香,长期会不会变成一座谁都翻不动的图书馆,有待观察。
第五,它还不是完全自主的真机学习器。 官方自我定位里点明这不是一个能在真机上完全自主学习的系统,搜索循环也要消耗可观算力。加上一个安全层面的提醒:ASPIRE 生成的 Python 拥有完整 import 权限,必须在隔离环境里运行,千万别直接丢到生产主机上。
总结
ASPIRE 真正有意思的地方,不是它把某个基准刷到了 99%,而是它把「机器人怎么从试错里长出经验」这件事工程化了:控制逻辑写成代码、失败修复存进技能库、用进化搜索避免陷入局部修补。对具身智能和 Agent 落地的开发者来说,这条 code-as-policy 的路线值得盯,因为它把瓶颈从「训一个更大的模型」挪到了「管好一份会成长的技能库」。但下手之前要把账算清------它的天花板由底层 LLM 决定,动作受原语 API 约束,长期知识管理还没解,真机自主程度也有限。我的建议是:先把它当成一个「会自我修正的代码循环样本」去读源码、跑最小闭环,再判断它适不适合你手上的机器人任务。它真正的考题是:当技能库越来越大,检索和管理会不会反过来成为新的瓶颈?这要比「今天刷到了几分」更值得长期跟踪,而不是被「开源即万能」的叙事带着走。
API 约束,长期知识管理还没解,真机自主程度也有限。我的建议是:先把它当成一个「会自我修正的代码循环样本」去读源码、跑最小闭环,再判断它适不适合你手上的机器人任务。它真正的考题是:当技能库越来越大,检索和管理会不会反过来成为新的瓶颈?这要比「今天刷到了几分」更值得长期跟踪,而不是被「开源即万能」的叙事带着走。