MCP 时代:Model Context Protocol 如何在 2026 年悄然重塑 AI 应用

Anthropic 在 2024 年底发布了 Model Context Protocol。大多数人把它归进“又一个标准”就翻篇了。十八个月后,MCP 已成为 AI 应用栈事实上的管道层。Claude Code 是 MCP 优先的。Cursor 在一次会话里同时跑多个 server。Linear、Figma、Notion、GitHub、Slack 和 Stripe 都发布了官方 server。这个协议赢了。

这是一份实战入门加现状报告。MCP 在传输层到底是什么,它为什么击败了此前的标准,生产环境中的标准 server,该拿它做什么,以及它还在哪里栽跟头。

MCP 是终于对上口的那根线缆

Model Context Protocol 让任何 AI 客户端都能通过标准 server 与任何工具或数据源对话。在 MCP 之前,每一次集成都是定制的。每个客户端发明自己的工具格式。每个工具为每个客户端写一份定制适配器。组合爆炸的成本压得人喘不过气,大多数开发者干脆放弃,硬编码几个集成了事。

MCP 把这一切压平了。server 只需构建一次,任何 MCP 客户端都能使用。客户端只需构建一次,任何 MCP server 都能连上。在对的时间选对了原语,在开放环境中治理,Anthropic 负责协议工作,但并不拥有这个标准。

MCP 在传输层到底是什么

MCP 就是跑在某种传输之上的 JSON-RPC,外加一小组标准原语。server 暴露资源(模型可以读取的数据)、工具(模型可以调用的动作)和 prompts(用户可以触发的模板)。客户端对每个 server 都使用同样的方法:list、read、call。整个抽象就这么多。

JSON-RPC 无聊、人人熟悉、能用 curl 调试,而且能穿过有史以来建过的每一道防火墙。这种原语划分让模型有足够的结构去推断 server 能做什么,又不会逼 server 去套一个千篇一律的 schema。

三种传输方式及其意义

MCP 提供三种传输:stdio、HTTP plus SSE 和 WebSockets。Stdio 把 server 作为客户端的子进程运行,是 Claude Desktop 这类桌面客户端的默认方式。HTTP plus SSE 把 server 作为远程服务运行,客户端轮询并从中获取流式数据,适合云端 MCP server。WebSockets 则覆盖需要与远程 server 全双工通信的少见场景。

传输方式主要是部署选择,而不是能力差异。同一套 server 逻辑可以跑在这三种传输上。团队可以先在本地用 stdio 做原型,再在自家认证网关后面用 HTTP plus SSE 上线,无需重写协议层。

为什么 MCP 赢在此前标准输掉的地方

ChatGPT plugins、function-calling 规范和 OpenAPI-for-LLMs 都曾想成为 agent 工具标准。三者全都停滞了。MCP 之所以赢,是因为它在对的时间,用对的治理方式,选对了原语。

ChatGPT plugins 绑定了单一客户端和单一计费模式,其 manifest 假设的是无状态 HTTP 端点加 OpenAPI 规范,而几乎没有真实产品能干净地提供这些。各家实验室的 function-calling 规范是披着标准外衣的单一厂商格式。OpenAPI-for-LLMs 试图把文档格式硬改成运行时契约,阻抗不匹配把它压垮了。

对的原语:server,而不是 plugin

MCP 选择把集成做成一个长期运行、暴露类型化契约的 server,而不是无状态的 plugin manifest,这个架构决策是其他一切的根源。server 可以持有数据库连接、缓存资源、管理认证令牌、流式返回响应,还能在不破坏客户端的前提下发布更新。无状态 plugin 几乎一样都做不到。真实的集成需要状态、重试、可观测性和限流处理。server 扛得起这些。plugin 只会跟它们打架。

对的时机:tool use 之后,agent 栈之前

MCP 发布的时机恰到好处:开发者不再争论 tool use 重不重要,转而争论如何把十个工具接进同一个 agent,而不用每次发版都重写。tool use 已成定论。下一个问题是编排。MCP 给编排层提供了一个干净的抽象。

治理也帮了忙。Anthropic 开源了规范,开放了 GitHub 组织,从第一天起就接受外部贡献,并允许其他实验室无需许可就实现客户端。到 2026 年中,OpenAI 已在其 Assistants 栈中提供 MCP 支持。Gemini 通过 Gemini API 支持它。正是这顶大帐篷,把一个副业项目变成了标准。

生产环境中的标准 MCP server

