开头前阵子帮一家出行平台做AI成本治理他们那边的Agent智能体数量一下子翻到原来的10倍订单查询、路况咨询、客服预判全是Agent在跑。按理说这种调用量涨下去账单应该是直线起飞结果月底一拉报表Token费用几乎和上个月持平。很多朋友问我是不是偷偷换了大模型的亲情价其实不是核心是做了五件事我管它们叫“降本五把刀”。这篇内容不聊虚的全是针对Agent实际运行时的成本结构包括模型路由、上下文复用、工具调用瘦身、任务调度和自托管部署。不管你是用LangChain、Spring AI还是自己用代码写Agent编排这套思路都能直接套。适合所有负责AI应用开发、平台架构或者关注预算的读者尤其适合那种Agent量级已经上来、但账单快压不住火的团队。1. 模型路由10块的活别用100块的模型干1.1 Agent成本大头在哪一次任务要调好几次模型很多人算AI成本时只看“调一次大模型要多少钱”但真放到Agent场景里就发现完全不是这回事。一个Agent处理一个用户问题往往不是一次推理而是多次推理先理解意图再规划步骤接着调用工具获取数据最后生成答案。每一步都是一次完整的模型请求而且每一步都会带上上下文Token消耗是按指数走的。我之前见过一个线上客服Agent用户只问了一句“我昨天打车为什么扣了两次款”这个Agent内部实际跑了六次模型调用第一次做意图识别第二次制定排查流程第三次调订单接口第四次把接口返回的数据整理成摘要第五次和第六次分别做退款判断和话术生成。这里面如果全都用旗舰大模型跑一次交互的Token消耗可能等于普通人写几十条短消息的量。一个月下来几百万次交互那账单不爆炸才怪。所以第一把刀的核心逻辑就是不让所有请求都走同一个模型而是根据任务难度动态选择模型。简单任务用七八B的小模型中等任务用几十B的开源模型只有那些实在绕不过去的高复杂推理才交给商业旗舰模型。这样既不牺牲整体效果又把平均单次成本压到了一个非常低的水平。1.2 怎么做路由意图分桶置信度阈值兜底模型路由不是简单地写几个if-else而是要在真实流量里跑出一个相对稳定的决策面。我的做法是分成三层。第一层是轻量级前置分类用一个很小、响应特别快的模型或规则引擎先把任务分桶。比如一个Agent系统里常见的分类知识库问答、订单查询、内容生成、复杂推理、纯闲聊。这层分类不需要很聪明目的是把“明显简单的任务”和“可能复杂的任务”切开。第二层是置信度阈值。前置分类模型会给每个意图打一个置信度分我内部设定的经验值是0.85。如果某条请求被归为“订单查询”且置信度高于0.85直接走小模型处理如果低于这个值或者分类结果在多个意图之间摇摆就升级到更大的模型重新理解。这个阈值不能拍脑袋定要拿一周的真实流量去回放看不同阈值下准确率和成本的变化曲线选拐点。第三层是兜底机制。每一类路由最终都要有个终极大模型打底避免小模型一顿输出给用户一个完全错误的答案结果还要运营团队去善后隐性成本反而更高。我在系统里设置了一个规则只要小模型生成的置信度低于0.7或者用户对回答点了“不满意”下一次交互立刻升级到旗舰模型并且把这条样本记入后续的路由优化训练数据。实际写起来大概是这样的一个伪代码结构def route_request(task, intent, confidence): if intent in (simple_query, chat) and confidence 0.85: model small-open-source elif intent in (tool_call, extraction) and confidence 0.75: model medium-open-source else: model premium-commercial return dispatch(model, task)这个路由不光能省钱还能提高整体响应速度。小模型的中位推理时间比大模型短得多用户侧感知到的延迟也降下来了属于性价比和体验双赢。2. 上下文复用把重复要烧的Token砍掉2.1 为什么Agent的Token消耗会成倍放大Agent和普通单轮问答最不一样的地方就是它要记上下文。单个用户问题上一次模型通常只需要输入几百个Token但Agent多轮交互时每一次都要把之前所有的对话历史、工具调用结果、中间推理步骤重新发给模型。这个过程我称之为“历史Token滚雪球”。我做过一个记录一个内部办公Agent用户连续问五个问题前后只隔十分钟。第五次请求时系统把前四轮的完整对话、所有工具返回的JSON、两段中间总结全塞进Prompt光这一次请求就有将近一万两千个Token。而其中真正支撑第五个问题的核心信息可能只有五百个Token。其余都是重复搬运每一轮都在为同样的历史内容付两遍钱。Agent数量翻10倍的时候这种浪费就翻了不止10倍因为越往后每一轮都越来越贵。要解决这个问题第一个思路是缓存第二个思路是压缩。2.2 三级上下文策略短缓存、长缓存和语义检索我自己实践下来最有效的方案是把上下文管理分成三级。第一级是精确前缀缓存。很多商业大模型和开源推理框架都支持Prompt前缀缓存如果一段Prompt的开头部分完全一致服务端可以直接复用之前的计算结果。我们就把系统提示词、固定工具说明、组织架构信息全部放在Prompt最前面不参与任何动态拼接。这样不管Agent跑多少轮公共头部只算一次钱。只靠这一条就能省下大概20%到30%的Token成本。第二级是压缩缓存。当一轮对话结束或者中间某段上下文不再会被引用时我会让一个轻量摘要模型把那段历史压成五十个字以内的摘要存进Redis或者内存里。后续请求里不再塞原始对话而是只带摘要。注意这里的摘要模型不能用最强的商用模型不然省下的钱又被摘要消耗吃回去。用小开源模型做摘要质量足够用成本几乎可以忽略。第三级是语义检索。如果Agent跳了好几个场景比如上句话还在聊订单下句话忽然问发票那就没必要把订单相关的所有历史都带进来。我们把历史消息切片、做embedding向量化存进向量库当新问题进来时只检索最相关的几个片段塞回上下文。这个我建议用本地向量库配合一个还不错的Embedding模型检索精确度可以做到九成以上。我还踩过一个大坑早期为了简单把所有历史全量塞进上下文结果效果确实不错但成本直线上升。后来引入三级策略Token消耗直接砍半。这里有一条很重要的经验上下文管理不要只想着“不丢信息”要想清楚“这个Agent到底需要哪些信息才能完成当前任务”主动丢信息往往才是正确的。3. 工具调用瘦身让Agent少跑冤枉路3.1 一个Agent一次任务能烧几次工具Agent最烧钱的地方不是大模型本身而是“大模型反复决策调用工具”这个过程。假设用户问“帮我改一下明天早上八点的闹钟”Agent第一步要判断该调哪个工具第二步把闹钟ID从历史里找出来第三步调用修改工具第四步再让模型确认修改成功。每一步都是一次模型推理而且每次推理都要上传工具定义和返回结果。如果工具定义写得很啰嗦每次都要把一个几百行JSON Schema塞进去线上几千个Agent并发跑起来光工具描述就是一笔不小的固定开支。更闹心的是如果Agent走了错误的分支比如调完一个工具后发现格式不对又得重新调一次那就等于白花几轮钱。3.2 Harness设计的三个原则单入口、早停、结构化返回这块我总结出三个原则直接决定了工具调用的Cost曲线。第一个原则是单入口。不要让Agent面对一堆零散工具而是把相关操作包成一个统一入口。比如闹钟相关的“新增”“修改”“删除”“查询”四个动作合并成一个AlarmToolAgent只需要决定“调用闹钟工具”这一个动作而不是在四个工具里纠结。这样不仅减少决策次数模型输出更容易稳定也降低了工具定义重复消耗Token的几率。第二个原则是早停。很多Agent框架里工具调用返回之后必须交给模型让模型决定下一步。但有些情况下工具返回结果已经完全能回答用户的问题不需要再让模型生成一句多余的话。所以我加了一个短路机制如果工具返回时带了final: true标记就直接把结果透传给用户不再启动新一轮推理。第三个原则是结构化返回。工具返回的数据不要乱七八糟一大坨JSON而是让调用端直接整理成一段面向最终用户的纯文本并且带上几个固定字段比如status、content、need_more。这样模型可以直接把content透传出去不需要再花一堆Token去重写一遍。我实测下来结构化返回能减少大约40%的生成类Token。这里顺便澄清一下很多人问的“Harness和Agent区别”问题。Harness是Agent的执行框架决定它怎么跑、怎么调工具、怎么接收反馈Agent是那个拿着工具去完成任务的逻辑主体。降本这件事大部分时候是在优化Harness而不是给Agent换一个更强的模型。4. 任务调度与批量推理把“贵”的时间让出去4.1 为什么峰值并发会抬高单价大模型推理服务和电网挺像峰值时段大家卡在一起算服务商要开更多GPU来扛成本自然上去了。体现在账单上就是按Token单价或者按并发请求数阶梯计价。Agent的即时响应任务没法挪但很多后台型Agent其实不要求毫秒级返回比如批量生成摘要、夜间数据标注、周期性报表分析。把这些任务压到低峰时段统一处理单价能便宜不少。我之前对比过一家云服务商的定价工作日白天峰值时段和凌晨低峰时段的同一规格模型价格可以差到一倍多。那只要把三成后台任务挪到低峰整体账单就能掉明显一截。4.2 队列消费动态批处理测试记录我做了一个很简单的队列消费模型。所有Agent任务先进一个消息队列每个任务带一个priority字段。实时交互任务直接走一条独立通道立刻调用模型。后台任务则进批处理队列攒够一定条数或者到固定时间窗口就触发一次推理批量执行。这里有个很关键的参数设计批处理的最大batch size和最大等待时间。我一开始把batch size设成64结果等待时间太长有些任务超时了业务侧反馈难等。后来调成32同时设置最长等待30秒效果就平衡了很多。伪代码大约是这样def batch_scheduler(jobs, max_batch32, max_wait30): buffer [] start time.time() for job in jobs: buffer.append(job) if len(buffer) max_batch or time.time() - start max_wait: yield buffer buffer [] start time.time()另外如果用的是自建推理服务还有一个更狠的优化叫动态批处理。多个请求同时进来不是一个个排队过GPU而是把它们的计算图拼在一起一次推理同时处理多条数据。这个要靠推理框架层面支持但只要做上吞吐能翻两三倍单次请求成本自然降下来。注意批处理调度要做任务超时保护和重试机制。有一次我把某个后台任务的超时时间设短了低峰批次里积压的请求大量重试反而把费用顶上去后来把所有重试改为指数退避并给每个任务单独设了最大重试次数问题才解决。5. 部署与观测自己扛一部分账目要透明5.1 哪些Agent任务值得自托管开源模型全链路都用商业大模型API在Agent数量少的时候没感觉等到业务量级上来就算前面的路由和上下文优化做得再好边际成本还是会越来越明显。这时就要考虑把一部分稳定、标准化、低风险的任务搬到自托管开源模型上。我判断迁移的标准有三条第一任务逻辑足够固定不需要频繁更新世界知识第二单次输出的变更对用户体验影响小第三对隐私和数据合规要求高数据不想出内网。最常见的就是意图分类、实体抽取、格式标准化、文本摘要这几个环节。这些任务用一个十来B的开源模型配合量化部署压到单张GPU上跑性能完全扛得住。比如我负责的系统中所有客服工单的分类和标签数据之前都走商业模型每月成本非常高。后来换成一个国产开源模型量化版自建推理服务准确率只掉了0.4个百分点但单次调用成本几乎为零。这里面的关键不是模型选得多牛而是任务边界清不清楚。任务越窄越适合自托管。自托管不提成本还有延迟优势。内网调用走内网带宽比公网API稳定得多也不担心外部限流。但你要有心理准备自托管意味着要有人运维GPU集群要有监控告警还要处理模型版本更新。这个成本得折算进去。5.2 成本预算和告警按业务线分账降本如果没有度量体系就是一笔糊涂账。我每接一个Agent项目第一件事就是把成本打上标签按业务线、按功能模块、按Prompt模板三个维度做分账。这样月底复盘时一眼就能看出到底是哪个业务线的Agent在烧钱哪个Prompt模板的Token消耗异常。具体做法是在每次模型调用时带上自定义标签字段比如bizorder、modulerefund、template_id123。这些标签会跟着用量数据进监控看板按天聚合。数据量上来之后再用报表工具拉趋势设定周环比和月环比阈值。我又设置了两道告警线黄色告警是单日费用环比前一天涨30%红色告警是单日费用超过预算上限的80%。告警触发后不是直接封停而是先自动把对应业务线的模型等级降一级比如旗舰模型降为中型开源模型等人工排查确定没有异常再恢复。这招虽然粗暴但能有效避免半夜Agent代码出bug循环调用API把预算烧光。6. 看见异常就踩刹车排查技巧与避坑清单6.1 为什么缓存命中率上不去很多团队抄我的方案去做上下文复用结果发现缓存命中率只有20%远低于预期。问题通常出在Prompt拼接顺序或者内容动态性上。缓存对前缀一致性要求极高只要前缀里有时间戳、用户名字、随机ID这类每次都在变的内容整个前缀就会失效。解决办法是把动态内容全部后置固定模板放最前面能在本地拼好的数据不要进模型输入。6.2 路由误判导致模型降级还有一次我发现某个业务的回答质量严重下滑查来查去是路由配置里“订单查询”的置信度阈值调太高大量本该走大模型的请求被错误地丢给了小模型。后来我们给路由增加了AB测试位每次路由决策会记录当时的置信度和最终用户反馈第二天对上一日的路由决策做离线回放修正阈值而不是拍脑袋调整。回放逻辑很简单就是把同样的请求用不同阈值各跑一遍比较效果成本差异一眼能看出来。6.3 工具循环调用治理工具循环调用是最隐蔽的烧钱点模型在几个工具之间来回跳明明已经拿到结果了还要再做一次校验或者补充一次查询。我在Harness里专门加了“循环调用次数上限”默认最多五次超出强制结束并返回当前已收集的信息。同时工具返回结果里明确标记task_complete模型一看这个字段是true就直接进入生成最终回答的环节不再继续调工具。这个机制上线后工具调用量又降了一成多。6.4 配额要按天看不能按月看最后一条避坑经验是预算管理千万别只看月底总数。AI账单不像传统服务器租金它是实时波动的某一个Agent出bug可能几小时就烧掉整月预算。我后来把配额管理细化到小时级单个业务线每小时最多能消耗多少Token都提前写死超出自动拦截请求并返回降级提示。一开始业务团队觉得这样太死板后来发现每次拦截都能拦住一次线上事故也就认了。根据我自己的经验整个降本动作推进顺序很有门道先做上下文压缩和工具瘦身因为改动小见效快然后做模型路由需要积累几天日志再做最后再做自托管和批量调度因为牵扯运维和底层推理框架节奏放慢一点分阶段灰度。每做一步都要把成本和效果指标记下来对比着调。最后再分享一个小技巧。我自己习惯在Agent系统里埋一个“单位任务成本”指标不是看总账单而是算清楚“处理完一个用户请求平均花了多少钱”。这个指标能帮团队建立成本意识也能在Agent数量增长时快速判断成本控制是持续有效还是开始反弹。记住降本不是靠牺牲体验硬省而是让每一笔Token都花在刀刃上。