Agent 项目刚上线那几天我盯着后台账单上的数字说实话有点心肌缺血。一个看起来挺简单的简历筛选 Agent每跑完一个候选人就要调三四次大模型接口日志里密密麻麻的 token 消耗记录换算成金额之后比原来单纯调一次 API 封装接口贵了将近一个数量级。这不是个例——身边好几个做 agent 开发的朋友都在同一个坑里Agent 跑起来是真爽工作流一接效果也确实惊艳但月底一看 API 费用直接把人劝退。这篇文章就是来聊这个事的。我会结合自己跑过的 agent 项目把成本暴涨的原因拆开再给出 6 个可以直接落地的工作流控成本技巧。适用对象是所有在用 LLM API 做 agent、搭工作流的人不管你是用 Dify、Coze 这类平台还是自己写代码调 DeepSeek、智谱之类的接口思路都通用。文章里不会有虚的理论全是能抄作业的实操。1. 先算清楚账Agent 的 API 成本到底烧在哪想省钱先得知道钱是怎么没的。很多人一上来就抱怨“API 太贵”但其实把账单导出来逐项看贵的原因根本不是单价而是用量被放大了。我把自己项目里的费用账单和调用日志拉出来对了一遍发现 Agent 场景下成本几乎都集中在三块地方。1.1 成本暴涨的“三座大山”第一座大山是输入 token 的重复消耗。Agent 跟普通 API 调用最大的区别在于它需要在一个会话里反复携带上下文。每次多轮推理你得把之前的对话历史、工具返回结果、系统提示词全部重新发给模型。OpenAI 和 DeepSeek 这类接口都是按 token 计费的输入虽然比输出便宜但架不住量大。比如一次简单的“查天气再推荐穿搭”的 agent 任务前两轮只有几百 token到第五轮的时候可能已经累计了几千 token而这些 token 里大部分是重复内容。第二座大山是工具调用带来的输出膨胀。Agent 要调用外部工具模型每次决策都会生成一大段 JSON 格式的“思考行动”文本。像 function calling 或者 ReAct 模式的 agent模型输出的很大一部分是它的推理过程和中间计划这些内容用户根本看不到但每一笔都算钱。更头疼的是模型偶尔会在工具调用失败后反复重试每重试一次就是一次完整的 API 计费。第三座大山是并行任务的乘法效应。Agent 一旦接了工作流通常不是单线程跑一个任务而是同时处理十个、五十个请求。我见过一个做批量文档处理的 agent单看每个文档的 token 消耗并不夸张但并发一上来QPS 翻了十倍账单也直接翻了十倍。这种增长是线性的没有任何优化空间除非从源头减少单任务消耗。1.2 为什么 Agent 比普通调用贵那么多传统 API 封装是“请求-响应”一次到底上下文是固定的发什么就是什么。Agent 则是多轮循环模型要理解任务、拆解步骤、调用工具、处理结果、再决定下一步。每一轮都是一次完整的 API 调用而且每一轮都要把前面的历史重新发给模型。用一个生活化的类比普通 API 调用像是你去快递站取一个固定包裹来回一趟就完事Agent 像是你让一个管家去办五件事管家每做一步都要跟你汇报一次每一次汇报你都要把之前交代过的所有事情重新说一遍。包裹没变多但沟通成本翻了五倍。明白了这个机制你就知道控成本的思路应该往哪个方向走了。不是去跟平台砍单价这个基本没戏而是想办法降低调用次数、降低单次 token、避免重复消耗。下面这 6 个技巧就是我踩坑之后总结出来的实操方案。2. 技巧一提示词减肥从源头把输入 token 压下来很多人写 system prompt 喜欢把“人设”“背景”“能力说明”“注意事项”全堆进去动辄两三千字。在普通 API 调用里这没啥问题但在 Agent 里这段提示词每一轮都要跟着请求走一遍。一个跑了 8 轮的 agent 任务光系统提示词就可能贡献了上万 token。所以我的第一个建议就是给提示词做一次彻底的“减肥手术”。2.1 动态组装提示词别一刀切全量发送我见过不少工作流设计把所有指令都固定写在系统提示词里不管用户这次问的是什么模型都要先读一遍全部规则。这显然很浪费。正确的做法是把提示词拆成“静态骨架 动态内容”。静态骨架是那些无论如何都不能省的规则比如输出格式、安全约束这部分尽量精简只保留必须的动态内容则是和当前任务相关的信息按需拼接。举个例子我在做一个“项目文档问答 Agent”的时候一开始把公司全部产品规范都塞进了系统提示词结果每次请求光提示词就有 4000 多 token。后来我把提示词拆成三层最外层是 500 token 的固定行为规则中间层是根据用户问题匹配到的产品线说明最内层才是当前上下文。这样单次请求的输入 token 直接从 4500 降到了 1500 左右降幅接近 70%而且回答质量没有明显下降。2.2 精简提示词的三条红线第一删除所有“你是”“你是一个”这类身份重复描述模型不需要你反复告诉它它是谁。第二把“你要注意”“请务必”这类语气词全部去掉直接写规则本身比如“输出必须是 JSON”比“请注意你的输出格式必须是 JSON”省了 6 个 token多轮累积下来就是不小的量。第三能用示例代替长描述的就用示例一个精准的 few-shot 示例往往比十行抽象描述更省 token效果也更好。我自己有个习惯每次改完提示词都会跑一遍 token 统计把没必要的修饰词删干净。这一步治标配合后面几个技巧才能治本。3. 技巧二模型路由分流让好钢用在刀刃上很多人做 Agent 的时候不管任务简单还是复杂全部调用同一个大模型。这就像不管搬砖还是绣花都用同一把大锤成本自然降不下来。合理做法是给 Agent 加一道“模型路由层”根据任务难度动态选择模型。3.1 分级路由的落地思路我常用的方案是三级路由。第一级是意图识别和小型分类任务比如判断用户这一步到底是要查询、还是要写代码这类任务逻辑简单用最便宜的小模型就够了。第二级是常规的中等复杂任务比如单轮问答、数据提取用性价比均衡的中型模型。第三级才是复杂推理比如多步代码生成、长文档分析这时候才动用能力最强的大模型。具体实现上如果你用的是 Coze 或者 Dify 这类可视化工作流平台可以直接在节点里配置模型选择条件先让一个小模型输出一个结构化的判断结果再用条件分支把请求分发到不同的模型节点。如果是自己写代码逻辑更简单一个 if-else 根据任务特征选模型就行。3.2 路由判断本身也要控成本这里有个容易忽略的坑路由判断本身也是一次 API 调用。如果为了省成本反而多调了一次模型那就亏了。我的经验是路由判断尽量用规则而不是模型。能用关键词匹配、正则表达式、长度判断搞定的绝不调模型。只有那些实在无法用规则判断的任务才让一个小模型来分类。笔者的项目里大约 60% 的请求是通过纯规则路由掉的这部分完全零成本。另外还有一个实用技巧把“是否值得用大模型”的判断标准反过来设。默认走小模型只有当任务连续失败两次或者用户明确要求深度回答时才升级到贵模型。这种“降级优先”的策略虽然不是最优解但往往是最省钱的解。4. 技巧三缓存复用不为同样的内容付两次钱Agent 跑起来之后你会发现大量请求其实在重复问类似的东西。不同用户可能问同一个产品的相同问题同一个用户可能在多轮会话里反复引用同一份文档。如果每一次都让模型重新从头计算那就是在白白烧钱。4.1 利用平台自带的上下文缓存主流的 LLM API 大多提供了 prompt caching 能力。简单的说就是如果你在短时间内多次发送相同的前缀内容服务商会对这部分命中缓存的 token 给出比较大的折扣。比如 DeepSeek 的上下文缓存命中价我记得大约是未命中价的十分之一左右这个折扣力度相当可观。使用缓存的前提是请求前缀要稳定。我自己的做法是把所有固定的内容——系统提示词、固定的知识片段、工具定义——统一放在 prompt 的最前面保持绝对不变这样每次请求都能命中缓存。变动的内容比如用户输入、中间结果放在后面不影响前缀的稳定。实测下来缓存命中率能到 80% 以上输入成本能省下大约一半还多。4.2 工作流层做结果缓存除了模型自带的 prompt caching更直接的是在工作流层面对已计算过的结果做缓存。很多平台自带知识库检索能力本质就是把文档切块存储用向量检索找相似片段这样模型不需要每次读取完整原文。如果你的 Agent 要频繁引用长文档强烈建议先把文档做切片入库让模型只读取相关的段落而不是每次都喂全量文本。对于那种“多个用户问相同问题”的场景还可以直接缓存最终回答。我在简历筛选工作流里做过一个措施把常见问题的答案放在一个键值存储里命中就直接返回根本不调模型。这一招给整个项目的 API 调用量降了大概 20%而且响应速度更快用户体验反而更好了。5. 技巧四工作流拆成开关把非必要步骤挡在门外很多 Agent 工作流的问题不是设计得太简单而是设计得太“满”。每一步都无脑执行该不该做、需不需要调用模型完全不判断。结果就是大量无效调用在消耗预算。5.1 条件分支是省钱的命门拿我踩过的一个坑来说。我做了一个“合同审核 Agent”流程设计成读取合同 → 提取关键条款 → 逐条风险评估 → 生成审核报告。一开始这个流程固定跑四步不管合同是两页的简单模板还是五十页的复杂协议全都走完整链路。后来发现很多简单合同根本不需要风险评估建模直接套规则就能判断。后来我把流程改成先做一个低成本的规则判断评估合同复杂度等级然后根据复杂度走不同的分支。简单合同走轻量分支只调一次模型复杂合同才走完整的多步链路。这个改动让平均单次任务成本降了 40%。所以说每个工作流节点之前都要问一句“这一步真的需要在这个任务里执行吗”然后给它加一个条件门控。5.2 人工确认点也是控成本的手段还有一个很多人忽视的点在关键操作前插入“人工确认”节点不仅能提升准确率也能省钱。比如一个自动写邮件的 Agent写完草稿后先让用户确认确认后才继续后续动作。如果用户不满意直接重新生成一次而不是让 Agent 自动进入“发送”环节后续的那一堆步骤。Coze 里有人工输入节点Dify 里有对话暂停等待用户输入的能力用起来很简单关键是思想上要把“人工确认”当成一种流程控制手段而不是累赘。5.3 批量任务的节奏控制如果你跑的是批量任务比如批量生成产品文案、批量处理简历还有个省钱细节把任务排队控制在比较平稳的并发水位而不是一次性全部打进去。原因有两个一是很多 API 提供的缓存是基于时间窗口的短时间内类似请求能命中缓存二是并发过高容易触发限流导致重试而每一次重试都是额外计费。把节奏放缓配合轮询和重试机制整体费用往往比猛冲猛打更低。6. 技巧五上下文瘦身别让窗口膨胀吞掉利润Agent 跑久了最容易出现的问题就是上下文越攒越长。每一轮结果都往消息列表里塞模型每次都读取全部历史。我见过一个 agent 跑到第 15 轮的时候单次请求的输入 token 已经超过 5 万而此时真正有用的信息可能只有最初的那几轮。上下文膨胀不仅烧钱还容易触发“400 context length exceeded”这类报错——我就被那条“this models maximum context length is 1048576 tokens”的错误消息折磨过其实不是真的到 100 万 token而是某个环节拼接出了问题把无用的历史全堆进去了。6.1 用摘要替代完整历史最经典的解决方案是“滚动摘要”。每跑完 N 轮就用一次模型调用把前面所有对话总结成一个几百 token 的摘要然后清空历史只保留“摘要 最近两轮完整对话”。这样后续请求的 token 量被锁死在一个稳定的范围内不会随着任务推进无限增长。这个小技巧我第一次用在客户支持 Agent 上效果立竿见影。原来一个 10 轮对话的任务最后一轮输入要 2 万 token用了摘要压缩之后稳定在 3000 token 左右末尾几轮的成本直接砍掉 85%。而且因为噪音少了模型回答准确率反而有所提升。要注意的是摘要本身也消耗 token所以压缩频率要权衡我一般建议每 5 到 8 轮压缩一次比较划算。6.2 关键信息提取而不是全量保留另一个思路是从源头筛选哪些信息值得保留。很多中间步骤的原始返回值比如某次工具调用返回的一整段 JSON其实只有其中两三个字段对后续决策有用。与其把整段结果塞回上下文不如在工作流里加一个“信息提取”节点只把必要字段拼装成一句话再传给模型。我在做一个“股票数据查询 Agent”的时候深有体会查询接口返回的数据结构很大一次返回几百个字段但模型真正关心的是价格、涨跌幅、成交量这几个。一开始直接把全量数据塞回上下文几轮下来 token 飞速上涨。后来改成用代码节点做字段筛选只保留模型需要的 5 个字段上下文长度从 8000 降到了 2000成本直接优势明显。关键字段的筛选规则要提前设计好别让模型自己去挑用代码处理更省。6.3 长文档处理要切片再说一个高频场景Agent 要读长文档比如几十页的 PDF 或者公司的知识库文档。如果直接把全文塞进 prompt一次可能就烧掉 5 万 token。正确的做法是先用 RAG 把文档切片用向量检索找到相关片段再把这些片段组装进 prompt。这一步表面上是加了检索成本向量库的调用但对比直接喂全文的 token 费用省下来的通常是数量级。7. 技巧六成本可视化给 API 装上“油表”最后一个技巧听起来不像技术但我觉得它是前面所有技巧的地基你得先能看清钱在哪烧才能知道往哪省。很多 Agent 项目上线后根本没有成本监控直到月底账单出来才傻眼。这样不行。7.1 在代码层记录 token 用量不管是用什么平台都应该在调用 API 的地方统一埋点记录每次请求的 prompt tokens、completion tokens、缓存命中情况。如果用的 OpenAI SDK响应里的 usage 字段可以直接拿到这些数字用 DeepSeek 或者兼容 OpenAI 格式的 API 也是一样。把这些数据写入日志再配合一个简单的统计脚本按任务、按用户、按模型维度汇总就能很直观地看到钱花在哪个环节。我自己写过一个不到 100 行的小工具输入一份原始调用日志输出一个按小时聚合的 token 消耗表顺带标出消耗最大的 Top 10 任务。每次优化完工作流跑一遍这个工具改造成效一目了然。免费大模型 API 不是没有但生产环境该用的还是得用商业接口这种情况下精确计量就更重要了。7.2 设置告警和配额给成本设置一个“油表指针”也很关键。很多网关类服务都支持配额管理比如设定一个单日消费上限到了阈值自动熔断。这个措施是最后一道保险防止某天工作流里出现死循环或者异常并发导致费用失控。我在生产环境里设了两个阈值一个是单任务 token 上限超过这个值直接终止任务并记录告警另一个是全局单日费用上限超过就暂停所有 agent 服务等人来排查。这里有个亲测有效的细节把告警消息推到即时通讯工具里而不是只看邮件。成本异常通常意味着线上故障即时通知能让你在账单爆炸之前先把规则救下来。8. 实操中踩过的坑与排查实录上文提到的 6 个技巧每一条背后都有一堆我踩过的坑。有些坑属于配置层面有些属于设计问题最后把它们整理成一份速查表方便你以后遇到类似问题直接对照。8.1 常见错误与排查速查现象常见原因排查思路与解决报错no api key for provider route deepseek-official路由配置里指定了某个 provider但该 provider 的 API key 没填或填错位置检查网关的路由表确认 deepseek-official 这一条 route 是否配置了正确的 key如果是自建网关核对环境变量名和 provider 名是否严格对应报错400 this models maximum context length is 1048576 tokens上下文拼接出错把重复内容或超长中间结果循环塞进了消息列表检查消息历史是否被正确截断尤其是工具调用返回值是否被重复追加用摘要压缩或切片检索来缩短上下文账单比预估高出数倍缺少缓存、全量喂长文档或多轮重复调用重新审视提示词是否动态组装确认是否开启 prompt caching检查工作流每个步骤是否都有条件门控并发一高就报限流错误重试后费用翻倍单次请求耗时太长或 QPS 超限控制并发水位增加指数退避重试优先压缩单次 token 量而不是提高请求频率小模型幻觉明显导致反复重试路由判断不准确简单任务误判为复杂任务给路由规则增加兜底条件提高升格到复杂模型的门槛同时增强输出格式校验减少无效输出表格里的第一行就是我刚开始搭网关时常遇到的坑明明配了 DeepSeek 的 key但路由名写错了所有请求都落到一个没有 key 的 provider 上直接报错。这种问题浪费的不仅是时间排查过程中的试错请求也都是钱。8.2 几条独家避坑心得第一条永远不要在 Agent 里用“重试”来掩盖质量问题。如果模型第一轮输出格式不对直接用代码做校验和修补而不是让模型再生成一次。每轮重试都是一次完整计费尤其输出 token 比输入贵重试的成本是双份的。用 Pydantic 这类库做输出结构校验或者在工作流里加一个 JSON 格式后处理节点能省下大量重试费用。第二条日志里一定要记录模型的“思考过程长度”。有些模型支持思维链或推理模式这部分输出 token 非常昂贵。如果你发现某个任务的完成 token 经常远高于预期大概率是模型在死磕一个不必要的问题。这时候应该回头调整提示词给模型更明确的停机条件比如“如果信息足够直接给出答案不要继续推理”。第三条上线前先做一轮“成本冒烟测试”。用真实的业务数据跑 20 个典型任务统计平均单任务 token 消耗和费用算出一个基线值。以后每次改工作流、改提示词都拿这个基线对比判断是优化了还是劣化了。我见过太多人只关心效果指标不关心成本指标结果优化了一个月效果提升了 5%成本翻了三倍这笔账怎么都划不来。9. 最后分享一点个人体会做 Agent 这一年多我最大的感受是控成本这件事本质上是在跟“对话的惯性”作斗争。Agent 的架构天然倾向于多轮、长上下文、高并发这些特性成就了它的智能也在悄悄吞噬预算。但只要把每一轮的 token 消耗都摊开来看你会发现省钱的空间远比想象中大。我个人现在养成的习惯是每做一个工作流改动先问自己三个问题——这一轮调用真的必要吗这个上下文必须要带吗这个任务需要这个级别的模型吗三个问题问完通常至少能砍掉一半成本。这不是什么高深理论就是老老实实地算账。说实话我第一次把项目成本压下来的时候没有用任何花哨的工具就是靠上面这 6 个笨办法一步步抠出来的。希望这份经验对你也有用。 LLM Agent成本飙升？6个实用技巧降低API调用与token消耗
Agent 项目刚上线那几天我盯着后台账单上的数字说实话有点心肌缺血。一个看起来挺简单的简历筛选 Agent每跑完一个候选人就要调三四次大模型接口日志里密密麻麻的 token 消耗记录换算成金额之后比原来单纯调一次 API 封装接口贵了将近一个数量级。这不是个例——身边好几个做 agent 开发的朋友都在同一个坑里Agent 跑起来是真爽工作流一接效果也确实惊艳但月底一看 API 费用直接把人劝退。这篇文章就是来聊这个事的。我会结合自己跑过的 agent 项目把成本暴涨的原因拆开再给出 6 个可以直接落地的工作流控成本技巧。适用对象是所有在用 LLM API 做 agent、搭工作流的人不管你是用 Dify、Coze 这类平台还是自己写代码调 DeepSeek、智谱之类的接口思路都通用。文章里不会有虚的理论全是能抄作业的实操。1. 先算清楚账Agent 的 API 成本到底烧在哪想省钱先得知道钱是怎么没的。很多人一上来就抱怨“API 太贵”但其实把账单导出来逐项看贵的原因根本不是单价而是用量被放大了。我把自己项目里的费用账单和调用日志拉出来对了一遍发现 Agent 场景下成本几乎都集中在三块地方。1.1 成本暴涨的“三座大山”第一座大山是输入 token 的重复消耗。Agent 跟普通 API 调用最大的区别在于它需要在一个会话里反复携带上下文。每次多轮推理你得把之前的对话历史、工具返回结果、系统提示词全部重新发给模型。OpenAI 和 DeepSeek 这类接口都是按 token 计费的输入虽然比输出便宜但架不住量大。比如一次简单的“查天气再推荐穿搭”的 agent 任务前两轮只有几百 token到第五轮的时候可能已经累计了几千 token而这些 token 里大部分是重复内容。第二座大山是工具调用带来的输出膨胀。Agent 要调用外部工具模型每次决策都会生成一大段 JSON 格式的“思考行动”文本。像 function calling 或者 ReAct 模式的 agent模型输出的很大一部分是它的推理过程和中间计划这些内容用户根本看不到但每一笔都算钱。更头疼的是模型偶尔会在工具调用失败后反复重试每重试一次就是一次完整的 API 计费。第三座大山是并行任务的乘法效应。Agent 一旦接了工作流通常不是单线程跑一个任务而是同时处理十个、五十个请求。我见过一个做批量文档处理的 agent单看每个文档的 token 消耗并不夸张但并发一上来QPS 翻了十倍账单也直接翻了十倍。这种增长是线性的没有任何优化空间除非从源头减少单任务消耗。1.2 为什么 Agent 比普通调用贵那么多传统 API 封装是“请求-响应”一次到底上下文是固定的发什么就是什么。Agent 则是多轮循环模型要理解任务、拆解步骤、调用工具、处理结果、再决定下一步。每一轮都是一次完整的 API 调用而且每一轮都要把前面的历史重新发给模型。用一个生活化的类比普通 API 调用像是你去快递站取一个固定包裹来回一趟就完事Agent 像是你让一个管家去办五件事管家每做一步都要跟你汇报一次每一次汇报你都要把之前交代过的所有事情重新说一遍。包裹没变多但沟通成本翻了五倍。明白了这个机制你就知道控成本的思路应该往哪个方向走了。不是去跟平台砍单价这个基本没戏而是想办法降低调用次数、降低单次 token、避免重复消耗。下面这 6 个技巧就是我踩坑之后总结出来的实操方案。2. 技巧一提示词减肥从源头把输入 token 压下来很多人写 system prompt 喜欢把“人设”“背景”“能力说明”“注意事项”全堆进去动辄两三千字。在普通 API 调用里这没啥问题但在 Agent 里这段提示词每一轮都要跟着请求走一遍。一个跑了 8 轮的 agent 任务光系统提示词就可能贡献了上万 token。所以我的第一个建议就是给提示词做一次彻底的“减肥手术”。2.1 动态组装提示词别一刀切全量发送我见过不少工作流设计把所有指令都固定写在系统提示词里不管用户这次问的是什么模型都要先读一遍全部规则。这显然很浪费。正确的做法是把提示词拆成“静态骨架 动态内容”。静态骨架是那些无论如何都不能省的规则比如输出格式、安全约束这部分尽量精简只保留必须的动态内容则是和当前任务相关的信息按需拼接。举个例子我在做一个“项目文档问答 Agent”的时候一开始把公司全部产品规范都塞进了系统提示词结果每次请求光提示词就有 4000 多 token。后来我把提示词拆成三层最外层是 500 token 的固定行为规则中间层是根据用户问题匹配到的产品线说明最内层才是当前上下文。这样单次请求的输入 token 直接从 4500 降到了 1500 左右降幅接近 70%而且回答质量没有明显下降。2.2 精简提示词的三条红线第一删除所有“你是”“你是一个”这类身份重复描述模型不需要你反复告诉它它是谁。第二把“你要注意”“请务必”这类语气词全部去掉直接写规则本身比如“输出必须是 JSON”比“请注意你的输出格式必须是 JSON”省了 6 个 token多轮累积下来就是不小的量。第三能用示例代替长描述的就用示例一个精准的 few-shot 示例往往比十行抽象描述更省 token效果也更好。我自己有个习惯每次改完提示词都会跑一遍 token 统计把没必要的修饰词删干净。这一步治标配合后面几个技巧才能治本。3. 技巧二模型路由分流让好钢用在刀刃上很多人做 Agent 的时候不管任务简单还是复杂全部调用同一个大模型。这就像不管搬砖还是绣花都用同一把大锤成本自然降不下来。合理做法是给 Agent 加一道“模型路由层”根据任务难度动态选择模型。3.1 分级路由的落地思路我常用的方案是三级路由。第一级是意图识别和小型分类任务比如判断用户这一步到底是要查询、还是要写代码这类任务逻辑简单用最便宜的小模型就够了。第二级是常规的中等复杂任务比如单轮问答、数据提取用性价比均衡的中型模型。第三级才是复杂推理比如多步代码生成、长文档分析这时候才动用能力最强的大模型。具体实现上如果你用的是 Coze 或者 Dify 这类可视化工作流平台可以直接在节点里配置模型选择条件先让一个小模型输出一个结构化的判断结果再用条件分支把请求分发到不同的模型节点。如果是自己写代码逻辑更简单一个 if-else 根据任务特征选模型就行。3.2 路由判断本身也要控成本这里有个容易忽略的坑路由判断本身也是一次 API 调用。如果为了省成本反而多调了一次模型那就亏了。我的经验是路由判断尽量用规则而不是模型。能用关键词匹配、正则表达式、长度判断搞定的绝不调模型。只有那些实在无法用规则判断的任务才让一个小模型来分类。笔者的项目里大约 60% 的请求是通过纯规则路由掉的这部分完全零成本。另外还有一个实用技巧把“是否值得用大模型”的判断标准反过来设。默认走小模型只有当任务连续失败两次或者用户明确要求深度回答时才升级到贵模型。这种“降级优先”的策略虽然不是最优解但往往是最省钱的解。4. 技巧三缓存复用不为同样的内容付两次钱Agent 跑起来之后你会发现大量请求其实在重复问类似的东西。不同用户可能问同一个产品的相同问题同一个用户可能在多轮会话里反复引用同一份文档。如果每一次都让模型重新从头计算那就是在白白烧钱。4.1 利用平台自带的上下文缓存主流的 LLM API 大多提供了 prompt caching 能力。简单的说就是如果你在短时间内多次发送相同的前缀内容服务商会对这部分命中缓存的 token 给出比较大的折扣。比如 DeepSeek 的上下文缓存命中价我记得大约是未命中价的十分之一左右这个折扣力度相当可观。使用缓存的前提是请求前缀要稳定。我自己的做法是把所有固定的内容——系统提示词、固定的知识片段、工具定义——统一放在 prompt 的最前面保持绝对不变这样每次请求都能命中缓存。变动的内容比如用户输入、中间结果放在后面不影响前缀的稳定。实测下来缓存命中率能到 80% 以上输入成本能省下大约一半还多。4.2 工作流层做结果缓存除了模型自带的 prompt caching更直接的是在工作流层面对已计算过的结果做缓存。很多平台自带知识库检索能力本质就是把文档切块存储用向量检索找相似片段这样模型不需要每次读取完整原文。如果你的 Agent 要频繁引用长文档强烈建议先把文档做切片入库让模型只读取相关的段落而不是每次都喂全量文本。对于那种“多个用户问相同问题”的场景还可以直接缓存最终回答。我在简历筛选工作流里做过一个措施把常见问题的答案放在一个键值存储里命中就直接返回根本不调模型。这一招给整个项目的 API 调用量降了大概 20%而且响应速度更快用户体验反而更好了。5. 技巧四工作流拆成开关把非必要步骤挡在门外很多 Agent 工作流的问题不是设计得太简单而是设计得太“满”。每一步都无脑执行该不该做、需不需要调用模型完全不判断。结果就是大量无效调用在消耗预算。5.1 条件分支是省钱的命门拿我踩过的一个坑来说。我做了一个“合同审核 Agent”流程设计成读取合同 → 提取关键条款 → 逐条风险评估 → 生成审核报告。一开始这个流程固定跑四步不管合同是两页的简单模板还是五十页的复杂协议全都走完整链路。后来发现很多简单合同根本不需要风险评估建模直接套规则就能判断。后来我把流程改成先做一个低成本的规则判断评估合同复杂度等级然后根据复杂度走不同的分支。简单合同走轻量分支只调一次模型复杂合同才走完整的多步链路。这个改动让平均单次任务成本降了 40%。所以说每个工作流节点之前都要问一句“这一步真的需要在这个任务里执行吗”然后给它加一个条件门控。5.2 人工确认点也是控成本的手段还有一个很多人忽视的点在关键操作前插入“人工确认”节点不仅能提升准确率也能省钱。比如一个自动写邮件的 Agent写完草稿后先让用户确认确认后才继续后续动作。如果用户不满意直接重新生成一次而不是让 Agent 自动进入“发送”环节后续的那一堆步骤。Coze 里有人工输入节点Dify 里有对话暂停等待用户输入的能力用起来很简单关键是思想上要把“人工确认”当成一种流程控制手段而不是累赘。5.3 批量任务的节奏控制如果你跑的是批量任务比如批量生成产品文案、批量处理简历还有个省钱细节把任务排队控制在比较平稳的并发水位而不是一次性全部打进去。原因有两个一是很多 API 提供的缓存是基于时间窗口的短时间内类似请求能命中缓存二是并发过高容易触发限流导致重试而每一次重试都是额外计费。把节奏放缓配合轮询和重试机制整体费用往往比猛冲猛打更低。6. 技巧五上下文瘦身别让窗口膨胀吞掉利润Agent 跑久了最容易出现的问题就是上下文越攒越长。每一轮结果都往消息列表里塞模型每次都读取全部历史。我见过一个 agent 跑到第 15 轮的时候单次请求的输入 token 已经超过 5 万而此时真正有用的信息可能只有最初的那几轮。上下文膨胀不仅烧钱还容易触发“400 context length exceeded”这类报错——我就被那条“this models maximum context length is 1048576 tokens”的错误消息折磨过其实不是真的到 100 万 token而是某个环节拼接出了问题把无用的历史全堆进去了。6.1 用摘要替代完整历史最经典的解决方案是“滚动摘要”。每跑完 N 轮就用一次模型调用把前面所有对话总结成一个几百 token 的摘要然后清空历史只保留“摘要 最近两轮完整对话”。这样后续请求的 token 量被锁死在一个稳定的范围内不会随着任务推进无限增长。这个小技巧我第一次用在客户支持 Agent 上效果立竿见影。原来一个 10 轮对话的任务最后一轮输入要 2 万 token用了摘要压缩之后稳定在 3000 token 左右末尾几轮的成本直接砍掉 85%。而且因为噪音少了模型回答准确率反而有所提升。要注意的是摘要本身也消耗 token所以压缩频率要权衡我一般建议每 5 到 8 轮压缩一次比较划算。6.2 关键信息提取而不是全量保留另一个思路是从源头筛选哪些信息值得保留。很多中间步骤的原始返回值比如某次工具调用返回的一整段 JSON其实只有其中两三个字段对后续决策有用。与其把整段结果塞回上下文不如在工作流里加一个“信息提取”节点只把必要字段拼装成一句话再传给模型。我在做一个“股票数据查询 Agent”的时候深有体会查询接口返回的数据结构很大一次返回几百个字段但模型真正关心的是价格、涨跌幅、成交量这几个。一开始直接把全量数据塞回上下文几轮下来 token 飞速上涨。后来改成用代码节点做字段筛选只保留模型需要的 5 个字段上下文长度从 8000 降到了 2000成本直接优势明显。关键字段的筛选规则要提前设计好别让模型自己去挑用代码处理更省。6.3 长文档处理要切片再说一个高频场景Agent 要读长文档比如几十页的 PDF 或者公司的知识库文档。如果直接把全文塞进 prompt一次可能就烧掉 5 万 token。正确的做法是先用 RAG 把文档切片用向量检索找到相关片段再把这些片段组装进 prompt。这一步表面上是加了检索成本向量库的调用但对比直接喂全文的 token 费用省下来的通常是数量级。7. 技巧六成本可视化给 API 装上“油表”最后一个技巧听起来不像技术但我觉得它是前面所有技巧的地基你得先能看清钱在哪烧才能知道往哪省。很多 Agent 项目上线后根本没有成本监控直到月底账单出来才傻眼。这样不行。7.1 在代码层记录 token 用量不管是用什么平台都应该在调用 API 的地方统一埋点记录每次请求的 prompt tokens、completion tokens、缓存命中情况。如果用的 OpenAI SDK响应里的 usage 字段可以直接拿到这些数字用 DeepSeek 或者兼容 OpenAI 格式的 API 也是一样。把这些数据写入日志再配合一个简单的统计脚本按任务、按用户、按模型维度汇总就能很直观地看到钱花在哪个环节。我自己写过一个不到 100 行的小工具输入一份原始调用日志输出一个按小时聚合的 token 消耗表顺带标出消耗最大的 Top 10 任务。每次优化完工作流跑一遍这个工具改造成效一目了然。免费大模型 API 不是没有但生产环境该用的还是得用商业接口这种情况下精确计量就更重要了。7.2 设置告警和配额给成本设置一个“油表指针”也很关键。很多网关类服务都支持配额管理比如设定一个单日消费上限到了阈值自动熔断。这个措施是最后一道保险防止某天工作流里出现死循环或者异常并发导致费用失控。我在生产环境里设了两个阈值一个是单任务 token 上限超过这个值直接终止任务并记录告警另一个是全局单日费用上限超过就暂停所有 agent 服务等人来排查。这里有个亲测有效的细节把告警消息推到即时通讯工具里而不是只看邮件。成本异常通常意味着线上故障即时通知能让你在账单爆炸之前先把规则救下来。8. 实操中踩过的坑与排查实录上文提到的 6 个技巧每一条背后都有一堆我踩过的坑。有些坑属于配置层面有些属于设计问题最后把它们整理成一份速查表方便你以后遇到类似问题直接对照。8.1 常见错误与排查速查现象常见原因排查思路与解决报错no api key for provider route deepseek-official路由配置里指定了某个 provider但该 provider 的 API key 没填或填错位置检查网关的路由表确认 deepseek-official 这一条 route 是否配置了正确的 key如果是自建网关核对环境变量名和 provider 名是否严格对应报错400 this models maximum context length is 1048576 tokens上下文拼接出错把重复内容或超长中间结果循环塞进了消息列表检查消息历史是否被正确截断尤其是工具调用返回值是否被重复追加用摘要压缩或切片检索来缩短上下文账单比预估高出数倍缺少缓存、全量喂长文档或多轮重复调用重新审视提示词是否动态组装确认是否开启 prompt caching检查工作流每个步骤是否都有条件门控并发一高就报限流错误重试后费用翻倍单次请求耗时太长或 QPS 超限控制并发水位增加指数退避重试优先压缩单次 token 量而不是提高请求频率小模型幻觉明显导致反复重试路由判断不准确简单任务误判为复杂任务给路由规则增加兜底条件提高升格到复杂模型的门槛同时增强输出格式校验减少无效输出表格里的第一行就是我刚开始搭网关时常遇到的坑明明配了 DeepSeek 的 key但路由名写错了所有请求都落到一个没有 key 的 provider 上直接报错。这种问题浪费的不仅是时间排查过程中的试错请求也都是钱。8.2 几条独家避坑心得第一条永远不要在 Agent 里用“重试”来掩盖质量问题。如果模型第一轮输出格式不对直接用代码做校验和修补而不是让模型再生成一次。每轮重试都是一次完整计费尤其输出 token 比输入贵重试的成本是双份的。用 Pydantic 这类库做输出结构校验或者在工作流里加一个 JSON 格式后处理节点能省下大量重试费用。第二条日志里一定要记录模型的“思考过程长度”。有些模型支持思维链或推理模式这部分输出 token 非常昂贵。如果你发现某个任务的完成 token 经常远高于预期大概率是模型在死磕一个不必要的问题。这时候应该回头调整提示词给模型更明确的停机条件比如“如果信息足够直接给出答案不要继续推理”。第三条上线前先做一轮“成本冒烟测试”。用真实的业务数据跑 20 个典型任务统计平均单任务 token 消耗和费用算出一个基线值。以后每次改工作流、改提示词都拿这个基线对比判断是优化了还是劣化了。我见过太多人只关心效果指标不关心成本指标结果优化了一个月效果提升了 5%成本翻了三倍这笔账怎么都划不来。9. 最后分享一点个人体会做 Agent 这一年多我最大的感受是控成本这件事本质上是在跟“对话的惯性”作斗争。Agent 的架构天然倾向于多轮、长上下文、高并发这些特性成就了它的智能也在悄悄吞噬预算。但只要把每一轮的 token 消耗都摊开来看你会发现省钱的空间远比想象中大。我个人现在养成的习惯是每做一个工作流改动先问自己三个问题——这一轮调用真的必要吗这个上下文必须要带吗这个任务需要这个级别的模型吗三个问题问完通常至少能砍掉一半成本。这不是什么高深理论就是老老实实地算账。说实话我第一次把项目成本压下来的时候没有用任何花哨的工具就是靠上面这 6 个笨办法一步步抠出来的。希望这份经验对你也有用。