先问个问题你跑过多Agent编排吗就是那种把大活拆成几个角色各自调用模型、工具、API最后拼出一个结果的工作流。如果你跑过大概率经历过这个场面——5个Agent并行跑其他4个都快出结果了突然有一个节点报了个超时错误然后整个调度器像被掐了电一样所有任务全部终止白跑的进度瞬间清零。这篇文章想聊的就是“一个节点失败其他节点怎么继续”这件事。抛开理论我会把多Agent调度里最常见的那几种失败场景拆开讲分享我实测过的三种容错架构——失败降级、分支隔离、异步解耦——以及完整的实测记录、常见问题排查。不论你是刚开始用LangGraph、AutoGen、Dify这类编排工具还是自己在写调度器这都能帮你少踩几个坑。为了把话说清楚先统一一下“节点”这个词的含义。在下面的语境里节点可以是一个Agent实例、一个任务执行单元也可以是一个工作流里的具体步骤。核心问题是同一个当某一块执行单元挂了调度系统能不能让其他部分接着跑。1. 多Agent调度到底在调什么1.1 从单Agent到多Agent调度器管了哪些事单Agent的场景很单纯一个LLM一条prompt一次调用一个结果。但真实业务一旦复杂起来你会发现单Agent什么都干不了——你要它既做市场调研、又写文案、又排版本一个模型上下文塞不下职责也分不清。于是多Agent出现了资料收集Agent、大纲Agent、写作Agent、配图Agent、审核Agent各干各的最后合成一个完整交付物。调度器就是连接这些Agent的“项目经理”。它至少要做三件事任务分发决定哪个Agent在什么时机执行拿到谁的输出作为输入。状态管理保存每个节点的中间产物让下游节点拿得到上游结果。生命周期管理启动、监控、终止、重试节点处理节点之间的依赖关系。我见过不少团队把多Agent用成了“多线程调用”以为把好几个模型调用扔在一起就是多Agent了结果一遇到失败就全线崩溃。真正的问题往往不在Agent本身而在调度器对“失败”这件事的处理。1.2 四种编排模型容错难度不一样先理清多Agent的编排模型因为不同的模型失败传播的方式完全不同。顺序链Sequential ChainA → B → C → D一个接一个。任何一个挂了后面全部无法开始。并行分支Parallel Branch几个Agent同时跑各自独立最后汇总。某一个挂了其他分支理论上可以继续但汇总节点要处理“部分结果缺失”。条件路由Conditional Routing根据某个节点的输出决定下一个走哪个分支。如果路由判断节点挂了整个流程直接停摆。动态编排Dynamic Workflow先跑规划Agent动态生成后续任务图再执行。这种最灵活但也最难做容错——因为任务图本身是“运行时才生成的”你没法提前设计每个失败路径。从我的实测经验来看最容易出问题的是顺序链因为节点之间是强耦合最难搞好的是动态编排因为失败路径不可预知。但不管哪种模型“一个节点失败”这件事本身并不可怕关键看调度器设计了几条后路。1.3 “一挂全崩”的四个根因把根因归纳分析一下你会发现绝大多数系统里不是节点太脆弱而是调度器没有隔离故障。同步阻塞调用调度器串行等待每个节点返回。只要一个节点卡住队列里所有节点一起等表面看起来就是“全崩了”。异常直接冒泡子节点的异常没有在边界处捕获一路抛到顶层导致整个工作流中断。状态只存在内存里节点执行了一半进程崩溃或任务重启中间状态全没了下游无从继续。没有超时与重试策略外部API一抖动节点无限等待或者一失败就放弃两者都不可接受。这四个根因我都在实测中踩过。最典型的一种事故是一个Agent调用第三方数据库工具对方服务临时不可用Agent抛了个ConnectionError调度器没兜住整个Pipeline直接失败。下游Agent其实根本不需要那个数据库的结果——它可以从缓存的另一份数据继续——但因为没有“降级路径”只能陪葬。2. 节点失败的真实类型与判定2.1 失败可以分成这么几类在写容错逻辑之前你一定要先清楚一点不是所有失败都需要同样的处理。我把多Agent调度中遇到的失败分为四类失败类型典型表现例子可恢复性超时型调用长时间无返回LLM API 响应慢、外部工具挂起可恢复重试有效资源型请求被封、算力不够模型限流、GPU OOM、并发配额超限部分可恢复需等待或降级逻辑型输出不符合预期Agent返回非法JSON、工具返回null不可恢复需要换路径依赖型上游失败导致下游缺料前置节点失败后续节点拿不到输入视情况决定是否替代这四类失败混在一起如果统一处理往往适得其反。我见过有人对所有异常都重试10次结果遇到逻辑型失败白白浪费10次token也有人对所有失败直接放弃结果限流这种明明等一下就好的问题也直接断送整个任务。2.2 先判断“致命失败”还是“可恢复失败”我的设计原则很简单重试只用于可恢复失败不可恢复失败必须立刻走降级或终止。怎么判断看错误类型和重试后的表现如果是限流、网络超时、短时间服务不可用属于可恢复失败重试退避就有戏。如果是输入数据不合法、Agent 输出的格式反复不对、配置错误属于致命失败重试多少次结果都一样。判断时机最好是“抛出异常的那一刻”。在调度器里我给每个节点一个错误分类器先把异常归一化成三类RetriableError、FatalError、FallbackNeeded。别让Agent自己乱抛原始异常那样调度器根本没法统一决策。2.3 超时、重试、健康检查三个核心参数超时时间不要设成“无限”。我通常给LLM调用设30~60秒给外部工具设10~15秒。如果超过立刻视为超时失败。超时时间太小容易误杀慢任务太大则会拖垮整体节奏建议先压测再定。重试次数3次是个不错的默认值具体要看失败类型。限流可以多试两次逻辑型一次都不要试。重试之间加指数退避第1次等1秒第2次等2秒第3次等4秒避免风暴。健康检查对外部依赖最好做主动健康检查比如每30秒探测一次下游API是否可用。但注意健康检查不能代替超时重试——探测通过了实际调用时还是可能失败。另外千万别忘了记录失败上下文。失败时要把“哪个节点、哪个输入、哪次重试、错误堆栈、当时的全局状态”写进日志。没有这个出问题你根本无从排查。3. 其他节点怎么继续三种容错架构实测3.1 方案一失败降级——换个方式完成任务第一种思路是“降级”。当某个节点失败时不中止整个流程而是用一个后备方案顶上。最常见的两种降级模型降级主模型不可用自动换备用模型。我实测过LLM供应商限流时把调用从大模型降级到小模型任务照样能跑完只是质量略降但总比全盘失败强。Agent降级某个专家Agent失败自动让另一个通用Agent接管它的职责。比如配图Agent调用图像生成服务失败就让文案Agent生成一段图片描述兜底。降级的核心是“提前定义后备路径”不是在失败那一刻才临时想。我在设计调度图时会给每个高风险节点配置一个Fallback节点。一旦检测到重试耗尽就直接走Fallback边。3.2 方案二分支隔离——失败不扩散第二种思路是“隔离”。让并行分支之间互不干扰一个分支挂了不影响其他分支继续跑完。关键点有两个状态隔离每个分支维护自己的独立状态空间不要共享一个全局写变量。我见过最惨的事故就是两个分支同时往同一个变量里写一个写坏了另一个读出来也是脏数据。事务性每个分支的执行可以看作一个小型事务成功提交状态失败回滚但只影响自己。我在实测中做过一组对照5个并行节点同时跑其中一个节点调外部接口超时。在“无隔离”模式下调度器一发现失败就终止全部在“隔离模式”下另外4个分支正常跑完最后汇总节点看到缺失了一个分支的数据打了一条警告然后用剩余数据产出了结果。这个方案适合“部分结果可接受”的业务场景。比如生成了5个章节丢了1章你可以接受这4章也可以再单独补一章。3.3 方案三异步队列解耦——让节点之间不互相等待第三种思路是“解耦”。节点与节点之间不再同步调用而是通过消息队列异步传递任务。结构大概是前一个节点把任务消息发到队列然后立刻返回后一个节点作为消费者从队列里取消息执行。节点失败后消息不会消失而是进入重试队列或死信队列不影响其他节点消费自己的消息。实测下来这个方案对“高并发、长耗时、多节点”的场景特别友好。比如在内容生产流水线里收集资料节点很慢但写作节点只要等到资料消息到达就可以开始不需要整个流程同步等它。不过有个代价异步化之后你很难再保持一个“同步的最终结果”。想要拿到最终结果需要自己实现结果汇聚或者做一个异步回调通知。这个方案不适合对延迟要求极高的场景但作为调度容错底子是足够扎实的。3.4 三种方案怎么选方案核心思想适合场景缺点失败降级换后备方案顶上有替代路径、质量可降降级结果可能不完整分支隔离故障隔离、不扩散并行分支、可接受部分结果汇总节点需处理缺失异步队列消息解耦、失败重投高并发、长流程结果汇聚复杂、延迟高如果是生产级系统我建议组合使用外部依赖类失败用降级并行子任务用隔离全链路长流程用异步队列。4. 实操记录一个演示环境下的完整流程4.1 场景设定内容生产流水线为了验证“一个节点失败其他节点怎么继续”我搭了一个5节点内容生产流水线collect资料收集Agent从测试库拉取资料。outline大纲Agent生成文章大纲。write写作Agent按大纲写正文。image配图Agent为文章生成图片描述。review审核Agent把关文字质量。设计上collect节点采用分支隔离模式outline节点配置降级路径write和image是并行分支review最后汇总。我刻意模拟了“outline节点调用LLM API超时”的故障看整个调度如何处理。4.2 代码与配置实现调度器用Python写了一个简化版核心是定义节点、边和容错策略。下面贴出核心代码伪代码风格忽略生产级细节import time from typing import Dict, Any class RetriableError(Exception): 可恢复失败重试有效 pass class FatalError(Exception): 致命失败重试无效 pass def collect_node(state: Dict[str, Any]) - Dict[str, Any]: print( collect 开始) time.sleep(1) state[docs] [行业报告.pdf, 用户访谈.md, 竞品分析.xlsx] print( collect 完成收集到 3 份资料) return state def outline_node(state: Dict[str, Any]) - Dict[str, Any]: print( outline 开始调用 LLM API...) time.sleep(2) # 模拟超时失败第一次抛异常后续重试仍失败 raise RetriableError(LLM API timeout after 2s) def fallback_outline_node(state: Dict[str, Any]) - Dict[str, Any]: print( fallback_outline 开始使用本地规则模板兜底) state[outline] { title: 多Agent容错实践指南, sections: [背景, 失败类型, 容错架构, 实测记录, 经验总结] } print( fallback_outline 完成生成兜底大纲) return state def write_node(state: Dict[str, Any]) - Dict[str, Any]: print( write 开始基于大纲写正文...) time.sleep(3) state[article] f基于大纲{state[outline][title]} 的正文内容 print( write 完成) return state def image_node(state: Dict[str, Any]) - Dict[str, Any]: print( image 开始生成配图描述...) time.sleep(2) state[image] 一张包含调度架构图的配图 print( image 完成) return state def review_node(state: Dict[str, Any]) - Dict[str, Any]: print( review 开始审核全文质量...) time.sleep(1) print( review 完成输出最终检查结果) return state调度主逻辑里我用边连接各个节点并给outline设置重试与降级def run_with_retry_and_fallback(node, state, retries3, fallbackNone, timeout5): for attempt in range(1, retries 1): try: result node(state) return result except RetriableError as e: print(f ! {node.__name__} 第 {attempt} 次失败{e}) if attempt retries and fallback: print(f ! 重试耗尽切换到 {fallback.__name__}) return fallback(state) duration 2 ** attempt # 指数退避 print(f ! 等待 {duration} 秒后重试...) time.sleep(duration) except FatalError as e: print(f ! {node.__name__} 遇到致命错误不再重试{e}) raise raise FatalError(f{node.__name__} 重试耗尽且无降级路径)在这个简化实现里outline节点执行失败会触发3次重试重试期间使用指数退避。重试耗尽后自动切换到fallback_outline节点。4.3 模拟节点失败观察其他节点行为为了模拟一个真实故障我故意让outline一直抛RetriableError。跑起来后日志输出如下节选关键步骤 collect 开始 collect 完成收集到 3 份资料 outline 开始调用 LLM API... ! outline 第 1 次失败LLM API timeout after 2s ! 等待 2 秒后重试... outline 第 2 次失败LLM API timeout after 2s ! 等待 4 秒后重试... outline 第 3 次失败LLM API timeout after 2s ! 重试耗尽切换到 fallback_outline fallback_outline 开始使用本地规则模板兜底 fallback_outline 完成生成兜底大纲 write 开始基于大纲写正文... image 开始生成配图描述... write 完成 image 完成 review 开始审核全文质量... review 完成输出最终检查结果关键观察点失败没有向上冒泡outline失败后调度器只对outline进行重试和降级没有中断流程。write和image并行执行在outline重试期间write和image并未等待。当然在这个简化日志里它们是从同一调度循环发起的实际生产中可以做成真正的并行执行。review最终拿到了兜底大纲fallback_outline输出的结构化大纲让write正常执行整个流水线没有因为outline失败而全盘终止。4.4 结果数据我记录了一个运行批次的节点状态汇总节点预期行为实际结果耗时collect成功成功3份资料约1秒outline调用LLM3次重试失败切换fallback约12秒fallback_outline兜底大纲成功结构完整约0.1秒write成功成功正文生成约3秒image成功成功配图描述生成约2秒review成功成功最终审核完成约1秒如果采用“无容错同步调度”outline失败那一刻整个流程就会终止后面write、image、review根本不会执行。加了重试、降级和隔离之后这条流水线的最终交付物如期产出只是内容大纲换成了兜底方案。5. 常见问题与排查实录5.1 问题速查表我把实测中遇到的典型问题整理成一个速查表现象可能原因排查思路解决建议一个节点失败整个流程全停异常未在调度边界捕获或同步阻塞看日志中第一个异常抛出的位置在调度器入口统一捕获异常配置Fallback重试多次仍然失败把逻辑型失败当成可恢复失败检查错误类型分类器对FatalError禁止重试直接降级或终止并行节点互相影响数据变脏共享了全局状态没有隔离检查状态读写位置每个分支用独立状态副本任务卡死永不超时没有设置超时时间看耗时最长的调用对LLM和工具调用设置明确超时fallback节点没生效Fallback边配置错误或没有触发条件检查调度图定义把Fallback作为显式边加日志确认触发失败信息丢了很难排查没记录失败上下文查看日志是否包含错误堆栈失败时记录节点、输入、重试次数、堆栈5.2 排查思路排查多Agent调度故障我习惯按这个顺序走看失败发生在哪个节点通过日志里的节点名和错误信息定位。看失败类型是可恢复失败还是致命失败这决定了下一步的方向。看重试路径重试了几次、有没有退避、有没有走降级。看事后状态从状态快照或日志里恢复“失败瞬间”的上下文。看下游影响失败节点的下游节点是否拿到替代数据或缺失标记。多Agent系统里最难的不是定位而是“复现”。因为LLM调用本身有随机性同一个输入可能这次成功下次失败。所以日志里一定要带上全局状态快照不然复现成本极高。5.3 避坑经验最后分享几条我在实测中踩过之后总结的经验不要在Agent内部吞掉异常。如果你在Agent内部把异常catch掉然后返回一个空字符串调度器会以为“这个节点成功了”然后下游拿空数据进行加工最后产出一篇鬼话连篇的文章你还不知道问题出在哪。正确做法是让异常往上抛在调度器边界统一决策。不要无脑重试。重试是要花时间和token的。我见过一个团队对限流和逻辑错误都用同一个重试逻辑结果逻辑错误的Agent重试了5次浪费了大量LLM调用成本。重试次数和退避策略一定要按错误类型区分。降级路径要提前定义不要临时拍脑袋。Fallback节点必须在调度图里预先画好并经过测试。临时在异常处理里写“那就换个prompt再试一次”这种做法生产环境根本来不及也不可靠。监控要覆盖到“失败但继续”的场景。这种场景比直接失败更隐蔽——任务最后成功了但某节点其实是靠降级顶过来的如果没人注意你会误以为系统是健康稳定的。要专门为“降级执行”打上指标和告警比如“节点outline降级次数 0”就告警。异步队列方案中千万要做好死信队列监控。任务反复重试最终进死信队列时如果没人看那这个任务就永远消失了。死信数量要进告警。最后再分享一个我个人的体会。做多Agent调度最难的不是把节点串起来而是设计“失败时怎么办”的路径。我实测下来最大的变化是心态以前我写调度器默认节点都会成功现在我默认每个节点都有可能失败所有设计都从“如果这里挂了系统会怎样”出发。这个思路转变之后系统的稳定性提升了一个档次。你可以在自己的项目里先挑一个最核心的节点给它配置重试、降级和隔离然后故意把它杀死看看整个流程的反应——这个实验成本很低但收获会非常大。