A2A：智能体到智能体，构建者实战指南

到 2026 年初，我已记不清有多少次企业架构评审以相同的图表开场。一个框代表 CRM 供应商的代理。一个框代表文档处理供应商的代理。一个框代表内部数据科学团队的代理，就是他们用 LangGraph 构建并引以为傲的那个。然后是框之间的一组箭头，当你问它们代表什么协议时，结果发现它们的意思是“某个团队稍后会编写的 REST 端点”。

现在每个供应商都提供一个代理。这部分已经完成，并且不会逆转。我在现场看到的情况，主要是在银行和保险公司，是次级问题：这些代理都无法相互通信。每对框之间都需要定制的胶水代码，而每段胶水代码都由在谈判中失利的团队拥有。代理之间的交接是临时拼凑的提示和 JSON 负载，既没有版本控制，也没有审计记录。当审查员问“哪个代理基于什么输入做出了这个决定”时，没有人能从日志中回答。这不是一个 AI 问题。这是一个披着 AI 外衣的集成问题，而我们以前已经解决过集成问题。我们通过协议来解决它们。

A2A (Agent2Agent) 是为这一层出现的协议。我与 Joyce Johnson 共同为 Camunda 博客撰写了一个两部分的系列文章，涵盖了决策框架和一个完整的抵押贷款构建，现在我已两次基于这些想法构建了多代理抵押贷款系统：一次是编排的 Camunda 演示，另一次是独立的 Gemini 3 黑客马拉松项目，带有真实的 Agent Cards 和 JSON-RPC 契约。本指南是其精髓：A2A 实际规定了什么，它相对于 MCP、AG-UI 和 AP2 的位置，我使用的两种编排模式，它实现的数据隐私边界，以及没有人会在发布幻灯片上提及的威胁模型。

多代理首先是一个集成问题，其次才是一个 AI 问题

我一直在那些只想谈论模型的人群中捍卫这个观点：企业中多代理系统的难点不在于代理的智能。而在于不同的团队拥有代理、大型语言模型和数据源，这些团队有不同的发布周期、不同的安全态势以及对“完成”的不同定义。

如果没有标准，你将得到 N 个代理以及多达 N×(N-1) 个点对点集成，每个集成都有自己的负载形状、重试语义和故障行为。我在 SOA 时代和微服务时代都看过这部电影。剧情从未改变。那些“临时”的集成变得承重。编写胶水代码的团队被重组。两年后，一次事件评审发现信用决策代理正在接收由某个无人拥有的服务通过字符串拼接组装的提示。

在受监管行业，风险更高，因为交接本身就是合规性表面。一个流经四个代理的抵押贷款决策需要每次跳转的可重构记录：发送了什么，返回了什么，哪个版本的哪个代理产生了它。临时集成使得这种记录昂贵或不可能。协议使其成为完成工作时的副产品。

A2A 是什么

A2A 是一个开放协议，用于代理之间跨越流程、团队和组织边界发现彼此、交换消息并执行任务。Google 于 2025 年 4 月宣布了它，有数十家启动合作伙伴，并于 2025 年 6 月将其捐赠给 Linux 基金会，现在它作为一个中立的开源项目存在。该规范于 2026 年达到 1.0 版。

事实	详情
起源	Google 于 2025 年 4 月宣布；2025 年 6 月捐赠给 Linux 基金会
治理	Linux 基金会（A2A 项目，a2aproject 在 GitHub 上）
当前规范	1.0（早期部署版本：0.2, 0.3；预计实际部署中存在偏差）
传输	JSON-RPC 2.0 over HTTP(S)；gRPC 和 HTTP+JSON/REST 绑定在规范后期添加
发现	Agent Card：在 /.well-known/agent-card.json 提供的 JSON 元数据
工作单元	任务，具有定义的生命周期和唯一 ID
结果	工件（结构化输出），与对话消息不同
流式传输	HTTP 绑定上的 Server-Sent Events；gRPC 上的服务器流式传输
长时间运行的工作	推送通知到客户端 webhook，加上重新订阅以重新连接
认证	在 Agent Card 中声明：API 密钥、HTTP Basic/Bearer、OAuth 2.0、OpenID Connect、双向 TLS

