MCP｜AI时代的万物互联

Background

背景：从API困境到MCP革新

最近，以Manus为代表的AI代理（Agent）突然流行起来，跟着一起火爆就是MCP协议。

MCP（Model Context Protocol，模型上下文协议）是2024年11月底，由 Anthropic 推出的一种开放标准。

欢迎大家阅读、讨论、学习。

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

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增加了额外的服务器的层，但并没有增加系统的复杂程度，实际上，它还降低了复杂度，因为实现了资源的共享：

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

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

Appliaction‍‍‍‍‍‍‍‍‍

应用：MCP重构工作流程

MCP vs API

功能

传统API

MCP协议

整合难度

每个API单独整合

一次标准化整合

实时双向通信

❌ 不支持

✅ 支持

动态发现工具

❌ 不支持

✅ 支持

扩展性

（弱）需要额外开发

（强）即插即用

安全性与控制

每个API单独定义

所有工具统一标准

MCP的应用场景举例

旅行规划助手

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

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

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

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

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

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

Future‍‍‍‍‍‍‍‍‍

未来：AI万物互联的生态

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

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

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

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

客户端

客户端主要是 AI模型公司，Agent公司：

首先，主流大模型普遍缺乏对MCP协议的深度兼容
其次，通用Agent要求模型严格遵循预设流程执行任务。Manus和OWL这些Agent产品，模型不会记住每次成功完成任务的路径，每一次执行都是从头开始：一次配置的环境不成功再重头配一次，一个工具使用不了就调用另一个工具。这种强制顺序执行的特性与限定了模型需要按照规划一步一步执行下去，导致算力成本大幅上升。
理论上，MCP的工具可以无限扩展，即使给模型提供有文字描述功能的模块，大模型本身不可能把所有的工具内容都训练进去。

因此，未来模型应当学习如何更好地使用MCP，比如在执行任务的过程中收集反馈，保存成功执行的路径并运用在以后类似的任务中。未来模型如果能记住最优最小代价的成功路径，性能还能再进一步提升。

服务端

MCP的设计理念是创建一个开放生态系统，任何人都可以为各种服务开发MCP服务器。Claude 推动 MCP 可以说是一个很好的时机，首先是 Claude Sonnet 3.5 在开发人员心中有较高的地位，而 MCP 又是一个开放的标准，所以很多公司和社区都愿意参与进来。

MCP协议也许dominate，接口商业化也是极有可能的，这一点利好卖接口服务的中间商。

不少公司已经在提供MCP服务

MCP官方

MCP官方维护的服务器，用于展示 MCP 的功能：https://github.com/modelcontextprotocol/servers?tab=readme-ov-file#-reference-servers

AWS 知识库检索
网页 / 本地搜索（Brave）
代码库搜索（Git/GitHub/GitLab）
安全文件操作（权限可控）
网页内容抓取（优化 LLM）
数据库查询（PostgreSQL/Sqlite，只读）
…

第三方开发者

MCP接口的商业化：服务的提供商可以为自己的产品创建MCP服务器，使其能很容易被AI模型调用。

比如，21st使用AI IDE (cursor，winsurf)作为客户端连接其服务器，集成【前端组件，图标库搜索】工具，使得cursor中的模型直接能调用这些工具，获得新的能力。

Cursor使用21st工具🔧：https://21st.dev/

各服务提供商官方维护的 MCP 服务器列表：https://github.com/modelcontextprotocol/servers?tab=readme-ov-file#%EF%B8%8F-official-integrations

21st.dev Magic 灵感驱动 UI 组件（21st 设计团队）
Apify 3000 + 云爬虫（电商 / 社交 / 地图数据）
Cloudflare 云部署、配置和查询您的资源
Exa AI 专用搜索引擎
Firecrawl 网页数据提取
Kagi Search 网络搜索（API 驱动）
Meilisearch 全文 / 语义搜索
…

社区服务器

由社区开发和维护的服务器，开源的MCP服务器合集：https://glama.ai/mcp/servers

企业内部团队

公司内部可能为其专有系统和内部工具开发自定义MCP服务器，以便其工具能够安全地访问内部数据。

AI公司自身

像Anthropic也可能开发一些核心MCP服务器，用于Claude Desktop集成常见基础的功能。

Tecnology‍‍‍‍‍‍‍‍

技术拆解

MCP概念

MCP（Model Context Protocol，模型上下文协议）是2024年11月底，由 Anthropic 推出的一种开放标准。

MCP旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

MCP就像是为AI模型量身定制的“USB-C接口”，可以标准化地连接AI系统与各类外部工具和数据源。包括数据库（例如 PostgreSQL）、API（例如 GitHub）、文件系统（例如 Google Drive）、电子邮件等。

为什么是MCP，而不是传统的API

通常，AI系统想连接外部工具时，需要单独整合多个不同的API。每个API都有独立的代码、文档、认证方式、错误处理和后续维护，极大地增加了开发复杂度。

传统API就像不同的门，每扇门都需要自己的钥匙和特定的规则，要求开发者为每个服务或数据源单独编写代码和整合方案。

MCP与传统API关键区别

