注：此文章内容均节选自充电了么创始人，CEO兼CTO陈敬雷老师的新书《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】

清华《GPT多模态大模型与AI Agent智能体》书籍配套视频课程【陈敬雷】

GPT多模态大模型与AI Agent智能体系列九十三

MCP：AI工具调用的"万能接口"！从Claude到本地模型，揭秘智能体如何打破生态壁垒

在AI智能体（Agent）飞速发展的今天，工具调用已成为衡量其能力的核心标准。然而，不同模型、不同工具之间的"语言壁垒"始终是行业痛点：OpenAI的Function Call、Google的Tool API、国内模型的自定义工具链……开发者往往需要为每个组合编写专属代码，陷入"重复造轮子"的困境。

2024年，Anthropic提出的MCP（Model Context Protocol，模型上下文协议）犹如一声惊雷，试图成为AI领域的"USB-C"——用统一标准打通大模型与工具的交互通道。从Claude到本地部署的小模型，从企业级应用到个人开发者的玩具，MCP正在重塑智能体的生态格局。本文将系统拆解MCP的技术内核、与传统工具调用的差异、支持的模型与应用场景，带你看清这场AI交互革命的全貌。

一、MCP的诞生：为AI工具调用"终结混乱"

回顾AI工具调用的发展历程，我们会发现MCP的出现并非偶然，而是技术演进的必然结果。

早期的大模型如同"信息囚徒"，知识被锁死在训练数据的时间节点上——2023年训练的模型永远不知道今天的天气，更无法访问企业内部数据库。为了打破这种局限，开发者们尝试了各种"补丁方案"：

• RAG（检索增强生成） 让模型能被动接收外部文档，但无法主动决定"查什么"；
• ReAct框架 引导模型用自然语言输出工具调用指令（如Search[北京天气]），但解析格式全靠提示工程，稳定性堪忧；
• Function Call 用结构化JSON规范工具调用，却陷入"生态壁垒"——OpenAI、Google、国内模型的协议互不兼容，换模型就意味着重写代码。

正如北方的郎在回答中类比："这就像前USB-C时代的电子设备，每个工具都带专属线缆，抽屉里永远堆满无法通用的接口。“而MCP的核心使命，就是成为AI领域的"万能接口”：无论你用的是Claude、GPT-4o，还是本地部署的Qwen2.5，无论工具是天气API、企业数据库还是智能家居，都能通过同一套协议顺畅交互。

Anthropic对MCP的定位非常清晰：它不是某款模型的专属功能，而是一套开放的"交互语言"。这意味着任何模型、任何工具，只要遵循MCP规范，就能无缝对接——这也是它与Function Call等技术的本质区别。

二、MCP的核心架构：三组件撑起"万能接口"

要理解MCP的魔力，需先看懂其"客户端-服务器-主机"的三元架构。这套架构看似复杂，实则像一个分工明确的"项目团队"，每个角色都有不可替代的作用。

• 主机（Host）：智能体的"大脑总部"
  主机是MCP的发起者，通常是具体的AI应用——可能是Claude客户端、代码编辑器插件（如Cursor），也可能是个人开发者写的聊天机器人。它的核心职责是：接收用户需求、管理整体交互流程、协调客户端与服务器的协作。
  举个例子：当你在Cursor中输入"用百度地图查下公司到机场的路线，再用Slack发给同事"，Cursor就是"主机"——它需要判断该调用哪些工具，以及如何把结果整合给用户。

• 服务器（Server）：工具能力的"封装器"
  服务器是工具的"代言人"，每个服务器对应一类具体能力。比如：

  • 百度地图MCP服务器封装了"路线查询""POI搜索"等工具；
  • 企业内部服务器封装了"数据库查询""订单系统调用"等私有工具；
  • 智能家居服务器封装了"开灯"“调温"等控制指令。
    服务器的关键作用是"标准化能力输出”：它会用MCP协议描述工具的名称、参数（如get_route(start, end)）、返回格式，让任何客户端都能看懂"如何使用我"。正如段小草在实验中提到的：“哪怕是控制家里的Home Assistant，只要封装成MCP服务器，模型就能调用——万物皆可MCP。”

• 客户端（Client）：协议交互的"翻译官"
  客户端是主机与服务器之间的"桥梁"，负责处理所有MCP协议的细节。它的工作流程堪称"全能秘书"：

  1. 向服务器"打听"可用工具（比如"百度地图服务器有哪些功能？"）；
  2. 把工具列表整理成模型能理解的格式（附带上参数说明、调用示例）；
  3. 接收模型的调用指令（如调用get_route，参数start=公司，end=机场），翻译成服务器能看懂的MCP协议；
  4. 把服务器的返回结果（如路线信息）反馈给模型，形成闭环。

