MCP vs. Skill 旧瓶装新酒这一块

MCP#

我在之前对 MCP 的学习中简单提到过当时 MCP 的一些痛点，不过发展到现在 MCP 这套通信协议已经被 Anthropic 搞得相当完善，MCP Server 也能快速适配到不同 Client。

从本质上来说，MCP 的功能侧重于包装了 Function Calling（函数调用），用户不需要具体 Tool 的逻辑。比如 Context7，封装了抓取网页、读文档等工具，LLM 在其加持下，引入并使用这些工具。

值得注意的是，作为 Agent 重点关注的 Context，MCP 的做法是将所有工具都放入上下文，

上图是通过 Claude Code 的 /context 得到的上下文占用情况，可以看到，MCP tools 会固定占用一定的空间，即，LLM 每次都会携带完整的工具，包括具体的调用参数、方法等。LLM 正是通过这种方式，能根据用户输入判断是否需要进行工具调用，以及如何调用，并直接调用 MCP Tools，如下图所示：

Skill#

Anthropic 可能是看到了 MCP 占用大量 Context 的问题，又提出了一个新的概念“Progressive Disclosure”（渐进式披露）以及 Agent Skill，如下图：

简单来说， 技能就是打包好的程序性知识，本质上就是文件夹。例如，Claude Code 中，每个 Skill 有一个 Skill.md：

它包含了提示词（Prompts）、脚本（Scripts）和说明文件等。看起来和 MCP 差不多，但两者真正的区别在运行时机制上。

1. Skill 在运行时，一开始只暴露元数据（Metadate），对应到图中的 YAML 中前置配置，用于提供简要的工具信息，同时避免工作时占用过多 Context。
2. 接下来，当用户指令或 LLM 发现请求与 Skill 的描述部分匹配时，就会触发并加载对应 Skill 的 Skill.md，此时包含详细信息的工具说明才进入上下文窗口。
3. 如果文件目录下还有其他资源和代码，在调用工具时也会进行按需加载；

因此，从本质上来说，Skill 就是按需暴露工具，从而不一次性并持久的占用上下文空间，从而节省了上下文窗口。

End#

之所以个人认为它是旧瓶装新酒，是因为本质上只是对 Agent 运行时使用和加载工具的时机进行了对 Context 进行优化，从功能上看没什么区别。并且，直接将 MCP 按照渐进式披露的思路进行转换，说不定更好，例如有一个类似的 MCP 工具 mcp__pdf，我们同样不加载一些具体的 Tool，一开始只告诉 LLM 有这个工具及其功能描述，当需要使用时，在通过类似 mcp_pdf --help 自行查看和加载需要的方法。甚至避免了在脚本上操作读取存在的安全性问题。

不过脚本由于其轻量且易于共享，因此个人认为 Skill 的出现还是属于进步的。把 Skill 认为是渐进加载的 MCP 也好，多个 MCP Tool 的整合或包装也好，现在都只需要写个通用提示词就能实现工具的选择和调用了。