第二个信号是大规模部署 MCP 服务器的技术瓶颈已经迎来了关键推进。
David 表示，在谷歌团队的参与之下，无状态传输协议取得了新进展，它可以让 MCP 服务器像传统的无状态 REST 服务一样，更容易规模化地部署到 Cloud Run、Kubernetes 等环境中。这项能力预计会在 6 月推出，并很快进入各类 SDK。
第三点是 server discovery 机制，未来 Agent、浏览器可以自动发现网站背后的 MCP 服务，这相当于为 Agent 打开了一层“隐形 API 网络”。此外，cross-app access 的出现也说明 MCP 正在补齐企业级身份与权限体系，这一步直接关系到能否进入真实业务环境。
此外，在分享的路线图中，还有一点值得注意：Skills over MCP。它将领域知识直接随服务器分发，而插件和注册中心的角色则被弱化了。
等等，还有不少如 A2A、技术原语等技术机制上的细节演进方向，这里不再一一展开了。
总之，David 的整场分享，可以说颠覆了过去人们对于 MCP 的想象空间，尤其是其明确表示：未来 MCP 应用，将主要运行在 Web 环境，很明显，这一点 CLI 就无法很好支持。
这也间接说明，Anthropic 内部已经开始押注“Agent + UI”的形态。
总之，大家 enjoy Anthropic 最新构思版的 MCP 吧！
未来感的MCP应用：
无需插件，自带界面
欢迎大家，我们开始吧。这是一个 MCP 应用。它是一个带有自身界面的 Agent，并不是通过插件，也不是通过 SDK，也不是在客户端由模型即时渲染，或者被硬编码进产品里的东西。它是通过一个 MCP 服务器提供的。你可以把这个服务器部署到云端，也可以接入 ChatGPT，或者放进 VS Code Cursor 里，它就可以直接运行。我觉得这点很有意思，因为要做到这一点，你需要一些当前生态里很多东西还不具备的能力。
你需要语义层，需要客户端和服务器双方都理解彼此在说什么，理解如何去渲染，理解即将出现的是一个 UI。
为此，你需要一个协议。而最关键的是，一个 MCP 服务器不仅可以提供一个应用，它还可以同时提供工具。这样一来，人类可以通过应用与它交互，模型也可以通过工具与它交互，这是一种我们还没有充分探索过的、非常独特的能力。
好，我们稍微回顾一下。从我刚才展示的这个我认为非常有未来感的 MCP 形态。
过去 18 个月 MCP 生态的演进：
从本地工具到远程支持、MCP 应用
往回看，大约一年多前，在 AI 的时间尺度里 18 个月已经很久了。当时这些都还不存在，只有一份简单的规范文档、几个 SDK，大多由 Claude 写的，只能在本地运行，功能也基本只是工具。
而在过去的 12 到 18 个月里，大家做了大量疯狂的构建工作，搭建服务器、构建生态。同时我们这边也在忙着把原本只能本地运行的能力扩展成支持远程、加入集中式授权、增加像 elicitation 和 tasks 这样的新原语，以及最后引入大家刚刚看到的 MCP 应用这样的实验性特性。
生态增长与采用里程碑
与此同时，我们达成了一个很有意思的里程碑，因为大家一直在疯狂地构建，当然也得益于各种 Agent 的帮助。现在我们大约达到了每月 1.1 亿次下载，而且这不仅仅是我们自己的客户端和服务器，还包括 OpenAI 的 Agent SDK、Google 的 ADK、LangChain，以及成千上万你甚至从未听说过的框架和工具，它们都把 MCP 作为依赖。这意味着我们现在拥有了一个统一的标准，可以彼此通信。
这里有一点对比背景：React 作为过去十多年里最成功的开源项目之一，达到这个下载量大概用了两倍的时间。
与此同时，大家还构建了很多非常有意思的服务器，从 WhatsApp、Blender 这种玩具项目，到 Linear、Slack、Notion 这样的 SaaS 集成，已经在支撑大家每天使用 MCP 的实际工作。但更重要的是，大多数 MCP 服务器其实都在“幕后”，连接企业系统与 Agent 和 AI 应用。
2026 Agent 迈向生产化的关键：连接性
不过我依然觉得这只是一个开始。我认为 2025 年是探索之年，而 2026 年将是把这些 Agent 真正投入生产的一年。
如果你回顾一下，在我看来 2024 年我们只是做了一堆 demo，展示了一些很酷的东西，带来了一点热度。
2025 年则是编码 Agent 的一年。而编码 Agent，其实是 Agent 最理想的应用场景：它是本地的、可验证的，你可以调用编译器，有开发者在电脑前随时修复问题，还可以提供一个界面，用户也会比较满意。但现在随着模型能力的提升，我们正在进入一个新的阶段。
今年会开始出现：我们不再只是做编码 Agent，而是会有通用 Agent，去完成真正的知识工作者任务，比如金融分析师、市场人员需要做的事情。而他们真正需要的，并不是一个调用编译器的本地 Agent，他们需要的是能够连接多个 SaaS 应用和共享存储的能力。
对他们来说，Agent 最关键的是“连接性”。而在我看来，连接性从来都不是单一方案。如果有人告诉你有一个万能的连接解决方案，无论是 computer use 还是 MCP，那基本是站不住脚的，因为现实是要看具体场景。
2026 的Agent技术栈：
Skills、MCP 与 CLI/Computer Use
在我看来，2026 年构建 Agent，需要重点考虑三件事：skills、MCP，以及 CLI 或 computer use（取决于你的具体场景）。这三者各自解决完全不同的问题。
首先，skills 本质上就是领域知识，把特定能力封装进一个非常简单的文件里，而且大多数是可以复用的，不同平台之间可能有一些细微差别。
其次，CLI 在本地编码 Agent 场景中非常流行，它是一个很好的起点，你可以在 bash 中组合各种能力，让模型自动发现 CLI 能做什么。
最重要的一点是，如果你的系统里有类似 CLI 的东西，比如 GitHub、Git，或者其他已经出现在预训练数据中的工具，那么 CLI 在连接性这一层是一个非常优秀的解决方案。尤其是在本地 Agent 场景下，你可以假设有一个沙箱环境，有代码执行环境，这种情况下 CLI 非常适合。
但如果你没有这样的条件，如果你需要更丰富的语义，需要一个可以展示长时间运行任务的 UI，需要资源管理能力，需要构建一个完全解耦、平台无关的系统，或者你没有沙箱环境，又或者你需要授权、治理策略这些企业级能力，甚至你想做 MCP 应用或未来基于 MCP 的 skills 这样的实验，那 MCP 就像是一层额外的“连接组织”，是你工具箱里的一种补充能力。
总结来说，我认为 2026 年我们会开始构建同时使用这些能力的 Agent，它们不会只依赖一种方式，而是会把这些能力无缝结合在一起。
不过我们还没有完全走到那一步，因为还有很多东西要做。一方面是因为现在的 Agent 还不够好，另一方面是我们还没有充分讨论如何把这些连接能力真正组合起来。
上下文膨胀如何解决？（一）
改进客户端框架：渐进式发现
我们首先需要做的是在客户端这一侧，也就是 Agent 的执行框架这一侧去建设，无论是 cloud code、API，还是你正在构建的任何应用，这些都是连接能力的核心。
而第一件必须做的事情，是引入一种叫“渐进式发现”的模式。很多人在谈到 MCP 时，会想到上下文膨胀问题。但如果你认真看协议本身，它只是负责把信息传输过去，真正处理这些信息的是客户端。
而目前大家在这个早期探索阶段的做法，是把所有工具直接塞进上下文窗口，然后再惊讶于上下文变得很大。其实你应该采用“渐进式发现”模式，比如使用工具搜索（tool search），把工具的加载延迟到模型真正需要的时候再进行。我们已经在 Anthropic 的产品和 API 中提供了这种能力，其他厂商的 API 也可以实现这一点，甚至你可以自己实现：只在需要时动态加载工具。
你可以给模型一个“工具加载工具”，当模型判断需要某个工具时，再去查找并加载。这样就可以按需加载工具。在这个例子中，左边是引入该机制前的 cloud code，右边是引入之后，你可以看到工具上下文的使用量大幅下降。
上下文膨胀如何解决？（二）
程序化工具调用与 Agent 编排
第二点是所谓的“程序化工具调用”，也就是很多人说的 code mode。核心思想是：你需要把能力组合起来，而不是让模型一次调用一个工具，拿到结果，再调用下一个工具，再拿结果，这样其实是在让模型负责整个编排流程，而这个过程依赖推理，不仅延迟高，而且效率低。很多事情如果写成脚本会更高效。事实上，你在使用 cloud code 写 bash 命令时已经在做这件事了。这个思路同样适用于 MCP，而且你应该这样做。
具体来说，你不应该让模型逐个调用工具，而是给它一个执行环境，比如 V8 isolate、Monty、Lua 解释器等，让模型直接生成代码并执行，由代码来完成组合。
MCP 里有一个很有用的特性叫“结构化输出”，它会明确返回值的类型，模型可以利用这些信息推断类型，从而更优雅地组合不同工具。
在这个例子中，你不再需要两次调用，而是一次调用并完成过滤，模型可以自动处理 JSON 并继续执行。如果没有结构化输出，你也可以让模型调用一个便宜模型，把结果转换成结构化格式，这样同样可以实现类型推断与组合。这一块目前我们做得还不够，是一个可以显著提升 Agent 框架的方向。除此之外，你还可以把这些能力和 CLI、其他组件、API 等一起组合使用。
上下文膨胀如何解决？（三）
Agent 与服务器设计的最佳实践
除了客户端的改进（渐进式发现和程序化工具调用），我们还需要开始真正为 Agent 去设计系统。这意味着要停止把 REST API 一比一地搬进 MCP 服务器。每当我看到有人在做 REST 到 MCP 的转换工具，我都会觉得有点问题，因为这通常会导致非常糟糕的结果。更合理的方式是从 Agent 的角度来设计。
你可以先从人的使用方式出发，思考如果是你自己，会如何与这个系统交互，这其实是一个很好的起点。如果你需要做复杂编排，可以在客户端使用程序化工具调用，也可以在服务器端实现。像 Cloudflare 的 MCP 服务器就是一个很好的例子：它不是提供一堆工具，而是提供一个执行环境，让模型在里面完成编排，这样可以减少 token 消耗、降低延迟，同时组合能力更强。
最后一点，作为服务器开发者，你应该更多利用 MCP 提供的丰富语义能力，比如直接发布 MCP 应用、在 MCP 上发布 skills，使用 tasks、elicitation 等当前还没有被充分利用的能力。这些是 MCP 独有的优势。当然，这不仅是你们需要做的事情，我们在 MCP 本身也还有很多工作要推进，接下来还有不少问题需要解决。
MCP 协议的2026路线
谷歌也参与进来了，三大核心改进
首先我们需要改进核心能力。过去一年在协议演进过程中，有一些地方还不够成熟。第一个问题是当前的 streamable HTTP 在大规模超大云厂商场景下很难扩展。
因此，我们和 Google 的团队一起提出了一个方案，叫做“无状态传输协议”（stateless transport protocol），它可以让 MCP 服务器像传统的无状态 REST 服务一样，更容易部署到 Cloud Run、Kubernetes 等环境中。这项能力预计会在 6 月推出，并很快进入各类 SDK。
除此之外，我们还需要改进异步任务（asynchronous task）这一原语，本质上就是实现 Agent 与 Agent 之间的通信。目前这个能力还比较实验性，支持的客户端也不多，所以我们会推进更多客户端支持。
同时，我们还会完善一些细节语义。我们将发布 TypeScript SDK v2 和 Python SDK v2，这些都基于过去一年的经验教训。比如现在有一个叫 FastMCP 的 SDK，比我们当前的 Python SDK 好很多，这一点我得承认，因为 Python SDK 是我写的。所以我们也邀请了更专业的 Python 开发者来一起改进它。第二个方向是更广泛的集成能力。
战略集成与企业能力
我们会推出一个面向企业的重要能力，叫做“跨应用访问”（cross-app access）。它本质上是与身份提供商（identity providers）深度集成，比如 Google 或 Okta。一旦你通过企业身份登录一次，就可以直接使用 MCP 服务器，而不需要反复登录，这会让体验更加顺滑。
此外，我们还会引入“服务器发现”（server discovery）机制，通过标准化的 well-known URL，让爬虫、浏览器、Agent 在访问网站时，不只是解析网页内容，还能自动发现是否存在可用的 MCP 服务器。这项能力同样计划在 6 月随新版本规范一起发布。最后，我们也开始引入扩展机制（extension mechanisms）。这意味着不同客户端可以支持不同扩展，比如 MCP 应用主要会在 Web 界面中支持，因为 CLI 很难渲染 HTML。
分发：扩展机制与 Skills over MCP
我们会继续推进这些扩展。其中一个很值得期待的方向，是在 MCP 之上直接分发 skills。
这个逻辑其实很自然：当你有一个包含大量工具的 MCP 服务器时，你希望同时提供领域知识，告诉模型这些工具应该怎么用。这让服务器开发者可以持续更新 skills，而不需要依赖插件机制或注册中心。
目前已经有很多人在这个方向上做实验，其实你今天就可以实现类似能力，比如给模型提供一个“加载 skills”的工具。当然，我们也会把这件事标准化，定义清晰的语义。
2026，Agent 关键词：链接
MCP会继续扮演关键角色
总结一下，我啰嗦讲了这么多，是想表达 MCP 其实已经处在一个很不错的阶段。今年我们会把 Agent 推向“全面连接”的阶段。
MCP 会继续扮演非常关键的角色，同时我们也非常需要社区的反馈。我们是一个开放的社区，刚刚成立了基金会，整体以开源方式运作，有 Discord、有 issue，欢迎大家直接告诉我们哪里做得不对，哪里做得不错，这样我们才能持续改进。
我认为 2026 年的关键词就是“连接性”，而最优秀的 Agent 会同时使用所有可用手段：computer use、CLI、MCP、skills，它们需要尽可能丰富的能力组合，才能构建出真正有价值的应用。比如我们最近发布的一个产品功能，本质上就是一个 MCP 应用，在底层负责渲染各种内容。
