MCP：它是什么，以及为什么重要

作者：Addy Osmani

原文：查看原文

摘要

创建 AI 与应用之间通用语言的标准

---

1. ELI5：理解 MCP

可以把 MCP 想成一种“通用插头”。模型上下文协议（MCP） 本质上就是 AI 世界里的通用连接标准。它是一个开放标准，也常被形容为“AI 集成领域的 USB-C”：让模型能够用一致的方式连接不同应用与数据源。

它在实际使用里意味着什么？如果你正在使用 Cursor、Windsurf 之类的 AI 编码工具，MCP 就是让这些工具代表你去调用外部系统的共享协议。通过 MCP，模型可以查询数据库、读取设计文件、操作本地应用，甚至控制某些自动化服务，而不需要为每个工具单独适配一套接口。

换句话说，MCP 的意义不是“又多了一个协议名词”，而是它把 AI 与外部软件之间原本零散、定制、难复用的连接方式，整理成了一层统一的协议层。你不再需要为每个工具写一套专门的胶水代码；只要工具提供 MCP 接口，任何支持 MCP 的客户端理论上都能接上去。

🧩 有人做了一个让 Claude 直接和 Blender 对话的 MCP，只靠提示就能生成漂亮的 3D 场景。

下面这段演示里，他用几句话就搭出了“守护宝藏的低多边形龙”场景👇

视频：Siddharth Ahuja

2. 历史背景：从文本预测到工具增强智能体

要理解 MCP，先得回头看一下 AI 助手是怎么一路演化过来的。

早期的大语言模型，本质上是非常强的文本预测器。你给它一段输入，它会基于训练语料里的模式继续往下生成。它们很擅长回答问题、写文案、总结信息，但能力边界也很清楚：它们本身并不直接接触外部工具和实时数据。如果你让早期模型去看日历、改文件、查数据库，它是做不到的，因为它只能生成文本。

到了 2023 年，事情开始变化。像 ChatGPT 这样的系统陆续引入插件、函数调用与工具机制，模型开始能够运行代码、调用 API、浏览网页。随后，各种框架也快速涌现，把 LLM 包装成能多步执行任务的智能体。

但那一阶段有一个很明显的问题：每种集成方式都各搞一套。有的工具要求模型输出 JSON，有的依赖定制包装器，有的又要求特定提示格式。工具能接上，但没有统一方法让模型知道“有哪些能力可用”“这些能力该怎么调”。每接一个新系统，往往都要再写一遍适配层。

到了 2023 年末，社区逐渐意识到：真正限制 AI 智能体扩展的，已经不再只是模型能力，而是连接方式本身。工具增强智能体的潜力已经很明显，但要继续往前走，就需要一套标准化接口，让工具、模型与宿主应用能以稳定方式协同工作。MCP 正是在这样的背景下出现的。

Anthropic 在 2024 年末推出 MCP，本质上是在回答一个很现实的问题：如果每接一个新数据源都要重做一遍集成，AI 系统就很难真正扩展。 因此，MCP 的目标并不是替代工具本身，而是统一 AI 与工具之间的连接方式。

3. MCP 解决的问题

没有 MCP 时，把 AI 助手接入外部工具，像是在面对一堆插头各异的电器，却没有通用插座。开发者不得不维护分散的集成：同一个 AI IDE，可能用一套方式接 GitHub，用另一套方式查数据库，再用第三套方式去驱动设计工具。每条集成链都要单独维护，也都很脆弱。

正如 Anthropic 所说：

“即使是最复杂的模型，也仍然受限于数据孤岛……每接入一个新数据源，都需要单独实现一遍，这让真正互联的系统很难扩展。”

MCP 的第一层价值，就是把这种碎片化问题正面解决掉。对工具开发者来说，只要实现一次 MCP 规范，理论上就能被所有支持 MCP 的客户端复用；对 AI 平台来说，只要支持 MCP，就不必为每一种第三方工具都重新发明集成方式。

第二个问题是“语言不匹配”。每个软件系统都有自己的 API、参数结构和操作语义。让模型去查 Salesforce、跑 SQL、编辑 Photoshop 文件，本来是三套完全不同的调用方式。MCP 把这些差异收束到一层标准化接口里：工具通过统一格式声明能力，客户端通过统一协议发现并调用这些能力，模型则只需要表达意图。

