WikiSkill:将智能体经验编纂为持久知识以实现技能演化
WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution
论文信息
标题: WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution
作者: Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, et al.
发布日期: 2026-08-27
arXiv ID: 2608.27454v1
PDF 链接: 下载 PDF
3 分钟速览
- 研究问题:如何把智能体在执行任务中积累的经验,系统性地编译成持久、可复用的知识,以支撑技能跨迭代持续演化。
- 核心方法:引入 WikiSkill 框架,将工作区划分为原始轨迹、Wiki 知识库、可执行技能三层,并通过推理、Wiki 维护、技能提案、验证门控四个组件循环迭代。
- 关键结果:在五个基准、五个模型上,WikiSkill 的平均性能均高于 EvoSkill、Trace2Skill、SkillOpt 等现有技能演化方法;例如 Gemini-3.5-Flash 的平均准确率从无技能的 49.5% 提升到 68.1%(表 1)。
- 主要局限:验证门控只接受验证分数提升的提案,会排除中性但可能有利于后续演化的更新;Wiki 层没有自动剪枝机制;未评估技能检索或触发;未覆盖数百步的超长时域任务(论文 Limitations)。
- 适合读者:关注 LLM 智能体技能演化、经验知识沉淀、自动化工作流设计,以及跨模型能力迁移的研究者与工程师。
论文背景和研究动机
通用智能体在复杂任务中越来越依赖领域专长,而 “智能体技能”(agent skill)提供了一种轻量的开放格式:将指令、脚本等打包成文件系统模块,无需更新模型参数即可扩展能力。技能支持渐进式披露,只在需要时加载相关内容,节省上下文空间。但开发有效技能仍依赖人工预判领域知识。
近年来出现自动技能发现与演化框架,如 EvoSkill、Trace2Skill、SkillOpt。它们的共同点是从执行轨迹中总结成功策略和失败原因,提出技能修改并用验证分数做门控。论文指出,这些方法的不足在于:演化过程中获得的洞察分散在优化历史、提案记录和轨迹中,没有形成一个独立的、持续演化的知识表示。
受 Karpathy 关于 LLM Wiki 的思考启发,论文提出 WikiSkill:将智能体经验编译进一个持久、可复利的知识库,使后续技能更新能建立在不断累积、整合的知识之上,而不是依赖散落在各次迭代中的演化产物。这一动机贯穿全文。
核心方法和技术细节
WikiSkill 将工作区组织为三层。原始层 raw/ 存储不可变的执行轨迹,包含推理、工具调用、环境反馈和最终答案。Wiki 层 wiki/ 维护持久知识,包含模式目录 patterns/、演化日志 logs.md 和技能影响跟踪器 skill-impact.md。技能层 skills/ 存放当前激活的技能,每个技能目录含 SKILL.md 和 PURPOSE.md,后者将技能映射回它来源的 Wiki 模式。
每次迭代包含四个组件。推理智能体用当前技能集 在训练任务上执行 rollout,生成轨迹。注意:训练 rollout 期间推理智能体被禁止访问 Wiki 层;论文第 5.1 节消融显示,允许其访问 Wiki 会降低最终技能质量(平均性能从 63.7% 降至 60.9%,表 3)。Wiki 维护器分析采样轨迹并更新 Wiki:进行根因分析,创建或增量编辑模式页,更新索引与演化日志。技能提案器以 ReAct 方式自主探索:先读 Wiki 索引、技能影响记录和任务结果摘要,再按需读取模式页和原始轨迹,最后生成一个原子提案,创建新技能或对现有技能做增量补丁。门控机制在验证集上评估候选技能;只有验证分数严格高于历史最优分数时才接受,否则技能回滚到上次成功配置。关键设计是:Wiki 永不回滚,无论提案是否被接受,模式、日志和提案差异都持续累积(见 Algorithm 1)。
形式上,系统状态为 ,技能集初始为空。每次迭代先 rollout 得到训练轨迹 ,Wiki 维护器从采样轨迹更新中间 Wiki 状态 ,技能提案器生成 ,应用后得到候选技能集,再用验证分数决定接受或回滚。最终通过 写入技能影响记录,完成状态转移。
创新点和贡献
论文贡献有三点。第一,提出 WikiSkill 框架,将技能演化与持久知识库共演化,使经验沉淀和技能更新解耦。与 EvoSkill 的扁平历史、Trace2Skill 的轨迹教训合并、SkillOpt 的拒绝编辑反馈相比,WikiSkill 建立了一个可持续积累的模式目录和审计轨迹,允许后续提案避免重复失败。
第二,在五个基准和五个模型上系统评估,覆盖数学推理 LiveMath、网络搜索 SealQA、电子表格 SpreadSheet、长文档问答 OfficeQA、具身交互 ALFWorld。结果显示 WikiSkill 在所有模型上的平均性能均超过对比方法(表 1),且作者报告改进随模型规模增大而增大。
第三,对跨模型技能迁移的分析揭示了技能发现与技能执行是两个不同能力。例如,Qwen-3.5-4B 在 OfficeQA 上自我演化技能会略微损害自身性能(30.2%→28.5%),但同一技能将 Qwen-3.6-27B 从 42.1% 提升到 52.9%(表 2)。论文据此提出,小模型可能发现有用程序但自身难以在长上下文中执行;这一判断带有作者推测成分,但为后续研究提供了可检验方向。
实验结果分析
主实验结果见表 1。在 25 个模型-基准组合中,WikiSkill 在绝大多数组合上优于无技能基线,并在每个模型上平均性能最高。相比每个模型的最强竞争方法,WikiSkill 平均分别提升 3.3、5.1、10.0、5.8、12.0 个百分点(见表 1 对应模型)。但这些提升在不同数据集和模型间差异明显,不宜泛化为普遍规律。
模型规模互补性在 Qwen 家族中表现明显:WikiSkill 相对无技能的平均提升为 12.3、17.5、23.9 个百分点(4B→9B→27B,见论文第 4.2 节)。同时,Qwen-3.5-9B 使用 WikiSkill 达到 47.4% 平均准确率,超过 Qwen-3.6-27B 无技能的 39.4%(表 1)。这说明在该评测设置下,较小模型携带技能可以补偿较大的模型规模差距,但论文未声称这一关系在所有任务上都成立。
跨模型迁移实验见表 2。Qwen-3.6-27B 技能将 Qwen-3.5-9B 的 SpreadSheet 从无技能 24.3% 提升到 50.5%,超过其自我演化技能的 33.6%;Qwen-3.5-4B 技能将 Gemma-4-31B 的 LiveMath 从 33.9% 提升到 73.1%,也超过自我演化技能的 56.7%。这说明在该实验条件下,技能来源模型更强并不保证产生更优技能,且跨模型迁移可能优于自我演化。
消融实验(表 3)支撑了持久 Wiki 的核心作用:当技能提案器无 Wiki 访问时,平均性能为 48.7%;启用提案器 Wiki 访问后升至 63.7%(+15.0 个百分点)。同时,推理智能体在训练时若有 Wiki 访问,平均性能反而降至 60.9%。这一对照说明持久知识的收益主要来自 “技能开发者” 使用 Wiki,而非 “任务执行者” 直接读取 Wiki。
实践建议
若要在实际系统中落地 WikiSkill 式经验沉淀,可以从以下几点入手。
第一,将原始执行轨迹、结构化知识、可执行技能三者分离。原始轨迹保留完整上下文以备追溯,知识与技能分开管理,可以避免演化过程中的经验散落。论文的三层架构可作为工程模板,但具体目录结构和模式粒度需要根据任务上下文调整。
第二,建立客观的技能影响审计轨迹。WikiSkill 的 skill-impact.md 记录每次提案的差异、验证分数和接受结果,使后续迭代能避开失败方案。工程团队可以借鉴这一机制,将失败的技能修改当作可检索资产,而不是丢弃。
第三,验证门控要与业务指标对齐。论文采用严格 “必须优于历史最优” 的接受准则,排除了中性提案。实践中如果演化预算充分,可以考虑放宽门控,允许中性提案进入技能库并观察长期收益;但需要注意论文作者也指出这是未来方向。
第四,考虑跨模型技能迁移。论文结果显示,在其他模型上演化出的技能有时优于自我演化技能(表 2)。因此在实际部署中,如果自有模型成本高或上下文能力有限,可以用更强模型开发技能,再注入目标模型;但需要测试模型专属 workaround 是否对目标模型产生负迁移,特别是在长上下文或工具预算受限的场景。
第五,注意训练阶段的信息暴露。论文消融显示,让任务执行代理在技能开发阶段直接读取 Wiki 会降低最终技能质量(表 3)。因此在实际构建技能库时,建议将 Wiki 仅提供技能维护与提案阶段,而非推理阶段。