最近 Skill 这个东西火了。虽然它去年 10 月 16 日就发布了，但一开始动静不大。有意思的是，这个时间节点跟 2024 年 MCP 发布时间差不多。它最终是落地上生产，还是重演 MCP 的路径，现在还不好说。
可以明显感受到 Skill 的热度正在扩散，各种解读文章开始出现，现在企业里的领导开始问这个东西了，开会的时候会专门提一句要不要研究一下 Claude 的 Skill 功能，有没有落地的可能性啊之类的。
既然有人问了，总得给个答案。市面上那些解读文章大多停留在介绍功能层面，讲讲 Skill 是什么，怎么用，能干啥。真要判断这东西能不能在自己业务里用起来，光看这些表面功能是不够的。你得知道它底层是怎么运作的，动态加载机制是什么样的，有哪些限制条件，跟现有系统怎么对接。所以我决定把 Claude Agent 动态加载 Skill 的底层逻辑拆开看看，搞清楚它到底是怎么实现的。
按需、最小化加载是如何实现的？
那 Skill 具体是什么，网上那些介绍文章已经说得够多了，这里就不重复了。我们直接切入正题，以 Claude Agent 为例，拆解一下 Skill 到底是怎么动态加载的。
我们首先创建一个智能体，配置一个读取飞书文档的 Skill。
---
name: feishu-docx
description: Export Feishu/Lark cloud documents to Markdown. Supports docx, sheets, bitable, and wiki. Use this skill when you need to read, analyze, or reference content from Feishu knowledge base.
---
从 System Message 我们可以看到，有一个 Skill Tool。Claude Agent 启动时会扫描指定目录下的所有 skill 文件夹，读取每个 SKILL.md开头的 YAML frontmatter，也就是 name和 description这两个字段。这些信息会被注入到 system prompt 里面。
这时候跟 Agent 对话，它可以直接列出已加载的 skills 而无需调用工具，说明 skill 的 description是直接写在 system prompt 里的。但是 SKILL.md的具体内容，也就是详细的使用说明、示例代码、注意事项这些东西，在初始化阶段是不会加载的。Agent 只知道有这么一个 skill，知道它大概能干什么，但不知道具体怎么用。
然后我们让它帮我们读取一下飞书的文档。简单的一句指令，看看它是如何执行的。
🕐 [22:52:38] 🤖 助手回复
----------------------------------------
💬 文本: 我来帮你查看这个飞书文档。由于需要访问飞书知识库,我将使用 feishu-docx skill 来导出文档内容。
🕐 [22:52:38] 🤖 助手回复
----------------------------------------
🔧 工具调用: Skill({'skill': 'feishu-docx'}) -- call_f00cc85ae2f749c08337027d
🕐 [22:52:38] 👤 用户消息
----------------------------------------
🆔 工具ID: call_f00cc85ae2f749c08337027d
📈 结果: Launching skill: feishu-docx
🕐 [22:52:38] 👤 用户消息
----------------------------------------
💬 文本: Base directory for this skill: /Users/leemysw/Projects/agent-kit/playground/.claude/skills/feishu-docx
# Feishu Docx Exporter
Export Feishu/Lark cloud documents to Markdown format for AI analysis.
## Instructions
### Setup (One-time)
1. Install the tool:
```bash
pip install feishu-docx
```
……收到用户的请求后，Agent 根据 system prompt 里的 skill 列表，识别到需要使用 feishu-docx这个 skill 来完成任务。接下来它触发了 Skill Tool。
这里有个细节值得注意：tool_result 返回的内容只是一句简单的 "Launching skill: feishu-docx"，并没有直接返回 SKILL.md的完整内容。
我一开始以为 skill 的内容是通过 tool_result 直接塞回去的，但实际的上下文构造方式是这样的：
1. tool_use: Agent 调用 Skill Tool，传入 skill 名称 2. tool_result: 返回 "Launching skill: xxx"，只做一个确认 3. user message: SKILL.md的完整内容作为一条新的 user message 注入到对话流里
这个设计有它的道理。如果把 skill 内容塞到 tool_result 里面，从语义上讲就变成了"工具执行的返回结果"，但 skill 内容并不是执行结果，它是一份操作指南。把它作为 user message 注入，语义上更像是"用户补充了一些背景资料"，Agent 在后续的推理过程中会把它当成上下文参考信息来处理。
具体内容注入后，Agent 就可以根据 skill 里写的操作步骤去调用实际的工具了。后续就是常规的 tool call 流程：
🕐 [22:52:40] 🤖 助手回复
----------------------------------------
💬 文本: 现在我来帮你导出这个飞书文档的内容:
🕐 [22:52:40] 🤖 助手回复
----------------------------------------
🔧 工具调用: Bash({'command': 'feishu-docx export "https://my.feishu.cn/wiki/KUIJwaBuGiwaSIkkKJ6cfVY8nSg" --stdout', 'description': '导出飞书文档内容到标准输出'}) -- call_bebec3051ba74ef28b5c1fa4
🕐 [22:52:50]👤 用户消息
----------------------------------------
🆔 工具ID: call_bebec3051ba74ef28b5c1fa4
📈 结果: ✓ Token 已刷新
发现 223 个 Block
预处理完成
渲染完成 (223 blocks)
# feishu-docx-document
# **feishu-docx**
Agent 从注入的 skill 内容里读到了 feishu-docx export <url> --stdout这个命令格式，然后按照这个格式去调用 Bash 工具执行实际的导出操作。
小结
整个流程拆下来，Skill 的加载机制其实并不复杂。它就是通过一次 tool call 来动态把操作指南注入到对话上下文里，让 Agent 在需要用的时候才去读取具体内容，而不是一开始就把所有 skill 的完整信息塞进 system prompt。
这种设计的好处是显而易见的：假设你有 20 个 skill，每个 SKILL.md平均 2000 token，如果全部预加载到 system prompt 里就是 40000 token，这对 context window 的消耗相当大，而且大部分情况下用户一次对话只会用到其中一两个。按需加载的方式可以把这个开销降到最低。
跟 MCP 对比来看，Skill 更像是在 MCP 的基础上加了一层 abstraction。MCP 解决的是"怎么让 Agent 调用外部工具"这个问题，提供了标准化的工具定义和调用协议。但工具多了以后，Agent 怎么知道什么时候该用哪个工具、怎么组合使用多个工具来完成一个复杂任务呢？这就是 MCP 没有完全解决的问题。
Skill 尝试在这一层做点事情：把"如何使用一组工具完成某类任务"的知识封装成一份可复用的文档，通过动态注入的方式让 Agent 在需要时获取这份知识。某种程度上，Skill 是在给 MCP 补一个"操作手册"的功能。
业务落地的坑
如果打算把 Skill 用到实际业务里，有几个问题可能得提前想清楚。
Skill 的执行过程涉及到多个环节：description 匹配、内容注入、指令解析、工具调用。任何一个环节出问题，最终表现都是没跑对或者没触发。但你想定位到具体是哪个环节出的问题，就得去看完整的对话日志，分析 Agent 在每一步是怎么决策的。如果系统没有把这些中间状态都记录下来，排查问题会非常痛苦。
当 skill 数量变多以后，可能会出现两个 skill 的 description描述相近的情况。用户说了一句话，Agent 可能同时觉得可以用 skill A，也可以用 skill B。这时候它会选哪个？
Skill 里面可以写任意的工具调用指令，包括执行 shell 命令、访问文件系统、调用外部 API。如果 skill 的内容能被用户影响，哪怕是间接影响，都可能存在安全风险。在设计 skill 的时候，得仔细考虑哪些参数来自用户输入，怎么做校验和过滤。
想要发挥作用，得有工具可以调用。如果公司内部的系统还没有暴露出标准化的 API 或者 CLI 接口，那得先把这部分工作做掉。而且接口的设计得考虑到 Agent 的使用场景：返回值是不是足够结构化、错误信息是不是够明确、参数格式是不是容易理解。
Description 怎么写也是个技术活。写得太长会占用 system prompt 的空间，写得太短又容易让 Agent 判断失误。而且 Skill 的编写本身需要对 Agent 的行为模式有比较深的理解，知道它在什么情况下会触发 skill，怎么写能让它更准确地理解你的意图。这不是随便找个人就能写好的，还是得懂业务。
一些吐槽
Skill 这套机制对模型能力的要求其实挺高的。
Agent 需要根据用户的自然语言请求，准确判断应该调用哪个 skill。如果 skill 的 description 写得模糊，或者用户的表述跟 description 差得比较远，模型就容易选错 skill 或者干脆不触发。
SKILL.md本质上是一份纯文本的操作指南，Agent 需要理解这份指南的意思，然后按照里面写的步骤去调用工具。如果模型的指令遵循能力不够强，可能会漏掉某些步骤，或者把参数搞错。
很多 skill 涉及到连续调用多个工具，中间还有条件判断和错误处理的逻辑。这对模型的规划和推理能力是个考验。
所以那些想用小尺寸模型来验证 Skill 功能的想法，建议直接放弃，光是意图识别就够呛，更别说后面那些复杂的多步骤执行了。
至于 Skill 会不会走 MCP 的老路，现在下结论还早。技术上它确实解决了一些实际问题，但能不能真正在生产环境里用起来，还得看后续的生态建设和工程化支持跟不跟得上。
