先说个背景。去年我在维护一个智能客服系统时发现生产环境的故障有一大半不是模型幻觉也不是底层模型服务宕机而是API编排层在压力下先撑不住了。一次简单的多轮对话会依次触发意图识别、知识库检索、工具调用、大模型生成中间任何一步超时或失败整个用户请求就像多米诺骨牌一样重试、堆积、雪崩。那段时间我几乎每天都在看链路图最后把API编排层当成独立的高可用系统工程重修了一遍才算把故障率压下来。这个话题适合所有正在做AI原生应用、智能体、Copilot类产品的开发者。AI原生应用不是简单地把大模型接口包一层HTTP路由它的核心逻辑都在编排层里——怎么调度模型、怎么调用外部工具、怎么维护会话上下文、怎么做降级和兜底。标题里说的API编排指的就是这个大脑。这篇文章会围绕高可用这个目标讲清楚编排层到底在编排什么、高可用指标怎么定、超时重试幂等怎么设计、状态和降级怎么落地以及最后部署演进时容易踩的坑。1. AI原生应用的API编排到底在编排什么1.1 和传统API网关的本质区别很多团队一开始会习惯性用之前的API网关思路来做AI应用的编排层——挂一堆路由规则、鉴权、限流然后把请求转发给模型接口。等你真正接到多轮对话、Agent工具调用、流式输出之后会发现它和传统API网关完全是两码事传统网关解决的是请求转发到正确服务而AI编排解决的是如何在一个请求里动态决定调哪几个服务、以什么顺序调、参数如何组装、结果如何合并、出错时怎么办。传统网关的路由表是静态的而AI编排的路由是由模型根据用户输入实时生成的。同样一句话今天走检索加生成的路径明天可能就变成直接调用外部订单接口。这意味着你不能像配Nginx location一样提前把路径写好编排层必须有能力执行一个动态计划并且处理计划在执行过程中发生的变化。另外传统API网关是无状态的但AI编排天然有状态。对话上下文、工具调用结果、中间步骤的临时数据都要在编排过程中被管理。一旦编排层崩溃用户可能已经输入了三轮信息重启后很难再回到原来的状态。这就是为什么高可用设计不能照搬旧方案。1.2 编排对象的四种基本形态我把日常会遇到的编排对象分成四类这四类对应着不同的高可用策略第一类是大模型调用。这是最常见的编排目标包括主模型、辅助模型、评测模型的调用。它们的特点是耗时长、价格贵、结果不可控而且依赖外部网络。对这类对象编排层需要处理超时、重试、成本控制、响应解析尤其是流式响应下的中间状态中断问题。第二类是外部工具调用也就是常说的function calling或工具调用。比如查天气、查库存、下单、发通知这类调用通常有真实的业务副作用。它们的特点是延迟波动大、可能产生下游业务影响而且不是每次调用都成功。编排层在调用前要校验参数调用后要处理业务错误还要考虑这个工具失败后能否用另一个工具替代或者干脆跳过。第三类是知识库检索。RAG类的应用会把用户问题向量化后去向量库召回再拼进Prompt送给模型。这类调用的特点是与上下文强相关检索结果的质量直接影响模型回答。高可用设计上要考虑检索超时后的降级方案比如降级为关键词搜索或者强制使用缓存中的历史结果。第四类是人机协同流程。比如审稿、审核、审批这类场景AI生成初稿后需要人工确认编排层要负责把流程挂起、等人工结果、再继续后面的步骤。这类流程可能持续几十分钟甚至几天编排层的状态管理能力在这里接受考验。这四类对象混合在一起才是AI原生应用的完整编排场景。做高可用时不要试图用一个通用方案包打天下我建议先画出自己应用里有哪几类节点每一类分别设计超时和降级策略再考虑怎么统一治理。2. 先把高可用翻译成可量化的设计目标2.1 AI场景的可用性指标和传统SLA哪里不同传统API的可用性指标非常清晰QPS、错误率、P95/P99延迟、可用性百分比。但在AI原生应用里这些指标如果不加转换会带来很大的误导。举个例子你的模型网关整体错误率只有0.5%看起来非常健康但某个用户的单次完整任务里包含了20个模型调用步骤那么整个任务级别的失败概率大约是1减去0.995的20次方约等于9.5%。也就是说即使每个环节都很稳用户感知到的成功率却非常差。所以我在实际设计中除了关注单次API调用的指标还会额外盯任务级成功率也叫流程级成功率。从用户角度看只有完整走完一次智能问答、一次下单助手流程、一次文档生成流程才算成功。这个指标的背后直接反映编排层的韧性——节点失败后能不能绕过步骤中断后能不能续跑。另一个差异在于Token消耗和成本。传统接口失败的代价是产生一次5xx错误而AI编排失败的代价还包括已经烧掉的Token成本。比如模型生成到一半超时前面生成的内容全部作废重试时还要重新烧一遍前置调用的成本。因此高可用设计不只看错误率还要看无效Token比例这是个很实操的成本指标我后面会再讲。2.2 SLO、错误预算与成本预算做高可用不是把每一个环节都做到100%而是定义好可接受的下限。我给团队定的做法是在编排层建立两个预算——错误预算和成本预算。错误预算跟SRE的思路保持一致。例如设定任务级成功率SLO为99.5%也就是一个月内10000个任务最多允许50个失败。一旦失败数量逼近限额就要主动触发限流或降级防止超出用户容忍底线。这个简单机制能让高可用从一个抽象愿望变成一个可执行的门禁条件。成本预算是我在AI项目中特别强调的。给每个用户请求设定一个Token花费上限例如一次普通问答最多10000 Token一旦编排过程中发现可能超支就触发策略压缩历史上下文、切换更小的模型、或者直接停止工具调用链只输出一个简化答案。听起来很具体但它和可用性紧密相关——不控制成本就无法在高峰期放开并发无法放开并发可用性自然受制约。2.3 一个可以直接套用的指标定义模板下面是我们在模拟项目X里实际使用的指标清单你可以根据自己业务调整指标名称定义建议阈值说明任务级成功率完整流程成功数 / 总请求数≥99.5%最核心的体验指标编排层自身错误率非上游错误导致的编排异常≤0.1%反映编排层代码质量单次任务P95耗时从请求进入到最终完成≤5s超过则需检查依赖链路无效Token占比因超时、中断、重试浪费的Token / 总Token≤3%过高说明超时与重试策略不当缓存命中率命中缓存请求数 / 总请求数≥40%RAG场景重点指标降级触发次数当周降级发生次数有告警即可用于复盘瓶颈这套指标不一定全但能让你每次讨论高可用时有一个统一的度量基准。高可用不是一个最终状态而是用这些指标不断校准的过程。3. 编排层的第一道防线超时、重试与幂等3.1 为什么超时设长点会雪崩我见过不少团队在编排层会把模型调用超时设成60秒、90秒理由是模型生成本来就慢设短了老超时。这个直觉很危险。假设上游模型服务的平均耗时是3秒P99是15秒你的编排层把超时设为30秒那么正常情况下大多数请求都能通过。但如果模型服务因为负载过高开始变慢P99从15秒涨到40秒超时时间30秒就会变成一个过滤闸门所有请求都要等30秒才失败而新的请求还在持续进入编排层的工作线程会被这些注定失败的请求占满。线程池耗尽后连健康检查都做不了整个服务直接雪崩。我的经验是超时时间必须和上游的延迟分布强相关而不是拍脑袋。先连续观测一段时间统计上游P50、P95、P99延迟把超时初步设为P95的一到两倍同时限制最大超时不超过20秒除非你的业务真的需要长任务。运行一段时间后再根据实际错误率校准。宁可让部分请求提前失败也不允许大量请求堆积占死线程池。3.2 重试的账要算服务端HTTP调用重试是很自然的动作但在LLM调用里重试的成本比普通API高得多。一方面模型服务按Token计费每次重试都在烧钱另一方面用户看到的是延迟成倍增加。我处理过的案例里有一次客服系统的外部工具调用失败后编排层自动重试了三次结果每次重试都在等待超时用户端30秒没有任何输出最后还额外消耗了约3000 Token。所以重试策略不能一刀切失败三次指数退避。我现在的规则是只有在上游明确返回网络错误、限流或5xx时且错误信息里没有不要在业务侧重试的语义时才允许重试。对于超时类错误第二次重试的时间代价用户通常接受不了需要直接走降级路径。同时我会区分幂等重试和业务副作用重试涉及到下单、扣款这类动作时重试必须先把幂等键带上否则宁可失败返回人工介入。多模型场景下还有个思路是重试时切换供应商比如主模型服务超时后直接切换到备用的模型服务而不是重试同一个已经拥堵的实例。实测下来这类跨实例重试的成功率往往比原地重试高一倍。3.3 幂等键与去重表从源头控制副作用前面提到工具调用有真实副作用这是AI编排高可用里最容易被忽略的一环。比如你的助手帮用户查库存、锁定库存、生成订单如果编排层因为网络问题对创建订单这个工具重试用户可能会收到两笔相同订单。这里必须引入幂等机制。我的做法是在编排层的入口为每个用户任务生成一个全局唯一的requestId并以requestId工具名输入参数哈希值作为单次工具调用的幂等键。调用带副作用的工具时这个幂等键会随请求一起传给下游。下游如果发现同一个幂等键已经处理过直接返回上次的结果不再重复执行。如果下游不支持幂等编排层就要自己维护一张去重表记录已完成的调用签名和响应结果。这张表的高可用本身也需要注意不能用本地内存存——进程重启就丢了。我会把去重表放在Redis里带TTL例如保留24小时恰好覆盖业务流最长周期。为了让Redis不可用时不至于阻塞主流程去重操作要做容错宁可放行新请求也不要因为查不到去重记录就拒绝所有重试。这在分布式系统里是典型的可用性优先于一致性取舍。3.4 一个经过验证的重试调度示例下面是我在项目里用过的一段简化伪代码展示超时与重试如何协作async def call_llm_with_resilience(llm_client, request, eager, request_id): # 第一次尝试 for attempt in range(2): # 最多重试1次 try: resp await llm_client.chat( request, timeouteager.timeout_ms, # 短超时 headers{X-Request-Id: request_id} ) if resp.status 429 or resp.status 500: # 只对明确的系统错误重试 if attempt 0 and eager.allow_retry: await asyncio.sleep(0.5 * (attempt 1)) continue raise UpstreamUnavailableError(resp.status) return resp except asyncio.TimeoutError: # 超时不重试直接降级 raise LLMTimeoutError() # 降级逻辑切换模型供应商或返回安全兜底 fallback_resp await fallback_client.chat( request, timeouteager.timeout_ms, headers{X-Request-Id: request_id} ) return fallback_resp注意我在第二次调用时直接切换到备用的fallback客户端而不是重试同一个上游。同时把超时时间保持在一个固定的合适值附近不因为重试而增加。这样单次任务的最坏延迟可控用户感知更稳定。代码里的X-Request-Id就是幂等的一条边下游和日志系统都能靠它串联全链路。4. 状态管理与降级落地从会话上下文到模型切换4.1 状态放哪无状态编排加外部状态存储AI原生应用几乎绕不开状态。最简单的场景多轮对话需要累积历史消息复杂一点的场景Agent执行过程中可能已经完成了三步工具的调用第四步失败后需要从第三步的结果继续续跑。这些状态如果放在编排服务的内存里一旦服务被重新部署或者扩容所有进行中的流程直接中断。我踩过这个坑最初单机部署时所有会话上下文都存在进程本地Map里后来为了扛流量把服务水平扩展到三副本结果用户刷新一下就被路由到另一个副本上下文全部丢失那段时间的投诉率非常高。后续的处理方案很明确编排服务本身保持无状态所有上下文、步骤状态、中间结果都放到外部状态存储里。最常用的方案是把会话上下文存Redis按会话ID聚合。步骤执行状态则设计成一张流程状态表每条记录包含requestId、节点名、输入摘要、输出摘要、耗时、错误信息、状态pending/success/failed/skipped。这样即使编排进程挂掉新启动的实例也能通过requestId从状态表里恢复流程。有人会担心Redis的性能和持久化实际用下来带AOF持久化的Redis足够支撑绝大多数场景。至少比内存方案稳定很多。如果单Redis不够可以做分片或引入带副本的集群但那是另一个话题。4.2 降级梯队模型降级、流程降级、内容降级高可用系统的核心能力之一是在异常时让系统以可接受的最低服务水平继续运行。我在AI编排里把降级设计成三个梯队按影响范围从小到大排列。第一梯队是模型降级。主模型不可用或超时时切换到备用模型。比如主模型超时后先用一个参数较小的快速模型顶住。实测中模型降级能把可用性从99%抬到99.8%左右且用户几乎无感知只是回答深度略降。第二梯队是流程降级。某些工具调用失败时不直接中断整个任务而是跳过该工具改用其他路径完成目标。比如查天气的工具失败就改为直接检索天气网站的公开摘要下单失败时改为生成下单链接让用户自行点击确认。流程降级要求你在设计编排图时预先为关键节点准备替代路线。第三梯队是内容降级。这是最保守的兜底当所有模型都不可用时返回固定话术或缓存的历史答案。内容降级虽然解决不了问题但至少让用户知道系统在尽力而不是白屏或连接超时。对用户体验的伤害要远小于直接抛500错误。编排层实现降级梯队时要注意降级动作本身要可观测比如在返回的头里加一个X-Fallback-Reason方便后续从日志中统计降级发生频率避免某条降级路径被默默触发了几十万次却没人知道。4.3 上下文窗口压缩与Token预算策略上下文管理对高可用影响很大因为它直接跟成本和可用性挂钩。每当对话变长Prompt里的历史消息会持续膨胀。模型处理长上下文的时间呈超线性增长Token费用也在涨接口超时风险同步上升。很多线上故障其实是上下文过长导致生成阶段超时而不是模型服务本身故障。所以编排层必须有一个上下文压缩模块。我常用的策略有三种一是按时间衰减。超过30分钟的历史消息只保留摘要不保留原文。做摘要的模型调用本身要控制次数通常每十轮才做一次摘要。二是按重要度裁剪。把工具调用结果中的长文本做截断只保留关键字段比如查询商品只保留名称、价格、库存不保留完整JSON。这能显著减少Token数又保留足够的信息。三是预算硬限制。为每次请求设定Token上限例如主模型上下文8K工具结果解析后如果超限优先丢弃中间最古老的工具结果而不是丢弃用户最近一轮的输入。这类策略需要结合业务场景微调但原则是宁肯模型少做一些推理也不能让它因超限而崩溃。实测下来加上预算硬限制后单次任务P95延迟下降了大概30%无效Token占比也从5%降到了2%出头。这对提升整体稳定性直接有效。5. 可观测性把每次编排变成一条可复盘的时间线5.1 编排层需要记录哪些关键事件如果你的系统出现了一次用户投诉说机器人回答到一半就不动了而你手里只有应用网关的访问日志你会非常抓狂。请求是哪一步开始失败的调用了哪个模型烧了多少Token当时上下文里有什么这些问题没有正确的观测数据就无法定位。在编排层我最关心四类事件请求流入事件、每一次外部调用事件、分支决策事件、异常和降级事件。每一类都必须带requestId、时间戳、耗时、节点名、输入摘要、输出摘要、错误码。尤其是外部调用事件一定要记录上下游用了多少毫秒、返回的状态码、是否重试、重试了几次。没有这些信息后续很难判断到底是模型服务慢还是编排逻辑慢。5.2 Trace与业务事件结构化结合技术圈里大家习惯用OpenTelemetry这类标准Trace来记录Span调用链。在AI编排场景里我建议在Trace之外额外打一套编排业务事件以JSON格式落到日志中心。原因是标准Trace对技术栈友好的但对业务语义不友好——协作平台里的人可能看不懂一个Span到底代表调了工具A还是切了模型B。实际做法是让Trace负责底层的调用链关系比如每个节点的耗时、上下游依赖而业务事件负责表达这一步做了什么决策、为什么这样做。例如{ event: tool_invocation, requestId: 7f3c4a..., tool: order_query, argsHash: ab12cd34, resultStatus: success, durationMs: 452, fallbackTriggered: false, tokenCost: 0, timestamp: 2025-01-15T10:00:12.123Z }这样每个用户请求都形成了一条完整的时间线。某个环节发生了降级、重试、超时一眼就能看清楚。排查线上问题时我通常先看业务事件列表确定异常点再跳到Trace里看更细的调用链效率比从前翻日志高很多。5.3 一次故障排查的完整链路举一个实际发生过的例子。某天下午智能助手突然大面积报回答超时。我们第一反应是怀疑模型服务故障拉出事件时间线后发现从入口进来的请求全部阻塞在知识库检索这个节点上等待时长高达8秒而后面的模型调用还没开始。再展开业务事件发现向量检索的并发在那一刻到达了连接池上限大量请求在排队等待连接。进一步查Trace确认不是模型服务问题而是之前一天我们调整了知识库集合的索引配置导致检索慢了一个数量级。整个过程从接到报警到定位根因花了不到20分钟。如果没有编排层的业务事件和Trace可能要到第二天才能定位。这个案例给我的教训是AI编排层的可观测性不是可选项而是和业务逻辑一样重要的核心模块。在高可用系统里任何一个节点故障都应该在观测面板上能被迅速定位。建议团队在系统建设初期就为每个关键节点埋好日志和指标不要等出了事故再补。6. 部署与演进从单机编排到可扩展架构的坑6.1 无状态水平扩展前的四个改造点很多编排服务早期都是单机部署没有会话粘滞请求随便路由也能正常跑。当你打算水平扩展到多副本时会发现有几个潜藏的问题必须提前处理。第一会话上下文已经挪到外部存储之后代码里要彻底清理所有本地内存缓存尤其是模型调用结果缓存。如果有本地缓存节点A的缓存命中可能跟节点B不一致表现为同样的请求在不同节点上手感不同。第二在途任务的处理方式要明确。编排层接收到一个请求后如果请求在节点A上执行到一半节点A被滚动更新掉这个任务是被中断还是被转移到节点B我建议把执行中的任务设计成可恢复的只要状态表里有完整步骤记录新节点就可以从断点续跑。如果做不到续跑那至少要优雅终止且返回可理解的错误信息不要让用户看到一个永远转圈的界面。第三分布式锁要跟着走。某些工具调用不允许并发比如同一个用户的连续操作单机部署时用进程内锁就够了多副本后必须改为Redis分布式锁或数据库锁。否则两个节点同时帮同一用户操作同一个外部系统会产生严重的数据一致性问题。第四限流要从单机限流改成分布式限流。每个节点的限流器如果只统计本机流量整体额度就会变成节点数倍。我见过某团队在扩容到5个节点后把原本设计的上游QPS限制撑大了5倍导致上游告警。比较省事的做法是在编排层前面统一进入一个分布式限流中间件或者用Redis做令牌桶。特别在限流策略涉及成本预算时分布式限流几乎是必须的。6.2 连接池与限流的配合AI编排服务通常要跟多个上游打交道模型服务、知识库、外部业务API、Redis。每个上游的连接池大小都需要根据实际并发量去调节。我遇到过的问题是连接池配置过小比如默认给模型服务分配了100个连接但业务高峰期需要300个并发结果大量请求在连接池排队。这个时间又被统计进上游耗时导致上游P99延迟飙升编排层误判为上游故障触发了很多不必要的降级。正确的做法是不要把连接池配置和超时配置割裂开。连接池本质上是阻塞资源连接满了超时时间再长也是白等。我的经验是连接池大小至少要能覆盖该路依赖的峰值QPS乘以平均耗时再加上一定余量。比如模型调用峰值QPS是50平均耗时3秒那连接池至少需要150个连接才不阻塞。当然这只是粗略估算真实还要考虑上游的连接并发限制。同时分布式限流的阈值也应和连接池大小匹配避免限流允许的请求量超过连接池能承载的量。否则限流还没生效连接池先被打满。6.3 灰度发布时的编排兼容问题编排层和普通服务不同它经常要面对新编排逻辑和旧上下文状态同时存在的情况。发布新的编排规则后如果有一个在旧版本里已经执行了一半的任务被路由到新版本的节点上新逻辑可能认不出旧状态表里的某些节点ID或字段结构。这个问题在灰度发布时尤其突出。方案之一是做好状态增量演进状态表里加版本号字段。新版本读取旧版本数据时先做一层兼容解析不认识的字段忽略缺省字段给默认值。方案之二是在发布期间保留一小部分旧节点承接在途任务等到所有在途任务自然结束再下线旧节点。方案之三是深度优先的任务主机亲和在任务开始执行时绑定一个编排版本标识后续步骤尽量路由到同版本的节点上处理除非节点不可用。我在模拟项目X里实践下来第三种方案最实用也让灰度风险最小。简单说状态表里写清楚该任务使用的编排版本号路由层发现同一任务要尽量调度到同版本实例。这虽然牺牲了一点负载均衡的均匀性但换来的稳定性非常值得。6.4 对高可用的一点个人感受整套系统重构完以后我的一个明显体会是AI编排层的高可用更多在于怎么失败得优雅而不是怎么保证永远不失败。模型服务会有波动外部工具有不可用的时候网络也会有抖动这些都是事实。编排层能做的是通过合理的超时、重试、幂等、状态存储、降级梯队、可观测性设计让每一次失败都呆在可控范围内不让单点故障演变成系统性雪崩。还有个心理层面的事也想分享不要追求把每个依赖的SLO都调到99.999%那既不现实也极昂贵。把注意力放在编排层自身的韧性上——失败时能否快速恢复降级是否无缝排查是否能20分钟内定位。对我这种实际干活的人来说这种韧性比一个漂亮的数字更让人安心。