MCP：Anthropic 想定义 AI 应用开发

想象一下这个场景：用户向 AI 客户端提出“希望 AI 能够搜索网页”的需求。在传统模式下，这个简单请求会触发一连串复杂的开发流程，从需求收集到最终发布，可能需要数周时间才能让用户获得这项功能。

这种模式在 MCP（Model Context Protocol）出现之前，一直是 AI 应用开发的常态。

传统模式与 MCP 模式的对比

传统 AI 工具集成流程

下面的流程图展示了传统 AI 应用开发中，从用户提出功能需求到最终实现的完整过程。

sequenceDiagram
    participant 用户
    participant AI客户端
    participant 应用商店
    
    用户->>AI客户端: 提出需求："希望AI能搜索网页"
    AI客户端->>AI客户端: 调研实现方案
    AI客户端->>AI客户端: 编写搜索API集成代码
    AI客户端->>AI客户端: 测试功能
    AI客户端->>AI客户端: 更新客户端代码
    AI客户端->>应用商店: 发布新版本
    用户->>应用商店: 下载更新
    用户->>AI客户端: 终于可以使用搜索功能

在传统模式下，工具集成流程存在几个核心问题：

功能被客户端锁定：用户无法自行添加新工具，必须等待开发者实现并发布更新
重复开发：每个 AI 客户端都需要单独实现相似功能，无法共享已有实现
缺乏标准：各开发团队使用不同方式解析 AI 输出、处理参数、返回结果
更新周期长：即使是微小功能调整，也需要经历完整的发布周期

需要注意，这并非技术可行性问题。开发者完全可以让 AI 连接任何外部系统——网页搜索、数据库查询、文件操作等，但问题在于每项功能都需要客户端开发者单独实现，用户只能被动等待。

MCP 带来的流程变革

在 MCP 框架下，当用户希望 AI 能够搜索网页时，流程应该是：

用户选择并连接一个提供搜索功能的 MCP 服务器
AI 客户端通过 MCP 协议发现服务器提供的搜索工具
用户授权 AI 使用该工具
用户提问需要搜索的内容
AI 通过 MCP 协议调用服务器的搜索工具
服务器执行搜索并返回结果
AI 将结果整合到回答中

这个流程中，关键是用户可以选择连接任何兼容 MCP 的服务器，而不仅限于 AI 客户端开发者预先集成的功能。

sequenceDiagram
    participant 用户
    participant AI客户端
    participant 第三方服务
    
    第三方服务->>插件库/工具目录: 开发并发布适配MCP的工具
    
    用户->>用户: 有使用搜索功能的需求
    用户->>插件库/工具目录: 浏览可用工具
    用户->>AI客户端: 安装支持搜索的 MCP Server
    用户->>AI客户端: 完成必要的配置(如API Key等)
    用户->>AI客户端: 提问需要搜索的内容
    AI客户端->>第三方服务: 调用搜索API
    第三方服务->>AI客户端: 返回搜索结果
    AI客户端->>用户: 展示包含搜索结果的AI回答
    
    Note over 用户,AI客户端: 全程无需AI客户端开发者参与
    Note over 第三方服务,插件库/工具目录: 一次开发，所有支持MCP的AI客户端可用

在 MCP 架构下，整个工具集成流程被极大简化：

用户自主选择：用户可可以直接从 GitHub、Twitter、公众号、插件库或工具目录中找到并安装需要的功能
开发者与客户端分离：第三方开发者创建的工具可被所有 MCP 兼容客户端使用
即时可用：安装配置后立即可用，无需等待客户端更新周期
客户端开发者解放：客户端只需实现一次 MCP 协议适配，后续能力迭代几乎不再需要他们参与

这种模式转变带来了显著效率提升。用户可能在出现“希望能搜索网页”的想法几分钟后就能自行完成工具安装并开始使用，而不是等待数周的开发周期。

更重要的是，这彻底改变了 AI 应用的生态关系——转变为用户和第三方服务共同参与的开放生态。AI 产品只需专注于提供良好的基础体验和 MCP 支持，而不必为每个第三方服务的接入单独适配，就像 USB C 接口一样。

MCP 的野心：不只是 Function Call 的封装

很多人初次接触 MCP 时，基本都是将其视为“Function Call 的一种封装”或“工具调用的标准化实现”。我认为这种理解虽然不完全错误，但过于片面，远未触及 Anthropic 的核心野心。

事实上，在我看来 MCP 是 Anthropic 对整个 AI 应用构建过程的全面重新思考，它定义了很多概念，比如说 Tools、Prompts、Resources 等，共同构成了一个完整的 AI 应用框架，它想教所有人“你应该怎么做一个 AI 产品”。

