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 model's 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 model's 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 个笨办法一步步抠出来的。希望这份经验对你也有用。