一份简短的清单就扛起了大部分工作。2026 年的大多数 agent 栈,都是下面这九个的某种组合。

Figma 暴露 frame、组件、变量和图层树,所以模型读一个 frame 就像开发者读规格说明。Linear 暴露 issue、项目和周期,把 Claude Code 变成了了解项目的程序员。Notion 暴露页面、数据库和 block,成为通用的上下文存储。GitHub 暴露仓库、issue、pull request 和 actions,是标准的代码上下文入口。Slack 暴露频道、线程和搜索。Stripe 暴露客户、订阅、扣款和指标,财务与运营 agent 就是这样读账本的。

Postgres 暴露 schema、表和查询,带只读或读写范围。Filesystem 暴露一个沙盒目录,Claude Code 就是这样读写仓库的。Browserbase 通过 MCP 暴露托管的 Chromium 集群,agent 由此驱动浏览器而无需管理基础设施。九个 server,九成的 agent 工作。

主导局面的 MCP 优先客户端

Claude Code 是标准的 MCP 客户端。每一个集成都是一个 MCP server。添加工具就是编辑一个配置文件,指向某个 server 的二进制文件或 URL。Claude Desktop 提供同样的模型,并带有按工作区配置 server 的界面。Cursor 在 2026 年初加入了 MCP 支持,现在能在一次会话中跑多个 server,所以同一个能编辑代码的 Cursor 面板,也能拉取 Figma frame、创建 Linear issue、查询 Postgres。

Continue.dev 是 MCP 优先。JetBrains AI 加入了 MCP 支持。Zed 也发布了 MCP。每一个想被认真对待的 IDE 和 AI 客户端,现在都提供 MCP 支持,而没有 MCP 故事的产品已经开始显得过时。

设计师到底该拿 MCP 做什么

别再截 Figma 的图了。把你的工具暴露成一个 MCP workspace。Figma MCP server 给模型的是真实的 frame 坐标、真实的变量和真实的组件实例,而不是从图片里猜出来的像素值。

更大的动作是搭建一个统一的 MCP workspace。把 Figma、Notion 和你的 design tokens 仓库作为三个 server 接入 Claude Code。同一条要求“按规格构建这个组件”的 prompt,会读取 Figma frame,从 Notion 拉取设计理由,引用 token 文件,然后写出代码。这是 design system 第一次在 AI 工作流里真正表现得像一个连续的整体。同样的模式也适用于 Claude Skills,其中 Skill 是人设,MCP 是工作区。

开发者到底该拿 MCP 做什么

为团队拥有的每一个内部工具都做一个内部 MCP server。把 Claude Code 指向它。然后看着那个写代码的 agent 开始跑运维。2026 年胜出的模式不是“面向 X 的 AI 助手”,而是“团队用的每个工具都暴露成 MCP server,由一个客户端负责编排”。

想要帮助把 MCP 接进团队的工具,又不想在认证模型上白白耗掉一个季度,或者想上线一套能在生产环境扛住的内部 MCP server 栈?雇用 Brainy。ClaudeBrainy 提供 MCP server 模板和 prompt 库,AppBrainy 为希望 agent 共享真实工作区而不是截图的团队交付完整的产品构建。

这活儿并不光鲜。大多数内部 MCP server 就是对现有 API 的一层薄封装,加上认证,再加上一份资源和工具清单。几百行代码,团队的部署看板、错误追踪器、计费控制台或管理后台,就成了 agent 可以使用的又一个工具。接入十个 server 之后,agent 就是队友,而不是 chatbot。

MCP 还在哪里吃亏

多 server 编排的延迟、认证的复杂性,以及移动端故事的缺失,是 MCP 仍然栽跟头的三个地方,而那些把它们藏起来的演示,正是该无视的演示。

多 server 编排的延迟是真实存在的。一条 prompt 在一轮中同时涉及 Figma、Notion 和 Postgres,模型在获得足够上下文回答之前可能要付出三次往返,在较慢的传输上累计等待会超过五秒。缓存有帮助。连接池有帮助。但没有哪个能让延迟消失。

认证复杂性是第二个窟窿。MCP 没有标准化认证。每个 server 自选模型:OAuth、API key、带范围的令牌,有时什么都没有。把十五个 server 接进一个客户端,意味着十五个凭证存储、十五套刷新策略和十五条审计轨迹。大多数团队低估了这一点,直到第一次有客户数据 server 泄漏到非客户上下文里。

