从提示词到技能系统：MUSE-Autoskill 如何让 Agent 持续变强

系统提示词曾经是构建 Agent 的主战场。

想让 Agent 会写代码，就在提示词里塞代码规范；想让它会查资料，就在提示词里写搜索流程；想让它会操作表格、处理 PDF、跑测试、写报告，就继续往提示词里追加规则。这样做在早期很有效，因为大模型本身足够通用，只要给出清楚的角色、流程和约束，就能完成不少复杂任务。

但提示词有一个天然问题：它很难沉淀经验。

一次任务成功了，成功路径通常留在对话历史里；下一次遇到相似任务，Agent 可能还要重新摸索。一次任务失败了，失败原因也很难稳定进入后续调用。提示词越写越长，规则之间还会互相干扰。很多 Agent 系统最后都会遇到同一个问题：能力不是没有增长，而是增长方式太松散。

MUSE-Autoskill 这篇论文讨论的正是这个问题。

论文全名是 MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation，arXiv 编号是 2605.27366。它提出的核心观点很直接：Agent 不应该只依赖一次性的 prompt 或临时工具调用，而应该把高频能力沉淀成 Skill，并围绕 Skill 建立创建、记忆、管理、评估和修复机制。

换成工程语言，就是把 Agent 的经验变成可维护模块。

Prompt 的上限：经验很难稳定复用

假设一个 Agent 第一次处理 PDF 表格抽取任务。它可能经历这样一条路径：

1. 先尝试直接读取 PDF 文本。
2. 发现表格结构丢失。
3. 改用表格解析库。
4. 遇到大文件超时。
5. 增加分页处理和重试逻辑。
6. 最后生成 Markdown 表格。

这次任务完成以后，真正有价值的不是最后那份 Markdown，而是中间形成的经验：

• 大 PDF 不能一次性读完，要分页。
• 表格抽取要优先保留行列边界。
• 超过某个大小要分批处理。
• 失败时应该输出中间文件，方便继续调试。

如果这些经验只停留在对话上下文里，它们很快会消失。下一次再处理 PDF，Agent 可能又从第一步开始试错。

提示词可以写成这样：

当处理 PDF 表格时，优先使用分页解析；如果文件过大，要分批处理；输出 Markdown 表格；遇到错误时保留中间产物。

这比没有规则好，但仍然不够。它没有代码，没有测试，没有输入输出样例，也没有记录实际失败过的文件类型。更麻烦的是，当类似规则变成几十条、几百条，系统提示词会变成一份难维护的操作手册。

Skill 系统要解决的，是把这些规则从“写在 prompt 里”变成“以模块形式存在”。

Skill 不只是提示词片段

在 MUSE-Autoskill 的语境里，Skill 是一个可复用能力单元。它可以是一段说明文档，也可以包含脚本、工具、资源、测试和记忆。

一个典型 Skill 可以长成这样：

pdf_table_extract/
├── SKILL.md
├── scripts/
│   └── extract_tables.py
├── tests/
│   └── test_extract_tables.py
├── resources/
│   └── sample.pdf
└── .memory.md

SKILL.md 说明这个技能什么时候用、怎么用、输入输出是什么；scripts/ 放可执行代码；tests/ 用来验证技能是否真的能跑；resources/ 放样例或辅助文件；.memory.md 记录后续使用中积累的经验。

这和普通 prompt 的区别很大。

维度	Prompt	Skill
存在位置	上下文里	独立目录或技能库里
生命周期	通常随对话结束	可长期保存和复用
可测试性	很弱	可以写单元测试或验证脚本
可维护性	规则堆叠后难管理	可以版本化、合并、删除、更新
经验沉淀	依赖人工复制	可以写入 skill memory
迁移性	绑定某次对话	有机会跨 Agent 复用

一个例子就能看出差异。

如果提示词里写“处理 CSV 时注意编码”，Agent 仍然要自己决定怎么做。一个 CSV Skill 可以直接写明：