工具（Tools）

大多数人首先关注的是 MCP 的工具系统，它确实是当前最成熟和应用最广泛的部分。但即使在这一层面，MCP 也远超传统 Function Call：

标准化工具定义：使用统一的 JSON Schema 定义工具接口，使不同开发者创建的工具具有一致性
工具发现机制：客户端可以通过 tools/list 端点动态获取可用工具，实现工具的动态发现
错误处理规范：定义了统一的错误报告格式，使 AI 能够理解并处理工具调用失败
权限控制模型：明确的授权机制和安全考量，让用户可以控制 AI 使用工具的边界

这些特性使得 MCP 的工具系统不仅仅是技术实现层面的标准化，更是创建了一个开放工具生态的基础设施。

提示（Prompts）

MCP 的提示系统，这一部分在目前的实现中较少被提及，但它可能对提升 AI 交互质量具有深远影响：

服务器定义的交互模板：MCP 允许服务器定义可重用的提示模板，客户端通过 prompts/list 和 prompts/get 端点获取这些模板
参数化提示：提示模板可接受动态参数，使服务器能提供可定制但结构化的交互方式
工作流引导：服务器可以定义多步骤交互流程，指导用户完成复杂任务
UI 元素集成：提示可以在客户端表现为斜杠命令等界面元素，提升用户体验

提示系统本质上是将 AI 交互专业知识标准化。好的提示词往往是 AI 应用效果的关键，而 MCP 的提示系统让服务器可以提供经过优化的专业提示模板，客户端可以直接使用这些模板，而无需重新发明轮子。

甚至 MCP 在文档中教客户端开发者如何展示这些提示：

Prompts can be surfaced in client UIs as:

Slash commands

Quick actions

Context menu items

Command palette entries

Guided workflows

Interactive forms

资源（Resources）

MCP 的定义中，它为 AI 应用提供了环境感知能力：

服务器暴露的资源：服务器可以通过 MCP 将各种数据（文件、数据库记录、系统状态等）暴露为资源
统一资源寻址：通过 URI 标识不同类型的资源，提供统一访问接口
资源内容访问：客户端通过 resources/read 从服务器读取资源内容，让 AI 可以访问这些数据
资源变更通知：客户端可以通过 resources/subscribe 订阅资源变化，服务器通过通知机制推送更新

资源系统的潜力在于彻底改变 AI 与用户环境的交互模式。比如说：用户打开一个 AI 编辑器，直接询问 AI 关于某个报错的信息，这个 AI 编辑器就可以通过实现一个内置 MCP 服务器，主要关注资源部分，然后结合标准化的资源访问能力和 LLMs 识别来实现仅仅通过报错信息就能快速定位到代码文件和进行修改。当然像 Cursor 或 Cline 这类集成了 AI 能力的代码编辑器或插件其实都已经是支持的了，但是现在通过 MCP 这一套标准协议去做，也会工程化的成本会更低，也许后面甚至会有专门做这个方面的 MCP Server 出来。

当然其实还有 Sampling、Roots 等等更多的元素：

Sampling 允许服务器直接通过客户端请求 LLMs 生成内容，好处主要在于安全性和减少 MCP Server 的成本消耗
Roots 是当客户端连接到服务器时，它会声明服务器应该关注的哪些内容，例如，当你使用代码编辑器时，客户端可能会告诉连接的服务器：“嘿，请专注于这个项目文件夹：file:///home/user/projects/my-app”

最后总结一下 MCP 的一些概念

服务器-客户端协议：MCP 本质上是一个客户端-服务器协议，定义了两者之间的通信标准
服务器角色：在 MCP 生态系统中，服务器扮演着功能提供者的角色，它可以是各种不同形式：
- 开发工具插件：如 VS Code 扩展，提供代码分析功能
- 数据服务接口：连接到数据库、数据仓库的接口
- 网络服务：搜索引擎、天气 API 等网络服务
- 企业应用连接器：Slack、GitHub、Notion 等 SaaS 服务的接口
- 本地系统工具：文件系统访问、操作系统功能等
- 专业领域工具：金融分析、医疗数据处理等领域特定工具
客户端角色：MCP 客户端通常是用户直接交互的 AI 应用，它通过协议与各种服务器连接，整合它们提供的功能。典型的客户端包括：
- AI 聊天应用
- 代码编辑工具
- AI 写作工具
- 等等
用户的选择权：MCP 架构的一个核心理念是将选择权交给用户，用户可以决定：
- 连接哪些 MCP 服务器
- 授予这些服务器什么级别的权限
- 允许 AI 使用哪些工具和资源

