1 次搭建完胜 1 亿次编码，MCP 硅谷疯传！Anthropic 协议解锁智能体「万能手」

【新智元导读】AI 智能体领域 Type-C 来了！Manus 及其开源复现诞生，一夜捧红了 MCP，工具调用 / 访问外部数据，一个协议就够了。

上一周，智能体迎来里程碑式的一周。

从 Manus 及其开源复现，到 Opera 的浏览器操作 AI 智能体、AI 工作伴侣 Archer，再到多种个人项目，将 Agent 推向热议风口。

在处理动辄需要十几甚至几十分钟的复杂任务时，涉及到 3 个核心能力：

规划
工具使用
记忆

其中，第二趴是让智能体「动起来」的关键，真正与现实世界进行交互。

举个例子，当前最强的开源复现 OWL 在查找伦敦今日放映的电影时，AI 智能体主动调用 Chrome 搜索工具后，精准返回影院的实时信息。

而最火的开源项目 OpenMauns，在查找 Karpathy 个人信息主页信息时，也是基于强大的工具使用能力。

这些案例生动地证明了，工具使用，能让智能体跳出空想局限，进化出会做事的能力。

而作为最强的标准化接口协议，MCP 也在一夜间爆红硅谷，无人不知。

对于圈外的人来说，可能对此有所陌生。而它的本质，就是智能体系统的一种。

一次搭建，代替 1 亿次配置

去 11 月，Anthropic 首次提出「模型上下文协议」，即 MCP，赋予了 Claude 模型超级能力，一次构建，让 AI 与工作流深度集成。

其主要优势如下：

**开发简化：**一次编写，多次集成，无需为每个新集成重写定制代码
**灵活性：**切换 AI 模型或工具时，不需要复杂的重新配置
**实时响应：**MCP 连接保持活跃状态，支持实时上下文更新和交互
**安全性和合规性：**内置访问控制机制和标准化的安全实践
**可扩展性：**随着 AI 生态系统的扩展，只需连接新的 MCP 服务器即可轻松添加新功能

用通俗的话讲，MCP 就像是专为 AI 应用设计的通用接口，类似我们日常使用的 USB-C。

正如 USB-C 简化了不同设备与计算机的连接方式，MCP 简化了 AI 模型与数据、工具和服务之间的交互方式。

通过 MCP，AI 助手不仅能够「读懂」代码，还能「理解」团队讨论、涉及文档等外部信息，提供更加精准的回答。

MCP 是一种标准化协议，用于连接 AI 智能体与各种外部工具和数据源

相比之下，在没有 MCP 之前，AI 助手要想与外部工具互动，必须通过编写代码并调用 API，这意味着每一种具体的连接都需要提前手动编程，效率低下且耗时费力。

更棘手的是，每个 AI 助手与每个外部工具之间都需要单独进行配置。如果有 1000 个 AI 助手和 1000 个外部工具，理论上需要编写 1000×1000=100 万个独立的连接代码，工作量简直是个天文数字。

打个比方：API 就像是不同的门，其中每扇门都有自己独特的钥匙和使用规则：

传统 API 要求开发人员为每个服务或数据源编写定制化的集成代码

而 MCP 的出现就像为 AI 助手和外部系统打造了一套通用的「标准语言」，堪称是智能体生态的一次「标准化革命」。

一旦某个 AI 助手实现了 MCP 协议，它就能通过这个协议无缝连接上成千上万的外部工具，无需再为每种连接单独编写代码。

同样，外部工具（比如邮件、天气应用等）也只需搭建一次 MCP 服务器，之后所有支持 MCP 的 AI 助手都可以直接与之交互。

假如有 1 万个 AI 助手和 1 万个外部工具。在 MCP 模式下，每方只需实现一次协议，总共只需 2 万次配置。

而按照传统编码方式，每种 AI 助手与每种外部工具都要单独对接，那将是 1 万 ×1 万 = 1 亿次配置！

这直接使配置效率提高了不止一个维度。

MCP 的灵活性也非常突出，它既可以在云端运行，也可以在本地设备上部署，适应性极强。

可以说，MCP 就像为 AI 助手和外部系统之间架设了一条高速路，取代了过去需要技术人员一桥一桥手工搭建的低效模式。

什么是 MCP？