When reading CSV files:
- Try UTF-8 first.
- If decoding fails, retry with GB18030 for Chinese Windows exports.
- Preserve original column names.
- Never silently drop malformed rows; write them to rejected_rows.csv.

它还可以带一段测试：

def test_gb18030_csv_is_readable():
    rows = read_csv("samples/chinese_export_gb18030.csv")
    assert rows[0]["姓名"] == "张三"

这时 Skill 已经不是提示词补丁，而是一个可以被验证的工程模块。

MUSE-Autoskill 的核心：给 Skill 一个生命周期

MUSE-Autoskill 的全称里有四个关键词：Creation、Memory、Management、Evaluation。论文正文还把 Refinement 作为生命周期的一部分。把它们连起来，MUSE-Autoskill 实际上是在回答一个问题：

Agent 怎么从一次成功任务中提炼能力，并让这个能力在未来持续变好？

可以用一张流程图概括：

flowchart TD
  A["新任务"] --> B["Agent 执行任务"]
  B --> C{"是否形成成功轨迹"}
  C -->|是| D["Skill Creation"]
  D --> E["生成 SKILL.md / scripts / tests"]
  E --> F["Skill Evaluation"]
  F --> G{"测试是否通过"}
  G -->|通过| H["注册到 Skill Bank"]
  G -->|失败| I["Skill Refinement"]
  I --> F
  H --> J["后续任务检索并复用"]
  J --> K["写入 Skill Memory"]
  K --> H
  C -->|否| L["记录失败原因"]

这条链路的关键不在“生成一个文件”，而在于生成之后还要评估、注册、调用、记录经验、失败后再修复。

Skill Creation：从成功轨迹里提炼能力

自动创建 Skill 的前提，是 Agent 至少成功完成过一次任务。

例如 Agent 处理一个 Excel 清洗任务时，成功完成了这些步骤：

1. 读取工作簿。
2. 识别表头所在行。
3. 删除空行和合计行。
4. 标准化日期格式。
5. 输出干净 CSV。

MUSE-Autoskill 会尝试从这条成功轨迹中提炼可复用部分，生成一个类似 spreadsheet_cleaning 的 Skill。这个 Skill 不应该只记录“清洗 Excel”，而要写清楚边界：

• 适用于多表头、空行、合计行混杂的 Excel。
• 输入是 .xlsx 文件。
• 输出是清洗后的 CSV。
• 表头识别失败时要要求人工确认或输出候选行。
• 不能默认删除所有包含“合计”的行，因为有些业务字段可能合法包含这个词。

最后一点尤其重要。一个差的 Skill 会把单次成功路径硬编码成规则；一个好的 Skill 会把成功路径抽象成可迁移策略，同时保留必要的条件。

论文里 MUSE-Autoskill 的自创建实验也暴露了这个问题：它的 Skill 生成依赖成功轨迹。51 个 SkillsBench 任务里，MUSE-Autoskill 成功为 35 个任务生成了 Skill，覆盖率是 68.6%。剩下 16 个任务没有成功轨迹，也就无法生成可用 Skill。

这说明 Skill Creation 的瓶颈不是写文件，而是初始探索能力。Agent 需要先做成一次，才有材料总结经验。

Skill Memory：让技能记住自己踩过的坑

MUSE-Autoskill 里最有意思的设计，是 skill-level memory。

很多 Agent 系统都有短期记忆和长期记忆。短期记忆记录当前任务上下文，长期记忆记录跨会话偏好或事实。MUSE-Autoskill 额外给每个 Skill 配了一份自己的记忆文件，比如 .memory.md。

这份记忆不属于某个用户，也不属于某次任务，而属于某个技能。

以 PDF 抽取 Skill 为例，.memory.md 可以逐渐积累这些内容：

## Observations

