上一篇我专门聊了一个更具体的话题：一个 Skill 到底该怎么写，才算写得好。
如果按 Anthropic 那份指南的思路，一个“像样的 Skill”大概应该做到这些事：
- frontmatter 写得清楚，知道什么时候该触发
写到这一步，很多人可能会自然觉得：
好，那接下来是不是只要不断多写几个 Skill，系统就会越来越强？
问题恰恰出在这里。
单个 Skill 写好，只是起点。真正的麻烦，往往是当它进入系统之后才开始。
因为一个 Skill 写得越像样，你越会发现，真正难的已经不是“这个 Skill 本身够不够好”，而是：
也就是说，从“写好一个 Skill”到“把一堆 Skill 组织成可用系统”，中间隔着的不是几个格式细节，而是一层完整的工程设计。
这篇我就想顺着这个角度，聊聊一个 Skill 系统真正绕不开的 4 个问题。
1. 第一个问题：怎么发现 Skill
一个 Skill 系统最先要解决的，往往不是“能力够不够多”，而是：
这些能力到底能不能被找到。
这个问题看起来简单，实际上非常基础。
对用户来说，难点是“我不知道该搜什么”
如果一个生态里只有三五个 Skill，事情还不复杂。
但一旦 Skill 的数量上来，用户马上就会碰到一个问题：
不是没有能力，而是不知道该去哪里找，也不知道自己该搜什么关键词。
比如用户想做的是“帮我自动整理竞品网页信息”，
他未必会自然想到自己需要的是：
用户表达的是任务，不是模块名。
而 Skill 系统真正要处理的，就是怎么把“任务表达”映射到“能力入口”。
这也是为什么前面那篇里我会觉得 find-skills 这类 Skill 很有代表性。
它看起来不像一个“主角型”能力，但它解决的是一个很根本的问题：
能力如果找不到，等于没有。
对 Agent 来说，难点是“我不可能把所有 Skill 都记在脑子里”
对系统来说，这个问题会更明显。
一个 Agent 不可能在每次任务开始时，把所有 Skill 的说明文件、使用规则、脚本资源全都塞进上下文。
这不现实，成本也太高。
所以它必须先做一件事：
在当前任务下，先判断哪些 Skill 值得被看到。
这本质上是一个检索/召回问题。
也就是说，Skill 系统首先要有一层能力发现机制：
如果这一步做不好，后面的选择、调用、执行都无从谈起。
所以我会觉得，Skill 系统的第一难题，不是能力不够，而是：
能力找不到。
2. 第二个问题：怎么触发 Skill
发现 Skill 之后，下一步不是立刻调用，而是要先回答另一个更难的问题：
什么时候该触发它？
这件事比看上去复杂得多。
因为在真实场景里，用户给出的从来不是“请调用 Skill A”。
用户给的是一个目标，甚至常常只是一个模糊目标：
而系统要做的，是把这些自然语言目标，路由到合适的 Skill 上。
这中间至少会遇到几个问题。
1. 触发条件怎么定义
一个 Skill 如果要被稳定调用，它的边界就必须尽量清楚。
它适合处理什么任务？
不适合处理什么任务？
什么样的描述算触发信号？
什么情况下又不该触发？
这些东西如果不清楚，系统就很容易出现两种问题：
这也是为什么上一篇里强调 description、read_when 这类触发信息很重要。
它们看起来只是说明，实际上是路由的输入。
因为 Skill 不只是写给人看的，也是写给系统做路由判断的。
2. 多个 Skill 都像能用时，怎么选
现实里更常见的问题是：
不是只有一个 Skill 看起来合适，而是有好几个都“像是能用”。
比如一个任务可能既需要浏览器执行，也需要总结，还可能需要信息提取。
这时候系统面对的不是“有没有 Skill”，而是：
先用哪个，后用哪个，哪个是主路由，哪个只是辅助。
一旦 Skill 多了，这种冲突和重叠几乎是必然的。
所以 Skill 系统一定会走到一个核心问题：
它不是只要“有 Skill”就行，还要有一套路由机制，决定：
3. 有些任务其实不该触发 Skill
还有一个特别容易被忽略的问题是：
并不是每个任务都值得触发 Skill。
有些任务很简单，直接靠模型回答就够了。
如果系统动不动就去加载 Skill、读说明、跑工具，反而会把简单问题复杂化。
所以一个成熟的 Skill 系统，不只是要学会“会调用”，还要学会：
什么时候别调用。
从这个角度看，一个 Skill 是否好用，不只取决于它本身强不强，更取决于：
系统能不能在合适的时候想到它。
3. 第三个问题：怎么控制上下文和成本
如果前两个问题解决的是“看不看得到、会不会用”，那第三个问题解决的就是：
系统扛不扛得住。
Skill 一旦多起来，第三个问题就会立刻浮上来：
上下文怎么管，成本怎么控。
这是一个非常现实的问题。
因为 Skill 不是凭空存在的。
每个 Skill 背后通常都会带着一整套内容：
如果系统每次任务开始时，都把这些东西全量带上，那上下文很快就会爆炸。
结果就是：
于是 Skill 越多，系统不一定越强，反而可能越笨。
真正关键的是：哪些内容常驻，哪些内容按需加载
所以 Skill 系统一定要做的一件事，就是把“看见 Skill”和“加载 Skill”分开。
换句话说：
- 只有当某个 Skill 真的可能被用到时，才去加载它的详细说明、脚本和资源
这背后其实就是上一篇里提到的渐进式披露，放到系统层面的结果。
这也是为什么我一直觉得，Skill 真正有意思的地方，不只是它换了个组织形式，而是它天然适合做成一个“先发现、后装载”的能力系统。
Skill 越多，调度难度也会同步上升
这也是一个很容易被低估的点。
很多人会自然地觉得，Skill 越多，Agent 就越强。
这句话当然有一部分是对的。
但另一半是：
Skill 越多，系统的调度复杂度和上下文管理难度也会同步上升。
所以真正好的 Skill 系统，拼的往往不只是“库存有多大”，而是：
否则最后很容易变成一个“能力很多，但系统越来越重”的怪物。
4. 第四个问题：怎么验证结果和处理失败
前面三个问题解决的是“能不能找到、能不能调用、能不能负担”。
但到了真正落地的时候，还有一个更硬的问题：
调完以后，怎么知道它做得对不对？
这件事比“能调起来”重要得多。
因为在真实系统里，Skill 不是调出来就算结束。
它的结果通常还要进入下一步链路。
而一个 Skill 的结果如果没法被稳定消费，那前面做得再漂亮，也很难真正落地。
1. 输出是不是符合预期
最基础的问题是：
如果一个 Skill 每次产出的结构都飘，那系统后面就会越来越难接。
所以一个 Skill 系统一定会越来越关注“输出约束”这件事。
不是只要能产出内容就够了，而是要尽量让内容可判断、可消费。
2. 失败怎么识别
另一个更难的问题是：
一旦结果不对，系统到底该怎么判断问题出在哪？
是 Skill 本身失败了？
是底层 Tool 失败了？
是模型理解任务时就偏了？
还是页面、网络、权限之类的外部环境出了问题？
如果系统对这些失败没有基本判断能力，那它就很难知道下一步该怎么办。
3. 失败之后怎么恢复
真正成熟的 Skill 系统，最后一定会走到恢复策略上。
比如：
这时候 Skill 系统其实已经越来越像一个真正的执行系统，而不再只是“能力展示层”。
所以我会觉得，Skill 的结果验证和失败恢复，才是真正决定它能不能进生产的一道门槛。
一句话说：
Skill 不是调出来就算结束，真正的系统问题在于：它的结果能不能被后续链路稳定消费。
把这 4 个问题串起来看，Skill 系统真正难的是三件事
如果把前面的四个问题再往上压一层，其实可以总结成三件更大的事：
1. 路由
包括：
2. 装载
包括：
3. 验证
包括：
所以很多人以为 Skill 系统的核心是“有多少 Skill”，但我现在越来越觉得，真正决定可用性的，往往不是库存规模，而是这套路由、装载和验证机制。
换句话说：
Skill 系统真正难的，不是写出多少个 Skill，而是能不能把它们管理成一个稳定工作的能力层。
写在最后
上一篇讲的是：一个好 Skill 应该怎么写。
这一篇更想补上的，是另一个很容易被忽略的事实：
一个 Skill 写好之后，系统层面的难题才刚刚开始。
你会发现，真正决定体验的，往往不再是单个 Skill 本身，而是系统有没有能力回答这些问题：
这些问题不解决，Skill 再多，也很容易只是一个能力仓库。
只有这些问题开始被认真设计，Skill 才有机会从“好玩”走向“可用”。
所以在我看来，从“写出一个好 Skill”到“做出一个好 Skill 系统”，中间差的从来不只是几个说明文件，而是一整套系统设计。
粤ICP备14082021号
免费POC，
零成本试错
