作者：Lei阅读 --

ASPIRE 深读：NVIDIA 教机器人的那套技能库，交付物是一个 CLAUDE.md

NVIDIA GEAR 的 ASPIRE 用 Claude Code 写机器人程序，把调试经验攒成技能库，长程任务零样本从 4% 提到 31%。但论文标题盖住了它自己的消融结论：拿走技能库不是最痛的，拿走执行轨迹才是（14%→62%）。这篇顺着「技能该存成什么」这条线，把 Voyager 到 ASPIRE 的表示切换拆开，并拿我自己的两个知识库跑了一遍论文的 Limitation 4——我的一条 skill 确实过期了。

AIAgentAgent 工程论文深读Skills记忆

原文：ASPIRE: Agentic /Skills Discovery for Robotics，arXiv:2607.00272v1，2026-06-30 提交，CC BY 4.0。作者 14 人，NVIDIA GEAR / CMU / UC Berkeley / UMich / UIUC，项目页 research.nvidia.com/labs/gear/aspire。下文所有数字读自 arXiv 全文（含附录），不是二手转述；凡属我自己的推断都在句内标了。

我是冲着机器人去读这篇的，读到第 3.1 节愣了一下：他们的 coding agent 就是 Claude Code（Claude Opus 4.6，1M 上下文），真机那组换成 Codex GPT-5.5 reasoning-xhigh。再翻到附录 E.2，直接贴出了他们的 CLAUDE.md 全文、.claude/skills/<name>/SKILL.md 的目录约定、.claude/memory/MEMORY.md 的启动读取顺序，甚至有一条「NEVER git commit unless user explicitly asks」。

也就是说，这篇 NVIDIA 的机器人论文，交付物形态跟我每天在这个博客仓库里维护的东西是同一个：一堆带 frontmatter 的 Markdown 技能文件。区别只是他们给它接了 LIBERO-Pro 和 BEHAVIOR-1K 的评测，跑出了带误差的数字。

所以这篇论文对我的真实价值，不是「机器人怎么学技能」，而是「我那套 skill 目录到底有没有用，有用在哪一段」——它是一次带对照组的实验。

名词速查

术语一句话解释
code-as-policy不让模型直接吐关节角度，而是让它写一段调用感知/规划/控制 API 的 Python，程序本身就是策略。站内谱系见推理转 Program 那篇
VLA（视觉-语言-动作模型）端到端模型：图像+指令进，动作直接出，中间没有可读的程序
技能库（skill library）把「以前踩过的坑怎么修」攒成可检索的条目，下次当提示词塞回去
执行轨迹（trace）每次调用 API 都记下入参、返回值、状态码和前后关键帧，失败时用来定位是哪一环坏的
LIBERO-Pro / BEHAVIOR-1K两个机器人基准：前者专测「把物体挪个位置、把指令换个说法」后还能不能做对，后者是长程家务
本体（embodiment）机器人的物理形态。换本体 = 换了机械臂型号、自由度、API，代码基本不通用
零样本迁移不再调试、不再更新库，直接拿去做没见过的任务
宏平均每个任务先各自算成功率，再对任务取平均（不按样本数加权）

一、原文在争什么

ASPIRE 反对的默认观点是：机器人的通用能力要靠端到端 VLA 把动作压进权重里。

它的主张是另一条：让 coding agent 写程序、看轨迹、自己修、把修好的经验攒成库。三个部件——执行引擎（吐细粒度轨迹）、技能库（存验证过的修复）、演化搜索（跳出局部修补）。

数字（均为论文报告值，我未复现）：LIBERO-Pro 宏平均总分 ASPIRE 0.72 对 CaP-Agent0 0.18，4 倍；Robosuite 双臂交接 20% → 92%；BEHAVIOR-1K 的 navigate-and-pick-up-radio 56% → 88%。最扎眼的是零样本那组：用 LIBERO-90 上攒的库去做没见过的长程任务，31% 对 4%，而基线还开着测试时推理和重试。

顺手纠一个容易被转述带偏的地方：摘要里的「up to 77%」是百分点不是相对提升。我按附录 B 的 Table 2 核过——libero-object 上 ASPIRE 的 Pos/Task 是 0.98/0.95，CaP-Agent0 是 0.22/0.18，两轴平均差 76.5 个点，Task 轴正好 77.0。写成「提升了 77%」就低估了。

至于 VLA 基线有多惨：OpenVLA 在全部六列上都是 0.00。另外两条 π 系列基线里有一条同样全 0，另一条总分 0.13。（行名到模型名的对应是我的推断：arXiv HTML 把 π₀ / π₀.₅ 的数学符号渲染丢了，我是按 §3.2 的引文顺序对回去的。）需要说清的是，这是 LIBERO-Pro 扰动套件，专门设计来打 VLA 的鲁棒性软肋，不是原版 LIBERO 上的常规分数——拿它说「VLA 不行」会过度外推。

