Agent编排降级设计实战：从重试到优雅降级的完整方案

Agent 跑在线上，最怕的不是它笨，而是它“看似正常地卡住”。一次会话里，编排层调度多个工具、多轮模型推理，任何一个环节静默失败，最终表现都是用户面对一个“突然变傻”的客服机器人。我维护的某客服 Agent 项目上线三个月后，最深刻的教训就是：Agent 编排必须把“失败”当成常态来设计，而不是把“成功”当成默认值。

之前版本里，每个工具调用都写了重试，模型超时就重试一次。结果线上该挂还是挂。原因很简单：重试只解决瞬时抖动，解决不了系统性故障。API 被限流、模型服务排队、下游数据源返回异常结构，这些情况重试几次结果都一样，反而把 RT 拉高、把错误率放大。后来我把结构改成“每个环节都有明确的降级路径”，表现立刻不一样了。这篇文章把我这几个月在生产环境里做 Agent 编排降级的完整思路、配置细节和踩坑记录整理出来，供大家参考。

1. 先看清问题：Agent 编排的链路到底长什么样

1.1 一条典型的 Agent 请求要过几道关

理解降级设计之前，先把编排链路拆开。我这里的场景是一个客服类 Agent，核心能力是：理解用户问题、拆解任务、调用订单/库存/售后等系统工具、汇总结果、生成回答。一次完整请求大致经过下面几个阶段：

1. 意图识别与任务拆解：大模型把用户自然语言转成结构化的任务序列。
2. 工具选择与参数抽取：模型决定调用哪个工具，从上下文里抽取参数。
3. 工具执行：Agent 向后端 API 发起调用，等待返回结果。
4. 结果理解与上下文整合：把工具返回的数据塞回上下文，供模型下一轮推理使用。
5. 答案生成与格式校验：模型生成回复文本，校验层检查格式、敏感词、必填字段。
6. 多轮状态维护：会话状态、步骤状态的存储与流转。

这六个阶段里，任何一环出问题，整条链路都会受影响。更麻烦的是，各环节的失败模式完全不同：模型层可能是超时、幻觉、上下文超限；工具层可能是限流、5xx、数据格式错误；编排层可能是状态丢失、并发冲突。所以降级方案没法用一个统一模板套，必须逐个环节单独设计。

1.2 失败不是小概率事件，而是常态

传统后端服务里，一个接口失败率 5% 已经算高了。但 Agent 编排里，端到端成功率是每环节成功率的乘积。假设六个环节每个环节成功率都是 99%，端到端成功率约 94%，也就是每 20 个用户就有 1 个遇到整体失败。这还只是单轮。多轮会话里，连续三次请求的成功率约 83%。用户体感就是“这个机器人十次里有两次在装死”。

我统计过我们线上数据，一次普通客服请求平均要经过 2 次模型调用、2-3 个工具调用。如果完全没有降级，每月因单点故障导致的会话失败率在 5%-8% 之间波动。这个数字在 2C 场景下，等同于每天几万用户遇到坏体验。所以我才开始给每个环节加降级，目标不是“让链路永不失败”，而是“让失败发生时用户无感或可接受”。

1.3 为什么传统重试在这里不适用

遇到失败第一反应是重试，这条经验在 Agent 编排里需要谨慎。原因有几个：一是 Agent 编排多为长链路，重试叠加在长链路上会造成响应时间不可控；二是模型推理具备不确定性，同样的请求重试一次可能得到不同结果，导致工具参数和上下文状态错乱；三是重试会放大下游压力，本来下游已经故障，重试等于补刀。

因此我的原则是：重试只用于“瞬时故障”，降级用于“持续故障”。区分两者的依据是：第一次失败时，记录失败类型和耗时；如果失败类型是超时、连接重置，可以在短时间窗口内重试一次；如果失败类型是限流、5xx、非法响应，直接走降级路径，不重试或只重试一次。另外给重试加一个总预算，比如单次请求全链路重试总次数不超过 3 次，总超时预算不超过 8 秒，超过直接降级。

2. 降级设计的三件套：粒度、阈值、方向