两个设计选择比其他任何都重要。首先，A2A 旨在不透明：代理之间不暴露其内部状态、模型权重或工具。它们暴露能力并交换结果。这种不透明性使得由供应商构建的、你无法控制模型的代理能够参与你的流程，而你无需信任其内部机制，只需信任其契约。其次，A2A 是面向任务而非面向聊天的。协议的核心对象是具有生命周期的任务，而不是消息线程。这一个选择使其适用于企业工作，因为企业工作不是对话。它是一个具有状态、所有者和截止日期的工作单元。

协议栈：A2A、MCP、AG-UI、AP2

我发现最有用的框架，也是我经常在白板上绘制的，是一个协议栈。每个协议回答一个不同的问题，它们相互补充而非竞争。

协议	层	它回答的问题	大致类比
MCP	代理到工具	一个代理如何调用工具并访问数据源？	能力的 USB-C
A2A	代理到代理	对等代理如何发现彼此并委托任务？	服务间的 HTTP
AG-UI	代理到用户	代理如何将状态流式传输到面向人类的界面？	前端的 WebSocket
AP2	代理到商家	代理如何证明支付授权并进行交易？	承载在下层协议上的签名授权令

具体地遍历协议栈：用户向经纪代理请求抵押贷款推荐（AG-UI 将交互带入 UI）。经纪代理将风险分析委托给承保代理（A2A）。承保代理从内部文档存储中拉取申请人文件（MCP）。如果流程最终由代理代表用户支付信用报告费用，支付授权将作为 AP2 授权令传输。四个协议，四个边界，一个流程。

协议栈框架的实际结果是架构纪律。当有人提议将内部数据库暴露为“代理”时，协议栈为你提供了拒绝的词汇：那是一个工具，把它放在 MCP 后面。当有人提议用自定义 webhook 将两个供应商代理连接起来时，协议栈会说：那是对等委托，使用 A2A 并免费获得任务生命周期。我写了一篇关于支付层的单独深度探讨，见AP2 现场指南；本指南专注于代理到代理的边界。

重要的机制

规范很长。实践中，有四个部分承担了大部分工作。

Agent Cards：作为契约的发现机制

Agent Card 是一个 JSON 文档，在 https://{host}/.well-known/agent-card.json 提供，它描述了一个代理是什么，它能做什么，以及如何安全地与其通信。它相当于 A2A 的 OpenAPI 文档，但它描述的是能力和技能，而不是端点和模式。

{
  "name": "Underwriter Agent",
  "description": "Analyzes applicant risk from income, debts, and credit score",
  "url": "https://agents.example.com/underwriter",
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "securitySchemes": { "oauth": { "type": "oauth2" } },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "risk-analysis",
      "name": "Mortgage risk analysis",
      "description": "Produces a structured risk assessment for a loan applicant",
      "tags": ["underwriting", "risk"]
    }
  ]
}

在我的黑客马拉松构建中，整个系统的冒烟测试实际上是 curl http://localhost:4001/.well-known/agent-card.json | jq '.name'。如果卡片解析成功，代理就是可发现的；其他一切都建立在此基础上。卡片还声明了代理的认证要求，以及它是否支持流式传输和推送通知，客户端在使用这些功能之前必须检查。当前规范支持签名卡片（对卡片内容进行 JWS 签名），因此客户端可以验证卡片是否由其声称的发行方发布。请使用它。我将在威胁模型中回到为什么。

任务生命周期

A2A 中的每个委托都是一个具有 ID 和状态机的任务。定义的 JSON 形式的状态：

状态	含义	终结状态？
submitted	已确认，尚未开始	否
working	正在积极处理	否
input-required	已暂停，等待客户端提供更多输入	否（中断）
auth-required	已暂停，等待额外授权	否（中断）
completed	成功完成，工件可用	是
failed	完成时出错	是
canceled	完成前已取消	是
rejected	代理拒绝了任务	是