二、第一性原理：这是一次表示的切换，不是一个新循环

用顶级原理望远镜里的第 ② 条「表示决定成败」去看，这篇的位置立刻清楚了。

共同祖先是 Voyager（2023，Minecraft 里让 LLM 把学会的动作存成可执行 JS 函数，站内谱系在那条四年时间线的 2023 格）。这不是我的联想——ASPIRE 的相关工作里第一个点名的就是 Wang et al. 2023，而我查了作者表：Voyager 的第一作者 Guanzhi Wang，正是 ASPIRE 的末位作者兼项目 lead。 同一个人，隔了三年，把同一件事的存储格式换了。

换成了什么？Voyager 存可执行函数；ASPIRE 存的是四元组——失败签名、何时适用的守卫（when-to-apply）、修复策略、以及「有用的时候」才附一段代码草图。附录 A 把这四项写得很明白。

那条 radio 任务的例子最能说明差别。机器人反复 navigate_to_pose 返回 PLANNING_ERROR，agent 从轨迹里查出根因：导航目标落在桌沿 20 厘米内，撞上了避障缓冲区。修复是写一个多角度接近例程。但入库的不是「捡收音机的程序」，而是「当规划器在障碍物边界附近反复报错时，先绕着物体换几个接近方向再重试感知和抓取」。

一句话根本约束（可反驳）

ASPIRE 的技能之所以必须长成「自然语言守卫 + 代码草图」而不是 Voyager 那样的可执行函数，是因为它要跨的边界不是任务，而是本体和 API。

这句话可反驳，反例条件也很清楚：如果本体和 API 锁死，技能就应该退回可执行函数——能直接调用的东西永远比要重新翻译一遍的提示词更可靠。Voyager 在 Minecraft 里就是这个情况，所以它存函数是对的。

论文自己把这个约束顶到了极限：仿真那组是 Franka 单臂 + CaP-X 的 API + Claude Opus 4.6；真机那组是双臂 YAM + 完全另一套 API + Codex GPT-5.5。跨本体、跨 API、还跨模型厂商。 一段 Python 函数活不过这三重边界里的任何一重，一句「规划器在障碍边界反复失败时换接近方向」三重都能活。

反事实崩点

把技能库换成最朴素的做法——存成功的完整程序（解法库而非诊断库）——先在哪崩？

不用推测，论文的基线就是这个：CaP-Agent0 带着预置技能库、每个种子重新生成程序、还开着测试时重试。它在 LIBERO-Pro 扰动下拿 0.18，ASPIRE 0.72，4 倍；到了零样本长程，4% 对 31%，接近 8 倍。崩点位置很具体：物体一挪位、指令一换说法，存下来的解法就失效，因为它编码的是「这一次怎么成的」，不是「这类失败为什么会发生」。

三、标题盖住了论文自己的消融结论

这是我读完最想说的一条，也是我认为大多数转述会漏掉的：

论文叫「Agentic /Skills Discovery」，重心全在技能库。但 §3.7 的消融是这么排的——

拿掉什么LIBERO-Pro 宏平均边际贡献
执行引擎、演化搜索都没有14%基线
加上执行引擎62%+48 点
再加上演化搜索72%+10 点

贡献最大的是执行引擎，也就是「把每个 API 调用的入参、返回值、状态码和前后关键帧都记下来」这件事。 不是技能库，是可观测性。

这两件事在文章里被同一个叙事包住，其实干的是两份工：

  • 执行引擎解决的是「这一次怎么修」——单任务内的一阶项，+48 点。
  • 技能库解决的是「下一次不用重新发现」——跨任务的复利项，体现在 4% → 31% 那组，而它根本没进上面那张消融表。

我觉得这个区分对做 agent 系统的人比论文本身的机器人结论更有用：如果你的 agent 还看不清自己为什么失败，先别急着建技能库。 库里攒的是诊断，诊断的原料是轨迹；原料不够，攒出来的只会是一堆「多试几次」级别的废话条目。顺序反了，复利无从谈起。

四、把 token 账算一遍：99.5% 花在重读，不在写

论文 Table 1 给了真机迁移的 token 数。我把输出占比和倍数算了一遍（纯算术，脚本验算过）：

任务输出/总量（无技能）总 token 倍数成功率
碗放盘子0.58%1.69×20/20 → 20/20
拎汽水罐0.29%9.41×13/20 → 19/20
开抽屉0.40%4.10×0/20 → 11/20