2.1 降级粒度：按环节切，还是按场景切

降级粒度是设计时最容易拍脑袋的。我一开始做的是“全链路降级”，就是某个环节失败后直接返回兜底话术“系统繁忙，请稍后再试”。后来发现这样太粗暴，很多失败本来可以在局部解决，不需要打断整条链路。

更合理的做法是按“环节 + 场景”两个维度切成小块。环节维度：任务拆解、工具选择、工具执行、上下文整合、答案生成、状态维护，每个环节独立配置降级策略。场景维度：不同业务场景对降级的容忍度不同。比如查询库存这种纯获取类操作，降级方案可以是“直接告诉用户暂时无法查询”；但创建售后工单这种写操作，降级方案必须更谨慎，不能随意吞掉用户指令。

我最终使用的配置模型如下：

每个粒度独立设置，互不干扰。这样一次故障可能只影响某个环节，不会把整条链路拖下水。

2.2 降级阈值：什么样的失败值得触发降级

阈值设计比粒度更容易出错。定得太小会导致频繁降级、正常流量都被降级处理；定得太大又会让降级形同虚设。我这边采用两层阈值：单次失败阈值和滑动窗口阈值。

单次阈值用于即时决策：一次调用失败后，判断是否立刻降级。判断条件是错误类型 + 耗时，比如 tool timeout 超过 3 秒且错误类型为 Timeout，直接降级；返回 429 或 503，直接降级；返回 200 但响应 JSON 结构缺失关键字段，也降级，不做重试。这里关键是：不要只看 HTTP 状态码，响应体内容异常也要算失败。我就遇到过工具返回 200 但 data 字段是 null 的情况，如果只看状态码，后面所有环节全在 null 上处理，最终答案生成阶段才炸。

滑动窗口阈值用于保护下游：在 60 秒窗口内，某工具错误率达到 30% 或错误数超过 20 次，触发熔断，直接跳过该工具或返回缓存数据。这个阈值需要根据下游的实际容量调整。某第三方库存接口给我们的配额是 100 QPS，我们设置的熔断阈值就要保守一些，避免熔断恢复后瞬间流量再次打满。

2.3 降级方向：往哪降才算“优雅”

降级方向是最终用户直接感知的部分。我按“代价从低到高”排序，始终尝试用最小代价实现降级：

• 参数降级：工具调用失败后，用默认参数或简化参数重试一次。比如订单查询超时后，去掉附加的“物流轨迹”字段，只保留基础订单状态字段再查一次。这类降级对用户几乎无感。
• 数据降级：获取实时数据失败时，使用最近一次的缓存数据，并在回复中附上一句“当前数据可能延迟”。注意这里必须明确告诉用户数据时效性，不能拿旧数据冒充实时数据。
• 功能降级：某个能力不可用，直接告知用户暂时不支持，并提供替代方案。比如售后工单创建接口挂了，转而引导用户拨打人工客服。
• 链路降级：放弃部分工具调用，只保留核心链路。比如需要调用三个工具才能完整回答的问题，在故障场景下只调用最关键的一个，其他部分用提示性文案跳过。
• 模型降级：主模型不可用时切换备用模型。这里不只是换一个模型服务，还要把 Prompt 简化、把思维链深度降低，因为轻量模型的指令遵循能力和推理能力都弱一些，不能直接拿同一套 Prompt 跑。
• 外呼降级：所有自动路径都失败时，返回明确的兜底话术，并生成一条人工处理工单。这是最后一道防线，不能省。

顺序很重要，先尝试低代价降级，不行再升级。这个顺序不是固定的，而是根据当前故障的严重程度动态跳转。如果熔断器已打开，就没必要再试参数降级，直接跳到数据降级或功能降级。

3. 实战拆解：每个环节的失败降级怎么做

3.1 任务编排层：拆解失败的兜底与并行转串行

任务编排层负责将用户请求拆解成可执行的任务序列。这里有两种典型失败：一是模型拆解任务失败，二是任务依赖关系导致执行死锁或冲突。

