过去一段时间，如果你持续关注 Agent 相关的产品、框架和讨论，应该会发现一个变化：
大家讨论的重点，正在慢慢从“模型够不够强”，转向另一个更具体的问题：
AI 到底该怎么组织能力，才能真正把事情做完。
光有模型不够，这件事大家已经越来越有共识。
于是我们给它接上搜索、浏览器、代码执行、数据库、文件系统、外部 API。
看起来能力越来越强，系统也越来越像“会干活”了。
但真正把这些东西接起来后，问题很快就出现了。
很多 Agent 不是不会调用工具，而是不能稳定地完成任务。
给它 10 个工具，不等于它就拥有了 10 种能力。
更多时候，它只是“有很多动作可以做”，却不知道什么时候该做哪一个、做完之后怎么接下一步、失败之后又该怎么处理。
于是，很多团队都会走到一个很熟悉的阶段：
Prompt 越写越长，规则越补越多，工具越挂越全，系统却没有变得更可靠，反而越来越臃肿、越来越贵，也越来越难维护。
也正是在这个过程中，我开始频繁注意到一个词：Skill。
一开始我也以为，这可能只是 Agent 圈又一个新术语。
但看得越多，我越觉得，它不是在做“概念加法”，而是在补 AI 应用里一个长期缺失的层：
我们一直在给 AI 加模型、加工具，却没有认真解决“能力该怎么被组织”这件事。
AI 应用今天卡在哪里
这两年，大家其实先后经历了两个阶段。
第一个阶段，是确认了一件事：大模型确实能做很多过去做不了的事。
写作、问答、翻译、总结、代码、检索、规划，能力上限一次次被抬高。
于是很自然地，很多人会觉得，只要模型继续变强，AI 应用落地就是时间问题。
但真正做过一段时间后，你会发现，事情没那么简单。
今天很多 AI 应用真正卡住的地方，往往不是“模型还不够聪明”，而是系统并没有把这些能力组织好。
1. 模型会的多，但不一定稳
大模型的强项，是它很会“理解任务”。
你给它一个目标，它通常能说出一个看起来很合理的方案，甚至把步骤拆得头头是道。
问题在于，会描述任务，不等于能稳定完成任务。
一旦任务从单轮问答变成多步骤执行，问题就开始出现了。
它可能第一步判断对了，第二步选错工具；也可能前面都做得不错，最后在一个细节上偏掉；更常见的是，它大概知道该怎么做，但整个执行过程不够稳，一遇到异常就乱。
这也是为什么很多 Agent Demo 看起来很惊艳，但一放到持续使用的真实环境里，效果就开始飘。
2. Tools 给得越多，不代表系统能力越强
于是大家想到的第二步，通常是给模型接更多工具。
浏览器、搜索、代码执行、文件系统、数据库、外部 API……这些工具接上之后，Agent 的动作空间确实大了很多。它不再只是“说”，而是开始“做”。
但这里有一个很容易被忽略的问题：
工具只是动作，不是能力。
给一个系统十几个 Tool，并不意味着它就自动拥有了十几种稳定能力。
因为“能力”从来不只是某个动作本身，还包括：
- 什么情况下该调用它
- 调用之前要准备什么上下文
- 调用之后如何判断结果对不对
- 如果失败了，下一步该怎么补救
这些东西，单靠 Tool 本身是不会自动出现的。
很多 Agent 项目最后都会变成这样：
工具越来越多，定义越来越全，但系统并没有越来越可靠，反而更像“拿着一整箱工具，却不知道先拧哪颗螺丝”。
3. Prompt 越写越长，但收益越来越低
再往后，很多团队会进入第三个阶段：
既然模型不稳定、工具不会组织，那就继续怼 Prompt。
于是 system prompt 越来越长，里面塞满了各种内容：
任务目标、使用规则、工具说明、注意事项、边界条件、失败兜底、业务背景、示例流程等等
刚开始，这样做通常是有效的。
因为很多问题，确实可以靠更明确的指令缓解。
但 Prompt 一旦膨胀到一定程度，副作用就会越来越明显。
第一是成本上升。上下文变长，调用变贵。
第二是注意力分散。信息越多，模型越不容易能稳定抓住重点。
第三是维护困难。每加一条规则，都是在给整个系统在打一层补丁，屎山可能就这样越堆越高。
最后你会发现，系统越来越像一个被各种说明文档和补丁缠住的装置。
它不是不能跑，而是越跑越笨、越跑越重。
所以今天很多 AI 应用的瓶颈，本质上并不在“能力缺失”，而在于：
我们已经有了不少能力模块，却还没有找到一种足够好的方式，把它们组织成一个真正可复用、可维护、可扩展的系统。
Skill 到底在补什么
也正是在这个背景下，Skill 这件事开始变得值得关注。
我现在越来越倾向于把它理解成：
Skill 不是在替代 Tool，也不是在替代 Prompt，而是在补一层长期缺失的“能力组织层”。
Prompt -> Tool -> Skill
如果用最简单的话来区分：
- Tool 解决的是“你能做什么动作”
- Prompt 解决的是“你先记住哪些规则和背景”
- Skill 解决的是“遇到某类任务时，你该如何组织这些动作、规则和资源，把事情做完”
这三者并不冲突，但解决的问题完全不同。
Tool 像工具，Skill 像能力包
一个 Tool 像是一把扳手、一把螺丝刀。
它很好，也很必要，但它只负责一件事：把某个动作做出来。
而一个 Skill，则更像是一整套可以反复调用的作业包。
里面通常不只有动作本身，还会包含：
- 任务说明
- 使用步骤
- 调用条件
- 脚本或模板
- 所需资源
- 输出约束
- 失败处理方式
换句话说，Skill 不是“多一个工具”，而是把某一类任务处理经验，封装成一个可以被按需调用的模块。
这件事的意义很大。
因为现实中的很多工作，本来就不是一个单动作能完成的。
它们更像是一串相互依赖的小步骤：先判断，再检索，再处理，再验证，最后输出。
如果没有一层机制把这些东西组织起来，系统就只能反复依赖模型临场发挥。
而临场发挥这件事，在 Demo 里很好看，在工程里通常不够稳。
Skill 的价值，在于把“经验”变成系统的一部分
过去做 Agent，经常会有一种感觉：
系统看起来拥有很多能力，但每次做任务，都像从零开始临时组织。
今天它也许能做对，明天换个表述、换个上下文、换个任务顺序，就未必还能做对。
这说明系统缺的，不只是功能，而是可复用的处理经验。
而 Skill 恰恰是在做这件事。
它不是让模型“自己猜”这类任务应该怎么做，而是把已有的经验、流程、脚本、资源，整理成一个可以重复使用的能力模块。
下次再遇到类似任务时，不需要重新在 Prompt 里从头交代，也不需要完全依赖模型自由发挥，而是可以直接调用对应的 Skill 去处理。
从这个角度看，Skill 最重要的贡献，其实不是增加了多少新能力，而是提高了已有能力的复用性、稳定性和可维护性。
Skill 在补的，是 Agent 从“能试”到“能用”的那一层
很多 AI 系统今天已经具备“试试看”的能力了。
你给它一个任务，它也许能成功，也许不能；今天行，明天未必行；简单任务做得还不错，复杂一点就开始漂。
这说明它已经有了一定能力，但距离“能用”还差一层。
而 Skill 补的，恰恰就是这层东西：
- 不只有动作，而且有组织的动作
- 不只有知识，而是可调用的经验
- 不只是一次性的跑通，而是可重复的完成
所以我会觉得，Skill 真正有意思的地方，在于它提醒了我们一件事：
AI 应用真正要走向落地，不能只靠更强的模型，也不能只靠更多工具，还需要一套更像“工作方法”的能力组织机制。
为什么现在 Skill 这件事值得关注
如果 Skill 只是换了个名字，把过去那些 Prompt、脚本、流程重新打包一遍，那它其实没有太大意义。
但我之所以觉得它值得认真看，是因为它确实解决了当前 AI 应用里几个非常现实的问题。
1. 它部分解决了上下文不断膨胀的问题
过去一段时间，我们有一种很自然的做法：
凡是系统需要知道的，都尽量往 Prompt 里塞。
这在早期是合理的，因为 Prompt 是最直接、最方便的控制手段。
但随着任务复杂度上升，这种方式的问题越来越明显。
系统需要知道的东西太多了，规则、范例、工具说明、边界条件、补充知识，全都堆在一起，最后上下文越来越长，成本越来越高，模型注意力也越来越分散。
Skill 提供了另一种思路：
不是所有知识都要常驻在上下文里，而是可以按需加载。
也就是说，系统平时只保留一个较轻的状态；真正遇到某类任务时，再去加载对应的 Skill，把相关指令、脚本和资源引进来。
这背后的意义不只是省 token。
更重要的是，它让整个系统从“全量加载”变成了“根据任务动态展开”，从而提升复杂 Agent 的可扩展性。
2. 它让能力变得可复用了
今天很多 AI 应用开发，仍然带有很强的一次性特征。
你做一个合同审查助手，就为它单独写一套 Prompt；
你再做一个文档解析流程，又重写一套；
下次换个业务场景，很多东西又得从头再来。
这当然不是不能做，但复用效率很低。
而且时间一长，你会发现系统里积累了大量“只在某个项目里活着”的隐性经验，很难迁移，也很难共享。
Skill 的一个重要价值，就是把这些经验从“散落在 Prompt、代码和人脑里”，变成一个可分发、可复用、可迭代的能力单元。
这不仅对单个 Agent 有帮助，对团队协作也一样重要。
因为从工程角度看，可复用的能力模块，远比一次性 Prompt 更接近真正能沉淀资产的方式。
3. 它让 Agent 更接近工程系统
很多人第一次接触 Agent，容易把它理解成“会调用工具的大模型”。
这个理解不算错，但不够全。
因为“会调用工具”只是表面，真正关键的是：
它能不能在复杂任务里，持续、稳定地组织这些能力，最终完成目标。
这背后其实更像工程系统，而不只是对话系统。
而作为系统设计人员需要考虑的是以下几点：
- 它的任务边界是什么
- 它该如何触发某种能力
- 它的输入输出如何约束
- 它失败后如何恢复
- 它的行为怎么验证和评估
Skill 的出现，某种程度上就是在推动这件事。
它把原本零散的能力调用，往更工程化的组织方式上推了一步。
所以我觉得，Skill 的价值不在“新鲜”，而在“方向正确”。
它是在把 Agent 从“能演示”往“能交付”上推。
4. 它可能引起 AI 应用竞争方式的改变
如果把时间线再往前看一点，会发现过去 AI 产品的竞争逻辑，主要集中在几件事上：
- 模型强不强
- 上下文长不长
- Tool 多不多
- Demo 惊不惊艳
但如果 AI 应用真的继续往实际工作场景里走，竞争点很可能会逐渐变化。
未来拼的也许不只是“谁的模型更聪明”，而是：
- 谁更会组织能力
- 谁更会沉淀经验
- 谁能把复杂任务拆成可复用、可验证的模块
- 谁能把系统做得既灵活又稳定
从这个角度看，Skill 值得关注，是因为它触及了一个很核心的问题：
模型决定的是能力上限，但像 Skill 这样的组织层，决定的更像是系统到底能不能被真正用起来。
为什么我打算系统写这个方向
也正因为上面这些原因，我决定接下来把 Skill 这个方向系统地写一组文章。
一方面，是因为它足够具体。
相比泛泛去聊“Agent 很重要”“AI 会改变工作方式”，Skill 更容易落到真实的工程问题上。
它不是一个空概念，而是一个可以具体讨论设计、调用、成本、稳定性和边界的话题。
另一方面，它又不只是一个局部技术点。
如果你顺着 Skill 往下看，会慢慢碰到很多更大的问题：
- AI 应用里的能力到底该怎么组织
- Tool 和 Prompt 的边界在哪里
- 为什么很多 Agent 做到后面越来越重、越来越脆
- 一个系统要从“会一点”变成“能稳定干活”，中间到底缺了什么
这些问题，本身就是我接下来最想持续写的方向：
AI 应用落地。
所以后面几篇，我会沿着这个线索继续往下写。
我会先从更容易感知的部分切进去，比如看一看 clawhub 上最火的几个 Skill，到底为什么火；
再往后，会讲清 Skill、Tool、Prompt 之间到底有什么区别；
然后再往工程层面走，看看一个 Skill 系统真正要解决哪些问题，以及为什么很多看起来很强的 Skill，实际却很难落地。
我希望这组文章最后讨论清楚的，不只是某个项目、某种框架，或者某个新概念。
我更想讨论的是：
当我们开始认真做 AI 应用时，到底该用什么方式，把这些零散能力组织成一个真正可用的系统。
如果你也关注 Agent、模型选型和 AI 应用落地，欢迎关注「算法工程笔记」。这里尽量少讲热闹，多讲判断。
