我叫 Lena——只是一个花了很多时间坐在 AI 系统旁边，看它们怎么运作的人。
读我文章的人，通常不是来这里找一个现成答案的。很多人都在搭 agent、在排查总会卡在同一个地方的 workflow，想让系统更可靠一点，又不想一直在旁边盯着。大家其实都很聪明，只是希望有人能陪着，把事情认真想清楚。
这篇文章想讲一个词：MCP。
最近它几乎到处都在出现。开发者论坛、工具文档，凡是聊 AI agent 如何接到外部世界的地方，几乎都会提到 MCP。但我一直注意到一件事：很多人会用这个词，却很少有人真的坐下来，把它到底在做什么讲明白。
所以。MCP 到底是什么？它解决了什么问题？它的边界又在哪里？
我从它刚发布时就开始留意这个协议。有些地方，现在我已经觉得很清楚了。还有些地方，我还在继续琢磨。但有一件事我基本能确定：只要你在做任何跟 AI agent 有关的事，MCP 都不是一个可以直接跳过去的东西。
我们从头开始。
这篇文章会讲这些：MCP 是什么、它怎么工作、哪些人已经支持它、生态里现在有什么，以及它真正的限制在哪里。不默认你有技术背景，但也不会把问题讲得太轻。
MCP 是什么？
MCP — Model Context Protocol 由 Anthropic 提出，目标是标准化 AI 系统与外部工具的交互方式。落到实际开发里，开发者会用 MCP server 把文件访问、API 等能力暴露给 Claude 这类 agent。这是技术层面的答案。真要说它在现实里意味着什么，大概是这样：
在 MCP 出现之前，每次你想让 AI 助手去碰一样东西——数据库、日历、GitHub 仓库、网页搜索——你都得自己写一套连接器。从零开始。每个工具一套，每个平台一套。如果你一边在 Claude 上开发，一边又在用 GPT-4，基本等于所有东西都要写两遍。
MCP 当初是为了解决什么问题
你可以把这件事想成 USB-C 出现之前的充电线。每台设备都有自己的专有接口。你有三台设备，就得备三根不同的线。单看每根线都能用，但作为一个系统，它完全是一团乱。
在 MCP 出现之前，开发者往往得为每个 data source 或工具各自做一套连接器，最后就变成 Anthropic 所说的 “N×M” 数据集成问题——如果你有 N 个 AI 系统和 M 个工具，理论上就要做 N 乘 M 种不同集成。重复劳动非常多。
MCP 在 2024 年 11 月由 Anthropic 公布，定位是把 AI 助手连接到数据系统的开放标准，覆盖内容仓库、业务管理工具和开发环境等场景。它从第一天起就是 open source 的，这一点后来被证明非常重要——也正因为如此，它才会传播得这么快。
MCP 如何工作：基本架构
说到底，MCP 建立的是一种共同语言。它给应用提供了一套标准方式，用来读文件、执行函数，以及处理带上下文的 prompts。
这个协议构建在 JSON-RPC 2.0 之上——一个很成熟、很轻量的远程过程调用标准。它还借用了 Language Server Protocol（LSP）的消息流思路，也就是让 VS Code、Vim 等编辑器里的代码智能能在不同工具之间保持一致的那套协议。如果这套架构听起来有点熟悉，那是因为它确实已经被证明过行得通：一套标准，多种实现。
最关键的心智模型是这个：MCP 不会改变 AI model 能 想 什么，它改变的是它们能 够到 什么。
altexsoft 绘制的 MCP 架构图
MCP Servers 和 MCP Clients
一旦把 MCP 的两侧想明白，后面的很多东西就会自动对上。
MCP server 做什么
一个 MCP server 是一段用标准方式暴露能力——tools、data 和 resources——的软件。谁拥有这项能力，谁就来实现这个 server。GitHub 为 GitHub 做了 MCP server。Stripe 做了支付相关的。Figma 做了设计文件相关的。
**server 决定暴露什么。**它会定义 AI 能调用哪些 tools、能读哪些 data、被允许执行哪些动作。权限控制也在这一层。
MCP client 做什么
一个 MCP client 就是你实际对话的那个 AI 应用。Claude.ai 是 MCP client。ChatGPT 桌面应用是 MCP client。Cursor（那个 AI 代码编辑器）也是 MCP client。当你让它去“看看我的 GitHub issues”或者“查一下我的 database 里有什么”，真正发起调用的就是 client 这一层，它会去找对应的 server。
这里最关键的是分层很干净：client 不需要知道 GitHub 的 API 内部到底怎么运作。它只需要会说 MCP；真正把请求翻译成 GitHub 自己系统语言的，是 server。
发现和连接是怎么发生的
这一块还在继续成熟。现在如果你想知道一个 MCP server 能做什么，通常得先连上去。这样一来，client 很难浏览有哪些 server 可用，像 registry 这种系统也很难自动把能力编目起来。
MCP 团队正在推进这件事。他们的路线图里包含让 server 通过 .well-known URL 主动“自我介绍”——某种意义上，就是给每个 server 发一张面向外界的“名片”，让 client 不用真正连上去，也能先读到它的基本信息。就像网站会发布 metadata，让搜索引擎不必完整加载页面也能先理解一些内容。
现在的发现过程大多还是手动的：你先在 MCP client 里配置 server URL，完成鉴权，然后 client 会在连接建立时学到有哪些 tools 可用。MCP 使用 OAuth 2.1 做认证，这意味着你会明确授权 AI 能做什么、不能做什么。没有你的许可，它不能直接在你的账号上替你行动。
谁在支持 MCP，生态里又有什么
模型提供方（已验证）
这里的采用速度，不管按哪个标准看都很快。MCP 公布之后，OpenAI 和 Google DeepMind 在内的主要 AI 提供方都陆续采用了这个协议。
Anthropic 在 2024 年 11 月推出 MCP，并且当天就 open source。到 2025 年 1 月，Cursor、Windsurf 这类 AI 开发工具已经加上支持。2025 年 3 月，OpenAI 正式采用；Google DeepMind 随后跟进。Microsoft 也宣布了 Windows 层面的 MCP 支持，并把它整合进 Azure 和 Semantic Kernel。
到了 2025 年 12 月，治理层面又发生了一个很大的变化。Anthropic 把 MCP 捐给了 Agentic AI Foundation——这是 Linux Foundation 下面的定向基金，由 Anthropic、Block 和 OpenAI 共同发起。这个动作很重要：它让 MCP 从 “Anthropic 的协议” 变成了 “整个 AI 行业的协议”。
到 2026 年初，2025 年 11 月发布的现行规范，已经成了各大提供方共同对齐的稳定基线。SDK 也已经覆盖 Python、TypeScript、C# 和 Java。
社区 MCP server 生态
这部分很快就变得有意思起来。到 2026 年 3 月，MCP 的 SDK 月下载量已经达到 9700 万，社区构建的 server 超过 5,800 个。
去看一眼 官方 MCP server registry，你会很直观地感受到它的广度：GitHub（仓库管理、issues、PRs）、Stripe（支付和客户）、Figma（设计上下文）、PostgreSQL（数据库查询）、Slack（团队沟通）、AWS 服务、Kubernetes 管理、Elasticsearch，以及更多更多。
MCP steering group 维护的 reference server 仓库，目标只是放少量参考实现，用来展示 MCP 特性和 SDK 的用法——更像给开发者看的教学样例，而不是可以直接拿去生产的方案。真正热闹的地方，还是社区 server，以及大平台自己的官方集成。
一个很现实的安全提醒：MCP 规范要求 tools 真正运行前要经过用户批准，但并不是每个 host 在早期实现里都把这一步做对了。恶意 server 响应触发的 prompt injection 是真实风险——如果某个 MCP server 被入侵，它完全可能通过输出内容去操纵 AI 的行为。所以，连任何新的 MCP server 之前，尤其是社区项目，一定要先看清楚你到底授权了什么。
MCP 能解决什么，又解决不了什么
这一段经常被轻轻带过，但老实说，最有意思的问题反而都在这里。
连接，不等于能力持久化
MCP 解决的是 连接。而且解决得很优雅，可扩展，也得到了很广泛的行业认同。这一点确实重要。
但 MCP 不解决的，是一次成功连接之后会发生什么。想想一个典型的 agent workflow：AI 连上某个工具，发起调用，拿到结果，再根据结果生成输出。然后对话结束——或者上下文窗口被塞满——session 终止。
tool call 确实发生了，结果也确实被用上了。但这次交互到底是怎么走通的，并不会以一种可持久、可复用的形式被保留下来。
等你下一次再开一个 session，同一个 agent 对上次什么有效、什么失败、哪一串 tool calls 得到了最好结果，统统没有记忆。它会重新开始。可能还会再犯一遍同样的错。也会重走一遍差不多的搜索路径。这不是 MCP 本身的缺陷——只是它的职责范围之外。
为什么一次成功的工具调用变不成可复用的知识
举个更具体的例子。假设你让一个 AI agent 去 debug 代码库里反复出现的问题。它连到 GitHub MCP server，读了几份文件，跑了几次搜索，来回试了几轮，最后找到 root cause，还给出一个修复方案。这次它成功了。
两周后，同一类问题又出现了，只是版本略有不同。agent 再次通过 MCP 连到 GitHub——协议没变，标准没变，连接依然可靠。但它对上次是怎么想出来的，没有任何记忆。那条成功的排障路径，没有被结构化地存起来。另一个 agent 也没法直接继承它。这个解法最后只活在一段已经关闭的对话里。
这不是在否定 MCP。它确实完成了自己该做的事：为 AI 系统和外部工具之间提供一个标准化、可靠的接口。MCP 早就不只是本地工具接线的那套东西了——它现在已经在大大小小的公司里跑在生产环境中，也确实在支撑 agent workflow。这是实打实的进步。
但“连接基础设施”和“能力持久化”本来就是两个不同的问题。MCP 解决的是前者。后者，才是下一代 agent 基础设施真正聚焦的地方。
局限与取舍
看着这个协议一路成熟下来，我有几条比较坦白的观察。
有状态的 server 扩展起来，还是麻烦。 现在很多实现都需要在请求之间记住一些东西，这就让你很难把它们横向扩到多台 server 实例上。虽然 Streamable HTTP transport 已经提供了一部分无状态支持，但 server 启动和 session 处理这两块，痛点还在。2026 年路线图已经在正面处理这个问题，如果你打算做大规模生产部署，这点值得提前知道。
企业级认证还在补课。 规范已经支持基于 OAuth 的授权，OAuth 2.1 的企业集成也在 2026 年路线图里。但对那些身份提供方要求很严、合规边界很重的行业来说，空白仍然有一些。企业已经开始大规模部署 MCP，也确实在撞上同一批问题：审计链路、SSO 集成认证、网关行为，以及配置可移植性。
安全责任更多落在实现者身上。 MCP 自身没法在协议层面强制执行安全原则——实现者必须自己把 consent 和 authorization flow 做扎实，把安全影响讲清楚，并加上合适的 access control。这个设计选择本身并不离谱——协议因此能保持轻量——但代价就是，生态里不同实现之间的安全质量差异会非常大。
发现过程现在仍然主要靠手动。
就像前面说的，你通常得先知道自己想连哪些 server，才能去连接它们。registry 预览和 .well-known URL 会缓解这个问题，但就眼下来看，这仍然是新用户探索生态时最明显的摩擦点之一。
社区 server 的质量差异非常大。 5,800+ 个 server，跨度当然也非常大。有些是公司自己维护的——像 GitHub 的 server、Stripe 的 server——安全和维护都有人盯着。也有一些只是社区实验项目。对待陌生 server，最好和对待任何第三方代码一样：先看清楚你到底准备交给它什么权限。
FAQ
MCP 只适合开发者吗？
也不完全是，但你今天大多还是会在开发者工具里遇到它——例如 Cursor、Windsurf 这类代码编辑器、AI IDE，或者 agent framework。随着越来越多应用把 MCP 支持 内嵌进去，终端用户以后很可能在完全没意识到的情况下就已经在用它了。
用了 MCP，是不是就代表 AI 能在我的电脑或账号里为所欲为？
不是。每个 MCP server 只会暴露它的开发者选择暴露的那部分能力，而你会显式授权访问。连接建立之后拿到的不是无限权限，而是那个 server 定义过的具体能力。话虽如此，连任何新 server 之前，先检查你准备授权什么，始终是个好习惯。
MCP 和普通 API call 有什么差别？
普通 API call 的前提，是 AI 系统必须被专门编程去调用那个 API——自定义代码、写死的 endpoint、单独处理认证。MCP 把这些都标准化了，所以任何兼容的 AI client 都能跟任何兼容的 server 对话，双方都不用再为彼此写定制代码。它有点像：不是给每个 USB 设备都重新写一遍驱动，而是大家共享同一套 USB 协议。
MCP 能跨不同 AI 模型工作吗？
是的。这正是它最重要的属性之一。MCP 提供的是一层通用接口——企业把一个 MCP server 搭好后，只要某个 AI assistant 会说 MCP，不管是 Claude、ChatGPT 还是别的模型，都能连上去。
MCP 和 function calling 有什么区别？
Function calling（有时也叫 tool use）是某个特定 model 调用工具的机制。MCP 则是更上面那层标准协议——它定义的是 tools 如何被发现、如何被描述，以及如何在不同 system 之间通信。可以把 function calling 理解成某一个 AI 内部的调用机制，而 MCP 是整个生态共享的那套语言。
MCP 现在算正式稳定了吗？
MCP 当前这版规范发布于 2025 年 11 月。官方规范 已经被视为可以稳定构建的版本。2026 年的路线图更关注企业可用性、扩展能力和发现机制，而不是去改协议的根。对大多数 use case 来说，现在这版已经能上生产。
去哪里找可用的 MCP server？
MCP Registry 是官方目录。社区维护的 awesome-mcp-servers 也收录得很全。如果你想看参考实现，Anthropic 在 GitHub 上维护了 modelcontextprotocol/servers 这个仓库。
我还会继续看它怎么演化。连接问题大概已经被解决了——真正有意思的是，能力这一层接下来会发生什么。