移动端的故事是缺失的。MCP 假设有一个长期运行的客户端,能够派生本地进程、保持网络连接并管理 server 生命周期。这些都不是移动端的执行模型。到 2026 年中,还没有真正好用的 iOS 版 MCP。少数团队正在做仅远程的配置,但协议还没到那一步。

被吹捧的 MCP 演示所隐藏的三种失败模式

2026 年大多数对 MCP 的后悔,都能追溯到同样的三个窟窿。

第一,认证糊弄式演示。演示者展示一个 server 连上了客户的 CRM,agent 作答,全场鼓掌。而那里的认证只是演示账号的个人令牌。把同样的配置指向多租户生产系统,就意味着要用带范围的凭证、OAuth 流程和租户隔离重建认证。解法:在上线 server 之前就选好认证模型,而不是之后。

第二,仅限本地的演示。一切都能在演示者的笔记本上跑通,因为 server 用 stdio 加本地文件系统和个人数据库。这些没有一样能交付给需要 HTTP plus SSE 和共享凭证的团队。解法:用 stdio 做原型,在你的认证网关后面用 HTTP plus SSE 上线,并在团队信任它之前测试部署流程。

第三,单 server 演示。agent 把一个 server 用得漂亮,演示者假装多 server 编排只是多加一行配置。在生产环境中,第二个和第三个 server 会带来延迟、认证冲突和 prompt 混乱。解法:把 server 集合当作一个系统来设计,而不是一份清单。写清楚边界。

按角色划分的第一步

团队中的每个角色,在 MCP 上的第一步各不相同。工作量分布并不均匀。

规律是这样的。设计师和前端开发者负责工作区的组装。后端开发者负责 server 契约和认证模型。创始人负责选定赛道。

FAQ

什么是 Model Context Protocol?

MCP 是一个开放协议,让任何 AI 客户端都能通过标准 server 与任何工具或数据源对话。server 暴露资源、工具和 prompts。客户端通过 stdio、HTTP plus SSE 或 WebSockets 说 JSON-RPC。Anthropic 在 2024 年底发布了规范,到 2026 年中,它已是事实上的 agent 工具集成标准。

MCP 只适用于 Claude 吗?

不是。Cursor、Continue.dev、JetBrains AI、Zed 和 OpenAI 的 Assistants 栈都支持 MCP。Gemini 通过 Gemini API 支持它。Anthropic 发布了这个协议,但并不拥有它。

我需要自己写 MCP server 吗?

对于标准工具,多半不需要。Figma、Linear、Notion、GitHub、Slack、Stripe、Postgres、Filesystem 和 Browserbase 都提供官方或标准 server。内部工具、自定义数据库和专有 API 则需要你自己写。大多数内部 MCP server 就是几百行代码加一个认证模型。

MCP 和 tool use 有什么不同?

tool use 是模型侧的能力,即用结构化的输入输出调用函数。MCP 是定义工具如何在任意客户端之间被发现、描述和调用的协议。tool use 是引擎,MCP 是接线。computer use agents 入门篇讲了第三条腿,也就是没有干净 API 可调用的时候。

什么时候 MCP 没有意义?

当你只有一个工具、一个客户端,而且硬编码的集成已经能用的时候。MCP 的价值在多工具、多客户端的世界里。对于一个 agent 加一个 API,普通的 tool use 就够了。

MCP 真正解锁的转变

MCP 不是更聪明的 agent。它是终于让 agent 共享工作区的协议,而把这个工作区当作其核心界面的产品,将赢下下一轮。

大多数团队仍把 AI 集成当作硬塞进产品的一个功能。领先的团队则把 AI 客户端加一组 MCP server 当作工作区,而产品只是出现在边缘的东西。前者多做了一个聊天标签页。后者做出了团队真正会用的工具。同样的转变也出现在 AI 代码编辑器对比和 Claude 4.7 for builders 的拆解中。

如果你的技术栈这个季度还没有 MCP 的故事,你的客户所用的 agent 会直接跳过你。如果有,这些 agent 就会开始把你的产品当作队友。选好工作流。上线 server。接好工作区。

如果你想要帮助把 MCP 接进团队的工具,又不想在认证模型上白白耗掉一个季度,或者想上线一套能在生产环境扛住的内部 MCP server 栈,雇用 Brainy。ClaudeBrainy 提供 Skill 包和 MCP server 模板。AppBrainy 为希望 agent 共享真实工作区而不是截图的团队交付完整的产品构建。