A2A 与 Agent 互操作 （前沿了解）

这篇主要考察什么

A2A（Agent2Agent Protocol）是 2025–2026 年多 Agent 方向最值得关注的开放标准之一。面试里一旦问到 A2A，通常不是为了让你背术语，而是要看你有没有真正思考过下面几个问题：

1. 当一个 Agent 不是直接调用工具，而是把任务委托给另一个 Agent 时，交互对象为什么已经不是函数了？
2. 跨 Agent 协作时，为什么不能只靠一个普通 RPC 接口？
3. 任务状态、上下文、Artifact、异步执行、用户补充输入这些东西，应该如何在协议层表达？
4. A2A 和 MCP 为什么是互补关系，而不是替代关系？
5. 一个多 Agent 系统如何在开放生态下做发现、协作、治理和审计？

所以，A2A 这道题考察的不是你懂不懂多 Agent 这个热点，而是你是否理解 Agent 作为一等公民 时，协议设计会发生什么变化。（可以去看下linear之类的产品）

面试一句话版本：

:::color1
A2A 本质上是一个面向 Agent 协作的开放协议。它假设交互对端不是一个简单工具，而是一个有身份、有能力说明、有任务状态、有异步生命周期、能产出 artifact、也可能要求补充输入的完整 Agent。因此 A2A 关心的不只是调用一个函数，而是把一个任务安全、可追踪地委托给另一个 Agent 并持续跟踪其进度。

:::

为什么 另一个 Agent 不能简单当成一个 Tool

这是理解 A2A 的起点。

如果你把另一个 Agent当成一个普通工具，会立刻遇到几个问题：

1. 它不一定同步返回结果

一个工具调用往往是：

• 给参数；
• 执行；
• 回结果。

但一个 Agent 可能：

• 先接收任务；
• 进入 working 状态；
• 中途产出部分 artifact；
• 要求用户补充资料；
• 等待授权；
• 在很久之后才完成。

这明显比函数调用复杂得多。

2. 它可能有自己的内部推理和工具系统

远端 Agent 不是一个黑盒函数，而是一个自治实体。
它内部可能：

• 自己做 planning；
• 自己调工具；
• 自己维护短期状态；
• 自己产出多版本 artifact；
• 自己决定何时请求补充信息。

这意味着调用方不应该强行要求它暴露所有内部细节，而应该通过协议只约定协作边界。

3. 它需要被发现和识别

如果是一个工具，你通常只要知道函数名和参数。
但如果是一个 Agent，你还需要知道：

• 它是谁；
• 它擅长什么；
• 接收什么类型的任务；
• 用什么输入输出格式；
• 是否支持 streaming；
• 是否支持 push notification；
• 认证要求是什么；
• 能否处理多轮继续任务。

这就是为什么 A2A 需要 Agent Card 这类能力说明。

4. 它会产出 Artifact 而不是只返回一个值

一个 Agent 的结果可能不是简单 JSON，而可能是：

• 报告草稿；
• 代码补丁；
• 审核意见；
• 合同批注；
• 多版本文档；
• 图表文件；
• 需要后续继续修改的工作产物。

这类产物通常需要版本和持续更新语义，不适合被压扁成一个函数返回值。

一图看懂 A2A 的定位

这张图表达的核心是：

• MCP 更适合 Agent 连接工具和资源；
• A2A 更适合 Agent 之间分工协作；
• 一个完整系统里，这两者经常同时存在：Agent 内部通过 MCP 获得外部能力，Agent 之间通过 A2A 协调任务。

A2A 的核心对象有哪些

这部分是面试里的基本盘，建议用发现—发消息—跟踪任务—处理产物的顺序讲。

1. Agent Card：Agent 的能力名片

Agent Card 可以理解成远端 Agent 的公开说明书，它告诉调用方：

• 这个 Agent 的名称、描述、版本；
• 它擅长什么任务；
• 支持什么输入输出；
• 是否支持 streaming；
• 是否支持 push notifications；
• 认证和连接信息；
• 可能还有更详细的扩展元数据。

面试里你可以直接说：
Agent Card 的作用相当于让 Agent 先完成自我介绍，调用方再决定要不要把任务委托给它。

这个设计很重要，因为多 Agent 生态里，调用方不能靠硬编码记住所有远端能力，它需要一个标准化发现和描述机制。

2. Message：一次交互输入

Message 表示一次发送给远端 Agent 的消息。
但要注意，A2A 里的 message 不只是聊天文本，它可能包含不同类型的 Part，例如：

