Multi Agent 协作通信设计：构建可靠的智能体分布式系统

Multi-Agent 系统的核心，不是简单地部署多个 Agent，而是让多个具备不同职责的智能体围绕同一目标稳定协作；一旦它们需要交换任务、状态、结果和控制信号，系统就具备了分布式系统的典型特征

消息可能重复、延迟、乱序或丢失，Agent 也可能超时、失败、重复执行，甚至出现循环调用；因此，通信层必须同时解决协作关系、消息协议、故障处理、状态管理和任务终止等问题

先定义 Agent 之间的协作关系：

在设计通信架构之前，应先明确每个 Agent 的职责边界，以及它们之间是固定依赖还是动态协作

例如，一个研究型系统可以拆分为任务规划 Agent、检索 Agent、分析 Agent、事实核验 Agent 和报告生成 Agent；规划 Agent 负责拆解目标，检索 Agent 负责获取资料，分析 Agent 负责归纳推理，核验 Agent 负责检查事实，最终由报告 Agent 组织输出

职责边界越清晰，消息协议越容易设计；如果多个 Agent 同时负责规划、执行和修改结果，就容易产生状态覆盖、责任不清和循环调用

四种主要通信模式：

点对点调用：

点对点调用是最直接的模式，一个 Agent 明确调用另一个 Agent，并等待对方返回结果

复制代码

Planner -> Researcher -> Analyst -> Writer

这种方式适合调用链固定、任务依赖明确的流程；它的优点是关系清晰、实现成本低，缺点是耦合较强，并且上游通常需要感知下游的接口和失败状态

当调用链较长时，还需要特别关注超时传播问题；如果每一层都设置独立超时，却没有统一的任务截止时间，整体执行时间可能远超预期

中心化编排：

中心化编排由一个 Orchestrator（编排器）统一管理任务分发、状态汇总和流程推进

复制代码

             -> Researcher
Orchestrator -> Analyst
             -> Writer

Orchestrator 可以根据任务状态决定下一步动作，也可以处理重试、超时、人工介入和结果合并；这种模式适合审批流、数据处理流和需要全局控制的复杂任务

它的主要风险是中心节点可能成为吞吐瓶颈或单点故障；生产环境通常需要让编排状态持久化，并支持故障恢复、水平扩展和任务接管

发布订阅：

发布订阅模式通过事件总线解耦消息生产者和消费者

复制代码

TaskCompleted
    |-> SummaryAgent
    |-> QualityAgent
    |-> MetricsService

一个 Agent 发布事件后，多个订阅者可以独立处理，不需要知道彼此的存在；这种模式适合通知、告警、并行分析和事件驱动流程

发布订阅并不意味着消息一定可靠；系统仍需设计消息持久化、消费确认、失败重试、死信队列和重复消费处理机制

共享状态：

共享状态模式让多个 Agent 通过数据库、任务看板、对象存储或共享上下文协作

复制代码

Agent A -> Shared State <- Agent B

这种方式适合长时间运行的任务，尤其是需要持续积累中间结果、人工修改和多轮协作的场景

共享状态的风险在于并发写入和状态污染；因此需要区分任务状态、业务数据和临时上下文，并通过版本号、乐观锁或状态机避免不同 Agent 相互覆盖结果

消息协议应当包含什么：

Agent 之间不应只传递一段自然语言，而应采用结构化消息协议；自然语言适合表达任务内容，结构化字段则负责保证可追踪性、可重试性和可维护性

复制代码

{
  "msgId": "msg_01J...",
  "traceId": "trace_01J...",
  "from": "planner",
  "to": "researcher",
  "type": "task.request",
  "timestamp": "2026-09-02T10:00:00Z",
  "schemaVersion": "1",
  "hopCount": 2,
  "deadline": "2026-09-02T10:00:30Z",
  "payload": {
    "task": "检索并归纳候选方案",
    "constraints": [
      "输出可验证来源",
      "优先使用近两年的资料"
    ]
  }
}

msgId 用于标识单条消息，主要承担去重和幂等控制；traceId 用于串联一次完整任务链路，便于查看一个任务经过了哪些 Agent；from 和 to 表示消息的发送方与接收方；type 用于区分任务、结果、错误、确认和控制消息；hopCount 用于限制消息转发深度；timestamp 用于判断消息新鲜度；schemaVersion 用于支持协议演进；deadline 用于约束任务的最终完成时间；payload 承载具体业务数据

常见的消息类型包括：

复制代码

task.request       请求执行任务
task.accepted      接收任务
task.progress      汇报进度
task.result        返回结果
task.failed        返回失败信息
task.cancel        取消任务
task.retry         请求重试
task.completed     标记任务完成

消息类型应尽量表达明确的状态变化，避免使用 "请处理一下" "结果可能有问题" 这类无法被程序可靠判断的模糊表达

