目录一、前言Demo 正常上线即崩的隐性陷阱二、消息泛滥现象与真实业务案例案例 1文档解析多智能体业务案例 2消息环路死循环消息泛滥底层根因三、四类多智能体通信模式对比1.广播模式2.点对点模式3.消息总线模式4.事件订阅模式四、消息总线核心能力设计五、工程落地权衡思考六、结尾摘要多数开发者实现 Master‑Worker 多智能体架构之后本地 Demo 运行一切正常接入线上并发业务却遇到 Token 暴涨、上下文窗口持续膨胀、显存占用飙升、系统内部自发无限循环等隐性故障。很多人把问题归咎于大模型本身而真实根因往往来自多智能体通信层缺少工程约束。本文分析消息泛滥现象与成因对比四类通信模式介绍消息总线生产级设计思路并给出极简工程示例代码面向 Agent 开发者、大模型应用工程师、B 端 AI 架构师。硬核工程向建议收藏一、前言Demo 正常上线即崩的隐性陷阱前面专栏文章讨论过 Agent 从 Demo 走向生产的各类翻车问题也解析过指挥官‑Worker 多智能体架构。不少团队照搬这套架构完成开发单任务测试环境表现良好一旦提升并发规模系统性能出现断崖式退化。查看内部日志可以观察一类诡异现象各个智能体之间持续互发消息大量无效报文来回流转上下文不断膨胀Token 消耗成倍放大极端场景产生消息环路外部没有新请求系统内部仍在不停调用大模型。业内将该类现象称之为多智能体消息泛滥。Demo 环境很难复现该问题原因在于 Demo 大多是单任务、少量 Agent 实例整体消息总量有限资源消耗问题被掩盖。进入生产并发场景之后缺陷被彻底暴露。二、消息泛滥现象与真实业务案例消息泛滥主要分为三类典型表现无差别广播扩散、消息环路死循环、消息无过期累积。案例 1文档解析多智能体业务Master 指挥官负责任务拆分多个 Worker 智能体分别完成文档片段解析。简易实现中 Worker 处理完子任务后将结果广播给到全部 Agent 实例。Worker 数量较少时看不出开销当 Worker 扩容至 8‑12 个每一条子任务结果复制推送至所有 Agent上下文持续堆积整体 Token 消耗数倍上涨。案例 2消息环路死循环Master 下发查询指令Worker 返回异常报文。缺少路由管控逻辑异常消息被广播回 MasterMaster 误识别为全新业务请求再次发起一轮调度任务形成闭环自循环。业务侧没有新输入大模型调用持续不断。消息泛滥底层根因缺少中心化路由层很多简易 Master‑Worker 实现Agent 之间直接互相调用没有统一通信管控。通信接收对象交由 LLM 自行决策大模型容易幻觉出接收对象或者直接选择全局广播。路由调度逻辑应当固化在代码层不交由大模型处理。缺失消息生命周期管理消息没有 TTL 过期机制任务结束后历史消息不会清理旧报文持续驻留会话上下文。无消息去重过滤逻辑大模型输出不稳定容易产生重复报文原始消息直接投递重复消息反复流转。会话之间缺乏强隔离不同业务 session 消息互相干扰跨会话消息泄露叠加上下文压力。三、四类多智能体通信模式对比1.广播模式所有消息推送全部 Agent 实例。✅优点实现简单适合快速写 Demo❌缺点极易诱发消息泛滥并发场景资源爆炸生产环境尽量禁用无条件广播2.点对点模式消息明确指定发送方与接收方一对一定向投递。✅优点减少无关消息流转❌缺点Agent 实例规模变大之后维护对象关系复杂度提升一对多场景需要循环发送3.消息总线模式所有 Agent 不再直接互相通信全部消息投递至独立消息总线组件总线统一完成路由分发、过滤、去重、TTL 管控、熔断保护。✅优点通信逻辑解耦收敛业务 Agent 聚焦业务逻辑便于增加监控统计❌缺点引入新组件增加一部分开发工作量4.事件订阅模式Agent 根据事件类型完成订阅总线按照事件类型分发消息而非基于 Agent 实例 ID 分发。✅优点事件驱动新增 Agent 无需修改路由配置❌缺点前期需要完整梳理事件体系设计成本较高工程实践结论基于 Master‑Worker 架构做业务落地优先引入消息总线作为通信管控层。四、消息总线核心能力设计面向多智能体场景消息总线需要具备核心能力消息元数据message_id、session_id、sender、target_ids、event_type、payload、timestamp、ttl消息去重根据 message_id 拦截重复投递报文TTL 过期淘汰超期消息直接丢弃不再执行分发会话隔离不同 session 之间消息完全隔离路由策略支持点对点、指定目标列表关闭无条件全局广播 6. 会话级熔断统计单会话内部消息总量超过阈值停止分发抵御消息环路import time class AgentMessage: def __init__(self, message_id, session_id, sender, target_ids, event_type, payload, ttl10): self.message_id message_id self.session_id session_id self.sender sender self.target_ids target_ids self.event_type event_type self.payload payload self.ttl ttl self.create_ts time.time() class MessageBus: def __init__(self): self.msg_store {} self.session_msg_counter {} self.max_session_msg 50 def is_expire(self, msg:AgentMessage): return time.time() - msg.create_ts msg.ttl def is_duplicate(self, msg_id): return msg_id in self.msg_store def publish(self, msg:AgentMessage): if self.is_duplicate(msg.message_id): return [] cnt self.session_msg_counter.get(msg.session_id, 0) if cnt self.max_session_msg: return [] self.session_msg_counter[msg.session_id] cnt 1 self.msg_store[msg.message_id] msg if self.is_expire(msg): return [] return self.dispatch(msg) def dispatch(self, msg:AgentMessage): deliver [] for tid in msg.target_ids: deliver.append((tid, msg)) return deliver提示以上为内存版演示代码不可直接用于线上生产。真实业务场景建议替换 MQ 中间件补充持久化、告警、监控指标。业务层禁止 target_ids 为空实现全局广播逻辑。五、工程落地权衡思考路由调度逻辑尽量固化代码层不要完全交给大模型决策。大模型擅长业务推理但并不适合底层调度路由。按需演进小规模业务不必直接上马重型 MQ可以先实现内存消息管控做防护业务体量上涨之后再迁移专业消息中间件。建议增加监控指标单会话消息数量、去重丢弃消息数、TTL 过期丢弃消息数通过指标及时发现消息泛滥与环路异常。六、结尾绝大多数多智能体优化工作开发者会把重心放在业务逻辑、提示词调优。通信层往往属于容易被忽略的短板。Demo 阶段可以随意广播上线生产环境消息泛滥、消息环路会持续消耗 Token 与显存资源。想要 Master‑Worker 架构稳定运行消息总线通信管控是必不可少的防护组件。