结果就是：过去那种 N 个工具 × M 个模型/平台 的集成矩阵，被压缩成“工具支持 MCP，平台支持 MCP”这两条主线。复杂度明显下降，可复用性明显上升。

4. MCP 的架构：客户端、协议、服务器与服务

MCP 架构可以拆成四个部分来看。

• MCP 服务器：这是贴近具体应用或服务的一层适配器。它把应用能力以标准方式暴露出来，相当于嵌在应用旁边的“翻译器”。比如 Blender MCP 服务器会把“创建一个立方体并加上木纹材质”翻译成 Blender 的 Python API 调用；GitHub MCP 服务器则会把“列出我的开放 PR”翻译成 GitHub API 请求。

• MCP 客户端：AI 助手或宿主应用里负责连接 MCP 服务器的部分。它负责建立连接、发送请求、接收结果，再把这些结果喂回模型。像 Cursor、Claude Desktop、Windsurf 这类工具，本质上都在扮演 MCP 客户端宿主的角色。

• MCP 协议：也就是客户端和服务器之间共享的通信规则。它约定了消息格式、工具发现、参数描述、结果返回以及错误处理方式。协议本身与传输层解耦，可以跑在 HTTP、WebSocket，甚至标准输入输出之上。

• 服务（应用/数据源）：这是 MCP 最终连接到的真实目标。它可能是本地文件系统、桌面应用、设计工具，也可能是远程 SaaS、数据库或 API 服务。MCP 服务器负责代表模型安全地访问这些能力。

如果把整个流程串起来，可以想象这样一个场景：你在 Cursor 里说一句“从数据库里统计用户分布并生成一张柱状图”。客户端先连接数据库对应的 MCP 服务器执行查询，再把结果交给图表工具对应的 MCP 服务器生成图像。模型不需要直接懂数据库驱动或绘图库 API，只需要通过统一协议表达意图即可。

MCP 架构还有一个很重要的点：它天然把“模型侧”和“系统侧”分开了。模型负责推理与决策，服务器负责与具体服务打交道，而权限、认证、网络连接等问题也更容易被集中管理。

5. 为什么 MCP 对 AI 智能体和开发工具是分水岭

MCP 的意义，不只是“更方便连工具”，而是它改变了 AI 智能体的能力扩展方式。

以前，要给 AI 增加新能力，通常得改提示、写胶水代码、接专门插件，甚至重新设计整个工具调用层。MCP 出现后，很多情况下你只需要新增一个 MCP 服务器，就能让已有客户端立刻获得新的工具能力。这个过程更像“装一个新接口”，而不是“重做一套新系统”。

对开发工作流来说，这个变化尤其明显。现实里的工程流程本来就跨很多工具：IDE、代码托管、工单系统、设计工具、数据库、CI、浏览器自动化……如果 AI 想真正参与到这些流程中，它就必须具备跨工具协作能力。MCP 提供的，正是这种跨工具协作的统一底座。

它还有一个很现实的好处：降低供应商锁定风险。只要协议层稳定，理论上你可以在不同模型、不同客户端之间切换，而不必重写一遍工具接入层。今天是 Claude Desktop，明天也许是 Cursor，后天也许是某个开源模型客户端——只要它们都支持 MCP，原有集成就有机会继续复用。

对工具开发者来说，MCP 也很有价值。一个工具一旦提供 MCP 接口，它就不仅有人类 UI，也天然获得了 AI 接口。于是越来越多人开始讨论“MCP 优先开发”：不是等功能做完后再想 AI 怎么接入，而是在设计产品时就把 AI 作为一等调用方纳入考虑。

6. 真实世界的 MCP 用例与演示

Figma + AI：从设计到代码的顺滑衔接

设计交付一直是软件开发里的摩擦点：设计师在 Figma 里完成视觉稿，开发者再手工把颜色、间距、组件结构翻译成代码。这个过程很耗时，也容易出现偏差。

Figma MCP 改变的，就是这一步。它让 AI 直接读取设计文件、拿到组件结构、颜色、布局和导出资源，再生成对应代码。有人做过一个 Cursor 对话 Figma 的 MCP 演示：开发者只需要说一句“从这个 Figma 文件提取登录页并生成 React 组件”，AI 就能完成从设计到实现的第一轮转换。

“不再来回切换上下文，不再手工翻译设计，也不再在设计到代码之间反复对齐。”

这个场景最重要的启发不只是“生成得更快”，而是设计数据第一次以协议化方式直接进入编码上下文。开发者不再需要手工摘抄设计稿里的信息，模型也不必靠截图猜布局。

