Agent 跑在线上最怕的不是它笨而是它“看似正常地卡住”。一次会话里编排层调度多个工具、多轮模型推理任何一个环节静默失败最终表现都是用户面对一个“突然变傻”的客服机器人。我维护的某客服 Agent 项目上线三个月后最深刻的教训就是Agent 编排必须把“失败”当成常态来设计而不是把“成功”当成默认值。之前版本里每个工具调用都写了重试模型超时就重试一次。结果线上该挂还是挂。原因很简单重试只解决瞬时抖动解决不了系统性故障。API 被限流、模型服务排队、下游数据源返回异常结构这些情况重试几次结果都一样反而把 RT 拉高、把错误率放大。后来我把结构改成“每个环节都有明确的降级路径”表现立刻不一样了。这篇文章把我这几个月在生产环境里做 Agent 编排降级的完整思路、配置细节和踩坑记录整理出来供大家参考。1. 先看清问题Agent 编排的链路到底长什么样1.1 一条典型的 Agent 请求要过几道关理解降级设计之前先把编排链路拆开。我这里的场景是一个客服类 Agent核心能力是理解用户问题、拆解任务、调用订单/库存/售后等系统工具、汇总结果、生成回答。一次完整请求大致经过下面几个阶段意图识别与任务拆解大模型把用户自然语言转成结构化的任务序列。工具选择与参数抽取模型决定调用哪个工具从上下文里抽取参数。工具执行Agent 向后端 API 发起调用等待返回结果。结果理解与上下文整合把工具返回的数据塞回上下文供模型下一轮推理使用。答案生成与格式校验模型生成回复文本校验层检查格式、敏感词、必填字段。多轮状态维护会话状态、步骤状态的存储与流转。这六个阶段里任何一环出问题整条链路都会受影响。更麻烦的是各环节的失败模式完全不同模型层可能是超时、幻觉、上下文超限工具层可能是限流、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 降级粒度按环节切还是按场景切降级粒度是设计时最容易拍脑袋的。我一开始做的是“全链路降级”就是某个环节失败后直接返回兜底话术“系统繁忙请稍后再试”。后来发现这样太粗暴很多失败本来可以在局部解决不需要打断整条链路。更合理的做法是按“环节 场景”两个维度切成小块。环节维度任务拆解、工具选择、工具执行、上下文整合、答案生成、状态维护每个环节独立配置降级策略。场景维度不同业务场景对降级的容忍度不同。比如查询库存这种纯获取类操作降级方案可以是“直接告诉用户暂时无法查询”但创建售后工单这种写操作降级方案必须更谨慎不能随意吞掉用户指令。我最终使用的配置模型如下环节降级类型降级动作用户可见性任务拆解结构降级退化为单步直答或规则模板部分可见工具执行功能降级返回部分数据/缓存数据/跳过该工具部分可见模型推理模型降级切换备用模型或简化 Prompt不可见上下文整合内容降级截断旧内容/用摘要替代不可见答案生成输出降级模板生成/固定话术可见状态维护存储降级降级为单轮无状态模式部分可见每个粒度独立设置互不干扰。这样一次故障可能只影响某个环节不会把整条链路拖下水。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%。当然后续随着场景增加还会出现新的失败类型但每一类失败都有对应的降级路径之后维护起来心里总是有底的。
