A2A：把工作交给另一个 Agent，怎样保留清楚的任务边界

旅行助手可以把行程整理交给一个专业 Agent。这与调用一次机票查询工具不同：对方可能异步工作、中途询问信息，最后交回多个文件或结果。A2A 为这种协作提供共同结构。

如果对方收取费用，任务通信与商业约定仍要分开。“远端已接单”不应该悄悄变成“用户同意承担所有后续账单”。

资料边界： 本文于 2026 年 11 月 1 日核对 A2A 官方文档。以下为接入设计分析，没有调用远端 Agent、预订行程或执行支付。

发现阶段，读到的是服务声明

A2A 简介 将协议定位为 Agent 通信与协作标准。发现文档 描述了 Agent Card：其中包含技能、能力、服务端点和认证要求等信息，可通过约定路径、注册目录或直接配置发现。

对商业客户，读到这些信息只是评估的起点。声明擅长行程规划的服务，仍要明确本次任务范围、可接受输入、应交付的内容，以及是否收费。技能描述不适合直接承担交易约定的职责。

使用 A2A 的付费服务概念流程，非实测。范围约定与验收规则由应用自行负责。

任务有生命周期，不只是一个响应

任务生命周期文档 区分了即时消息与有状态任务。任务可以报告进度、等待输入或授权，并最终进入终态；上下文与任务标识帮助关联这些交互。

在行程场景里，如果缺少出行日期，应暂停依赖该信息的工作，而不是让调用方自行编造偏好。如果缺的是授权，也应进入适当的授权流程，不能把它当网络错误不断重试。

建议分别保存三种状态：

记录	回答的问题
远端任务状态	对方现在做到哪一步
商业与支付状态	约定了什么、批准了什么、是否扣费
客户验收状态	交回的内容是否满足要求

这是我们的接入设计建议。任务显示 completed，仍可能需要检查产物；任务显示 canceled，也不能直接证明费用已退回或预订已取消。

断开进度流，不要自动生成第二个任务

A2A 的异步操作文档 介绍了流式与推送更新。它们改善任务可观察性，但客户端断线、通知延迟时，应用仍需要恢复流程。

把控制权交回调用方前，先保存远端任务引用。重新连接后，通过所选实现支持的机制查询已有工作，不要把“我没收到更新”解释成“对方没开始做”。如果重新提交会再次收费，这个区别尤其重要。

建议的验收练习是：创建任务后主动断开客户端，检查系统是否接回原任务；另行测试重复通知，以及本地超时后才到达的产物。这些是设计检查项，不是某个 SDK 的测试报告。

产物能证明什么

产物是待检查的交付内容，不是可以改变客户端权限的新指令来源。一份行程文件可以包含建议、外部链接，也可能夹带试图重新指挥助手的文本。客户端应按原任务验收它，而不是把支付凭证或用户权限交给远端服务。

付费场景应保留足以关联任务、购买与产物的引用信息；不必把用户的私人行程复制进公开反馈记录。保留什么、保留多久、谁能访问，都需要应用另作决定。

与工具连接的区别

MCP 常用于暴露工具与上下文，A2A 用于与另一个 Agent 协作。这个区别有助于选择接口：一次确定性的账单状态查询可以是工具；多步骤的外部研究委托，更适合有明确生命周期的任务。但无论选哪种接口，授权要求都不会消失。

我们的判断是，当远端服务确实独立承担一段工作时，A2A 的价值更清楚。先定义任务边界与商业状态，再选择传输和 SDK。可继续查看 A2A 目录条目、MCP 与 ERC-8004 的证据层。