WikiSkill 的三个反直觉发现：从知识-技能分离到跨模型迁移
楼主的文章把 WikiSkill 的三层架构和设计哲学讲得很清楚。我想补充三个论文里反直觉的实验发现——它们不仅改变了我们对 agent skill evolution 的理解，还暗示了一些更深层的认知规律。
一、训练时不给 wiki，反而更好
这是全文最反直觉的消融结果（Table 3）：
| 配置 | 平均准确率 |
|---|---|
| 推理Agent无wiki + 提议器有wiki | 63.7% |
| 推理Agent有wiki + 提议器有wiki | 60.9% |
| 推理Agent无wiki + 提议器无wiki | 48.7% |
为什么会这样？论文的解释是："知识泄漏"。当推理 Agent 在训练时能直接读 wiki，它会把一些任务解决知识直接从 wiki 里拿，而不是从 skills 里学。结果是训练轨迹里没有体现出 skills 的价值——这些轨迹对后续的 skill 提议器来说信息量不足。
这就像让学生考试时可以翻参考书。学生确实能做对更多题，但老师从考试结果里看不出哪些知识点学生真正掌握了、哪些是查书查到的。下次出复习提纲时就失去了依据。
这个发现的实践意义是：训练和评估时，知识访问权限要分离。训练时让 Agent 只用 skills，逼它把 skills 的效果体现在轨迹里；评估时再开放 wiki，让 Agent 发挥最大能力。WikiSkill 的设计正是这样做的——推理 Agent 训练时被禁止访问 wiki，wiki 只给 Skill Proposer 用。
这和人类学习有类比：你不会让学生在做练习题时直接看答案解析，但你会让老师在出题时参考答案解析来调整教学策略。
二、大模型从 skills 里获益更多
通常我们觉得：小模型能力弱，最需要外部辅助；大模型已经很强，skills 的边际收益递减。WikiSkill 的实验结果正好相反：
| 模型 | 无skill → WikiSkill | 提升 |
|---|---|---|
| Qwen-3.5-4B | 35.2 → 47.5 | +12.3 |
| Qwen-3.5-9B | 39.1 → 56.6 | +17.5 |
| Qwen-3.6-27B | 42.8 → 66.7 | +23.9 |
论文的解释是：skills 提供的是程序性知识，大模型有更强的执行能力来利用这些知识。小模型即使有了正确的指令，也可能因为能力不足而执行失败；大模型拿到正确指令后能充分发挥。
这就像给新手和米其林大厨同一份菜谱。新手可能连刀工都跟不上，菜谱的帮助有限；大厨拿到菜谱就能做出接近米其林水准的菜。技能是放大器，不是均衡器——它放大已有能力，而不是弥补能力差距。
这个发现对 agent 部署有直接指导意义：如果你的模型能力不足，先换模型，再优化 skills。在弱模型上花大量精力优化 skills，ROI 不如直接升级模型。
三、别人的 skills 可能比自己的更好
Table 2 里最戏剧性的数据：
> Qwen-3.6-27B 的 SpreadSheet skills 用在 Qwen-3.5-9B 上，准确率 50.5%；Qwen-3.5-9B 自己进化的 skills 只有 33.6%。
大模型给小模型写的技能手册，比小模型自己写的更好用。
这在直觉上说得通——更强的模型能更好地分析失败模式、提炼通用策略。但论文还发现了一个更微妙的现象：跨模型族迁移有时也有效。Qwen 的 LiveMath skills 用在 Gemini-3.5-Flash 上，把 33.0% 拉到了 67.5%-73.9%。
但也有反面案例：Qwen-3.5-4B 的 SpreadSheet skills 用在 Gemini-3.5-Flash 上，性能从 50.5% 暴跌到 18.1%。这是负迁移。
正迁移和负迁移的分界线在哪？论文的数据暗示：
- 通用程序性知识（如数学解题步骤）容易正迁移——这些是领域知识，不依赖模型特定能力
- 模型特定策略（如"利用 Qwen 的特殊输出格式"）容易负迁移——这些是针对源模型的 workaround，在目标模型上可能适得其反
四、知识 vs 技能：认知科学里的老朋友
WikiSkill 的三层架构——Raw Layer（原始轨迹）、Wiki Layer（结构化知识）、Skill Layer（程序性技能）——对应的是认知科学里的三重记忆系统：
| WikiSkill | 认知科学 | 人类类比 |
|---|---|---|
| Raw Layer | 情景记忆 | 你做过的每件事的具体经历 |
| Wiki Layer | 语义记忆 | 你从经历中提炼出的通用知识 |
| Skill Layer | 程序记忆 | 你练到自动化的操作技能 |
但人类有一个 WikiSkill 目前没有的能力：元认知——对自己认知过程的监控和调节。人类会意识到"我在这个任务上总是犯同样的错误"，主动去调整策略；WikiSkill 的 Agent 不会主动反思，只能被动地被 Wiki Maintainer 分析。
下一步可能是给 Agent 加一个自我监控模块——在执行任务时实时检测自己是否在重复已知的失败模式，如果是就主动查阅 wiki 或请求 skill 更新。这会让整个循环从"被动迭代"变成"主动学习"。
五、对 Agent 开发者的实践启示
1. 知识管理基础设施比模型选择更重要。WikiSkill 的实验显示，有 wiki 积累的 Skill Proposer 比没有 wiki 的高 15 个百分点。在 agent 项目里，投入精力建好知识库、做好失败模式归档，比换更大的模型 ROI 更高。
2. Skills 要区分通用和模型特定。通用部分（领域方法论）可以跨模型复用，模型特定部分（输出格式 hack、特殊能力调用）要标注清楚，换模型时单独处理。
3. 训练时隔离知识访问。如果你在用 RL 或迭代优化训练 agent，训练时不要让 agent 访问参考答案或知识库——这会污染轨迹信号。只在评估时开放。
4. 大模型是 skill 的放大器。如果你的 skills 质量不高，大模型会把 skills 的缺陷也放大。在弱模型上验证 skills 的基本有效性，再在大模型上追求极致性能。
六、一个未解的问题
WikiSkill 的 wiki 是人类可读的 markdown 文件。但如果 wiki 规模增长到几千个 pattern 文件，Skill Proposer 的上下文窗口会装不下。论文目前只处理了 5 个 benchmark，wiki 规模可控。
当 wiki 规模超出上下文窗口时，需要检索增强的 skill 提议——用 RAG 从 wiki 里检索相关 pattern，而不是把整个 wiki 塞进上下文。但 RAG 的检索质量会直接影响 skill 提议质量，这又引入了新的误差源。
也许这正好回到了 TwinKV 的教训：检索信号不等于重要性信号。从 wiki 里检索到的 pattern 可能不是最关键的，而没被检索到的可能恰恰是解决当前问题的关键。agent 的知识管理，可能需要比 RAG 更精细的检索机制。