尧图网页设计 
A2A 协议面向异构智能体的互操作标准与工程实践说明本文从一个常见的问题出发——“A2A 协议是什么”——但目标不止于给出一个能应付面试的定义。我们将按照定位 → 数据模型 → 交互流程 → 传输绑定 → 与 MCP 的关系 → 工程权衡的顺序把 A2AAgent2Agent Protocol当作一个普通的分布式系统协议来分析它解决了什么问题、抽象边界在哪里、落地时要注意什么以及它不是什么。一、背景智能体协作的孤岛问题过去两年围绕单个 Agent 的构建已经形成了相对成熟的工具链LLM Prompt Memory Tool UseFunction Calling。但当我们把视野从单个 Agent拉到多个 Agent 协同完成一个复杂目标时会立刻撞上一堵墙——异构孤岛。现实中的 Agent 可能由不同团队、不同框架LangGraph、CrewAI、AutoGen、Google ADK、Semantic Kernel……、不同大模型构建部署在不同的域名与网络环境里。此时让它们协作常见的临时方案是把对方的 Agent “包成一个 Tool”用私有 HTTP 接口 自定义 JSON 去对接。这种方式在规模上来后会迅速恶化发现难没有统一的能力描述格式调用方只能靠文档或口头约定。协作语义弱普通 HTTP 请求-响应无法原生表达长时任务、状态流转、多轮澄清、主动回调。重复造轮子每个集成对都要重新约定鉴权、错误码、进度推送、取消机制。A2A 的出现本质上是要把这套智能体间通信从私有的点对点集成提升为标准化的互操作层。它把智能体视为对等的、不透明的协作者而非被调用的工具通过一套自描述的能力声明 有状态的任务模型 可复用的传输绑定让不同阵营的 Agent 能够互相发现、委派任务、同步状态、交付结果。一句话定位A2A 是 Agent 世界的外交协议——它不关心对方内部用什么模型、什么框架只规定你如何描述自己、如何接活、如何回报。二、A2A 是什么官方定位与演进A2A 全称Agent2Agent Protocol是由 Google 于 2025 年 4 月首次发布、后捐赠给Linux FoundationAgentic AI Foundation治理的开放标准协议[citation:1]。截至 v1.0.02026 年 3 月 GA规范已经进入稳定维护期拥有多家云厂商与开源框架的支持[citation:2]。理解 A2A 最重要的一件事是认清它的设计哲学——“Agents Are Not Tools”维度A2A 的立场对端身份远程 Agent 是独立、有推理能力的对等实体抽象边界不定义 Agent 内部实现prompt / memory / tools协议范围不做编排框架、不与 MCP 竞争标准化方式Proto-Firstproto 文件为唯一规范性定义这一点决定了 A2A 的克制它只规范 Agent 之间的契约面而把Agent 内部怎么想完全留给实现方。正是这种克制才让跨厂商互操作成为可能。三、核心数据模型五个关键概念A2A 的数据模型可以概括为五个名词用一个口诀记忆非常有效Agent Card 是简历Task 是派单Message 是聊天记录Artifact 是交付物。下面逐一落到工程细节。3.1 Agent Card智能体的自描述名片AgentCard是一份机器可读的 JSON 元数据文档通常发布在符合RFC 8615的 Well-Known URI 路径下GET https://{domain}/.well-known/agent-card.json客户端另一个 Agent 或用户应用通过解析这张卡片判断该不该找它干活、怎么跟它通信、需要什么凭据。一份较完整的 Agent Card 包含以下模块[citation:16][citation:17]{name:Travel Booking Agent,description:搜索并预订机票、酒店,version:1.0.0,provider:{organization:TravelCorp,url:https://travelcorp.com},supportedInterfaces:[{url:https://api.travelcorp.com/a2a,protocolBinding:JSONRPC,protocolVersion:1.0}],capabilities:{streaming:true,pushNotifications:true},defaultInputModes:[text/plain,application/json],defaultOutputModes:[text/plain,application/json],skills:[{id:flight-search,name:机票搜索,description:按出发地、目的地、日期搜索可用航班,tags:[travel,flight],examples:[搜索明天北京到上海的航班]}],securitySchemes:{oauth2:{type:oauth2,flows:{clientCredentials:{tokenUrl:https://auth.travelcorp.com/token,scopes:{search:搜索航班和酒店,book:完成预订}}}}},security:[{oauth2:[search,book]}]}关键字段解读supportedInterfaces显式声明协议绑定、版本与端点支持多绑定并存与版本协商客户端选择兼容版本[citation:2]。skills这是能力发现的核心——把能做什么结构化、可检索。相比 Tool 清单它更偏向意图与能力而非具体函数签名。securitySchemes/security把鉴权要求前置到发现阶段避免先调再用、报错才知道要 token。签名signaturesJWS企业场景下可验证卡片来源与完整性防止中间人篡改[citation:16]。Extended Agent Card认证后可获取更丰富的扩展信息GetExtendedAgentCard实现分层信息披露——对外只暴露摘要认证后才给细节[citation:2]。工程提示发现机制不止 Well-Known URI 一种还包括策展注册中心中心化目录按 skill/tag 查询与静态配置已知关系直接硬编码[citation:17]。协议没有规定中心化注册表生产环境通常需要自己加一层发现/治理层[citation:5]。3.2 Task有状态的核心工作单元如果说 Agent Card 解决找到谁Task解决的就是怎么把活交出去并盯住它。Task 是 A2A 中唯一同时具备身份、生命周期、状态和产出物的概念其数据结构大致为{id:task-123,contextId:ctx-001,status:{state:working,message:{text:正在搜索航班...}},artifacts:[],history:[...]}id任务全局唯一标识支持跨 Agent 追踪。contextId所属上下文会话/流程用于把多个 Task 归入同一业务流程。status当前状态含state与可选的描述消息。artifacts最终交付物集合。history交互历史。Task 状态机是 A2A 区别于普通 API 调用最关键的部分[citation:1][citation:10]┌─────────────┐ │ SUBMITTED │ 已提交尚未开始处理 └──────┬──────┘ ▼ ┌─────────────┐ │ WORKING │ 正在处理可能持续推送进度 └──┬───┬───┬──┘ ┌───────────┘ │ └───────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────────┐ ┌───────────┐ │COMPLETED │ │ INPUT_REQUIRED│ │AUTH_REQUIRED│ │ (终态) │ │ (暂停等输入)│ │ (暂停等认证)│ └──────────┘ └──────┬───────┘ └──────┬────┘ │ │ ▼ │ 回到 WORKING ◄────────────┘ │ ┌────────┬───────┴───────┬─────────┐ ▼ ▼ ▼ ▼ FAILED CANCELED REJECTED (unknown) (终态) (终态) (终态)需要特别注意的几点终态不可重启一旦进入COMPLETED/FAILED/CANCELED/REJECTED该 Task 就不能再次启动后续操作必须在同一contextId下创建新 Task[citation:7]。这是一个重要的工程权衡——简化了实现与追踪但意味着重试需要由上层业务自己建模。INPUT_REQUIRED与AUTH_REQUIRED是暂停态而非终态前者支持人机协作 / 多轮澄清后者把鉴权异常显式建模进状态机而不是靠错误码偷偷传递。REJECTED≠FAILEDREJECTED表示拒绝执行如权限不足、无法理解意图FAILED表示尝试了但出错了——语义不同调用方应区别处理。unknown任务状态无法确定ID 无效、未知、已过期[citation:10]。长时任务是 Task 状态机的第一性驱动力。一个供应链优化任务可能跑几小时甚至几天单纯请求-响应会让连接和资源管理陷入困境——这正是 A2A 引入状态机、轮询、流式、推送多种同步机制的动因。3.3 Message 与 Part通信内容的最小单元Message表示一次通信轮次包含roleuser 客户端发送 /agent 服务端发送和一个或多个Part{role:user,parts:[{type:text,text:帮我订明天北京到上海的机票},{type:data,data:{preferred:经济舱}}]}Part是内容与多模态的最小载体支持text文本、file文件含 MIME、data结构化 JSON[citation:1]。这让 A2A 天然支持多模态文本、图片、音频、视频、结构化数据、文件都能在消息/交付物中流转。Message与Artifact的分工Message通信过程中的非交付内容——指令、上下文、思考过程、状态更新。Artifact任务完成后正式的、不可变的交付物可包含多个 Part[citation:12]。一句话Message 是过程Artifact 是结果。把两者分开才能让中间讨论和最终成果不混在一起也便于做产物管理与审计。四、交互流程一次完整委派长什么样把上面四个概念串起来一个典型的 A2A 交互时序如下Client Agent Remote Agent │ │ │── GET /.well-known/agent-card.json ──▶│ ① 发现 │◀── AgentCard (能力/接口/安全) ────────│ │ │ │── SendMessage (Task, Message) ───────▶│ ② 委派 │◀── Task(id, statusSUBMITTED) ───────│ │ │ │◀── SSE: statusWORKING ──────────────│ ③ 进度 │◀── SSE: artifact delta ──────────────│ │ │ │── GetTask (轮询/兜底) ──────────────▶│ ④ 查询 │◀── Task(status, artifacts) ──────────│ │ │ │◀── Task(statusCOMPLETED, artifacts) │ ⑤ 交付对应到**抽象操作Abstract Operations**层主要方法为[citation:9][citation:12]操作作用SendMessage发送消息创建或继续一个 TaskSendStreamingMessage发送消息并通过流接收更新SSEGetTask查询 Task 当前状态与结果ListTasks按条件列出任务CancelTask请求取消任务SubscribeToTask订阅已有 Task 的流式更新Create/Get/List/DeleteTaskPushNotificationConfig配置异步 Webhook 推送GetExtendedAgentCard认证后获取扩展 Agent Card长时任务的三套同步机制A2A 对任务进度如何同步到调用方给出了三种等价机制开发者按场景选择[citation:2]轮询PollingSendMessage后周期性GetTask——实现简单适合秒级延迟可接受的场景。流式SSEServer-Sent EventsSendStreamingMessage服务端持续推送TaskStatusUpdateEvent/TaskArtifactUpdateEvent——适合需要实时进度、但调用方需维持长连接的场景。推送通知Push Notification预先配置 Webhook任务状态变化时由服务端主动回调——最适合小时级/天级的超长任务调用方无需维持连接。这三套机制共用同一套StreamResponse数据模型是 A2A 设计中多种传输、统一语义的典型体现。五、传输绑定分层架构的工程价值A2A 规范按Data Model → Abstract Operations → Protocol Bindings三层组织[citation:9]。第三层协议绑定允许同一套语义映射到多种传输且规范保证它们之间语义等价[citation:2]绑定传输方式流式支持典型场景JSON-RPC 2.0HTTP POSTapplication/jsonSSEtext/event-stream最简单、生态最广gRPCHTTP/2 ProtobufServer Streaming RPC高性能、强类型HTTPJSON / REST标准 RESTful 端点SSE对接既有 REST 基础设施示例一个发送消息操作在不同绑定下的映射[citation:9]// JSON-RPC 2.0 请求{jsonrpc:2.0,id:1,method:SendMessage,params:{message:{role:user,parts:[{type:text,text:我要一杯拿铁}]},taskId:null}}# REST 等价端点 POST /message:send Content-Type: application/json { message: {...} }// gRPC 等价服务 service AgentService { rpc SendMessage(MessageRequest) returns (Task); rpc SendStreamingMessage(MessageRequest) returns (stream StreamResponse); }HTTP 层的约定也不容忽视规范额外定义了A2A-Version头如1.0、A2A-Extensions头逗号分隔的扩展 URI以及自定义 media typeapplication/a2ajson生产环境必须使用 HTTPS推荐 TLS 1.3[citation:17]。为什么这种分层 多绑定设计值得学习它把业务语义和传输细节解耦让不同技术栈都能接入同时通过 proto 作为唯一规范性来源消除规范漂移specification drift。这是协议设计的通用最佳实践即便你不用 A2A这套思路也可借鉴。六、A2A 与 MCP精确辨析而非口号A2A 管同事、MCP 管工具是很好记的口诀但要写出客观的技术分析需要把边界讲到更细。6.1 分工一横一纵维度A2AMCP提出方 / 治理Google 发起LF 治理Anthropic 提出通信对象Agent ↔ AgentAgent ↔ Tool / 资源对端智能性两端都有推理能力仅 Agent 端智能Tool 端是确定性服务核心概念Agent Card、Task、Message、ArtifactTool、Resource、Prompt状态性有状态Task 完整生命周期通常无状态Tool 调用交互模式多轮对话、委派、协商结构化函数调用、读写资源发现机制Agent Card能力声明Tool 清单典型延迟秒到分钟级长时任务毫秒级认证双向认证OAuth 2.0 / OIDC服务端控制为主抽象层次高级意图与能力低级具体功能/接口[citation:4][citation:8]6.2 何时用哪个判断依据很朴素——对端是确定性函数还是需要推理的实体[citation:4]用 MCP远程端是一个确定性函数——数据库查询、API 调用、代码执行沙箱、读文件。Agent 完全掌控交互过程。用 A2A远程端需要对模糊指令做推理——解释意图、做判断、调用自己的 Tool、进行多轮对话。两者都用编排 Agent 通过 A2A 把任务委派给专家 Agent而每个专家 Agent 通过 MCP 访问自己的工具[citation:4]。6.3 组合架构一张分层图┌──────────────────────────────┐ │ 用户复杂目标 │ └──────────────┬───────────────┘ ▼ ┌──────────────────────────────┐ │ 编排 Agent总监 │ └──┬───────────┬───────────┬───┘ │ A2A │ A2A │ A2A ← 横向Agent 间 ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │机票Agent│ │酒店Agent│ │报销Agent│ └──┬───┘ └──┬───┘ └──┬───┘ │ MCP │ MCP │ MCP ← 纵向Agent→工具 ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │航司API│ │OTA平台│ │财务系统│ └──────┘ └──────┘ └──────┘企业差旅实例用户说下周去上海帮我订机票和酒店还要能报销。编排 Agent 通过 A2A发现机票、酒店、报销三个 Agent可能分别来自航司、OTA、公司财务系统读取各自的 Agent Card用 Task委派并收集 Artifact最终汇总成一份完整方案。而机票 Agent 内部则用 MCP 去查航司库存 API。常见误区澄清这也是面试高频扣分点❌ “有了 A2A就要统一底层大模型” → A2A不管模型只规定 Agent 间如何交流。❌ “A2A 只是 API 封装” → 它包含能力发现 任务状态机 交付物 多轮协商等协作语义。❌ “A2A 和 MCP 二选一” → 它们是互补关系正经企业级系统通常两个都要[citation:8][citation:11]。七、工程落地优势与真实挑战客观分析必须同时讲清楚收益和代价。A2A 的优势很明显标准化互操作、解耦新增 Agent 只需加 URL不改代码、原生支持长时/多轮/异步任务、安全前置。但它也带来了实实在在的工程挑战需要正视的几个问题状态一致性管理复杂多 Agent 长时协作下Task 状态、上下文contextId、重试语义的分布一致性需要业务层自己保证。部分故障处理尚不成熟一个编排流程里某个 Agent 长时间无响应、返回unknown、或交付物格式不兼容时补偿与重试策略规范并未给出标准答案。鉴权与权限治理不可忽视跨厂商协作必须先确认你是谁 你能做什么——OAuth2/OIDC、scope、最小权限都要落地不能因为是Agent 内部就省略。协议仍在演进v1.0 才刚稳定真实生产部署的规模与最佳实践仍在积累中生态的采纳广度最终决定协议的实际价值[citation:2]。性能与成本相比直接函数调用引入 Agent 推理 多轮通信会显著增加延迟与 token 开销不适合对延迟敏感的确定性链路。最小可运行骨架概念代码下面这段 Python 伪代码用于理解协议报文结构不依赖官方 SDK# ---------- A2A Server 侧简化----------fromuuidimportuuid4fromdataclassesimportdataclass,fieldfromtypingimportList,OptionalimportjsonclassTaskState:SUBMITTED,WORKING,COMPLETED,FAILED,INPUT_REQUIRED\submitted,working,completed,failed,input-requireddataclassclassTask:id:strfield(default_factorylambda:ftask-{uuid4().hex})context_id:strfield(default_factorylambda:fctx-{uuid4().hex})state:strTaskState.SUBMITTED artifacts:List[dict]field(default_factorylist)# Agent Card 发现端点app.get(/.well-known/agent-card.json)defagent_card():return{...}# 见 3.1 完整卡片# JSON-RPC: 同步发送任务app.post(/message:send)defsend_message(params:dict)-dict:taskTask()# ... 交由 task_handler 异步处理 ...task.stateTaskState.WORKINGreturn{jsonrpc:2.0,id:params.get(id),result:{id:task.id,status:{state:task.state}}}# SSE: 流式发送任务app.post(/message:stream)defsend_stream(params:dict):defevent_stream():yieldevent: task-status\ndata: {state:working,message:处理中...}\n\nyieldevent: task-artifact\ndata: {parts:[{type:text,text:结果}]}\n\nyieldevent: task-status\ndata: {state:completed}\n\nreturnStreamingResponse(event_stream(),media_typetext/event-stream)# ---------- A2A Client 侧简化----------defdiscover(base:str)-dict:returnhttp.get(f{base}/.well-known/agent-card.json).json()defdelegate(endpoint:str,text:str)-dict:payload{jsonrpc:2.0,method:SendMessage,id:1,params:{message:{role:user,parts:[{type:text,text:text}]}}}returnhttp.post(endpoint,jsonpayload).json()defget_task(endpoint:str,task_id:str)-dict:payload{jsonrpc:2.0,method:GetTask,id:2,params:{id:task_id}}returnhttp.post(endpoint,jsonpayload).json()生产建议真实项目优先使用官方 SDKPython / JS / Java / Go / .NET而非手写避免重复实现状态机、错误模型与绑定细节[citation:2]。八、总结把单体智能连接成协同网络回到开头的问题——“A2A 协议是什么”一个相对完整、能在面试或技术评审中站得住脚的回答是A2A 是面向异构 AI Agent 的开放互操作协议。它通过Agent Card能力发现、Task有状态任务生命周期、Message / Part多模态通信、Artifact交付物四个核心抽象配合JSON-RPC / REST / gRPC三种等价传输绑定解决了不同厂商、不同框架 Agent 之间的发现、认证、委派、状态同步与结果交付问题。它与 MCP 互补而非竞争MCP 管 Agent 调用工具纵向A2A 管 Agent 之间协作横向。更本质地说A2A 体现的是一种架构视角迁移把 AI 系统从单体能力推向智能体生态——单个 Agent 是专家协议让专家之间能像团队一样协作。这也是它被称为Agent 世界的 HTTP的原因。但要记住客观边界A2A 不是银弹。它解决的是通信与协作的标准化不解决模型能力、工具质量、业务正确性也不替你处理所有分布式系统的复杂性。引入前请先问自己你的场景是否真的存在跨框架/跨团队的 Agent 互操作需求如果只是同一框架内的多 Agent 编排框架自带机制往往更简单只有当异构协作真实存在时A2A 的标准化价值才会真正兑现。参考资料A2A 官方规范https://a2a-protocol.org/latest/specification/A2A 项目仓库https://github.com/a2aproject/A2A腾讯云技术百科A2A 协议架构与核心组件[citation:1]A2A 中文社区规范翻译TaskState、Message 等[citation:10]A2A vs MCP 精确对比与组合架构[citation:4][citation:8][citation:11]延伸思考如果你对要不要自研一套 Agent 通信协议还有犹豫不妨把 A2A 的分层架构Data Model → Operations → Bindings当作评估模板——即便最终不用 A2A这套语义与传输解耦 自描述发现 有状态任务的设计思想也值得在你的系统里复用。 A2A 协议：面向异构智能体的互操作标准与工程实践
A2A 协议面向异构智能体的互操作标准与工程实践说明本文从一个常见的问题出发——“A2A 协议是什么”——但目标不止于给出一个能应付面试的定义。我们将按照定位 → 数据模型 → 交互流程 → 传输绑定 → 与 MCP 的关系 → 工程权衡的顺序把 A2AAgent2Agent Protocol当作一个普通的分布式系统协议来分析它解决了什么问题、抽象边界在哪里、落地时要注意什么以及它不是什么。一、背景智能体协作的孤岛问题过去两年围绕单个 Agent 的构建已经形成了相对成熟的工具链LLM Prompt Memory Tool UseFunction Calling。但当我们把视野从单个 Agent拉到多个 Agent 协同完成一个复杂目标时会立刻撞上一堵墙——异构孤岛。现实中的 Agent 可能由不同团队、不同框架LangGraph、CrewAI、AutoGen、Google ADK、Semantic Kernel……、不同大模型构建部署在不同的域名与网络环境里。此时让它们协作常见的临时方案是把对方的 Agent “包成一个 Tool”用私有 HTTP 接口 自定义 JSON 去对接。这种方式在规模上来后会迅速恶化发现难没有统一的能力描述格式调用方只能靠文档或口头约定。协作语义弱普通 HTTP 请求-响应无法原生表达长时任务、状态流转、多轮澄清、主动回调。重复造轮子每个集成对都要重新约定鉴权、错误码、进度推送、取消机制。A2A 的出现本质上是要把这套智能体间通信从私有的点对点集成提升为标准化的互操作层。它把智能体视为对等的、不透明的协作者而非被调用的工具通过一套自描述的能力声明 有状态的任务模型 可复用的传输绑定让不同阵营的 Agent 能够互相发现、委派任务、同步状态、交付结果。一句话定位A2A 是 Agent 世界的外交协议——它不关心对方内部用什么模型、什么框架只规定你如何描述自己、如何接活、如何回报。二、A2A 是什么官方定位与演进A2A 全称Agent2Agent Protocol是由 Google 于 2025 年 4 月首次发布、后捐赠给Linux FoundationAgentic AI Foundation治理的开放标准协议[citation:1]。截至 v1.0.02026 年 3 月 GA规范已经进入稳定维护期拥有多家云厂商与开源框架的支持[citation:2]。理解 A2A 最重要的一件事是认清它的设计哲学——“Agents Are Not Tools”维度A2A 的立场对端身份远程 Agent 是独立、有推理能力的对等实体抽象边界不定义 Agent 内部实现prompt / memory / tools协议范围不做编排框架、不与 MCP 竞争标准化方式Proto-Firstproto 文件为唯一规范性定义这一点决定了 A2A 的克制它只规范 Agent 之间的契约面而把Agent 内部怎么想完全留给实现方。正是这种克制才让跨厂商互操作成为可能。三、核心数据模型五个关键概念A2A 的数据模型可以概括为五个名词用一个口诀记忆非常有效Agent Card 是简历Task 是派单Message 是聊天记录Artifact 是交付物。下面逐一落到工程细节。3.1 Agent Card智能体的自描述名片AgentCard是一份机器可读的 JSON 元数据文档通常发布在符合RFC 8615的 Well-Known URI 路径下GET https://{domain}/.well-known/agent-card.json客户端另一个 Agent 或用户应用通过解析这张卡片判断该不该找它干活、怎么跟它通信、需要什么凭据。一份较完整的 Agent Card 包含以下模块[citation:16][citation:17]{name:Travel Booking Agent,description:搜索并预订机票、酒店,version:1.0.0,provider:{organization:TravelCorp,url:https://travelcorp.com},supportedInterfaces:[{url:https://api.travelcorp.com/a2a,protocolBinding:JSONRPC,protocolVersion:1.0}],capabilities:{streaming:true,pushNotifications:true},defaultInputModes:[text/plain,application/json],defaultOutputModes:[text/plain,application/json],skills:[{id:flight-search,name:机票搜索,description:按出发地、目的地、日期搜索可用航班,tags:[travel,flight],examples:[搜索明天北京到上海的航班]}],securitySchemes:{oauth2:{type:oauth2,flows:{clientCredentials:{tokenUrl:https://auth.travelcorp.com/token,scopes:{search:搜索航班和酒店,book:完成预订}}}}},security:[{oauth2:[search,book]}]}关键字段解读supportedInterfaces显式声明协议绑定、版本与端点支持多绑定并存与版本协商客户端选择兼容版本[citation:2]。skills这是能力发现的核心——把能做什么结构化、可检索。相比 Tool 清单它更偏向意图与能力而非具体函数签名。securitySchemes/security把鉴权要求前置到发现阶段避免先调再用、报错才知道要 token。签名signaturesJWS企业场景下可验证卡片来源与完整性防止中间人篡改[citation:16]。Extended Agent Card认证后可获取更丰富的扩展信息GetExtendedAgentCard实现分层信息披露——对外只暴露摘要认证后才给细节[citation:2]。工程提示发现机制不止 Well-Known URI 一种还包括策展注册中心中心化目录按 skill/tag 查询与静态配置已知关系直接硬编码[citation:17]。协议没有规定中心化注册表生产环境通常需要自己加一层发现/治理层[citation:5]。3.2 Task有状态的核心工作单元如果说 Agent Card 解决找到谁Task解决的就是怎么把活交出去并盯住它。Task 是 A2A 中唯一同时具备身份、生命周期、状态和产出物的概念其数据结构大致为{id:task-123,contextId:ctx-001,status:{state:working,message:{text:正在搜索航班...}},artifacts:[],history:[...]}id任务全局唯一标识支持跨 Agent 追踪。contextId所属上下文会话/流程用于把多个 Task 归入同一业务流程。status当前状态含state与可选的描述消息。artifacts最终交付物集合。history交互历史。Task 状态机是 A2A 区别于普通 API 调用最关键的部分[citation:1][citation:10]┌─────────────┐ │ SUBMITTED │ 已提交尚未开始处理 └──────┬──────┘ ▼ ┌─────────────┐ │ WORKING │ 正在处理可能持续推送进度 └──┬───┬───┬──┘ ┌───────────┘ │ └───────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────────┐ ┌───────────┐ │COMPLETED │ │ INPUT_REQUIRED│ │AUTH_REQUIRED│ │ (终态) │ │ (暂停等输入)│ │ (暂停等认证)│ └──────────┘ └──────┬───────┘ └──────┬────┘ │ │ ▼ │ 回到 WORKING ◄────────────┘ │ ┌────────┬───────┴───────┬─────────┐ ▼ ▼ ▼ ▼ FAILED CANCELED REJECTED (unknown) (终态) (终态) (终态)需要特别注意的几点终态不可重启一旦进入COMPLETED/FAILED/CANCELED/REJECTED该 Task 就不能再次启动后续操作必须在同一contextId下创建新 Task[citation:7]。这是一个重要的工程权衡——简化了实现与追踪但意味着重试需要由上层业务自己建模。INPUT_REQUIRED与AUTH_REQUIRED是暂停态而非终态前者支持人机协作 / 多轮澄清后者把鉴权异常显式建模进状态机而不是靠错误码偷偷传递。REJECTED≠FAILEDREJECTED表示拒绝执行如权限不足、无法理解意图FAILED表示尝试了但出错了——语义不同调用方应区别处理。unknown任务状态无法确定ID 无效、未知、已过期[citation:10]。长时任务是 Task 状态机的第一性驱动力。一个供应链优化任务可能跑几小时甚至几天单纯请求-响应会让连接和资源管理陷入困境——这正是 A2A 引入状态机、轮询、流式、推送多种同步机制的动因。3.3 Message 与 Part通信内容的最小单元Message表示一次通信轮次包含roleuser 客户端发送 /agent 服务端发送和一个或多个Part{role:user,parts:[{type:text,text:帮我订明天北京到上海的机票},{type:data,data:{preferred:经济舱}}]}Part是内容与多模态的最小载体支持text文本、file文件含 MIME、data结构化 JSON[citation:1]。这让 A2A 天然支持多模态文本、图片、音频、视频、结构化数据、文件都能在消息/交付物中流转。Message与Artifact的分工Message通信过程中的非交付内容——指令、上下文、思考过程、状态更新。Artifact任务完成后正式的、不可变的交付物可包含多个 Part[citation:12]。一句话Message 是过程Artifact 是结果。把两者分开才能让中间讨论和最终成果不混在一起也便于做产物管理与审计。四、交互流程一次完整委派长什么样把上面四个概念串起来一个典型的 A2A 交互时序如下Client Agent Remote Agent │ │ │── GET /.well-known/agent-card.json ──▶│ ① 发现 │◀── AgentCard (能力/接口/安全) ────────│ │ │ │── SendMessage (Task, Message) ───────▶│ ② 委派 │◀── Task(id, statusSUBMITTED) ───────│ │ │ │◀── SSE: statusWORKING ──────────────│ ③ 进度 │◀── SSE: artifact delta ──────────────│ │ │ │── GetTask (轮询/兜底) ──────────────▶│ ④ 查询 │◀── Task(status, artifacts) ──────────│ │ │ │◀── Task(statusCOMPLETED, artifacts) │ ⑤ 交付对应到**抽象操作Abstract Operations**层主要方法为[citation:9][citation:12]操作作用SendMessage发送消息创建或继续一个 TaskSendStreamingMessage发送消息并通过流接收更新SSEGetTask查询 Task 当前状态与结果ListTasks按条件列出任务CancelTask请求取消任务SubscribeToTask订阅已有 Task 的流式更新Create/Get/List/DeleteTaskPushNotificationConfig配置异步 Webhook 推送GetExtendedAgentCard认证后获取扩展 Agent Card长时任务的三套同步机制A2A 对任务进度如何同步到调用方给出了三种等价机制开发者按场景选择[citation:2]轮询PollingSendMessage后周期性GetTask——实现简单适合秒级延迟可接受的场景。流式SSEServer-Sent EventsSendStreamingMessage服务端持续推送TaskStatusUpdateEvent/TaskArtifactUpdateEvent——适合需要实时进度、但调用方需维持长连接的场景。推送通知Push Notification预先配置 Webhook任务状态变化时由服务端主动回调——最适合小时级/天级的超长任务调用方无需维持连接。这三套机制共用同一套StreamResponse数据模型是 A2A 设计中多种传输、统一语义的典型体现。五、传输绑定分层架构的工程价值A2A 规范按Data Model → Abstract Operations → Protocol Bindings三层组织[citation:9]。第三层协议绑定允许同一套语义映射到多种传输且规范保证它们之间语义等价[citation:2]绑定传输方式流式支持典型场景JSON-RPC 2.0HTTP POSTapplication/jsonSSEtext/event-stream最简单、生态最广gRPCHTTP/2 ProtobufServer Streaming RPC高性能、强类型HTTPJSON / REST标准 RESTful 端点SSE对接既有 REST 基础设施示例一个发送消息操作在不同绑定下的映射[citation:9]// JSON-RPC 2.0 请求{jsonrpc:2.0,id:1,method:SendMessage,params:{message:{role:user,parts:[{type:text,text:我要一杯拿铁}]},taskId:null}}# REST 等价端点 POST /message:send Content-Type: application/json { message: {...} }// gRPC 等价服务 service AgentService { rpc SendMessage(MessageRequest) returns (Task); rpc SendStreamingMessage(MessageRequest) returns (stream StreamResponse); }HTTP 层的约定也不容忽视规范额外定义了A2A-Version头如1.0、A2A-Extensions头逗号分隔的扩展 URI以及自定义 media typeapplication/a2ajson生产环境必须使用 HTTPS推荐 TLS 1.3[citation:17]。为什么这种分层 多绑定设计值得学习它把业务语义和传输细节解耦让不同技术栈都能接入同时通过 proto 作为唯一规范性来源消除规范漂移specification drift。这是协议设计的通用最佳实践即便你不用 A2A这套思路也可借鉴。六、A2A 与 MCP精确辨析而非口号A2A 管同事、MCP 管工具是很好记的口诀但要写出客观的技术分析需要把边界讲到更细。6.1 分工一横一纵维度A2AMCP提出方 / 治理Google 发起LF 治理Anthropic 提出通信对象Agent ↔ AgentAgent ↔ Tool / 资源对端智能性两端都有推理能力仅 Agent 端智能Tool 端是确定性服务核心概念Agent Card、Task、Message、ArtifactTool、Resource、Prompt状态性有状态Task 完整生命周期通常无状态Tool 调用交互模式多轮对话、委派、协商结构化函数调用、读写资源发现机制Agent Card能力声明Tool 清单典型延迟秒到分钟级长时任务毫秒级认证双向认证OAuth 2.0 / OIDC服务端控制为主抽象层次高级意图与能力低级具体功能/接口[citation:4][citation:8]6.2 何时用哪个判断依据很朴素——对端是确定性函数还是需要推理的实体[citation:4]用 MCP远程端是一个确定性函数——数据库查询、API 调用、代码执行沙箱、读文件。Agent 完全掌控交互过程。用 A2A远程端需要对模糊指令做推理——解释意图、做判断、调用自己的 Tool、进行多轮对话。两者都用编排 Agent 通过 A2A 把任务委派给专家 Agent而每个专家 Agent 通过 MCP 访问自己的工具[citation:4]。6.3 组合架构一张分层图┌──────────────────────────────┐ │ 用户复杂目标 │ └──────────────┬───────────────┘ ▼ ┌──────────────────────────────┐ │ 编排 Agent总监 │ └──┬───────────┬───────────┬───┘ │ A2A │ A2A │ A2A ← 横向Agent 间 ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │机票Agent│ │酒店Agent│ │报销Agent│ └──┬───┘ └──┬───┘ └──┬───┘ │ MCP │ MCP │ MCP ← 纵向Agent→工具 ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │航司API│ │OTA平台│ │财务系统│ └──────┘ └──────┘ └──────┘企业差旅实例用户说下周去上海帮我订机票和酒店还要能报销。编排 Agent 通过 A2A发现机票、酒店、报销三个 Agent可能分别来自航司、OTA、公司财务系统读取各自的 Agent Card用 Task委派并收集 Artifact最终汇总成一份完整方案。而机票 Agent 内部则用 MCP 去查航司库存 API。常见误区澄清这也是面试高频扣分点❌ “有了 A2A就要统一底层大模型” → A2A不管模型只规定 Agent 间如何交流。❌ “A2A 只是 API 封装” → 它包含能力发现 任务状态机 交付物 多轮协商等协作语义。❌ “A2A 和 MCP 二选一” → 它们是互补关系正经企业级系统通常两个都要[citation:8][citation:11]。七、工程落地优势与真实挑战客观分析必须同时讲清楚收益和代价。A2A 的优势很明显标准化互操作、解耦新增 Agent 只需加 URL不改代码、原生支持长时/多轮/异步任务、安全前置。但它也带来了实实在在的工程挑战需要正视的几个问题状态一致性管理复杂多 Agent 长时协作下Task 状态、上下文contextId、重试语义的分布一致性需要业务层自己保证。部分故障处理尚不成熟一个编排流程里某个 Agent 长时间无响应、返回unknown、或交付物格式不兼容时补偿与重试策略规范并未给出标准答案。鉴权与权限治理不可忽视跨厂商协作必须先确认你是谁 你能做什么——OAuth2/OIDC、scope、最小权限都要落地不能因为是Agent 内部就省略。协议仍在演进v1.0 才刚稳定真实生产部署的规模与最佳实践仍在积累中生态的采纳广度最终决定协议的实际价值[citation:2]。性能与成本相比直接函数调用引入 Agent 推理 多轮通信会显著增加延迟与 token 开销不适合对延迟敏感的确定性链路。最小可运行骨架概念代码下面这段 Python 伪代码用于理解协议报文结构不依赖官方 SDK# ---------- A2A Server 侧简化----------fromuuidimportuuid4fromdataclassesimportdataclass,fieldfromtypingimportList,OptionalimportjsonclassTaskState:SUBMITTED,WORKING,COMPLETED,FAILED,INPUT_REQUIRED\submitted,working,completed,failed,input-requireddataclassclassTask:id:strfield(default_factorylambda:ftask-{uuid4().hex})context_id:strfield(default_factorylambda:fctx-{uuid4().hex})state:strTaskState.SUBMITTED artifacts:List[dict]field(default_factorylist)# Agent Card 发现端点app.get(/.well-known/agent-card.json)defagent_card():return{...}# 见 3.1 完整卡片# JSON-RPC: 同步发送任务app.post(/message:send)defsend_message(params:dict)-dict:taskTask()# ... 交由 task_handler 异步处理 ...task.stateTaskState.WORKINGreturn{jsonrpc:2.0,id:params.get(id),result:{id:task.id,status:{state:task.state}}}# SSE: 流式发送任务app.post(/message:stream)defsend_stream(params:dict):defevent_stream():yieldevent: task-status\ndata: {state:working,message:处理中...}\n\nyieldevent: task-artifact\ndata: {parts:[{type:text,text:结果}]}\n\nyieldevent: task-status\ndata: {state:completed}\n\nreturnStreamingResponse(event_stream(),media_typetext/event-stream)# ---------- A2A Client 侧简化----------defdiscover(base:str)-dict:returnhttp.get(f{base}/.well-known/agent-card.json).json()defdelegate(endpoint:str,text:str)-dict:payload{jsonrpc:2.0,method:SendMessage,id:1,params:{message:{role:user,parts:[{type:text,text:text}]}}}returnhttp.post(endpoint,jsonpayload).json()defget_task(endpoint:str,task_id:str)-dict:payload{jsonrpc:2.0,method:GetTask,id:2,params:{id:task_id}}returnhttp.post(endpoint,jsonpayload).json()生产建议真实项目优先使用官方 SDKPython / JS / Java / Go / .NET而非手写避免重复实现状态机、错误模型与绑定细节[citation:2]。八、总结把单体智能连接成协同网络回到开头的问题——“A2A 协议是什么”一个相对完整、能在面试或技术评审中站得住脚的回答是A2A 是面向异构 AI Agent 的开放互操作协议。它通过Agent Card能力发现、Task有状态任务生命周期、Message / Part多模态通信、Artifact交付物四个核心抽象配合JSON-RPC / REST / gRPC三种等价传输绑定解决了不同厂商、不同框架 Agent 之间的发现、认证、委派、状态同步与结果交付问题。它与 MCP 互补而非竞争MCP 管 Agent 调用工具纵向A2A 管 Agent 之间协作横向。更本质地说A2A 体现的是一种架构视角迁移把 AI 系统从单体能力推向智能体生态——单个 Agent 是专家协议让专家之间能像团队一样协作。这也是它被称为Agent 世界的 HTTP的原因。但要记住客观边界A2A 不是银弹。它解决的是通信与协作的标准化不解决模型能力、工具质量、业务正确性也不替你处理所有分布式系统的复杂性。引入前请先问自己你的场景是否真的存在跨框架/跨团队的 Agent 互操作需求如果只是同一框架内的多 Agent 编排框架自带机制往往更简单只有当异构协作真实存在时A2A 的标准化价值才会真正兑现。参考资料A2A 官方规范https://a2a-protocol.org/latest/specification/A2A 项目仓库https://github.com/a2aproject/A2A腾讯云技术百科A2A 协议架构与核心组件[citation:1]A2A 中文社区规范翻译TaskState、Message 等[citation:10]A2A vs MCP 精确对比与组合架构[citation:4][citation:8][citation:11]延伸思考如果你对要不要自研一套 Agent 通信协议还有犹豫不妨把 A2A 的分层架构Data Model → Operations → Bindings当作评估模板——即便最终不用 A2A这套语义与传输解耦 自描述发现 有状态任务的设计思想也值得在你的系统里复用。