凌晨两点客服群的告警弹出来的时候我差点把咖啡打翻Redis 集群 CPU 直接飙到 90%客服 Agent 的日志里刷满了同一种错误——exceeded retry limit, last status: 429 too many requests, request id: ...。不用看监控我都能背出后面的剧情大模型供应商限流了我们的重试逻辑又太“死脑筋”把网关线程池挤爆了最终整条客服链路全挂。那阵子我们每天被 429 搞得焦头烂额直到后来把客服 Agent 的底模整体切到 Flash 方案成本降到了原来的 15%429 导致的雪崩也基本绝迹。这篇文章就把从“被限流打挂”到“用 Flash 止血”的完整过程写出来包含成本测算、迁移步骤、限流保护和一些踩坑记录应该适合正在做 Agent 落地、被上游 API 配额折磨的团队参考。1. 客服 Agent 为什么会死在 429 限流上1.1 429 不是“请求太多”四个字那么简单HTTP 429 的官方解释是“Too Many Requests”但放在客服 Agent 的场景里它的破坏力远超过字面意思。客服 Agent 和普通 Web 应用最大的区别在于一个用户问题进来Agent 内部往往要完成多轮上下文处理、知识库检索、工具调用而每一步都可能触发一次大模型 API 请求。也就是说用户侧只有 1 个请求上游 API 侧可能对应 3 到 5 个甚至更多调用而且调用链是串行的任何一个环节被限流整个用户请求就卡死在那里。服务商做限流本质上是保护自己也是商业策略的体现。每个账号都会有 RPM每分钟请求数和 TPM每分钟 Token 数限制你的用量超过配额服务端直接返回 429。很多团队早期只把 429 当成一种普通网络异常没有设计好重试和熔断结果在流量高峰期前几个请求被限流后续所有请求都在等待重试线程池被打满新的请求又进不来——这就成了典型的生产事故。我见过最夸张的一次事故是某次大促活动客服 Agent 同时在线会话数暴增三倍核心链路每个会话要调用两次大模型 API加上重试实际每秒发出的请求量是配额的几十倍。服务商返回 429 后我们的客户端代码还在以固定间隔疯狂重试最终不只是 Agent 服务崩了连带的登录、工单系统也因为共享线程池被拖垮。所以429 实际上是一个信号你的消费模型和上游配额之间已经严重不匹配了。1.2 还原一次典型的“被打挂”过程把时间拨回到事故发生的那个下午。上午 10 点业务流量开始爬坡我们收到第一波监控告警大模型 API 的错误率从 0.1% 跳到 5%。查看日志出现的是Error: exceeded retry limit, last status: 429 too many requests, request id: 23cbdc...这句话的意思是SDK 内部已经按照默认策略重试了好几次仍然收到 429最终抛出了异常。但我们的 Agent 外层还有一个历史遗留的重试代码遇到任何异常都会再追加两次重试。于是一次用户请求最多可能对上 6 次 API 调用在限流状态下这些重试几乎全部命中 429。紧接着调用大模型的线程池被打满队伍越来越长。因为线程一直没有释放CPU 和内存也在飙升。到了 10 点 15 分网关开始主动丢弃请求客服用户看到的提示是“系统繁忙请稍后再试”。最要命的是我们当时没有做熔断导致流量继续往即将崩溃的服务上打最终整个 Agent 集群连续两次扩容后仍然处于半瘫痪状态直到服务商那边的配额窗口刷新流量降下来服务才慢慢恢复。事后复盘我们发现真正的问题有三个第一对上游限流策略不了解没有处理Retry-After响应头第二重试机制没有退避形成重试风暴第三单次调用的模型太贵太慢导致我们不敢把请求分散到更多配额上也不敢轻易提升并发。所以解决 429 不能只盯着“重试”要从模型选型和调用架构一起改。1.3 限流背后的原理以及我们能改变什么大模型 API 的限流通常有两个维度一是请求频率也就是 QPS 或 RPM二是 Token 消耗速率也就是 TPM。即使你每秒只发一个请求只要每个请求的 Token 数很大依然会触发 TPM 限流。客服场景里特别是使用了长上下文的 Agent每次请求都要带上历史消息和检索出来的知识片段很容易导致 Token 消耗暴涨还没到请求次数上限就先撞上 Token 限额。既然服务商为了保护系统而限流我们不能去改服务商的规则但能改变自己的消费模式。最有效的思路是两条要么降低单次调用的成本让同样预算下可以申请更高配额或者承担更多调用要么减少无效调用比如去掉疯狂重试、缓存重复问题、控制输出长度。我们后来把底模切到 Flash 方案本质上是同时触达了这两条路——既降低了单次调用价格又因为响应更快、输出更短间接减少了 Token 占用。另外一个容易忽略的点是很多团队把 429 视为纯技术问题忽略了它和产品层面的耦合。客服 Agent 适合什么模型不只取决于模型能力还取决于你的业务容错度。如果业务上允许 20% 的答案不够完美、允许“兜底转人工”那么完全可以用更便宜、更容易获得配额的模型把省下来的钱投入到知识库和提示词工程里去。2. 用 Flash 模型把成本砍到 15% 的选型思路2.1 Flash 模型是什么和重型模型的真实差距这里的 Flash 不是指手机闪存而是各家模型厂商推出的“轻量小模型”系列通常带着 Flash、Turbo、Nano 一类的后缀名。它们的特点是参数量小、推理速度快、价格便宜面向高并发、对延迟敏感、对绝对智商要求不高的场景。用生活里的话说重型模型像米其林大厨能为你定制复杂的创意菜品Flash 模型则是标准化的快餐连锁出餐稳定、价格便宜适合一天几千单的生意。在客服 Agent 这个场景里我们真正需要的是什么绝大多数用户问题其实都是重复的查余额、改地址、退换货、催发货。这些问题根本不需要顶级的推理能力只要能从知识库里找到正确答案并用通顺的话表达出来就行。Flash 模型在指令跟随、结构化输出、常用知识问答上的表现已经足够好真正弱的是复杂推理、长链路规划和抽象理解。也就是说只有一小部分疑难问题需要重型模型出马。从实际出发我们测试过几个 Flash 类模型初始化阶段明显感觉到几个差异第一对 prompt 的敏感度更高同样一段提示词重型模型能“猜”到你的意思Flash 则需要你写得非常明确第二输出长度偏好不同Flash 往往倾向于简洁如果不显式要求它会把回复压得很短这在客服场景里反而是优点第三在工具调用function calling上Flash 对参数格式的容错率低一些但只要我们严格校准输出格式也能稳定运行。2.2 成本测算为什么能降到 15%我们之前的客服 Agent 使用的是重型商用模型按 Token 计费每次客服会话平均消耗输入约 1200 Token输出约 600 Token。当时我们的日均调用量大概在 80 万次算下来每天的 Token 费用大约是 1200 美元。对于一家中大型电商的客服部门这个成本虽然不至于伤筋动骨但老板看了也肉疼。换到 Flash 之后模型单价大约降为原来的六分之一到八分之一我们再把输出长度限制得更紧平均每次会话的输出 Token 从 600 压到了 450加上一些缓存命中的优化最终综合成本降到了原来的 15% 左右。具体数字如下表项目原重型模型Flash 模型输入价格美元/百万 Token5.000.60输出价格美元/百万 Token15.002.00每次平均输入 Token12001000每次平均输出 Token600450日调用量万次8090日成本美元1200162日成本从 1200 美元降到 162 美元换算下来是 13.5%和标题里的 15% 差不多。而且因为价格低了我们敢于申请更高的配额把日调用量提升到了 90 万次覆盖更多的客服会话整体服务能力反而更强了。这也是“成本降到 15%”的另一层含义不是单纯省钱而是用同样的预算撑起更大的业务盘子。这里给所有准备迁移的团队一个建议先别急着拍脑袋换模型把过去一两周的调用日志拉出来统计平均输入 Token、输出 Token、日均调用量、分时段峰值再拿到新模型的价目表去算总账。算完之后你就会知道换 Flash 能省多少钱以及你需要把输出长度压缩到什么程度才能达到预期比例。2.3 从重型模型迁移到 Flash 的迁移清单迁移不是改一行 model 参数那么简单否则你会在线上看到各种莫名其妙的翻车。我们当时整理了一份迁移清单照着执行才稳稳接住。第一定义能力边界。先把客服的知识库问题分类退换货、订单、物流、支付、售后等。给每个类别做 20 条典型测试用例用 Flash 和重型模型跑一遍对比答案质量。如果某类问题 Flash 的准确率低于 85%就把这类问题标记为“高危”后续路由到重型模型或直接转人工。第二重写提示词。Flash 模型对冗长、模糊的提示词不敏感你需要把提示词改成结构化的“角色规则检索结果用户问题输出格式”。我们一开始偷懒直接搬用重型模型的系统提示词结果 Flash 经常答非所问。重写之后格式统一变成你是客服助手。只根据以下【知识库】内容回答不要编造。 【知识库】 检索结果 【用户问题】 用户输入 如果知识库没有答案请输出需要转人工。 输出格式不超过三句话不附解释。第三适配输出格式。客服 Agent 内部需要结构化结果来做后续动作比如“是否需要转人工”“用户情绪是否愤怒”。Flash 模型对 JSON 输出的遵循度比重型模型差一点我们需要在请求参数里显式指定 response_format并且在解析时做容错处理——如果 JSON 解析失败用正则兜底提取关键字段。第四搭建回归测试集。迁移期间每天早上用固定的 200 条测试问题跑一遍新模型把“正确率”“误判率”“转人工率”记录到一个表里。连续观察一周如果质量稳定再逐步扩大线上流量。我们当时是 10%、30%、50%、100% 这样灰度放量每一步都盯监控。第五保留一键回退开关。在配置中心做一个开关如果 Flash 模型抽风可以一秒切回重型模型。这个开关在节假日大促期间格外重要以防模型服务商那边也出现性能波动。3. 落地实操客服 Agent 接入 Flash 模型全流程3.1 环境准备和 API 参数配置我们的 Agent 服务用的是 Python底层通过 OpenAI 兼容的 SDK 去调用各家模型的 API。切到 Flash 之后最直观的变化是修改配置文件的 model 字段和 base_url。这里有一个容易踩的坑不同服务商的 Flash 模型名称前缀很不一样而且有些 Flash 版本还分“长上下文版”和“标准版”选错了会直接报 invalid model。配置文件大致长这样llm: provider: openai_compatible base_url: https://api.example.com/v1 api_key: ${LLM_API_KEY} model: flash-1.5-standard temperature: 0.3 max_tokens: 512 timeout: 10对于客服场景我不建议让 max_tokens 设置得太大。输出越多成本越高而且延迟越久更容易引发超时重试。我们后来把 max_tokens 全局限制在 512个别需要长回答的场景单独传参。另外超时时间也要单独设置Flash 模型虽然快但偶尔也会被网络波动影响如果超时设置太短比如 3 秒反而会造成不必要的重试设置太长又会导致请求堆积。我们最终用的是连接超时 5 秒读取超时 10 秒。还有一点Agent 在调用大模型时通常要附带历史消息。历史消息是 Token 消耗的大头在迁移 Flash 后尤其要注意控制上下文长度。我们的做法是做一个滑动窗口最多保留最近 6 轮对话遇到超长历史就用摘要模型先把更早的内容压缩成一段话再拼进当前上下文。这样既保住了上下文信息又避免 Token 浪费。3.2 关键参数temperature、max_tokens、重试策略怎么调Flash 模型在客服场景里的参数调整和重型模型差异还挺大。重型模型我们以前用 temperature0.7出来的回答像真人一样流动但 Flash 本身表达风格偏平如果再调高 temperature容易出现语句碎片化和逻辑跳跃所以我们直接压到 0.2让回答尽量确定。即使这样为了保证关键操作比如退换货链接、退款金额百分百准确我们还会把敏感信息从模型回复中剥离出来通过工具接口去真实数据库查证。重试策略是整个 429 事故的命门。原来我们用的是 SDK 默认的固定间隔重试遇到 429 会立刻重试效果极差。后来我们改成了指数退避加随机抖动第一次重试等 1 秒第二次等 3 秒第三次等 7 秒最多三次。每次重试前检查响应头里的 Retry-After 字段如果服务商明确告诉你要等多少秒就无条件等到那个时间。代码大致如下import time import random import requests def call_llm_with_retry(api_request): max_retries 3 for attempt in range(max_retries 1): response requests.post(**api_request) if response.status_code 429: retry_after response.headers.get(Retry-After) wait_time float(retry_after) if retry_after else (2 ** attempt random.random()) time.sleep(wait_time) continue return response raise RuntimeError(exceeded retry limit, last status: 429 too many requests)注意重试只对瞬时限流有效。如果 429 已经持续了几分钟说明上游配额耗尽此时应该快速失败并降级而不是继续重试。我们在代码里加了一个简单的熔断如果一个窗口内 429 的比例超过 30%就停止后续调用直接返回“客服繁忙请稍后再试”让流量在入口处被挡掉保护下游系统。另外日志里一定要记录request_id。这是你和模型供应商沟通的唯一凭证没有它出了纠纷你根本无从举证。我们会在每次 API 调用的日志里打上model、request_id、latency、token_usage、status_code后面查问题非常省事。3.3 配套限流保护Redis 令牌桶实现 Agent 端自我保护换了个便宜的模型并不代表你可以无限量地调用。恰恰因为便宜大家可能更不注意节制结果还是会在某个时间点把上游配额打满。所以我们在 Agent 服务内部又加了一层令牌桶限流把单位时间内的 API 调用数控制在一个安全值以内宁可让用户排队也不要触发上游限流。Redis 是实现分布式令牌桶的常见选择坑在于并发环境下要保证原子性所以最好用 Lua 脚本实现。下面是我们用的一个简化版令牌桶脚本它工作在水位线上每个业务线一个 key每秒补充一定数量的令牌每次调用扣一个令牌令牌不足则拒绝。-- KEYS[1]: bucket key -- ARGV[1]: capacity -- ARGV[2]: refill_rate (tokens per second) -- ARGV[3]: request_time (current timestamp) local bucket redis.call(HGETALL, KEYS[1]) local tokens tonumber(bucket[2] or 0) local last_refill tonumber(bucket[4] or ARGV[3]) local capacity tonumber(ARGV[1]) local rate tonumber(ARGV[2]) local now tonumber(ARGV[3]) local delta math.max(0, now - last_refill) tokens math.min(capacity, tokens delta * rate) if tokens 1 then return 0 end tokens tokens - 1 redis.call(HSET, KEYS[1], tokens, tokens, last_refill, now) return 1调用这个脚本时我们会根据上游配额自动计算速率。例如我们的模型供应商允许 3000 RPM折算下来是每秒 50 个请求。我们把这个值再打个八折设置成每秒 40 个令牌给突发流量留点余量。这样做的好处是即使运营同学做了一次全员推送Agent 端的调用速率被限制在安全范围内上游永远不会因为我们的并发过高而返回大量 429。另外如果你用的是 Spring Cloud 微服务也可以考虑用 Sentinel 做集群限流如果项目比较简单可以用 AOP 注解的方式在 Service 方法上直接标注限流阈值。不过这些更偏网关和接口层的防护对于 Agent 内部大模型调用这种资源级限流Redis 令牌桶依然是最灵活、最可控的方案。4. 常见问题与排查技巧实录4.1 429 重试死循环retry 策略怎么设计迁移到 Flash 模型后我们以为 429 会消失结果发现并没有。原因很简单Flash 模型虽然便宜但如果你在代码里每个环节都调它调用次数还是会超出供应商给的低规格配额。那段时间日志里频繁出现exceeded retry limit, last status: 429 too many requests, request id: a375b4。排查下来发现是重试策略设计得不合理外层有两个重试器一个是 HTTP 客户端自带的一个是业务代码里自己加的两层重试叠加导致一个请求在失败时会触发 6 到 8 次调用。后来我们把所有重试逻辑统一收敛到一个装饰器里并且约定429 只看 Retry-After网络超时才做指数退避业务异常直接抛出不重试。这样做之后同样的流量下 429 的错误量下降了 70% 以上。这里有一个大家容易忽略的点Retry-After可能是秒数也可能是具体的 HTTP 时间字符串。解析时要兼容两种格式否则重试时机依然不对。另外日志里的request id一定要保留到重试结束后的异常信息里否则当你向服务商提工单时连哪个请求出错的都查不到。4.2 Flash 模型质量不够用怎么办知识库和提示词补偿有朋友看到我们用 Flash第一反应是“客服回答会不会很蠢”。说实话早期确实有一段时间Flash 模型在回答复杂的售后纠纷时会显得答非所问。后来我们用三个招把它给扳回来了。第一招是强化 RAG。把客服语料、产品说明书、历史工单全部切块建索引用户问题进来先去向量库检索最相关的 3 到 5 段内容拼到 prompt 里。Flash 不需要“记得”这些事实只需要从检索结果里“找出”答案这样它犯错的概率低很多。第二招是写死输出模板要求模型按“先说结论再给依据”的格式回复减少自由发挥。第三招是设置置信度兜底我们在 prompt 里明确告诉模型“如果不知道怎么回答就回复‘需要转人工’”并且通过一个分类器判断用户情绪当检测到情绪激烈时直接跳过 Flash把对话转给人工客服。这三招做完Flash 的线上答案合格率从 82% 提到了 94%剩下的 6% 由转人工兜住。表面上看我们省了大模型的钱但知识库和提示词工程的开发成本增加了。要明白Flash 模型的核心用途不是替代重模型的能力而是让你把钱花在更合适的地方。4.3 费用和限流指标监控用日志和告警快速定位最后聊一聊监控。迁移以后如果不对指标做精细化观测成本可能悄悄反弹。我们在日志系统里建立了三个核心指标调用量按 model、接口、业务线分类统计观察不同场景的消耗分布。限流率429 次数占总调用次数的比例超过 5% 触发告警。成本估算根据 token 用量和模型单价实时估算费用按小时展示。这些指标展示在 Grafana 上配合钉钉或企微告警让我们在成本或者限流异常时能及时反应。有一次某个新的知识库插件引入了死循环导致同一个用户问题被重复调用 20 次要不是成本监控异常升高我们根本发现不了。所以别嫌监控麻烦在 Agent 场景里一次小小的配置错误可能就会让日账单翻倍。另外建议把每次调用的输入 Token 和输出 Token 都写进日志。很多模型服务商的 API 响应里有usage字段记得解析并存储。这些数据不仅能用来算成本还能帮助你优化上下文长度——你会发现很多用户问题根本不需要带上全部历史消息截取最近两轮就够了。关于限流告警我们设置了分级提醒429 比例高于 5% 时只发一个普通通知高于 20% 时自动切换到保护模式主动丢弃部分非核心请求同时通知负责人检查上游配额和令牌桶参数。有了这套机制我们再也没出现过一次真正意义上的“被打挂”。我个人折腾下来最大的感受是429 并不是靠着堆机器、无限重试能解决的它考验的是你对上游配额、模型成本和业务熔断的综合掌控能力。Flash 方案也不是单纯“降级”而是用工程的手段让便宜模型在客服这种高频、标准化的场景里扛起主力。最后再分享一个小技巧迁移到 Flash 之后一定要保留一套重型模型作为 fallback通过配置中心做一个开关。因为总会有某个下午Flash 服务端出现波动或者你的 prompt 被一些极端输入击穿那时候手忙脚乱去换模型的滋味可不好受。提前留好后路遇到问题切一下配置比什么都管用。
