MCP:AI的「万能插头」?一文带你从零开始玩转模型上下文协议

模型上下文协议(MCP)旨在为AI模型与外部工具交互提供标准化连接。本文通过实例讲解了MCP的工作原理和应用,并探讨了其未来发展。

原文标题:从0到1玩转MCP:AI的「万能插头」,代码手把手教你!

原文作者:机器之心

冷月清谈:

本文介绍了模型上下文协议(MCP),它旨在为AI模型与外部数据源和工具之间的交互提供一个通用、标准化的连接方式。文章通过将MCP类比为餐厅模型,生动地解释了主机、服务器、客户端、智能体和工具在MCP中的角色和相互关系。此外,文章还提供了一个使用IBM的beeAI框架和Brave搜索服务器的Re-Act智能体代码示例,展示了MCP的实际应用。最后,文章探讨了MCP的未来发展潜力和面临的挑战,包括工具发现、安全性和延迟等问题。

怜星夜思:

1、MCP被誉为AI的“万能插头”,你认为它真正普及开来还需要克服哪些关键障碍?除了文章中提到的,还有其他的吗?
2、文章中提到OpenAI也开始支持MCP,如果未来所有的AI平台都支持MCP,会对AI应用开发带来哪些深远影响?
3、文章用餐厅模型来类比MCP,你觉得这个类比是否恰当?如果让你来类比,你会选择什么模型来解释MCP?

原文内容

选自Towards Data Science

作者:Sandi Besen

机器之心编译


在人工智能飞速发展的今天,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 能够克服这些挑战,充分发挥其潜力,为行业带来更多价值。


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

我觉得会加速AI应用的普及。现在很多企业想用AI,但又不知道怎么下手。有了MCP,他们就可以很方便地接入各种AI服务,降低了使用门槛。

如果从程序员的角度来看,MCP更像是“微服务架构”。每个工具都是一个独立的微服务,可以通过API进行交互。MCP就是定义这些API的标准。

如果所有平台都支持MCP,那AI应用开发就真的要起飞了!想象一下,开发者可以像搭积木一样,把不同平台的AI能力组合起来,做出各种各样炫酷的应用,简直不敢想!

从学术角度看,统一的协议标准有助于科研人员更专注于算法和模型的创新,而不是把时间浪费在不同平台的适配上。这绝对是AI领域的一大利好。

我倒觉得像“USB接口”。各种设备都可以通过USB接口连接到电脑上,实现数据传输和功能扩展。MCP也是类似的作用,让不同的AI工具可以方便地连接到AI模型上。

标准化这事儿,说起来容易做起来难。就算MCP是个好东西,大家愿不愿意用还是另一回事。得有足够多的公司和开发者参与进来,形成一个真正的生态,才能让它真正普及。

我更关心成本问题。用这些工具是不是要花很多钱?如果太贵了,小公司或者个人开发者根本用不起,那MCP就只能是大公司的玩具了。

餐厅模型挺形象的,但我觉得用“乐高积木”来比更贴切。每个工具就像一块乐高积木,可以随意组合,搭建出各种不同的AI应用。MCP就是连接这些积木的接口标准。

我觉得除了文章里说的那些,数据安全和隐私也是个大问题。现在各种工具都要连到AI模型上,数据在不同服务器之间传来传去,万一泄露了怎么办?得有更严格的安全协议才行。