• 文本；
• 结构化数据；
• 文件引用；
• 表单数据；
• 其他协议定义的部件。

这说明 A2A 的交互模型比简单的文本 RPC 更丰富。

3. Task：被委托出去的工作单元

Task 是 A2A 最重要的概念之一。
当 client agent 把一件事情交给 remote agent 时，本质上是在创建或推进一个 task。
Task 之所以重要，是因为它把下面这些东西统一挂在一起：

• 当前状态；
• 输入上下文；
• 相关 artifact；
• 错误信息；
• 后续继续交互所需的 taskId / contextId；
• 可能的进度与历史。

一句话记忆：
Message 更像一次通信，Task 更像一件持续存在的工作。

4. Artifact：工作产物

Artifact 是远端 Agent 产出的结果对象。
它和 tool result 最大的不同在于：

• 可能有多个版本；
• 可能是中间产物，不是最终结果；
• 可能在任务过程中持续被更新；
• 可能需要人类或另一个 Agent 再次编辑。

例如：

• 一个调研报告草稿；
• 一份合同修订版；
• 一段生成的代码；
• 一个分析表格；
• 一个带批注的文档。

在 A2A 里，Artifact 把Agent 不只是回答一句话，而是在协作中生产工作成果这件事表达出来了。

5. Context：任务继续所依赖的上下文

多轮任务推进时，只靠上一条消息文本是不够的。
你还需要知道：

• 这是哪个任务上下文；
• 当前轮是在继续哪个 task；
• 之前已经产出了什么 artifact；
• 是不是等待用户补充；
• 是不是某个审批还没完成。

因此，A2A 里的 context 不是上下文窗口意义上的 prompt，而更接近协议层任务上下文标识。

A2A 的任务状态为什么是关键设计

这是面试里最能区分理解深度的地方。
A2A 明确把 task state 提上来了，因为 Agent 任务天然是长生命周期的。

一个典型状态流可以这样理解：

各状态怎么理解

• submitted：任务已提交，远端 Agent 已经接收；
• working：正在处理；
• input-required：远端 Agent 不能继续，需要补充输入；
• completed：任务完成，通常伴随最终 artifact；
• failed：任务失败；
• canceled：任务被取消；
• rejected：任务被拒绝，通常表示能力不适配或策略不允许；
• auth-required：需要认证或额外授权；
• unknown：调用方无法准确判断的保底状态。

为什么这很重要？
因为一旦你把远端 Agent 看成完整工作单元，系统就必须显式区分：

• 它是还在跑；
• 还是缺信息；
• 还是需要认证；
• 还是彻底失败；
• 还是可以继续推进。

如果没有这些状态，你就没法做真正的多 Agent 协作，只能做发一条消息碰碰运气。

A2A 的标准协作流程

可以在面试里按下面这条链讲

第一步：发现远端 Agent

通过 Agent Card 或目录服务，知道有哪些 Agent 可用、各自擅长什么。

第二步：发送任务消息

Client agent 把用户需求或子任务封装成 message / task 请求发给远端 agent。

第三步：远端进入任务状态机

远端可能立刻完成，也可能进入 working 状态持续执行。
如果是长任务，它可能通过 polling、streaming 或 push notification 持续更新状态。

第四步：产出 artifact 或请求补充输入

如果任务执行中遇到信息不足、权限不足、认证不足、边界不明确，远端 agent 可以进入 input-required 或 auth-required，而不是瞎猜着继续干。

第五步：继续任务或结束任务

Client agent 可以基于 taskId / contextId 继续推进同一任务，而不是从头新开一轮。

这条流程的本质，是把跨 Agent 协作从一次性请求，升级为有状态任务协作。

A2A 为什么需要 Streaming、Polling、Webhook / Push Notification

真实系统里，跨 Agent 任务经常很长。
如果只支持同步请求-响应，会有三个问题：

1. 用户体验差

你不可能让用户一直盯着一个同步请求等 2 分钟、5 分钟甚至更久。

2. 中间结果无法暴露

很多复杂任务中间就已经有价值，例如：

• 已完成第一轮信息收集；
• 已生成报告初稿；
• 已发现风险点；
• 已完成 70% 子任务。

如果没有 streaming 或异步状态更新，调用方无法利用这些中间进展。

3. 网络与前端连接不可靠

长任务执行期间，前端页面关闭、网络波动、连接断开都很常见。
协议必须支持：

