|
说实话，MCP 在演示中表现完美，但一旦你尝试扩展使用，它就会崩溃。 一个 GitHub MCP 服务器可以暴露 90 多个工具。这意味着在模型开始思考你的提示词之前，就已经有超过 5 万个 token 的 JSON 模式和描述被加载到了模型的工作记忆中。 所以当 Anthropic 推出 Skills 时，我看到的不是一个新功能——我看到的是一次航向修正。一次悄无声息的航向修正，但确实是航向修正。 MCP 的真正问题不在于工具本身从底层来看，MCP 的概念其实很简单。 你运行一个或多个 MCP 服务器。每个服务器暴露一组工具，每个工具有一个模式，客户端将这些定义加载到模型的上下文中，这样模型就可以决定调用哪些工具以及如何调用它们。理论上，这为模型提供了一个干净的、类型化的外部世界接口。 但在实践中，这个"干净的接口"变成了一个消防水管。 每个工具模式都会在一开始就被塞进上下文窗口。无论你是让模型读取文件、查询数据库，还是只是总结一段话，模型都必须在完整的工具清单、参数和描述中筛选，才能确定哪些可能相关。 再加上工具调用准确性的复合效应：如果单个工具决策的准确率是 90%，那么连续调用 5 个工具的整体准确率就变成 0.90⁵ = 0.59，不到 60%。无数 Reddit 帖子都在说同一件事：当你堆叠调用时，工具调用准确率会呈指数级下降。 结果是一个糟糕的组合： - • 对话历史、全局工具定义和任务特定上下文都在争夺空间
- • 多步骤工作流开始时表现良好，但随着模型失去对早期约束的跟踪而逐渐失败
我在真实系统中见证过这种情况。任务很简单，工具也是正确的，但失败源于认知过载。模型被要求在脑中保持整个工具宇宙的同时进行推理、规划和选择工具。 今天大多数人实现的 MCP，不只是暴露工具——它暴露得太多了。 Anthropic 的解决方案不是修补 MCP他们瞄准的是真正有问题的模式：静态的、预先暴露。 Skills 翻转了这个流程。 一个 Skill 就是一个文件夹。文件夹里有一个带 YAML 前言（名称、描述、元数据）的 SKILL.md 文件，后面是详细的指令、参考资料，还可以选择链接到同目录下的其他文件。 在启动时，智能体不会完整读取每个 skill。它只获取每个 skill 的最小元数据，并将其放入系统提示词中。这给 Claude 提供了刚好足够的信息来判断某个 skill 何时可能相关，而不用付出加载所有内容的代价。 当用户提出请求时，Claude 会经历一个渐进式披露过程： - 2. 如果某个 skill 看起来相关，使用文件系统工具打开 SKILL.md
- 3. 如果该文件引用了其他文档（如 forms.md 或 reference.md），只在需要时才读取它们
- 4. 如果 skill 包含脚本，通过代码执行环境运行它们，而不是试图通过 token 生成来"模拟"
关键是：上下文是分层加载的，而不是一次性倾倒。 你可以在一个 skill 中打包大量知识——多个 Markdown 文件、示例、指标定义，甚至完整的 Python 脚本，它们在智能体环境中充当确定性的微服务。但这些内容都不会进入上下文窗口，直到 Claude 判断它们与当前任务相关。 这与大多数 MCP 设置的行为正好相反。 Skills 不只是 Claude UI 的技巧。它们在 Claude 应用、Claude Code、API 和 Agent SDK 中都得到支持，全部连接到同一个代码执行工具，为智能体提供安全的脚本运行环境。 所以，Anthropic 没有说"MCP 有问题"，而是做了一件更有趣的事：他们改变了模型"遇见" MCP 的方式。 Skills 在前面，MCP 在后面。 Skills = 检索，MCP = 工具，合在一起 = RAG-MCP如果你做过检索增强生成（RAG），这个模式应该很熟悉。 在 RAG 中，你不会把整个知识库塞进上下文窗口。你把它单独存储，使用索引只检索相关内容，然后让模型在工作时读取那部分。 Skills 对工具和程序性知识做了同样的事情： - • "索引"是 skill 的元数据：名称、描述、标签
- • "文档"是 SKILL.md 正文加上任何链接的文件
- • "回答步骤"是指令、代码和（在必要时）包装在该 skill 中的 MCP 调用的组合
与其把每个 MCP 工具模式都倒入上下文，不如将它们绑定到特定的工作流： - • "
 DF 表单填写" skill 知道使用哪个 MCP 服务器和脚本 - • "营销分析洞察" skill 使用 Python 处理 CSV，只在需要时调用工具
- • "推文转新闻稿" skill 由你自己写作风格的示例和辅助代码构建
模型不再需要了解整个工具宇宙。 它只需要知道哪个 skill 相关，而 skill 知道如何编排其余的部分。 这就是 RAG-MCP 的实践： - 4. 当工作流需要时，将 MCP 工具作为最后一公里集成来调用
Skills 不与 MCP "竞争"——它们驯化了 MCP。 为什么这对实际构建智能体的人很重要如果你只是在搭建玩具项目，很多问题可以暴力解决。上下文窗口很大，演示很短，工具很少。MCP 感觉还不错。 但一旦你进入： 裂缝就会显现。 你会开始看到： - • 第一天能用的工作流，到第七天就漂移了，因为对话历史现在在与工具定义争夺上下文空间
你可以打补丁绕过去。我也这样做过。 你可以精简模式、拆分服务器、重写描述使其更短。 你可以启动监督智能体，试图引导主智能体回到正轨。 但你仍在与底层模式作斗争：模型在接触任务之前就被工具淹没了。 Skills 改变了问题的形状。 你从"模型必须理解系统中的每个工具"转变为"模型必须为任务选择正确的 skill，而 skill 会带来它所需要的一切"。 这是一个更理性的心理模型。 它也符合我们培训人类的方式：我们不会在新队友第一天就把完整的维基交给他们并期望他们记住。我们给他们一个入门指南，然后在他们遇到实际任务时指向具体的文档和脚本。 Skills 为智能体正式化了这种模式。 更好的前进道路Anthropic 处理这件事的方式有些我很欣赏的地方。 他们没有发布"MCP 现状"文章。他们没有宣布协议已死。他们没有试图假装上下文膨胀只是用户错误。 他们悄悄地发布了一种机制，接受大型工具生态系统的现实，并给智能体一种与之交互的方式，而不会在压力下崩溃。 Skills 是可组合的。跨产品可移植。高效，因为它们只加载需要的内容。强大，因为当可靠性比纯生成更重要时，它们可以引入代码执行。 最重要的是，它们承认了我们许多在实际环境中构建的人都感受到的事情： 智能体的未来不是更大的工具堆。 而是与工具"相处"的更好方式。 检索和编排优先。上下文被视为稀缺资源，而不是无限的倾倒场。MCP 仍在那里，但它不再压在模型胸口。 Anthropic 没有放弃 MCP。他们让它变得可持续了。 对于我们这些试图构建做真正工作的智能体的人来说，这种悄无声息的转变比任何协议公告都更重要。 | 
