别把多智能体协作做成接口拼盘：A2A任务闭环的设计方法

把几个聊天机器人接到同一条业务链上，并不会自动得到一个可靠的协作系统。最常见的失控情形是：调度者知道某个远端智能体“大概能办”，却不知道它接受什么输入、如何认证、任务是否已经开始、失败后能否恢复，也无法判断返回的是进度消息还是最终成果。A2A的价值正在这里——它把智能体之间的合作从随意拼接的接口，提升为可以发现、协商、追踪和验收的任务关系。

协作失败通常先败在“谁能做什么”

一个旅行规划任务可能同时需要交通、住宿、天气、地图和翻译能力。若把所有能力塞进同一个智能体，短期看似省事，长期却会出现提示词膨胀、权限边界模糊、组件无法独立升级等问题。拆成专门智能体以后，新的难点又变成能力发现：调度方不能只凭名称猜测对方是否适合，还要知道任务类型、输入格式、认证方式、输出形态以及是否支持流式更新。

因此，能力描述不应被当作宣传文案，而应是一份机器可读的协商入口。A2A用智能体名片公开元数据，调用方先读取这些信息，再决定是否建立任务。名片只能描述稳定能力，不能承诺动态库存、当前价格或即时可用性；后者应在任务执行阶段查询。把静态契约与动态业务数据分开，能减少缓存过期和错误路由。

能力名片需要回答的四个问题

设计名片时可以从调用者的决策过程反推字段。第一，它是谁以及由谁负责；第二，它能处理哪些明确任务；第三，通信与认证怎样建立；第四，它可能返回哪些内容形态。若任何一项只能由人工阅读文档才能确定，自动编排就仍然存在断点。

• 能力名称应落到可判定的动作，例如“查询库存”比“采购助手”更容易路由。
• 认证声明只公布支持的方案，不在元数据里放令牌、密钥或用户隐私。
• 输入与输出格式要包含版本，让新旧调用方能够在升级期共存。
• 不可用能力应及时撤下或标记状态，避免调度者反复发起必然失败的任务。

这一步的产物不是一张漂亮卡片，而是一份可自动测试的契约。测试环境应定期抓取名片，检查字段完整性、地址可达性与版本兼容性；生产调度器则应设置缓存期限和回退策略，避免发现服务短暂异常时整个业务停摆。

任务不是一次请求，而是一段可追踪的生命史

A2A把任务视为协作的基本单元。提交成功只代表远端已经接单，不代表业务已经完成。耗时操作可能经历已提交、处理中、等待补充信息、成功、失败或取消等状态。调用方必须保存任务标识，并以轮询、事件流或回调等方式接收变化，否则一旦连接断开，就会出现重复下单、进度丢失或结果无人领取。

1. 调度者生成幂等键与本地任务记录，再向匹配到的远端能力发起请求。
2. 远端先校验身份、权限和参数，拒绝不完整请求时给出机器可处理的原因。
3. 执行期间只发布必要进度，不把内部推理、密钥或原始敏感数据塞进消息。
4. 需要用户补充时，任务进入明确的等待状态，而不是用一段自然语言悄悄暂停。
5. 完成后返回交付物清单与校验信息，调度者验收成功才关闭本地流程。

状态机要与重试机制一起设计。网络超时并不等同于远端未执行，盲目重发可能产生两张订单。更稳妥的办法是用同一幂等键查询既有任务；只有得到“未创建”的确定回答后才重新提交。取消也不能只在界面上隐藏任务，必须明确远端是否接受取消、已产生的副作用如何处理。

消息负责沟通，交付物负责被使用

协作过程中会出现两类内容：消息用于提问、澄清和报告进度，交付物用于承载可被后续系统消费的结果。采购方案、生成文件、结构化表格或图片都更适合作为交付物存在，并附带媒体类型、版本、摘要与完整性校验。若把所有内容都压进一条聊天消息，下游就只能再次解析自然语言，可靠性会明显下降。

以设备采购为例，采购智能体可以先返回“预算已校验”的进度消息，最终再交付候选清单。调度者不应直接把第一项结果当作订单，而要检查价格是否在预算内、字段是否齐全、链接是否允许访问，并把需要人工批准的节点保留在人机流程中。协议提供运输轨道，业务规则仍由系统自己负责。

判断一条返回内容该放在哪里的简单办法是：它若需要被另一个程序稳定读取，就应成为结构化交付物；它若只帮助参与者理解当前进展，才适合作为消息。

与MCP、ANP的关系应从拓扑看，而不是争胜负

MCP更常用于模型应用连接工具、资源和提示模板，调用关系通常围绕客户端与服务端展开；A2A关注的是远端智能体之间如何委派并管理任务；ANP强调开放网络中的身份、语义描述与点对点连接。三者解决的问题层级并不相同，把它们简单排成替代关系，容易造成错误选型。

真实系统可以组合这些层次：一个旅行调度智能体通过A2A委派酒店任务，酒店智能体内部再通过工具协议读取库存；若参与方来自开放网络，则还需要额外的身份发现和信任机制。组合时应给每一层划清责任，避免同一份认证、重试和状态逻辑被重复实现。

上线前用故障演练验收协议价值

最有说服力的验收不是“两个演示智能体成功对话”，而是主动制造故障：能力名片暂时不可达、令牌过期、任务执行超时、回调重复、交付物损坏、用户中途取消。系统应能说明任务现在在哪里、是否产生副作用、由谁恢复，以及审计记录能否还原全过程。

最后还要收紧可观测性。日志里记录任务标识、状态迁移和耗时，但对参数与结果做脱敏；指标分别统计发现失败、认证失败、业务拒绝和执行异常；告警指向可行动的责任方。做到这些，A2A才不只是“智能体可以互相调用”的概念展示，而会成为一条能够承受重试、升级和权限审查的协作通道。

成熟的多智能体架构并不追求参与者越多越好，而追求每次委派都有明确契约、每次变化都有可追踪状态、每份结果都有验收依据。先把这三个闭环做实，再扩充智能体数量，系统复杂度才不会随着连接数一起失控。