企业官网建设流程全解析

简介：《A2A协议与MCP协议解析-蒋俊411.pptx》是一份面向AI技术团队的多Agent协作协议讲解PPT，适合开发者、架构师快速掌握智能体通信与模型外部能力接入的核心概念。内容从协议基础概述切入，对比A2A与MCP在技术架构、功能特性、安全验证、兼容性及传输效率上的差异，并结合招聘背调、工业物联网、医疗影像等案例说明应用场景，同时涉及性能优化与发展前景，帮助读者理清A2A负责Agent间协作、MCP负责连接外部工具和数据源的分工，为多Agent系统选型提供参考。资源包共1个PPT文件，大小2.42MB，按基础概述、技术架构对比、功能差异、场景分析、优化方向、前景展望六部分组织，结构清晰。其中对Agent卡、SSE通信、即插即用连接等关键概念的讲解，便于加深对协议实现机制的理解。已有332人学习，可用于团队技术分享或自学梳理协议要点。

1. 先搞懂这两份协议不是同一层的东西：A2A 管 Agent 之间，MCP 管 Agent 与工具

AI Agent 落地走到现在，绕不开两份协议：模型上下文协议（MCP）和代理间协议（A2A）。我第一次把两者放一起看时，误以为它们是要二选一的竞品，后来真正动手做多 Agent 编排，才明白根本不是同一层的技术。

MCP 解决的是 AI 应用里模型与外部工具之间的调用标准化问题；A2A 解决的是多个 Agent 服务之间互相发现、任务协商和结果交接的协作标准化问题。一个在工具层，一个在协作层，可以共存也可以单独用。下面把两份协议拆开，再放到同一个系统里说。适合正在做 Agent 编排选型的开发者，也适合已经写了一套自定义工具接口、想往标准协议上迁移的人。你先记住结论：只接工具用 MCP，要让 Agent 互相委托任务再上 A2A。

2. MCP 协议拆解：从 JSON-RPC 到本地工具调用的标准通道

MCP 的核心价值是“工具的标准化接入”。没有 MCP 之前，给模型接一个查库存的工具，要做一套私有接口；接一个算运费的，又要一套新接口。接入方每增加一个，模型框架就要多写一个适配器。MCP 出现后，工具被描述成标准 schema，客户端对照 schema 就能知道参数怎么传、结果怎么解析，适配器不用再为每个工具单独写。

协议本身基于 JSON-RPC 2.0，消息结构继承了 jsonrpc、id、method、params、result、error 这些字段。这套协议最大的好处是：所有 JSON-RPC 的调试经验和工具链可以复用；最大的坏处是：方法名一多，概念容易混淆。下面按角色拆开讲。

2.1 host / client / server 三角色，先把职责画清楚

MCP 把一条调用链路分成了三个角色，各管一段，不能混着用。

host 是宿主应用，通常是 IDE 插件、编辑器或者正在运行的 Agent 框架。host 决定什么时候调工具、把哪些上下文拼给模型，以及模型请求的工具调用命令要不要执行。host 不直接连接工具，它只和 client 打交道。

client 是 host 和 server 之间的连接器。一个 host 里可以维护多个 client，每个 client 对应一个 server。client 负责建立连接、维护会话状态、发送请求、接收响应，并把 server 的能力原语转发给 host。你可以把 client 理解为协议语法层面的翻译官。

server 是工具的真正宿主。它向 client 暴露三类能力：tools（工具调用）、resources（资源读取）、prompts（提示词模板）。tools 是多数项目的刚需，resources 和 prompts 在内容型应用里也越来越多。server 内部实现长什么样，对 host 完全透明，host 只看到 schema 和调用结果。

我自己的记忆方式是：host 是大脑，client 是神经，server 是手脚。如果项目里只有你一个人写三层，角色划分就更重要，否则 debug 时上下文很容易错乱，出错后都以为问题在别人那层。

2.2 40 行 Python 搭出可用的 MCP Server（stdio 模式）