Blender + AI：用自然语言做 3D 建模

Blender MCP 是另一个很有代表性的例子。它让模型能够通过自然语言控制 Blender：创建对象、调整材质、布置灯光、查询当前场景状态。

比如你可以直接说：

“创建一个守护宝藏的低多边形龙，周围放几块岩石，再加上有戏剧感的灯光。”

然后 AI 就能通过 MCP 调用 Blender 的脚本接口，把这些操作落到具体场景里。更关键的是，这不是一次性的“生成后结束”，而是可以持续迭代：模型还能继续查询“现在场景里有几个对象”“龙的多边形数是多少”，再基于结果继续调整。

这类用例说明，MCP 不只适合开发工具，也适合复杂桌面软件。它把原本只能由熟练用户通过图形界面完成的操作，开放给了自然语言驱动的工作流。

AI + Unity：自然语言驱动游戏开发

Unity MCP 展示了类似的方向。通过 MCP，AI 可以在 Unity 编辑器里创建对象、挂载组件、执行菜单命令、运行测试，甚至调整场景结构。

这意味着你可以把“给场景加一个 NPC，让它巡逻，并在地图上生成 5 个生命值道具”这样的高层意图，交给 AI 去拆分并落到 Unity 编辑器中。

这类场景的关键点在于：MCP 把原本封闭在桌面工具里的操作能力，转化成了可以被模型调用的协议能力。对于复杂创作型软件来说，这一步的意义非常大。

Zapier MCP：把成千上万个业务工具接给 AI

如果说 Figma、Blender、Unity 代表的是单一高价值工具，那么 Zapier MCP 代表的就是另一种规模化路径：一次接入，把海量 SaaS 工具都变成 AI 可调用能力。

Zapier 在 2024 年末为自己的生态提供了 MCP 接口，相当于把原本已经很庞大的应用连接目录，整体变成了 AI 可用工具。这样一来，模型理论上就能通过同一个 MCP 入口去发送 Slack 消息、更新 CRM、安排日历、创建任务，甚至串起多个自动化步骤。

这类场景特别能体现 MCP 的网络效应：一个协议接通之后，后面的价值不是线性增长，而是会随着可用工具数量增加而快速放大。

其他值得关注的 MCP 集成

除了上面几个标志性案例，MCP 生态还在快速扩张：

• GitHub MCP：读仓库、开 issue、管理 PR、辅助代码审查
• Slack MCP：发送消息、管理频道、自动化团队通知
• Google Drive / Docs MCP：读写文档、表格和演示文稿
• 数据库 MCP：以自然语言查询 Postgres、MySQL 等数据库
• 音乐 / 媒体类 MCP：控制播放、创建播放列表、做推荐实验

这些例子共同说明了一件事：MCP 正在把“AI 与数字世界的连接”从零散特例，变成一种可以复用的系统能力。

7. 开发者如何开始使用 MCP

使用现成的 MCP 服务器

对大多数人来说，最简单的入门方式不是自己写，而是先用现成服务器。Anthropic 维护了一个官方 MCP 服务器目录，社区里也在持续补充更多实现。

典型步骤大致如下：

1. 选择支持 MCP 的客户端：例如 Claude Desktop、Cursor、Windsurf 或 Cline。
2. 配置服务器连接：大多数客户端都有配置文件，可以指定要连接的 MCP 服务器。
3. 安装依赖：不少服务器本身是 Node.js 或 Python 包，需要先安装。
4. 提供凭据：如果需要访问 GitHub、Slack 等受保护资源，就要配置 API 密钥或令牌。
5. 测试连接：启动客户端，用自然语言尝试调用新能力，确认它确实可用。

构建自定义 MCP 服务器

如果你的场景足够专有，自己做一个 MCP 服务器也并不复杂。Anthropic 已经提供了 SDK 与文档，常见做法通常是：

1. 选择语言：常用的是 TypeScript / JavaScript 或 Python。
2. 定义工具：把你要暴露给模型的能力拆成清晰的工具接口。
3. 实现处理逻辑：把工具调用落到实际 API、文件操作或应用动作上。
4. 处理身份验证：保证访问受保护资源时有合适的认证机制。
5. 测试与调试：借助 MCP Inspector 或实际客户端做联调。
6. 发布与复用：如果适合公开，开源出去能让更多客户端直接复用。