- PDFs larger than 100MB often timeout with the default parser.
- Scanned PDFs need OCR before table extraction.
- Some bank statements use invisible text layers; validate extracted rows against page screenshots.
- When outputting Markdown, escape pipe characters inside cells.

下一次 Agent 调用这个 Skill 时，看到的不只是 SKILL.md 里的标准说明，还能看到历史使用中积累的经验。这样就避免了一个常见问题：同一个技能每次都在同一个坑里摔一次。

这也是 Skill Memory 和普通长期记忆的差别。普通长期记忆可能写着“用户喜欢 Markdown 输出”，这是用户偏好；Skill Memory 写的是“这个 PDF 解析技能在 100MB 以上容易超时”，这是技能经验。

从工程角度看，Skill Memory 像模块旁边的运行手册。代码负责执行，测试负责验证，memory 负责记录真实世界里的边界条件。

Skill Management：技能越多，治理越重要

如果 Agent 能持续创建 Skill，很快会出现另一个问题：技能库会变乱。

假设系统里已经有这些 Skill：

csv_cleaning
spreadsheet_cleaning
excel_table_normalize
financial_excel_parser
dataframe_export_helper

新任务来了，Agent 应该选哪一个？这些技能之间有没有重复？某些 Skill 是否已经过时？如果两个 Skill 都能处理 Excel，但一个更稳定，另一个只适用于金融报表，检索系统要能区分。

MUSE-Autoskill 把这部分放进 Skill Management。它涉及几类动作：

• Retrieval：根据任务描述找到候选 Skill。
• Merge：把高度相似的 Skill 合并，减少重复。
• Update：根据新经验更新 Skill 文档、脚本或测试。
• Forget：删除低质量、过时或长期不用的 Skill。

一个具体场景是：Agent 之前创建了一个 json_to_csv Skill，后来又创建了一个 nested_json_flatten Skill。多次使用后发现前者只是后者的简单子集，就可以把它合并进后者，在 SKILL.md 里增加“简单 JSON 也适用”的说明，并保留旧名称作为别名。

没有管理层的 Skill 系统，很容易变成“提示词垃圾场”的目录版。MUSE-Autoskill 的提醒在这里很现实：自动创建能力并不等于自动拥有能力，真正困难的是持续治理。

Skill Evaluation：没有测试的 Skill 不能放心复用

MUSE-Autoskill 另一处工程味很重的设计，是用测试来验证 Skill。

这点看似朴素，但对 Agent 很关键。因为 LLM 很擅长写出“看起来合理”的说明文档，也很擅长生成“看起来能跑”的代码。没有测试，Skill Bank 很快会混入大量半成品。

一个可用的 Skill 至少要回答三个问题：

1. 它能在样例输入上跑通吗？
2. 它的输出格式稳定吗？
3. 它失败时是否能给出可恢复的信息？

例如前面的 CSV Skill，可以配这些测试：

def test_preserve_column_names():
    result = clean_csv("samples/messy.csv")
    assert "订单编号" in result.columns

def test_rejected_rows_are_exported():
    clean_csv("samples/bad_rows.csv")
    assert Path("rejected_rows.csv").exists()

测试失败时，MUSE-Autoskill 不应该直接丢弃 Skill，而是进入 Refinement：让 Agent 根据失败信息修复 SKILL.md、脚本或测试，再重新执行评估。

这一步让 Skill 从“经验总结”变成“可验证资产”。对长期运行的 Agent 系统来说，这比单次表现更重要。一个没有测试的 Skill，调用得越多，风险越大；一个有测试、有失败反馈、有修复机制的 Skill，才有机会随着使用次数增加而变稳。

实验结果：Skill 是否真的让 Agent 变强

论文在 SkillsBench 上做实验。SkillsBench 包含真实任务，评估在标准化 Docker 环境中完成，并由自动 verifier 打分。论文报告的是其中 51 个任务，覆盖 Science & Engineering、Data Analysis、Document Processing、Ops & Planning 四类。

