MCP 或将成弃子
Anthropic 的工程师们上周发了篇博客,可以说是直接把自家的 MCP 给「背刺」了。
而这时间点,也好巧不巧,正好就是 MCP 推出刚刚一年之际。
文章中提出了一个方案,能让 token 消耗从 150,000 降到 2,000,直接节省 98.7%!
在我看来,这个方案其实说的就是:别用 MCP 了,写代码吧!
此话怎讲?且往下看——
Token 黑洞
MCP(Model Context Protocol)的设计思路很简单:把工具们的「说明书」塞进 Claude 的 context window,然后让模型决定要不要用,怎么用。
但这就好像,给一位工人配了一套工具箱,但要求他必须把所有工具的使用手册都摊在工作台上。
于是,问题来了:
假设你有 100 个工具,每个工具定义占 150 tokens. 然后还没开始干活,context 就被占了 15,000 tokens 了。
如果是大型企业场景的 1000 个工具呢?
那就是 150,000 tokens!
工作台都被说明书占满了,哪还有地方干活呢?
别急,还有另一个更要命的:数据「过路费」:
比如你要把 Google Drive 的文档同步到 Salesforce,传统 MCP 的流程是这样的:
Claude 调用 Google Drive API,10KB 的文档返回到 context(消耗 10,000 tokens)。Claude 读取内容,再调用 Salesforce API,把这 10KB 发出去(又消耗 10,000 tokens)。
在这里,Claude 就是个搬运工的角色而已,但却付了两次过路费。
Claude 模型价格
Anthropic 的文章里提到,复杂工作流可能消耗 150,000+ tokens。处理 50 个客户反馈生成报告,光 token 成本就要 $0.225,还要等 100 秒。
又慢又贵,极其浪费。
从调工具到写代码
Anthropic 团队表示,他们发现了一个被忽视的事实:Claude 写代码的能力远超调用工具的能力。
想让 Claude 从 100 个工具中找到正确的,理解参数格式,正确调用,这很难。
但让 Claude 写段 Python 代码?
那 Claude 可就高兴了:这题我会。
from tools import db, email# 查询数据users = db.query("SELECT * FROM users WHERE last_active > '2024-01-01'")# 筛选活跃用户(在代码中处理,不经过 context)active_users = [u for u in users if u.login_count > 10]# 批量发送for user in active_users:email.send(user.email, "您是我们的活跃用户...")
而这里的关键在于:代码在沙箱执行,中间数据不经过 context。
MCP 变成文件系统
新的方案是把 MCP 服务器转换成了代码文件来运行。
MCP 方案:
所有工具定义加载到 context,Claude 需要理解这些定义,然后调用。
新的代码方案:
servers/├── google-drive/│ ├── getDocument.ts # 可执行的代码文件│ └── index.ts├── salesforce/│ ├── updateRecord.ts│ └── index.ts
Claude 只需要看到文件结构,然后写代码导入:
import { getDocument } from './servers/google-drive'import { updateRecord } from './servers/salesforce'
然后执行,然后完事。
上下文很干净,token 也很少,一切都很美好。
来做一下数字对比
同样是「把 Google Drive 文档同步到 Salesforce」:
MCP:
工具定义加载:15,000 tokens
文档数据传输:20,000 tokens
总计:35,050 tokens
往返次数:4 次
代码:
文件结构理解:500 tokens
Claude 写代码:200 tokens
结果返回:20 tokens
总计:720 tokens
往返次数:1 次
节省:97.9% tokens,75% 时间。
Skills 或成 MCP 的替代品
Skills 是 Anthropic 上个月在 Claude Code 中引入的功能(网页版中也能使用),见:Claude 推出 Skills 功能,及 Agent Skills 开发指南。
而 Skills 在本质上,可以理解为就是一个包含知识、代码和最佳实践的文件夹,例如:
/mnt/skills/user/my-tools/├── SKILL.md # 简短的说明文档└── src/ # 实际的代码文件├── github.ts├── database.ts└── utils.ts
而在我看来,上个月推出的 Skills 其实是上周文章的伏笔,二者的组合之下,MCP 可能要成弃子了。
再看个例子对比
MCP 方式
即使用户只问「帮我搜索 AI 相关的仓库」,12 个工具定义也全在 context 中(~2,400 tokens)。
执行后返回 20 个仓库的完整数据(~5,000 tokens)。
总计约 8,000 tokens。
Skills 方式
Claude 读取 SKILL.md(100 tokens),写代码(150 tokens),代码在沙箱执行,20 个仓库数据在沙箱内处理,只返回格式化的 Top 10 列表(500 tokens)。
总计 750 tokens。
而还有一个重要的,是代码的可组合性。
处理「分析 TypeScript 生态中最活跃的 10 个项目」这种复杂任务,Skills 方式下 Claude 可以写一段完整的分析代码,50+ API 调用在沙箱完成,数据处理、分析、图表生成都在沙箱,Claude 的 context 只看到最终结果。
Token 消耗约 2,000,而不是 100,000+。
实战迁移
如果你看到了这里,那你可能要心动了。你可能想问:
那是不是可以把 MCP Server 转换成代码和 Skills 的方式呢?
答案当然是肯定且简单的。
假定原 MCP Server 的 tool handler 长这样:
server.addTool({name: 'query_database',description: 'Query PostgreSQL database',parameters: {...},handler: async (params) => {// 数据库查询逻辑}})
转换为 Skills 则是这样:
// /mnt/skills/user/data-tools/src/database.tsexport async function queryDatabase(sql: string): Promise<any[]> {// 同样的数据库查询逻辑扔这里}
再写个简洁的 SKILL.md,完成。
使用时,Claude 只需要读取 SKILL.md(100 tokens),写代码调用这些函数(200 tokens),执行(数据不经过 context),返回结果(10 tokens)。
总 tokens:310,而 MCP 方式要 12,000,节省 97.4%。
问题出在哪里?
传统 MCP 的问题本质是:计算发生在错误的地方。
所有数据必须经过 context,而 context 是很「贵」的(每个 token 都要钱都要经过计算),有大小限制(100K-200K tokens),往返延迟高。
而代码 + Skills 的方案,则把计算下沉到了沙箱之中。
数据处理在沙箱中,不经过 context,Context 只有代码和结果,干净简单。
而为什么 LLM 写代码比调用工具更高效呢?
因为代码是 LLM 的「母语」,是 Claude 的一直 bet 的超强项。
LLM 训练数据中有数十亿行代码样本,想出错已经很难了,但 API 调用定义只有数百万个。
在 LLM 写出 const filtered = users.filter(u => u.age > 18) 时,它隐式知道 JavaScript 数组方法、异步操作、类型推断,并且这些知识不需要在 context 中明确说明,它早已内化于心了。
而对于工具调用,则需要大量 tokens 来描述 LLM 不那么知道的东西。
MCP 还有未来吗?
那么……MCP 是不是要 deprecated 了?
虽然我已经让 Claude Code 自己把我的几个大 MCP 转成 Skills 在用了,但也不能说 MCP 从此就完了,至少目前 MCP 还有些有价值的场景:
大型组织需要统一的工具接入标准
复杂协议实现(LSP、DAP)
权限和安全控制
第三方生态
只是目前来看,大多数场景下,Skills + 代码 > MCP.
至于未来,MCP 则可能变成一种「中间格式」,还会有些自动转换工具可以把 MCP Server 转成 Skill 代码。
我其实可以(让 Claude Code)做一个,只是我最近确实太忙了,你若有兴趣就交给你了,我还在看 Claude Agent SDK 混乱的文档。
也可能会是混合式的架构:部分用 Skills(大量的长尾工具),另一部分则保留 MCP(核心的高频工具)。
MCP 倒不一定就会此终结,而是可能会从此进化,作为标准协议的价值依然存在,但实际使用形态接下来会逐渐发生改变。
Anthropic 想必不会明说“别用 MCP 了”,但在我看来,这篇文章实际上是把 MCP 调用改造成了基于文件系统的 Skills.
未来 = 代码执行 + MCP as filesystem(Skills)
可能很快,之前狂跟 MCP 的,马上都要开始搬家了!
使用 MCP 执行代码:构建更高效的智能体: https://www.anthropic.com/engineering/code-execution-with-mcp
👇
👇
👇
另外,我还用AI 进行了全网的AI 资讯采集,并用AI 进行挑选、审核、翻译、总结后发布到《AGI Hunt》的实时AI 快讯群中。
这是个只有信息、没有感情的 AI 资讯信息流(不是推荐流、不卖课、不讲道理、不教你做人、只提供信息、希望能为你节省一些时间)欢迎加入!
也欢迎加群和10000+群友交流。