在大模型智能体（AI Agent）快速演进的今天，工具调用（Tool Use） 和 多智能体协作（Multi-Agent Collaboration） 已成为两大核心能力。然而，早期的实现方式高度碎片化——每个框架、每个平台、每个工具都采用私有接口，导致开发者重复造轮子、系统难以互操作、生态彼此割裂。
为解决这一问题，行业正在形成两大标准化协议：
MCP（Model Context Protocol） —— 让 Agent 与外部工具 的交互标准化
MCP 解决的问题可以概括成一句话：让“外部工具、资源、提示词模板”等能力，能够按统一协议被不同 AI 应用发现和使用。
A2A（Agent-to-Agent Protocol） —— 让 Agent 与 Agent 的协作标准化
这两大协议并非竞争关系，而是互补共生，共同构成未来 AI Agent 生态的“基础设施层”。本文将从起源、架构、工作原理、应用场景、对比分析等多个维度，对 MCP 与 A2A 进行全面、深入、系统的解析，助你把握 AI 智能体发展的技术脉络。
一、MCP（Model Context Protocol）：Agent 的“万能工具接口”
（一）什么是 MCP？
MCP（Model Context Protocol，模型上下文协议） 是由 Anthropic 于 2024 年提出的开放标准协议其目标是：为 AI 应用提供一种统一、安全、可扩展的方式，动态注入和管理外部工具、数据源与上下文信息。
✅ 简单理解：MCP 就像 USB-C 接口——任何工具只要实现 MCP Server，就能被任意支持 MCP 的 Agent 调用，无需定制适配。
（二）核心设计思想
MCP 的设计围绕三个关键原则
上下文结构化：将工具、数据、提示词等资源以标准化 JSON 格式描述。
职责分离：
Prompts：由用户控制（如系统提示词）
Resources：由应用控制（如知识库文件）
Tools：由模型控制（如 API 调用函数）
Agent Tool 与 MCP Tool 的关系
可以用一个简单的公式来理解：
Agent 的 Tool 模块 = MCP 的 Tools（作为主要实现方式）
Agent系统的Tool模块原则上可以使用MCP的Resources和Prompts，但在绝大部分工程实践中，Agent的Tool模块通常只消费Tools，而不直接消费Resources和Prompts。
具体来说，两者是这样的关系：
传输无关性：支持
stdio（本地进程通信）、HTTP/SSE（远程服务）等多种传输方式。
（三）架构组成
MCP 采用经典的 Client-Server 架构：
ServerVCP
MCP Server 是整个架构的核心，负责向大模型提供结构化上下文和可调用的操作能力。它定义了三大类基础能:
1)Resources:类似静态或动态的数据文档，比如 AP! 返回的 JSON、配置文件、项目结构，供模型查询参考
2)Tools:模型可调用的函数接口，比如发请求、创建文档、执行命令，执行前通常需要用户授权来保证安全
3)Prompts:预定义的提示模板，用来引导模型完成特定任务，比如代码审查、生成 commit message、总结会议内容，能提高交互效率。通过这三类能力，MCP Server 让模型不仅能"看懂"信息，还能"动手"完成任务社区维护的 MCP Servers
Repository 和 Awesome MCP Servers 里有大量开源的 MCP Server 实现。TypeScript 写的MCP Server 通常用 npx 命令运行，Python 写的用 uvx 命令启动，部署起来很方便。
MCP 协议层面大致怎么工作
MCP 不只是“发 HTTP 请求”这么简单，它在协议层有自己的一套约定。学习本章时，先理解下面这条主线即可：
Host / Client 发起连接
Client 和 Server 做初始化
双方声明各自支持的 capabilities
客户端发现服务器提供的 tools / resources / prompts
按需调用或读取
结果返回给 Host，再由模型 / UI 使用
MCP 的底层消息格式基于 JSON-RPC 2.0（请求 / 响应 / 通知）。这也是为什么你会在很多资料里看到：
request / response / notification
capabilities negotiation
initialize
MCP 更像是：**“AI 应用与外部能力之间的协议层 + 能力发现层 + 调用层”**而不只是某个单纯的 SDK。
3.2.1 用 5 个动作理解一次完整 MCP 调用
如果把 MCP 放回一轮真实问答里，可以把它拆成下面 5 个动作：
握手与能力发现（Handshake & Discovery）
Host 启动后，会根据配置连接 MCP Server，并完成初始化。此时客户端会知道：这台服务器提供了哪些 Tools、Resources、Prompts，以及它支持哪些 capabilities。用户提问与上下文注入（Context Injection）
用户提出问题后，Host 会把“用户问题 + 已发现的工具说明 / 资源信息 / 提示词信息”一并提供给模型或应用逻辑。模型或应用做决策（Reasoning / Decision）
模型决定是否需要调用某个 Tool，或者应用决定是否读取某个 Resource、选用某个 Prompt。路由与执行（Routing & Execution）
Host / Client 按协议把请求发给 MCP Server。Server 在自己的进程或远端服务中执行真正的逻辑，例如查天气、读文件、查数据库。结果回传与继续生成（Result Feedback）
Server 把结果返回给 Client，Client 再把结果交回 Host，由 Host 继续让模型生成最终回答，或者直接展示给用户。
可以把这个过程和Tool 调用对比着理解：
Tool 调用 更像“模型知道怎么调一个函数”
MCP 更像“这个函数来自哪里、怎么发现、怎么连接、怎么按协议调”
这也是为什么在 Agent 场景里，MCP 常常出现在 Tool 之前一层。
（四）通信方式
两种通信机制:这一节先把新旧叫法分清楚。
根据 MCP 官方传输规范（文档以 Transports 等页面为准，版本会迭代），当前主线标准传输是：
stdio
Streamable HTTP
官方还明确说明：
Streamable HTTP 取代了 2024-11-05 版本中的 HTTP+SSE transport
新的 HTTP 传输里，服务器仍然可以使用 SSE 作为流式返回机制
也就是说，今天更准确的理解应该是：
STDIO：本地子进程通信
Streamable HTTP：独立服务进程，通过 HTTP 通信，必要时可配合 SSE 流式返回
而你在很多旧资料、旧案例、适配器配置里看到的 sse，通常属于：
旧的 HTTP+SSE transport 叫法
或兼容写法
或具体库层面对历史接口的保留
结合仓库现有案例，可以这样看：
MCP 支持两种底层传输方式，适用场景完全不同:
Stdio 模式:基于标准输入输出流，Client 和 Server 跑在同一台机器上，通过进程间管道通信。启动快、延迟低、调试方便，本地开发首选。Claude Desktop 默认就用这种方式启动本地 Server。
SSE 模式:基于 HTTP 长连接，Server 可以部署在远端。Client 通过 HTTP POST发请求，Server 通过 Server-SentEvents 推送响应。适合分布式部署、跨网络调用的生产场景。
与传统 Function Calling 的区别
很多人会问:MCP 和 OpenAI 的 Function Calling 有什么区别?
核心差异在于标准化和解耦。
传统 Function Calling 是模型厂商各搞各的，OpenAI 有一套格式，Claude 有另一套，换个模型就得改代码。工具定义也是硬编码在应用里，每接一个新工具就得改应用代码重新部署。MCP 把这套流程标准化了:工具以 Server 的形式独立部署，Client 通过协议发现和调用工具。换模型不用改 Server，加工具不用改 Client。就像 USB 接口一样，只要符合协议，插上就能用。
（五）工作流程
MCP 的核心工作流程是一个客户端-服务器协作的闭环，整体分为7个阶段:
1)初始化连接:主机应用启动后，MCP Client 与 MCP Server 建立连接。一个主机可以同时连多个 Server，每个 Server负责不同的工具和资源。
2)获取工具列表:Client 从 Server 拉取可用的工具清单，包括每个工具的名称、参数、用途描述。这一步相当于"能力注册"，让模型知道手里有哪些牌可以打。
3)构造 Function Caling 请求:用户输入问题后，Client 把工具描述和用户问题一起打包发给 LLM。传输格式是结构化的Function Calling，告诉模型"你现在能调用这些函数"。
4)模型智能决策:LLM 根据上下文和工具信息，判断是否需要调用外部工具、调用哪个、传什么参数。比如用户问天气
模型就会选择 getWeather 工具并填入城市参数。
5)工具调用执行:如果模型决定调用工具，Client 把调用请求转发给 Server;Server 负责实际执行--跑脚本、查数据库、调 API，然后把结果返回。
6)结果整合:工具执行结果传回 LLM，模型把这个结果和原始问题、对话上下文糅在一起，生成最终的自然语言回答,
7)用户响应输出:Client 把模型生成的回答展示给用户，完成一次完整的人机协作。
（四）全流程示例图（续）
和Tool、RAG、Agent 有什么区别？
Tool 解决“能不能调用”
RAG 解决“能不能拿到知识”
MCP 解决“怎么统一接入”
Agent 解决“谁来决定何时调用”
（六）面试官追问
提问:MCP Client 和 Server 之间的连接断了怎么办?有没有重连机制?
回答:MCP 协议本身定义了连接生命周期管理。Stdio 模式下，Server 进程挂了 Client 会收到 EOF 信号，可以选择重启Server 进程。SSE 模式下，HTTP 长连接断开后 Client 可以重新发起连接。具体的重连策略、重试次数、退避算法这些是Client 实现层面的事，协议没有强制规定，得看各家 SDK 怎么实现。
提问:如果模型一次需要调用多个工具，MCP 怎么处理?
回答:MCP 支持串行和并行两种模式。串行就是一个工具执行完拿到结果，再决定下一步调哪个。并行就是模型一次返回多个工具调用请求，Client 同时发给 Server 执行。具体用哪种取决于模型的推理结果和工具之间的依赖关系。比如先查用户ID再查订单，这种有依赖的只能串行;查天气和查股票这种独立的就可以并行。
提问:MCP 和 LangChain 的 Agent 有什么关系?能一起用吗?
回答:两者解决的问题不在一个层面。LangChain Agent 是个编排框架，负责把多个步骤串起来、管理对话状态、处理工具调用结果。MCP 是个通信协议，定义 Client 和 Server 怎么交互。完全可以在 LangChain Agent 里接入 MCP Client，让Agent 通过 MCP 调用外部工具。LangChain 社区已经有 MCP 的集成方案了。
提问:MCP Client 和 MCP Server 之间是怎么通信的?用的什么协议?
回答:MCP 底层用的是 JSON-RPC 2.0 协议，传输层支持两种方式:一种是 stdio，适合本地进程间通信;另一种是 HTTF+SSE，适合远程服务调用。stdio 方式下 Client 直接 fork 一个 Server 进程，通过标准输入输出交换 JSON 消息，延迟低、实现简单。HTTP+SSE 方式下 Client 用 HTTP POST发请求，Server 用 Server-Sent Events 推送响应，适合跨网络场景。
提问:一个 MCP Client 能同时连多个 MCP Server 吗?这种多连接场景下怎么管理?
回答:可以，MCP 设计上就支持一个 Client 同时连多个 Server。每个 Server 提供不同能力，Client 会维护一个 Server 列表，每次请求前先聚合所有 Server 的工具列表给模型。模型选择调用哪个工具时，Cient 根据工具归属把请求路由到对应的Server。Cursor 里配置多个 MCP Server 就是这个原理。
提问:MCP Server 的 Tools 和 Resources 有什么本质区别?
回答:Resources 是只读的数据，模型拿来参考用，不会产生副作用;Tools 是可执行的动作，会真正改变外部状态。
提问链接：https://www.mianshiya.com/question/1914241826789912577
（七）典型应用场景
开发工具集成：Git、Docker、Playwright 等通过 MCP Server 暴露为 Agent 可调用工具
企业系统对接：将内部 CRM、ERP、数据库封装为 MCP 服务，供智能客服调用。
多模态能力扩展：图像生成（Stable Diffusion）、语音识别（Whisper）等作为 MCP 工具接入。
🌐 生态现状：截至 2025 年 12 月，MCP 市场 已收录超 2000 个社区贡献的 MCP Server，涵盖开发、设计、办公、云服务等领域
（八）如何用MCP
8.1直接使用现成的 MCP 服务
如果你的目标不是“学习怎么实现协议”，而是“先把能力接进来”，最直接的方式通常是：
找到现成的 MCP Server
在宿主应用里配置连接方式
让客户端自动发现其 Tools / Resources / Prompts
当前官方已经有 Registry 方向的能力和生态，公共 MCP 服务器的发现也越来越规范化。这意味着：
很多能力无需一开始就自己写服务端，先学会怎么接、怎么配、怎么调试也很有必要。
8.2 本地自建 MCP 服务端
如果你要接的是：本地文件系统、内部数据库、企业私有 API、自己的业务系统。
那通常就要自己写 MCP Server。这也是本章案例的重点：我们会通过本地天气服务、FastMCP 示例和 mcp.json 客户端配置，理解一个 MCP 服务是如何被暴露、被发现、再被 Agent 使用的。
8.2.1 什么是 FastMCP
这里很适合顺手把 FastMCP 这个词讲清楚，因为后面的案例文件名里会频繁出现它。
FastMCP 是 MCP 官方 Python 生态里用来快速编写 MCP Server 的高层封装。它帮你把很多底层样板工作收起来，让你可以更接近“写 Python 函数”的方式去暴露 MCP 能力。
先把它和 MCP 的关系看成下面这组对应：
MCP 是协议标准，解决“AI 应用怎么统一接入外部能力”
FastMCP 是 Python 里的服务端开发工具，解决“我怎么更方便地把能力按 MCP 标准暴露出去”
也就是说：MCP 是规则，FastMCP 是实现这些规则的一种工具。这就像：HTTP 是协议，FastAPI / Flask 是帮助你实现 HTTP 服务的框架。
放到这一章里也是一样：MCP 决定 Host、Client、Server 之间怎么协作，FastMCP 帮你更轻松地写出一个 MCP Server。
8.2.2 本章为什么讲 FastMCP
在真实项目里，如果你准备自己写一个 MCP 服务端，通常有两条常见路线：
自己直接按 SDK / 协议细节去实现
借助 FastMCP 这种更高层的封装来实现
第二条路线通常更友好，因为它能把注意力放回到“我要暴露什么能力”上，而不是一开始就陷进大量底层细节。
这也是为什么本章案例会分成两类：
McpServer.py
这是教学版极简实现，帮助你理解“服务端注册工具”这个最小概念。McpServerByFastMCP.py、McpServerWeatherByFastMCP.py
这是更贴近真实 Python MCP 开发体验的写法，帮助你理解 Tool / Resource / Prompt 怎么按官方 SDK 风格暴露出去。
因此这一章里，FastMCP 不是主角，MCP 协议本身才是主角；但 FastMCP 很适合作为 Python 侧的入门实现工具。
8.3 在 LangChain / Agent 里使用 MCP
这一点也和当前项目主线非常贴近。
LangChain 官方已经提供了对 MCP 的适配支持。常见路线是：
用
MultiServerMCPClient连接一台或多台 MCP 服务器通过
get_tools()取回 MCP 工具把这些工具交给
create_tool_calling_agent或create_agent让 Agent 在对话中实际调用它们（Agent 的创建与执行细节见 第 21 章 Agent 智能体）
思考：
MCP 解决的问题，和“写一个本地工具函数”有什么不同？
参考思路： 本地工具函数只服务当前代码；MCP 让工具、资源、提示词以统一协议暴露给不同 AI 应用复用。它的重点是标准化接入和跨应用复用，而不是多写一个函数。
Host、Client、Server 三个角色如果搞混，会造成什么理解偏差？
参考思路： 会分不清谁运行应用、谁负责协议通信、谁暴露能力。Host 是应用宿主，Client 负责连接 MCP Server，Server 提供 Tools / Resources / Prompts。角色清楚后，配置和排障才有方向。
Tool、Resource、Prompt 三类能力应该怎么划分？
参考思路： Tool 适合可执行动作，Resource 适合被读取的上下文资料，Prompt 适合可复用提示模板。不要把所有东西都做成 Tool，否则权限和语义都会变乱。
什么时候用 stdio，什么时候更关注 Streamable HTTP？
参考思路： 本地进程、桌面工具、开发调试常见 stdio；跨进程、服务化、远程访问更需要 HTTP 形态。传输方式服务于部署场景，不是单纯背协议名。
小结：
MCP 负责“标准化接入”
LangChain / Agent 负责“把接进来的能力真正用起来”
MCP 的本质：不是模型、不是工具本身，而是 AI 应用与外部能力之间的标准化连接协议。
MCP 的核心价值：统一发现、统一描述、统一接入，让工具、资源、提示词模板更容易跨应用复用。
和其他概念的区别：Tool 解决“调用能力”，RAG 解决“检索知识”，Agent 解决“规划和决策”，MCP 解决“标准化接入”。
当前规范重点：标准传输优先理解为
stdio与Streamable HTTP；仓库中的sse写法保留为案例兼容与教学理解用途。本章案例主线：从极简版教学服务端，到 FastMCP 服务端，再到
mcp.json+ LangChain Agent 的 MCP 客户端，已经构成了完整的入门路线。安全边界不能省略：MCP 让接入更统一，不代表接入就天然安全。真实项目里仍要考虑服务器来源可信、认证授权、最小权限、敏感能力隔离，以及不要把本不该暴露的内部资源直接开放给模型侧。
学完本章后，你至少应该能分清四件事：MCP 是协议层；Host / Client / Server 是通信角色；Tools / Resources / Prompts 是服务端暴露的能力；统一接入不等于自动解决安全问题。
二、A2A（Agent-to-Agent Protocol）：Agent 的“通用协作语言”
（一）什么是 A2A？
A2A（Agent-to-Agent Protocol，智能体到智能体协议） 是由 Google 于 2025 年 4 月联合 Linux 基金会推出的开放标准其目标是：实现不同厂商、不同框架、不同平台的 AI 智能体之间的安全、高效、互操作协作。
✅ 简单理解：A2A 就像 TCP/IP 协议——让来自 CrewAI、AutoGen、LangGraph 的 Agent 能像人类团队一样自然协作。
（二）核心设计哲学
A2A 基于四大原则
不透明性（Opacity）：Agent 无需暴露内部逻辑，仅通过接口交互，保护知识产权与隐私。
基于现有标准：构建于 HTTP、JSON-RPC 2.0、SSE（Server-Sent Events）之上，易于集成。
任务驱动：以“任务”（Task）为核心单元，支持长周期、多轮、异步协作。
默认安全：支持 OAuth 2.0、API Key、OpenID Connect 等企业级认证机制。
（三）核心组件
（四）工作流程（三阶段）
（五）高级特性
流式传输：通过 SSE 实时推送任务进度、中间结果（如代码生成过程）。
异步通知：对长时间任务（数小时/天），支持 Webhook 推送最终状态。
多模态支持：消息和工件可包含文本、图像、音频、结构化 JSON 等。
状态管理：任务状态持久化，支持断点续做。
（六）典型应用场景
跨企业协作：零售库存 Agent 检测缺货 → 通过 A2A 调用供应商订单 Agent。
专业分工：招聘经理 Agent → 委托简历筛选 Agent → 再委托背景调查 Agent。
复杂任务编排：旅行规划 Agent 协调航班、酒店、景点、支付等多个专业 Agent。
🌍 生态进展：Google Cloud、IBM、阿里云等已宣布支持 A2A；CrewAI、LangGraph 等框架正逐步集成 A2A 客户端
三、MCP 与 A2A 的关系：互补而非替代
协同工作示例：汽车维修店智能系统
客户通过 A2A 与“店长 Agent”沟通问题。
店长通过 A2A 委派任务给“机械师 Agent”。
机械师通过 MCP 调用诊断工具和维修手册。
若需零件，机械师通过 A2A 联系“供应商 Agent”。
供应商通过 MCP 查询自身库存数据库。
🔑 关键结论：MCP 负责“做事”，A2A 负责“找人”。两者结合，才能构建真正强大的多智能体系统。
四、如何选择？实践建议
五、未来展望
MCP + A2A + ANP：随着 ANP（Agent Network Protocol） 的发展，未来将形成“工具接入（MCP）→ 智能体协作（A2A）→ 网络发现（ANP）”的完整协议栈
标准化加速：Linux 基金会、W3C 等组织正推动 A2A 成为正式 Web 标准。
生态爆发：开发者可像开发 npm 包一样，发布 MCP 工具或 A2A 智能体，形成繁荣的“Agent App Store”。
结语
MCP 与 A2A 的出现，标志着 AI Agent 技术从“各自为战”走向“互联互通”的新时代。MCP 解决了“能力接入”的标准化问题，A2A 解决了“智能协作”的标准化问题。二者如同“USB 接口”与“互联网协议”，共同为下一代 AI 应用奠定基础设施。
对于开发者而言，拥抱 MCP 与 A2A，不仅是技术升级，更是参与构建开放、互操作、可持续的 AI 生态的关键一步。
📚 延伸阅读：
MCP 官方文档
《AI Agent 工程化实践指南》（2025）