Skill 越装越多，Agent 为什么却越来越不好用？
Skill 能让 Agent 固化工作流程，但数量增加不等于能力线性增长。本文从渐进加载机制出发，分析路由冲突、规则碰撞、上下文成本和维护债务，并给出六项治理方法。
摘要：Skill 能让 Agent 掌握固定流程，但数量增加并不等于能力线性增长。真正影响体验的，往往是技能边界重叠、触发描述含糊、指令冲突和缺少评测。本文从 Skill 的加载机制出发，解释问题为什么发生，以及应该如何治理。
你可能遇到过这种情况：
Agent 刚安装几个 Skill 时，表现明显变好了。它知道如何写技术文章、检查代码、生成配图，也能按照固定流程发布内容。
但继续安装以后，体验却开始下降：有时选错 Skill，有时一次触发好几个流程，有时明明只是改一段文字，却先读取大量说明，最后还被互相矛盾的规则卡住。
这并不意味着 Skill 越少越好。
更准确的结论是：Skill 的数量不是主要问题，技能之间缺少清晰边界，才是 Agent 变得不好用的根源。
Skill 不是插件按钮，而是一套可被调用的工作方法
Skill 可以理解为给 Agent 准备的一份“岗位操作手册”。它通常包含任务说明、执行步骤、参考资料和可选脚本，用来把一次成功经验固化成可复用流程。
例如，同一个 Agent 可以安装这些 Skill：
- 技术文章写作
- 文章配图生成
- 公众号发布
- 代码审查
- 故障复盘
每个 Skill 单独看都很有价值。问题出现在 Agent 收到一个请求后，还要先完成另一项任务：应该调用哪一个 Skill？
Skill 越多，这一步越像一个不断扩大的路由系统。
Agent 并不会一开始就读取所有 Skill
很多人以为，安装一百个 Skill，就会把一百份完整说明全部塞进模型上下文。至少在当前 Codex 的机制中，实际情况并非如此。
官方文档说明，Skill 使用渐进披露机制：系统起初只提供技能的名称和描述；当某个 Skill 被选中后，才读取完整的 SKILL.md。
初始 Skill 列表还有上下文预算：最多占模型上下文窗口的 2%；无法确定窗口大小时，使用 8000 个字符作为上限。如果安装数量太多，Codex 会先缩短描述；规模继续扩大时，还可能省略部分 Skill 并给出警告。
这说明两件事：
第一，安装 Skill 不会必然造成上下文按数量线性膨胀。
第二，Skill 越多，Agent 越依赖那段简短的名称和描述做出正确选择。
从整个系统看，失控通常集中在四个位置：选错入口、规则冲突、上下文承压，以及长期积累的维护债务。下面逐一展开。
第一个问题：描述相似，Agent 很容易选错
假设系统里有三个 Skill：
- “用于编写技术文章”
- “用于优化公众号文章”
- “用于生成并发布技术内容”
当用户说“帮我整理一篇技术文章”时，三个描述都可能匹配。
Agent 可能只选中其中一个，也可能同时加载多个。选择结果还会受到用户措辞、上下文以及描述被缩短后的内容影响。
这不是模型突然变笨了，而是路由规则没有给出足够清楚的边界。就像一家公司的三个部门都写着“负责内容”，转交工单时自然容易出错。
第二个问题：多个 Skill 的规则可能互相冲突
不同 Skill 往往不只提供知识，还会规定执行流程。
一个 Skill 要求先搜索资料再写作，另一个要求先生成提纲；一个要求完整输出 Markdown，另一个要求直接生成 HTML；一个允许自动发布草稿，另一个要求发布前必须确认。
这些规则各自在自己的场景里可能都是合理的。一旦同时命中，Agent 就必须继续判断优先级。如果规则没有说明适用范围，结果可能是流程变长、重复执行，甚至原地等待。
所以 Skill 的冲突，本质上不是“知识太多”，而是多套操作规范在争夺同一个任务的控制权。
第三个问题：命中以后，上下文仍然会膨胀
渐进加载解决的是“不要提前读取全部 Skill”，并没有消除被选中后的成本。
当一个 Skill 被激活，Agent 会读取完整说明；如果说明继续引用多份文档、模板和检查清单，这些内容还会进一步进入工作上下文。
一个请求误触发三个大型 Skill，就可能出现：
- 有效任务信息被大量流程说明稀释
- Agent 花更多时间协调规则，而不是解决问题
- 对话变长以后，早期约束更容易被压缩
- 工具调用次数和执行时间增加
因此，SKILL.md 并不是越长越专业。它更适合作为一张清晰的路线图：告诉 Agent 何时使用、先做什么、需要时再读取哪份资料。
第四个问题：Skill 也会产生维护债务
Skill 不是安装完成就永远正确的静态文件。
接口会更新，工具会变化，业务流程也会调整。如果团队不断添加新 Skill，却不清理旧版本，就可能同时保留两套过期规则。Agent 未必知道哪一套才是当前标准。
更隐蔽的问题是：某个 Skill 单独测试没有问题，不代表它和其他 Skill 一起出现时仍然稳定。
随着数量增加，需要评测的不只是“这个 Skill 能不能完成任务”，还包括：
- 应该触发时，是否真的触发
- 不应该触发时，是否保持安静
- 与相邻 Skill 同时存在时，是否会选错
- 描述被缩短后，关键触发条件是否还在
- 多个 Skill 同时命中时，规则能否兼容
如果没有这些测试，Skill 库越大，行为就越难预测。
解决办法不是少装，而是治理
一个稳定的 Skill 体系，可以从下面六件事开始。
1. 按任务边界划分，而不是按关键词划分
“文章”“图片”“代码”只是对象，不是完整边界。
更好的划分方式是明确输入、结果和责任。例如，“将技术素材写成公众号 Markdown”和“将已确认的 HTML 发布为公众号草稿”，就是两个容易判断的任务。
2. 把描述当成路由规则来写
描述至少要回答三个问题：
- 什么请求应该使用它
- 它负责完成到哪一步
- 哪些相似任务不属于它
关键触发条件应放在描述前面。因为 Skill 很多时，描述可能被缩短，写在末尾的重要边界未必还能保留。
3. 让完整说明保持短而明确
核心文件只保留必须遵守的流程、判断条件和安全边界。大段教程、模板和案例放进引用资料，需要时再读取。
这能减少单次激活的上下文成本，也能降低规则冲突的概率。
4. 重要流程尽量显式调用
对发布、部署、数据修改等结果敏感的任务，不要完全依赖自动匹配。明确指定 Skill，可以降低路由的不确定性，也方便追踪本次任务使用了哪套流程。
5. 给 Skill 建立触发评测
每个 Skill 至少准备三类样例：应该触发、不应该触发、容易与相邻 Skill 混淆。
每次新增或修改 Skill 后，重新跑一遍这些样例。评测目标不是证明它“偶尔能用”，而是确认它能稳定地在正确场景出现。
6. 定期合并、废弃和改名
高度重叠的 Skill 应合并；已经被新流程替代的 Skill 应退出；名称过于宽泛的 Skill 应重新命名。
Skill 库应该像代码库一样维护，而不是像浏览器收藏夹一样只进不出。
怎样判断是不是已经装得太多？
不要只看 Skill 总数，可以观察下面几个信号：
- 同一句请求经常触发不同 Skill
- Agent 频繁读取与任务无关的说明
- 一个简单任务也要协调多套流程
- 新增 Skill 后，旧任务的成功率反而下降
- 团队成员说不清相邻 Skill 的区别
- 已经没人知道哪些 Skill 仍在使用
出现两三个信号时，应该做的不是继续补充提示词，而是重新检查分类、描述和评测。
最后
Skill 的价值，是把经验变成 Agent 可以重复执行的工作方法。它让 Agent 更专业，但不会自动让系统更有秩序。
Skill 少的时候，模糊边界还不明显；Skill 多起来以后，路由冲突、规则碰撞、上下文成本和维护债务会被一起放大。
因此，真正值得追求的不是“我装了多少 Skill”，而是：
- 每个 Skill 是否有清晰边界
- Agent 是否能稳定选中正确 Skill
- 多个 Skill 是否能够协同而不冲突
- 整套系统是否可以持续评测和清理
好的 Agent，不是会调用最多的 Skill，而是在正确的时候，只调用真正需要的 Skill。