拆解失败的兜底方案，我采用的是“层级退让”：模型拆解失败后，先重试一次简化指令；再失败，退化为预设的任务模板匹配。举例来说，用户问“我的订单为什么还没发货”，如果任务拆解模型无法输出结构化 JSON，则用简单的关键词模板匹配“订单”和“发货”，直接映射到一个内置的“订单状态查询”任务。虽然比大模型拆解粗糙，但至少能完成任务。

并行转串行是针对任务依赖的一种降级。当多个工具调用原本设计为并行执行，但并发场景下经常出现下游限流时，我会在检测到连续两次并行调用失败后，自动转回串行执行。代价是响应时间变长，但成功率明显提升。我之前遇到过并行同时调用库存接口和物流接口，两个接口都不支持并发，结果被两边限流。串行化之后基本没有触发过限流。

另一个容易忽略的点：编排层要明确降级任务的优先级。当链路部分失败时，需要动态裁剪任务列表。比如查询“订单详情+物流信息+库存信息”三个任务在一次请求中，库存接口挂掉后，剩下的两个任务仍然执行，最终回复里自动拼接一段“库存信息暂时无法获取”。这里要注意，动态裁剪的逻辑必须在编排层实现，不能留给模型自行判断，否则模型会基于幻觉瞎猜一个库存数。

3.2 工具调用层：限流、超时、数据缺失的三重降级

工具调用层是最容易发生故障的环节，因为依赖的都是外部系统。我按失败类型分三条降级路径。

限流和 503 错误：这种情况下不能重试，直接在聚合层返回“该工具暂时不可用”。如果该工具的结果不是核心依赖，就跳过它，用其他工具的结果补充回答；如果必须依赖，则走缓存数据或人工兜底。我的代码实现中，每次工具调用都包了一层降级器，统一拦截异常并返回一个标准结构ToolResult{status, data, fallbackReason}，上层只管读取。

超时错误：分两级处理。如果超时时间在 3 秒内，允许一次快速重试；如果仍然失败，就使用就近的缓存数据。每个工具都维护了一个最近成功的响应缓存，带 30 秒到 5 分钟不等的 TTL，具体视数据敏感度。比如库存数据缓存 TTL 设短一点，因为库存随时变化；售后工单步骤说明类的内容 TTL 可以设长一些，因为变化频率低。

响应体结构异常：某些工具接口返回 200 但 JSON 结构不符合预期。这种失败最容易漏掉，因为监控工具默认只看状态码。我在工具调用的解析层对返回结构做了逐步校验：先检查外层字段、再检查核心数据字段、最后检查字段类型。校验失败后，不会进入下一环节，而是标记为“ToolSchemaError”，走数据缺失的降级路径。这里用到了一个小细节：每个工具定义了一个 JSON Schema，解析成功后再用 Schema 校验，省去手写大量字段判断代码，也更容易扩展。

3.3 模型推理层：主模型降备模型，以及 Prompt 的自动切换

模型推理层是整个 Agent 的心脏，也是最容易出现“部分可用”的环节。部分可用指的是：模型服务没有完全挂掉，但响应质量下降（例如超长延迟、频繁重试才成功），或者部分能力失效。

我的降级方案是三层模型后备链。正常情况使用主模型，它能力强、上下文理解更准。主模型超时或连续报错时，切换到备用模型，备用模型响应更快、稳定性更好，但推理能力弱一些。备用模型也失败时，降级到最小可用模型，只用来做最终话术生成，不做复杂工具决策。切换模型的同时，Prompt 模板也要跟着切。

这里有个实操细节：主模型的 Prompt 可以写得比较开放，因为它的指令遵循能力强，即使给一个简略的提示词也能完成工具选择。但备用模型的 Prompt 必须非常结构化，要明确列出可选工具、每个工具的编号含义、输出格式要求，甚至加上几个示例。原因很简单：轻量模型在模糊指令下表现不稳定，很容易乱写。我最初直接在主模型模板上换模型，结果备用模型完全没法正确选工具，还凭空编出参数来。优化之后，备用模型模板里每个工具都给了输入输出样例，表现才稳定下来。