三个任务合计 405.5M → 93.4M，整体 4.34 倍。

但真正让我停下来的是第二列：输出 token 只占总量的 0.3%–0.6%。 也就是说，agent 自主调试的成本里，99.5% 以上不是「写代码」，而是反复把轨迹、日志、关键帧读进上下文。

这把「技能库省钱」重新解释了一遍——它省的不是生成，是重新推导。一条 200 字的守卫，顶掉的是几千万 token 的重新看图、重新试错。开抽屉那行尤其说明问题：没有技能时烧掉 334.9M token，最后 0/20，一次都没成。那不是效率问题，是它根本没走到正确的假设上。

五、拿我自己的两个知识库对一遍

看完 ASPIRE 的技能格式，我回头翻了这个博客仓库，发现一件之前没意识到的事：我其实有两个知识库，而且分工恰好踩在论文那条线上。

存储数量体量内容形态对应 ASPIRE 的什么
.claude/skills/2 个3279 词流程说明书（怎么发博客、怎么追踪研究者）初始技能模板（附录 E.5 那种）
项目级 memory 目录8 条1950 词失败签名 + Why + How to apply验证过的修复（附录 A 那种）

数字是刚点的（wc -w）。让我意外的是第二行的格式——我照着 memory 的写法要求攒了几个月，结构跟 ASPIRE 附录 A 的四元组几乎逐项对上：

  • description 那行 ≈ 失败签名（「pnpm validate:blog 在旧文标签上退出 1」）
  • How to apply ≈ when-to-apply 守卫
  • Why ≈ 从轨迹里读出的根因
  • frontmatter 里的 originSessionId ≈ 论文说的 origin task

连 [[双链]] 都对得上论文里「技能之间互相引用」的用法。两边没有任何抄袭关系，是同一个约束逼出了同一个形状：要让一条经验在别的任务里还能用，你就只能存诊断，不能存解法。

反过来，这张表也暴露了我的问题：我真正有复利价值的那 8 条，全是 agent 在会话里自动攒的；我手写的 2 个 skill 反而是纯流程文档，属于论文说的「初始模板」那一档——它们不会自己长大。

六、跑一遍论文的 Limitation 4：我的技能确实过期了

论文第 5 节第四条限制，原话大意是：技能库会变陈旧、过度特化、冗余或误导，需要检索、剪枝、排序和重新验证机制，而 ASPIRE 现在没有。

我库里恰好有一条自带自检提示的 memory（写于 2026-08-31），说 pnpm validate:blog 会因为一批旧的 codex-ai-digest 文章而退出 1，约 26 条 error，全部来自 codex-ai-digest-*.md，并叮嘱「用之前先确认它还成立」。

那就确认一下。今天（2026-09-22）我真跑了一遍：

pnpm validate:blog 2>&1 | grep -E "^src/content/blog" > out.txt
grep -v " warning " out.txt | wc -l          # 32
grep -v " warning " out.txt | grep -c codex-ai-digest   # 30
grep -v " warning " out.txt | grep -v codex-ai-digest   # 2 条

结果：32 条 error，30 条来自 digest，还有 2 条不是——

src/content/blog/delivery-gate-vs-eval-system-2026-09-04.md  unknown-tag "门禁"
src/content/blog/delivery-gate-vs-eval-system-2026-09-04.md  singleton-tag "门禁"

这条 memory 的守卫仍然有效（「只 grep 你自己的 slug」这个动作没错），但它的失败签名已经漂了：从「26 条，全在 digest」变成「32 条，其中 2 条来自一篇它写成时还不存在的文章」。三周，一条新文章，就让一条技能的诊断部分失准。

我承认这次是撞上的，不是设计好的验证：本来只是想按发布流程跑一下校验，顺手对了眼旧 memory 才发现数字不对。但撞上得正是时候——这就是 Limitation 4 的活样本，而且它告诉我一件论文没说的事：漂移的不是守卫，是签名。 守卫写的是「怎么做」，只要环境的因果没变就一直对；签名写的是「现在长什么样」，它是对世界的一次快照，注定过期。

如果让我给 ASPIRE 的技能格式提一条修改，就是这个：四元组里的失败签名应该带时间戳和重验成本，守卫不用。 我这条 memory 靠人手写了一句「用之前先确认」勉强兜住，ASPIRE 的自动库连这一句都没有——库越长越大，越可能拿三个月前的世界指导今天的任务。

七、我的判断

可信的：技能库的跨任务复利（4% → 31%，且论文 Figure 5b 显示成功率随库规模单调上升）和消融里执行引擎的 +48 点。这两组都有 held-out（留出）种子、有分轴拆解，口径写得清楚。