• 重新订阅；
• 查询 task 状态；
• 接收推送；
• 从中断处恢复。

所以 A2A 对 streaming 和 async 的关注，不是高级特性，而是它把 Agent 当作长期协作对象的自然结果。

A2A v1.0 值得知道的更新点

如果想体现跟得上最新生态，可以在面试里提到一些 v1.0 之后的重要点。这里不要求你背协议字段，但应该知道方向：

1. v1.0 走向稳定与生产可用

这意味着 A2A 不再只是概念验证，而是开始强调：

• 稳定语义；
• 版本迁移；
• 多语言 SDK；
• 企业部署需求。

2. 交互协议有过迁移与升级

例如 Part、流式事件解析、Agent Card 解析、版本头、分页等都做了更明确的规范化。
你不一定需要背每个字段，但要知道：
A2A 正在从能跑通走向行为更可预测、更适合生产。

3. SDK 生态更完整

Python、Go、Java、JavaScript、.NET 等多语言 SDK 的稳定度提升，说明协议正在从少数示范项目进入更广泛采用阶段。
这个点在面试中很有用，因为它说明你知道一个协议是否能真正落地，不只看概念，还看 SDK 和生态。

A2A 和 MCP 怎么讲最清楚

推荐用下面这个对照说法：

维度	MCP	A2A
主要对象	工具、资源、提示	完整 Agent
关注点	接入外部能力	委托和协作任务
状态模型	相对轻	明确 task / artifact / async state
典型场景	检索、文件、数据库、业务系统连接	专家 Agent 协作、跨团队智能体协作
关系	Agent-to-tool / app-to-context	Agent-to-agent

你甚至可以直接说：
MCP 像 USB-C，A2A 像互联网协议。
前者让 Agent 接能力，后者让 Agent 彼此通信。

A2A 和普通微服务调用有什么差别

这是非常好的深入题。

普通微服务调用通常假设：

• 服务边界明确；
• 入参出参相对固定；
• 调用方知道对方 API；
• 返回值是业务响应；
• 不太强调继续任务的多轮语义。

而 A2A 假设：

• 对端是自治 Agent，不一定暴露内部细节；
• 能力往往以自然语言任务和 artifact 协作为主；
• 需要发现机制和能力描述；
• 需要状态化任务推进；
• 需要 input-required、auth-required 这类协作状态；
• 需要更强的异步与 streaming 语义。

所以 A2A 不是替代微服务，而是给智能代理之间的协作定义一个更贴合的语义层。

企业级 A2A 落地要注意什么

1. 身份与信任

跨组织或跨系统协作时，远端 Agent 不能只是一个 URL。
你需要知道：

• 它是谁；
• 其 Agent Card 是否可信；
• 是否经过签名验证；
• 是否在可信目录中；
• 该不该被授权访问某类任务。

2. 数据最小化

不要把本地全部上下文都丢给远端 Agent。
应该只发送完成当前子任务所需的最小数据集，并明确敏感字段脱敏或省略策略。

3. 全链路追踪

A2A 场景里，一个用户请求可能穿过多个 Agent。
因此必须有：

• correlation ID；
• taskId / contextId；
• trace / span；
• 请求者与被请求者身份信息；
• 明确的日志和审计记录。

4. 多租户与策略

远端 Agent 可能是多租户服务。
你必须确认：

• 是否按租户隔离任务；
• artifact 是否可能串租户；
• 调用额度和频率如何控制；
• 是否支持策略拒绝和审批。

5. 失败与补偿

如果远端 Agent 已经做了部分动作，又在后续失败，你要能知道：

• 失败发生在哪一阶段；
• 是否已产出部分 artifact；
• 是否需要补偿；
• 是否需要重新委托或人工接管。

常见使用模式

模式一：Supervisor + Expert Agents

主 Agent 负责理解用户问题和任务分解，把子任务交给不同专家 Agent，例如：

• 调研 Agent；
• 法务 Agent；
• 财务 Agent；
• 数据分析 Agent。

这是最典型的 A2A 使用方式。

模式二：跨组织能力协作

本公司 Agent 不直接调用外部企业内部系统，而是把任务交给合作方的 Agent，由对方在自己的安全边界内完成工作并返回 artifact。
这个模式很符合 A2A 的保留内部逻辑不暴露的理念。

模式三：人机混合协作

某个远端 Agent 在执行过程中进入 input-required，请求用户补充信息；用户补充后，再由本地 client agent 继续推进任务。
这类多轮、多主体协作，正是 A2A 比普通 API 更自然的地方。

