最近，正在关注 AI 应用开发的演进，尤其是在如何让模型更好地“使用工具”这个问题上。Function Calling、AI Agents、Retrieval-Augmented Generation（RAG）这些方案已经被广泛讨论和应用。而就在不久前，Anthropic 发布了一个全网爆火的新协议 —— Model Context Protocol（简称 MCP），我觉得它非常值得聊一聊。
MCP 到底是什么？
首先我们看一下官方的 MCP 架构图。
MCP整个协议框架拆解为五个部分，分别是：
- MCP Hosts：也就是 LLM 运行所在的应用程序环境。比如 Cursor、Claude Desktop、Cline 等，这些应用负责启动模型，并与 MCP 协议打通，让模型能够运行在支持插件、具备上下文的环境中。
- MCP Clients：客户端是运行在 Host 内部的桥梁，负责维护与 Server 的一对一连接。它在模型与工具之间起到“代理”的作用，负责请求转发、结果返回、权限验证等任务。
- MCP Servers：这个部分是整个协议中最关键的角色。它负责向 Client 暴露所有可以使用的工具、数据源、API，并通过统一格式（如 JSON Schema）提供参数信息、调用权限、功能描述等。Server 实际上就是模型和外部世界之间的“接线员”。
- Local Data Sources：本地数据源，比如用户的文件系统、本地数据库、甚至运行在本机上的服务。这些资源可以通过 MCP Server 封装后供模型调用。
- Remote Services：外部的 API、SaaS 服务、云数据库、文档平台等，比如 Notion、Google Drive、PostgreSQL 等，统一通过 MCP Server 接入。
在这五个组件中，Server 是连接模型与现实世界的桥梁。Host 和 Client 对熟悉网络架构或前后端开发的同学来说应该都很好理解，它们更偏向于“通信和连接”的职能。但 MCP Server 的角色更复杂 —— 它是整个生态的“调度中心”和“目录服务”。
要理解 MCP Server 的价值，我们可以对比一下 Cursor 上 AI 功能的发展路径。这个过程大致可以分为三个阶段：
- AI Chat：最早期的 AI 只是一个聊天助手。它可以回答问题、给出建议，但最终的行为都是人来完成的。哪怕它帮你写了一段代码，也得你手动复制粘贴到编辑器里。
- AI Composer：这个阶段 AI 已经可以直接修改代码文件了，比如自动重构一个函数或改个变量名。但它仍然离不开人的监督，每一步都需要确认，能力也局限在代码编辑器内部。
- AI Agent：这是 AI 应用的终极形态。它不仅能理解代码，还能自己读取 Figma 图稿生成前端结构，分析日志修复后端 Bug，甚至完成 Git 操作，一键提交 PR。这已经不是“建议”或“半自动”了，而是一个真正能执行完整任务的自动化系统。
而要实现这样的 AI Agent，模型必须具备两个关键能力：一是知道世界上有哪些服务（发现能力），二是能具体调用它们完成工作（执行能力）。MCP Server 恰恰就是为了满足这两个需求而设计的。它对模型暴露“服务目录”：你可以理解成一种更智能的 API 文档，还包含哪些函数可以调用、参数有哪些、调用权限是什么、预期返回结果等等。
模型 Agent 就像是在一个大型操作系统中运行的进程，而 MCP Server 就是它的“系统调用接口”。模型不需要知道背后是调用了哪个数据库还是哪个 HTTP 接口，它只需要从 Server 获取服务定义，构造参数，通过 Function Calling 发起调用，然后处理结果即可。
所以说，MCP Server 是 AI Agent 能够“动手做事”的前提。如果没有这个中间层，模型就只能“说说而已”，始终停留在建议和辅助层面。而有了 MCP Server，模型才具备了行动能力，迈向真正的自动化。
简单来说，Model Context Protocol 是一个为“模型调用外部工具”而设计的开放通信协议。它的目标非常明确：让 AI 模型能以一种统一、标准化的方式接入各种数据源、工具和系统资源。听起来像是 Agent 系统的底层基础设施，对吧？没错，它更像是“AI 工具层的操作系统”。
这个协议定义了模型如何通过 JSON-RPC 协议与外部“工具服务器”通信。每一个工具（比如 Google Calendar、数据库、搜索引擎、文档检索系统等）都可以通过 MCP 协议暴露出自己的接口，包括输入参数、返回结果的格式，甚至还有权限控制等信息。这样，模型就可以动态地去发现、调用、组合这些工具，就像人类在使用插件一样自由。
那 MCP 和 Function Calling、AI Agents 有啥不一样？
我们可以从几个维度来理解 MCP 与其它方案的区别：
1. 和 Function Calling 相比
OpenAI 的 Function Calling 本质上是一种“模型调用函数”的能力，开发者在调用模型时附带一组函数定义，模型会根据意图调用函数。这种方式虽然灵活，但依赖预先定义和注册，难以动态扩展。
而 MCP 的做法是标准化了“工具发现”和“通信协议”。你不需要每次都重新注册函数，只要你的工具实现了 MCP 协议，任何模型都能通过 MCP 主机自动发现和调用它。可以理解为 MCP 是 Function Calling 的升级版 —— 从“模型内部注册函数”走向了“模型动态发现外部工具”。
2. 和 AI Agents 相比
传统的 Agent 框架，比如 LangChain 或 AutoGPT，更关注的是模型如何规划一系列工具调用来完成任务（也就是“推理”逻辑），但这些框架里调用工具的细节五花八门，没有统一的规范。
MCP 不处理推理规划问题，它只关心一件事：把工具调用的接口标准化、可复用、可组合。这就像我们开发网页时需要 RESTful API，一旦大家都遵守这个标准，工具之间才能高效协作。
你可以把 MCP 看成是 Agent 框架的基础设施，Agent 决定“干什么”，MCP 负责“怎么做”。
3. 和 RAG（检索增强生成）相比
RAG 更像是给模型“投喂”知识，比如把企业文档变成向量库让模型检索，算是一个“被动喂饭”的过程。而 MCP 是让模型“主动出门找饭吃” —— 模型自己发现工具、发请求、拿结果、继续处理，具备了主动决策和执行的能力。
RAG 是补脑，MCP 是装手。
MCP 带来了哪些可能性？
这部分让我特别兴奋。MCP 不仅让模型能动态访问工具，它还让这些工具之间互相组合成为可能。这意味着我们可以搭建出一整套由模型驱动、跨工具协作的应用系统：
- 模型 A 先从 Notion 查一份文档；
- 然后把摘要发给 Slack 群组；
- 再创建一个待办事项到 Google Calendar；
- 最后发一封邮件通知相关人员。
整个过程模型自己就能完成，而每个步骤都只是 MCP 协议下的一个工具调用。这种“多工具流水线”是 Function Calling 很难做到的，也是当前 Agent 系统实现起来比较繁琐的。
那 MCP 会带来什么变化？
对开发者来说，MCP 可能会改变我们开发 AI 应用的方式。从“我给模型写插件”变成了“我写 MCP 工具服务器，模型自动识别和调用”。工具开发和模型调用解耦了，开发者只需要专注把业务逻辑变成一个 MCP 兼容的服务即可。
从生态的角度来看，一旦有足够多的工具实现 MCP（比如数据库、文件系统、GitHub、Jira、PostgreSQL、Notion 等等），我们就能构建出真正“全栈 AI 助手”的底座 —— 一个可以动态组装、调用、记忆和推理的 AI 工作空间。
而对于模型厂商来说，MCP 也降低了工具接入的门槛。不需要每次都训练模型识别某个工具的用法，只要协议标准化了，调用逻辑就可复用。无论是 Claude、ChatGPT，还是 Gemini，只要都支持 MCP，就可以“通用调用工具”，这其实是模型之间“互联互通”的第一步。
目前，已经有不少公司和开源组织开始围绕 MCP 构建生态了。Claude Desktop 已经内置 MCP Host，Zed 和 Replit 等也正在支持。我们可以预见，在不远的将来，MCP 很可能会成为 AI 应用中工具调用的事实标准。
如果说 Function Calling 是模型的“打电话”能力，那 MCP 更像是给模型配了一个“工具台”，上面有按钮、仪表盘、开关……模型不再只是坐着等问题，而是具备了主动动手解决问题的能力。
下一代 AI 应用，或许就是这样搭建出来的。
MCP 的一些资源
下面是一些 MCP 的资源，大家可以参考一下。
MCP 官方资源
社区的 MCP Server 的列表
MCP 官方集成教学：
- Git - Git 读取、操作、搜索。
- GitHub - Repo 管理、文件操作和 GitHub API 集成。
- Google Maps - 集成 Google Map 获取位置信息。
- PostgreSQL - 只读数据库查询。
- Slack - Slack 消息发送和查询。
支持 MCP 的 第三方平台官方
由第三方平台构建的 MCP 服务器。
MCP 服务器 社区
下面是一些由开源社区开发和维护的 MCP 服务器。
- AWS - 用 LLM 操作 AWS 资源。
- Atlassian - 与 Confluence 和 Jira 进行交互，包括搜索/查询 Confluence 空间/页面，访问 Jira Issue 和项目。
- Google Calendar - 与 Google 日历集成，日程安排，查找时间，并添加/删除事件。
- Kubernetes - 连接到 Kubernetes 集群并管理 pods、deployments 和 services。
- X (Twitter) - 与 Twitter API 交互。发布推文并通过查询搜索推文。
- YouTube - 与 YouTube API 集成，视频管理、短视频创作等。
