Hugging Face Daily Papers 在 8 月 28 日收录了 Google 的新论文 WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution，arXiv 页面显示该论文 2026 年 8 月 27 日提交。论文的摘要很清楚：agent skills 可以把专门知识和工作流封装成可复用资源，但自动发现技能的过程往往把关键洞察散落在优化历史里，难以跨迭代复用。WikiSkill 的做法是让技能和一个持久 wiki 共同进化，把原始执行经验、累计知识和可执行技能分开管理。参考来源：arXiv 论文页、Hugging Face 论文页。
这篇论文值得关注，因为它击中了当前 agent 工程的一个真实瓶颈：我们已经开始让 agent 长时间做任务、反复尝试、生成大量轨迹，但大多数系统只会把轨迹作为日志保存。日志能复盘，却很难自动变成下一次更好的行为。WikiSkill 试图补上中间层：把轨迹里的经验编译成结构化、可读、可维护的知识，再从知识生成或更新技能。
问题背景
过去一年，技能化 agent 成为很强的工程趋势。一个技能通常包含任务说明、工具使用方法、示例、边界条件和失败处理。相比把所有知识塞进系统提示，技能有两个优势：可以按需加载，也可以版本化维护。
但自动技能进化仍然粗糙。一个 agent 完成任务后，我们能拿到完整轨迹：它试了哪些命令，调用了哪些工具，在哪里失败，最终如何修正。问题是，这些轨迹通常太长、太噪、太局部。下一轮要更新技能时，优化器可能只看到最近几条成功或失败样本，很难形成稳定的原则。
WikiSkill 的核心判断是：技能进化需要一个持久知识层。这个 wiki 不是聊天记忆，也不是向量库里的松散片段，而是围绕任务、失败模式、工具约束、可复用策略组织的经验仓库。
三层分离
论文中的关键设计可以概括成三层。
第一层是原始经验。它保存 agent 与环境交互的轨迹，包括任务、动作、观察、成功信号、失败信号和最终产物。原始经验不直接进入技能，因为它太长，也包含大量偶然细节。
第二层是持久 wiki。系统从原始经验中抽取可复用知识，例如“某类任务中先检查 schema 再写 SQL 更稳定”、“某个工具返回空结果时应改用精确 ID 查询”、“长任务中间态需要写到文件而不是只放在上下文里”。这些知识应该有来源、置信度和适用范围。
第三层是可执行技能。技能面向 agent 主机，是运行时会被加载的材料。它比 wiki 更精炼，包含明确步骤、工具约束、输入输出格式和反例。
这三层分开之后，系统不必在每次任务后立刻改技能。它可以先积累 wiki，等证据足够时再更新技能。这样能减少单次偶然成功污染技能的风险。
实验结论怎么看
论文摘要报告了几个有工程价值的结论。
第一，WikiSkill 在多个 benchmark 和模型上超过已有技能进化方法，并且多数设置下优于无技能 baseline。这说明“持久知识中间层”不是只增加复杂度，而可能带来稳定收益。
第二，技能进化和模型规模互补。较大模型通常能更好地利用进化技能；同时，小模型配合好技能也可能超过更大但没有技能的模型。这个结论对成本敏感团队很重要，因为它提示我们不要只把预算押在更贵模型上。对高频、可流程化任务，维护技能可能比无限升级模型更划算。
第三，技能可以跨模型和模型家族迁移，甚至“其他模型进化出的技能”可能超过自我进化技能。这个结论很有意思：技能开始像组织知识资产，而不是某个模型的私有缓存。只要技能写得足够清晰、证据足够扎实，它就能跟随团队跨模型迁移。
第四，消融实验强调 wiki 的持久知识积累是关键。也就是说，效果并不是单纯来自“多写一段 prompt”，而是来自经验被系统化整理后反复复用。
和现有记忆系统的差别
很多 agent 平台已经有 memory，但 WikiSkill 的方向更接近“工程知识库”。普通 memory 可能记录用户偏好、项目背景、历史对话和事实片段。WikiSkill 关心的是：哪些经验可以改变下一次执行策略。
举例来说，普通 memory 可能记住“这个项目使用 pnpm”。WikiSkill 式知识会写成：“在该项目中新增 MDX 文章后，必须先运行标签 lint，再运行 Astro check；失败常见原因是正文裸写小于号或标签含特殊字符。”前者是事实，后者是可执行经验。
这个区别决定了存储结构。WikiSkill 不应该只是向量检索。它需要条目类型、来源轨迹、适用条件、失效条件、版本和审核状态。否则 wiki 会变成另一堆难以信任的文本。
工程落地建议
如果要把 WikiSkill 思路搬进生产系统，可以先做一个很小的版本。
每次 agent 任务结束后，记录四件事：任务类型、失败点、修复动作、最终是否通过验证。只有通过验证的任务才允许进入候选经验池。然后用一个离线任务把候选经验整理成 wiki 条目，但不要自动发布为技能。
wiki 条目可以长这样：
id: mdx-angle-bracket-check
scope: astro-mdx-blog
evidence_runs:
- run_2026_08_29_0142
lesson: "正文中的小于号必须转义为 <，代码块除外。"
applies_when:
- "writing MDX article"
- "plain text contains comparison symbols"
skill_patch:
- "Before final check, scan new files with grep for raw angle patterns."
status: reviewed发布技能时，再从已审核 wiki 条目生成 SKILL.md 或局部规则。这一步最好有人审。原因很简单：agent 的成功经验不一定是真因，失败修复也可能只是碰巧通过当前测试。
论文的局限
WikiSkill 方向很强，但落地仍有几个开放问题。
第一，wiki 写入质量如何保证。错误经验一旦进入持久层，会被多次复用，污染范围比一次 prompt 错误更大。
第二，技能迁移的边界在哪里。跨模型迁移有效不等于跨工具、跨组织、跨权限环境都有效。很多技能隐含了运行时假设，例如文件系统权限、工具输出格式、模型上下文长度。
第三，技能更新和安全审计如何结合。一个能够自我进化技能的系统，也可能把临时绕过策略固化成“最佳实践”。生产系统必须把授权、审计和回滚放在技能发布链路里。
总结
WikiSkill 的贡献不是又提出一个更复杂的 agent memory 名字，而是把“经验如何变成组织能力”这件事拆开了：轨迹负责保存事实，wiki 负责沉淀可复用知识，技能负责指导运行时行为。对开发者来说，最值得借鉴的是这个分层，而不是具体 benchmark 分数。
未来的 agent 团队可能会像维护代码库一样维护技能库：有评审、有版本、有测试、有 changelog，也有弃用策略。WikiSkill 这篇论文说明，技能不是 prompt 的附属品，而可能成为模型之外最重要的能力资产。