可进化 Skill：AutoSkill 与 XSKILL 的智能体经验学习机制

Agent 要想越用越好，不能只依赖大模型本身的参数能力，还需要把使用过程中的经验沉淀下来。这里的关键对象就是 Skill。

一个固定不变的 Skill，本质上更像一段可复用 Prompt：它能描述任务步骤、工具调用方式、注意事项，但不会因为新的失败案例、新的用户偏好或新的环境状态而改变。可进化 Skill 的目标不同，它把每一次交互都看成一次训练样本，把有价值的经验合并进 Skill，把一次性需求丢弃，把重复经验压缩成更稳定的操作原则。

可以把 Skill 理解成 Agent 的“外部程序性记忆”。它不一定修改模型参数，却能改变 Agent 之后处理任务的方式。

flowchart LR
    A[用户任务] --> B[检索相关 Skill]
    B --> C[大模型生成回答或动作]
    C --> D[用户反馈 / 执行轨迹 / 环境观察]
    D --> E[经验抽取]
    E --> F{Skill 管理}
    F -->|Add| G[新增 Skill]
    F -->|Merge| H[合并到已有 Skill 并更新版本]
    F -->|Discard| I[丢弃一次性经验]
    G --> J[(Skill Bank)]
    H --> J
    J --> B

这个闭环里有两个重点：

1. Skill 被当成长期资产管理，不是一次性提示词。
2. 经验要经过筛选和压缩，不是把所有聊天记录或执行日志原封不动塞进知识库。

AutoSkill 和 XSKILL 分别从两个方向推进了这个思路：AutoSkill 解决对话交互中的 Skill 版本化演进，XSKILL 解决多模态智能体中结构化 Skill 与情境化 Experience 如何配合。

AutoSkill：让 Skill 在用户交互中持续迭代

传统 RAG（Retrieval-Augmented Generation，检索增强生成）系统通常把知识库看成静态文档集合。用户提问时，系统检索相关文档，把内容塞进上下文，再让大模型生成回答。问题在于，这个过程只“使用知识”，不“更新知识”。

AutoSkill 的核心变化是：用户交互不只是输入输出记录，而是可以转化为新的 Skill 或已有 Skill 的新版本。

双循环架构：回答当前问题，同时更新长期能力

AutoSkill 把系统拆成两个循环：一个负责生成当前响应，另一个负责从交互经验里进化 Skill。

左侧的 Response Generation Loop 负责解决当下任务：根据用户输入检索 Skill，把匹配到的 Skill 放入上下文，生成回答。右侧的 Skill Evolution Loop 负责处理长期学习：从用户请求、模型回答、用户反馈中抽取可复用经验，再决定是否写入 Skill Bank。

这个架构的关键不是“多了一个知识库”，而是 Skill Bank 会持续变化。每次交互结束后，系统都会判断新经验属于哪一类：

Merge 是 AutoSkill 里最重要的动作。它不是简单追加日志，而是把新经验提炼成更通用的规则，再更新已有 Skill 的版本。

一个工程化 Skill 可以组织成类似下面的 Markdown 工件：

# professional_text_rewrite

Version: 0.1.34

## Trigger
当用户要求改写、润色、压缩、扩写专业文本时使用。

## Goal
在保持事实不变的前提下，提高表达清晰度、结构性和目标读者适配度。

## Procedure
1. 识别文本用途：论文、技术博客、商业文案、报告或邮件。
2. 保留核心事实、数据、约束条件和专有名词。
3. 根据目标场景调整语气、段落结构和术语密度。
4. 输出前检查是否引入了新事实。

## Common Failures
- 过度美化导致事实变化。
- 删除了限定条件。
- 把技术概念改写得过于口语化。

## Changelog
- v0.1.34: 增加“不得引入新事实”的检查步骤。

版本号在这里不只是装饰。它表示这个 Skill 被多少轮有效经验打磨过。一个频繁被调用、频繁被纠正、频繁被合并的 Skill，会比一个从未更新过的 Skill 更接近真实使用需求。

SkillBank 的统计能反映真实需求分布

AutoSkill 在 WildChat-1M 数据集上构建 SkillBank，并统计了不同子集的规模和结构。下面的表格展示了 SkillBank 子集的基本信息。

这类统计的价值在于，它能把“用户到底经常需要什么能力”显式化。SkillBank 不再只是人工预设的分类目录，而是从大量交互中长出来的能力集合。

技能类别分布也能看出哪些任务更容易发生持续迭代。

其中，编程与软件开发类 Skill 数量达到 482 个，写作创作类 Skill 数量达到 363 个。这两个方向之所以活跃，并不难理解：它们都是高频生产力场景，用户会反复提出相似但不完全相同的需求，系统也更容易从反馈中总结出可复用规则。

版本号可以作为 Skill 成熟度信号

