Skip to main content

SkillRAE：把检索到的技能在线编译成执行器可用的紧凑上下文

Paper Info​

Overview​

  1. 核心问题：SkillRAE 关注 RAE（Retrieval-Augmented Execution）中被忽略的一步——技能检索之后，如何把相关技能、子单元证据和任务约束编译成执行器能直接使用的上下文。

  2. 背景问题：现有方法多聚焦技能路由、仓库检索或执行规划，但"选到一个相关技能"不等价于执行器看到了当前任务真正需要的步骤、文件约定和约束。

  3. 方法总览：SkillRAE 分为离线建图与在线检索编译两阶段。离线阶段构建技能社区、技能节点和子单元节点三层图；在线阶段先做技能检索，再做上下文编译。

  4. 图结构：技能社区负责粗粒度能力匹配，技能节点保留执行器能消费的程序单元，子单元节点暴露局部步骤、命令模式和使用约束。

  5. 检索机制：在线检索同时走自上而下的社区信号和自下而上的子单元证据，再结合技能描述相似度、名称匹配和社区加分做技能排序。

  6. 编译机制：编译器会从未选中的技能里"救出"少量相关子单元，把它们挂到已选技能上，再筛成任务特定的 guidance，最后组织成紧凑上下文包。

  7. 系列定位：相比 SkillX / Trace2Skill 关注技能如何生成、SKILLGRAPH 关注技能关系如何组织、SkillClaw 关注技能库如何更新，SkillRAE 补的是"检索到技能之后、执行器看到技能之前"这一步。

  8. 实验结果：在 SkillsBench 上 SkillRAE 达到 29.26% reward mean，高于人工 curated skills 的 26.20% 与 SkillRouter 的 22.04%；在 AgentSkillOS 上达到 84.59%。

  9. 消融结论：去掉 top-down retrieval 从 29.26% 降到 16.61%，去掉 context compilation 降到 22.59%，说明技能社区和上下文编译都不是"只是加一段提示词"。

  10. 局限边界：SkillRAE 依赖明确的 SKILL.md 过程性文本、文件约定和约束说明；它是 advisory compiler，不是 planner 或 controller，不能保证运行时失败恢复。

核心内容解读​

为什么"检索到技能"不等于"执行器能执行"​

RAE 流程通常拆成三步：先按任务检索技能，再把选中的技能交给执行器，最后让执行器完成任务。这类方法里有一个被低估的环节——检索结果以什么形态进入执行器。

一个技能常常服务一类任务，范围比当前任务更大。比如 citation management 类技能可能同时覆盖搜索论文、验证元数据、生成 BibTeX、检查引用格式四个子目标，当前任务也许只需要"DOI 到 BibTeX"的一段逻辑。把整份技能直接塞进上下文，关键信息会被无关内容稀释。

反过来，如果只抽其中一段子单元也不行——子单元脱离来源技能后会丢掉前置条件、文件约定和输出约束，执行器难以独立消费。

SkillRAE 的处理思路是：保留技能作为执行器认识的基本单元，同时把真正相关的局部证据显式标出来。技能是组织单位，子单元是检索单位，两者职责分离。

两阶段流水线：离线建图 + 在线检索编译​

离线阶段——从技能仓库里建一张多层技能图，结构上分三层：

  • 技能社区（Skill Community）：用高 IDF 子单元构造技能表示，embedding 后用 k-means 聚类而成，是粗粒度的能力分组。
  • 技能节点（Skill Node）：保留执行器能直接消费的原始 skill（如 SKILL.md），下游执行器看到的还是这个形态。
  • 子单元节点（Subunit Node）：从 skill 里用确定性抽取规则抓出过程性元素、引用和约束型语句，再做长度过滤、标准化和精确去重，是细粒度的证据单位。

这张图是离线一次性建好的，在线阶段直接消费。

在线阶段——先用这张图检索，再做上下文编译，最后把任务特定的上下文包交给下游执行器。两阶段严格分离：检索只关心"找出哪些技能"，编译只关心"怎么呈现这些技能"。

双向检索：自上而下的社区 + 自下而上的子单元​

在线检索同时走两个方向：

自上而下：先看任务和哪个技能社区匹配，匹配社区里的技能会得到加分。这是粗粒度的能力过滤，先把候选池缩小。

自下而上：先匹配任务和子单元文本，找到契合的局部证据后，把这些子单元的命中信息投射回来源技能。这是细粒度的证据召回来确认候选来源是否真的有可用片段。

两路信号汇合后，再结合技能描述相似度、名称匹配和社区加分做最终排序。检索输出不只是一组技能 id——它同时为每个选中技能导出高量子单元（HQ），并保留未选中但含相关子单元的候选记录（RQ）。这一步为后续"rescue"机制留好了入口。

编译阶段：从落选技能里救出关键子单元​

检索结果出来后，编译器面对一个非平凡的决策：整体分数不够高的技能，可能恰好有一条子单元和当前任务非常贴近。这类子单元如果被埋掉，关键证据就丢了。