这种架构带来的最大好处是解耦和专业化：

客户端开发者可以专注于提供优秀的 AI 体验
工具开发者可以专注于创建高质量的专业功能
用户可以自由组合这些组件，创建个性化的 AI 工作流

所以从我的角度来说，我认为 Anthropic 更像是在写一本《如何构建 AI 应用》的教科书，但是我认为它仍然存在很多问题。

MCP 面临的问题

1. 普通用户的门槛

MCP 将选择权交给了用户，但未必所有用户都能或愿意承担这种复杂性。

我在某社媒上看到有人在吐槽集成 Brave 的搜索能力时，卡在了配置界面前：“API Key？这是什么东西？”

这正是 MCP 面临的首个现实挑战——虽然理论上将工具选择权交给了用户，但实际上创造了一个新的技术门槛。大多数普通用户既不知道如何获取 API Key，也不理解如何正确配置服务参数。他们只想使用功能，而不是成为半个开发者。

这种情况就像给普通用户一堆电脑配件（电源、CPU、GPU、主板、内存、SSD、机箱、显示器、键鼠等等），问题是他们只是想要一台能打游戏的电脑呀。

2. 配置体验碎片化

在测试不同的 MCP 客户端实现时，我发现每个客户端都有完全不同的配置方式：

某些客户端要求用户直接编写 JSON 配置（几乎等同于编程）
另一些提供了基础的表单界面，但仅限一些能适配得上的服务，字段名称和描述仍然充满技术术语
还有一些尝试让 AI 辅助配置，但这又会消耗大量的 tokens，增加使用成本
同时在使用部分服务甚至要求用户存在开发环境才能正常使用

想象一下，如果 App Store 中每个应用安装方式都不同，用户体验会怎么样？所以我目前对于 MCP 能够创造一个 “AI 工具 App Store” 是存疑的。

3. 安全与隐私

在封闭生态中，平台可以严格审核每个工具；但在 MCP 的开放世界里，谁来保证这些第三方工具的安全性和隐私保护？一个看似无害的天气工具，有可能在后台收集用户数据。

这种安全风险就像是把陌生人请进家门——没有完善的信任机制和安全保障，用户很难放心地使用这些工具。尽管 MCP 协议考虑了一些安全和权限控制，但我觉得仍然缺乏统一的安全标准和验证机制，大部分的评判工作仍然依赖用户自己。

4. 实现复杂度高

不管是 MCP 客户端还是 MCP 服务如果想要完整地支持 MCP，实现起来还是要比看起来复杂得多，当然目前大部分服务感觉似乎只提供 Tools 就够了，不过这样 MCP 的一些理想最佳用例似乎就很难真正应用了。

5. 标准还在演进

MCP 仍在快速发展中，规范可能随时变化。另外就是，Anthropic 是否真的有能力将 MCP 推广成事实标准，尽管它们最大的对头 OpenAI 似乎也说要支持，但我还是觉得还需要观察，比如说中美之间在未来可能都会都一些不太一样的地方，也有可能出现地区性标准啥的。

疑问和总结

对于从业者来说，我是存在一些疑惑的。是否应该现在就全面拥抱 MCP，还是等标准更加成熟？早期采用者可能面临更多变化和调整成本，但也有机会塑造标准和建立先发优势，但一般团队很难有这个资格，目前似乎没有太多因素能明显促进产品推广，许多产品的能力也无法简单地归纳为某个简单的服务。

未来的 AI 产品可能不再是封闭生态，而是由核心体验加可扩展模块组成，那么也许在未来产品规划需要考虑哪些是核心能力，哪些可以交给第三方生态，但是在开放生态中，如何建立对第三方工具的隐私和安全管理也相对比较重要。同时假设客户侧有内部专用的工具，是否可以帮助他们接入，也许也会影响到产品的规划。

或者也许可以不必再构建完整的 AI 产品，团队可以专注于特定领域的服务，如法律文档分析、医疗数据解读或金融数据处理等专业工具。那么是成为 MCP 客户端、MCP 服务提供者，还是连接两者的平台？每个位置都有不同的商业模式和竞争格局。

成功的开放标准往往经历了从混乱到秩序、从理想到现实的演变过程。MCP 正处于类似的早期阶段——充满潜力，但也面临挑战。它代表了 Anthropic 对 AI 应用开发的宏大愿景，一种将 AI 能力组件化、标准化、可组合的未来。无论如何，MCP 已经为我们提供了一个新的思考框架，更新了大家对于 AI 应用构建方式的认知。