常见误区

误区 1：A2A 就是把 HTTP API 换个名字

错误。
A2A 强调的是 Agent 的身份、发现、任务状态、artifact 和异步协作语义，而不是简单的接口封装。

误区 2：A2A 可以替代 MCP

错误。
MCP 更适合连接工具与上下文，A2A 更适合连接 Agent 与 Agent。它们经常同时使用。

误区 3：多 Agent 一定要用 A2A

不一定。
如果只是单项目内、单团队、少数子代理，而且完全受同一 runtime 控制，用框架内 handoff 或内部消息协议也可以。A2A 的价值在于开放互操作，不是所有多 Agent 场景都必须上。

误区 4：远端 Agent 一定要暴露内部推理过程

不需要。
A2A 的一个重要价值就是允许 Agent 以黑盒但可协作的方式存在，只暴露协作边界和任务结果，而不是内部工具链。

误区 5：Artifact 只是附件

太浅。
Artifact 是多 Agent 协作里的工作产物抽象，它承载的是持续演化的结果，而不是简单文件上传。

高频面试题与回答模板

1. 为什么 A2A 不能简单用 Tool Calling 代替？

标准回答：Tool Calling 更适合短、同步、边界清晰的动作。A2A 面向的是完整 Agent 的协作，它需要任务状态、artifact、多轮继续、异步更新和能力发现，这些都不是简单函数调用能自然表达的。

2. A2A 和 MCP 的区别是什么？

标准回答：MCP 解决 agent-to-tool / app-to-context 的标准接入问题，A2A 解决 agent-to-agent 的标准协作问题。前者接能力，后者协同工作。

3. Agent Card 的作用是什么？

标准回答：它是 Agent 的能力名片，帮助调用方在调用前知道对方是谁、会什么、支持什么交互能力，从而进行发现、选择和策略判断。

4. 为什么 Task 比 Message 更重要？

标准回答：Message 是一次通信，Task 是一件持续存在的工作。跨 Agent 协作的关键不是发出一句话，而是把任务在多个状态之间推进并跟踪产物和进度。

5. 为什么 A2A 强调 Artifact？

标准回答：因为 Agent 的协作结果经常不是一句文本，而是报告、文档、代码、表格等工作产物。只有把 Artifact 抽象成一等公民，才能支持版本、持续更新和后续协作。

6. A2A 最大的工程挑战是什么？

标准回答：信任和治理。因为远端是自治 Agent，你需要处理身份、授权、数据最小化、全链路追踪、多租户和失败恢复，而不是只关注一个请求有没有返回 200。

7. 什么场景下没必要上 A2A？

标准回答：单团队、单 runtime、内部子代理 handoff 就能解决的问题，未必需要上 A2A。A2A 更适合开放生态、多组织协作和跨框架互操作。

项目表达模板

在我们的系统里，主 Agent 负责理解用户需求和任务编排，但有些子任务是由独立专家 Agent 完成的，比如法务审查和财务核验。我们没有把这些专家能力简单包装成普通工具，因为它们本身有较长生命周期，会产出报告、需要补充资料、可能等待认证或审批，因此更适合按 Agent 任务协作建模。我们用标准化的 Agent Card 做能力发现，用 taskId 跟踪任务状态，用 artifact 管理中间和最终产物，用 streaming / polling 反馈进度；而专家 Agent 自己内部再通过 MCP 去连接知识库和业务系统。这样做的好处是，每个 Agent 可以保持自治和安全边界，同时整个系统仍然可追踪、可恢复、可治理。

小结

把 A2A 这篇压缩成四句话：

1. A2A 解决的是 Agent 与 Agent 的协作，而不是简单函数调用；
2. 它把 Agent 看成有身份、能力说明、任务状态、artifact 和异步生命周期的完整实体；
3. 它与 MCP 互补：MCP 接能力，A2A 协作 Agent；
4. 它最适合多 Agent、跨团队、跨组织和开放生态的协作场景。

如果你能围绕这四句话展开到任务状态、artifact、发现机制、异步交互和企业治理层面，A2A 这一题就已经答得很有层次。

延伸阅读与更新依据（官方为主）

• A2A Protocol Home
• A2A v1.0 Announcement
• A2A SDK
• A2A and MCP
• A2A Enterprise Features
• Google Blog: Interactions API and A2A

更新: 2026-04-02 15:43:15
原文: https://www.yuque.com/u63312805/df29bk/fol1g2gq0pbx8ipg