Agent Skill 不是写完就完事：一套进化方法论
很多人写 Agent Skill 的方式是：想清楚流程 → 写 SKILL.md → 跑一次 → 完事。
这跟”写代码不维护”是一个性质的问题。
Skill 是活的东西。它在真实使用中会暴露漏洞，会被新的工具版本淘汰，会因为你踩了坑而需要补流程。同时，外部世界也在不停地产出新的最佳实践、新的技术理念——如果你的 Skill 不从这些地方汲取养分，它就会慢慢变成一个”看起来能用但其实已经过时”的摆设。
这篇文章讲两件事：
- Skill 怎么从实践中迭代（内生进化）
- Skill 怎么从外部知识中生长（外源进化）
以及这两个方向怎么拧成一个闭环。
一、问题：为什么 Skill 会腐烂
先说清楚”腐烂”长什么样。
我见过几种典型的 Skill 衰退模式：
流程过期。 Skill 里写的是”调用 API A，然后调用 API B”，结果 API A 已经升级了，参数变了，甚至被废弃了。Skill 还在教 Agent 走老路。
理念过期。 Skill 里的设计理念是基于某个阶段的技术认知写的。比如一个 RAG Skill 写的是”先召回再重排”，但后来业界已经普遍用 hybrid search + cross-encoder rerank，旧理念虽然不能说错，但已经不是最优解。
流程漏洞。 Skill 写的时候只考虑了 happy path。实际跑起来发现：网络超时了怎么办？返回的数据结构变了怎么办？并发请求冲突了怎么办？这些只有真跑过才知道。
经验没沉淀。 你用了十次这个 Skill，发现其中七次你都要手动干预同一个步骤——这说明这个步骤的设计有问题。但如果你不主动回去改 SKILL.md，第十一次还是会踩同一个坑。
核心原因只有一个：Skill 被当成了文档，而不是代码。 文档写完归档，代码写完要跑测试、要 review、要迭代。Skill 应该是后者。
二、内生进化：从实践中反馈迭代
2.1 什么算”实践反馈”
不是所有使用中的不顺畅都值得改 Skill。我按信号强度分三档：
强信号——必须改：
- Skill 执行失败率高于 20%，且失败原因可归类
- 同一个步骤在多次执行中都需要人工介入修正
- Skill 生成的输出被用户反复要求重写
中信号——应该改：
- 某个步骤在特定场景下是多余的（比如 Skill 写了”先检查权限”，但实际所有调用场景都已经预检了权限）
- 某个参数的默认值在实践中几乎总是需要覆盖
- Skill 引用的外部资源（API、文档链接）已经变更
弱信号——可以改：
- 表述不够清晰导致 Agent 偶尔走偏
- 某些步骤的顺序在实际执行中不够自然
- 缺少一些边界 case 的处理指引
关键是要有一个机制来捕获这些信号，而不是靠感觉。
2.2 怎么捕获：实践日志
最简单有效的办法是给每个 Skill 配一个 CHANGELOG.md，放在 Skill 目录下。每次使用后如果发现问题，记一条。
格式不用复杂：
1 | ## 2026-09-18 |
这跟软件工程的 bug tracking 是一回事。区别在于，Skill 的”bug”不是代码层面的，而是流程设计层面的。
2.3 迭代节奏
不需要每天改。建议的节奏：
周度回顾。 每周花 15 分钟翻一遍本周的 Skill 使用记录，看看有没有中信号以上的问题。有就记到 CHANGELOG。
月度修订。 每月选 1-2 个使用频率最高的 Skill 做一次正式修订。修订不是微调，是重新审视整个 SKILL.md 的结构是否还合理。
季度大改。 每季度做一次全面扫描，重点看：有没有 Skill 已经完全不用了（该删）、有没有 Skill 之间的职责重叠（该合并）、有没有新出现的场景缺 Skill（该建）。
2.4 修订的具体动作
修订 Skill 时，有四种操作：
删。 这是最容易被忽略的。一个步骤如果连续 5 次使用中都没有产生实际作用，删掉它。Skill 不是越多越全越好，是越精确越好。
补。 发现了一个新的失败模式，就在对应步骤后补一个条件分支或前置检查。但注意——补的不是”if-else 堆砌”，而是”为什么要 if，背后的逻辑是什么”的简短说明。
改。 某个步骤的描述不够准确，或者某个理念需要更新。改的时候要在 CHANGELOG 里注明改了什么、为什么改。
合并/拆分。 一个 Skill 承担了太多职责时拆开，两个 Skill 总是一起用时合并。
三、外源进化：从外部知识萃取生长
内生进化解决的是”已有的 Skill 怎么变好”。但还有一类需求：新的知识、新的最佳实践，怎么变成新的 Skill，或者融入已有的 Skill。
这就是外源进化。
3.1 知识来源
不是什么文章都值得萃取。我按质量分三层：
第一层——技术深度文章。 特征：有具体的架构设计、有代码、有性能数据、有踩坑经验。来源：个人技术博客、工程团队的实践分享、会议演讲整理。
第二层——业界最佳实践。 特征：被多个团队验证过、有数据支撑、有对比实验。来源：大厂工程博客（Meta、Google、NVIDIA）、开源项目的 design doc、技术委员会的标准文档。
第三层——技术趋势。 特征：方向性的判断，不一定有具体实现，但能影响你未来的 Skill 设计方向。来源：领域 KOL 的判断、论文综述、行业报告。
第一层是萃取的主战场。第二层用来校准方向。第三层只做参考，不急着动手。
3.2 萃取方法
读文章时，带着三个问题：
问题一：这篇文章解决了什么问题？
不是”这篇文章讲了什么”，而是”它解决的痛点是什么”。因为 Skill 的本质就是解决特定问题的流程。如果一篇文章没有明确的问题定义，它很难萃取成 Skill。
问题二：它的解决方案的核心逻辑是什么？
不是抄步骤，而是理解”为什么要这么做”。比如一篇文章说”用 speculative decoding 加速推理”，核心逻辑不是”加一个 draft model”，而是”用小模型的计算换大模型的延迟，前提是小模型预测准确率够高”。理解了核心逻辑，才能判断这个方法在你的场景下是否适用。
问题三：这个解决方案可以变成 Skill 的哪部分？
三种可能：
- 新 Skill：这是一个全新的能力，现有 Skill 覆盖不了
- 已有 Skill 的增强：这个解决方案能让某个已有 Skill 的某个步骤更高效
- Skill 设计原则的更新：这个解决方案不直接变成 Skill，但它改变了你对”好 Skill”的认知
3.3 萃取到发布的工作流
这是关键——萃取不应该只是”读了、记了、忘了”。应该形成一个完整的产出链：
1 | 读文章 |
最后一步”写成博客文章”不是多余的。它有两个作用：
- 倒逼理解。 你能写出一篇让别人看懂的文章，说明你真的理解了。写不出来说明萃取不到位。
- 建立知识档案。 博客成了你的 Skill 设计知识库。下次设计新 Skill 时可以回溯。
所以外源进化的产出物是双份的：一份 Skill 更新（或新建），一篇博客文章。
四、闭环：内生 + 外源 怎么拧到一起
两条进化路径不是独立运行的。它们之间有交叉点。
交叉点一：外源知识验证内生直觉
你在实践中”感觉”某个步骤应该优化，但不确定怎么优化。这时候读到的外部文章给了你方向。
比如：你发现你的 RAG Skill 在长文档场景下召回质量不稳定，但你不知道是召回策略的问题还是 chunk 策略的问题。这时候读到一篇讲 late chunking 的文章，你一下子明白了——问题不在召回策略，在 chunk 时机。
这就是外源知识帮你定位了内生问题的根因。
交叉点二：内生经验筛选外源知识
反过来，你的实践经验帮你判断外部文章的价值。
一篇文章说”用 ColBERT 做后期交互可以提升检索质量”。但你从实践中知道，你的场景是实时对话，延迟敏感，ColBERT 的开销太大。所以你判断：这篇文章的方案不适合做成 Skill，但它的对比实验数据可以作为参考。
这就是内生经验帮你过滤了外源知识。
闭环模型
1 | 实践使用 Skill |
这个循环转起来，Skill 就不会腐烂。它会在实践中越来越精确，在外部知识中越来越丰富。
五、落地：具体怎么做
讲了一堆方法论，给点可操作的东西。
5.1 给每个 Skill 加两个文件
CHANGELOG.md — 记录内生进化的变更。
1 | # CHANGELOG |
SOURCES.md — 记录外源进化的知识来源。
1 | # 知识来源 |
5.2 定一个萃取节奏
不用天天做。建议：
每周一次知识扫描。 花 30 分钟扫一遍几个固定来源（你关注的博客、arXiv、HN、技术周刊）。看到值得萃取的就记到 SOURCES.md 的”待评估”列表。
每两周一次萃取实践。 从”待评估”列表里选 1-2 篇，做完整萃取：读 → 提炼 → 映射到 Skill → 写博客。
每月一次 Skill 修订。 结合 CHANGELOG 和 SOURCES，做一次正式的 Skill 更新。
5.3 博客文章的定位
萃取产出的博客文章不是”翻译”原文，也不是”读后感”。它应该是**”我是怎么把这个知识变成 Skill 的”**。
文章结构建议：
- 问题是什么——为什么这个知识引起了你的注意（通常是因为实践中的某个痛点）
- 核心逻辑——不是翻译原文，而是用你自己的话解释”它为什么有效”
- 怎么变成 Skill 的——具体怎么改的 SKILL.md，加了什么、删了什么、为什么
- 效果验证——改完之后实际跑了几次，效果怎么样
- 局限和边界——这个方案在什么场景下不适用
这种文章比纯粹的”技术解读”有价值得多，因为它带了实践视角。
六、一些反直觉的判断
最后说几个我在这件事上的观点，可能跟主流认知不一样。
Skill 不是越多越好。 一个有 50 个 Skill 的系统，如果其中 30 个从没被用过第二次，那不是”能力强”，是”噪音大”。定期删 Skill 比定期加 Skill 更重要。
简单 Skill 比复杂 Skill 耐用。 复杂的 Skill 依赖太多外部假设，外部一变它就坏了。简单的 Skill 只描述核心逻辑，把细节交给 Agent 的通用能力。所以写 Skill 时，能少写一步就少写一步。
不要追求”完美”的 Skill。 Skill 的价值在于”比没有强”，不在于”比别人的好”。一个 70 分的 Skill 先跑起来，比花两周打磨一个 90 分的 Skill 更有价值——因为你需要实践来告诉你那 20 分该补在哪。
CHANGELOG 比 SKILL.md 更重要。 SKILL.md 是当前快照，CHANGELOG 是进化轨迹。当你想理解一个 Skill “为什么这么设计”时，CHANGELOG 能告诉你每个决策的来龙去脉。这比读 SKILL.md 本身更有信息量。
FAQ
Q: Skill 进化和代码重构有什么区别？
本质上是同一件事的不同层面。代码重构是”实现层面的进化”，Skill 进化是”流程层面的进化”。区别在于 Skill 描述的是 Agent 的行为流程，不是代码逻辑。所以 Skill 进化的颗粒度更粗，但影响面更大——一个 SKILL.md 的改动可能影响 Agent 在所有场景下的行为。
Q: 怎么判断一个 Skill 该删还是该改？
看使用频率和失败率。如果一个 Skill 连续一个月没被触发过，删。如果一个 Skill 触发率正常但成功率低于 50%，而且你已经修订过两次了，也删——说明这个 Skill 的问题不是细节问题，是整体设计就有问题，不如推倒重来。
Q: 外源萃取会不会变成”抄别人的方案”？
不会，如果你真的带着自己的实践问题去读的话。萃取不是照搬，是”这个外部知识解决了我实践中的什么问题”。同样一篇 FlashAttention 的文章，不同人萃取出来的东西是不一样的，因为他们的实践痛点不同。你的实践经验就是你的过滤器。
Q: 这个方法论本身是不是也是一个 Skill？
算是。它是一个 meta-skill——关于怎么管理 skill 的 skill。所以它自己也应该遵循这套进化逻辑：在实践中学、从外部汲取、持续迭代。如果半年后回头看这篇文章觉得哪里不对了，那就对了——说明它也在进化。