论文比较了三个 GPT-5.5-backed agents：Codex、Hermes 和 MUSE-Autoskill。它们都有无 Skill 和加入人工 Skill 的设置。

核心结果如下：

设置	总体准确率
Codex with human skills	67.3%
Hermes with human skills	61.2%
MUSE-Autoskill with human skills	68.40%
MUSE-Autoskill without skills	53.19%
MUSE-Autoskill self-created skills	60.35%

可以读出三层信息。

第一，Skill 对 Agent 确实有帮助。MUSE-Autoskill 加入人工 Skill 后，从 53.19% 提升到 68.40%，提升 15.21 个百分点。论文图 1 也显示，三个 Agent 加入人工 Skill 后都有明显提升。

第二，MUSE-Autoskill 自己生成的 Skill 也有效。51 个任务里，它成功为 35 个任务生成了 Skill。把这些自生成 Skill 纳入后，整体准确率达到 60.35%，比无 Skill 基线高 7.16 个百分点。

第三，覆盖任务上的效果很强。在成功生成 Skill 的 35 个任务上，第二阶段准确率达到 87.94%。这说明从成功轨迹里蒸馏出来的 Skill，确实能编码很强的任务相关知识。

但这个数字不能单独看。整体 51 任务准确率只有 60.35%，原因是另外 16 个任务没有生成 Skill，在总分里拖了后腿。论文也明确指出，当前瓶颈更多在 coverage，也就是 Agent 能否先完成任务并生成 Skill，而不是生成 Skill 之后的质量。

跨 Agent 迁移：Skill 是不是绑定某个 Agent

一个很有价值的实验是跨 Agent 迁移。

论文把 MUSE-Autoskill 生成的 Skill 文件不做修改，注入到 Hermes 里，然后重新评估。结果是 Hermes 从 47.89% 提升到 58.40%，提升 10.51 个百分点，接近 MUSE-Autoskill 使用同一批生成 Skill 时的 60.35%。

这说明生成的 Skill 不完全是 MUSE-Autoskill 运行时内部行为的副产品。它们以文档和脚本形式外化出来后，另一个 Agent 也能读懂并使用。

这个结论对 Agent 工程很重要。

如果 Skill 能跨 Agent 迁移，那么 Skill Bank 就不只是某个产品的私有配置，而可能成为一种能力资产。今天给 Codex 用，明天给 Hermes 用，后天给企业内部 Agent 用。不同 Agent 的模型、工具和运行时可以不同，但只要它们能理解同一套 Skill 接口，就能共享一部分经验。

当然，论文只验证了 MUSE-Autoskill 到 Hermes 这一个方向。要说 Skill 已经具备普遍迁移性，还需要更多 Agent、更多任务和更多运行环境验证。

这篇论文真正值得借鉴的地方

MUSE-Autoskill 最有价值的地方，不是提出“让 Agent 自动写 Skill”这个单点功能。自动生成文档、代码和测试，很多系统都能做一部分。

它更重要的启发是：Skill 应该被当成软件工程对象管理。

可以把三种能力组织方式放在一起看：

方式	典型形态	优点	问题
Prompt	系统提示词、Few-shot 示例	快、灵活、容易改	难测试，难沉淀，容易膨胀
Tool	API、函数、命令行工具	执行稳定，边界清晰	不一定包含使用经验
Skill	文档 + 脚本 + 测试 + 记忆	可复用、可测试、可演进	需要治理和评估成本

Tool 更像能力的执行接口，Skill 更像“什么时候用、怎么用、怎么避坑”的完整封装。一个 pdf_extract() 函数只是工具；一个 PDF Skill 会告诉 Agent 什么时候需要 OCR，什么时候要分页，如何验证抽取结果，失败后怎么保留中间文件。

这也是从提示词工程走向技能工程的变化。

