Agent成本爆炸？五把刀教你从Token消耗到架构优化全面降本

最近社群里有好几个朋友都在聊同一个话题Agent 跑通了业务方也认可了结果一上量账单先炸了。单个任务跑一遍可能只要几毛钱但并发一上来Token 消耗就像开了闸的水龙头。Uber 这种体量的公司内部 Agent 数量翻了 10 倍AI 账单却没有同步飞涨靠的不是某一个大模型降价而是五把很务实的刀。这篇文章就把这五把刀拆开讲清楚每个策略我都会给到具体的落地思路和实操中的坑。1. 先盘一盘Agent 的成本到底贵在哪个环节聊降本之前得先搞清楚钱到底烧在哪里。很多人一开始只盯着大模型的 Token 单价觉得换个便宜点的模型就能解决问题但真正跑过规模化的人都知道账完全不是这么算的。1.1 一次 Agent 任务的真实成本拆解一个 Agent 执行一次完整任务消耗的 Token 远不止用户提问 最终回答这两部分。我拆过一个典型的客服类 Agent一次任务大概要经历意图识别、信息检索、工具调用、结果校验、回复生成这几个阶段。其中工具调用往往要反复好几轮每一轮都要把当前对话上下文、工具返回结果重新发给模型这部分 Token 消耗比最终生成回复要高出好几倍。举一个更直观的例子用户问一句我上周的订单为什么还没到如果这个 Agent 需要查询订单系统、物流系统、可能还要查一下支付记录每次查询都是一次独立的工具调用。三次调用下来累计的输入 Token 可能已经上万而用户看到的那句回复可能只有几百 Token。所以实际成本模型是单次任务成本 Σ(每轮调用的输入 Token 输出 Token 工具返回 Token)。理解了这一点才能真正明白后面的每把刀是在砍哪里。1.2 规模化的成本失控点Agent 数量翻 10 倍的时候如果只按单次任务成本线性估算那确实会吓人。但真正导致账单失控的往往不是线性的调用量增长而是几个非线性因素第一个是上下文窗口的无限制膨胀长会话任务越跑越贵第二个是失败的重复尝试一次工具调用报错Agent 可能会重试好几次第三个是过度设计很多任务明明用不到大模型的推理能力但默认全部走最强的模型。Uber 这类平台的特殊性在于他们的 Agent 场景往往有明确的 SLA 要求比如乘客端的地图搜索、地址标准化、ETA 预估。这些场景单次任务价值低、但调用频率极高。在这种场景下成本优化的敏感度会比做高价值科研任务的团队更高因为每一分钱都要从利润率里扣。2. 第一把刀模型路由分发让便宜的模型干便宜的活第一把刀也是最立竿见影的一把刀不要把所有的请求都丢给最强的模型。这不是什么新概念但在 Agent 架构里做起来比传统 API 网关要复杂得多因为你需要判断的不是这次请求是分类还是翻译而是这个 Agent 子任务需要多强的推理能力。2.1 路由层的核心逻辑任务分级定价我习惯把 Agent 里的子任务分成三个等级。第一级是纯提取和格式化任务比如从用户输入里抽出发货地址、把日期格式标准化这类任务用最大参数模型的推理能力完全是浪费中小模型就能做到 98% 以上的准确率。第二级是需要一定理解能力的任务比如判断用户意图是退货还是换货这需要模型有不错的语义理解能力。第三级才是真正的复杂推理任务比如多个约束条件冲突时的决策、跨系统数据综合判断这些场景才值得动用旗舰模型。路由层就是在这三个等级之间做分发。落地的时候可以基于历史日志训练一个小型分类器也可以直接定义一个规则引擎先看任务类型再看输入长度和复杂度特征最后加一层模型置信度兜底。Uber 在地址解析这种高频场景里大部分请求都会被分到中小模型旗舰模型只保留了大约 10% 的流量。2.2 路由层的工程落地细节路由层本身也会产生成本而且它会成为新的瓶颈这个必须提前想清楚。我见过不少团队在路由层调用一个大模型做分类结果是省下的钱又被路由层的 Token 消耗吃掉了。比较稳妥的做法是优先用规则和轻量分类器处理能明确判断的任务只有模糊任务才升级到模型分类。比如你可以把路由判断做成两级——第一级用关键词和正则匹配能命中就直接分流命中不了的再丢给一个小型分类模型。路由层的响应时间也要监控因为它相当于给所有 Agent 任务增加了一道前置转发。路由分发还有一个容易忽略的问题同一个任务对于不同用户、不同上下文可能需要的推理能力是不同的。所以路由层最好能拿到当前任务的关键上下文特征而不是只看任务名。比如用户发起退款申请这个任务如果用户附带了一段很长的投诉说明那需要的推理能力就比简单退款要高这时候要把任务升级到复杂模型。2.3 质量回环路由不能只分不查路由分发做久了会遇到一个典型问题分到小模型的任务偶尔会出现质量下降但整体准确率看着还可以于是问题一直被掩盖。我的建议是建立一个大模型审计机制每天随机抽 5% 的小模型处理结果用最强的模型做离线二次判断把误判案例回流到路由策略里做调整。这个比例不用太高5% 的审计成本完全可以接受但它能帮你守住质量底线。没有质量回环的路由分发本质上是在盲人骑瞎马——省了钱但可能正在一点一点丢失用户体验。3. 第二把刀上下文瘦身别让 Agent 背着一整本百科全书跑Agent 和普通 API 调用的最大区别就是它要带着上下文跑。这个特性既是 Agent 智能的来源也是 Token 消耗的大头。相同任务上下文管理得好不好成本可以差出 5 到 10 倍。3.1 上下文膨胀的三个隐蔽来源上下文膨胀通常来自三个地方。第一个是多轮对话的全量保留Agent 每执行一步都要把完整历史发给模型跑了 20 轮之后历史文本比当前任务本身大得多。第二个是系统提示词的冗余堆叠每次迭代在系统提示词里加一条指令加到最后这个提示词本身可能就有几千 Token而且每轮都要全量发送。第三个是工具返回结果的全量注入一个工具接口返回了 5000 Token 的 JSONAgent 其实只需要其中两个字段但你把整包都塞给了模型。三个因素叠加上下文窗口很容易就从几千 Token 膨胀到几万甚至十几万。而 LLM 当前的计费模式输入 Token 尤其是长上下文部分的成本占比相当高所以每省下 1 万的输入 Token都是在直接扣减账单。3.2 动态上下文管理的三种实操手段第一种是系统提示词静态化与长度治理把长期不变的指令、角色设定、业务规则抽出来在每次请求时用模板填充变量而不是让 Agent 自己在历史里总结。系统提示词的每一行都要定期审查删掉已经没有用的历史指令。第二种是对话历史的分段裁剪设定一个窗口大小只保留最近几轮完整对话更早的历史用一段摘要来代替。如果摘要压缩得足够好一整个长会话的历史可以被压缩到原来 Token 数的 10% 到 20%。这里要注意不要只在会话开始的时候做一次摘要而是要在整个会话过程中持续维护一个滚动摘要每轮结束后把新内容增量合并进去。第三种是工具返回结果的结构化截断在把工具结果交给模型之前先做一次字段级别的过滤只保留模型真正需要的字段。这个步骤可以用一段简单的 JSON Path 或 XPath 表达式实现成本几乎可以忽略但效果却立竿见影。3.3 摘要记忆的经验边界滚动摘要的做法有一个实际代价摘要会丢失细节。比如用户在一个小时前提过一个订单号后面所有轮次都在围绕这个订单号讨论摘要大概率会把订单号保留下来但如果用户在两轮前提到过一个具体的时间点摘要里很可能就丢了。我的经验是设置一个关键信息提取层在生成摘要之前先单独提取当前上下文里的业务实体订单号、地址、金额、时间等把这些实体以结构化字段的形式单独保存摘要正文只保留语义层面的内容。这样即使正文摘要压缩得很狠关键业务字段也不会丢Agent 后续要用的时候可以直接从结构化字段里取。4. 第三把刀缓存复用同样的活不要干两遍如果你已经做了模型路由和上下文瘦身接下来最值得动手的就是缓存。Agent 领域里的缓存比传统后端缓存复杂一些但收益也更大。很多高频任务其实是在反复请求相同或者非常接近的结果把这些结果直接复用了Token 消耗就能直接归零。4.1 两级缓存精确缓存与语义缓存Agent 场景里的缓存至少要做两层。第一层是精确缓存适合参数完全一致的重复请求。比如同一个订单的状态查询、同一个地址的标准化结果直接用请求参数的哈希值做 Key命中就直接返回完全不需要再调用模型。第二层是语义缓存适合请求不完全一样但语义等价的场景。比如用户问我要退货怎么办和想退掉我刚买的商品步骤是什么这两句话在字面上完全不同但意图和所需答案是高度重合的。语义缓存的做法是在第一次请求时把问题和答案都存下来后续请求先通过 embedding 计算相似度相似度超过阈值就直接返回缓存结果。4.2 缓存分层的实际落地精确缓存的实现很直接Redis 加一个 TTL 就能搞定。关键在于 Key 的设计要把 Agent 的任务类型、业务参数、上下文摘要版本号都包含进去避免不同上下文的请求互相污染。带时间敏感性的数据比如实时 ETA不能缓存这一点要靠业务规则来约束不能只靠 TTL。语义缓存麻烦一些。每个缓存条目都要算 embedding 并建索引查询时要先对当前请求做 embedding再和最相似的历史条目做距离计算。为了控制性能开销可以先用一层粗筛基于任务类型和关键实体做候选集缩小只在候选集里做相似度计算。我见过一上来就全局算相似度的方案延迟直接多了一两百毫秒这在核心链路里是扛不住的。4.3 缓存命中率上不去的真实原因很多人做完缓存后发现命中率低得可怜连 20% 都不到。我排查过好几个类似项目原因出奇地一致不是技术问题而是请求的自然分布太零散。用户的问题各有各的说法即使语义相同也很难保证语义相似度超过阈值。解决思路是不要只缓存最终答案还要缓存中间步骤。比如一个用户咨询退货政策的任务虽然每个用户的具体问题不同但查询退货政策这个工具调用结果是一样的。把工具调用结果缓存下来后面的生成阶段还是要调模型但检索阶段的 Token 消耗已经省掉了。这是一种过程缓存的思路可能比结果缓存命中率更高也更容易落地。还有一个建议引入缓存预热。挑选历史请求里 Top 100 的高频问题在业务低峰期提前生成结果并写入缓存。这样一上线就能看到比较可观的命中率运营层面也更有信心。5. 第四把刀并行编排与批处理把时间成本转换成钱Agent 里经常会出现一个任务包含多个相互独立的子步骤的情况。如果按默认流程串行执行每一步都要单独等待模型响应整个过程耗时长账也越挂越高。把可以并行的步骤同时跑起来既能缩短整体响应时间也能减少不必要的重算。5.1 依赖分析哪些步骤本来就可以并行假设一个场景用户要预订一辆去机场的车。Agent 需要同时确认用户当前位置、查询机场航班到达时间、检查道路拥堵情况、估算费用。这四个子任务是相互独立的完全可以在同一轮并行调用。但如果你的代码是按顺序写下来的先查位置再查路线再查费用那整个过程会被迫拉长三倍而且每一步的设备资源都要重复准备。实现并行编排的技术方案并不复杂把 Agent 的工作流改造成 DAG每个节点是一个子任务只有存在依赖关系的节点之间才加边。很多成熟的 Agent 框架已经内置了 DAG 编排能力你可以直接声明依赖关系框架负责并行调度。改造的关键是找出哪些步骤之间存在真实的依赖这一步要跟业务方逐条核对不能拍脑袋。5.2 批处理聚合的账如何算比并行更进一步的是批处理聚合。把多个用户的相同类型请求合并成一次模型调用再在返回结果里做切分。比如在客服场景里查询订单状态这类工具调用如果同时有 20 个用户发起请求与其逐个调用不如把这 20 个订单号打包成一个请求发给模型让模型一次返回 20 个结果。这个做法的成本优化效果非常明显。一方面模型的请求处理有固定开销合并后可以摊薄这部分开销另一方面大批量输入的输出 Token 往往比小批量累加要低。但要注意批处理并不适合所有场景如果其中有任何一个请求是时间敏感的整批都会被拖慢。所以批处理聚合通常只用在非实时、可延后的任务上。5.3 编排层省钱的三个判断法则结合我踩过的坑总结出三条判断法则。第一条能并行的不要串行因为串行不仅慢还可能导致后面的步骤在错误的前置结果上计算白白消耗 Token。第二条能聚合的不要单发但先确认响应时间要求。第三条能跳过的不要走完并不是每个任务都需要走完 DAG 里的所有节点条件满足可以直接走捷径逻辑跳过不必要的子步骤。我见过一个很典型的浪费同一个任务里既有判断用户是否是会员的节点又有查询会员专享优惠的节点但前面的节点已经判断出该用户不是会员后面的节点依然被无条件执行白白调用了一次大模型。这种冗余节点排查一遍就能发现一堆每发现一个就是在直接省钱。6. 第五把刀重试与容错把失败成本压缩到最低Agent 和传统接口不一样它的执行链条更长任何一个工具调用失败都可能引发连锁反应。很多团队的默认做法简单粗暴——失败就重试重试还不行就整体报错。这套逻辑下的成本往往很惊人。6.1 一次失败重试的真实账单假设你的 Agent 在一次任务中调用了一个下游接口接口超时了。如果代码里写得是简单的重试三次那这次任务的成本会变成什么事情呢每次重试都会把当前上下文完整地重新发送给模型而随着会话推进上下文越来越大。第一次失败的上下文可能是 8000 Token第二次重试时因为多了一轮错误信息上下文涨到 1 万第三次涨到 1.2 万。三次重试下来实际消耗是基础成本的 3 倍以上而不是简单的 3 次×基础成本。更要命的是如果重试是同步阻塞的Agent 还会在等待期间持有资源整个执行引擎的资源利用率也会同步下降。对于一个要撑住 10 倍 Agent 规模的系统这种浪费是致命的。6.2 智能重试策略的工程实现智能重试不是简单地限制重试次数而是要给重试加上几个约束维度。第一个约束是重试次数与退避默认最多重试两次采用指数退避加抖动。第一次重试的间隔是 500 毫秒第二次是 1.5 秒。抖动的作用是防止多个 Agent 在同一时刻对同一个下游服务发起重试造成雪崩。第二个约束是错误类型感知下游接口返回的错误可以分为可恢复和不可恢复。限流、超时、暂时性的 5xx 基本都是可恢复的可以走重试逻辑。但认证失败、参数格式错误这类问题是重试多少次都不会成功的直接放走不要再浪费任何一次 Token。第三个约束是分支降级重试仍然失败时不要让整个 Agent 任务失败而是触发降级分支。比如用静态缓存数据替代实时查询或者换一个更便宜的模型完成简版回答。降级分支消耗的 Token 远低于一次完整重试但至少能给用户一个可用的结果。6.3 幂等设计是重试的底线还有一个很多人忽略的前提——重试的前提是被调用的接口是幂等的。如果 Agent 调用的是一个创建订单接口网络超时后你发起重试结果可能产生两笔订单。这种场景下重试策略再精巧都是灾难。所以我要提醒在给任何 Agent 步骤加上重试逻辑之前先确认下游接口是否支持幂等。如果不支持要么让下游加一个幂等键requestId 机制要么上游负责去重。没有幂等保护的重试省下的钱远远不够赔偿业务损失。7. 这五把刀的组合打法与落地顺序五把刀都介绍完了但现实中没人会一次性全部落地。根据团队现状和业务阶段应该有一个清晰的落地顺序和组合策略。7.1 不同阶段的策略优先级我给的建议是分三步走。第一步先把上下文瘦身和缓存复用做掉这两个策略不改动任务分发逻辑对业务侵入最小而且见效最快。通常一周左右就能在账单上看到明显变化团队也比较容易接受。第二步再上模型路由分发。这一步需要跟业务方对齐质量标准也建议同步建立质量回环机制。因为路由是主动改变模型的逻辑风险比前两步高但收益也最大。第三步才是并行编排和重试容错。这两个策略需要对 Agent 的工作流有全局认知改造成本最高而且涉及跨系统的接口依赖梳理更适合放在中期来做。不过一旦做完系统整体的稳定性和资源利用率都会有质的提升。7.2 需要长期盯住的核心成本指标降本不是一个一次性动作而是一个持续运营的过程。我建议每个团队都在监控面板上长期盯这四组指标单任务平均 Token 消耗、每千次成功任务的模型成本、缓存命中率和路由小模型分派占比。单任务平均 Token 消耗是最直观的指标它的波动能直接反映上下文管理是否在恶化。每千次成功任务成本则把模型价格变动排除在外让你能看到真实的策略效果。缓存命中率不用追求极致我见过很多团队非要卡在 40% 以上结果缓存占用的存储成本比省下的模型钱还多要结合实际场景找到合理的命中率区间。路由小模型分派占比反映的是你让小模型干活的实际比例一个典型的理想状态是 60% 到 70% 的流量都走小模型旗舰模型只保留核心推理。7.3 成本治理的组织保障最后一个容易被忽视的点成本治理不是几个工程师的事它需要产品、算法、工程三方共同参与。我参与过的项目里只要是降本效果能持续稳定下来的都建立了一个轻量的成本治理例会机制每两周过一次数据和策略执行情况。产品负责判断哪些任务可以接受小模型的质量下限算法负责优化路由策略和质量回环工程负责监控和报警。这个机制不需要很重甚至可以只是一个共享的看板和每两周半小时的对齐会议但它可以保证策略在不断变化的数据面前不被搁置。五把刀没有一把是花哨的黑科技也没有一把需要推翻现有系统重来。价格再低的模型也架不住无节制的 Token 消耗真正决定规模化成本上限的是工程侧对整个执行链路的精细化治理。希望这篇文章能帮你在做 Agent 规模化的时候少走一些我用账单换来的弯路。