前面几篇我们完整地走了一遍：LLM是大脑，Tools是手脚，Agent是把大脑和手脚编排起来干活的框架。但在实际开发中，有一个工程痛点一直没解决------每个工具都要单独适配。
你用OpenAI的API写了一个查天气的工具，换成Anthropic的Claude就得重写一遍参数格式。你给Agent接了一个数据库查询工具，换成另一个框架可能连定义方式都变了。每换一个模型、一个平台，就得重新适配一次，跟出差带了一堆不同接口的充电线一样烦。
MCP就是来解决这个问题的。
MCP是什么？
MCP ，全称Model Context Protocol，中文叫模型上下文协议 。它是一个让LLM与外部世界交互的标准协议。
在MCP出现之前，让LLM连接一个新工具很麻烦。开发者需要为不同的LLM和工具做专门适配------OpenAI的Function Calling有自己的参数格式，Anthropic的Tool Use又是另一套。用今天的流行比喻来说，就像每买一个电子设备就得配一个专用充电器。
MCP定义了一个通用标准：只要工具和客户端都支持MCP，它们之间就可以"即插即用"。你的LLM或Agent运行时就像一个带USB-C接口的电脑，各种支持MCP的服务------Gmail、Slack、数据库、浏览器调试工具------就像U盘、鼠标、显示器。你随时可以把一个MCP服务"插"到Agent上，Agent立刻多一批标准化工具可用。
这对降低AI连接万物的成本意义重大。你不用再为每个工具单独写适配层，一个MCP服务端写好了，所有兼容MCP的客户端都能用。
MCP的核心架构：客户端和服务端
MCP采用的是经典的客户端-服务器架构，但这个架构的巧妙之处在于角色的分离：
MCP服务端是工具和资源的提供方。它暴露三类核心能力：
- Tools：可执行的函数，LLM可以通过Tool Calling触发。比如发送邮件、查询数据库、操作浏览器。
- Resources：可读取的数据源，类似文件系统里的只读文件。比如一个PDF文档、一张数据库表、一段API返回的JSON。
- Prompts：预定义的提示词模板，方便用户快速发起特定类型的任务。
MCP客户端是LLM和Agent运行时的宿主。它负责连接服务端、发现可用的能力和资源、把服务端的工具列表转换成LLM能理解的Schema格式，然后在Agent Loop里处理Tool Calling的完整流程。
客户端和服务端之间通过MCP协议通信，传输方式可以是标准输入输出（适合本地进程），也可以是HTTP加SSE（适合远程服务）。这种设计让MCP既能用于本地的开发工具链，也能用于生产环境的分布式部署。
MCP和Function Calling是什么关系？
这个问题我在学习MCP时也困惑过。仔细梳理之后发现，它们不是互相替代的关系，而是工作在不同抽象层级的互补机制。
Function Calling（或者说Tool Calling）是LLM层面的能力：模型根据你提供的工具描述，决定调用哪个工具、填什么参数，输出一个结构化的调用请求。这是"谁在填工具申请单"的问题。
MCP是协议层面的标准：它规定了工具应该如何被描述、发现、调用，以及调用结果应该如何返回。这是"工具申请单的格式和传递流程应该长什么样"的问题。
MCP没有替代Function Calling，而是给Function Calling提供了一套标准化的工具接入方式。在MCP架构下，LLM仍然在做Function Calling的决策，但工具的定义和调用不再需要每个平台单独适配------MCP客户端会自动把服务端提供的工具描述翻译成当前LLM平台能理解的Schema格式。
举个例子就很清楚了：你有一个MCP服务端暴露了"发送邮件"工具。当你把这个服务端接入支持MCP的Agent时，无论底层LLM是OpenAI还是Anthropic，客户端都会自动把工具描述转成对应的Function Calling参数格式。你不需要为不同LLM重写工具的接入代码。
一次完整的MCP工具调用
结合前面学过的Agent Loop，MCP工具调用在Agent内部大致是这样运转的：
- 连接与发现：MCP客户端连接到服务端，获取可用的工具列表和每个工具的Schema描述。
- 转换与注册：客户端把服务端返回的工具描述转换成LLM平台能理解的格式，注册进Agent的可用工具列表。
- 模型决策：用户提问后，LLM判断需要调用某个工具，输出工具名和参数（标准的Function Calling流程）。
- 调用执行：MCP客户端接收到调用请求，转发给对应的MCP服务端，服务端真正执行并返回结果。
- 结果回灌 ：客户端把工具执行结果作为
tool角色消息写回Context，LLM基于结果继续推理。
整个流程里，模型调用的仍然是我们前面讲过的Function Calling机制，但工具的发现、描述、执行都被MCP标准化了。这对构建复杂Agent来说是一个关键的基础设施------你可以随时给Agent"插"上新的能力，而不用停下来改代码。
为什么MCP对Agent很重要？
还记得前一篇Agent里说的吗？Agent = LLM + Tools + 循环。工具是Agent的手脚，工具越多，Agent能做的事越多。但传统方式下，每增加一种工具都意味着一次适配和接入开发。
MCP改变了这个局面。它把工具从"定制适配"变成了"标准化接入"。一个支持MCP的数据库服务写完，所有支持MCP的Agent都能用；一个开源社区提供的MCP浏览器工具，你下载下来就能"插"到自己的Agent上。
这带来的不仅是开发效率的提升，更重要的是生态效应------工具提供方和Agent构建方可以独立发展、各自迭代，通过MCP这个标准接口对接。这种"即插即用"的能力，是构建复杂Agent系统的关键基础设施。
到这里，我们这个系列的基础概念就全部讲完了。从LLM这个"超级毕业生"开始，到Prompt怎么跟他说话，Context和Memory怎么让他记住东西，Tools和Tool Calling怎么让他动手，RAG怎么让他翻你的私有资料库，Agent怎么把这些能力编排成一个能自主干活的管家，最后到MCP怎么让工具接入变得标准化。
这些概念都不是孤立的。把它们串在一起，你就能理解现代LLM应用开发的完整图景。下一篇，我们聊Workflow------当单个Agent还不够时，怎么把多个Agent串成一条生产线。