有两个状态值得关注，因为它们编码了聊天式协议所忽略的企业现实。input-required 意味着任务可以在执行中暂停并请求更多信息，这就是远程承保代理如何在不导致整个任务失败的情况下请求缺失文档的方式。rejected 意味着代理可以拒绝其不具备资格或未获授权执行的工作，这是用于策略执行的协议级钩子。一个不处理这两种状态的客户端并没有实现 A2A；它只是实现了演示。

消息、部分、工件

任务内的通信使用消息（角色：用户或代理），每条消息都包含部分：文本、原始字节、文件引用或任意结构化数据。结果以工件的形式返回，工件也由部分组成，但与对话不同。这种分离听起来很官僚，直到你真正构建出东西。对话是代理之间协商的方式；工件是你据以行动和审计的内容。在抵押贷款系统中，承保代理的工件是结构化风险评估。下游步骤消费工件，而不是产生工件的“闲聊”。

流式传输和长时间运行的任务

对于交互式工作，HTTP 绑定通过 Server-Sent Events 流式传输 TaskStatusUpdateEvent 和 TaskArtifactUpdateEvent 对象（在 JSON-RPC 绑定中，是 message/stream）。这就是驱动实时进度 UI 的方式：我的抵押贷款演示中动画承保清单是直接从流式状态更新渲染的。

对企业更重要的是长时间运行的场景。银行中的实际任务不会在一个 HTTP 连接中完成。了解你的客户 (KYC) 检查可能需要数天。房产评估涉及人工驾车前往房屋。A2A 通过推送通知处理这种情况：客户端注册一个 webhook，服务器在任务进行过程中向其 POST 状态和工件事件，重新连接的客户端可以通过 ID 重新订阅任务。无需保持任何连接打开，双方也无需持续运行。

但请注意协议在这里没有做什么：它不会为你记住任何东西。如果你的客户端进程在三天任务的第二天崩溃，A2A 会乐意地将完成事件发送到一个不再知道为何关心它的 webhook。客户端的持久状态是你的问题，而这正是工作流引擎为此而生的原因。这就是编排问题紧随其后的技术原因。

编排与蜂群

将 A2A 代理连接到系统中有两种方式，这个选择比本指南中的任何其他选择都重要。

在蜂群模型中，代理之间点对点地相互委托。经纪代理调用承保代理，承保代理自行决定调用文档代理，文档代理再调用其他东西。控制流是涌现的。在编排模型中，流程引擎拥有流程并以步骤的形式调用 A2A 代理。引擎决定运行什么、以什么顺序、超时时间是多少；代理在每个步骤内部进行思考。我的单行版本，也是我在 Camunda 系列中演示的模式：流程是编排器。

在两部分的博客系列中，我们将其分解为一个我仍然逐字使用的决策启发式。如果在给定步骤的问题是“现在调用这个代理，等待最多 X 分钟，重试 Y 次，并在失败时升级”，那么该步骤属于确定性流程流，A2A 作为服务任务被调用。如果问题是“我到底应该调用哪个代理，接下来我们应该做什么”，那么该步骤属于 AI 代理子流程内部，其中 A2A 是众多工具之一，代理在运行时进行选择。在 Camunda 构建中，这些实际上是两种连接器模式（独立模式与代理工具模式），但该模式与引擎无关：在 Temporal 上，它是一个活动与由 LLM 规划器驱动的子工作流；在 LangGraph 上，它是一个固定边与路由器节点。模式优先，产品其次。

这两种模式是互补而非竞争的。我的工作系统两者都使用：关键路径的确定性主干，探索性区域内的代理驱动工具选择。

我强烈反对的是受监管环境中的纯蜂群模型。在每次严肃的评审中都会出现三种故障模式：

可审计性。 在蜂群中，重构“哪个代理基于什么做出了这个决定”意味着关联由不同团队或不同公司拥有的服务日志。在编排流程中，每次 A2A 调用都是流程实例中的一个步骤：输入、输出、时间、重试都通过构建记录为流程状态。当我构建抵押贷款演示时，每个中间代理结果都落在了一个命名的流程变量中，操作员可以检查。这不是额外的工作。它是架构的自然产物。