先用最小代码把链路跑通。下面的代码用 FastMCP 库实现一个本地 MCP Server，暴露两个工具，一个做加法，一个读环境变量：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-server") @mcp.tool() def add(a: int, b: int) -> int: """两数相加""" return a + b @mcp.tool() def get_env_var(name: str) -> str: """读取环境变量，用于排查运行时配置""" import os return os.environ.get(name, "") if __name__ == "__main__": mcp.run(transport="stdio")

代码里 FastMCP 把三件事包掉了。第一件：函数签名自动转成工具 schema，包括参数名、类型、描述和 docstring。第二件：实现 initialize 和 tools/list 的报文字段。第三件：监听标准输入输出，按 JSON-RPC 2.0 解析并回包。add 和 get_env_var 就是两个工具，host 端拿到 tools/list 后能看到函数的描述与参数结构，不需要知道背后实现。

transport="stdio" 是本地模式，host 和 server 在同一个进程组里，协议消息走 stdin/stdout。选这个模式有一个硬性要求：日志和任何调试输出必须走 stderr 或独立文件，stdout 只要出现一行非协议内容，解析就会崩。这也是新手踩得最多的坑——print 一打，客户端直接报 protocol error。

参数方面，默认的 JSON 序列化已经够用，不需要自定义 encoder。函数返回值会自动转成 text 类型的 content part；返回 dict 时会转成 JSON 字符串放进 text。想返回结构化数据，自己打包成字符串，客户端再按约定解析。

2.3 transport 选型：stdio 适合本地，HTTP+SSE 适合远程

MCP 的 transport 常见两种：stdio 和 HTTP + SSE。选型唯一的标准是“server 跑在哪”。

stdio 模式优势是零网络配置，进程内通信延迟低，不暴露端口也不用做网络鉴权。劣势是 server 必须由 host 拉起，一个连接占一组 stdin/stdout 管道，做不到多客户端共用一套常驻进程，也没法做负载均衡。

HTTP + SSE 模式把 server 变成独立服务，host 通过网络访问。优势是统一鉴权、多客户端共享进程、可以上负载均衡和监控。代价是网络层的复杂度自己扛：请求超时、断线重连、SSE 心跳保活，一样不能少。特别是代理层配置，请求和 SSE 流是两条路径，两个路径都要放开。

我的习惯是：开发调试用 stdio，一个 server 一个进程，日志干净，问题定位快；部署到测试或生产环境，切成 HTTP + SSE，当普通 HTTP 服务去治理。代码层面，业务逻辑不要因为 transport 不同写两套，FastMCP 的抽象已经帮忙隔离，剩下的靠自己的目录结构守住。

2.4 一次 tools/call 请求的完整报文与参数说明

把一次真实调用拆开看。客户端发送：

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "add", "arguments": { "a": 3, "b": 5 } } }

服务端返回：

{ "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "8" } ], "isError": false } }

重点看几个字段。result.content 永远是数组，不是单个对象。多段 content 用来支持多模态返回，比如一段文本加一张图片路径，客户端要遍历数组逐个解析。isError 是业务错误标志：工具执行里抛异常时置 true，但这条 JSON-RPC 响应本身还是成功的，HTTP 状态码不会变。客户端判断逻辑要分开：先看 JSON-RPC 有没有 error 字段，再看 isError 是不是 true，不能把两个当成同一个东西。

id 必须和请求完全一致，JSON-RPC 靠它关联请求和响应。异步场景里连续发多个请求不等待，返回顺序不保证和请求顺序一样，只能靠 id 对应。

一个容易翻车的点：手拼 JSON。工具参数里带个换行符、反斜杠，手拼漏了转义，整个响应解析直接失败。这种问题客户端和服务端日志都看不出来，只会看到一堆 protocol error，排查半天才发现是自己拼包拼错了。所有 JSON 构造交给序列化库，不要自己拼字符串，这条规矩值得反复强调。

3. A2A 协议拆解：Agent 的“名片”与任务协作流程

A2A 全称是 Agent-to-Agent，解决的场景是 Agent 之间互相发现、下发任务、取回结果。它和 MCP 的差别本质上是场景差别。MCP 假定调用方是一个 AI 应用或 Agent，被调用方是工具；A2A 假定双方都是 Agent，都有决策能力，任务可能需要多轮交互、中间确认和分支处理。

理解 A2A 最直观的办法就两个词：名片和任务。每个 Agent 挂一张 AgentCard 名片，声明自己叫什么、能做什么、任务端点在哪；调用方根据名片决定要不要把任务交给对方。真正协作干活时，双方围绕一个 Task（任务）推进，任务有一组固定的生命周期状态，服务端负责推进状态，客户端负责观察状态变化，最终拿到产物。

3.1 AgentCard：一个 Agent 怎么让别人发现并知道它能干什么

AgentCard 是 A2A 发现机制的承载物，通常放在服务 HTTP 入口下的固定路径 /.well-known/agent-card.json。一个简化的例子：

{ "name": "report-bot", "description": "生成周报文档的 Agent，支持日志分析和表格摘要", "url": "http://127.0.0.1:8101/api", "capabilities": { "streaming": true, "pushNotifications": false }, "skills": [ { "id": "weekly-report", "name": "周报生成", "description": "根据日志目录生成 Markdown 周报", "inputModes": ["text"], "outputModes": ["text", "file"] } ] }

字段里最容易低估的是 description 和 skills 里的 description。A2A 的世界里，调用方通常是一个大模型驱动的 Agent，它在拿到一大堆 AgentCard 后，靠这些文本描述来判断把任务委派给谁。描述写得模糊，路由就会乱：把数据分析任务丢给一个只会写文档的 Agent，双方来回推诿，最后任务 failed。

capabilities 字段也很关键。streaming 声明服务端是否支持流式事件推送，pushNotifications 声明是否支持服务端主动推送。客户端根据 capabilities 决定用订阅还是轮询。声明和实现不一致，就是后面要讲的第五个坑。

3.2 任务生命周期：submitted 到 completed 的状态机

A2A 的核心抽象是任务 Task。客户端通过 task/send 提交任务，服务端创建任务实例并推进状态。状态流转如下：

input-required 是唯一一个“非终态”的暂停状态。它的价值在于多轮交互的标准通道：Agent 在执行过程中发现缺信息，比如删除操作要确认、参数二选一要拍板，就推进到 input-required，把问题通过消息推给调用方。调用方补充输入后，服务端把任务状态改回 working 继续跑。

我见过不少人把 input-required 当成 failed 来处理，客户端一看不是 completed 就报错退出。这是对状态机理解不到位。实现时，客户端要把 input-required 单独列一个分支，专门处理“需要人类或上层 Agent 确认”的场景。

3.3 用 curl 模拟 A2A 客户端：task/send 与结果轮询

不引入任何 SDK，先用 curl 把一次任务提交跑通。假设服务端地址 http://127.0.0.1:8234，任务分发端点 /api/task/send。

curl -s -X POST http://127.0.0.1:8234/api/task/send \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "task/send", "params": { "task": { "parts": [ { "type": "text", "text": "把当前目录下所有 .log 文件的大小统计出来" } ] } } }'

服务端返回一个 task 对象，带 task_id 和初始状态 submitted。注意，task/send 的响应本身不会带最终结果，只给句柄。接下来客户端要么轮询，要么订阅事件拿结果。轮询用 task/get：

curl -s -X POST http://127.0.0.1:8234/api/task/get \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 2, "method": "task/get", "params": { "task_id": "task-0001" } }'

task/get 返回的任务对象里，status 表示当前状态，artifacts 是执行完后的产物列表。状态不是 completed 时 artifacts 通常是空的，客户端要等待。

轮询间隔我一般从 1 秒开始，不低于 500 毫秒。服务端压力全在查询上时，日志里全是 task/get 请求，那是典型的“短轮询打爆服务”信号。调试时第一条铁律：task/send 响应里 task_id 不为空，所有后续逻辑都建立在 task_id 上。如果服务端直接把任务执行完了不给 task_id，这条路后面就走不通，趁早换实现。

3.4 Part 结构与流式更新：多模态内容的报文表达

A2A 的消息体里，内容用 parts 数组表达，每个 part 有一个 type 字段。常见三种：text 是普通文本；file 带 file_id、file_name、mime_type 等元数据；data 用于结构化数据，比如 JSON 片段。一次多模态结果可以包含多个 part，比如“一份图表图片 + 一段说明文字”，在协议里就是两个 part。

再看流式更新。客户端如果接受流式结果，会建立 SSE 连接订阅事件。服务端每次推送包含消息序号的增量数据：

{ "message_index": 1, "parts": [ { "type": "text", "text": "正在分析文件，进度 50%" } ] }

message_index 是消息序号，客户端按序号顺序拼接才能还原完整上下文。这里有个实现共识：流式更新里不要重复推送历史 parts，只推新增部分，靠 message_index 做对齐。服务端和客户端对消息序号的起始值要一致，如果一边从 0 开始，一边从 1 开始，拼接结果全是错位。

这个部分最容易出的问题：服务端把流式更新和最终 artifacts 做成两份独立数据，没有对齐 message_index，客户端解析顺序错乱或内容缺失。协议规定结构，但实现对索引的约定完全靠工程上守住。不需要复杂处理，服务端一个全局递增计数器保证单调递增就行。

4. 双协议协同：把 MCP 和能力服务藏在 A2A 后面的编排实践

前两章分别拆了两份协议，现在把它们放到同一个系统里说。常见做法是三层结构：最底层是各种 MCP Server，负责提供确定性工具，查库存、读文档、跑 SQL 都在这一层；中间层是业务 Agent，对上层暴露 A2A AgentCard 和任务端点；最上层是编排服务，只负责路由、鉴权、超时和重试。

上层的 Agent 要调工具时，自己充当 MCP client 去连对应的 MCP Server。Agent 之间的协作用 A2A，Agent 与工具之间的取数用 MCP，互不干扰。这个设计的核心收益在于：工具没有记忆，不需要知道业务上下文，被调用后返回结果就结束；Agent 有状态，能决策，可在 A2A 层协商和反悔。

4.1 边界划分：哪些能力该做成 MCP Server，哪些该暴露成 A2A Agent

判断一个能力放哪层，标准就一条：调用方需不需要多轮沟通。

不需要多轮、一次调用、结果确定，做成 MCP Server。查天气、算价格、读文件、查数据库全是这类。需要多轮、需要中间确认、结果不确定，做成 A2A Agent。订机票的客服 Agent 是典型：乘客想改时间、改仓位、加行李，一个来回根本谈不拢。这种场景做成 MCP 工具，状态管理全压在客户端，客户端既要维护会话又要衔接多轮参数，痛苦不堪。

按数据流关系，可以画一张表：

选型还有个很实用的经验法则：凡是你的客户端代码里要写循环轮询直到完成、并且循环里有分支判断要不要带参数重试的，这个能力大概率应该做成 A2A Agent，而不是 MCP Server。MCP 假设一次调用返回结果，A2A 假设过程是持续的。

4.2 本地多 Agent 拓扑：一个最小的双协议编排骨架

一个本地实验拓扑，四个进程就够了：

• 编排服务：监听 8000，对外接收 HTTP 请求，维护全局任务状态。
• Agent A：监听 8101，暴露 AgentCard 和任务端点，负责日志分析。
• Agent B：监听 8102，暴露 AgentCard 和任务端点，负责生成报告。
• MCP Server：监听 8201，承载文件读取、目录扫描、SQL 查询等基础工具。

编排服务接到请求后，先看任务描述，从 AgentCard 注册表里判断分给 A 还是 B，还是两个都要；Agent 在执行过程中，自己作为 MCP client 去连 8201 取数据。A2A 只管任务路由和状态，MCP 只管数据搬运，两层没有直接调用关系。

这个拓扑要特别注意 MCP Server 的端点规划。HTTP + SSE 模式通常需要两个端点：一个用于 SSE 事件流建立，一个用于客户端发消息。代理层配置时两个路径都要放开，只放一个会导致客户端卡在“正在建立连接”不动，看起来像网络问题，其实是路径没配全。我排查过三次这个问题，每次都是路径配置漏项。

4.3 伪代码级别的编排骨架：登录校验、超时、重试必须在这里做

编排层不是转发器，它是整个系统的唯一入口。登录校验、超时、重试逻辑必须放在这一层。

放在这里的原因有两点。第一，放进子 Agent 会导致每个成员 Agent 重复实现一套鉴权，权限相等的代码拷贝到四面八方，改一个要全局搜索替换；第二，超时和重试逻辑分散，全局依赖关系很难梳理。编排层是天然的集中点，做错了能兜底，做对了也方便观测。

骨架如下，伪代码级别，不是完整实现：

def orchestrate(request): if not verify_token(request.token): reject("unauthorized") return candidates = discover_agents(request.task_description) results = [] for agent in candidates: task_id = send_task(agent, create_task_payload(request)) result = poll_task(agent, task_id, timeout=120) if timeout: mark_agent_unhealthy(agent) fallback_to_other_agent(agent, candidates) results.append(result) return aggregate(results)

第一步鉴权失败直接拒绝，不进入任务分派。第二步 discover_agents 从注册表拉候选，这一步要看 AgentCard 里的 description 做语义匹配，匹配质量直接决定后面任务路由准确率。第三步循环里 poll_task 的 timeout 参数是最重要的单一配置项：内部工具场景设 30 秒，跨 Agent 协作设 120 秒，再长切异步通知而不是同步等待。

fallback_to_other_agent 是容易被忽略的一步。超时之后直接把任务标成失败，体验很差；有替代 Agent 时应尝试换路。但换路前要确认任务没有副作用，如果前一个 Agent 已经执行到一半，比如已经把数据写入文件，切到另一个继续写可能产生脏数据，这时候宁可失败也不要并发跑两个。

4.4 本地实验网络的三个参数习惯

本地跑双协议实验，几个参数习惯建议固定下来。

第一，所有服务绑定 127.0.0.1，不绑 0.0.0.0，避免局域网内其他机器直接访问开发环境。

第二，SSE 连接的代理空闲超时设置不低于 300 秒。长任务执行时间超过网关默认 60 秒空闲超时，连接会被静默掐断，表现就是任务还在 working，客户端已收不到事件。

第三，服务间地址统一用环境变量注入，不硬编码。四个服务一多，硬编码地址翻车概率直线上升。改一次端口要改五处，这种痛苦经历过一次就不会再犯。

协议本身不规定这些工程参数，但实验从“能跑”到“稳定跑”的区别就在这里。

5. 落地避坑指南：协议版本不一致、嵌套调用与权限冲突

双协议落地，坑集中在五个位置。每条按“现象 → 原因 → 解决”写，可以直接对照排查。

5.1 现象：MCP Server 能连上但 tools/list 为空

客户端已建立连接，initialize 也成功了，但 tools/list 返回空数组，host 看不到任何工具。两个常见原因：工具注册发生在连接建立之后，注册时查找上下文失败，异常被静默吞掉；或者工具由插件机制加载，插件初始化失败被上层吞掉，tools/list 自然为空。

解决：先看 server 进程日志里工具注册相关的 warning，确认所有工具模块是否加载成功。再把 tools/list 的响应结构化打到日志里，别只看最终结果。排查顺序永远是先 server 日志，再 client 日志，最后才看协议报文。反过来会浪费大量时间在猜疑链上。

提示：tools/list 为空时，不要怀疑是协议不兼容，先把服务端日志翻到底，多数是工具注册环节的异常被吞了。

5.2 现象：A2A 任务卡在 working 状态一直不结束

任务提交后一直是 working，不推进到 completed，也不回 input-required。最常见原因是事件推送通道坏了：服务端走 SSE 推送状态，客户端没正确建立监听；或监听建立后心跳超时被代理关闭。

解决：确认客户端是否把 SSE 的注释行心跳帧忽略了。SSE 服务端会定期发送以冒号开头的注释行维持连接，客户端不能把它当数据事件处理。另一个思路：查看服务端任务完成回调是否真的触发。有项目把任务完成回调放在异步分支里，回调抛异常被外层代码吞掉，状态永远停在 working。

提示：心跳帧间隔建议 15 秒，既能维持代理不超时，又不会因为过于频繁消耗资源。

5.3 现象：双协议混用时身份模型冲突

MCP Server 通常用 API Key 认身份，A2A Agent 通过 agent_id 或令牌认身份，两套体系在编排层对冲。常见翻车现场是：编排层校验了调用方 token 就往下透传，但子 Agent 不认识这个 token，到 MCP Server 那层又识别不了 agent_id。

解决：在编排层做身份翻译。先把调用方身份映射成内网统一服务身份，再按目标服务的鉴权方式分别生成请求头。不透明传递，不改各服务的鉴权实现，只在编排层适配。画一张身份传递表，列清楚 A2A 请求头带什么、MCP 请求头带什么、映射规则是什么。这张表比任何口头约定都管用。

5.4 现象：流式输出断流或心跳超时

SSE 连接开始几秒数据正常，随后静默断流，客户端收不到事件，进程没有报错。原因几乎都指向代理层空闲超时：有些反向代理默认 60 秒空闲断连，SSE 连接超过无数据时间就掐。

解决：服务端加心跳，建议 15 秒间隔；客户端做断线重连，重连后根据上次的 message_index 从断点续拉。心跳帧自身不带业务数据，只是保持连接活性。另一层保险是客户端订阅恢复接口，重连时先调一次任务状态同步，再做增量收流。

5.5 现象：capabilities 声明和实际实现不一致

AgentCard 里声明支持 streaming 和 pushNotifications，实际服务端只实现了轮询接口。客户端一看支持流式，选择 SSE 订阅，结果订阅接口 404，任务状态无从推送，只能退回到轮询。

解决：AgentCard 里的 capabilities 必须与真实实现严格对齐，先实现，后声明。服务端可加一个启动时检查，凡声明了但路由没实现的，启动阶段报警告日志。根治的办法是把 AgentCard 声明和实现的对齐写进发布前的检查清单，每次发版本逐项核一遍。这个坑不解决，会让调用方对整个服务失信，后面所有协商都开始怀疑你。

6. 生产化验证：接口级日志和压测，先于业务联调

协议类服务的验证，不能停留在“curl 通了”就完事。我见过的线上故障里，一大半是协议边界条件没测到：少一个字段、序列化出错、能力声明超前。要稳定，先把下面三件事做扎实。

6.1 三层日志：transport、协议、业务

我的日志习惯分三层。transport 层记录连接建立、断开、重连和心跳；协议层记录消息的 id、method、耗时和错误码；业务层记录参数、结果摘要和堆栈。三层打到不同 logger，级别分开。排查顺序固定：先 transport，再协议，最后业务。每条协议消息带 request_id，并与业务链路 trace_id 绑定，否则双协议协同很难看清 A2A 任务和 MCP 调用之间的因果。

6.2 入参压测与并发阈值

压测方案：并发 10、50、100 三档，各跑 60 秒，记录 P99 和错误率。P99 超过 2 秒或错误率超 1% 就是环境上限。并发上去后重点看 MCP Server 的资源消耗，stdio 模式一个连接一个进程，10 并发就是 10 组进程，压测结果像网络抖动其实是进程开销。切到 HTTP+SSE 后要给 SSE 连接数设置上限，防止断线重连打满池。

6.3 容器化部署的几条配置习惯

容器部署我固定这几条：健康检查用 HTTP GET，绝不用 SSE 路径；环境变量统一管地址和密钥；单容器单进程，stdout 交给日志采集，stderr 单独定错误流。MCP 的 stdio 在容器里有个大坑：日志写进 stdout 就污染协议数据流，第三方库的 print 调用都会让解析失败。日志强制定向 stderr，同时采集器 stdout/stderr 都要收。

我保留的习惯还有一个：新接一个 Agent 或工具服务，先 mock 掉对端，只验证协议报文规范，再接入真实服务。故障发生后能立刻区分是协议实现还是业务逻辑的问题。两层混在一起时，查报文像代码问题，查代码又像报文格式问题，也是踩过几次之后才定下来的规矩。希望帮到你。

本文还有配套的精品资源，点击获取