前言 #
MCP 基于大模型，相当于 HTTP 基于互联网。
MCP 是目前大火的概念。不少人认为，MCP 基于大模型，相当于 HTTP 基于互联网。
对此我比较认同。当我看到 MCP 时，第一感受是：做应用开发的程序员终于有活干了。
大模型终究是巨头们竞争的舞台，就像操作系统一样，硝烟平息之后，可能只剩下那么几家。
整个产业的繁荣，还是得依靠大量的应用开发者，就像 iOS 和 Android 平台上的千万开发者推动互联网的浪潮一样。
当然，在 AI 编程工具的竞争下，程序员的需求量势必是会下降的，这个就是后话了。
现在我们要做的就是，学好 AI 技术，用好 AI 编程工具，学好 MCP.
MCP 是什么 #
MCP (Model Context Protocol，模型上下文协议) 是由 Anthropic 在 2024 年底推出的一种开放协议，它通过提供一种标准化的接口，旨在通过标准化的接口实现大语言模型 (LLM) 与外部数据源及工具的无缝集成。
最初推出时，仅有 Claude 的桌面应用支持，市场反响平平，且不乏质疑之声。但近期，随着诸多 AI 编辑器 (如 Cursor、Windsurf，以及 Cline 等插件) 纷纷加入对 MCP 的支持，其热度逐渐攀升，已然展现出成为事实标准的潜力。
Before / after MCP #
为何 MCP 会诞生，它要解决什么问题？
理解 MCP，先要了解其为何诞生。
即 MCP 出现之前，我们面临什么问题，而 MCP 又如何解决这一问题。
-
Before MCP
最初，大语言模型确实掌握了语言，但也仅限语言。
问黄鹤楼的历史，它能 balabala 告诉我们一大堆。
问能否帮忙在 blender 创建某种场景，它能告诉我们操作步骤，但也仅此而已。
「只能说，不能做。」
问我有没有新邮件，它只能说，抱歉，没有能力读取你的邮箱信息。
「只能获取公开信息，获取不了私域信息。」
-
Function Calling
要让大模型突破语言，扩展出更多能力。
我们需要一些 function 来让大模型 call.
2023 年 6 月，OpenAI 首次在 GPT-4 和 GPT-3.5-turbo 中集成了 Function Calling，让大模型具备了调用 function 的能力。这一举措意义重大，首次将大模型从「纯文本生成」升级为「可编程接口」。
紧随其后，Anthropic（Claude）、Google（Gemini）、Meta（Llama）等厂商陆续推出类似功能。但由于没有形成统一的标准，大家的实现方式各异，在调用格式和调用逻辑上均有差别，导致生态碎片化。
如上图所示，不同的大模型使用各自实现的 function call 去调用目标服务，未能形成统一生态。
-
After MCP
MCP 其实就是标准化的 Function Calling.
2024 年底，Anthropic 发布 MCP 协议，旨在统一碎片化的 Function Calling 生态。以目前市场、社区热度，以及主要大模型及应用厂商的集成情况来看，MCP 显然已经成为统一标准。
架构 #
MCP 长啥样？
下图是 MCP 官方提供的架构图，比较简单，总结下来就是：实现了 MCP Client 的 Host 应用，通过同一套 MCP 协议与不同的 MCP Server 对接，各 Server 提供了各自的不同能力。
我通过下图将其更加具象化地呈现。
我们的聊天应用实现了一个支持 MCP 协议的 Client，Gmail 服务和 Blender 应用则各自实现了 MCP Server. 就像是装上了标准插头，我们的聊天应用和 Gmail 及 Blender 对接了起来，通过 MCP 协议可以调用它们提供的能力。
MCP (以及 Function Calling) 在本质上其实和 RPC (Remote Procedure Call) 远程过程调用是相通的。
即一种专门面向大模型应用场景的 RPC.
一个小 Demo #
为了更直观地理解 MCP，我们直接实现一个小而完整的 demo 来进行演示。
MCP 的架构简单，实现起来也不难。
官方已经提供了各种语言的 SDK 来帮助我们快速完成 Client 及 Server 的开发。
我们使用 Python 实现一个聊天工具，通过自然语言的交互，可以帮你：
- 获取本机工作空间中的文件列表
- 在本机工作空间中新建文件
代码量很小，包括：
- server: 10+ 行
- client: 20+ 行
- chat: 100+ 行
其它信息：
- LLM API 提供商：OpenRouter
- LLM： Google Gemini2.0 pro
代码会贴在最后，不在此处展开。
实际上，应用本身很简单，关键的是理解协议的原理及流程。
原理及流程 #
我们举一个日常生活中办事的例子，来类比 MCP。
假设有一位用户去服务大厅办事，不过是简单地查询一些个人信息（调人才档案），但是却涉及到了跨部门协作（所查询的信息保存在文件管理处）。以往的话，服务大厅会开一个介绍信，告诉用户，凭介绍信去文件管理处，你的档案在那里。
但是现在，服务大厅和文件管理处都增设了外联部。服务大厅通过外联部与文件管理处取得通讯后，对方直接将用户的档案发送了过来。因而用户不用再多跑一趟腿，直接在服务大厅就办完了事情。
类比到 MCP，概念映射如下：
- 用户：即用户
- 服务大厅：用户所使用的 agent 软件，如 Claude Desktop、Windsurf、Cline
- 咨询部：聊天窗口
- 决策部：大模型
- 外联部：MCP Client
- 文件管理处：具备文件管理能力的软件
- 外联部：MCP Server
- 执行部：文件管理接口
用户来到 Agent 服务大厅，想知道自己的工作空间中有哪些文件。咨询部将此问题传达给了大模型，大模型经过思考后，认为应该找文件管理处。于是让外联部与文件管理处联系。由文件管理处的执行部门完成文件的查询工作。
文件管理处完成查询工作后，将结果通过外联部反馈回了服务大厅。决策部根据查询的结果，组织了清晰而友好的回复内容，最终由咨询部向用户进行回复。
以下是一个更为详细和严谨的时序图。
关键概念 #
以上我们一直是使用 tool 来举例分析。
还有一些其它的关键概念我们在此简单提一下。
Resources #
Resource 用于 server 向 client 提供可获取的数据。可以包括文件内容、数据库记录、API 返回、系统数据、图片、日志文件，等等。
Tools #
Tool 用于 server 向 client 提供可执行的操作。
它很像是 RPC 远程调用，让 client 具备了超出其运行环境的调用能力。
Prompts #
Server 可以定义好一些 prompt 提示词，这些提示词可以给到 client，由 client 提供给用户及 LLM，从而能够帮助用户及 LLM 更好地完成任务。
Samplings #
Sampling 允许 server 向 client 发送其希望 LLM 执行的操作。
Sampling 的请求和返回均由 client 来传递，client 可以对请求内容进行修改。
Roots #
Roots 用于定义 server 聚焦的资源边界。client 可以通过它来告诉 server 应该聚焦于哪些资源。
Roots 以 URI (Uniform Resource Identifier) 的形式提供，包括 HTTP URL、文件路径等。
如：
file:///home/user/projects/myapp
<https://api.example.com/v1>应用场景 #
实体 → 数字化 → agentic 化
MCP 的应用场景非常有潜力，想想互联网浪潮，一切都数字化了，而在将来，一切都要 agentic 化。这些都是 MCP 施展的地方。
在此不展开哪个具体场景。不妨看看目前市场上已有的 MCP Server，获取能够受到启发。
以下是两个 MCP Server 商城页面的截图，从 categories 中可以看到非常广泛的类别。
另外提一下，连支付宝都已经支持 MCP 了。以后 agent 就可以自己找我们收钱了，还挺赛博的。。。