原子取消。 客户撤回申请。在编排流程中，你取消流程实例，引擎取消正在进行的 A2A 任务（协议为你提供了 tasks/cancel；引擎为你提供了调用它的对象）。在蜂群中，取消是一个谣言，以尽力而为的速度在可能遵守也可能不遵守的代理之间传播。现在想象一下被取消的任务是“提交信用申请”。

事件调查。 当编排流程出现故障时，事件有地址：流程实例、步骤、时间戳、负载。当蜂群出现故障时，调查的第一周是确定发生了什么，而代理自己的叙述日志不是证据，而是证词。

评审意见：如果你的多代理架构没有一个地方可以回答“这个客户请求的当前状态是什么”，那么你还没有构建一个系统。你只是构建了一个带有 API 密钥的群聊。

所有这些都不需要 Camunda 特别支持。它要求某种持久且可检查的东西拥有流程。Camunda 是我构建的地方，因为它是我的日常工作，也因为 BPMN 为审计员提供了他们可以阅读的图表，但这个论点适用于任何具有持久状态、计时器和取消语义的引擎。

一个实际模式：抵押贷款礼宾服务

我现在已经两次构建了这个系统，所以我将描述其通用形状，并诚实地说明每个构建证明了什么，又伪造了什么。

角色，四个代理和一个边界：

• 经纪代理。 前门。接收申请人的请求，决定聘请哪些专家，并汇总最终推荐。在 Camunda 构建中，这是一个带有 A2A 客户端、DMN 决策表、向量存储和 CRM 查找工具箱的 AI 代理子流程。在黑客马拉松构建中，它是一个独立的编排服务。
• 承保代理（远程）。 Gemini 驱动的对收入、债务和信用评分的风险分析。在黑客马拉松构建中，这个代理通过 Files API 将整个抵押贷款法规指南（大约 8.5 万个 token 的房利美销售指南）加载到上下文中，并在其输出中引用具体的法规代码，例如 B3-6-02。它是远程的，也应该如此：它完全基于申请人选择提交的数据工作，并受益于最强大的可用模型。
• 市场研究代理（本地）。 为风险状况查找适用的利率。特意托管在信任边界内部。更多信息见下一节。
• 评审代理。 评估经纪代理的汇总输出并对其置信度进行评分。高于阈值，流程自动进行。低于阈值，流程将路由到附带完整上下文的人工评审任务。在黑客马拉松版本中，这个角色是一个对抗性 QA 代理，它检查计算（债务收入比、贷款价值比）并拒绝虚构的法规引用，然后用户才能看到它们，自主地将失败的输出发送回去进行纠正。

评审代理是人们低估的部分。置信度门控的人工回退将“模型有时会出错”从一个异议转化为一个设计好的路径。阈值是一个业务决策，你可以根据风险类别进行调整，而人工评审任务是一个具有 SLA 的一流流程步骤，而不是在第一次事件后才匆忙添加的异常处理程序。

关于演示与生产之间的差距的诚实说明：

在我的演示中	在生产中
申请人输入的信用数据	带有同意跟踪的信用局集成
所有内容只有一个评审阈值	每个产品和风险类别都有阈值，由风险部门拥有，定期评审
通过硬编码的卡片 URL 发现代理	带有签名验证和白名单的卡片注册表
快乐路径取消	每个有副作用的步骤都有补偿逻辑
一个团队拥有所有四个代理	四个所有者，四个发布周期，每张卡片都有契约测试

最后一行改变了一切。只有一个所有者时，A2A 是一个不错的内部约定。有四个所有者时，它是你与本指南开头提到的 N×(N-1) 胶水问题之间唯一的屏障。

数据隐私边界模式

本地敏感 / 远程公共

这是抵押贷款构建中推广性最强的模式，也是我最常为银行勾勒的模式。

根据数据敏感性而非功能来划分你的代理。接触敏感数据（借款人个人身份信息、账户历史、任何有监管驻留限制的数据）的代理在你的信任边界内部本地运行，使用你托管的模型或你控制的契约。处理公共数据（市场利率、可比房产、法规文本）的代理可以在最强大的前沿模型上远程运行。A2A 是这两个区域之间的边界。

