目录1.A2A的定义2.A2A的核心对象（1）Agent Card（2）Task（3）Message（5）Artifact3.A2A的工作流程4.A2A的发现与认证5.怎么判断A2A适不适合你的系统网址：A2A Protocol - Agent2Agent Communication1.A2A的定义A2A针对的是一个很现实的问题：企业里不会只有一个 agent。一个“招聘 agent”可能要和“候选人搜索 agent”“背景调查 agent”“日程安排 agent”协作；一个“研发助手”可能要和“代码 agent”“测试 agent”“文档 agent”“审批 agent”协作。问题在于，这些agent往往来自不同供应商、用不同框架实现、运行在不同系统里。Google 在发布文章里把这个痛点概括为：agent 需要能跨孤立的数据系统和应用生态协作，否则多 agent 自动化很难真正落地。A2A 的目标就是提供一种“共同语言”，让 agent 能在企业系统之上安全交换信息、协调行动。从更长的历史看，这个问题并不新。早在 1990 年代，KQML就被提出为一种“知识与信息交换”的 agent communication language；随后FIPA ACL又把 agent communication 标准化为消息语言、会话协议和平台服务的一整套规范。KQML 论文把它描述为同时具备消息格式和消息处理协议的语言；FIPA/JADE 论文则强调 FIPA ACL 定义了消息的编码、语义和语用，并提供像 AMS、ACC、DF 这样的 agent 平台服务。A2A 可以被看作这一脉络在 LLM/agent 时代的“web-native、enterprise-native”重写：它不再从“言语行为语义学”出发，而是从任务、工件、流式更新、认证和多模态协作出发。Google 发布 A2A 时给了五条设计原则。第一，面向真正的 agent 协作，而不是把另一个 agent 当成“工具函数”；第二，建立在现有标准之上，例如 HTTP、SSE、JSON-RPC；第三，默认面向企业安全，强调认证和授权；第四，原生支持长任务，可以处理从即时回复到持续数小时/数天的任务；第五，模态无关，不仅是文本，还考虑音频、视频和更丰富的 UI 能力。这个定位和早期 ACL 的一个明显区别在于：A2A 非常强调“在真实 IT 栈上可接入、可运营、可治理”，而不只是抽象语义正确。2.A2A的核心对象