MCP协议详解：复刻Manus全靠它，为什么说MCP是Agent进化的一大步？

文章转载自「新智元」。

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

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

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

规划
工具使用
记忆

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

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

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

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

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

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

01 一次搭建，

代替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助手和外部系统之间架设了一条高速路，取代了过去需要技术人员一桥一桥手工搭建的低效模式。

02 什么是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主要支持工具，其他功能都不行，适合简单工具操作。