模型服务的健康检查也很关键。你不能等到超时了才知道模型挂了。我实现了一个探活协程，每 30 秒调用一次模型服务的较小请求，统计成功率。当探活成功率低于 50% 时，自动把流量切到备用模型；探活恢复后再切回来。这个机制同样用于工具调用。使用探活而不是只靠请求失败来判断的好处是：可以提前感知故障，避免大量用户请求打到坏模型上做无用的等待。

3.4 上下文管理层：超限截断与摘要降级

上下文超限是长会话场景里最常见的隐性故障。不是像网络错误那样突然报个异常，而是模型开始“变笨”——用户说了什么它记不住，工具调用结果被截掉。我印象最深的线上事故：一个用户和 Agent 聊了 20 轮，中途用户修改了一个订单信息，但上下文里旧信息没清理，模型最后生成了基于错误订单号的回复。

上下文管理的降级方案分两步：超限检测和内容压缩。超限检测不是等到 token 数超过模型窗口才动手，而是设置一个安全水位，比如主模型窗口是 32K，当会话 token 数超过 24K 时触发压缩。压缩优先级从低到高依次是：历史对话小节摘要化、工具返回结果的详细数据精简、丢弃过时的系统提示。这里的核心原则是“保近丢远，保事实丢寒暄”：近几轮的对话信息最完整地保留；早期的对话用摘要替代；工具返回的表格型数据尽量精简，只保留最终状态和关键数字。

极端情况下，上下文被压缩到最小之后还是超限，就直接执行会话重置：告诉用户当前对话延续超过能力上限，建议开启新会话，同时把当前会话的关键状态（比如订单号、用户身份）固化到会话记录里，新会话可以继续读取。不要小看这一个操作，它能避免很多后续纠纷。

我建议给上下文管理做专门的日志。每次压缩时记录压缩前后的 token 数、丢弃了哪些类型的内容。上线后我发现，默认的“压缩垃圾回收”顺序经常把用户刚提到的偏好信息当作寒暄丢掉了，后来调整了分类权重，才减少这类问题。

3.5 输出校验层：模型自纠错与规则兜底

答案生成完毕并不算结束，输出校验层的职责一样重要。模型生成的文本可能出现的事实性错误、格式错误，或者包含敏感词。这些错误没有异常抛出，但比异常更危险——用户在不知情的情况下收到了错误信息。

我的输出校验分三层。第一层是规则校验：正则表达式检查电话号码、金额格式、日期格式，以及与用户问题相关性的关键词匹配。举个例子，用户问“订单号 ABC123 物流进度”，模型回答却附上了“订单号 XYZ789”的信息，这种场景可以通过校验器识别出回答里的订单号与上下文里的订单号不一致，从而拦截。第二层是语义校验：用一次轻量模型调用，让模型总结“回复里是否包含了用户问题所需的全部关键信息”，并给出“缺少什么”。这一层会额外消耗一次推理，但能有效提升低质量回复的拦截率。第三层是兜底策略：校验失败时，不直接返回错误内容，而是走一个“重生成指令”：把校验结果反馈给模型，让它重新生成一次答案。如果重生成后仍然失败，就走模板兜底。

模板兜底不要只写“系统繁忙”这一类话术。更好的做法是输出结构性兜底：把已经成功获取的部分信息填进模板，缺失的部分明确标注“暂未获取”。比如“您的订单当前状态为【已发货】，预计送达时间【暂未获取】，建议稍后查询物流详情。”这是在所有降级手段用尽之后的最优结果，至少用户拿到了一部分确定信息，而不是一个冷冰冰的错误提示。

4. 降级联动与观测：别让降级引发“雪崩”

4.1 降级状态传递：明确当前处于哪个级别

多环节独立降级需要解决一个致命的联动问题：当上一个环节已经降级时，下一个环节的决策必须知道这一点。我最初没有做状态传递，结果出现这样的情况：订单查询工具已经降级成缓存数据，但上下文整合环节不知道，依然把缓存数据当实时数据传给模型，模型生成时还加了“根据最新信息显示”。用户看到“最新信息”四个字，实际上数据是几分钟前的，投诉随之而来。

