Agent 保姆级万字详解·第四章MCP 协议AI 世界的USB 接口《上一章》我们写了 Function Call学会了怎么让 LLM 调用外部工具。用户问天气LLM 输出一个 JSON代码去查 APILLM 把结果翻译成人话——这套路子走通了很漂亮。但问题也跟着来了。你用 OpenAI 的模型定义了一套工具。现在老板说咱们以后要用国产模型降本嘛。你打开代码一看——好家伙OpenAI 的Tool结构、Claude 的ToolUse结构、国产模型的 tool schema三套完全不一样。你得把每个工具的定义重写一遍。更夸张的是你辛辛苦苦写了一套查天气、查机票、发邮件、读数据库的工具。现在隔壁组也想用他们用的是另一个 Agent 框架——你猜怎么着不好意思工具没法直接给对方用又得重来一遍。有没有一种办法让工具只写一次所有模型、所有框架都能直接用这就是 MCP 协议要解决的问题。没有标准的痛苦一个真实的开发场景我先给你讲个故事这个故事是我一个朋友亲身经历的细节略有加工但绝对真实。小张是个后端开发在一家中型互联网公司负责 AI 平台建设。老板说“我们要做一个内部 AI 助手能帮员工查日程、查文档、发通知。”小张接到需求就开始干了。他调研了一圈选了 OpenAI 的 Function Call 方案吭哧吭哧写了三个月终于把功能做完了部署上线效果不错。结果第三个月老板又说了咱们以后 AI 助手要接入 Claude效果更好。小张打开代码一看傻眼了——整套 Function Call 的实现都是基于 OpenAI 的 SDK 写的工具定义、参数校验、调用流程全部得重写因为 Claude 的 tool_use 结构和 OpenAI 完全不是一回事。又干了一个月终于接入了 Claude。结果第四个月老板又说财务那边想用他们用的是一个国产 Agent 框架接口不一样。小张当时的心情大概就像一个人同时插了三种互不兼容的充电线——线都在手里能用的一个都没有。反正就是小张花了大半年写的工具代码每次换模型都得改一遍工具本身一个没变但接口全得重写。这不是技术问题这是工程管理问题。再这样下去小张每天的工作就是——改接口。这个故事告诉我们什么工具和模型不应该紧耦合。工具应该独立存在模型应该去适应工具而不是反过来。MCP 协议解决的就是这个问题。互联网早期的历史重演其实技术圈每隔几年就会遇到一次协议不统一的问题然后有人出来做标准大家纷纷跟进问题解决。咱把时间拨回 1990 年代。那时候互联网刚起步每个网站自己做自己的通信协议。用户要访问不同的网站得装不同的客户端软件。A 网站的客户端打不开 B 网站的内容C 网站又有一套完全不同的访问方式。整个互联网像一堆互不相通的孤岛。后来 Tim Berners-Lee 出手了搞了个 HTTP 协议。所有人都用同一套规则——你用 IE 能访问新浪我用 Netscape 也能访问新浪因为大家都遵循 HTTP。互联网因此连成了一张大网。再后来程序员做后端开发早年也是各家自己定义 API 格式。张三的接口返回{code:0,data:{}}李四的返回{status:ok,result:{}}王五的返回 XML。你写一个 SDK 适配张三过两年公司换成李四的系统SDK 又得重写。再后来 RESTful 风格出来了GET /users/123、POST /orders统一的 URL 规范、统一的 HTTP 方法、统一的状态码。SDK 写一份能跑通一堆 API。现在的 AI 开发正处于协议混战的年代。每个模型厂商有自己的 Function Call 格式每个 Agent 框架有自己的工具定义方式互相不兼容。MCP 协议就是来做这个标准化工作的。你把 MCP 理解为 AI 时代的 HTTP——工具定义和模型无关了只要你的工具符合 MCP 协议任何支持 MCP 的模型都能直接调用。什么是 MCPMCP全称Model Context Protocol中文翻译是模型上下文协议。它是由 AnthropicClaude 的母公司在 2024 年底发布的一个开放标准。它的目标用一句话说清楚就是让 AI 模型和外部工具之间的交互标准化、可复用、可插拔。你可能会问MCP 和 Function Call 是什么关系打个比方。Function Call 像是你每换一个手机就得重新配一条充电线——苹果用 lightning华为用 Type-C小米又是另一套。而 MCP 像是USB 接口——不管是苹果手机还是安卓手机不管是充电还是传数据一根 USB 线全搞定。具体来说Function Call定义的是LLM 和工具之间传递的信号格式——也就是我要调用这个函数参数是这样。这是必要的基础协议。MCP定义的是工具本身怎么暴露自己、怎么被调用、怎么返回结果——也就是这个工具是谁、它能干什么、怎么找到它、怎么调用它。这是在 Function Call 之上的更高层抽象。你可以理解为Function Call 是说话的内容MCP 是说话的规范。MCP 让 Function Call 不再是各说各话而是有了一套统一的接口契约。MCP 的基本架构MCP 的架构说起来不复杂一共就三个角色。MCP Server工具的发布者MCP Server 是一个独立的程序它负责把一个或多个工具暴露出来。比如你写了一个查天气的服务按照 MCP 规范把它包装成一个 MCP Server。那么任何支持 MCP 的 AI 模型都能发现这个 Server、了解它有哪些工具、调用这些工具——不需要知道你底层是怎么实现的也不需要为每个模型单独适配。MCP Server 就像是 USB 设备插上去就能用。MCP Client工具的使用者MCP Client 是 AI 应用比如你写的 Agent 系统的一部分。它负责连接到 MCP Server发现可用的工具把工具提供给 LLM 使用。当 LLM 通过 Function Call 决定要调用某个工具时MCP Client 负责把调用请求发送到对应的 MCP Server把结果取回来交给 LLM。MCP Client 就像是电脑上的 USB 接口插什么都认。MCP Host整个系统的运行环境MCP Host 是指运行整个 Agent 系统的环境可以是一个 CLI 工具、一个桌面应用、或者后端服务。它负责启动 MCP Client、加载 MCP Server、管理它们的生命周期。一个 MCP Host 可以同时连接多个 MCP Server——就像你的电脑可以同时插着鼠标、键盘、U 盘一样。MCP 到底解决了什么问题说清楚了架构咱来看看 MCP 具体解决了哪些痛点。痛点一工具只写一次所有模型都能用没有 MCP 的时候你的工具是为某个特定模型、某个特定框架写的。换模型换框架工具代码基本得重写。有了 MCP 之后你把工具做成 MCP Server任何支持 MCP 的模型都可以直接调用。你在 GPT-4 上测试通过的工具切换到 Claude、切换到国产模型不需要改一行代码。这就好比你写了一个 RESTful API写一次Postman 能调curl 能调Python 能调Java 能调MCP 就是干这个事儿的。痛点二工具可以复用和共享没有 MCP 的时候你想用别人写好的工具等于是要从他的项目里把代码抠出来适配到自己的框架里累死累活还容易出 bug。有了 MCP 之后工具是独立部署的。一个团队开发了一个查询公司知识库的 MCP Server其他团队只要在本地的 MCP Host 里配置一下地址立刻就能用。整个公司不需要重复造轮子。MCP 的生态一旦成熟社区里会有大量的 MCP Server 可以直接拿来用——有人写了查股票价格的 MCP Server有人写了操作 GitHub的 MCP Server你只需要安装配置不需要从零开发。痛点三工具发现和连接变得标准化没有 MCP 的时候你的代码里写死了我要调用这个 URL 的 APIURL 变了、接口变了你得改代码。有了 MCP 之后工具的发现、连接、调用、返回都是标准化的。你的 Agent 系统只需要实现 MCP Client就天然能连接任何符合规范的 MCP Server。供应商换一个 MCP Server 的地址改个配置就行代码不用动。一个实际的使用场景说这么多抽象概念可能还是有点晕咱来一个具体的场景。假设你在一家电商公司做 Agent 开发。老板的需求是“让 AI 帮运营人员自动生成每日销售报告。”没有 MCP 的时候你需要做的事情从 ERP 系统里拉订单数据 → 写一个数据查询模块让 AI 分析数据、生成报告 → 配置 OpenAI API Function Call把报告发到钉钉 → 写一个钉钉通知模块三个模块独立开发代码分散。万一公司换成飞书钉钉模块全部重写。万一换成国产模型Function Call 全部重写。有了 MCP 之后ERP 数据查询 → 一个 MCP Server所有模型都能调用报告生成 → 配置模型不影响工具钉钉通知 → 一个 MCP Server换飞书换一个 Server 地址就行工具和模型彻底解耦了。你换模型、换 IM 工具、换数据源工具模块岿然不动只有配置变了代码不用改。这就是 MCP 的价值降低集成成本提升工程效率让 Agent 开发从泥腿子变成搭积木。MCP 的局限性夸了 MCP 这么多咱也得说点实在的——MCP 不是银弹它解决的是工具调用层的问题但 Agent 架构里还有别的挑战。第一个局限MCP 只解决工具怎么用的问题不解决工具怎么做的问题。MCP 告诉你怎么标准化地暴露一个工具但工具本身该怎么实现、怎么保证准确性、怎么处理异常还是得你自己写。MCP 是接口规范不是 AI 能力的来源。第二个局限MCP 不解决复杂技能的问题。有些能力不是调用一次 API 就能完成的而是需要一连串复杂的操作。比如帮我把这个月的销售数据整理成一份 PPT——这不只是一个工具调用而是一系列工具的编排、状态的维护、进度的跟踪。MCP 本身不提供这种工作流编排的能力。第三个局限MCP 不解决多 Agent 协作的问题。真实的业务场景里往往不是一个 Agent 在干活而是多个 Agent 分工协作。比如一个 Agent 负责查数据一个 Agent 负责分析数据一个 Agent 负责写报告——它们之间怎么通信、怎么交接任务、怎么保证数据一致性MCP 没有定义这部分。这三个 MCP 的局限恰恰就是下一章要讲的内容——Skills技能和 A2A 协议Agent to Agent。Skills 解决的是怎么让 Agent 学会复杂技能的问题不再是简单的一次性工具调用而是有状态、有步骤、有反馈的完整工作流程。A2A 解决的是多个 Agent 怎么一起干活的问题让 Agent 之间能够像人类员工一样分工协作、互相交接。MCP Skills A2A三者合起来才是一套完整的 Agent 基础设施。下一章咱们把最后这两块拼图补上。敬请期待三连催更咱们不见不散作者利威尔xu一个正在死磕 AI 应用落地、热爱分享的普通后端开发。如果这篇文章对你有帮助欢迎点赞、收藏、关注更多硬核内容持续更新中。