AutoSkill 的案例里有一个很典型的对比：

这说明 Skill 的价值不只取决于初始写得多完整，更取决于它能不能在使用中被持续校正。高频 Skill 往往会变成系统里的核心资产，低频 Skill 则可能长期停留在初始状态。

AutoSkill 的方法也提醒了一点：Skill 进化不是无限追加内容。真正有价值的是把用户反馈压缩成更稳定的操作规则，而不是把所有对话都存下来。

AutoSkill 相关资料：

AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution
https://arxiv.org/pdf/2603.01145
https://github.com/ECNU-ICALK/AutoSkill

XSKILL：让 Skill 和 Experience 在多模态任务中协同进化

AutoSkill 更关注对话和文本交互里的 Skill 自进化。XSKILL 面对的问题更复杂：多模态 Agent 不只要读文本，还要看图像、理解环境状态，并调用工具完成任务。

在这种场景里，单靠一份“任务手册”并不够。因为同一个工具调用步骤，在不同视觉状态下可能有不同选择；同一个任务目标，也可能因为画面内容不同而需要不同动作。

XSKILL 把长期知识拆成两条流：

这两个部分并不是替代关系。Skill 提供稳定流程，Experience 负责根据当前场景做适配。

两阶段框架：先积累知识，再用知识解决新任务

XSKILL 的整体流程分为两个阶段：Phase I 通过执行轨迹积累知识，Phase II 在新任务中检索并使用这些知识。

Phase I 会从视觉观察、动作序列和任务结果中总结经验，并通过交叉批判机制比较成功轨迹与失败轨迹。Phase II 则把新任务拆解成子任务，再结合 Skill Library 和 Experience Bank 生成动作。

这个流程可以简化成下面的调用关系：

sequenceDiagram
    participant Env as 多模态环境
    participant Agent as Agent
    participant Skill as Skill Library
    participant Exp as Experience Bank
    participant Critic as 轨迹批判器

    Agent->>Env: 执行任务并观察图像状态
    Env-->>Agent: 返回视觉观察和执行结果
    Agent->>Critic: 提交多次成功/失败轨迹
    Critic->>Skill: 更新结构化任务流程
    Critic->>Exp: 写入情境化经验
    Agent->>Skill: 新任务检索通用流程
    Agent->>Exp: 检索相似场景经验
    Agent->>Env: 生成更稳妥的动作序列

Cross-Rollout Critique：从多次尝试里找因果经验

单次失败并不能说明规则。比如一个多模态 Agent 调错了工具，可能是视觉识别错了，也可能是任务拆解错了，还可能是工具参数写错了。

XSKILL 使用 Cross-Rollout Critique，对同一类任务的多次执行轨迹进行比较：

• 成功轨迹做了什么？
• 失败轨迹在哪一步偏离？
• 哪些视觉线索会影响工具选择？
• 哪些动作看似合理但会导致后续失败？

这种比较能把“结果不好”拆成更具体的原因。经验不是简单记录“这次失败了”，而是提炼成“当图像中出现某类对象或布局时，应该优先使用某个工具，避免某种参数组合”。

Hierarchical Consolidation：合并相似经验，删除冗余内容

Experience Bank 如果只追加不整理，很快会变成噪声库。XSKILL 用 Hierarchical Consolidation 做分层整合：

1. 相似经验归并成更通用的经验。
2. 重复或低价值经验删除。
3. Skill 文档自动精简，避免越来越长。
4. 高层流程和低层动作经验保持分工。

这一步很像给长期记忆做“压缩”。保留能迁移的模式，去掉具体任务里的偶然细节。

Visual Grounding：经验必须绑定视觉观察

多模态 Agent 的一个常见风险是：模型会根据文本描述想象场景，而不是基于真实视觉状态做判断。XSKILL 强调 Visual Grounding，也就是知识提取必须来自视觉观察和执行轨迹。

这能减少两类问题：

实验结果：Skill 与 Experience 需要配合使用

XSKILL 在 5 个多模态基准测试中和多个基线方法进行了比较。结果显示，在 Average@4 指标上，XSKILL 相比最强基线 Agent-KB 最高提升 11.13 分。

这个结果说明，知识库对 Agent 有帮助，但知识库的组织方式很关键。只存静态知识不够，单纯堆经验也不够；把结构化 Skill 和情境化 Experience 分开管理，再在执行时组合使用，才能让多模态任务更稳定。

错误分析能更细地展示两类知识的作用差异。

从错误类型看，Skill 对格式和调用规范尤其重要。它能显著减少语法错误和工具名错误，例如语法错误比例从 20.3% 降到 11.4%，工具名错误比例从 2.85% 降到 0.32%。Experience 更偏向策略层，帮助 Agent 在具体视觉情境下选择更合适的工具或动作。

