此文章仅供内部学习，如果有问题欢迎指正。

Introduction

举例解释

让我们举个例子来更好地理解MCP协议：

假设你要做一个Agent，让它能操作各种APP，比如发邮件、查数据库。

这不仅仅是让模型学习邮件、数据库对应的API操作文档那么简单。

• 举个例子，Gmail API 可能允许你删除邮件，发送邮件，但你并不希望这个Agent拥有这些权限，所以你得限制Agent，只让它创建新邮件，或者帮忙写草稿。为了实现这一点，你不能让它访问完整的API，得创建一些自定义的提示信息或者自定义的实现方式，以此来引导或者限制Agent。

  
  

• 好不容易让Agent学会在Windsurf(实现了Agent的集成开发环境IDE)里操作Gmail和给公司的数据库干活，结果有天你朋友说："这个Agent很好用啊，但我用的是Cursor编程，怎么办？"

就像给iPhone配的lighting没法给安卓用，所有功能都得重新开发一遍。

这里就引出MCP的核心价值：不需要重复造轮子。

传统模式：不同网站的不同业务需要不同的API 

MCP协议：大模型连接至MCP服务器，服务器集成外部数据源并提供交互功能

就像给AI量身定制的“USB-C接口”。MCP 定了个统一标准，不管是什么Agent或者AI助手（Windsurf、Cursor还是Cladue），只要符合这个协议，就能连接到后端或不同 API，即插即用。

Architecture‍‍‍‍‍‍‍‍‍

MCP协议的核心是客户端-服务器模型(Client-Server Model)：

• MCP客户端：AI 模型内部使用MCP 协议与 MCP服务器通信。

  
  

• MCP服务器：连接 AI 模型和外部系统之间的中介，充当“桥梁”和“翻译”。它接收来自 MCP 客户端的请求，理解 Al 的意图，然后去外部资源获取数据或执行操作，再把结果返回给 Al 模型。

  
  

不同厂商只需遵循MCP协议开放自己的API 和部分能力，即可让自家服务被任意MCP客户端（Agent）调用。

举个例子，如果你实现了计算器A工具，查看天气B工具，发邮件C工具，你就可以通过 MCP 服务器公开这些工具。MCP客户端(比如Cursor)可以连接到你的 MCP 服务器，模型能立即知道：“哦，我可以调用A工具，还可以使用B和C工具。”，在接下来的任务中使用它们。

Appliaction‍‍‍‍‍‍‍‍‍

MCP vs API

1. 旅行规划助手

   使用API时：分别为谷歌日历、邮件、机票预订写代码，繁琐而复杂。

   使用MCP时：AI助手Agent直接通过MCP统一协议，查看日历、订机票、发邮件确认，无须单独整合每个工具。

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

   使用API时：手动连接文件系统、版本管理、包管理和文档，耗时费力。

   使用MCP时：IDE 通过 MCP 一次连接所有功能，带来更丰富的上下文支持，更强大的智能建议。

3. 复杂的数据分析

   使用API时：人为管理与每个数据库、数据可视化工具的连接。

   使用MCP时：Agent自动发现并连接多个数据库和可视化工具，通过统一的MCP接口完成分析任务。

Future‍‍‍‍‍‍‍‍‍

Manus的火爆验证了通用型agent的市场需求，也加速整个行业的资源投入和技术迭代（比如 MCP协议）。

有意思的是，Manus 联合创始人表示Manus并未采用MCP协议，而是借鉴了CodeAct框架：统一Agent行动为可执行的Python代码，以提升其交互能力和处理复杂任务的能力。

预计Manus采用MCP协议以后manus性能会有进一步的提升，比如不用单独开沙盒虚拟机，因为服务提供商能直接设定agent的权限。

当前，客户端和服务端还存在很大的优化空间：