可靠性设计：

幂等处理：

消息可能因为网络重试而被投递多次，因此接收方不能假设每条消息只到达一次

Agent 在执行任务前，可以根据 msgId 或业务幂等键查询处理记录；如果任务已经成功执行，则直接返回历史结果；如果任务正在执行，则返回处理中状态；如果上次执行失败，则根据失败类型决定是否允许再次执行

超时与重试：

重试不应成为默认动作，而应区分错误类型

网络临时故障、服务限流和依赖服务短暂不可用，通常可以采用指数退避重试；参数错误、权限不足和业务规则冲突，重试通常不会产生不同结果，应直接返回失败

复制代码

第 1 次重试：等待 1 秒
第 2 次重试：等待 2 秒
第 3 次重试：等待 4 秒

重试还应设置最大次数和截止时间，并为每次尝试生成独立的执行记录，否则多个 Agent 之间可能形成重试风暴

失败隔离：

一个 Agent 的失败不应拖垮整个系统；编排器需要区分可恢复失败、不可恢复失败和部分成功

例如，三个检索 Agent 中有一个超时，系统可以保留其他两个 Agent 的结果，并将缺失信息标记为待补充；但如果事实核验 Agent 判定关键结论不可信，就不应直接生成最终报告

死信与人工介入：

经过多次重试仍无法处理的消息，应进入死信队列，并保留完整的错误上下文、原始消息和执行记录

对于涉及资金、权限、医疗、法律或生产系统变更的任务，还应设置人工确认节点；Agent 可以提出建议，但不应在缺乏授权的情况下自动完成高风险操作

状态机比布尔值更可靠：

复杂任务不应只用 isCompleted 表示状态，而应定义明确的状态机

复制代码

PENDING 待执行
  -> RUNNING 运行中
  -> WAITING_DEPENDENCY 等待依赖
  -> SUCCEEDED 成功结束

RUNNING 运行中
  -> RETRYING 重试中
  -> FAILED 执行失败
  -> CANCELLED 被取消

每次状态变化都应记录操作者、时间、原因和关联消息；这样既能恢复中断任务，也能还原任务为什么进入当前状态

状态机还可以防止非法转换，例如已经完成的任务不能重新进入执行状态，已经取消的任务不能被普通重试逻辑重新拉起

必须设计终止条件：

多 Agent 系统最容易出现的问题之一是循环调用

复制代码

Planner -> Executor -> Planner -> Executor

为了避免任务无限运行，至少应设置最大跳数、最大重试次数、任务截止时间、Token 或费用预算，以及明确的成功和失败状态

当 hopCount 超过阈值时，系统应拒绝继续转发；当任务超过截止时间时，编排器应汇总已有结果并输出部分完成状态；当预算耗尽时，系统应停止调用模型，并保存当前上下文供后续处理

终止条件必须由系统控制，不能完全依赖 Agent 自己判断；模型可能误判任务是否完成，也可能因为上下文变化不断提出新的子任务

可观测性是协作系统的基础：

多 Agent 系统发生问题时，单看最终输出通常无法定位原因；因此需要围绕 traceId 建立完整链路

至少应记录以下信息：

每条消息的发送和接收时间
Agent 的输入、输出和模型版本
工具调用、外部依赖和返回结果
Token 消耗、执行耗时和重试次数
状态转换和失败原因
最终结果由哪些中间结果合并而来

通过这些数据，可以回答 "哪个 Agent 变慢了" "哪条消息被重复消费了" "失败发生在模型、工具还是消息队列" "最终结论依赖了哪些来源"等问题

生产系统还应对日志中的用户隐私、密钥和业务敏感信息进行脱敏，避免为了排查问题而扩大数据暴露范围

如何组合这些模式：

实际系统很少只使用一种通信模式，通常会采用分层组合

例如，一个研究报告系统可以使用中心化编排管理整体生命周期；编排器通过点对点调用分发核心任务；检索结果通过发布订阅通知多个分析 Agent；共享状态则用于保存中间文档、引用和人工修订内容

复制代码

                 -> RetrievalAgent
Orchestrator ----> AnalysisAgent
       |         -> VerificationAgent
       |
       -> Shared State
              |
              -> ReportAgent

这种组合能够同时获得全局控制、局部解耦和状态持久化能力，但也会增加系统复杂度；设计时应优先保证职责边界清楚、协议统一和故障可追踪，再逐步引入异步化和并行化

结语：

Multi-Agent 通信的核心，不是让更多智能体互相发送消息，而是建立一套可理解、可追踪、可恢复、可终止的协作协议

可靠的系统通常具备清晰的 Agent 职责、合适的通信模式、结构化消息、幂等和重试机制、持久化状态、明确终止条件，以及覆盖全链路的可观测性