论文信息
- 标题：Continual Learning from Experience and Skills in Multimodal Agents
- 方法名：XSkill
- 领域：多模态 Agent / Agent Memory / Tool Use / Continual Learning
- 结论一句话：这篇工作想解决多模态 agent 每次都像“失忆”一样重新做题的问题，提出把历史轨迹抽成两类外部知识——
experience和skill，再在新任务上检索、改写、注入，做到不更新参数也能持续变强。
这篇论文在做什么
这篇论文盯的是一个很实在的问题：现在多模态 agent 虽然已经能调工具、看图、搜网页、写代码，但大部分系统还是单回合、无记忆、无成长的。
具体表现为两类瓶颈：
- tool use 低效：简单题也会绕很多步，复杂题又容易探索不够。
- tool orchestration 不灵活：工具组合比较僵，遇到新场景很难把已有套路迁移过来。
作者认为，人类做题时会同时依赖两类知识：
- experience：偏局部、偏战术的经验，比如“图像倒了先旋转”“目标很小先裁剪再识别”。
- skill：偏全局、偏流程的技能，比如“这类题应该先分解任务，再搜图，再写代码验证”。
所以 XSkill 的核心想法其实挺直给：
不要只记完整轨迹，也不要只记一个统一 memory；而是把历史轨迹提炼成技能（skill）+经验（experience）两条知识流，分别负责高层规划和低层决策。
核心方法
先看论文里最重要的框架图，基本把整套方法都画出来了：
上图可以直接概括成一句话： 先从多条历史轨迹里抽 skill 和 experience，再在新任务上检索、改写、注入给 agent。
1. 双流知识库：Skill + Experience
XSkill 把外部知识库拆成两部分：
Skill Library
Skill 是任务级别的结构化知识，主要描述：
- 这类任务通常怎么拆解
- 工具调用流程怎么组织
- 哪些代码模板可以复用
作者把它存成 Markdown 文档，里面包含：
- 元信息（名字、描述、版本）
- workflow sequence
- reusable tool templates
你可以把它理解成： “这类题通常怎么做”的 SOP。
Experience Bank
Experience 是动作级别的短经验，结构更像条件-动作对：
- condition：什么情况下触发
- action：该怎么做
例如：
- 如果图片方向异常，先做旋转校正；
- 如果目标太小，先 crop 再识别；
- 如果网页证据不一致，优先回到图像本身验证。
它本质上是面向执行时刻的 tactical prompt，而不是完整流程。
2. 两阶段框架
XSkill 分成 accumulation 和 inference 两个阶段。
Phase I：Accumulate（积累知识）
给定训练任务，agent 会做多条 rollout，然后从这些轨迹里抽知识。
a) Rollout Summary
对每个任务做多次 rollout，收集不同成功/失败路径。 然后用一个专门的知识管理模型去总结：
- 哪些关键决策点起作用
- 哪些 tool pattern 有用
- 哪些失败是由视觉线索误判导致的
这里作者特别强调： 总结不是只看文字轨迹，而是要结合视觉观察一起做。
这点很关键。因为很多多模态任务里的成败信号，本来就来自图像本身：
- 图是不是倒了
- 对象是不是太小
- 对比度是不是太低
- 当前视觉上下文是不是和旧经验匹配
b) Cross-Rollout Critique
然后让系统对不同 rollout 做对比分析：
- 成功轨迹为什么成功
- 失败轨迹为什么失败
- 哪些经验应该新增
- 哪些旧经验应该改写
这一步的产物主要是新的或修改后的 experience。
c) Knowledge Consolidation
为了避免知识库越来越乱，作者又加了 consolidation：
- 相似 experience 先做 merge
- 低质量、低泛化性的经验会被删掉
- skill 文档过长也会被压缩、抽象和去冗余
所以它不是简单“越记越多”，而是试图把 memory 做成一个可维护的知识库。
Phase II：Inference（用知识做题）
到测试时，XSkill 不是把整个知识库硬塞给模型，而是做三步：
a) Task Decomposition Retrieval
先把当前任务分解成若干子任务，再针对每个子任务检索相关 experience。
这比直接拿原始 query 去检索更合理，因为复杂任务往往同时需要多个局部能力：
- 图像增强
- 几何比较
- 搜索网页证据
- 错误恢复
b) Experience Rewrite
检索到的经验不会直接用，而是会结合当前图像和任务上下文重写。
比如原始经验可能只是：
当图像方向异常时先校正再识别。
在当前任务里会被改写成更具体的版本：
当前图像存在上下颠倒，先旋转 180 度再做物体识别。
这一步解决的是： 经验得可迁移，但落地时又得足够具体。
c) Skill Adaptation
全局 skill 文档也会根据当前任务裁剪、改写，并把刚刚改写好的 experiences 融进去。
最后把这个 adapted skill 注入给执行模型，作为一个非强制参考。
也就是说，XSkill 不是把 agent 变成固定脚本，而是给它一个更贴题的“作战手册”。
这篇方法为什么有价值
我觉得这篇论文最值钱的地方，不是“又做了一个 memory”，而是把 agent 的外部知识拆成了两种粒度：
- skill 管高层流程
- experience 管局部战术
这比很多把所有历史信息混成一个向量库/轨迹库的做法更合理。
因为真实 agent 失败，往往就败在两个层面：
- 要么流程没想对，比如本该先搜图后访问网页，结果直接瞎搜；
- 要么局部动作没做对，比如该裁剪没裁剪，该旋转没旋转。
XSkill 相当于把这两个问题分开建模了。
另外，多模态场景里作者强调“visual grounding”也是对的。很多 text-only memory 的方法迁到图像任务上，都会碰到同一个问题： 文字很难完整表达当时真正触发决策的视觉线索。
实验结果
作者在 5 个 benchmark 上评测，覆盖三类任务：
- visual agentic tool use
- multimodal search
- comprehensive multimodal reasoning
并在 4 个 backbone 上做实验：
- Gemini-2.5-Pro
- Gemini-3-Flash
- GPT-5-mini
- o4-mini
主要结论
-
相对 tool-only baseline，XSkill 一直有提升。 Average@4 提升大约 2.58 到 6.71 个点。
-
相对已有 learning-from-experience baseline，多数设置下更强。 尤其在复杂视觉推理和多步工具组合任务上优势更明显。
-
跨模型迁移有效。 有些模型直接使用 Gemini-3-Flash 累积的知识，也能得到增益。
这说明它学到的不只是某个模型私有的 prompt hack，而更像是可以转移的外部知识结构。
消融实验说明了什么
作者做的消融基本支持了论文主张。
1. skill 和 experience 缺一不可
去掉任意一个都会掉点：
- 去掉 experience：性能下降
- 去掉 skill：性能也下降，而且下降还更明显一些
这说明两条流不是重复建设，而是确实互补。
2. skill 更像是在“减少执行错误”
作者分析发现，skill 能明显减少：
- syntax error
- tool name error
- runtime 级别的执行错误
这很符合直觉： skill 本质上就是结构化 workflow + template，对执行鲁棒性帮助很大。
3. experience 更像是在“改变工具选择策略”
experience 的加入会让 agent 更偏向用更合适的工具，例如：
- 在视觉推理任务中更频繁调用 code interpreter
- 在 multimodal search 中更愿意调用 image search
也就是说，它提升的不是“写代码语法正确率”，而是： 当前这个题，应该先用什么手段试。
我的判断：这篇论文真正的增量在哪里
我认为这篇工作的真实增量有三点。
增量 1：把记忆分成 task-level 和 action-level
这是最核心的设计点，也是最像“一个对 agent 有用的 memory system”的地方。
很多 memory paper 的问题是： 记了很多，但不知道这些 memory 到底服务于哪一级决策。
XSkill 至少在结构上回答了这个问题。
增量 2：强调视觉 grounding，而不是只做 text memory
这使它比很多纯文本 agent memory 方法更适合多模态场景。
如果 retrieval 和 rewrite 不能看当前视觉上下文，那么很多所谓经验在图像任务里其实是没法对齐的。
增量 3：强调 knowledge adaptation，而不是生硬拼接
检索后先 rewrite，再注入 skill，这条链路是合理的。
因为 raw memory 直接拼 prompt 经常有两个问题：
- 不够贴当前任务
- 干扰项太多
XSkill 至少在框架上认真处理了这个问题。
这篇论文的局限
虽然我觉得思路不错，但也有几个明显边界。
1. 还是强依赖知识管理模型本身的能力
XSkill 的关键步骤——summary、critique、merge、rewrite、adapt——几乎都靠 MLLMkb 完成。
这意味着：
- 如果知识管理模型不够强，抽出来的经验可能很虚；
- merge / rewrite 也可能带来信息漂移；
- 整个系统的效果很依赖 prompt engineering 和管理模型质量。
换句话说，它虽然是“training-free”，但不是“cost-free”或“pipeline-free”。
2. benchmark 证明了有效，但离真实长周期在线学习还有距离
论文现在展示的主要还是： 先 accumulate 一批，再 test。
作者说架构支持 continual loop，这在逻辑上没问题； 但它还没有真正展示一个持续数周/数月、知识不断演化的真实在线系统会不会：
- memory 爆炸
- 经验污染
- 旧经验过时
- 错误经验反复被强化
3. 知识质量评估还是偏 heuristic
什么叫“高质量 experience”、什么叫“泛化性强的 skill”，现在更多还是让模型自己判断。
这在小规模实验里可行，但真到大规模长期积累时，很可能会变成瓶颈。
4. 与参数更新路线的关系还没完全说透
这篇论文强调 non-parametric continual learning，这当然很实用； 但从长期看，外部知识库和参数内化之间怎么配合，依然是开放问题。
也许更现实的方向不是二选一，而是：
- 在线阶段靠 XSkill 这种外部知识库快速适配
- 离线阶段再把稳定模式蒸馏回模型参数
我觉得适合谁看
这篇论文比较适合以下几类人：
- 做 multimodal agent / tool-use agent 的人
- 在想 memory 怎么设计，而不是只想“加个向量库” 的人
- 想做 test-time continual improvement 的人
- 对 agent skill / workflow / experience 这类外部知识表示感兴趣的人
如果你做的是纯 LLM benchmark 刷分，这篇的吸引力可能一般； 但如果你关心“agent 怎么随着任务越做越强”，这篇是值得读的。
一句话评价
这篇论文不是在证明 agent 终于会“学习”了，而是在认真回答：一个多模态 agent 的外部知识，到底该按什么粒度组织，才能真正在下一题派上用场。