需要打折的：真机那部分只有 3 个技能、3 个任务，论文自己用的词是 “initial evidence”，我认同这个措辞。开抽屉那行 0/20 → 11/20 很漂亮，但 n=1 个任务，换个抽屉是什么结果没人知道。

立场偏差要说破：NVIDIA 自己卖 GR00T N1——一个 VLA 基座模型。而这篇论文 Figure 4 里被打到 0.00 的，正是 VLA 路线。同期 Jim Fan 在 X 上公开说主流 VLA 路线「feels wrong」（二手，来自搜索摘要，我没拿到原帖）。

有意思的是，这个偏差的方向是对论文可信度有利的：一个实验室发论文证明自己旗舰产品线的路线在某类任务上不行，这种「不方便的结果」通常比自我吹捧的结果更值得信。要提防的反而是反向过读——别把「VLA 在对抗性扰动套件上崩了」读成「VLA 路线错了」，这篇论文支撑不起那么大的结论。

最有说服力的一处，论文没有强调：技能是 Claude Opus 4.6 在仿真里发现的，消费它的是真机上的 Codex GPT-5.5。Limitation 2 承认整套依赖冻结的前沿模型，这让人怀疑技能库是不是只是在给上下文窗口打补丁。但跨厂商这一跳恰好排除了这个解释——上下文大小解释不了「A 模型写的笔记能让 B 模型少烧 9 倍 token」。这说明那些 Markdown 文件是独立于模型的真实资产，不是某个模型的私有缓存。这一点对我的意义比机器人大得多：它意味着我写的 skill 文件，理论上换个 agent 也还能用。

八、下一步我要动的地方

论文给我的最直接的改法只有一条，而且成本很低：把我那 2 个手写 skill 从「流程说明书」改造成「带失败签名的诊断库」。

具体到这个仓库：publish-blog 的 SKILL.md 现在是线性流程（写→校验→构建→推送），而真正值钱的知识——validator 会在旧文上假性失败、mermaid 构建通过也可能渲染错位、两份 skill 副本会静默分叉——全都散在 memory 里，靠 agent 每次会话自己捞。按 ASPIRE 的做法，这些应该作为「失败签名 + 守卫」条目正式进 skill 文件，并且给签名加上最后验证日期。

至于要不要学 ASPIRE 把这个过程自动化（让 agent 自己往 skill 里写条目）——我暂时不做。原因就是第六节那件事：我这条 8 月底的 memory 三周就漂了，而自动库没有剪枝和重验机制。 自动化一个会自己长、不会自己收的库，长出来的是负债不是资产。先把重验这一环用人手跑通，再谈自动。

小结

  • 根本约束：ASPIRE 的技能存成「自然语言守卫 + 代码草图」而非可执行函数，是因为它要跨的是本体、API 和模型厂商三重边界——代码过不去，诊断过得去。本体锁死时，这个结论反转。
  • 崩点：改存完整解法（论文基线 CaP-Agent0），扰动下 0.18 对 0.72（4 倍），零样本长程 4% 对 31%（近 8 倍）。
  • 被标题盖住的一阶项：消融里执行引擎贡献 +48 点（14%→62%），技能库的价值在跨任务复利、不在单任务。看不清失败原因之前，别急着建库。
  • 可带走的动作：技能条目里，守卫长期有效，失败签名会过期——给签名加验证日期，给库加重验流程。

常见误读 → 实际情况

容易读成实际是什么
「技能库是 ASPIRE 提升的主因」消融里执行引擎 +48 点、演化搜索 +10 点；技能库压根不在那张表里，它的贡献在零样本那组（4%→31%）
「比基线高 77%」是 77 个百分点（0.95 对 0.18）。按 Table 2 核过，写成百分比会低估
「论文证明 VLA 路线不行」只证明了 VLA 在 LIBERO-Pro 这个专打鲁棒性的扰动套件上崩了。原版基准上的表现不在本文范围
「技能库 = 把成功的代码存起来复用」恰恰相反。存代码的是 Voyager；ASPIRE 存的是失败诊断，代码草图只是可选附件
「sim-to-real 已经打通」论文自己写的是 “initial evidence”：3 个技能、3 个任务，且真机仍需重新调试
「技能库建好就一直有效」Limitation 4 明说会陈旧。我库里一条三周前的条目，失败签名已经对不上了
「这是机器人领域的事」他们的 coding agent 是 Claude Code，交付物是 CLAUDE.md + .claude/skills/*/SKILL.md。换个词就是你我的 agent 配置

参考来源

论文

工程实践 / 站内