WikiSkill：给 Agent 装一本「永不清空的经验百科」，9B 小模型带技能反超 27B

WikiSkill 把 Agent 的工作区分成三层，职责清晰分离：

① Raw Layer（raw/）：存放每轮训练采样的完整执行轨迹——推理过程、工具调用、最终答案。这一层只写不改，保留原始历史，用于审计和复盘。② Wiki Layer（wiki/）：把原始轨迹整理成结构化、可累积的知识。里面有一个 pattern 目录，每个 pattern 是一份 Markdown 文件，记录一种失败模式或成功策略以及可操作的应对办法；另有 logs.md 记录每轮发现，skill-impact.md 追踪每个提案的 diff、验证分数和接受/拒绝结果。③ Skill Layer（skills/）：放当前生效的技能，每个技能目录含 SKILL.md（技能全文）和 PURPOSE.md（说明这个技能由哪些 wiki 模式催生、经历过什么演化）。

关键设计：技能更新可以被回滚，但 wiki 永不重置。被拒的提案、复发的错误、新的证据全都被保存下来，下一轮提案才能站到完整历史之上。这正是 EvoSkill、Trace2Skill、SkillOpt 等方法缺失的部分——它们的分析结论散落在各自优化记录里，没有形成独立、持续演进的知识表示。

每一轮技能进化由四个组件协作完成：

① 执行 Agent（Inference Agent）：用当前技能在训练集上跑任务，产出不可变轨迹。注意：默认配置下执行 Agent 被禁止读 wiki（原因见第 4 步的消融实验）。② 知识库维护 Agent（Wiki Maintainer）：每轮从训练轨迹里采样最多 8 条（最多 5 条失败的做根因分析、3 条成功的提炼有效策略；单条日志截断到 15000 字符），对照现有 wiki 分析，新增或更新 pattern、修订索引、追加演化日志。③ 技能提案 Agent（Skill Proposer）：以 ReAct 方式自主行动，先读 wiki 索引、技能影响追踪和训练结果摘要，再按需用 read_file 读具体 pattern 页和原始轨迹，诊断根因后给出一个聚焦提案——新建一个技能，或对现有技能做打补丁式的小改动。④ 验证门控与回滚：把候选技能在验证集上跑，只有分数严格超过历史最优才接受为新技能；否则回滚到上一版。被拒的修改只在技能层回滚，wiki 层保留这次尝试的全部记录。

论文用 ALFWorld（交互式家庭任务环境）展示这套机制，模型是 Qwen-3.6-27B：第 0 轮，维护 Agent 发现一个基础循环行为——Agent 拿起物品、检查、放回原处、然后重复。提案 Agent 据此提出 goal-directed-action 技能，验证集上分数没有提升，被拒。关键在 skill-impact.md 保留了这次提案的 diff 和拒绝结论。第 1 轮，提案 Agent 参考这份拒绝历史，创建了更具体的 break-repetition-loop 技能，规则是「不要把物品放回它的原位」，这次被接受。第 2、3 轮没有新技能被接受，但 wiki 持续补充证据：采样里又出现新的循环变体——对同一个物品反复执行操作而不检查是否完成。第 4 轮，提案 Agent 据此给技能加了第二条规则「每种操作对每个物品只做一次」。被拒的尝试、复发的错误、新的证据，最后都成了迭代的基础。

论文用 Gemini-3.5-Flash 做了四组消融：无技能基线 40.4%；只有执行 Agent 读 wiki 45.3%；两边都不读（无知识累积）48.7%；两边都读 60.9%；默认配置（只有提案 Agent 读 wiki）63.7%。两个结论：其一，持久知识库是主要增益来源——提案 Agent 读 wiki 让平均分从 48.7% 升到 63.7%（+15.0 个百分点）；其二，训练时给执行 Agent 开 wiki 反而有害——从 63.7% 降到 60.9%。论文的解释：执行 Agent 同时拿到技能和 wiki 时，部分解题知识直接取自 wiki，生成的轨迹对技能开发的信息量就变小了，反而不利于发现当前技能缺什么。这个「知识库服务于诊断与修复、而非直接回答任务」的边界，是落地时最容易做错的地方。

主结果：WikiSkill 在 5 个基准（LiveMath 数学、SealQA 检索、SpreadSheet 表格、OfficeQA 长文档、ALFWorld 家庭任务）上全面领先最强对比方法，平均分分别高 3.3–12.0 个百分点；且模型越强、技能收益越大（Qwen 家族平均提升从 4B 的 +12.3 涨到 27B 的 +23.9）。反向看，小模型带技能可以追平规模差距：9B 配技能 47.4% 反超 27B 无技能 39.4%。

跨模型迁移实验更有意思：Qwen-27B 炼的技能把 Qwen-9B 在 SpreadSheet 上带到 50.5%（无技能 24.3%、自炼 33.6%）；但负迁移真实存在——Qwen-4B 的技能把 Gemini-Flash 在 SpreadSheet 上从 50.5% 打到 18.1%。原因：4B 技能编码的是低层绕行技巧（单行命令、字符串转换），帮小模型避开执行失败，却束缚了强模型写完整脚本。结论是技能发现和技能执行是两种能力——技能捕获的是通用流程还是模型特定的绕行技巧，决定迁移成败。

WikiSkill 的价值不在「再训练一个模型」，而在架构模式：把执行历史编译成持久知识（分离 Raw/Wiki/Skill 三层）、用门控保证技能可回滚、用「影响追踪」让被拒提案变成后续资产。给你三个落地要点：① 分析成本不随训练任务数增长——提案 Agent 按需读轨迹，每轮固定 1+T 次调用（T 约 10–20），任务从 10 条涨到 1000 条开销基本不变；② 知识层要和执行层分离——给执行 Agent 直接塞 wiki 会降低轨迹信息量；③ 从「自己炼技能」升级到「跨模型用技能」——强模型当老师、便宜模型当执行者，可能是最省钱的生产方式。

论文自认的四个局限也值得记住：① 实验把所有进化出的技能都注入执行 Agent，真实部署需要的检索步骤从未被评估；② 严格验证门控会丢弃「现在中性、以后有用」的提案；③ wiki 无限累积、没有自动剪枝——跑几个月的生产系统里，wiki 可能成为瓶颈；④ 基准时间跨度较短，未覆盖数百环境动作的长程任务。想深入了解技能标准化的基础，可回看Agent Skills 开放标准；想对比「让 Agent 自己造 Agent」的思路，可参考PenguinHarness 自进化。