1. 从一场信令风暴说起所有设备都在“正确工作”系统却崩了几年前我还在做通信网络维护时经历过一次真正让我失眠的故障。节假日的业务高峰话务量比平时翻了好几倍核心网突然开始大面积丢消息。我盯着监控大屏发现每一台信令节点上报的状态全部正常CPU没有跑满内存没有告警链路也没有中断。但用户侧就是打不通电话、发不出短信。那种感觉非常诡异整个系统的每一个零件都是好的系统本身却已经死了。后来我转型到AI应用开发开始研究多Agent协作架构测试过几个主流框架也自研过编排层。第一个让我头皮发麻的瞬间是在一个内部Demo里三个Agent因为互相等待对方的确认消息进入了循环调用日志涨得飞快消息队列直接被打爆。那一刻我脑子里立刻弹出当年信令风暴的监控大屏。把Agent类比成信令节点把任务消息类比成信令——每台设备都安全连起来却崩了这句话在通信时代是血泪教训在多Agent时代又重新开始刷存在感。1.1 事后复盘谁都没有犯错但系统错了那次故障的复盘会开了一整天。最终结论特别简单又特别扎心一台边缘节点因为硬件隐患重启周围的设备按照协议自动把话务转移到它的邻居邻居负载升高开始丢包丢包触发重试重试信令又涌回原节点。每一台设备都在严格执行自己的运行规程没有任何一个模块做错了但整个网络在十分钟内陷入瘫痪。这就是信令网里最著名的“信令风暴”本质上是局部正确行为在全局尺度上演化成了集体崩溃。这类故障最折磨人的地方在于事后看每个环节都合情合理。设备确实该重启后恢复邻居确实该接收转接话务超时确实该重发消息。单独的任何一个动作都没有问题组合起来却形成了一条灾难链路。通信行业为此交了三十年学费从七号信令系统到IP化改造围绕的核心问题始终只有一个怎么防止局部的合理行为在全局上变成灾难。1.2 让我警觉的是多Agent系统正在重演这一段历史真正让我把这两个领域联系起来是在一次Agent联调测试中。一个负责数据清洗的Agent调用另一个负责入库的Agent入库Agent因为数据库连接数达到上限而超时数据清洗Agent收到超时后立刻重试重试的请求又占掉更多数据库连接紧接着第三个Agent也开始尝试写入同一条数据。日志里全是重试和超时和当年信令风暴里的重试风暴几乎一模一样。我在那一刻才意识到多Agent系统表面上是一个个“聪明”的智能体在做协作实际上从系统论的角度看它们就是一张新的信令网。每个Agent由大模型驱动模型本身能力很强单看每个任务执行得都很好。可是一旦进入协作场景消息交互、任务依赖、超时重试这些底层机制开始发挥作用通信系统踩过的坑AI系统一个都不会少踩。2. 信令网三十年局部可靠性与全局脆弱性的博弈2.1 七号信令系统为什么“每台设备都安全”要理解这个问题得先了解信令网的基本设计。传统通信网络里话音、短信这类业务数据走用户面控制指令则走独立的信令面也就是七号信令系统SS7。这种设计把控制与承载分开了好处很明显控制指令可以用高可靠的专用链路传递业务再怎么波动信令网都有一个相对稳定的控制通道。在这个体系里每一个信令节点都被设计得非常“坚固”。硬件层面有双备份、双链路软件层面有故障自检、主备倒换、异常隔离单机可靠性做到了五个九甚至更高。电信设备厂商做了大量容灾设计目的就是保证任何一台设备单独看都不容易出问题。但问题恰恰出在这里。当系统最重视“单机不故障”的时候系统性的、全局性的故障往往就从另一个方向冒出来。单机安全是通过规则和冗余实现的全局安全却需要面对节点之间的依赖关系、流量分布、失败传播路径。这两件事需要的能力完全不同。通信行业发展三十年真正难的不是造出一台可靠的交换机而是让几百上千台交换机在网络拓扑中协同工作时不出系统性事故。2.2 单机五个九整体可能连两个九都不到这里有一笔账值得算。假设一个系统由N个独立节点串联组成每个节点单机可靠性是R等于99.999%如果所有节点都必须在线系统才能可用那系统整体可靠性就是R的N次方。当N等于100时系统的整体可靠性大约是99.9%当N等于1000时就掉到大约99%。这时候再叠加节点之间的依赖和联锁关系情况只会更差。这个计算告诉我们一个反直觉的事实局部可靠性和全局可靠性之间隔着一条组合爆炸的鸿沟。你不能指望通过把每一台设备做到极度可靠就得到一套无限接近100%可用的系统。节点数量越多节点间交互越复杂系统性风险就越高单机层面的努力就越显得杯水车薪。信令风暴之所以能瘫痪整个网络正是因为节点之间的交互链路被打满了。单个节点再可靠也扛不住所有邻节点同时向它发起重试请求。全局规模带来的压力会轻而易举击穿单机的任何冗余设计。所以在分布式的世界里全局视角不是锦上添花而是安全底线。2.3 信令风暴的四个经典成因回头看信令网三十年的故障史真正导致全网崩溃的成因其实很集中我把它归纳为四类。第一类是重试风暴。某个节点失败后周边节点按照协议自动重发消息重发进一步加剧拥塞拥塞导致更多超时超时又触发更多重试形成正反馈。第二类是负载转移闭环。节点故障后周边节点按照负荷分担策略把压力转给某一个健康节点所有压力集中过去该节点被压垮继续向外转移压力形成跨节点连锁反应。第三类是控制面资源被抢占。正常业务量高峰时大量信令消息堆积在控制面处理队列里而信令网本身也是靠CPU和内存工作的处理不过来就排队排队就超时超时又引发重试控制面资源在无效消息上被大量消耗。第四类是状态不一致。节点间维护的全局状态出现分裂同一个用户或同一条事务在不同节点上看到了不同结果导致指令冲突、资源竞争。这四个成因单独看都是相对基础的分布式系统问题。麻烦在于它们在真实系统里往往同时发生互相放大。多Agent系统如今面临的协作故障拆开来看几乎可以一一对应到这四个成因上。3. 多Agent重演历史单Agent很强协作却“信令风暴”频发3.1 Agent协作与信令网的同构关系把多Agent系统和信令网做一次结构对比你会发现两者惊人地同构。我整理了这样一张对照表信令网概念多Agent系统对应信令节点Agent实例信令链路Agent间消息通道呼叫业务流程任务分解与执行流程重试与拥塞控制LLM调用超时重试、工具调用重试信令转接点STP调度器、编排器、Supervisor Agent网管系统Agent监控与追踪平台信令路由表任务路由与Agent寻址配置全局状态数据库共享上下文或状态存储这张表放到一起很多问题就清楚了。Agent在单点层面的能力提升解决的是“单个节点会不会出错”的问题而多Agent协作真正要面对的是“节点之间怎么协调才能不崩溃”的问题。当年信令网无法靠单机可靠性解决系统性崩溃今天多Agent系统同样无法靠单个Agent的智能水平解决协作失控。3.2 案例一Agent互相等待死锁我在测试一个多Agent流程时遇到过典型的死锁。一个Agent负责收集需求另一个Agent负责生成方案还有一个Agent负责最终审批。收集需求的Agent把任务发送给生成方案的Agent之后按规则等待对方的完成信号生成方案的Agent又认为需要等审批Agent先给出一份标准模板审批Agent的逻辑则是必须有完整方案才能开始工作。三个Agent形成了循环等待谁都永远等不到自己需要的那个消息。这类问题在信令网里对应的是信令路由的死循环。当年靠设置跳数上限、路由环检测来解决。在多Agent系统里很多编排框架还没有内置这样的环检测机制。没有环检测死锁就只能靠全局超时兜底而如果全局超时设置得不合理又会触发另一个问题——超时后的无限重试。3.3 案例二Agent重试风暴打垮工具服务另一个更常见也更疼的问题是重试风暴。某个Agent调用第三方工具接口接口因为自身负载过高开始返回超时。Agent的容错逻辑通常很简单失败就重试重试还是失败就再试。如果多个Agent同时调用同一个工具每个Agent都在做指数级或固定间隔的重试工具服务面对的就是信令网里同样的正反馈循环。我有一次在联调环境里就亲眼看到一个并不复杂的Agent协作任务因为某个上游API延迟升高导致十几个Agent实例同时开始疯狂重试把下游服务彻底打崩。最讽刺的是如果当时所有Agent都停下什么都不做下游服务本来可以在几秒钟内自行恢复。但Agent不会停它们只会按照预设的容错逻辑继续重试于是恢复时间被无限拉长。这和信令风暴里的重试机制几乎完全一样。通信系统最后总结出的经验是重试必须有上限、必须有退避、必须加随机抖动而多Agent系统里的重试逻辑很多时候还停留在最原始的“失败就再来一次”的阶段。3.4 案例三全局状态不一致导致重复执行还有一个典型的翻车场景来自状态管理。多个Agent共享一份上下文或工作区A和B同时读取到一条记录的状态是“未处理”于是两个Agent都开始处理这条记录。处理完成后A把状态更新为“已处理”B也把自己处理的结果写入结果覆盖了A的成果。更严重的情况是B的处理动作本身是不可重入的比如扣减库存、发送通知、写入账单重复执行就会产生实打实的业务事故。信令网对应的问题叫做“消息重复投递”和“事务状态不一致”当年的解决方案是给每条消息分配唯一的信令点编码和序列号在收端做去重配合事务状态机保证同一事务只执行一次。多Agent系统里的Agent之间传递的往往是自然语言任务天然缺少这种唯一消息ID和幂等机制。于是同样的任务被重复处理成了多Agent协作里非常高频的问题。4. 把学费变经验给多Agent系统的七条防崩设计原则信令网三十年的学费核心成果其实可以沉淀成几条非常朴素的设计原则。当年做通信系统时这些原则是写在规范文档里的现在做多Agent系统我建议把它们当作硬性设计要求直接引入架构设计。4.1 原则一全局控制节点必须存在且不允许无限重试多Agent协作不能只有一群平级Agent互相通信必须有明确的全局控制节点或者叫Supervisor、调度器、协调者。这个节点的职责和信令网里的STP一样负责统筹任务分配、流量控制、状态仲裁。当协作规模超过三五个Agent时去掉这个控制节点整个系统就回到了无政府状态死锁和重试风暴只是时间问题。控制节点同时要承担重试上限的管理。我在系统里通常会把每个Agent的重试次数写死默认不超过三次。重试策略必须由全局配置统一下发不允许每个Agent自己决定要不要重试、重试几次。这是阻断重试风暴最关键的一步。4.2 原则二指数退避加随机抖动把重试风暴扼杀在摇篮里一旦确认需要重试必须使用指数退避算法而且一定要加入随机抖动。指数退避让重试间隔随次数翻倍随机抖动则避免多个Agent在同一时刻发起重试把集体性的请求洪峰打散成零零散散的请求。这是我做通信系统时验证过无数次的做法用在多Agent协作里同样有效。import random import time def retry_with_backoff(agent_call, max_retries3, base_delay0.5): for attempt in range(max_retries): try: return agent_call() except Exception as exc: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.5) time.sleep(delay)这段逻辑虽然简单但在真实系统里带来的改善非常明显。我去掉随机抖动和保留随机抖动做过对比测试没有抖动时多个Agent的重试请求往往扎堆到达下游服务持续处于过载状态加上抖动后请求时间轴被打散下游服务有了喘息空间整体恢复速度快了好几倍。4.3 原则三扇出上限与并发闸门一个Agent触发子任务时能同时通知多少个子Agent必须有明确上限。我见过很多Agent编排设计一个主任务被广播给几十个Agent并行处理看起来效率很高实际上任何一个环节出问题几十个Agent同时重试系统瞬间就被打爆。建议给每个任务的扇出数量设上限超过上限的任务进入排队队列。在Agent编排框架里做一层并发闸门类似信号量的作用限制同一时间进入执行阶段的Agent数量。信令网里的负荷控制机制就是这么做的排队限流丢弃超龄消息保护核心节点不被无效消息淹没。4.4 原则四全局上下文用版本号和分布式锁状态变更留痕共享上下文是很多Agent协作方案的默认做法但这恰恰是状态不一致的温床。我的经验是对共享状态的每一次读取和写入都要带上版本号控制简单说就是CAS机制更新前检查当前版本是否和自己读取时一致不一致就重新读取再决策。对于关键业务动作比如扣库存、改订单状态、发送消息还要配合分布式锁或者唯一任务ID的幂等设计。同一个任务ID只允许执行一次重复调用时直接返回第一次的执行结果。这套机制通信行业叫“消息去重”在Agent系统里就是幂等保护的落地。4.5 原则五Agent必须是幂等的因为只要有网络只要有重试重复请求就一定会发生。所以每一个Agent对外提供的操作能力都必须是幂等的。所谓幂等就是同一个请求执行一次和执行一百次对系统状态的影响完全一样。比如一个写操作执行前先检查目标记录是否已经存在处理标记如果已经标记为处理完成就直接返回成功。这比在实现里反复判断“是否已经执行过”要可靠得多。把幂等设计写在Agent的职责定义里而不只是依赖上层编排去避免重复调用这个习惯能解决大量隐蔽的线上问题。4.6 原则六熔断器与容量隔离多Agent系统上游依赖的LLM接口、工具服务、数据库都有可能因为Agent的集体行为而过载。对这些依赖必须配置熔断器当某个依赖的失败率达到阈值比如连续失败超过10次熔断器打开后续调用直接快速失败不再真正请求依赖服务。依赖服务恢复后熔断器半开状态放一个试探请求成功后才关闭熔断器恢复流量。容量隔离也很重要。把不同优先级任务的Agent调用路径隔离开核心交易链路和批处理任务用不同的连接池和并发限额。这样即使批处理任务把某个工具打满核心链路也不受影响。这和信令网把重要信令与其他信令分开传输的思路完全一致。4.7 原则七可观测性——像信令网网管一样监控Agent信令网能快速定位故障靠的是完备的网管系统。多Agent系统也必须配套建设监控追踪能力不能等到日志刷屏再去翻。建议至少采集如下指标Agent消息队列长度、单次任务处理延迟、重试次数分布、下游依赖错误率、Agent间等待死锁检测、上下文版本冲突次数。给每一次Agent协作分配全局唯一的Trace ID所有Agent在日志中带上这个ID。排查问题的时候按Trace ID把一次完整协作链路串起来就能快速定位是哪个环节超时、哪个Agent引发了重试风暴。没有Trace ID的多Agent系统一旦出现问题就等着在成堆的日志里慢慢翻吧。5. 多Agent协作翻车现场排障实录与避坑清单5.1 排障实录一日志刷屏根本无法定位某个Agent任务跑着跑着日志系统突然告警每分钟新增几百万行日志。我登录日志平台一看全是同一个报错的重复输出不同Agent实例在同一时间段内疯狂重试同一个失败的工具调用。最初的问题是下游API短暂抖动但Agent的重试策略把它放大成了系统级事故。排查思路是先找到发起重试的责任链。我用Trace ID筛选出第一次失败的请求顺着调用链找到第一个开始重试的Agent再检查它的重试配置。定位后发现这个Agent的重试次数是无限次而且重试间隔是固定一秒。把所有Agent的重试配置统一改成有限次数加指数退避加随机抖动后问题消失。这个排障过程和当年在信令网里找重试源头一模一样。5.2 排障实录二Agent调用链出现循环依赖一次联调里发现两个Agent在互相持续调用谁都停不下来。A调用B查询信息B为了完成查询又回头调用A提供的接口而A的接口实现里又依赖B的查询结果。两个Agent的调用环没有终止条件消息在生产者和消费者之间来回弹跳直到触发队列上限。处理方式是先通过Trace ID确认调用环的存在在编排框架中加入最大跳数限制比如单个Agent最多转发消息三次达到上限直接终止并报错。更彻底的方案是重新设计两个Agent的职责边界把交叉依赖抽到一个共享服务下让A和B都不再直接调用对方。这跟信令路由环路检测的思路完全一致。5.3 常见问题速查表故障现象可能原因处理方法多个Agent互相等待任务一直不结束Agent职责存在循环依赖设置全局超时定位调用环并重新设计职责边界下游服务被大量重试请求打满重试策略无上限或间隔过短配置有限重试次数启用指数退避加随机抖动同一业务数据被多个Agent重复修改共享上下文无版本控制引入版本号CAS机制关键操作用唯一任务ID做幂等LLM接口调用费用异常飙升Agent循环调用或过度重试增加调用次数监控和熔断器设置单任务调用预算某个Agent负载过高其他Agent空闲任务分配策略不均衡检查扇出上限和任务路由增加动态负载反馈系统恢复后再次波动大量Agent同时用固定周期重试重试计划加入随机抖动避免请求同时到达5.4 关于多Agent框架与部署的一点实操笔记现在很多新一代Agent编排框架已经开始意识到这些问题。以AgentScope 2.0这类框架为例配置多Agent调用时除了定义Agent本身的模型、提示词和工具更重要的是把协调模式、消息路由、超时和重试参数单独抽出来配置。我建议把这类框架的配置理解为“设计一张信令路由表”而不是简单的Agent列表。你在配置里写清楚谁跟谁能通信、消息走什么通道、失败怎么办就相当于给系统做了拓扑规划。实际部署多Agent服务时建议采用多容器拆分的模式。比如用一个容器跑Agent运行引擎一个容器跑WebUI管理界面一个容器跑工具服务和状态存储按域名把流量在容器间做路由。我之前用三条命令完成了这套部署第一条拉起状态存储和工具服务第二条启动Agent运行引擎并连接状态存储第三条启动WebUI并指向Agent引擎。容器数量少依赖关系简单排查问题时头脑也清晰。大规模协作场景再按Agent类型继续拆分容器但原则不变控制面逻辑集中承载面逻辑隔离。部署完成后第一时间验证的应该是故障场景而不是正常流程。故意让一个Agent超时观察其他Agent的反应故意让下游工具抛错观察重试是否按预期退避。通信系统上线前一定做容灾演练Agent系统同样应该这样测不要在线上让系统自己考试。提示多Agent系统上线前请务必做一个“故障注入测试清单”至少覆盖超时、重试、死锁、重复执行、下游服务熔断这五个场景。这个习惯来自信令网运维的容灾演练传统能帮你提前暴露80%以上的协作稳定性问题。我个人在实际踩坑中最深刻的体会是多Agent系统的崩溃几乎从来不是某一个Agent不够聪明而是Agent之间的交互机制缺少通信系统早就验证过的底线设计。三十年前信令网用惨痛教训换来的退避重试、全局控制、幂等保护、可观测性现在到了多Agent系统该交作业的时候。别再让学费白交把这些原则写进你的Agent架构里比给Agent换更强大的模型更值得优先做。
1. 从一场信令风暴说起所有设备都在“正确工作”系统却崩了几年前我还在做通信网络维护时经历过一次真正让我失眠的故障。节假日的业务高峰话务量比平时翻了好几倍核心网突然开始大面积丢消息。我盯着监控大屏发现每一台信令节点上报的状态全部正常CPU没有跑满内存没有告警链路也没有中断。但用户侧就是打不通电话、发不出短信。那种感觉非常诡异整个系统的每一个零件都是好的系统本身却已经死了。后来我转型到AI应用开发开始研究多Agent协作架构测试过几个主流框架也自研过编排层。第一个让我头皮发麻的瞬间是在一个内部Demo里三个Agent因为互相等待对方的确认消息进入了循环调用日志涨得飞快消息队列直接被打爆。那一刻我脑子里立刻弹出当年信令风暴的监控大屏。把Agent类比成信令节点把任务消息类比成信令——每台设备都安全连起来却崩了这句话在通信时代是血泪教训在多Agent时代又重新开始刷存在感。1.1 事后复盘谁都没有犯错但系统错了那次故障的复盘会开了一整天。最终结论特别简单又特别扎心一台边缘节点因为硬件隐患重启周围的设备按照协议自动把话务转移到它的邻居邻居负载升高开始丢包丢包触发重试重试信令又涌回原节点。每一台设备都在严格执行自己的运行规程没有任何一个模块做错了但整个网络在十分钟内陷入瘫痪。这就是信令网里最著名的“信令风暴”本质上是局部正确行为在全局尺度上演化成了集体崩溃。这类故障最折磨人的地方在于事后看每个环节都合情合理。设备确实该重启后恢复邻居确实该接收转接话务超时确实该重发消息。单独的任何一个动作都没有问题组合起来却形成了一条灾难链路。通信行业为此交了三十年学费从七号信令系统到IP化改造围绕的核心问题始终只有一个怎么防止局部的合理行为在全局上变成灾难。1.2 让我警觉的是多Agent系统正在重演这一段历史真正让我把这两个领域联系起来是在一次Agent联调测试中。一个负责数据清洗的Agent调用另一个负责入库的Agent入库Agent因为数据库连接数达到上限而超时数据清洗Agent收到超时后立刻重试重试的请求又占掉更多数据库连接紧接着第三个Agent也开始尝试写入同一条数据。日志里全是重试和超时和当年信令风暴里的重试风暴几乎一模一样。我在那一刻才意识到多Agent系统表面上是一个个“聪明”的智能体在做协作实际上从系统论的角度看它们就是一张新的信令网。每个Agent由大模型驱动模型本身能力很强单看每个任务执行得都很好。可是一旦进入协作场景消息交互、任务依赖、超时重试这些底层机制开始发挥作用通信系统踩过的坑AI系统一个都不会少踩。2. 信令网三十年局部可靠性与全局脆弱性的博弈2.1 七号信令系统为什么“每台设备都安全”要理解这个问题得先了解信令网的基本设计。传统通信网络里话音、短信这类业务数据走用户面控制指令则走独立的信令面也就是七号信令系统SS7。这种设计把控制与承载分开了好处很明显控制指令可以用高可靠的专用链路传递业务再怎么波动信令网都有一个相对稳定的控制通道。在这个体系里每一个信令节点都被设计得非常“坚固”。硬件层面有双备份、双链路软件层面有故障自检、主备倒换、异常隔离单机可靠性做到了五个九甚至更高。电信设备厂商做了大量容灾设计目的就是保证任何一台设备单独看都不容易出问题。但问题恰恰出在这里。当系统最重视“单机不故障”的时候系统性的、全局性的故障往往就从另一个方向冒出来。单机安全是通过规则和冗余实现的全局安全却需要面对节点之间的依赖关系、流量分布、失败传播路径。这两件事需要的能力完全不同。通信行业发展三十年真正难的不是造出一台可靠的交换机而是让几百上千台交换机在网络拓扑中协同工作时不出系统性事故。2.2 单机五个九整体可能连两个九都不到这里有一笔账值得算。假设一个系统由N个独立节点串联组成每个节点单机可靠性是R等于99.999%如果所有节点都必须在线系统才能可用那系统整体可靠性就是R的N次方。当N等于100时系统的整体可靠性大约是99.9%当N等于1000时就掉到大约99%。这时候再叠加节点之间的依赖和联锁关系情况只会更差。这个计算告诉我们一个反直觉的事实局部可靠性和全局可靠性之间隔着一条组合爆炸的鸿沟。你不能指望通过把每一台设备做到极度可靠就得到一套无限接近100%可用的系统。节点数量越多节点间交互越复杂系统性风险就越高单机层面的努力就越显得杯水车薪。信令风暴之所以能瘫痪整个网络正是因为节点之间的交互链路被打满了。单个节点再可靠也扛不住所有邻节点同时向它发起重试请求。全局规模带来的压力会轻而易举击穿单机的任何冗余设计。所以在分布式的世界里全局视角不是锦上添花而是安全底线。2.3 信令风暴的四个经典成因回头看信令网三十年的故障史真正导致全网崩溃的成因其实很集中我把它归纳为四类。第一类是重试风暴。某个节点失败后周边节点按照协议自动重发消息重发进一步加剧拥塞拥塞导致更多超时超时又触发更多重试形成正反馈。第二类是负载转移闭环。节点故障后周边节点按照负荷分担策略把压力转给某一个健康节点所有压力集中过去该节点被压垮继续向外转移压力形成跨节点连锁反应。第三类是控制面资源被抢占。正常业务量高峰时大量信令消息堆积在控制面处理队列里而信令网本身也是靠CPU和内存工作的处理不过来就排队排队就超时超时又引发重试控制面资源在无效消息上被大量消耗。第四类是状态不一致。节点间维护的全局状态出现分裂同一个用户或同一条事务在不同节点上看到了不同结果导致指令冲突、资源竞争。这四个成因单独看都是相对基础的分布式系统问题。麻烦在于它们在真实系统里往往同时发生互相放大。多Agent系统如今面临的协作故障拆开来看几乎可以一一对应到这四个成因上。3. 多Agent重演历史单Agent很强协作却“信令风暴”频发3.1 Agent协作与信令网的同构关系把多Agent系统和信令网做一次结构对比你会发现两者惊人地同构。我整理了这样一张对照表信令网概念多Agent系统对应信令节点Agent实例信令链路Agent间消息通道呼叫业务流程任务分解与执行流程重试与拥塞控制LLM调用超时重试、工具调用重试信令转接点STP调度器、编排器、Supervisor Agent网管系统Agent监控与追踪平台信令路由表任务路由与Agent寻址配置全局状态数据库共享上下文或状态存储这张表放到一起很多问题就清楚了。Agent在单点层面的能力提升解决的是“单个节点会不会出错”的问题而多Agent协作真正要面对的是“节点之间怎么协调才能不崩溃”的问题。当年信令网无法靠单机可靠性解决系统性崩溃今天多Agent系统同样无法靠单个Agent的智能水平解决协作失控。3.2 案例一Agent互相等待死锁我在测试一个多Agent流程时遇到过典型的死锁。一个Agent负责收集需求另一个Agent负责生成方案还有一个Agent负责最终审批。收集需求的Agent把任务发送给生成方案的Agent之后按规则等待对方的完成信号生成方案的Agent又认为需要等审批Agent先给出一份标准模板审批Agent的逻辑则是必须有完整方案才能开始工作。三个Agent形成了循环等待谁都永远等不到自己需要的那个消息。这类问题在信令网里对应的是信令路由的死循环。当年靠设置跳数上限、路由环检测来解决。在多Agent系统里很多编排框架还没有内置这样的环检测机制。没有环检测死锁就只能靠全局超时兜底而如果全局超时设置得不合理又会触发另一个问题——超时后的无限重试。3.3 案例二Agent重试风暴打垮工具服务另一个更常见也更疼的问题是重试风暴。某个Agent调用第三方工具接口接口因为自身负载过高开始返回超时。Agent的容错逻辑通常很简单失败就重试重试还是失败就再试。如果多个Agent同时调用同一个工具每个Agent都在做指数级或固定间隔的重试工具服务面对的就是信令网里同样的正反馈循环。我有一次在联调环境里就亲眼看到一个并不复杂的Agent协作任务因为某个上游API延迟升高导致十几个Agent实例同时开始疯狂重试把下游服务彻底打崩。最讽刺的是如果当时所有Agent都停下什么都不做下游服务本来可以在几秒钟内自行恢复。但Agent不会停它们只会按照预设的容错逻辑继续重试于是恢复时间被无限拉长。这和信令风暴里的重试机制几乎完全一样。通信系统最后总结出的经验是重试必须有上限、必须有退避、必须加随机抖动而多Agent系统里的重试逻辑很多时候还停留在最原始的“失败就再来一次”的阶段。3.4 案例三全局状态不一致导致重复执行还有一个典型的翻车场景来自状态管理。多个Agent共享一份上下文或工作区A和B同时读取到一条记录的状态是“未处理”于是两个Agent都开始处理这条记录。处理完成后A把状态更新为“已处理”B也把自己处理的结果写入结果覆盖了A的成果。更严重的情况是B的处理动作本身是不可重入的比如扣减库存、发送通知、写入账单重复执行就会产生实打实的业务事故。信令网对应的问题叫做“消息重复投递”和“事务状态不一致”当年的解决方案是给每条消息分配唯一的信令点编码和序列号在收端做去重配合事务状态机保证同一事务只执行一次。多Agent系统里的Agent之间传递的往往是自然语言任务天然缺少这种唯一消息ID和幂等机制。于是同样的任务被重复处理成了多Agent协作里非常高频的问题。4. 把学费变经验给多Agent系统的七条防崩设计原则信令网三十年的学费核心成果其实可以沉淀成几条非常朴素的设计原则。当年做通信系统时这些原则是写在规范文档里的现在做多Agent系统我建议把它们当作硬性设计要求直接引入架构设计。4.1 原则一全局控制节点必须存在且不允许无限重试多Agent协作不能只有一群平级Agent互相通信必须有明确的全局控制节点或者叫Supervisor、调度器、协调者。这个节点的职责和信令网里的STP一样负责统筹任务分配、流量控制、状态仲裁。当协作规模超过三五个Agent时去掉这个控制节点整个系统就回到了无政府状态死锁和重试风暴只是时间问题。控制节点同时要承担重试上限的管理。我在系统里通常会把每个Agent的重试次数写死默认不超过三次。重试策略必须由全局配置统一下发不允许每个Agent自己决定要不要重试、重试几次。这是阻断重试风暴最关键的一步。4.2 原则二指数退避加随机抖动把重试风暴扼杀在摇篮里一旦确认需要重试必须使用指数退避算法而且一定要加入随机抖动。指数退避让重试间隔随次数翻倍随机抖动则避免多个Agent在同一时刻发起重试把集体性的请求洪峰打散成零零散散的请求。这是我做通信系统时验证过无数次的做法用在多Agent协作里同样有效。import random import time def retry_with_backoff(agent_call, max_retries3, base_delay0.5): for attempt in range(max_retries): try: return agent_call() except Exception as exc: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.5) time.sleep(delay)这段逻辑虽然简单但在真实系统里带来的改善非常明显。我去掉随机抖动和保留随机抖动做过对比测试没有抖动时多个Agent的重试请求往往扎堆到达下游服务持续处于过载状态加上抖动后请求时间轴被打散下游服务有了喘息空间整体恢复速度快了好几倍。4.3 原则三扇出上限与并发闸门一个Agent触发子任务时能同时通知多少个子Agent必须有明确上限。我见过很多Agent编排设计一个主任务被广播给几十个Agent并行处理看起来效率很高实际上任何一个环节出问题几十个Agent同时重试系统瞬间就被打爆。建议给每个任务的扇出数量设上限超过上限的任务进入排队队列。在Agent编排框架里做一层并发闸门类似信号量的作用限制同一时间进入执行阶段的Agent数量。信令网里的负荷控制机制就是这么做的排队限流丢弃超龄消息保护核心节点不被无效消息淹没。4.4 原则四全局上下文用版本号和分布式锁状态变更留痕共享上下文是很多Agent协作方案的默认做法但这恰恰是状态不一致的温床。我的经验是对共享状态的每一次读取和写入都要带上版本号控制简单说就是CAS机制更新前检查当前版本是否和自己读取时一致不一致就重新读取再决策。对于关键业务动作比如扣库存、改订单状态、发送消息还要配合分布式锁或者唯一任务ID的幂等设计。同一个任务ID只允许执行一次重复调用时直接返回第一次的执行结果。这套机制通信行业叫“消息去重”在Agent系统里就是幂等保护的落地。4.5 原则五Agent必须是幂等的因为只要有网络只要有重试重复请求就一定会发生。所以每一个Agent对外提供的操作能力都必须是幂等的。所谓幂等就是同一个请求执行一次和执行一百次对系统状态的影响完全一样。比如一个写操作执行前先检查目标记录是否已经存在处理标记如果已经标记为处理完成就直接返回成功。这比在实现里反复判断“是否已经执行过”要可靠得多。把幂等设计写在Agent的职责定义里而不只是依赖上层编排去避免重复调用这个习惯能解决大量隐蔽的线上问题。4.6 原则六熔断器与容量隔离多Agent系统上游依赖的LLM接口、工具服务、数据库都有可能因为Agent的集体行为而过载。对这些依赖必须配置熔断器当某个依赖的失败率达到阈值比如连续失败超过10次熔断器打开后续调用直接快速失败不再真正请求依赖服务。依赖服务恢复后熔断器半开状态放一个试探请求成功后才关闭熔断器恢复流量。容量隔离也很重要。把不同优先级任务的Agent调用路径隔离开核心交易链路和批处理任务用不同的连接池和并发限额。这样即使批处理任务把某个工具打满核心链路也不受影响。这和信令网把重要信令与其他信令分开传输的思路完全一致。4.7 原则七可观测性——像信令网网管一样监控Agent信令网能快速定位故障靠的是完备的网管系统。多Agent系统也必须配套建设监控追踪能力不能等到日志刷屏再去翻。建议至少采集如下指标Agent消息队列长度、单次任务处理延迟、重试次数分布、下游依赖错误率、Agent间等待死锁检测、上下文版本冲突次数。给每一次Agent协作分配全局唯一的Trace ID所有Agent在日志中带上这个ID。排查问题的时候按Trace ID把一次完整协作链路串起来就能快速定位是哪个环节超时、哪个Agent引发了重试风暴。没有Trace ID的多Agent系统一旦出现问题就等着在成堆的日志里慢慢翻吧。5. 多Agent协作翻车现场排障实录与避坑清单5.1 排障实录一日志刷屏根本无法定位某个Agent任务跑着跑着日志系统突然告警每分钟新增几百万行日志。我登录日志平台一看全是同一个报错的重复输出不同Agent实例在同一时间段内疯狂重试同一个失败的工具调用。最初的问题是下游API短暂抖动但Agent的重试策略把它放大成了系统级事故。排查思路是先找到发起重试的责任链。我用Trace ID筛选出第一次失败的请求顺着调用链找到第一个开始重试的Agent再检查它的重试配置。定位后发现这个Agent的重试次数是无限次而且重试间隔是固定一秒。把所有Agent的重试配置统一改成有限次数加指数退避加随机抖动后问题消失。这个排障过程和当年在信令网里找重试源头一模一样。5.2 排障实录二Agent调用链出现循环依赖一次联调里发现两个Agent在互相持续调用谁都停不下来。A调用B查询信息B为了完成查询又回头调用A提供的接口而A的接口实现里又依赖B的查询结果。两个Agent的调用环没有终止条件消息在生产者和消费者之间来回弹跳直到触发队列上限。处理方式是先通过Trace ID确认调用环的存在在编排框架中加入最大跳数限制比如单个Agent最多转发消息三次达到上限直接终止并报错。更彻底的方案是重新设计两个Agent的职责边界把交叉依赖抽到一个共享服务下让A和B都不再直接调用对方。这跟信令路由环路检测的思路完全一致。5.3 常见问题速查表故障现象可能原因处理方法多个Agent互相等待任务一直不结束Agent职责存在循环依赖设置全局超时定位调用环并重新设计职责边界下游服务被大量重试请求打满重试策略无上限或间隔过短配置有限重试次数启用指数退避加随机抖动同一业务数据被多个Agent重复修改共享上下文无版本控制引入版本号CAS机制关键操作用唯一任务ID做幂等LLM接口调用费用异常飙升Agent循环调用或过度重试增加调用次数监控和熔断器设置单任务调用预算某个Agent负载过高其他Agent空闲任务分配策略不均衡检查扇出上限和任务路由增加动态负载反馈系统恢复后再次波动大量Agent同时用固定周期重试重试计划加入随机抖动避免请求同时到达5.4 关于多Agent框架与部署的一点实操笔记现在很多新一代Agent编排框架已经开始意识到这些问题。以AgentScope 2.0这类框架为例配置多Agent调用时除了定义Agent本身的模型、提示词和工具更重要的是把协调模式、消息路由、超时和重试参数单独抽出来配置。我建议把这类框架的配置理解为“设计一张信令路由表”而不是简单的Agent列表。你在配置里写清楚谁跟谁能通信、消息走什么通道、失败怎么办就相当于给系统做了拓扑规划。实际部署多Agent服务时建议采用多容器拆分的模式。比如用一个容器跑Agent运行引擎一个容器跑WebUI管理界面一个容器跑工具服务和状态存储按域名把流量在容器间做路由。我之前用三条命令完成了这套部署第一条拉起状态存储和工具服务第二条启动Agent运行引擎并连接状态存储第三条启动WebUI并指向Agent引擎。容器数量少依赖关系简单排查问题时头脑也清晰。大规模协作场景再按Agent类型继续拆分容器但原则不变控制面逻辑集中承载面逻辑隔离。部署完成后第一时间验证的应该是故障场景而不是正常流程。故意让一个Agent超时观察其他Agent的反应故意让下游工具抛错观察重试是否按预期退避。通信系统上线前一定做容灾演练Agent系统同样应该这样测不要在线上让系统自己考试。提示多Agent系统上线前请务必做一个“故障注入测试清单”至少覆盖超时、重试、死锁、重复执行、下游服务熔断这五个场景。这个习惯来自信令网运维的容灾演练传统能帮你提前暴露80%以上的协作稳定性问题。我个人在实际踩坑中最深刻的体会是多Agent系统的崩溃几乎从来不是某一个Agent不够聪明而是Agent之间的交互机制缺少通信系统早就验证过的底线设计。三十年前信令网用惨痛教训换来的退避重试、全局控制、幂等保护、可观测性现在到了多Agent系统该交作业的时候。别再让学费白交把这些原则写进你的Agent架构里比给Agent换更强大的模型更值得优先做。