SkillRAE 把这一步专门命名为 rescue：从落选技能里筛出少量任务相关、非冗余、对齐到某条已选技能、且不超预算的子单元，把它们附着到某个已选技能下面，而不是当作新的可执行技能插入列表。

挂回而不是新建的好处是执行面保持稳定——下游执行器仍然消费原来的技能集合，不会突然多出一个孤立片段；但这条技能旁边会多出一条任务相关提示，提醒执行器在使用该技能时关注某个局部步骤或约定。

最终留下来的就是 task-specific guidance：只保留具体、与任务对齐、与已有证据不重复、且能塞进上下文预算的附属子单元。

最终上下文包的组织结构​

论文给最终可选提示预算为 384 tokens，是个相当紧的预算。上下文包按任务优先组织：

  1. 任务请求和输出约束（先写明执行目标）
  2. 选中技能的列表（保留技能名和原有内容）
  3. 每个技能里的关键高量子单元
  4. 附着到这些技能上的补充提示

执行器看到的是已经整理好的工作材料，不用在几份技能文档里自己翻找重点。

SkillRAE 把自己定位为 advisory compiler——它改的是执行前看到的上下文，不改原 skill、不改 planner、也不改 executor。这个边界让它可以叠加到不同检索器和执行器上。

实验结果：SkillsBench 与 AgentSkillOS 双基准​

论文在两个公开基准上验证：

  • SkillsBench：87 个任务 / 207 个技能，用 deterministic verifier 算 reward。主执行器是 Codex CLI + GPT-5.2，还跑了 Gemini CLI + Gemini 3 Flash 两个设置。
  • AgentSkillOS：30 个任务 / 200 个技能，用归一化 score。

主执行器下的关键数字：

基准SkillRAEcurated skillsSkillRouter
SkillsBench29.26%26.20%22.04%
AgentSkillOS84.59%83.50%82.30%

值得注意的是：curated skills 已经是 benchmark 里人工指定的相关技能，SkillRAE 还能高出 3.06 个百分点。这说明选对技能只是第一步，同样的技能材料组织方式更适合执行器后，任务完成率也会变。

消融：技能社区和编译都是真贡献​

在 Codex 设置下的消融结果：

配置SkillsBench
完整 SkillRAE29.26%
去掉 bottom-up retrieval23.43%
去掉 top-down retrieval（技能社区）16.61%
去掉 context compilation22.59%

最大单项损失来自 top-down retrieval——也即技能社区这层粗力度匹配，掉了 12.65 个百分点。上下文编译本身贡献了 6.67 个百分点（29.26 → 22.59）。

论文还把轻量版编译接到外部检索器上：BGE 检索提升 2.27 点，LLM-based retrieval 提升 7.02 点。后者更明显，论文给出的解释是：LLM selector 选出的技能未必最干净，但编译层能把任务约束和已选技能重新组织成更可读的入口——他们称之为 compatible retrieval backbone 上的 context exposure 效果。不过完整版 SkillRAE 仍然依赖图里的子单元和附属关系，不是纯粹的提示词包装。

边界：何时不该用 SkillRAE​

第一，SkillRAE 依赖 SKILL.md 这类显式的过程性文本。如果关键依赖藏在黑盒工具里、未文档化的代码里或运行时状态里，子单元就抽不出来，编译层也无处发力。

第二，它只是 advisory compiler，不保证执行器一定用好上下文，也不负责运行时失败恢复。要拿到运行时层面的鲁棒性，还得配套传统的 retry、错误反馈和反思机制。

第三，评测范围有限——只在两个 benchmark 共 117 个任务上验证，技能社区用的是相对简单的 k-means，效果会受技能池质量和规模影响。384 tokens 的上下文预算遇到需要大量背景的任务可能偏紧，编译策略本身也需要调整。

系列定位：补上 RAE 里的一段空白​

把这篇论文放进 agent skills 的近期谱系里看，SKILL 的相关问题已经被分成几段：

  • 技能如何生成：SkillX / Trace2Skill 研究从轨迹和经验里蒸馏出 skill。
  • 技能关系如何组织：SKILLGRAPH 探索技能之间的关系图谱。
  • 技能库如何更新：SkillClaw 关注真实使用后技能库的增量更新和验证。

SkillRAE 补的是另一段空白：技能已经被检索到了，执行器真正看到的上下文该怎样编译。它和 Planning 方法（如 Hagen 等 planner）的关键区别在边界——planner 会改变执行过程（拆任务、排工具、调控制流），SkillRAE 改的是执行前看到的入口，不去碰 planner 也不去碰 executor，因此可以叠加在不同检索器和执行器之上。

落到工程实践，对正在搭技能库 + RAE 的团队而言，最该带走的判断是：别把"检索到了"当成"能执行了"。当技能库越来越大，系统要关心技能进入执行器之前的形态：哪些步骤该突出、哪些约束必须保留、哪些跨技能片段要挂回合适位置。SkillRAE 把这一步单独拿出来，并用实验说明它值得认真做。

Resources​

Last updated on by Kimi Gao