协议以临时集成无法实现的方式使这个边界清晰。Agent Card 在不暴露数据的情况下宣传能力：远程经纪代理知道本地市场研究代理的存在及其提供的技能，但每次实际交换都是一个明确的、已记录的 A2A 任务，其消息部分由你控制。敏感字段绝不会出现在出站部分，并且由于所有跨边界流量都通过一个协议流动，你可以在单一瓶颈点通过检查 A2A 负载的出站网关来强制执行这一点，而不是审计十几个定制集成。

在抵押贷款系统中：承保代理（远程，Gemini）看到申请人为此目的提交的财务信息。市场研究代理（本地）在边界内部进行检索，并在其工件中返回利率，而不是客户上下文。评审代理看到两个输出但在本地运行。该模式中没有任何奇特之处。它是应用于代理的网络分段，A2A 作为边界上的可路由协议。这种熟悉性是一个特点：你的安全团队已经知道如何评审这种设计。

威胁模型：难点

A2A 为你提供了契约表面。契约表面会受到攻击。以下是我在每次设计评审中都会提出的五个问题，大致按照它们会多早伤害到你的顺序。

Agent Card 欺骗

卡片是位于知名 URL 的 JSON 文件。任何能提供 JSON 的东西都可以声称是你的承保代理。TLS 保护的是通道，而不是声明：受损的 DNS 条目、被劫持的子域名或恶意的内部服务可以为一个它不操作的代理呈现一个格式完美的卡片，而你的经纪代理会乐意地向其发送贷款申请。缓解措施，按严重程度递增排序：固定卡片 URL，而不是盲目地遵循发现机制；根据你信任的发行方验证卡片签名（规范支持 JWS 签名的卡片）；并运行一个充当白名单的内部卡片注册表，这样“可发现”和“可调用”就是不同的权限。对待新的 Agent Card 就像对待新的上游依赖一样，因为它就是如此。

能力漂移

卡片显示版本 1.4.0 并宣传风险分析技能。六周后，其背后的团队更换模型、重写系统提示，并发布版本 1.4.1，卡片文本相同但行为实质上不同。协议中没有任何东西能捕捉到这一点；A2A 强制执行的契约是结构性的，而非行为性的。缓解措施与我们用于任何服务依赖的相同，但适应了非确定性：契约测试，按计划针对实时代理运行黄金任务，并在工件中出现分布偏移时发出警报，而不仅仅是模式中断。如果你消费一个不属于你的代理，你需要为其配备一个评估套件。我测量过足够多的模型替换，可以明确地说：相同的卡片，相同的模式，不同的模型，就是一个不同的代理。

版本偏差

规范发展迅速：大约一年内从 0.2 到 0.3 再到 1.0，而且变化并非表面性的。添加了传输绑定，甚至知名发现路径也发生了变化（早期实现提供 agent.json，当前规范规定 agent-card.json）。在多所有者部署中，你将同时拥有不同规范版本的代理，这是肯定的。在每个任务日志中记录协议版本，明确测试版本协商路径，并且不要假设生态系统的 SDK 会以相同方式解释边缘情况，因为它们不会。

跨组织边界的可观测性

在你的边界内部，你可以追踪一切。任务一旦跨越到合作伙伴的代理，你的追踪就在他们的前门结束。A2A 为你提供了用于关联的任务 ID 和上下文 ID，但关联只有在双方都保留并共享记录的情况下才有效。这是一个契约谈判，而不是代码问题：在上线前就追踪 ID 传播、日志保留和访问达成一致，因为在事件发生时进行谈判是痛苦的。我的默认立场是，拥有客户结果的一方应保留每项跨边界任务的权威记录：请求、响应、时间以及卡片版本。编排使其几乎免费；蜂群使其成为一个项目。

谁拥有 SLA

