MCP

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 公司推出的一个开放标准协议，它就像是一个 “通用插头” 或者 “USB 接口”，制定了统一的规范，不管是连接数据库、第三方 API，还是本地文件等各种外部资源，都可以通过这个 “通用接口” 来完成，让 AI 模型与外部工具或数据源之间的交互更加标准化、可复用。

所以 MCP 的本质，还是在做 “标准化”，它让给 AI 扩展外部能力这件事更 “标准化”。

假如你的 Agent 连接了多个 MCP，它似乎也能实现 “按需加载”（根据用户的意图决定调用哪个工具）。

但这个 “按需加载” 背后的代价是非常巨大的，在 MCP 的架构下，仅仅是“连接”这个动作，就已经在透支你的额度了。

这是由 LLM 的工具调用机制决定的。为了让 AI 知道它有哪些能力可用，每一个连接的 MCP Server 必须在对话开始前，将其所有工具的完整定义（名称、详细描述、参数 Schema、使用示例）一次性注入 LLM 的上下文中。

每个 MCP Server 一般都会包含大量的工具，比如 Github MCP ，它自己就包含了 30 多个工具：

假如每个工具消耗 500 个 Token，那只链接这一个工具就需要消耗将近 20000 Token。

在真实环境下，一个 Agent 不会仅链接一个 MCP Server。

假如你只问了 AI 一个非常简单的问题（1+1=？），Agent 已经烧掉了大几万的 Token，这个成本是非常恐怖的。

更深层的问题在于链接过多的 MCP Server 可能导致 LLM 的 “注意力” 下降，从而降低工具调用的准确性。

之前的文章中有讲过一个专门测试 MCP Server 调用准确度的基准：MCP Atlas（世界最顶级的大模型，都在 PK 些啥？ （大模型评估完全指南）），在这个基准中包含了 40 多个不同服务器、300 多个工具的复杂环境。

模型必须自己发现合适的工具、正确调用，并把多步结果汇总成最终答案。目前最强的 Claude Opus 4.5 也只能拿到 62% 的准确率，这个值还会随着工具的增多而进一步下降。

MCP 适合的是：

需要持久状态的工具（浏览器会话、数据库连接）

需要实时双向通信的场景（流式响应、事件推送）

工具数量巨大且需要动态发现的平台（10+ 服务集成）

在这些场景下，MCP 把 M×N 变成 M+N，维护成本能降低 50-70%。

SKILL

• 节省 Token：首次链接时，相比 MCP 需要将 40 多个 MCP Server 下 300 个工具全部塞进模型上下文（消耗数万 Token），模型只需要加载 40 个 Skills 的元数据（几千 Token）。
• 提升注意力： 面对几百个工具，AI 很容易分心。Skills 采用的是“漏斗式”引导：先通过目录判断大方向，确认要干活了，再加载具体的说明，最后通过说明找到详细的文档和脚本最后再执行。让 AI 每次只专注于当前任务。即使是能力稍弱的模型，在这种机制下也能保持极高的调用准确率。

MCP与SKILL区别

Skills 看起来更智能、更节省资源，那 MCP 会被淘汰吗？结论是：MCP 不会被完全淘汰，但对它的需求会大幅减少！

首先，MCP 协议层的价值不可替代： MCP 的真正价值不在于它如何把文本塞进 Prompt，而在于它制定了一套标准接口。它统一了 AI 连接世界的方式。

如果你是一个通用的三方平台（高德地图、Notion 等），想发布一个工具让其他 Agent 都能用上你的能力，那首先选择的还是 MCP。

但是，如果你有一些重复性的工作流，比如要以固定的流程读写本地文件、要用一个标准的范式来 Review 代码、有一套固定的风格来编写文章，这些场景都推荐使用 Skill 来实现。

在过去这几个需求中的本地文件读写、链接 Github、给文章生成图片这些需要链接外部世界的能力都得通过 MCP 去实现，但现在你可以都把它们打包到 Skill 里。

未来的格局可能是这样的：

• Agent 本身内置部分核心能力（bash、read、edit、write）
• 少数通用 MCP Server 负责远程连接（数据库、云 API、SaaS 集成）
• 大量 Skills 负责封装标准工作流、连接本地知识库
• 两者在必要时协作，但 Skills 会承担绝大部分 “教 AI 怎么做事” 的工作（这其中也包含教 AI 怎么用 McpServer、怎么用其他 Skills、怎么更好的调用核心能力）

而 Skill 和 MCP 的关系呢？MCP/API 告诉 Agent 能获取或写入什么数据，Skill 告诉 Agent 遇到这个场景应该怎么组合工具。Skill 最大的价值是封装经验，把多 Agent 协作踩过的坑、平台特性、安全边界写进去，新 Agent 上线就能继承，不用重新踩一遍。

:::info 个人理解：

MCP和SKILL都是通过tool_call方式被调用。

MCP不会被SKILL完全替代。因为MCP与SKILL在Agent中发挥的作用是完全不同的。

MCP通常需要连接某个服务提供商，例如高德的天气查询、位置查询等，这就需要高德去提供这个server。这是SKILL无法做到的或者说实现起来成本较高。

• 当我们制作好一些特定服务，需要对外部的Agent，远程提供服务支持，首选MCP方式。

SKILL则通过渐进式披露的方式，能够让Agent实现更复杂(规定一套完整、复杂的SOP)、更精准的功能。例如，”用户的输入转为日语，调用本地japan.py脚本进行格式处理，随后转为md格式，存入本地text.md，将md导出为pdf”(这个流程只是为了体现SOP的复杂度)。这期间需要调用多个脚本。

• 当我们有一套完整、标准、复杂的处理流程，且简单的tool_call方法不能保证每轮调用链的完整性，泽可以将其打包为一个SKILL，为模型赋予这项技能。

:::