技能库的膨胀与遗忘

Agent 的能力增长是指数性的。每增加一个 skill，你获得一种新能力。但当技能数量超过你的认知负荷时，收益开始递减。

你开始遇到这些问题：两个 skill 做着相似的事，你不知道该用哪个。一个 skill 引用了已经不存在的工具，但没人注意到。一个实验性的 skill 被丢在角落里，半年后变成了技术债务。

最危险的是：你不再理解自己的系统。它变得像一个你从未完整读过的代码库——庞大、复杂、充满意外。

设计目标：边界，不是无限增长

治理的目标不是把技能数量最大化。而是让每个 workflow 都有边界：知道自己属于哪个领域、承担什么责任、与谁协作、何时退场。

这意味着：

有归属 — 每个 skill 属于一个明确的类别。研究、创作、运维、游戏——不跨界的 skill 更容易维护。

有状态 — 每个 skill 知道自己当前的状态。是稳定运行、实验探索、已归档、还是待清理？

有命名 — 名字是契约。好的命名让人一眼就能判断一个 skill 的用途和边界。

有退场 — 不是每个 skill 都值得永生。实验性的、过时的、被替代的——它们应该有尊严地退出活跃索引。

治理不是一次性整理

技能治理不是某个周末的整理活动。它是一种持续的维护节奏。

• 分类 — 把 skills 归入它们真正所属的类别。不是按创建时间，而是按功能域。
• 索引 — 建立一个可搜索的目录，让人能快速找到需要的功能，而不必逐个目录翻看。
• 审计 — 定期检查每个 skill 的健康状态。它还能运行吗？它的依赖还在吗？它是否与其他 skill 重复？
• 归档 — 把那些不再活跃但仍有历史价值的 skills 从主索引中移除，但保留文件本身。不删除，只是不展示。
• 去重 — 识别功能重叠的 skills，决定保留哪个、合并哪个、废弃哪个。
• 标记 — 用清晰的元数据标记每个 skill 的性质。实验性的、稳定的、子模式的、已废弃的——状态应该一目了然。

人决定哪些能力值得保留

系统可以检测重复、标记异常、生成审计报告。但它不能判断一个 skill 是否有存在的意义。

这个判断需要人的介入。因为一个 skill 的价值不只是功能层面的——它可能承载着某个特定的工作流、某个阶段性的实验、某种你尚未意识到的组合潜力。

脚本告诉你："这个 skill 三个月没被调用过。"你决定："它过时了，归档。"或者："它在等待合适的时机，保留。"

数据提供信号，人做出决定。

产出：一个可理解的系统

治理的最终产物不是一个完美分类的技能库。而是一个可理解的系统。

你能快速找到需要的功能。你能判断一个改动的影响范围。你能识别哪些 skills 是核心资产、哪些是临时实验。你知道系统里有什么、没有什么、正在发生什么。

这不是控制欲。这是可维护性。当系统规模超过你的记忆容量时，可维护性是唯一能让你继续前行的东西。