一次成功，如何变成可复用的 Agent 技能？

一、核心问题不是「能不能生成」，而是「能不能可靠复用」

论文里最能说明问题的是一正一反两个任务。它们告诉我们：把成功轨迹写进技能文件很容易，判断其中哪些经验值得长期保留才困难。

所以 MUSE 真正要解决的不是「让 LLM 再写一份 SKILL.md」，而是给经验增加三道约束：

• 创建时看见真实执行上下文：技能在 ReAct 运行中按需产生，而不是脱离工具状态事后编写。
• 登记前获得失败信号：测试、沙箱和源轨迹检查把「看起来合理」变成可验收、可修补的制品。
• 复用后继续积累证据：失败模式和输入陷阱回写到逐技能记忆，下一次调用不必重新踩坑。

二、已有工作已经有「技能」，但还没有完整闭环

下面三张卡片只回答一个问题：在 MUSE 之前，技能系统还缺哪一段？折叠态给出主线所需结论；想了解各系统的输入、处理和输出，再展开阅读。

起点 · Voyager TMLR 2024 展开 它证明「成功程序可以积累为技能」；但技能主要是描述加代码，还没有通用测试、逐技能经验和跨 Agent 迁移边界。

它解决什么：Agent 不只要完成眼前任务，还要自己决定下一步学什么，并把已经掌握的行为组合成更复杂能力。Voyager 因此把终身探索拆成自动课程、代码技能库和迭代提示三个部件。

它怎么做：Minecraft 状态进入 GPT-4 课程模块，产生与当前能力匹配的新任务；系统根据任务计划和环境反馈检索 top-5 相关技能，再让 GPT-4 生成 Mineflayer JavaScript。环境反馈、执行错误与 self-verification 共同驱动修订，成功程序由描述 embedding 索引后入库。

它留给 MUSE 的问题：Voyager 证明了「技能能积累」，但每个技能主要是描述加最终代码；没有逐技能经验文件、版本治理、统一测试、冲突合并或异构 Agent 迁移协议。

Voyager 原论文 ↗

Voyager 总架构：课程提出任务，代码在环境反馈中迭代，验证成功后进入技能库。

展开说明 ▸

• 左侧自动课程：根据物品栏、环境和探索进度提出略高于当前能力的新任务，并在任务完成后更新进度。
• 中央代码动作：LLM 不是逐步输出低层动作，而是生成可跨多步执行的 JavaScript 程序。
• 底部反馈：环境状态与解释器错误回流；self-verification 决定当前目标是否真正完成。
• 红色与绿色分支：失败沿红线继续改程序，成功沿绿线把新程序登记为技能。
• 右侧技能库：新任务检索旧程序并组合使用，让能力增长不必每次从头开始。

直接对照 · AutoSkill arXiv 2026 展开 它让技能从交互中持续添加、合并和版本化；但创建发生在回合后的后台，看不到完整工具执行，也没有测试门禁。

它解决什么：传统记忆常保存事实和对话片段，却没有把反复出现的偏好、约束和工作流变成可执行行为。AutoSkill 将这些经验外化为可检查、版本化的 SKILL.md。

它怎么做：在线回路先重写查询，通过 embedding 与 BM25 混合检索技能，再把命中技能注入回答；异步回路从近期用户查询抽取持久约束，与 SkillBank 近邻比较后由 Judge 决定 add / merge / discard，合并会提升版本号。

它与 MUSE 的差别：AutoSkill 的创建发生在回合后的后台，主要依赖语义 Judge；没有看到当前工具执行的完整上下文，也没有逐技能调用经验或单元测试门禁。它更像个性化技能记忆层，MUSE 则把技能创建嵌进任务执行本身。

AutoSkill 原论文 ↗

AutoSkill 双回路：SkillBank 同时服务前台回答与后台技能演化。

展开说明 ▸