三者协同的流程像一场精密的"接力赛"：用户需求由主机接收，客户端负责"牵线搭桥"，服务器提供具体能力，最终通过大模型的推理生成答案。这种架构的妙处在于——任何一环的替换都不影响整体运行：换模型（从GPT-4o到Qwen2.5）、换工具（从百度地图到高德），只要遵循MCP规范，系统就能自动适配。

三、MCP vs Function Call：不止是"标准化"那么简单

很多人会把MCP与OpenAI的Function Call混为一谈，但实际上，二者的差异远超"格式规范"的范畴，本质是"生态思维"的不同。

维度	Function Call（以OpenAI为例）	MCP
工具管理方式	静态定义，需在每次请求中手动传入工具列表	动态发现，客户端自动向服务器查询工具
模型依赖	依赖模型原生支持（如GPT-4o的tool_calls字段）	不依赖模型原生支持，通过提示工程实现
跨模型兼容性	差（OpenAI格式与Google、国内模型不通用）	强（任何模型只要能理解指令即可）
工具复用性	低（工具定义需在每个应用中重复编写）	高（服务器封装后可被无数主机调用）
通信方式	单向（模型→工具，无工具主动推送）	双向（支持工具主动向模型推送信息）

段小草在实验中生动地展示了这种差异：他用本地部署的Qwen2.5-0.5B（仅5亿参数的小模型）成功调用了MCP服务器控制智能家居。"MCP的核心是’指令遵循’，而不是模型有多强。"他解释道，“哪怕是小模型，只要能看懂’调用xxx工具，参数是xxx’的提示，就能用MCP。”

这种"去模型依赖"的特性，让MCP具备了极强的包容性。相比之下，Function Call更像"闭源生态"：模型厂商定义规则，开发者必须跟着走；而MCP是"开源接口"，谁都可以参与制定规则，这也是它能快速被国内模型接纳的关键。

四、哪些模型支持MCP？从Claude到本地小模型的全名单

提到MCP，很多人第一反应是"只有Claude支持"——这其实是对MCP的最大误解。正如tomsheep在回答中强调：“不是Claude这个’模型’支持MCP，而是Claude这个’应用’实现了MCP协议。”

事实上，MCP对模型的要求极低：只要具备基础的"指令遵循能力"，能理解"如何调用工具"的提示，就能接入MCP生态。目前支持（或可通过适配支持）MCP的模型/应用主要分为三类：

1. 原生支持MCP的应用（内置客户端）
   这类应用本身实现了MCP客户端，用户无需额外开发即可调用MCP服务器。

   • Claude（Anthropic）：作为MCP的提出者，Claude客户端原生支持MCP协议，可直接连接第三方服务器（如百度地图MCP服务器、Slack MCP服务器）。
   • Cursor（代码编辑器）：程序员常用的AI编辑器，通过MCP对接GitHub、Stack Overflow等工具，实现"写代码时自动查API文档"。
   • Roo Cline（智能体框架）：支持用户自定义MCP服务器，兼容GPT-4o、DeepSeek-R1等多种模型作为"大脑"。

2. 国内主流大模型（通过适配支持）
   国内模型虽未原生集成MCP，但通过简单的提示工程或SDK适配，即可接入MCP生态。

   • 通义千问（阿里）：开发者可通过Spring AI等框架封装MCP客户端，让千问模型调用MCP服务器的工具（如实验中调用天气API）。
   • 文心一言（百度）：支持自定义工具链，通过MCP协议转换层，可对接百度地图、百度搜索等自家服务的MCP服务器。
   • 智谱AI（GLM）：小参数模型（如GLM-4-9B）也能通过MCP调用工具，适合本地部署的轻量化智能体。

3. 本地小模型（低门槛接入）
   即便是参数小于10B的本地模型，只要能理解结构化指令，就能玩转MCP。

   • Qwen2.5-0.5B/1.8B：段小草的实验证明，仅5亿参数的Qwen2.5小模型，可通过MCP控制智能家居，完成"开灯""调温"等操作。
   • Llama 3-8B：开源社区已出现MCP适配插件，让Llama 3在本地调用企业数据库、执行Python代码。

五、MCP的落地实践：从企业级应用到个人玩具

MCP的价值不仅在于技术创新，更在于其强大的落地能力。从企业效率工具到个人开发者的创意项目，MCP正在渗透到AI应用的方方面面。

• 企业级：打破数据孤岛
  某连锁零售企业通过MCP搭建了"智能运营助手"：

  • 部署"库存系统MCP服务器"，封装"查库存""调货"等工具；
  • 部署"会员系统MCP服务器"，封装"查消费记录""发优惠券"等工具；
  • 用通义千问作为"大脑"，通过MCP客户端调用上述服务器，实现"用户咨询时自动查库存+推优惠券"的闭环，员工无需切换系统。

