Inside MCP: 让智能体真正连接现实世界的关键环节
引言
大型语言模型（LLMs）很强大。它们可以解释概念、推理问题，并生成几乎任何主题的文本。但有一个限制：它们对你的世界一无所知。它们无法查看你公司的数据库、检查今天的日志，或更新系统中的记录。单独使用时，它们是聪明的——但与现实脱节。
这就是 Model Context Protocol (MCP) 的价值所在。MCP 为智能体提供了一种标准方式来连接真实的系统和数据。它定义了智能体（客户端）如何与暴露工具、文件或 API 的服务器通信。有了 MCP，智能体不再只是聊天界面，而是可以真正参与到工作流中。
参考资料: ModelContextProtocol.io
LLM、Agent、MCP 与系统之间的关系
要理解 MCP，可以先看看各个部分之间的关系：
用户 → Agent → LLM
↓
MCP Client → MCP Server → 系统/APIs → 数据- 用户：用自然语言和智能体交互。
- Agent：控制器。决定何时调用 LLM 进行推理，何时调用 MCP 来执行操作。
- LLM：推理引擎。当智能体需要时生成文本、答案或计划。
- MCP Client：智能体在 MCP 中的角色，负责发出请求。
- MCP Server：系统在 MCP 中的角色，负责暴露工具和数据。
- 系统/APIs：现有的软件和服务，提供实际功能。
- 数据：存储在这些系统中的信息。
简而言之：智能体调用 LLM 来获取智能，并通过 MCP Client/Server 连接真实的系统和数据。
Agent 作为 MCP Client
在 MCP 中，角色非常清晰：
- Agent（MCP Client） 发出请求：“你能做什么？能帮我取这个文件吗？能执行这个查询吗？”
- MCP Server 返回响应：“这些是我支持的工具。这是你要的结果。”
这种方式的强大之处在于，你不必为每个新的智能体或系统单独开发集成。任何实现了 MCP 的服务器，都能被 MCP 支持的智能体使用。
MCP 重要性
如果没有 MCP，智能体只能依赖训练时的数据，或少量硬编码的 API。这意味着：
- 它能解释 SQL 语法，但不能真正执行查询。
- 它能描述如何查看日志，但不能自己去取。
- 它能建议一个工作流，但不能亲自跑通。
有了 MCP，智能体可以：
- 连接数据库，提取实时数据。
- 获取当天的日志并生成总结。
- 跨不同系统执行工作流步骤。
这就是“聪明的顾问”和“真正的助手”之间的区别。
从 API 到 MCP
API 一直是软件间通信的标准手段，功能强大，但前提是开发者必须清楚要调用哪个接口以及具体的调用方式。
MCP 是为智能体设计的。与固定的 API 调用不同，智能体可以发现 MCP Server 提供了哪些工具，并根据用户的请求决定使用哪些。
你可以把它看作是软件交互方式的下一步演进：
- GUI：人点按钮。
- API：程序调接口。
- MCP：智能体发现工具并执行操作。
总结
MCP 带来了一个简单但关键的转变：
- LLMs 是推理引擎。
- Agents 包装 LLM，并作为 MCP 客户端。
- MCP Servers 暴露工具和数据。
- 系统与 APIs 提供真正的功能。
- 数据 是智能体最终需要访问和使用的部分。
通过引入 MCP，智能体不再只是回答问题，而是能够在真实的系统和数据中执行操作。
下一篇文章，我们将深入探讨 MCP 如何把智能体连接到数据库、文件和 APIs —— 并展示实际案例。