我给每个请求分配了一个DegradeContext，贯穿整个编排链路。里面记录了当前已触发的降级事件、每个事件的级别和发生时间。下游环节读取这个 Context 后，能做出更明智的判断。例如：当工具调用层标记了“dataStale”，答案生成环节就会在最终话术里拼接“当前信息可能不是实时数据”。如果多个环节都发生了降级，Context 会累计最终兜底级别，并在日志里输出完整的降级链路，方便复盘。

状态传递还涉及跨请求场景。多轮会话中，上一轮降级了，下一轮是否恢复？我采用的策略是：每一轮请求都检查当前环节的故障状态，不做全局性的“永久降级”，但是降级事件会自动影响本轮后续环节。整个会话则记录一个降级计数，一旦某轮降级次数超过阈值，下轮开始时直接进入“简化模式”——不再尝试复杂任务拆解，只回答直接问题。这样可以避免在多轮故障状态下反复做无谓的尝试。

4.2 降级风暴防护：快速失败优于无限重试

降级机制本身也会带来新的风险，其中最大的就是“降级风暴”。当一个下游服务故障时，大量请求同时触发降级。如果你的降级路径里包含了对备用模型或备用 API 的调用，直接结果就是备用通道也被流量瞬间打爆，然后所有请求继续降级到下一层，一层层打爆下去，形成雪崩。

有效防护手段有三种。第一种是设置降级调用配额：每个降级路径的 QPS 上限是主链路的 30%-50%，超出后直接进入最终兜底，不再尝试更复杂路径。第二种是降级路径也要有独立的熔断器，不能因为它是“备用”就无限重试。第三种是设置验证请求快速失败机制，这里引入一个 Shed Lock 概念：如果服务端发现系统资源占用超过 85%，直接丢弃部分请求并返回 503，避免排队请求拖垮整体。客户端侧对应把 503 当作降级触发信号，而不是排队重试。

在实际生产中，尤其需要关注“全局降级策略的优先级问题”。如果同一条链路上多个环节都触发了降级，不要都各自重试。我这边做了“降级合并”：一个请求只允许一次性进入降级，降级深度最大为三级，超过三级直接交给人工工单。这样既保留了降级路径的可用性，又限制了资源消耗。

4.3 可观测性：降级日志、Metrics 和 Trace 的配合

降级机制上线后，观测体系必须同步升级。没有观测的降级等于盲飞。我的观测指标包含三个层面：降级总览指标、环节级降级指标、降级前后对比指标。

降级总览指标就是统计每分钟降级请求占比、降级触发原因 TopN、降级平均耗时，这部分用一个单独面板展示。环节级降级指标会具体到每个工具、每个模型的降级次数和原因分布。降级前后对比指标更重要，我重点监控降级前后端到端成功率、平均响应时间、用户投诉率的变化。这样能回答一个关键问题：这次降级让用户体验变好了多少？如果降级后成功率提高了 10 个点但用户投诉率反而上升，说明降级路径本身有问题。

Trace 上，我把降级事件作为一种特殊的 Span 记录，每条 Trace 都能看到哪个环节触发了什么原因导致的降级、走了哪条降级路径、最终结果是什么。线上排查时，通过 Trace 的降级标记可以快速定位是工具问题、模型问题还是编排逻辑问题，不用再看散乱的到处日志。每日收敛一条“降级事件报告”，按用户影响量级排序，优先处理影响大但触发条件不合理的问题。

5. 排坑实录：降级机制上线后我踩过的那些坑

5.1 降级误触发：把正常流量当成故障

上线第一周就遇到了“降级误触发”。原因很尴尬：我设置的滑动窗口熔断阈值没有区分错误类型，把“单请求偶尔超时”和“持续故障”混在一起统计，导致某个工具在高峰期因为少量超时请求触发熔断，整个工具被跳过，结果大量正常请求也走了降级路径，用户体验反而变差了。

