从 MCP 到 A2AAgent 项目里“通信协议”到底在解决什么问题最近学习 Agent 的时候我发现一个问题以前我以为 Agent 的重点就是大模型 Prompt Tool RAG。但继续往下看会发现真正做 Agent 项目时还有一个非常关键的问题Agent 到底怎么和外部世界通信比如Agent 怎么调用工具 Agent 怎么访问本地文件 Agent 怎么连接第三方 API Agent 和另一个 Agent 怎么协作 MCP、A2A、SSE、Streamable HTTP 又分别是什么 大模型网关在这里到底有没有必要这些问题看起来分散但其实都围绕一个核心Agent 不是一个孤立的大模型而是一个需要连接工具、系统、数据和其他 Agent 的执行体。所以今天这篇文章我想从通信协议的角度重新梳理一下 Agent 项目的底层逻辑。一、先说结论Agent 项目不只是“调大模型接口”很多刚开始学习 Agent 的同学容易把 Agent 理解成用户输入问题 ↓ 调用大模型 ↓ 大模型返回答案但这其实更像普通 ChatBot不是真正意义上的 Agent。Agent 更完整的流程应该是用户输入目标 ↓ Agent 理解任务 ↓ 判断是否需要工具 ↓ 调用外部工具 / API / 数据源 ↓ 根据工具结果继续推理 ↓ 必要时多轮调用工具 ↓ 最终给出答案或执行结果也就是说Agent 和普通 LLM 应用最大的区别在于普通 LLM 应用偏“问答”Agent 偏“理解目标 调用工具 执行任务”。这里就会出现一个很现实的问题工具怎么接进来工具调用怎么规范化不同 Agent 之间怎么协作这就是 MCP 和 A2A 这类协议出现的背景。二、Function Calling 解决的是“模型怎么表达我要调用工具”在说 MCP 之前先要理解 Function Calling。Function Calling 可以理解为大模型不只是返回自然语言还可以返回一个结构化的工具调用意图。比如用户问帮我查一下北京今天的天气。如果模型判断这个问题需要调用天气工具它可能不会直接回答而是返回类似这样的结构{ name: getWeather, arguments: { city: 北京 } }这表示模型想调用 getWeather 这个工具 并且参数是 city 北京。然后由框架来真正执行这个方法weatherTool.getWeather(北京);执行完之后再把工具返回结果交给大模型让它组织成自然语言回答。所以 Function Calling 解决的是大模型如何表达“我要调用哪个工具” 大模型如何生成工具调用参数 框架如何识别模型返回的 tool_call但是它没有完全解决另一个问题这些工具从哪里来不同工具怎么统一暴露本地工具、远程工具、第三方服务工具怎么标准化接入这就引出了 MCP。三、MCP 解决的是“Agent 怎么标准化连接工具和数据源”MCP全称是 Model Context Protocol。它可以理解为给大模型应用连接外部工具、数据源和上下文的一套标准协议。Anthropic 在介绍 MCP 时把它定义为一种开放标准用于在 AI 应用和数据源之间建立安全的双向连接开发者可以构建 MCP Server 暴露数据也可以构建 MCP Client 去连接这些 Server。如果用更项目化的话说MCP Client通常在 Agent 应用这一侧 MCP Server负责暴露工具、资源、数据源 Tool具体能被 Agent 调用的能力 Resource可读取的上下文资源 Prompt可复用的提示模板可以画成这样用户 ↓ Agent 应用 / MCP Client ↓ 连接 MCP Server ↓ 获取工具列表 / 资源列表 ↓ 大模型决定是否调用工具 ↓ MCP Server 执行工具 ↓ 返回结果给 Agent ↓ Agent 继续推理并回答所以 MCP 的意义不是“让大模型更聪明”而是让 Agent 更容易连接外部世界。四、MCP 和普通 API 调用有什么区别很多人会问MCP Server 最后不也是调用 API 吗那我直接在后端写 API 不就行了吗这个问题非常关键。答案是底层确实还是 API、数据库、文件系统、脚本、服务调用。但是 MCP 的价值在于它把这些能力统一包装成 Agent 可以理解和调用的工具。普通 API 更像这样后端开发者知道接口地址 后端开发者知道请求参数 后端开发者手动写调用逻辑MCP 更像这样MCP Server 暴露工具定义 Agent / MCP Client 获取工具描述 大模型根据工具描述判断是否调用 框架负责发起工具调用也就是说MCP 不是替代 API而是把 API 包装成 Agent 生态里的标准工具。举个例子。你原来有一个接口GET /api/order/{orderId}普通后端项目里需要你手写代码调用它。但是如果做成 MCP Tool它可能会变成工具名queryOrder 描述根据订单 ID 查询订单状态 参数orderId 返回订单详情这样大模型在看到工具描述后就有可能自己判断用户问的是订单状态需要调用 queryOrder 工具。这就是 MCP 和普通 API 的区别。五、MCP 的通信方式stdio、SSE 和 Streamable HTTP今天聊天里还提到了一个重点MCP 到底用什么通信方式根据 MCP 官方规范MCP 使用 JSON-RPC 编码消息并定义了标准传输机制其中包括 stdio 和 Streamable HTTP。可以简单理解为stdio适合本地进程通信 Streamable HTTP适合远程服务通信 SSE早期常见的流式传输方式现在更多作为历史方案或兼容方案理解1. stdio适合本地工具stdio 就是标准输入输出。比如 Claude Desktop 调用本地 MCP Server本质上可以启动一个本地进程然后通过标准输入输出传 JSON-RPC 消息。它适合本地文件工具 本地脚本工具 本地数据库工具 开发环境工具 IDE 辅助工具可以理解成Agent Client ↓ stdio 本地 MCP Server ↓ 本地文件 / 本地命令 / 本地工具优点是简单适合本地环境。缺点也明显不太适合大规模远程部署 权限管理和服务治理能力有限 不太适合企业级多用户场景2. SSE服务端向客户端持续推送SSE全称 Server-Sent Events。它是基于 HTTP 的一种单向流式推送方式。你平时看到大模型一个字一个字输出很大概率就是类似 SSE 的流式效果。它的特点是客户端发起请求 服务端持续返回数据流 适合大模型流式输出它不像 WebSocket 那样是全双工通信。WebSocket 更像客户端可以随时发 服务端也可以随时发 双方保持一条长连接SSE 更像客户端问一句 服务端沿着这条响应流持续输出所以你之前提出的疑问很有价值为什么大模型输出过程中我不能随时打断并改变它的回答这里不仅是协议问题还涉及产品设计、服务端中断机制、上下文管理和模型推理状态。WebSocket 确实更适合双向实时通信但 SSE 更简单更适合“服务端持续输出文本”的大模型问答场景。3. Streamable HTTPMCP 现在更重要的远程通信方式Streamable HTTP 可以理解为 MCP 更现代的 HTTP 传输方式。根据 MCP 官方文档Streamable HTTP 中服务端可以作为独立进程处理多个客户端连接并通过 HTTP POST 和 GET 请求通信服务端也可以选择使用 SSE 来流式发送多条消息。它比单纯 SSE 更适合 MCP 的原因在于可以更自然地支持远程 MCP Server 更适合企业级部署 更容易结合 HTTP 鉴权、网关、审计、负载均衡 可以支持流式能力所以可以这样理解早期理解 MCPstdio SSE 现在理解 MCPstdio Streamable HTTP如果是本地开发stdio 很方便。如果是企业级 Agent 平台远程 MCP Server、大模型网关、权限认证、日志审计都要考虑那么 Streamable HTTP 就更重要。六、那 A2A 又是什么MCP 主要解决的是Agent 怎么连接工具和数据源。而 A2A 解决的是另一个问题Agent 和 Agent 之间怎么通信、协作和互操作。A2A全称是 Agent2Agent Protocol。Google 在 2025 年发布 A2A 时将它定位为让 AI Agent 能够相互通信、安全交换信息并在不同企业平台或应用之上协调行动的协议。它的重点不是“工具调用”而是“Agent 协作”。例如一个采购 Agent 一个财务 Agent 一个审批 Agent 一个库存 Agent它们可能分别属于不同系统、不同团队、不同平台。如果没有统一协议就需要大量定制集成。A2A 想解决的问题就是不同框架开发的 Agent 怎么互相发现 不同平台上的 Agent 怎么交换任务 一个 Agent 怎么把任务委托给另一个 Agent Agent 之间怎么传递状态和结果A2A 官方 GitHub 介绍里也强调它面向的是让不同公司、不同框架、不同服务器上的生成式 AI Agent 能够有效通信和协作而不只是把对方当工具调用。七、MCP 和 A2A 的区别这两个很容易混。可以用一句话区分MCP 是 Agent 连接工具。A2A 是 Agent 连接 Agent。更具体一点对比项MCPA2A核心对象工具、资源、数据源另一个 Agent主要关系Agent → ToolAgent → Agent解决问题工具标准化接入Agent 互操作与协作常见场景查数据库、读文件、调 API、执行脚本多 Agent 协作、跨平台任务委托更像什么工具协议Agent 通信协议举个例子。如果你的 Agent 要查数据库Agent → MCP Server → 数据库这更适合 MCP。如果你的 Agent 要把任务交给另一个专门的 AgentPlanner Agent → Executor Agent或者客服 Agent → 订单 Agent → 售后 Agent这更接近 A2A 的场景。八、那多 Agent 项目里一定要用 A2A 吗不一定。如果你的多 Agent 是在同一个项目内部实现的比如使用 Spring AI Alibaba Graph、LangGraph、AutoGen 这类框架很多时候不需要上来就用 A2A。因为框架内部已经可以通过状态对象、节点编排、消息传递来完成协作。比如用户输入 ↓ Planner Agent 生成计划 ↓ Executor Agent 执行工具 ↓ Reviewer Agent 检查结果 ↓ Supervisor 判断是否结束在这种项目里Agent 之间的通信可能只是共享状态 State 消息列表 Messages 节点输出 outputKey 框架内部事件流这时候并不一定需要 A2A。A2A 更适合的是跨系统 Agent 协作 跨公司 Agent 协作 不同框架 Agent 协作 远程 Agent 服务互相调用 Agent 生态互操作所以不能简单理解成只要是多 Agent就必须用 A2A。更准确的理解是项目内部多 Agent 编排可以用框架自己的 State / Graph / Message 机制跨平台、跨系统、跨组织的 Agent 协作才更需要 A2A 这类协议。九、大模型网关在 Agent 项目里解决什么今天还聊到了“大模型网关”。这个概念可以类比后端里的 API 网关。普通后端网关解决的是统一入口 鉴权认证 限流 路由 日志 监控 熔断 灰度发布而大模型网关解决的是 LLM 调用层面的统一治理。比如统一接入 OpenAI、DeepSeek、通义千问、Claude 等模型 统一 API 格式 统一鉴权 统一限流 统一日志审计 统一费用统计 统一模型路由 统一降级策略 统一 Prompt 管理 统一内容安全过滤在 Agent 项目里大模型网关不是必须的但在企业级项目里很有价值。如果只是个人学习项目Spring AI → DeepSeek API这样就可以跑起来。但如果是企业级平台可能就变成Agent 应用 ↓ 大模型网关 ↓ 不同模型厂商这样做的好处是模型可以动态切换 调用成本可以统计 异常可以统一监控 不同业务可以配置不同模型 敏感内容可以统一过滤 Token 消耗可以统一管理所以大模型网关更像是 Agent 平台化之后的基础设施而不是每个小项目一开始就必须要做的东西。十、把这些概念放到一张图里可以这样理解整个 Agent 通信体系用户 ↓ Agent 应用 ↓ ┌──────────────────────────────┐ │ Agent 核心层 │ │ 任务理解 / 规划 / 记忆 / 工具决策 │ └──────────────────────────────┘ ↓ ↓ ↓ ↓ MCP Client A2A Client ↓ ↓ MCP Server 其他 Agent ↓ ↓ 工具 / API / DB 专业 Agent 服务 ↓ 外部系统如果再加上大模型网关Agent 应用 ↓ 大模型网关 ↓ LLM 服务商如果再加上 RAGAgent 应用 ↓ RAG 检索链路 ↓ 向量库 / ES / 知识库这里 RAG 只是 Agent 获取知识的一种方式。MCP 是 Agent 连接工具的方式。A2A 是 Agent 连接其他 Agent 的方式。大模型网关是 Agent 调用模型时的治理入口。十三、今天的总结今天这部分学习让我意识到Agent 的核心不只是“会不会调用大模型”而是它能不能连接外部世界。Function Calling 解决的是大模型如何表达工具调用意图MCP 解决的是Agent 如何标准化连接工具、资源和数据源A2A 解决的是Agent 如何和其他 Agent 通信协作Streamable HTTP 解决的是MCP 在远程服务场景下如何更好地传输消息SSE 解决的是服务端如何向客户端持续流式输出大模型网关解决的是企业级场景下模型调用如何统一治理RAG 在这里也很重要但它不是今天的主角。它更像是 Agent 的一种知识获取能力Agent 需要知识 → 调用 RAG 检索工具 → 获取上下文 → 再调用大模型生成答案而 MCP、A2A、Streamable HTTP、大模型网关这些内容则是在回答另一个更底层的问题当 Agent 不再只是聊天而是要执行任务、调用工具、连接系统、协作完成复杂目标时它们之间到底靠什么通信
从 MCP 到 A2A：Agent 项目里“通信协议”到底在解决什么问题？
发布时间：2026/5/28 22:32:20
从 MCP 到 A2AAgent 项目里“通信协议”到底在解决什么问题最近学习 Agent 的时候我发现一个问题以前我以为 Agent 的重点就是大模型 Prompt Tool RAG。但继续往下看会发现真正做 Agent 项目时还有一个非常关键的问题Agent 到底怎么和外部世界通信比如Agent 怎么调用工具 Agent 怎么访问本地文件 Agent 怎么连接第三方 API Agent 和另一个 Agent 怎么协作 MCP、A2A、SSE、Streamable HTTP 又分别是什么 大模型网关在这里到底有没有必要这些问题看起来分散但其实都围绕一个核心Agent 不是一个孤立的大模型而是一个需要连接工具、系统、数据和其他 Agent 的执行体。所以今天这篇文章我想从通信协议的角度重新梳理一下 Agent 项目的底层逻辑。一、先说结论Agent 项目不只是“调大模型接口”很多刚开始学习 Agent 的同学容易把 Agent 理解成用户输入问题 ↓ 调用大模型 ↓ 大模型返回答案但这其实更像普通 ChatBot不是真正意义上的 Agent。Agent 更完整的流程应该是用户输入目标 ↓ Agent 理解任务 ↓ 判断是否需要工具 ↓ 调用外部工具 / API / 数据源 ↓ 根据工具结果继续推理 ↓ 必要时多轮调用工具 ↓ 最终给出答案或执行结果也就是说Agent 和普通 LLM 应用最大的区别在于普通 LLM 应用偏“问答”Agent 偏“理解目标 调用工具 执行任务”。这里就会出现一个很现实的问题工具怎么接进来工具调用怎么规范化不同 Agent 之间怎么协作这就是 MCP 和 A2A 这类协议出现的背景。二、Function Calling 解决的是“模型怎么表达我要调用工具”在说 MCP 之前先要理解 Function Calling。Function Calling 可以理解为大模型不只是返回自然语言还可以返回一个结构化的工具调用意图。比如用户问帮我查一下北京今天的天气。如果模型判断这个问题需要调用天气工具它可能不会直接回答而是返回类似这样的结构{ name: getWeather, arguments: { city: 北京 } }这表示模型想调用 getWeather 这个工具 并且参数是 city 北京。然后由框架来真正执行这个方法weatherTool.getWeather(北京);执行完之后再把工具返回结果交给大模型让它组织成自然语言回答。所以 Function Calling 解决的是大模型如何表达“我要调用哪个工具” 大模型如何生成工具调用参数 框架如何识别模型返回的 tool_call但是它没有完全解决另一个问题这些工具从哪里来不同工具怎么统一暴露本地工具、远程工具、第三方服务工具怎么标准化接入这就引出了 MCP。三、MCP 解决的是“Agent 怎么标准化连接工具和数据源”MCP全称是 Model Context Protocol。它可以理解为给大模型应用连接外部工具、数据源和上下文的一套标准协议。Anthropic 在介绍 MCP 时把它定义为一种开放标准用于在 AI 应用和数据源之间建立安全的双向连接开发者可以构建 MCP Server 暴露数据也可以构建 MCP Client 去连接这些 Server。如果用更项目化的话说MCP Client通常在 Agent 应用这一侧 MCP Server负责暴露工具、资源、数据源 Tool具体能被 Agent 调用的能力 Resource可读取的上下文资源 Prompt可复用的提示模板可以画成这样用户 ↓ Agent 应用 / MCP Client ↓ 连接 MCP Server ↓ 获取工具列表 / 资源列表 ↓ 大模型决定是否调用工具 ↓ MCP Server 执行工具 ↓ 返回结果给 Agent ↓ Agent 继续推理并回答所以 MCP 的意义不是“让大模型更聪明”而是让 Agent 更容易连接外部世界。四、MCP 和普通 API 调用有什么区别很多人会问MCP Server 最后不也是调用 API 吗那我直接在后端写 API 不就行了吗这个问题非常关键。答案是底层确实还是 API、数据库、文件系统、脚本、服务调用。但是 MCP 的价值在于它把这些能力统一包装成 Agent 可以理解和调用的工具。普通 API 更像这样后端开发者知道接口地址 后端开发者知道请求参数 后端开发者手动写调用逻辑MCP 更像这样MCP Server 暴露工具定义 Agent / MCP Client 获取工具描述 大模型根据工具描述判断是否调用 框架负责发起工具调用也就是说MCP 不是替代 API而是把 API 包装成 Agent 生态里的标准工具。举个例子。你原来有一个接口GET /api/order/{orderId}普通后端项目里需要你手写代码调用它。但是如果做成 MCP Tool它可能会变成工具名queryOrder 描述根据订单 ID 查询订单状态 参数orderId 返回订单详情这样大模型在看到工具描述后就有可能自己判断用户问的是订单状态需要调用 queryOrder 工具。这就是 MCP 和普通 API 的区别。五、MCP 的通信方式stdio、SSE 和 Streamable HTTP今天聊天里还提到了一个重点MCP 到底用什么通信方式根据 MCP 官方规范MCP 使用 JSON-RPC 编码消息并定义了标准传输机制其中包括 stdio 和 Streamable HTTP。可以简单理解为stdio适合本地进程通信 Streamable HTTP适合远程服务通信 SSE早期常见的流式传输方式现在更多作为历史方案或兼容方案理解1. stdio适合本地工具stdio 就是标准输入输出。比如 Claude Desktop 调用本地 MCP Server本质上可以启动一个本地进程然后通过标准输入输出传 JSON-RPC 消息。它适合本地文件工具 本地脚本工具 本地数据库工具 开发环境工具 IDE 辅助工具可以理解成Agent Client ↓ stdio 本地 MCP Server ↓ 本地文件 / 本地命令 / 本地工具优点是简单适合本地环境。缺点也明显不太适合大规模远程部署 权限管理和服务治理能力有限 不太适合企业级多用户场景2. SSE服务端向客户端持续推送SSE全称 Server-Sent Events。它是基于 HTTP 的一种单向流式推送方式。你平时看到大模型一个字一个字输出很大概率就是类似 SSE 的流式效果。它的特点是客户端发起请求 服务端持续返回数据流 适合大模型流式输出它不像 WebSocket 那样是全双工通信。WebSocket 更像客户端可以随时发 服务端也可以随时发 双方保持一条长连接SSE 更像客户端问一句 服务端沿着这条响应流持续输出所以你之前提出的疑问很有价值为什么大模型输出过程中我不能随时打断并改变它的回答这里不仅是协议问题还涉及产品设计、服务端中断机制、上下文管理和模型推理状态。WebSocket 确实更适合双向实时通信但 SSE 更简单更适合“服务端持续输出文本”的大模型问答场景。3. Streamable HTTPMCP 现在更重要的远程通信方式Streamable HTTP 可以理解为 MCP 更现代的 HTTP 传输方式。根据 MCP 官方文档Streamable HTTP 中服务端可以作为独立进程处理多个客户端连接并通过 HTTP POST 和 GET 请求通信服务端也可以选择使用 SSE 来流式发送多条消息。它比单纯 SSE 更适合 MCP 的原因在于可以更自然地支持远程 MCP Server 更适合企业级部署 更容易结合 HTTP 鉴权、网关、审计、负载均衡 可以支持流式能力所以可以这样理解早期理解 MCPstdio SSE 现在理解 MCPstdio Streamable HTTP如果是本地开发stdio 很方便。如果是企业级 Agent 平台远程 MCP Server、大模型网关、权限认证、日志审计都要考虑那么 Streamable HTTP 就更重要。六、那 A2A 又是什么MCP 主要解决的是Agent 怎么连接工具和数据源。而 A2A 解决的是另一个问题Agent 和 Agent 之间怎么通信、协作和互操作。A2A全称是 Agent2Agent Protocol。Google 在 2025 年发布 A2A 时将它定位为让 AI Agent 能够相互通信、安全交换信息并在不同企业平台或应用之上协调行动的协议。它的重点不是“工具调用”而是“Agent 协作”。例如一个采购 Agent 一个财务 Agent 一个审批 Agent 一个库存 Agent它们可能分别属于不同系统、不同团队、不同平台。如果没有统一协议就需要大量定制集成。A2A 想解决的问题就是不同框架开发的 Agent 怎么互相发现 不同平台上的 Agent 怎么交换任务 一个 Agent 怎么把任务委托给另一个 Agent Agent 之间怎么传递状态和结果A2A 官方 GitHub 介绍里也强调它面向的是让不同公司、不同框架、不同服务器上的生成式 AI Agent 能够有效通信和协作而不只是把对方当工具调用。七、MCP 和 A2A 的区别这两个很容易混。可以用一句话区分MCP 是 Agent 连接工具。A2A 是 Agent 连接 Agent。更具体一点对比项MCPA2A核心对象工具、资源、数据源另一个 Agent主要关系Agent → ToolAgent → Agent解决问题工具标准化接入Agent 互操作与协作常见场景查数据库、读文件、调 API、执行脚本多 Agent 协作、跨平台任务委托更像什么工具协议Agent 通信协议举个例子。如果你的 Agent 要查数据库Agent → MCP Server → 数据库这更适合 MCP。如果你的 Agent 要把任务交给另一个专门的 AgentPlanner Agent → Executor Agent或者客服 Agent → 订单 Agent → 售后 Agent这更接近 A2A 的场景。八、那多 Agent 项目里一定要用 A2A 吗不一定。如果你的多 Agent 是在同一个项目内部实现的比如使用 Spring AI Alibaba Graph、LangGraph、AutoGen 这类框架很多时候不需要上来就用 A2A。因为框架内部已经可以通过状态对象、节点编排、消息传递来完成协作。比如用户输入 ↓ Planner Agent 生成计划 ↓ Executor Agent 执行工具 ↓ Reviewer Agent 检查结果 ↓ Supervisor 判断是否结束在这种项目里Agent 之间的通信可能只是共享状态 State 消息列表 Messages 节点输出 outputKey 框架内部事件流这时候并不一定需要 A2A。A2A 更适合的是跨系统 Agent 协作 跨公司 Agent 协作 不同框架 Agent 协作 远程 Agent 服务互相调用 Agent 生态互操作所以不能简单理解成只要是多 Agent就必须用 A2A。更准确的理解是项目内部多 Agent 编排可以用框架自己的 State / Graph / Message 机制跨平台、跨系统、跨组织的 Agent 协作才更需要 A2A 这类协议。九、大模型网关在 Agent 项目里解决什么今天还聊到了“大模型网关”。这个概念可以类比后端里的 API 网关。普通后端网关解决的是统一入口 鉴权认证 限流 路由 日志 监控 熔断 灰度发布而大模型网关解决的是 LLM 调用层面的统一治理。比如统一接入 OpenAI、DeepSeek、通义千问、Claude 等模型 统一 API 格式 统一鉴权 统一限流 统一日志审计 统一费用统计 统一模型路由 统一降级策略 统一 Prompt 管理 统一内容安全过滤在 Agent 项目里大模型网关不是必须的但在企业级项目里很有价值。如果只是个人学习项目Spring AI → DeepSeek API这样就可以跑起来。但如果是企业级平台可能就变成Agent 应用 ↓ 大模型网关 ↓ 不同模型厂商这样做的好处是模型可以动态切换 调用成本可以统计 异常可以统一监控 不同业务可以配置不同模型 敏感内容可以统一过滤 Token 消耗可以统一管理所以大模型网关更像是 Agent 平台化之后的基础设施而不是每个小项目一开始就必须要做的东西。十、把这些概念放到一张图里可以这样理解整个 Agent 通信体系用户 ↓ Agent 应用 ↓ ┌──────────────────────────────┐ │ Agent 核心层 │ │ 任务理解 / 规划 / 记忆 / 工具决策 │ └──────────────────────────────┘ ↓ ↓ ↓ ↓ MCP Client A2A Client ↓ ↓ MCP Server 其他 Agent ↓ ↓ 工具 / API / DB 专业 Agent 服务 ↓ 外部系统如果再加上大模型网关Agent 应用 ↓ 大模型网关 ↓ LLM 服务商如果再加上 RAGAgent 应用 ↓ RAG 检索链路 ↓ 向量库 / ES / 知识库这里 RAG 只是 Agent 获取知识的一种方式。MCP 是 Agent 连接工具的方式。A2A 是 Agent 连接其他 Agent 的方式。大模型网关是 Agent 调用模型时的治理入口。十三、今天的总结今天这部分学习让我意识到Agent 的核心不只是“会不会调用大模型”而是它能不能连接外部世界。Function Calling 解决的是大模型如何表达工具调用意图MCP 解决的是Agent 如何标准化连接工具、资源和数据源A2A 解决的是Agent 如何和其他 Agent 通信协作Streamable HTTP 解决的是MCP 在远程服务场景下如何更好地传输消息SSE 解决的是服务端如何向客户端持续流式输出大模型网关解决的是企业级场景下模型调用如何统一治理RAG 在这里也很重要但它不是今天的主角。它更像是 Agent 的一种知识获取能力Agent 需要知识 → 调用 RAG 检索工具 → 获取上下文 → 再调用大模型生成答案而 MCP、A2A、Streamable HTTP、大模型网关这些内容则是在回答另一个更底层的问题当 Agent 不再只是聊天而是要执行任务、调用工具、连接系统、协作完成复杂目标时它们之间到底靠什么通信