单一协议：MCP像一个统一接口，只要一次整合，就能连接多个服务。
动态发现：AI模型能自动识别并使用可用的工具，不用提前写死每个接口。
双向通信：MCP支持类似WebSockets的实时双向通信，模型不仅能查询数据，还能主动触发操作。

拉取数据：模型实时查询数据，如查看你的日历。
触发操作：模型主动向服务器发出指令，如重新安排会议或发送邮件。

为什么要有双向通信？有了MCP提供实时互动，模型能实现：

MCP原理

MCP 的核心思想：客户端-服务器模型(Client-Server Model)

MCP主机（Host）：就是运行 AI 应用（比如 Claude）的环境，运行 MCP 客户端。
MCP客户端（Client）：运行在 AI 模型内部，负责用MCP 协议与 MCP服务器通信。

示例：如果 Claude 想从 PostgreSQL 数据库中获取销售数据，MCP 客户端会将请求格式化，并将其发送给 MCP服务器。

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

针对每种外部资源（比如 PostgreSQL，Google Drive，各种API），都会有一个对应的 MCP 服务器，不同的服务器处理不同类型的外部资源。
示例：如果 Claude 需要从 PostgreSQL 获取数据，PostgreSQL的MCP 服务器会接收来自 MCP 客户端的请求，与数据库通信，获取数据，然后将其发送回 Claude。

简单说，MCP像一座桥梁：它本身不处理复杂逻辑，只负责协调AI模型与工具之间的信息流动。

比如，一个Python脚本（client.py）作为MCP客户端，可以轻松连接MCP服务器，以控制Gmail、Slack或日历应用，无需每个工具单独编写代码。

再举个例子，对于Agent而言：Claude +MCPClient + Mcp Servers = Agent

Claude：提供核心智能和推理能力
MCP客户端：让Claude能够格式化请求并与外部世界通信的接口
MCP服务器：连接各种外部工具、数据源和服务的中介组件

没有MCP，Claude 只是一个强大的语言模型，因为被限制在它自己的内部知识中。

MCP是解锁Claude 潜力，使其成为真正Agent 的关键——一个不仅能理解和生成文本，还能与世界互动、访问信息并执行操作来解决问题和实现目标的Al。

Function Calling 与MCP的概念

Function Calling 指的是 AI 模型根据上下文自动执行函数的机制。Function Calling 充当了 AI 模型与外部系统之间的桥梁，不同的模型有不同的 Function Calling 实现，代码集成的方式也不一样。由不同的 AI 模型平台来定义和实现。

Function Calling和MCP两者是互补，而不是竞争的关系。

三者关系图
Function Calling 是 MCP 服务的消费者，它的输入是可用的 MCP 服务，输出是本次执行要调用的具体 MCP Server。

从代码逻辑来看Function Calling的作用👉

为什么 MCP 会被广泛接受

答：其实是在开发的过程中，将AI模型集成现有的系统或者第三方系统确实挺麻烦。

市面上有一些框架支持 Agent 开发，例如LangChain Tools,LlamaIndex或者是Vercel AI SDK。

LangChain 和 LlamaIndex 虽然都是开源项目，但是整体发展还是挺混乱的，首先是代码的抽象层次太高了，想要推广的都是让开发人员几行代码就完成某某 AI 功能，这在 Demo 阶段是挺好用的，但是在实际开发中，只要业务一旦开始复杂，糟糕的代码设计带来了非常糟糕的编程体验。还有就是这几个项目都太想商业化了，忽略了整体生态的建设。
Vercel AI SDK，尽管代码抽象的比较好，但是也只是对于前端 UI 结合和部分 AI 功能的封装还不错，最大的问题是和 Nextjs 绑定太深了，对其它的框架和语言支持度不够。

所以 Claude 推动 MCP 可以说是一个很好的时机，首先是 Claude Sonnet 3.5 在开发人员心中有较高的地位，而 MCP 又是一个开放的标准，所以很多公司和社区都愿意参与进来，希望 Claude 能够一直保持一个良好的开放生态。

MCP 对于社区生态的好处主要是下面两点：

开放标准给服务商，服务商可以针对 MCP 开放自己的 API 和部分能力。
不需要重复造轮子，开发者可以用已有的开源 MCP 服务来增强自己的 Agent。

4.1 MCP 的好处

简化开发：一次整合，多次复用，不再重复开发。
灵活性强：轻松切换AI模型或工具，无需复杂的重新配置。
实时互动：长连接保证数据实时更新。
安全可靠：内置标准化安全和权限控制。
扩展性强：AI系统扩展时，只需连接新的MCP服务器。

4.2 传统API的优势

如果你的应用场景需要精准且严格受控的交互方式，那么传统API可能更合适。MCP提供广泛而灵活的动态能力，更适合需要上下文理解的场景，但不一定适用于严格受控的场合。

需要细粒度控制、功能严格限制；
更偏好紧耦合以提升性能。

Reference‍‍‍‍‍‍‍‍

参考文章

https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/
https://guangzhengli.com/blog/zh/model-context-protocol/
https://zhuanlan.zhihu.com/p/10528016323
https://www.communeify.com/tw/blog/ai-model-context-protocol-mcp-seamless-data-integration
https://github.com/cyanheads/mod…
https://cline.bot/blog/the-devel…