修正方法是给熔断阈值增加一个条件：必须是同一种错误类型连续发生且概率超过阈值，才触发熔断。比如库存接口返回 5xx 的请求占比超过 30%，而不是把所有错误类型相加。另一个重要优化是熔断恢复时加“半开探测”：熔断开 30 秒后，放行 10% 的流量，观察是否恢复，逐步增加到 100%。一次全量恢复很容易再次打挂刚缓过来的下游服务。

5.2 降级后遗症：上下文状态与用户预期断裂

降级最容易留下后遗症的场景是“跨轮状态断裂”。举一个真实案例：用户在第一轮咨询时要求“分批发货，先发两个，剩下的等库存到货再发”，Agent 把指令拆成了任务A和任务B。此时工具层故障，只执行了任务A，任务B被丢弃。第二轮用户问“那剩下两个什么时候发”，Agent 却因为没有任务B的记录，完全不知道怎么回答。

这个问题的根源是：降级发生在工具执行层，但编排层没有同步更新任务状态。我后来的做法是：任何环节发生降级，都必须往DegradeContext里写入“未完成事项”，并且在最终回复里明确告知用户“您刚才要求的后续操作暂时无法完成，需要重新提交”。宁可让用户再操作一次，也不能让用户以为事情已经办完。这个原则在处理“写操作”类需求时尤其重要，绝不能为了降级而假装成功。

5.3 降级测试：模拟故障比想象中难

降级机制上线前一定要做故障演练，但这个演练比我预想的复杂。一开始我以为只要把某个工具服务停掉就能验证，结果发现停服务只能测出“连接失败”这一种路径，测不出“响应超时”、“返回错误格式”、“限流”这些更常见的故障类型，而这些才是线上真正频繁出现的。

我后面搭了一套故障注入工具，在测试环境对指定工具和模型服务注入不同故障类型：延迟加大到 5 秒、返回 429、返回残缺 JSON、返回空数据等。每个故障类型对应写一个用例，逐一验证降级路径是否正确触发、降级后是否正常返回、DegradeContext中的标记是否准确记录。这里有个非常重要的细节：测试时不要只看结果成不成功，还要看降级日志和 Trace 中标记的降级原因是否符合预期。我就遇到过一次：工具返回了残缺 JSON，代码却走了超时降级路径，说明异常被上游包装后丢失了原始异常类型。如果不看日志，这个问题在测试时会完全漏掉。

另外故障演练要定期做，不能上线前做一次就完事。随着工具接口升级、模型 Prompt 调整，降级路径会被无意间“破坏”。我现在的做法是：每两周做一次随机故障演练，随机选一个环节注入一种故障类型，验证降级机制是否仍然有效。几次演练下来，总能发现和修复一两个隐藏问题。

5.4 小技巧：降级话术也要做 A/B

最后分享一个小技巧。降级话术的文案对用户满意度影响很大，同样是一次失败，话术不同用户投诉率能差出一倍。我一开始用的兜底文案是“系统繁忙，请稍后再试”，后来换成了“当前查询功能有点拥挤，我们正在努力恢复，您可以稍后再试，或者先查看常见问题”。但即使替换后，直接结束对话的仍不算少。我后来在兜底话术里增加了一个引导动作：“您可以点击下方链接查看订单状态，也可以直接拨打人工客服电话”，用户转向人工的意愿明显提升。

降级话术是需要持续调优的，但它不是本文核心，这里不再展开。重点是：降级不只是技术设计，还包含用户沟通设计。技术保障的是“链路不断”，沟通设计保障的是“用户信任不丢”。

跑生产环境的时间越长，我越能感受到一个道理：Agent 编排系统的稳定性，本质上是一种“面对不确定性依然能交付结果”的能力。给每个环节加失败降级，不是为了做个花哨的架构，而是为了避免用户在最需要帮助的时候，遇到一个帮不上忙的机器人。这套降级设计上线后，我这边因单点故障导致的服务不可用事件降低了约 80%，单轮会话失败率从之前的 6% 以上降到了接近 1%。当然，后续随着场景增加，还会出现新的失败类型，但每一类失败都有对应的降级路径之后，维护起来心里总是有底的。