求求了，别再吹 Skills 了 --知识铺

Claude Skills[1] 出来一段时间了，落地的东西没怎么见到，光看自媒体狂欢了。一会儿是“新 AI 范式”了，一会儿又“颠覆 Agent 开发”啦。

Skills 真的没什么新东西，核心就是将 Prompt（通过 SKILL.md）与 Tool（脚本代码形式）封装在一起。

夸 Skills 的主要集中在这几点：

提供标准化格式进行能力封装，适配不同模型与 Agent。
通过 SKILL.md 实现提示词分发。
脚本代码形式的工具，免去 Schema 描述，节约 Token，减缓上下文腐化。
渐近式披露，按需加载提示词与工具。

怎么说呢，大方向没毛病，细想一下，要打一些 ❓。

标准化

所有 IT 技术标准化的核心作用都是为了解耦供需端的实现，便于上下游衔接、集成、分发、传播，从而扩大原有规范的影响。

从这个层面来说，Skills 的 Spec[2] 非常潦草，只描述了许多概念上的东西，完整 Spec 的长度甚至不一定比本文长。

应用层开发者（包括 AI App 开发者和 Skills 开发者）作为下游对接无疑会非常灾难。毕竟哪怕 MCP 这种已经相对较为标准的协议（有官方 SDK 实现、有示例、有字段级别的协议描述），各个 AI App Client 和 MCP server 实现的依然随缘。问题诸如：

不完整：支持 Prompt、Resource 的就很少，更不要提 Sampling、Elicitation 这些“高级”用法了。
不标准：对 listChanged 事件的正确支持；报错处理、Input/Output schema 的 Validation 等
不统一：比如 Prompt, Resource 要不要支持 AI 访问；工具调用是否要设置超时等。

而 Skills 本身设计就过于轻量（或者说简陋），许多东西都依赖于开发者自己脑补：

SKILL.md 如何插入 Context 中，是注入 System prompt 还是 User message？
Skills 渐进式披露时每层使用何种数据结构和 Prompt 模板？
如何设计遍历 Skills 文件夹、读取文件内容对应工具（一次读取完整文件会占用太多 context，支持搜索则要走 Claude Code Agentic Search 模式或者 RAG 的老路）？
脚本文件夹中脚本是直接通过命令行调用、还是写代码通过 Interpreter 执行？本地执行还是通过 VM 或容器执行？
Skills 脚本依赖的执行环境（Python, Node 本体及对应的包管理）如何处理？

当然上述有些问题不纳入标准中也可能是考虑“灵活性”。不过一旦过多的描述不是标准约定，只是 Best Practice （甚至连这也没有）的话，对于开发者的要求就会大幅提升。同一套 Skills 在不同的 App 中运行效果可能也会大相径庭。

提示词分发

另一种常见的说法是，Tool 或者是 MCP Server 只能提供工具自身，但不提供如何做。SKILL.md 标准化了提示词的分发，进而可以将垂直场景的专业知识与 AI 共享。

不过一个好的工具本身，在其描述提示词中，是一定会或多或少的提供相关领域的知识的，否则无法准确的引导 AI 使用它。而这部分内容是一定会注入到模型上下文中的。因此工具本身的分发，其实就附带了提示词的分发。

另外 MCP 协议本身规范中也在 MCP Server 中提供了 instructions[3] 字段，允许 Client 在安装 MCP Server 时注入关于 MCP Server 如何使用的提示词，这部分内容完全可以代替 SKILL.md。问题只是大部分 Client 在实现似乎并不关注此字段，并不会自动完成上下文的注入。而另外 MCP Server 本身的 Prompts[4] 其实就是一种标准的提示词分发方式，只是也不被大家所关注。

这些其实是比较可惜的。我在之前的文章中也提到过，MCP 协议本身真不是仅仅标准化了工具调用而已，其最初的设计是真正意义上的 Model Context 协议，所有 AI 外的上下文（提示词、工具、资源、人机交互）都在协议设计中全面考虑过。理想情况下，一个 AI 模型（不需要额外的提示词）加上一个 MCP Server 就可以化身完整的 AI Agent。Skills 给我的感觉是，既然 MCP 没能实现预期的效果，那我们就索性提一个新的标准出来。

脚本工具

“通过写代码作为工具”更不是新东西。比如 ChatGPT 很早就有 Interpreter 工具提供 Python 代码执行能力。黑哥的 AiPy[5] 对此践行得也很早且彻底。

Claude Skills 与 Anthropic 他们自己提出的Code execution with MCP[6] 的理念都是一脉相承的，这份理念实际也体现在 Claude Code 中。Claude Code 早期最让人津津乐道亮点之一就是工具设计，只要提供文件系统 + Bash，就实现了相当程度的通用 Agent。

在 Claude Skills 中，脚本本身既可以直接作为 CLI 工具整体使用，也可以作为 Library 导入，通过编写代码进行灵活的组合、扩展与批处理。

