MCP的接班人不是A2A，是Skills

上周我在调试一个自动化工作流，连上了4个MCP服务器——GitHub、Brave Search、Filesystem、Puppeteer。配置完毕，打开Claude，输入"你好"。

就这两个字。

Token计数器显示：67,000 tokens。

我还没开始干活，context window已经用掉三分之一了。

---

一、67,000 tokens买了什么？

不是我一个人遇到这个问题。Medium上的Joe Njenga写过一篇文章，标题直接叫《MCP正在悄悄吃掉你的context》："4个MCP服务器连接后，我连一个字都还没输入，67,000 tokens就没了。"

这不是个例。DEV.to上的piotr_hajdas给过一个简单公式：

10台MCP服务器 × 15个工具/服务器 × 500 tokens/工具 = 75,000 tokens

Reddit社区r/ClaudeCode的一位用户测得更极端：6个MCP服务器连接时，预加载了83,300 tokens，占200K上下文窗口的41.6%。

对于Claude Sonnet，按官方pricing算，每百万token输入约$3。如果你每天对话20轮，光是MCP的"开场费"就是：

83,300 × 20 × $3 / 1,000,000 ≈ $5/天

这还是保守估算。有人在Twitter上晒账单：接了一堆MCP服务，两天烧了$300。一个月下来轻松$375+，全给了"工具描述"。

---

二、MCP的原罪：这是设计，不是Bug

很多人第一反应是：那找写得更精简的MCP服务器不就行了？

我也这么想过。直到看到2025年9月华为研究员提交的SEP-1576提案——他们分析了官方GitHub MCP中的工具定义，发现60%的字段是冗余的。换句话说，即使是官方维护的、质量最高的MCP实现，也有大量无效token。

这不是"某个MCP写得烂"的问题。这是JSON Schema协议的必然代价。

MCP的工具描述长这样：

{
  "name": "search_web",
  "description": "Search the web for information",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The search query"
      },
      "num_results": {
        "type": "integer",
        "description": "Number of results to return",
        "default": 10,
        "minimum": 1,
        "maximum": 100
      }
    },
    "required": ["query"]
  }
}

这段JSON对机器来说很友好——类型严格、可验证、可程序化解析。但对LLM来说，它是一堆重复的结构噪音。"type": "object"，"type": "string"，"required"数组……每一行都在消耗token，却几乎不增加LLM真正需要的语义信息。

MCP协议设计的初衷是让工具调用标准化、可互操作。这个目标没错。但副作用是：你为机器可读性付出了LLM理解成本。这是协议层的权衡，无法通过"优化某个MCP"来根治。

---

三、A2A：一个跑题的答案

2025年4月，Google发布了Agent-to-Agent（A2A）协议，社区里炸开了锅。"MCP的替代者来了！"

等我真正看完A2A规范，发现它解决的根本不是同一个问题。

A2A要解决的是：已经存在的多个AI代理之间，如何通信和协作。它定义了代理发现、任务委派、状态同步的标准协议——这是一个非常有价值的问题，但前提是你已经有一群跑得很稳的AI代理在生产环境里运行。

现实是什么？大多数开发者还在为MCP token付钱，还在调试单个代理为什么突然忘了上下文，还在想办法让Claude别把工具描述当成任务描述来回答。

用A2A解决MCP的token问题，像是在一条土路上造了一条六车道高速公路——路修好了，但你的车还没发动。

A2A是2027年的答案。MCP的token问题是今天每个连了三个以上服务器的人都在面对的问题。

---

四、Skills：被所有人忽视的第三条路

Skills不是什么新技术。它的核心极其简单：

用自然语言把工具的使用方法注入System Prompt，而不是用JSON Schema定义工具接口。

一个等价的"网络搜索"工具，用Skills描述是这样的：

使用 firecrawl 工具可以搜索网页。调用方式：exec firecrawl search "查询词"。
适用场景：需要获取实时网络信息、查找文档、研究某个主题时使用。