最佳实践

使用 MCP 时，有几条经验尤其重要：

• 工具描述要清楚：说明这个工具做什么、什么时候该用、参数是什么意思。
• 错误处理要完整：别把失败都吞掉，给模型返回足够可行动的错误信息。
• 权限要最小化：能给只读权限就别给写权限，能收窄作用域就别全开。
• 注意速率限制与成本：如果背后接的是外部 API，要考虑配额与失败重试。
• 文档要能直接上手：写清楚安装方法、配置示例和典型调用方式。

8. MCP 当前的限制与挑战

MCP 很有潜力，但它离“万物互联已经成熟”还有距离。

标准化身份验证仍在演进

今天很多 MCP 集成都还要靠手工配置凭据。虽然能用，但在企业环境里，这会给权限管理、凭据轮换和审计带来额外负担。未来如果没有更统一的认证标准，MCP 在更大规模环境中的部署成本仍然不低。

生态成熟度还不够高

协议本身正在快速发展，但生态仍然处于早期：

• 很多流行工具还没有官方 MCP 服务器
• 部分服务器文档不足、样例不够完整
• 协议和实现版本仍可能出现兼容性问题
• 社区规模相对还小，最佳实践还在形成中

性能并非没有代价

MCP 多了一层通信与协调，因此会带来新的性能问题：

• 远程服务器会增加网络延迟
• 同时运行多个 MCP 服务器会消耗额外资源
• 一旦依赖远程服务，整体稳定性就受网络影响

安全与隐私问题不能忽视

让 AI 智能体访问真实工具，本来就意味着风险管理要更严谨：

• 权限给太大，会放大误操作风险
• 指令理解偏差，可能触发非预期动作
• 敏感数据可能沿着连接链路暴露出去
• 企业环境通常还需要可审计、可追踪的操作记录

MCP 不会自动替你解决这些问题，它只是把这些问题从“到处零散处理”集中到了“协议层和工具层一起处理”。

普通用户的配置门槛仍然偏高

对非技术用户来说，配置 MCP 仍然不够顺滑：编辑配置文件、安装依赖、处理凭据、排查连接问题，这些步骤都还需要一定门槛。未来如果没有更友好的图形化配置和更清晰的报错体验，MCP 的普及速度会受到影响。

9. MCP 的未来：接下来会发生什么？

尽管现在还不完美，MCP 的方向已经很清楚了。

企业采用会持续增加

随着协议成熟，我们很可能会看到更多官方企业级服务器出现，例如 Salesforce、SAP、Oracle 等系统的标准接入方式，以及围绕审计、权限控制和合规的配套工具。

开发者工具会更完善

围绕 MCP 的工具链也会越来越成熟：

• 更好用的调试器和测试工具
• 从 API 规范自动生成 MCP 服务器的生成器
• 可观测性与监控面板

跨平台标准化会更强

如果更多模型厂商、客户端和工具生态共同采用 MCP，它就有机会成为真正意义上的跨平台 AI 互操作层，而不只是某一家的生态接口。

智能体编排会成为下一个重点

一旦“接工具”这件事标准化了，更高一层的问题就会浮现：多个智能体如何协同工作？跨多个 MCP 服务器的多步流程如何组织？这会把讨论从“能不能接上”推到“如何高效编排”。

用例会继续外溢

今天我们看到的是设计、开发、自动化和创作工具，接下来也很可能扩展到：

• 物联网与智能家居
• 机器人与自动化设备
• AR / VR 环境
• 科研工具与实验设备

10. 结论：MCP 为什么重要

MCP 代表的，不只是一个新协议，而是一种新的连接方式：让 AI 与应用、数据和工具之间的交互，第一次有机会建立在统一、可复用、可扩展的协议层上。

对开发者来说，它意味着更少的一次性集成代码、更高的复用性，以及更低的供应商锁定风险。

对用户来说，它意味着 AI 助手不再只能“聊天”和“给建议”，而是可以更自然地接入真实工作流，参与真实操作。

对整个行业来说，MCP 可能正在成为 AI 互操作性的关键基础设施。它未必会一夜之间解决所有问题，但它确实把很多过去零散、临时、难维护的集成方式，推进到了一个更像“标准层”的阶段。

就像 HTTP 让网络真正扩张起来、USB 让设备连接变得统一一样，MCP 也很可能成为连接 AI 与数字世界的重要协议之一。这正是它值得关注的原因。