脚本 CLI 可大致对标 Tool call，但其实未必比 Tool call 更好用。主要原因在于增加了 AI 理解工具本身的负担。对于 Tool call 来说，AI 只需要理解名称、工具描述、Input schema（本质就是工具参数的描述）这三个内容。以此决定是否调用、如何调用某个工具。对于脚本来说，上述三种描述其实是蕴含在代码本体中的，AI 需要理解代码本身功能、输入输出，从而正确的运用他们。而程序员们应该都有体会，自己写代码不难，但读懂别人写的代码（尤其是要改别人写的代码）非常难。本质在于许多底层设计、背后的理念、各种隐含的坑不会直接通过代码体现出来。当然有一种解决方法是原作者能够写非常详细且正确的注释。然而如果为工具调用的每个参数能要写详细介绍的话，与写 Input schema 其实就没有本质区别了。

通过 Library 形式使用，除了在处理接口定义时要面临上述参数定义问题外，还有一个点额外问题。因为这个 Library 是高度定制化的，也意味着模型本身是没有相关知识的。假设我们提供了一个 my_http_request 库，模型写代码正确调用这个库的难度，明显是要高于调用普通的 requests, httpx 库。因为模型已经通过海量文档、示例、甚至源码，了解了 requests 的各种用法、各种坑，模型可以很容易的进行“下意识”的代码生成。而对于 my_http_request，则只能通过 In-Context Learning，进行推理，才能得到正确用法。

总结来说，开发者写一个 AI 友好的脚本工具，以及 AI 用好一个脚本工具的难度，是要大于经典 Tool Call 的。从开发者侧来说，这种难度会导致很难实现高质量的、稳定可靠的工具。从 AI 侧来说，这会导致对模型智能程度的要求升高，提高模型使用成本。

渐近式披露

渐近式披露（Progressive Disclosure）无疑是很好的理念，本质仍然是一种上下文工程的手段。言午的这篇把这种信息分层的设计思路可以说是讲得十分透彻了。对于所有 Agent 开发者都是一种很大的启发。

但思路正确不一定保证结果正确。武林秘笈拿给小白练有可能出现绝世高手，但更大可能一无所成甚至走火入魔。为了实现正确的信息分层，通过渐近式披露最有效地利用有限的上下文窗口，这对 Skills 开发者有非常高的要求。相对经典 Tool Call 或者 MCP Server，Skills 除了要描述工具本身的定义、使用方法外，还需要仔细控制各层级的信息分布与信息密度。信息不够，则可能导致 AI 无法理解，造成工具误用，或者无法一步一步完成渐近式读取。信息过多，则失去渐近的意义，反而产生更多的 Token 量。

即使开发者能够相对理想化的实现，最终能否节约 Token / 减少上下文空间，依然存在一些前提要满足。按照官方推荐分成三级[7]：

Metadata (~100 tokens) 包括名称和描述
Instructions (< 5000 tokens) 包括完成 SKILL.md
Resources（token 量按需），包括 scripts, references 等。

具体任务需要读到哪个层级，信息才是足够的？如果大部分任务需要读到第 3 级才能完成，那么分级显然反而会造成 token 的浪费：

信息分级描述引入的额外 token
分级读取进行工具调用产生的 token

最终是否能节省 token 实际要计算加权平均，而每种业务场景的权重是很难预估出来的，Skills 开发者不可能预估出使用者最终业务场景中的分布。

另外即使是渐近式披露本身，也并不是独创的概念（但确实应该是独创的词汇）。也是只有通过 Skills 的分文件读取才能实现。MCP 协议中本身的 Prompt 功能，在元数据中也区分了描述与详细内容两层，如果支持模型自主调用，本质也是一种渐近式披露。在 MCP Server 最火的那段时间，已经有不少相关产品提供了工具聚合器。本质是将成百上千个工具封装成两个工具

search_tool 通过自然语言或者关键字搜索完成目标任务适用的工具（背后可能是关键字搜索、向量搜索、小的专有模型），返回工具 id, schema 等信息。
call_tool 统一的工具调用入口，通过前面返回的工具 id 进行最终的工具调用。

这种形式同样不需要将大量的工具描述、schema 预先载入到上下文中，同样能够达到按需使用的目标。

渐近式披露并非银弹。极致的上下文管理，在载入阶段进行优化只是杯水车薪。即使实现了很棒的渐近式披露，一旦进行过一次全量载入（在解决复杂任务的 Agent 中，几乎必然发生），这些内容都是会永久性的占据上下文，与整体预加载并没有显著区别。渐近加载相比全量加载会有更大的犯错的可能，比如我需要 XX 能力，这个能力可能在某个 reference 文件中，加载后却发现文件中的内容并不能满足需求。那么这次尝试就是白白浪费 token 了。

如果 “载入” 阶段的帮助不大，那么什么是重要的？我的看法是遗忘，即 Context 的压缩或者说 Memory 的管理，正确且及时地将非关键的信息从上下文中移出，腾出宝贵的注意力空间给核心任务。比如对于某次错误的尝试，可以只保留最终结论，而“遗忘”试错的过程；对于某些使用过的工具，也可以暂时“遗忘”，当需要使用之时重新加载回来，如同计算机各种工程实践中的 Cache，及时的进行换入换出。当然遗忘也是有成本的，一方面遗忘本身会导致 KV Cache Miss，造成模型调用成本增加；另一方面“回忆”起“遗忘”的内容，也要引入额外的 token。这些都需要基于具体的业务场景，在重复评估、迭代的循环来进行试错与权衡。