针对合作伙伴代理的 A2A 任务有一个你设置的超时时间和他们控制的完成时间。当承保代理从四十秒减慢到四百秒时，这是谁的事件？协议不会告诉你。在运营协议中写入具体数字（每项技能的响应时间百分位数、吞吐量、计划维护窗口），并机械地执行你方职责：每个步骤的超时预算、基于计时器的轮询退避、最大重试次数以及重试耗尽时的明确升级路径。在确定性模式中，所有这些都存在于流程模型中，操作人员可以看到。如果你的唯一 SLA 执行方式是希望远程代理速度快，那么蜂群已经赢了，而你已经输了。

评审意见：这五个问题中的每一个都是一个具有技术表面的组织问题。协议为你提供了表面。它无法替你参加治理会议。

A2A 没有解决什么

最快失去架构委员会信任的方法就是过度推销一个协议。以下是这个协议的诚实边界。

语义。 A2A 保证消息以有效结构到达。它不保证两个代理对 income 的含义相同。毛额还是净额？每年还是每月？家庭还是个人？两个符合规范的代理可以交换完美的 JSON 并产生错误的决策。你仍然需要共享词汇表，在受监管领域，你需要将它们书面记录下来。协议将集成问题提升了一个层次；它并没有解决它。

信任。 签名卡片告诉你谁发布了能力声明。它们不会告诉你代理是否称职、其训练数据是否合适，或者其运营商下个季度是否仍然存在。代理的声誉、认证和问责制是开放性问题。今天它们像往常一样，通过公司之间的契约来解决。

支付。 A2A 传输的是任务，而不是金钱。当代理需要证明它被授权代表用户消费时，那是一个不同的问题，具有不同的加密要求，而这正是 AP2 存在的目的。我已在AP2 现场指南中单独撰写了这方面的内容。

模型质量。 完美编排的平庸代理管道会产生可审计的平庸结果。协议层使故障可见且可归因，这非常有价值，但评审代理模式和诚实的评估才是使输出值得信任的关键。两者都要预算。

长时间运行的状态。 协议定义了多日任务如何通信。它不会持久化你这边的故事。某种持久的东西必须记住你为什么启动任务、什么依赖于它，以及当它完成或失败时该怎么做。带上一个工作流引擎，否则就准备好意外地构建一个。

一段话版本

每个供应商都提供代理，因此企业多代理问题首先是一个集成问题，其次才是 AI 问题，而集成问题通过协议来解决。A2A（Google，2025 年 4 月；Linux 基金会，2025 年 6 月；规范现已达到 1.0 版）是协议栈中代理到代理的层，与用于工具的 MCP、用于接口的 AG-UI 和用于支付的 AP2 并列：代理在 /.well-known/agent-card.json 发布签名的 Agent Cards，通过定义的生命周期（submitted 经由 completed、failed、canceled 或 rejected，以及用于暂停的 input-required 和 auth-required）交换任务，通过 SSE 流式传输进度，并通过 webhook 处理长达数天的工作。将这些代理与持久的编排器而非点对点蜂群连接起来，因为可审计性、原子取消和事件调查才是受监管行业真正看重的；将代理按数据隐私边界划分（敏感数据本地，公共数据远程，A2A 作为边界）；通过置信度评分的评审代理对自主输出进行把关，并在必要时回退到人工评审；并清楚地认识到协议留给你解决的问题：共享语义、代理信任、跨组织边界的 SLA，以及记住为什么启动一个三天任务的持久状态。

参考文献

• 我与 Joyce Johnson 共同撰写了本指南所依据的两部分系列文章：使用 A2A 实现您的业务目标，第 1 部分（决策框架：确定性 A2A 步骤与代理驱动的工具选择）和第 2 部分（完整的抵押贷款构建，两种模式均已实现）。
• A2A 协议规范，Agent Cards、任务状态、传输和安全方案的权威来源；源代码和 SDK 位于 github.com/a2aproject/A2A。
• gemini3-hackathon-mortgage-concierge，我的公共多代理抵押贷款预审构建：经纪代理、视觉代理和承保代理，带有 Agent Cards、JSON-RPC 2.0 契约、通过 Files API 获取的 8.5 万个 token 的法规上下文，以及对抗性 QA 循环。
• AP2：支付层，现场指南，我关于代理需要转移资金而不仅仅是任务时会发生什么的配套深度探讨。