从0到1玩转MCP：AI的「万能插头」，代码手把手教你！

在人工智能飞速发展的今天，LLM 的能力令人叹为观止，但其局限性也日益凸显 —— 它们往往被困于训练数据的「孤岛」，无法直接触及实时信息或外部工具。

2024 年 11 月，Anthropic 推出了开源协议 MCP（Model Context Protocol，模型上下文协议），旨在为 AI 模型与外部数据源和工具之间的交互提供一个通用、标准化的连接方式。MCP 的开源性质也迅速吸引了开发社区的关注，许多人将其视为 AI 生态系统标准化的重要一步。

MCP 的好处之一是它们能让 AI 系统更安全。当大家都能用到经过严格测试的工具时，公司就不必「重复造轮子」，这样既减少了安全隐患，也降低了恶意代码出现的可能。

随着 MCP 的逐渐普及，其影响力开始在行业内显现。2025 年 3 月 27 日，OpenAI 也开始支持 MCP 了。

谷歌似乎也在考虑是否加入 MCP 大家庭：

仔细看 MCP 的相关资料，会发现明显存在信息断层。虽然有很多解释「它能做什么」的概述，但当你真想了解它是「怎么运作的」时，资料就变得稀少了 —— 特别是对非专业开发者来说。目前的资料不是过于表面的介绍，就是太过深奥的源代码。

近日，一篇博客以浅显易懂的方式讲解了 MCP，让各种背景的读者都能理解它的概念和功能，读者还可以跟着代码进行实践。

博客链接：https://towardsdatascience.com/clear-intro-to-mcp/

让我们跟随博客一探究竟（注：本文代码截图可能不完整，详见原文）。

通过类比理解 MCP：餐厅模型

首先，让我们将 MCP 的概念想象成一家餐厅，其中：

• 主机（Host）＝餐厅建筑（智能体程序运行的环境）

• 服务器（Server）＝厨房（工具发挥作用的地方）

• 客户端（Client）＝服务员（发送工具请求的角色）

• 智能体（Agent）＝顾客（决定使用哪种工具的角色）

• 工具（Tools）＝食谱（被执行的代码）

现在，我们来看看这家餐厅的「岗位要求」：

主机（Host）

智能体运行的环境。类比餐厅建筑，在 MCP 中，它是智能体或 LLM 实际运行的位置。如果在本地使用 Ollama，用户即为主机；若使用 Claude 或 GPT，则 Anthropic 或 OpenAI 为主机。

客户端（Client）

负责从智能体发送工具调用请求的环境。相当于将顾客订单传递至厨房的服务员。实际上是智能体运行的应用程序或接口，客户端通过 MCP 将工具调用请求传递给服务器。

服务器（Server）

类似厨房，存储各种「食谱」或工具。集中管理工具，使智能体能够便捷访问。服务器可以是本地的（用户启动）或远程的（由提供工具的公司托管）。服务器上的工具通常按功能或集成方式分组，例如，所有 Slack 相关工具可集中于「Slack 服务器」，或所有消息工具可集中于「消息服务器」。这种组织方式取决于架构设计和开发者偏好。

智能体（Agent）

系统的「大脑」，由大语言模型驱动，决定调用哪些工具完成任务。当确定需要某工具时，向服务器发起请求。智能体无需原生理解 MCP，因为它通过每个工具关联的元数据学习使用方法。工具关联的元数据指导智能体如何调用工具及执行方式。需注意，平台或智能体必须支持 MCP 才能自动处理工具调用，否则开发者需编写复杂的转换逻辑，包括从架构解析元数据、以 MCP 格式形成工具调用请求、将请求映射至正确函数、执行代码，并以符合 MCP 的格式将结果返回给智能体。

工具（Tools）

执行具体工作的函数，如调用 API 或自定义代码。工具存在于服务器上，可以是：

• 用户创建并托管在本地服务器的自定义工具

• 他人在远程服务器上托管的预制工具

• 他人创建但用户在本地服务器托管的预制代码

如何协同工作

下面详细介绍 MCP 的具体工作流程：

服务器注册工具：每个工具都需定义名称、描述、输入 / 输出模式及函数处理程序（执行代码），并注册到服务器。这一过程通常通过调用特定方法或 API，向服务器声明「这是一个新工具及其使用方式」。