正如前文所说，MCP（Model Context Protocol）是一种新的开放协议，目的是为 LLM 提供标准化的上下文信息传递方式，从而实现 AI 智能体与外部数据及工具的结合。

和传统的 API 相比，MCP 的区别在于：

**单一协议：**MCP 作为一种标准化的「通用接口」，集成一个 MCP 意味着可以访问多个工具和服务，而不仅仅是单一服务。
**动态发现：**MCP 允许 AI 模型动态发现并与可用工具交互，无需预先设定每个集成的固定代码。
**双向通信：**MCP 支持持续、实时的双向通信------类似于 WebSockets。AI 模型既可以获取信息，也可以实时触发操作。

其中，实时双向通信的机制如下：

**拉取数据：**LLM 向服务器查询上下文信息。例如，查看你的日历安排。
**触发操作：**LLM 指示服务器执行具体操作。例如，重新安排会议、发送电子邮件。

不过，如果应用场景需要精确、可预测的交互模式，并有严格的限制条件，传统 API 可能更为适合。

MCP 提供了广泛、动态的能力，非常适合需要灵活性和上下文感知的场景，但对于高度受控的、确定性的应用可能不是最佳选择。

在以下情况下推荐使用传统 API：

需要精细控制和高度特定、受限的功能场景
追求性能优化而需要紧密耦合的系统
要求最高可预测性和最小上下文自主性的应用

架构

MCP 采用简单的客户端 - 服务器架构模式：

**MCP 主机：**需要访问外部数据或工具的应用程序（如 Claude Desktop 或 AI 驱动的集成开发环境）
**MCP 客户端：**与 MCP 服务器维持专属的一对一连接
**MCP 服务器：**轻量级服务器，通过 MCP 协议提供特定功能，连接到本地或远程数据源
**本地数据源：**MCP 服务器安全访问的文件、数据库或服务
**远程服务：**MCP 服务器访问的基于互联网的外部 API 或服务

将 MCP 比作一座桥梁可以更清晰地理解：MCP 本身不处理复杂逻辑；它只是协调 AI 模型和各种工具之间的数据和指令流通。

具体来说，服务器就是与 API 进行交互的东西。它可以在远程服务器上（例如，在云上），或者在你的本地系统上。

它包含了所有系统上需要与之交互进而采取行动的代码，比如发送 Slack 消息、创建文件等等。

如下图所示，可以通过 MCP 服务，调用 GitHub API 在仓库里创建代码文件。

MCP 客户端负责与服务器进行通信。客户端的一个非常酷的特点是它可以同时与多个服务器进行交互。

所以你可以设置专门的服务器来处理 GitHub 交互和 Slack 交互，然后把它们接入同一个客户端。

最重要的，协议是使一切运作的关键。可以将它视为一种永远不会改变的通用语言，MCP 服务器和 MCP 客户端都能使用。

它就像 USB 接口一样，用于将 MCP 客户端连接到 MCP 服务器。

USB 接口让手机连接到笔记本电脑，MCP 协议让你可以将第三方 API 连接到桌面应用程序。

针对各种类型的 MCP 客户端，Total TypeScript 的作者 Matt Pocock 还进行了一波对比。

可以看到，Claude Desktop 和 Continue 支持资源、提示、工具，功能很全面。5ire 和 BeeAI Framework 就比较有限，工具支持还可以，但其他方面基本不行。Cline 也支持资源和工具，但不支持提示。Cursor 和 Emacs Mcp 主要支持工具，其他功能都不行，适合简单工具操作。

应用场景

在实际应用中，MCP 客户端（例如，client.py 中的 Python 脚本）会与管理各种特定工具（如 Gmail、Slack 或日历应用）交互的 MCP 服务器进行通信。

这种标准化大大降低了复杂度，使开发人员能够快速实现复杂的交互功能。

1. 行程规划助手

使用传统 API 需要为 Google 日历、电子邮件、航空公司预订 API 分别编写代码，每个都需要单独的认证、上下文传递和错误处理逻辑。
使用 MCP 则容易得多，AI 助手能够无缝地检查日历可用时间，预订航班，并发送确认邮件------所有这些都通过 MCP 服务器完成，无需为每个工具单独开发集成代码。

2. 高级 IDE（智能代码编辑器）