• 中央 SkillBank：保存带版本号的技能，是左右两个循环共享的长期状态。
• 左侧回答循环：当前输入先改写为独立检索查询，再混合检索、过滤并注入相关技能。
• 右侧抽取：用户交互成为技能候选的证据，重点抽取可复用偏好和工作流，而不是复制一次性问题。
• 管理决策：新候选可以添加、与旧技能合并，或因不够稳定与通用而丢弃。
• 闭环意义：后台更新后的技能会在未来查询中被重新检索，能力增长来自显式记忆而非微调。

另一条路线 · SkillOS arXiv 2026 展开 它用 RL 学会何时插入、更新或删除技能；但需要额外训练，迁移的是策展策略，而不是可直接交换的技能包。

它解决什么：技能编辑的价值经常要到后续相关任务才显现，固定增删规则难以处理这种延迟信用分配。SkillOS 将技能策展本身建模为长期 RL 问题。

它怎么做：冻结的 Agent Executor 从 SkillRepo 检索技能并执行任务；Curator 读取任务、轨迹、自判正确性和相关技能，输出 insert / update / delete 操作。训练样本由相互依赖的任务组组成，后续任务结果与内容质量、格式和压缩奖励共同更新 Curator。

它与 MUSE 的差别：SkillOS 迁移的是训练好的策展策略对不同 executor backbone 的兼容性，并且需要 RL 训练；MUSE 是 inference-time training-free，显式验证的是同一批技能文件能否不修改地交给另一种 Agent。

SkillOS 原论文 ↗

SkillOS 训练流程：任务组沿时间推进，后续结果为早期技能编辑提供学习信号。

展开说明 ▸

• 任务分组：每个训练实例是一组技能相关任务，并从空 SkillRepo 开始，模拟真实流式部署。
• 冻结 Executor：它只负责检索和执行，不更新参数，从而把性能变化归因到策展策略。
• 可训练 Curator：读取 rollout 后插入、更新或删除 Markdown 技能，更新结果留给后续任务。
• 复合奖励：任务结果、函数调用有效性、内容质量和压缩程度共同缓解延迟信用分配。
• 时间箭头：Curator 从早期大量插入逐步学会更新、删除和编排，目标不是无限扩张技能库。

三、MUSE 的答案：让一次成功经过六步，才成为技能

沿着上一节的共同缺口，MUSE 没有再增加一个独立的生成器，而是把技能子系统接进 Plan → Action → Observation 主循环。关键变化是：技能不能生成后直接入库，它必须经过执行和验收，失败信号还要回到技能本身。

教学主图（按论文 Figure 3 数据流重绘）：技能必须经过执行与验收；失败信号回到技能，通过后才入库并绑定私有记忆。

展开说明 ▸

• 主循环：用户任务进入 Master Agent，Plan、Action、Observation 循环直到输出最终结果。
• 复用分支：若库中已有技能，目录先帮助路由；选中后才加载完整 SKILL.md。
• 创建分支：若能力缺失，Creator 依据技能意图生成 SKILL.md 及可选脚本、测试和资源。
• 隔离执行：Executor 在沙箱加载技能、运行脚本并返回 observation 与 artifacts，副作用不污染宿主。
• 验证分支：有测试时运行测试；没有测试的文本技能或代码包，使用沙箱、源轨迹和运行反馈检查。
• 反馈闭环：失败进入 Refiner 后重试；成功的观察写入 Memory，并在后续规划中被 recall。

查看原论文图（Figure 3）▸

论文 Figure 3 原图：Master Agent、Skill Bank、Creator、Executor、Evaluator、Refiner 与 Memory 的端到端连接。信息较密，适合对照核对。

1. 先路由：Master Agent 只看技能名称与描述，已有能力够用就复用，缺口明确才创建。
2. 再打包：Creator 生成 SKILL.md，并按需要附带脚本、测试和资源。
3. 隔离执行：Executor 在沙箱中运行技能，返回 observation 与 artifacts，副作用不污染宿主。
4. 验收结果：有测试就运行测试；否则结合沙箱、源轨迹与运行反馈检查。
5. 失败修补：Evaluator 把具体错误交给 Refiner，修改技能后重新执行，而不是让调用者自己绕过去。
6. 成功复用：通过检查的技能才登记；后续调用把新经验写回该技能的私有记忆。