token数：大约30-40个。

对比JSON Schema方式的300-600 tokens，差距是5-10倍。

更关键的是：自然语言对LLM来说本来就更"可读"。LLM是在自然语言语料上训练的，理解"查找网络信息时用firecrawl"比解析一大段JSON Schema更直接、更准确。BAML（BoundaryML）的研究发现，在某些场景下，纯提示词技术的准确性甚至高于传统函数调用方式（来源：boundaryml.com/blog/schema-aligned-parsing）。

Skills的另一个优势是灵活性。你可以用自然语言描述"什么时候用这个工具"、"这个工具的注意事项"、"和其他工具的区别"——这些元信息在JSON Schema里几乎无法表达，或者要用大量冗余字段才能勉强描述。

---

五、我的实战：13个Skills，0个MCP

说够了理论。来看实际效果。

过去三个月，我把工作流从"MCP为主"切换到"Skills为主"。目前我在OpenClaw里运行13个Skills：

Skill	替代的MCP功能
agent-browser	Puppeteer MCP / Playwright MCP
firecrawl	Brave Search MCP / Fetch MCP
github	GitHub MCP
weather	天气API MCP
obsidian	Obsidian MCP
himalaya	邮件MCP
apple-reminders	提醒事项MCP
apple-notes	Notes MCP
pdf	PDF处理MCP
docx	Word文档MCP
coding-agent	—
nano-pdf	—
summarize	—

覆盖范围：浏览器控制、网页抓取、代码管理、文件处理、邮件、天气、笔记……我原来需要7-8个MCP服务器才能实现的功能，13个Skills全部覆盖，且上下文开销大幅减少。

实际感受：

上下文更干净。 每个会话开始时，Skills注入的内容大约是1,500-2,000 tokens（13个Skills，每个约100-150 tokens的描述）。等价的MCP配置会是什么？参考前面的公式，至少50,000 tokens起步。

模型表现更稳定。 这是我没预期到的副作用。当context不被工具描述占满时，模型在推理任务上的表现明显提升。它不需要"穿越"大量结构化噪音才能到达真正的任务描述。

不再有"今天context够不够用"的焦虑。 以前做长文档处理或者复杂代码重构时，我总要提前规划token预算。现在这个问题基本消失了。

---

六、三者的正确位置

写到这里，我要说一句公道话：MCP没有错，A2A也没有错。

MCP的价值在于标准化和精确性。如果你在构建一个对外提供的AI工具服务，或者需要严格的类型校验和错误处理，MCP是正确选择。它的问题不是设计错了，而是在token成本没有解决之前，不应该被当作"默认选项"滥用。

A2A的价值在于未来的多代理系统。当你真的有多个专业化AI代理在生产环境协作时，A2A会是它们之间的通信标准。但那是2026-2027年的事。

Skills今天就能用，而且效果可验证。它不是一个新协议，不需要等生态成熟，不需要服务商支持——你只需要能修改System Prompt。

---

结语：接班人不是推翻，是先把活干了

MCP还没解决自己的token问题，A2A已经在讨论多代理通信标准，而Skills悄悄把这两件事都绕过去，把活干完了。

这就是我说"MCP的接班人是Skills"的意思。不是推翻，不是替代——是在生态还没成熟、token还很贵的今天，找到了一条更务实的路。

等MCP解决了token bloat（也许会有SEP-1576的压缩方案，也许会有新协议），等A2A等来了真正的多代理时代，我们再重新评估。

但现在，2026年的今天——13个Skills，0个MCP，我的context window终于不再消失。

---

数据来源：Medium Joe Njenga《MCP正在悄悄吃掉你的context》；DEV.to @piotr_hajdas；Reddit r/ClaudeCode；华为SEP-1576提案（2025-09-30）；BoundaryML BAML研究（boundaryml.com/blog/schema-aligned-parsing）