服务器暴露元数据：服务器启动或智能体连接时，通过 MCP 协议暴露工具元数据（包括模式和描述）。

智能体发现工具：智能体通过 MCP 查询服务器，了解可用工具集。智能体从工具元数据中学习如何使用每个工具。这一过程通常在系统启动时或新工具添加时触发。

智能体规划工具使用：当智能体确定需要某个工具（基于用户输入或任务上下文）时，会按照标准化的 MCP JSON 格式构建工具调用请求，包含工具名称、符合工具输入模式的参数及其他必要元数据。客户端作为传输层，通过 HTTP 将 MCP 格式的请求发送至服务器。

翻译层执行：翻译层接收智能体的标准化工具调用（通过 MCP），将请求映射到服务器上对应的函数，执行该函数，将结果格式化回 MCP 格式，然后发送回智能体。抽象化 MCP 的框架可以完成所有这些工作，开发者无需编写翻译层逻辑（这听起来是个令人头疼的事情）。

MCP Brave 搜索服务器的 Re-Act 智能体代码示例

为了理解 MCP 的实际应用效果，我们可以使用 IBM 的 beeAI 框架，该框架原生支持 MCP 并为我们处理转换逻辑。如果你计划运行这段代码，你需要：

• 克隆 beeAI 框架仓库以获取此代码中使用的辅助类： https://github.com/i-am-bee/beeai-framework ；

• 创建一个免费的 Brave 开发者账户并获取 API 密钥（有免费订阅可用，需要信用卡）；

• 创建一个 OpenAI 开发者账户并生成 API 密钥；

• 将你的 Brave API 密钥和 OpenAI 密钥添加到仓库 Python 文件夹级别的 .env 文件中；

• 确保你已安装 npm 并正确设置了路径。

示例 .env 文件

示例 mcp_agent.ipynb

1. 导入必要的库

2. 加载环境变量并设置系统路径（如有需要）

3. 配置日志记录器

4. 加载辅助函数如 process_agent_events、observer，并创建 ConsoleReader 实例

• process_agent_events：处理智能体事件并根据事件类型（如错误、重试、更新）将消息记录到控制台。它为每种事件提供有意义的输出，以帮助跟踪智能体活动。

• observer：监听来自发射器的所有事件，并将它们路由到 process_agent_events 进行处理和显示。

• ConsoleReader：管理控制台输入 / 输出，允许用户交互并通过带有色彩编码角色的方式显示格式化消息。

5. 设置 Brave API 密钥和服务器参数。

Anthropic 有一个 MCP 服务器列表：https://modelcontextprotocol.io/examples

6. 创建一个 Brave 工具，它将启动与 MCP 服务器的连接，发现工具，并将发现的工具返回给智能体，以便它决定对于给定的任务应该调用哪个工具。 

在此情况下，Brave MCP 服务器上可发现 2 个工具：

• brave_web_search：执行带分页和过滤的网页搜索

• brave_local_search：搜索本地商家和服务

（可选）检查与 MCP 服务器的连接，并在将其提供给智能体之前确保它返回所有可用的工具。

输出

7. 编写创建智能体的函数

• 分配一个 LLM

• 创建一个 brave_tool () 函数的实例，并将其分配给 tools 变量

• 创建一个 re-act 智能体，并给它分配选择的 llm、tools、内存（以便它可以进行持续的对话）

• 向 re-act 智能体添加系统提示

注意：您可能会注意到在系统提示词中添加了一句话：「If you need to use the brave_tool you must use a count of 5.」这是一个临时解决方案，因为在 Brave 服务器的 index.ts 文件中发现了一个错误。用户将为该仓库贡献代码来修复它。

8. 创建主函数

• 创建智能体

• 与用户进入对话循环，并使用用户提示和一些配置设置运行智能体。如果用户输入「exit」或「quit」，则结束对话。

输出:

MCP 凭借网络效应、标准化优势、降低开发成本和行业门槛以及增强互操作性，未来发展潜力巨大。但它也面临挑战，包括工具发现依赖服务器、新增故障点、治理需求、安全考虑和延迟问题。

随着技术的不断发展，我们期待 MCP 能够克服这些挑战，充分发挥其潜力，为行业带来更多价值。