从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 能够克服这些挑战，充分发挥其潜力，为行业带来更多价值。

文章来自于微信公众号 “机器之心”，作者 ：Sandi Besen