18 个月前,MCP 还只是一份 spec 文档加几个 SDK——按演讲者自述,SDK 大部分由 Claude 写出来,纯本地、几乎只有 tool 这一个 primitive。18 个月后,这个协议月下载量冲到 1.1 亿,OpenAI Agent SDK、Google ADK、LangChain 以及上千个普通开发者听都没听过的框架都把它拉成依赖。达到这个量级,React 用的时间是 MCP 的两倍。 但当 Anthropic 主导 MCP 协议的工程师在 2026 年初一场开发者大会上谈 MCP 自己时,他没有走"我们赢了"那种叙事。他用了相当大的篇幅承认三件事:MCP 不是 agent 连接的唯一答案;官方 Python SDK 不如社区写的 fastmcp 好用;现在大部分 MCP server 实现"是 cringe 的"——尤其是把 REST API 一对一翻译过来那种。
这场演讲值得听完的原因是,在协议看起来已经"赢"的时刻,主导它的人本人在公开划清协议的边界:什么场景应该用 CLI、什么时候应该用 Skills、什么时候才轮到 MCP。这是给做 agent 产品的人的一份清醒账本——尤其是那些已经在 2025 年踩过"all-in 一种连接器"坑的团队。
18 个月从 spec 文档到月下载 1.1 亿:MCP 凭什么
MCP 协议在 2024 年下半年由 Anthropic 公开推出,定位是 agent 与外部系统之间的标准连接协议。最初的样子按演讲原话是:一份 spec 文档、几个 SDK(主要 Claude 写的)、纯本地、能力有限,核心只有 tool 这一个 primitive。
接下来 18 个月发生了几件事。Anthropic 这边把它从纯本地扩展到 remote、加上了 centralized authorization、引入了 elicitation 和 tasks 这些新 primitive,以及最近实验性的 MCP applications(把 server 端的 UI 直接通过协议传到 client 端渲染)和 skills over MCP。社区这边——也就是这场演讲反复致谢的对象——构建了从 WhatsApp、Blender 这类玩具 server,到 Linear、Slack、Notion 这种真正生产级 SaaS 集成的全套生态。
数据点是 110 million monthly downloads——月下载 1.1 亿。这不只是 Anthropic 自家客户端用的量,关键在于 OpenAI Agent SDK、Google ADK、LangChain 和上千个开发者可能没听过名字的框架,都把 MCP 拉成依赖。换句话说,这是一个跨主要 frontier 实验室都在使用的连接器协议——在一个竞争如此激烈的行业里,这种事其实并不常见。
横向对比:React 这种被认为是过去十年最成功的开源项目之一,达到同等量级下载量大约用了 MCP 的两倍时间。这个对比在严格意义上不算公平——React 面向终端开发者,MCP 面向 agent infrastructure,fan-out 模式不同。但它至少说明 MCP 进入主流的速度,远超普通开发者库。
另一个被演讲者强调的事实是:大部分 MCP server 其实在闭门后面跑——企业内部把自己系统连接到 agent 上的 server 不会出现在任何公共 registry 里。所以 1.1 亿月下载只是显性的那部分。
值得驻足的判断是这个:当一个协议在不同立场的玩家之间都被采用,它就不再是某一家的产品策略,而是基础设施。MCP 现在大致到了这个位置。同时另一个不太常见的信号是,演讲里顺带提了一句——MCP 已经成立基金会。这是治理结构的变化,意味着协议从"Anthropic 的项目"变成了"open source 社区治理"。这种结构变化对那些不想被锁在某一家 frontier 实验室的 enterprise 用户来说,是关键信任信号。
但站在 1.1 亿月下载这个高点上,演讲者本人对这个位置反而格外谨慎。这就引出了他下一段要讲的事。
2026 不再是 coding agent 的世界:连接广度才是新瓶颈
演讲者把过去几年分得很清楚。2024 年是 demos——大家做出一些 cool stuff,圈内有 buzz,但都没真正走出 demo 阶段。2025 年是 coding agents 的天下——Claude Code、Cursor、Aider、Codex CLI 大爆发。原因不复杂:coding agent 是 agent 最理想的场景。它本地、可验证(直接调编译器)、人类开发者就在屏幕前可以即时纠错、UI 显示就是代码编辑器。所有 agent 的难点(连接、信任、UI 呈现)在编码场景里都被天然压平了。 2026 年是 general agent 元年——但 general agent 面对的现实和 coding agent 完全不同。一个金融分析师、一个市场营销负责人想用的 agent,不是要调 compiler,是要连接他每天用的五个 SaaS 应用加一个共享驱动器。对他们来说,agent 最重要的能力不是推理深度,是连接广度。
这一段是整场演讲的中心论点,也是给做 agent 产品的人的一个直接判断:如果有人告诉你存在一个解决所有连接问题的银弹——不管是 computer use、CLI 还是 MCP——他大概率是错的。原话用的是 "probably pretty wrong"。理由是连接性问题不是单一问题,而是一个 stack——不同的工具适合不同场景。
这个判断对正在做产品决策的人有几层含义。第一层,如果你押注一个连接器路线作为唯一通道,你的产品天花板就是这个通道的天花板。第二层,frontier 实验室自己内部已经在按这个判断走——OpenAI 在 ChatGPT 里同时使用 MCP、function calling 和 computer use,Anthropic 自己的 Claude.ai 也是 MCP + Skills + 内置 tool 三层共存。这不是某一家的产品策略,而是 frontier 系统对外接的共识结构。第三层,创业公司只会一种连接方式上手很容易,但产品成熟到 enterprise 需求时,大概率要回头补另外两种。
需要注意的是,这个判断和 MCP 自身的商业利益某种程度上是冲突的。如果 Anthropic 主导 MCP 的人自己跳出来说"MCP 不是唯一答案",那基本可以确认这是真实的技术判断,而不是 marketing 话术。这种诚实在协议团队公开 talk 里是稀缺的——更常见的姿态是"我们的协议解决一切",而这位演讲者的姿态明显不是这样。
三件套并行:Skills、MCP、CLI/Computer use 怎么选
演讲里给出了 2026 connectivity stack 的三件套——Skills、MCP、CLI/computer use——以及每一件应该在什么时候用。这是这场演讲对做 agent 产品的人最直接可以拿走的部分。
Skills 适合 domain knowledge 和场景特定能力——也就是把"这件事应该怎么做"写进一个简单的文件,模型按需加载。Skills 的优点是简单、可复用、跨平台基本一致(虽然不同 platform 在细节上有差异)。它本质是给模型一个"操作手册",而不是一个"动作接口"。Anthropic 在 Claude.ai 里大量使用 Skills 来约束 docx、pptx、PDF 这类文件操作的行为——演讲者隐含的意思是,很多被错误建模成 MCP server 的能力,本质上其实应该是 Skills——一份说明文档比一个完整 server 更轻、更快、更易维护。
CLI 适合本地 coding agent + 预训练里已有的工具。如果你做的是本地 coding agent,你可以假设有 sandbox 和 code execution 环境。而 GitHub、Git 这类工具的 CLI 命令模型在预训练里大量接触过——直接给模型一个 bash 接口,让它自己 discover 命令的能力,演讲原话是 "amazing solution"。这就是为什么 Claude Code、Codex CLI、Aider 都重度用 CLI 而不是 wrapping 各种 API:因为模型对 CLI 的语义已经内化。你不需要再用一个 MCP wrapper 把 git 包一层。
MCP 在以下情况才是正解——演讲者列得很具体:你需要 rich semantics、你需要 UI 来显示长期运行任务、你需要 resources(不只是 tools)、你需要 fully decoupled 和 platform-independent 的能力、你没有 sandbox、你需要 authorization/governance/policies(他直接称这是"boring but important enterprise stuff"),或者你想用 MCP applications、skills over MCP 这些扩展功能。
把这三条放一起看,会得出一个相当具体的产品决策树。如果要做 enterprise 部署、需要登录态、需要 UI、需要长任务,MCP 是正解;如果做本地 coding agent,CLI 优先;如果是教 agent 一种新的工作方式,Skills 优先。这种"右活给右工具"的判断,在 2025 年大部分 agent 创业公司是没做的——很多产品把所有连接需求都强行套进一种通道里,导致用户体验和工程成本两边都不优。
演讲者最直接的批评就是关于这件事:每次他看到有人把 REST API 一对一转成 MCP server,他都觉得有点 cringe。原文用词就是 "cringe"。理由是 REST API 是为人类开发者通过代码调用设计的——语义粒度、错误处理方式、字段命名都不是为 agent 优化的。把 REST 字面翻译过来,你会得到一个跑得通但每个 tool 都难用、token 浪费严重的 MCP server。正确的做法是为 agent 重新设计;或者反过来,先想清楚一个人类要怎么操作这件事最舒服——人类舒服的接口,通常对 agent 也是好接口。
真正的瓶颈在 client harness:Progressive Discovery 和 Code Mode
如果说三件套是产品层选择,那么演讲下半场的工程层实操是另一个维度——具体怎么构建一个能用好这套连接器的 agent。这部分有两个核心技术点。
第一个是 Progressive Discovery(渐进式发现)。今天大部分 agent 实现里,所有 tool definitions 在对话开始前就被一次性塞进 context window。tool 数量稍多,context 立刻爆——这是 MCP 被诟病"太烧 token"的核心原因之一。但这其实是 client 实现的问题,不是协议的问题。协议负责把 tool 信息放在 wire 上,client 决定加载策略。
正确的做法是给模型一个 "tool search" 工具,让模型在需要时自己查找可用 tool 并按需加载。Anthropic API 已经把这个能力做进去了,演讲里展示的 Claude Code 前后对比图,context usage 有非常显著的下降(具体数字未给出,但视觉上是数量级差距)。这套思路在 OpenAI 的 Responses API 里也有类似机制,Cursor 等客户端在做自己的版本。
这件事对做 MCP client 的开发者意味着:不要再用"全量塞 context"这种朴素实现。给模型一个 tool 检索工具,让它自己 discover 自己需要什么。这会让你的 agent 在面对几十个甚至上百个 MCP server 时仍然可用——而这正是 enterprise 部署的常态。
第二个核心技术点是 Programmatic Tool Calling,也称 Code Mode。这是过去几个月 frontier 实验室和高级 agent 框架共同收敛的方向。
它解决的问题是:今天大部分 agent 的执行模式是"调用 tool → 收结果 → 交给模型 → 模型决定下一步 → 再调用 tool → ……"这种线性 orchestration。每一步都消耗一次 inference,每一次模型上下文都要重新加载之前的全部结果。模型在 orchestrate,但 orchestrate 这件事本来不需要模型——它需要的是代码。
正确的做法是给模型一个 REPL 工具——比如 V8 isolate、MOND 沙箱、Lua interpreter——以及关于可用 tool 的类型信息(MCP 的 structured output 直接就提供了这一点)。然后让模型自己写一段脚本,把多个 tool call 在脚本里组合好,一次性执行,只把最终结果交回。这等于把模型从"orchestrator"角色改成了"程序员"角色——orchestration 由它写出来的代码完成,而不是由它逐步推理完成。
这套思路在 Cloudflare 的 MCP server 里被推得最激进——它干脆不直接暴露 tool,而是给模型一个执行环境,让模型自己写代码调用。Anthropic 的 Claude Code 在写 bash 命令组合多个动作时,本质上做的是同一件事。这套设计的代价是必须有沙箱(执行环境)和良好的类型信息;收益是 token 用量、延迟、可组合性都数量级提升。
需要注意的是,Code Mode 不是 MCP 独有的概念——它是更普遍的 agent 设计 pattern。但 MCP 的 structured output 让 Code Mode 更容易做,因为类型信息天然存在,模型不需要先调用一次 tool 才知道返回值长什么样。如果服务端没有 structured output,演讲里给的兜底方案是"用便宜模型先把返回值整理成期望的类型"——但这显然只是过渡。
把 Progressive Discovery 和 Code Mode 放一起,你得到的是连接器使用层面的"成熟 agent"——它不会因为多接几个 MCP server 就 token 爆炸,也不会因为任务复杂就被 inference 链拖死。演讲者的判断很直接:这两件事我们做得还不够,这是 2026 年 client 工程的主要补课。
协议路线图与还没修好的部分
最后一部分是 Anthropic 这边对 MCP 协议本身的路线图,以及演讲者明确点出的"还没修好"的部分。
还没修好的第一件事是 streamable HTTP 难以 scale。演讲者直接承认,目前的 streamable HTTP transport 对大型 hyperscaler(意指 AWS、GCP、Azure 这类规模的部署)非常不友好。Google 那边正在主导一个名为 stateless transport 的新协议,目标是让 MCP server 可以像普通无状态 REST server 一样部署到 Cloud Run、Kubernetes 这种环境。原话给出的预期上线时间是"6 月"——结合演讲时点(2026 年初),意思是 stateless transport 大约 2026 年中之前会落地。这是一件对 enterprise 部署影响巨大的事:之前在大规模生产部署上踩坑的团队,可以在这条路径上等一等再决策。
还没修好的第二件事是 async task primitive。这是 MCP 用来支持 agent-to-agent 通信的基础设施,目前是非常实验性的状态,只有少数 client 支持。Anthropic 的计划是推动更多 client 实现这个 primitive,并改进协议本身。这一项的重要性在于,真正的多 agent 协作不会在一个进程里完成——必须有跨服务的、异步的、可恢复的通信机制。MCP 想成为这层基础设施,但目前还不是。
还没修好的第三件事——也是演讲里最直接的自嘲——是官方 Python SDK 不如社区的 fastmcp 好用。演讲者明确说 "that's on me because I wrote the Python SDK"。Anthropic 的方案是直接做 TypeScript SDK v2 和 Python SDK v2,基于过去一年的经验教训重写,并请更好的 Python 开发者参与。这种公开承认"我们写的不如别人写的"在协议组态度里其实是健康信号——它意味着规范定义层和参考实现层是分开演进的,社区 SDK(fastmcp)的设计经验会被吸收进官方 v2。对做基于 MCP 产品的团队来说,这意味着 SDK 层在 2026 年内会有一次重大版本切换,接入层应该预留迁移空间。
还在路上的几件正向工作同样值得关注。第一是 Cross-app access——Anthropic 正在和 Okta、Google Identity 这类身份服务商合作,做企业级单点登录:登录一次本地公司 IdP 之后,所有 MCP server 都不需要重新登录。这是 enterprise 部署的关键阻力之一,演讲明确说这件事正在和 IdP 厂商共同推进。第二是 Server discovery via well-known URLs——agent 可以扫一个网站的 well-known URL,自动发现这个网站是否提供 MCP server,结构上类似 robots.txt 的发现机制。这件事在演讲里被点名为"6 月下个 specification 版本"会发布。这意味着以后做 agent 的 crawler 不只能解析 HTML,还能直接用更结构化的 MCP 接口拿数据。
第三是 extension mechanisms 正在被启用——具体两个例子是 MCP applications(只有 web 客户端会支持,因为 CLI 渲染不了 HTML)和 skills over MCP(让 server 自己 ship knowledge 给 client,不依赖 plugin 机制和 registry)。skills over MCP 现在已经有人做实验性版本——只要给模型一个 load_skills tool 就能跑起来,只是没有官方语义。Anthropic 的计划是把语义定义清楚,让这件事标准化。这件事如果落地,意味着 server 作者可以在不发布新 SDK、不依赖 plugin 系统的前提下,持续推送"该怎么用我"给客户端——这是当前 MCP 没有解决的一个真实痛点。
把这一节放一起看,MCP 当前状态是:协议层面已经被广泛采纳,但实现层面有几个明确的补丁要打——transport 要重写,SDK 要重写,A2A 要落地,enterprise 身份要打通。这些都是 2026 年内的事。如果你正在做基于 MCP 的产品,值得在版本演进上预留迁移空间——比如 Python SDK v2 出来时可能要做接入层重写;stateless transport 上线后,部署架构可能要调整;skills over MCP 标准化后,你可能要把当前 ad-hoc 的"操作手册"嵌入方式重做一遍。
更广义的判断是,2026 年内 MCP 会在协议层稳下来,但应用层会有一波明显的迁移成本。做产品决策时这一点应该算进去——尤其是那些把 MCP server 已经放在生产路径上的团队。