A2A
为什么重要
深度解析
A2A 要解决的问题说起来很直接：组织部署的智能体越来越多，这些智能体需要互相转交工作，而眼下每一对都得定制集成。A2A 为这种交接定义了共同模式。一个智能体充当客户端，提出任务；另一个充当远程智能体，负责执行。双方通过普通 Web 基础设施交换上下文、指令和结果——线路格式采用基于 HTTP 的 JSON-RPC 2.0，实时更新采用 Server-Sent Events——因此接入时既不需要新传输层，也不要求共享运行时。最关键的是，智能体彼此仍是黑盒：它们靠声明的能力和任务状态协调，不会共享记忆、权重或内部推理。
智能体卡片与能力发现
A2A 通过智能体卡片完成发现：这是一份小型 JSON 文档，通常发布在智能体域名下的知名路径，例如 /.well-known/agent.json，内容说明谁在运营它、它提供哪些技能、接受什么输入输出格式，以及需要何种身份验证。客户端智能体会在发送任何实际工作前先读取卡片，以便通过程序或 LLM 规划器判断这个远程智能体到底是不是任务候选者。实践中，卡片有两种出现方式：如果工作流已经知道合作智能体的 URL，就直接读取；否则，就从企业为批准的智能体维护的精选注册表中查找。卡片模型让 A2A 不只是一套消息约定，而是真正的发现层；它也照出了自主智能体理解任何其他资源的方式：读描述、拿它与目标匹配，然后行动。
任务、消息与产物
A2A 的工作单位是任务，并拥有明确生命周期：已提交、处理中、需要输入、已完成、失败或取消。在任务内部，两个智能体交换消息，而每条消息都由部件组成，不只是原始文本——自然语言放进文本部件，二进制内容放进文件部件，表单、报价等结构化 JSON 载荷则放进数据部件。这种部件模型很重要，因为真实商业工作流跑的是结构化数据；A2A 让智能体可以围绕结构化输出协商，不必把一切硬塞进聊天散文。任务完成时，结果以产物形式交付：这些具名输出同样由部件组成，客户端智能体可以自己消费，也可以传给更大智能体工作流的下一步。
生命周期状态在长时间运行的工作中最能证明价值。耗时数分钟或数小时的任务，可以通过 Server-Sent Events 向客户端连续发送进度事件；如果客户端无法一直保持连接，也可以用推送通知向 webhook 交付更新，让断开连接的消费者仍能使用流式传输。其中最微妙的是“需要输入”状态：远程智能体可以在任务中途暂停并提出澄清问题，多轮智能体协商也就不必打破任务抽象。
A2A 不会取代 MCP
关于 A2A 最常见的误解，是它在与 MCP 竞争。并没有——两个协议工作在不同层。MCP 统一一个智能体连接工具和数据源的方式：调用函数、读取资源、运行查询。A2A 则统一两个独立智能体的协调方式，由一方把任务委派给可能属于完全不同团队、供应商或信任域的同伴。常见的简写是，MCP 是纵向接口，也就是智能体到工具；A2A 是横向接口，也就是智能体到智能体。
真实的生产配置会在同一条调用链中同时使用两者。编排智能体可以用 MCP 完成工具使用——访问 CRM、搜索索引或代码仓库——再用 A2A 把工作分包给专业智能体，例如由法务部门运行的合同审查智能体，而后者内部又依赖 MCP 和 Function Calling。两个协议都不规定另一个智能体内部发生什么，而这种不透明是刻意的设计：组织可以协作，又不必暴露提示词、记忆或专有推理。
治理、生态与开放问题
Google 于 2025 年把 A2A 作为开放规范发布，并附上参考 SDK；发布时已有 50 多个技术合作伙伴支持，横跨企业软件供应商、LangChain 等框架，以及咨询公司。随后，Google 把项目捐给 Linux Foundation，确保没有一家供应商能独自控制它的演进。这一步治理动作对采用很重要：只有竞争对手不必担心规则被人在脚下突然改掉，协议才可能变成管道。规范、SDK 和样例智能体全部公开，设计也刻意复用现有 Web 标准，没有另起炉灶。
前方真正困难的问题，与其说是消息格式，不如说是信任。智能体卡片会声明所需的身份验证，却没有任何协议机制告诉你该不该相信卡片，因此跨组织 A2A 流量既是集成问题，也同样是AI 安全问题。提示注入就是具体风险：恶意或已遭入侵的远程智能体，可以把敌对指令嵌进任务结果，而客户端智能体的模型会老老实实读进去。如今，基于 A2A 构建多智能体系统的团队通常会把发现范围限制在精选注册表，先验证产物再让模型看到，并默认将所有远程智能体视为不受信任。