核心论点：数字员工间通信不是"随便发消息"，而是需要标准化的协议——异步任务、Webhook 订阅、上下文共享。A2A 协议让数字员工从"私有胶水"走向"标准协议"。

---

痛点场景

用户拍了张照片发来投诉：“手机屏幕有划痕，电池健康度只有 80%，说好的 99 新呢？” 售后助手收到投诉后需要判断：划痕算不算"99 新"标准？该赔多少钱？但如果售后助手自己不懂质检标准、也不知道市场定价，它只能把图片转给人工——三个数字员工各有所长，但没法协作。

质检 Agent 能分析图片质量，定价 Agent 懂补偿标准，售后 Agent 会写回复——但三者之间没有标准通信方式，各自的结果没法互相传递。

问题出在哪？数字员工间通信是"私有胶水"（每个数字员工自己实现一套消息格式和通信方式），改一个数字员工就要改所有相关的调用方。

这个案例暴露了 A2A 通信的核心矛盾：数字员工间需要标准的通信协议来传递推理结果，否则各自为政，互相等不到对方的输出。下面我们拆解常见的三种失败模式：

---

失败模式

❌ 硬编码调用：改一个数字员工要改所有调用方

很多企业硬编码数字员工间的调用：

售后 Agent 直接调用质检 Agent 的 assess_quality() Python 函数——如果质检参数变了（从 image_path 改为 image_base64），所有调用它的 Agent 都要改。问题：

• 耦合度高：一个数字员工的变动影响所有依赖它的数字员工
• 维护困难：每次接口变更都需要同步更新多个数字员工
• 扩展性差：新增数字员工需要修改所有相关的调用方代码

硬编码耦合度太高，那通过共享数据库来通信怎么样？

❌ 共享数据库：实时性差且难以追踪

有些企业通过共享数据库实现数字员工间通信：

质检 Agent 把检测结论写入数据库，定价 Agent 轮询数据库获取更新。问题：

• 实时性差：轮询间隔最少 10 秒，紧急问题无法及时响应
• 一致性问题：并发读写可能导致数据不一致（订单状态同时被两个数字员工修改）
• 难以追踪：无法追踪消息传递路径，出问题时难以定位根因

共享数据库实时性差，那有些企业干脆不做数字员工间通信，各干各的：

❌ 不做数字员工间通信：信息孤岛

有些企业不做数字员工间通信，每个数字员工独立工作：

质检 Agent 和定价 Agent 各自独立运作——质检检测出"屏幕划痕超过 99 新标准"，定价 Agent 不知道这个结论，直接按 99 新定价。问题：

• 重复劳动：多个数字员工重复查询同样的数据（都查订单状态）
• 信息不同步：不同数字员工的信息可能不一致，导致错误决策
• 无法协作：复杂任务（如退款）需要多个数字员工配合，但它们之间无法通信

---

解法框架

A2A 协议架构

从三种失败模式中我们总结出一个核心思路：数字员工间通信不能依赖私有实现，而是需要标准化的协议。基于此，设计了 A2A（Agent-to-Agent）通信协议：

A2A（Agent-to-Agent）协议定义了数字员工之间传递推理结果的标准方式。核心是异步任务模式——质检 Agent 提交检测结论给定价 Agent 后立即拿到一个任务 ID，不需要等定价 Agent 算完补偿方案再继续。定价 Agent 处理完成后通过回调通知质检 Agent，质检 Agent 也可以主动查询状态。这种设计避免了同步调用中的级联超时——一个 Agent 处理慢时不会拖垮调用方。

A2A 协议包含以下核心端点，支撑完整的数字员工间通信：

协议端点

功能	说明
提交任务	数字员工 A 向数字员工 B 提交异步任务，立即返回任务 ID
查询状态	用任务 ID 查询处理进度和结果
取消任务	取消尚未完成的任务
注册回调	任务完成时主动通知调用方
共享上下文	读取对话历史，避免每次从头沟通

---

实战案例：shop-agent 的 A2A 协议实现

在 shop-agent 项目中，我们实现了完整的 A2A 协议：

架构与流程

流程：数字员工 A 提交任务到 A2A 服务（①），服务派发给数字员工 B（②），B 完成后回调通知 A（③）。A 也可主动轮询进度 or 读取共享上下文（④）。整个流程异步非阻塞，不会因为 B 处理慢而拖垮 A。

理解了 A2A 协议设计和实战实现后，下面是落地时需要检查的事项：

---

落地检查清单

[ ] 梳理需要通信的数字员工（订单、售后、物流等）
[ ] 设计 A2A 协议端点（异步任务、Webhook、上下文共享）
[ ] 实现异步任务队列（支持超时、重试）
[ ] 实现 Webhook 订阅机制（支持回调通知）
[ ] 实现上下文共享（支持对话历史查询）
[ ] 配置任务超时和重试策略
[ ] 测试 Agent 间通信（是否按预期传递消息）
[ ] 建立通信监控（消息延迟、成功率、失败率）
[ ] 准备通信优化（根据监控数据调整）