这里也能看出一个实际设计原则：
Skill 负责“怎么做才规范”，Experience 负责“当前场景下怎么选”。

跨任务迁移：检验进化出来的是不是通用能力

持续学习最容易陷入一个误区：系统在训练任务上表现变好，但换个任务就失效。XSKILL 用跨任务迁移来检验知识是否具有泛化能力。

实验把 VisualToolBench 中积累的知识直接迁移到 TIR-Bench，不针对新任务重新训练。

结果显示，XSKILL 迁移后的表现仍然优于其他基线。这说明它沉淀下来的不是某个任务的硬编码答案，而是更接近“如何观察、如何拆解、如何选择工具”的元能力。

静态 Skill 和可进化 Skill 的区别

把 AutoSkill 和 XSKILL 放在一起看，可以得到一套更清晰的 Skill 设计标准。

可进化 Skill 的本质不是“把 Prompt 写得更长”，而是建立一套生命周期管理机制。

flowchart TD
    A[初始 Skill] --> B[任务调用]
    B --> C[获得反馈或轨迹]
    C --> D[抽取候选经验]
    D --> E{是否可复用}
    E -->|不可复用| F[丢弃]
    E -->|新能力| G[新增 Skill]
    E -->|改进旧能力| H[合并并生成新版本]
    H --> I[回归检查]
    G --> I
    I --> J{是否通过}
    J -->|通过| K[发布到 Skill Bank]
    J -->|不通过| L[回滚或人工审核]
    K --> B

设计可进化 Skill 时要注意的工程问题

可进化 Skill 很有用，但不能无约束自动更新。真实系统里需要处理几个问题。

1. 不能把所有交互都写入 Skill

用户的一次需求可能非常特殊，例如“把这句话改成我朋友喜欢的风格”。这种信息没有长期复用价值，写进 Skill 反而会污染后续任务。

更安全的做法是给经验抽取加判断条件：

2. Merge 要做冲突检测

新经验可能和旧 Skill 冲突。比如旧 Skill 要求“技术改写时保持术语不变”，新反馈却要求“把所有术语改得更口语”。这不一定说明旧规则错了，可能只是场景不同。

更合理的合并方式是增加触发条件，而不是简单覆盖：

## Rule
默认保留技术术语，避免改变概念边界。

## Exception
如果用户明确要求面向非技术读者，可以在首次出现术语时添加解释，
但不要删除关键概念。

3. 版本更新后要做回归测试

Skill 更新可能修复一个问题，同时破坏另一个场景。每次 Merge 后都应该用一组固定任务检查回归。

def update_skill_bank(candidate, skill_bank, regression_set):
    matched_skill = retrieve_similar_skill(candidate, skill_bank)

    if matched_skill is None:
        new_skill = create_skill(candidate)
        if pass_regression_tests(new_skill, regression_set):
            skill_bank.add(new_skill)
        return

    merged_skill = merge_skill(matched_skill, candidate)
    merged_skill.version = bump_patch_version(matched_skill.version)

    if pass_regression_tests(merged_skill, regression_set):
        skill_bank.replace(matched_skill, merged_skill)
    else:
        log_failed_merge(candidate, matched_skill)

这段伪代码表达的是一个基本原则：自动进化可以存在，但发布前需要检查。否则 Skill Bank 会逐渐堆积错误经验。

4. Experience 和 Skill 要分层存储

XSKILL 的双流设计对工程落地很有启发。结构化流程和情境化经验最好不要混在一起。

这样做能避免 Skill 文档越来越碎，也能让 Experience Bank 保留足够的场景细节。

从写 Skill 到维护 Skill 生命周期

可进化 Skill 的核心思想可以概括成三句话：

1. 进化是压缩：把大量交互和轨迹压缩成少量可复用规则。
2. 进化是对齐：每次版本更新都让 Skill 更贴近真实用户需求和环境反馈。
3. 进化是资产化：Skill Bank 记录的不只是任务说明，而是一套可复用、可迁移、可回滚的能力历史。

Agent 系统如果只会调用工具，能力上限取决于模型当前表现；如果能把成功和失败都沉淀成可管理的 Skill，它就有机会在不改模型参数的情况下持续改进。

AutoSkill 给出了对话场景下的 Skill 自进化路径，XSKILL 给出了多模态任务中 Skill 与 Experience 协同学习的路径。两者共同指向同一个工程结论：Skill 不应该只是写好后放进库里的静态提示词，而应该拥有版本、反馈、合并、验证和回滚机制。

相关资料：

AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution
https://arxiv.org/pdf/2603.01145
https://github.com/ECNU-ICALK/AutoSkill

XSkill: Continual Learning from Experience and Skills in Multimodal Agents
https://arxiv.org/pdf/2603.12056
https://xskill-agent.github.io/xskill
https://github.com/XSkill-Agent/XSkill