• 开发者生态：工具复用成潮流
  MCP服务器的"一次开发，多端复用"特性，让开发者乐于分享工具。

  • 有人开发了"抖音爬虫MCP服务器"，支持智能体自动爬取视频数据、分析热门话题；
  • 开源社区出现"本地文件管理MCP服务器"，让智能体通过MCP读写本地文档，避免重复开发文件操作工具。

• 个人玩家：低成本玩转智能体
  个人开发者无需高深技术，就能用MCP搭建专属智能体：

  • 学生用MCP对接"知网MCP服务器"和"Python执行服务器"，实现"查论文时自动跑数据可视化代码"；
  • 极客通过MCP连接"监控摄像头服务器"和"短信服务器"，做一个"异常情况自动报警"的家庭安防智能体。

六、MCP的挑战与未来：标准化之外的隐忧

尽管MCP前景广阔，但其落地过程中仍面临不少挑战：

1. 上下文占用问题
   随着MCP服务器和工具增多，客户端需要向模型传入的"工具清单"会越来越长。段小草的实验显示，仅启用2个服务器、9个工具，就占用了1500 tokens的上下文空间——这对小模型的理解能力是极大考验，也可能挤压对话历史的空间。

2. 安全与权限边界
   MCP的"万能接口"特性也带来了安全风险：一个恶意的MCP服务器可能骗取模型调用敏感工具（如企业数据库查询）。目前行业的解决方案是"宿主（Host）管控"——由应用层决定哪些服务器可接入、哪些工具可调用，类似手机的"应用权限管理"。

3. 生态碎片化风险
   虽然MCP旨在统一标准，但不同厂商可能推出"MCP扩展协议"（如增加私有字段），久而久之又可能形成新的壁垒。这需要社区共同维护协议的开放性，避免"名为标准，实为垄断"。

结语：MCP重构AI的"能力边疆"

从USB-C统一电子设备接口，到TCP/IP成为互联网的基石，历史反复证明：统一标准是技术生态爆发的前提。MCP之于AI智能体，正扮演着这样的角色。

它让大模型摆脱了"模型厂商绑定"，让工具开发者无需适配数十种模型，让用户能用任何模型调用任何工具——这种"解耦"思维，正是AI从"单打独斗"走向"协同智能"的关键。

未来，随着MCP生态的成熟，我们可能会看到：一个本地小模型通过MCP调用全球的工具资源，一个企业智能体通过MCP对接上百个服务商——而这一切，都源于那个简单却伟大的愿景：让AI的工具调用，像插USB线一样简单。

对于开发者而言，现在正是入局MCP的最佳时机：无论是开发一个MCP服务器分享工具，还是用MCP搭建智能体，都可能在这场AI交互革命中抢占先机。毕竟，谁掌握了"万能接口"，谁就掌握了AI时代的主动权。

更多技术内容

更多技术内容可参见
清华《GPT多模态大模型与AI Agent智能体》书籍配套视频【陈敬雷】。
更多的技术交流和探讨也欢迎加我个人微信chenjinglei66。

总结

此文章有对应的配套新书教材和视频：

【配套新书教材】
《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】
新书特色：《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）是一本2025年清华大学出版社出版的图书，作者是陈敬雷，本书深入探讨了GPT多模态大模型与AI Agent智能体的技术原理及其在企业中的应用落地。
全书共8章，从大模型技术原理切入，逐步深入大模型训练及微调，还介绍了众多国内外主流大模型。LangChain技术、RAG检索增强生成、多模态大模型等均有深入讲解。对AI Agent智能体，从定义、原理到主流框架也都进行了深入讲解。在企业应用落地方面，本书提供了丰富的案例分析，如基于大模型的对话式推荐系统、多模态搜索、NL2SQL数据即席查询、智能客服对话机器人、多模态数字人，以及多模态具身智能等。这些案例不仅展示了大模型技术的实际应用，也为读者提供了宝贵的实践经验。
本书适合对大模型、多模态技术及AI Agent感兴趣的读者阅读，也特别适合作为高等院校本科生和研究生的教材或参考书。书中内容丰富、系统，既有理论知识的深入讲解，也有大量的实践案例和代码示例，能够帮助学生在掌握理论知识的同时，培养实际操作能力和解决问题的能力。通过阅读本书，读者将能够更好地理解大模型技术的前沿发展，并将其应用于实际工作中，推动人工智能技术的进步和创新。

【配套视频】

清华《GPT多模态大模型与AI Agent智能体》书籍配套视频【陈敬雷】
视频特色： 前沿技术深度解析，把握行业脉搏

实战驱动，掌握大模型开发全流程

智能涌现与 AGI 前瞻，抢占技术高地

上一篇：《GPT多模态大模型与AI Agent智能体》系列一》大模型技术原理 - 大模型技术的起源、思想
下一篇：DeepSeek大模型技术系列五》DeepSeek大模型基础设施全解析：支撑万亿参数模型的幕后英雄