提示词工程关心的是“怎么让模型这一次表现更好”。技能工程关心的是“怎么让系统下一次不用重新学习”。前者优化单次调用，后者沉淀长期能力。

局限：别把结果读得太满

论文的实验结果很吸引人，但也有几个限制需要放在一起看。

第一，评估只覆盖 SkillsBench 94 个任务中的 51 个。论文说明被排除的任务往往有更复杂的 Docker 环境，可能更难。因此当前数字可能高估了完整任务集上的表现。

第二，自生成 Skill 的覆盖率只有 68.6%。这意味着系统还不能稳定地为所有任务创建 Skill。没有成功轨迹的任务，Skill Creation 就没有足够材料。

第三，每个生成 Skill 来自单次成功轨迹。单次轨迹可能包含偶然选择和任务特定假设，未必是最泛化的解法。比如一次 Excel 清洗任务里删除了所有空列，不代表所有 Excel 清洗都应该这么做。

第四，跨 Agent 迁移只验证了一个方向：MUSE-Autoskill 到 Hermes。更强的结论需要在更多 Agent、更多模型和更多工具环境里重复。

第五，每个任务 5 次运行，对二值奖励任务来说置信区间仍可能较宽。对于真实生产环境，还需要更长周期的线上验证。

这些限制不削弱论文的工程价值，反而提醒读者：Skill 系统不能只看一次 benchmark。它需要长期运行后的稳定性、可维护性和治理成本数据。

对开发者的启发

如果正在做 Agent 应用，MUSE-Autoskill 至少给出几个很实用的建议。

第一，不要把所有经验都塞进系统提示词。系统提示词适合放全局原则，比如安全边界、输出风格、工具调用规则；具体任务经验更适合沉淀成 Skill。

第二，高频任务要模块化。比如“复核技术文章”“抽取 PDF 表格”“生成数据库迁移脚本”“检查前端页面可访问性”，这些都可以变成独立 Skill。

第三，Skill 要有测试。哪怕只是一个最小样例，也比纯文档强。测试能防止 Skill 在修改后悄悄失效。

第四，给 Skill 留记忆位置。很多使用经验不是第一次写 Skill 时就知道的，而是在真实任务里逐渐遇到的。把这些经验写回 .memory.md，比写进一份巨大的全局记忆更容易复用。

第五，定期清理 Skill Bank。自动创建越强，治理越重要。重复、过时、低质量的 Skill 会污染检索结果，让 Agent 更难选对能力。

一个简化版 Skill 规范可以这样设计：

skill-name/
├── SKILL.md        # 使用说明、适用场景、输入输出
├── scripts/        # 可执行脚本，可选
├── tests/          # 最小验证用例
├── resources/      # 样例文件或模板
└── .memory.md      # 使用经验、失败模式、注意事项

这套结构不复杂，但它把能力从“写在 prompt 里”推进到了“可以维护的目录里”。

结语

MUSE-Autoskill 讨论的不是一个小技巧，而是 Agent 能力组织方式的变化。

当任务简单时，提示词足够好用；当任务变长、工具变多、场景变复杂，Agent 需要的不只是更长的上下文，而是一套能沉淀经验的机制。Skill 正好提供了这样的抽象：它把过程、代码、测试和记忆放在一起，让一次成功不再只是一次成功，而能变成后续任务可以调用的能力。

这篇论文的关键启发可以压缩成一句话：Agent 持续变强，不只依赖更大的模型，也依赖能否把经验转化成可复用、可测试、可演进的技能系统。

参考资料

• Huawei Lin, Peng Li, Jie Song, Fuxin Jiang, Tieying Zhang. MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation. arXiv:2605.27366. https://arxiv.org/abs/2605.27366
• arXiv PDF: https://arxiv.org/pdf/2605.27366
• Anthropic. Agent Skills: Equipping Agents for the Real World. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Anthropic Skills GitHub Repository. https://github.com/anthropics/skills