多 Agent 之间如何通信？

核心回答

多 Agent 通信要先看运行边界和交接内容，不一定都需要网络消息：

1. 同一应用内，可以通过函数参数和返回值委派，也可以由图状态传递信息；每个 Agent 提交自己负责的结果，由编排器按规则合并。
2. 主 Agent 调用子 Agent，通常把目标、约束和必要上下文作为任务输入，子 Agent 返回结论、证据或产物引用。各自完整的内部对话不必互相复制。
3. 跨进程或跨服务，需要把任务和结果序列化，经 API、RPC 或队列传输；独立 Agent 服务之间需要统一能力发现和任务生命周期时，可以采用 A2A。

不论采用哪种方式，都要明确任务 ID、输入版本、状态、错误和结果归属，并处理依赖、超时、重复与晚到结果。消息 ID 用于识别一次消息，业务幂等键用于保护同一个业务操作，两者不能混用。

以研搜参考项目为例，主 Agent 通过框架的 task 工具委派三个自定义业务专家，结果返回主 Agent 汇总；当前链路并没有把专家拆成经消息队列通信的独立服务。

展开说明

1. 通信方式随状态归属和部署边界选择

简单的主从调用可以直接传参数、等待返回值。图编排则把跨节点需要的信息放进 State，节点读取输入并返回更新，边决定后续执行者。共享 State 不等于每个 Agent 随意修改同一个字典：要规定字段归属、更新方式和并行结果的合并规则，避免两个分支覆盖同一结论。

需要角色持续交换消息时，可以用信箱或消息中心，把信息投递给明确的接收者；事件驱动则适合发布“某项结果已就绪”等事件，由订阅者继续处理。信箱可以只在进程内实现，不能看见“消息”两个字就认为已经有网络传输和可靠存储。

跨进程以后，普通内存引用不再能直接使用，需要序列化契约。短任务可以通过请求响应接口完成；长任务可先返回任务标识，再查询或接收进度。队列能解耦生产和消费，但还要设计持久化、确认、重试和积压处理。跨团队、跨框架的 Agent 若采用 A2A，则通过 Agent Card、Message、Task 和 Artifact 约定对外协作，内部实现仍可各不相同。

2. Reason 和 Worker 之间实际交付什么

Reason 负责提出子目标或调整计划，Worker 负责完成具体子任务。可以约定一份任务输入，例如下面的设计示例：

{
  "task_id": "query-17",
  "input_version": 2,
  "goal": "查询指定商品上月销量",
  "inputs": { "product_id": "P100", "period": "2026-09" },
  "depends_on": [],
  "output_type": "sales_result"
}

实际还可以包含父任务、截止时间、允许的资源范围和结果验收条件。用户身份与可访问资源应由可信服务端绑定，不能只因为消息正文自称某个角色就获得权限。

Worker 的返回则包含同一任务及输入版本、执行状态、结果数据、证据或文件引用、缺失项和错误信息。Reason 判断结果是否满足目标，再继续计划；收到“已接收”只代表任务已被接收，不能当成已经完成。若 Worker 需要补充条件，应明确返回需要输入，而不是编造缺失参数。

自然语言仍可用于描述目标和解释结论，但关键字段应有 Schema 和业务校验。结构合法只能保证可以交接，结论是否正确还要核对证据、口径与时间。

3. 研搜参考代码怎样传递

主 Agent 注册三个自定义业务专家，通过 task 工具传入 subagent_type 和 description：前者选择已注册的专家，后者说明本次子任务。应用还会读取这些参数，把委派事件上报给前端。

项目安装的 Deep Agents 0.5.7 在委派时会创建子状态，把任务描述作为新的用户消息交给子代理，不直接复制主 Agent 的整段消息历史。子代理完成后，框架将其结果包装成与原调用 tool_call_id 对应的 ToolMessage，交回主 Agent；符合规则的共享状态字段也可能合并，子代理完整消息历史不会直接覆盖主对话。

因此，主 Agent 必须在委派描述中交代必要范围，不能假定专家已经读过所有对话。当前项目主要通过任务描述与专家回答交接；需要更严格的依赖管理和结果校验时，可以在现有委派边界上增加任务版本、依赖和结果 Schema。

模型和工具间的消息配对标识用于对应调用结果，不替代整个任务 ID。前端 WebSocket 进度推送也只是观察通道，不能替代 Agent 之间的任务状态和结果交付。

4. 重复、乱序和失败怎样处理

每条消息可以有独立 message_id，用于识别投递或去重；task_id 关联逻辑任务，输入版本区分条件更新，执行尝试标识区分重试。涉及创建工单、发送通知等副作用时，再使用与具体操作参数绑定的业务幂等键。重试可能产生新消息 ID，却仍然是同一个业务操作，不能仅凭新消息 ID 允许重复执行。

同一任务的状态变化应遵循明确顺序，可用序号或版本检查拒绝旧更新。输入从九月改成十月后，九月任务迟到的结果可以保留记录，但不能覆盖十月任务的当前结果。并行分支各提交产物，由指定归并者检查依赖和验收条件，再形成最终答案。

超时后先判断远端仍在运行、已失败还是结果未知；确认可以重试时采用有限重试，必要时查询原任务。队列消费确认也要与结果持久化协调，不能刚取出消息就宣布工作完成。取消信号和截止时间应向下传递，已经产生的外部操作则需要另外核对或补偿。

常见追问

大量文档、代码 Diff 怎样在 Agent 之间传？

小结果可以直接传，较大内容可以保存在受控产物存储中，交付摘要、位置引用、内容哈希或版本信息，下游按需读取。代码 Diff 还要关联仓库与比较版本，避免审查的是旧输入。摘要保留关键证据和未解决问题，不能只有“检查通过”而无法核对。

共享状态和消息队列怎么选？

同一应用、步骤耦合紧且状态由一个运行时管理时，参数返回值或图状态通常较直接。需要独立部署、异步处理和削峰时，可以使用队列，但要承担重复投递、任务持久化和一致性维护。两者也可以组合，不是所有 Agent 必须采用同一种通信载体。

多 Agent 通信一定要用 A2A 吗？

不一定。内部编排可以直接调用；稳定的远程能力也可以沿用已有业务 API。A2A 适合独立 Agent 服务之间需要统一能力说明、任务状态和产物交付的情况，但它不替系统决定任务拆分、结果验收或业务幂等策略。

对应教程

参考资料