这六步形成了论文最重要的因果链：执行产生反馈，反馈决定是否登记，失败驱动修补，复用继续产生证据。因此技能不再是一次性的文字总结，而是一个会经历验收和维护的软件制品。

技能包为什么既像文档，又像软件包？

最小技能只需 SKILL.md；需要执行时再附带脚本和资源，需要客观验证时加入测试。目录先暴露 name + description，完整正文按需加载，体现 progressive disclosure。

pdf-form-update-redaction/
├── SKILL.md        # 对外接口、适用场景与工作流
├── scripts/        # 可选：沙箱中执行的代码
├── tests/          # 可选：代码技能的 pytest 验证
├── resources/      # 可选：数据、文档、模板
└── .memory.md      # 本 Agent 的逐技能经验，不随发布包迁移

四、闭环能成立，靠三道约束

六步流程不是把几个 Agent 串起来就结束。要让技能真的可复用，MUSE 还必须回答三个工程问题：技能以什么形式交换、凭什么允许入库、后续经验写回哪里。

迁移边界由此变得清楚：跨 Agent 分享的是标准技能包；私有 .memory.md 不进入发布包。因此实验测到的是「技能制品能否迁移」，不是把源 Agent 的历史一起复制过去。

选择性阅读：长任务如何压缩上下文而不丢掉原始历史

这不是技能闭环的核心，但它保证长 ReAct 任务能持续运行。MUSE 用可变 parent_id 定义当前活动链，用不可变 history_prev / history_next 保留原始顺序；压缩改变读取路径，不覆盖历史。

论文 Figure 4：先压缩超大单节点，仍超预算时再合并中间连续区间；原始历史始终可重放。

展开说明 ▸

• 固定两端：真实配置中最早 5 轮和最近 5 轮保持原文，保护任务定义和即时工作状态。
• Level 1：中间单节点超过 15K tokens 时，原位生成摘要但保留该轮边界。
• Level 2：总活动上下文仍超过 180K 时，把中间连续区间合成一个 synthetic summary node。
• 双指针：active chain 可以重连，但不可变历史指针从不重写，因此压缩前轨迹仍能恢复。

五、实验的回答：技能质量成立，稳定覆盖还不成立

当前 v2 在 75 个 SkillsBench 任务上评测，每种条件每任务运行 5 次；缺失技能、无输出和操作失败都记 0。这个分母恰好能检验核心问题：系统能否稳定把一次成功转成可复用技能，而不只是展示成功案例。

正确结论：一旦有可用源轨迹，MUSE 蒸馏出的技能很强；但 85.24% 不能当作整体成绩。全任务 53.42% 与 47/75 覆盖率共同说明，系统的主瓶颈已从「技能写得好不好」转向「Phase 1 能否先探索出一条可蒸馏轨迹」。

「可迁移」也获得了初步证据

• 直接注入 Hermes：无技能 37.24%，人工技能 48.02%，MUSE 技能 51.90%。同一批技能文件可以换 Agent 使用，但仍只有 47 个任务被覆盖。
• 独立 SkillLearnBench：无技能 43.0%、人工技能 72.0%、自创建技能 48.0%。自动技能有增益，但覆盖和质量还未追上人工技能。

相关基准：SkillsBench ↗ · SkillLearnBench ↗

因此，结论必须停在这三条边界内

• 任务筛选：只评测四种运行时都能本地执行的 75/94 个 SkillsBench 任务，被排除任务通常环境更复杂。
• 同任务重测：技能主要由一条成功轨迹蒸馏，再回到同一任务测试，可能高估跨输入、跨环境的泛化。
• 迁移仍是单向初测：只完整测试 MUSE 技能注入 Hermes，尚未完成多种 Agent 的全配对迁移；高风险使用仍需要人工审核。