把 Agent 从 demo 推到生产环境最快让人肉疼的不是代码 bug而是 API 账单。我做过的几个 Agent 项目凡是“跑起来很爽”的月底看账单基本都倒吸一口凉气。普通聊天机器人一次问答最多烧一两次模型调用Agent 不一样一次任务里规划、路由、工具选择、结果解释、记忆压缩各付一次钱十几次调用打底一点都不夸张。更麻烦的是很多人一开始就把旗舰模型接到所有节点上上下文越堆越长重试逻辑又没做限制账单自然直线飙升。这篇文章不是讲怎么把 Agent 做出来而是把“怎么让 Agent 跑得不那么贵”这件事拆透。我会先从成本结构入手然后给出 6 个经过实际业务验证的控成本技巧再到具体踩坑案例和排查表。不管你是在 Coze 这种托管平台上搭工作流还是用 Dify 自建、或者直接撸 Harness / Multi-Agent 框架这篇都适用。1. 先把账单拆开Agent 的成本结构和普通聊天完全不是一回事很多团队看到 API 费用暴涨的第一反应是“换个便宜的模型”实际上模型单价只是冰山一角。Agent 场景下真正让账单失控的是调用次数和上下文长度这两项才是成本大头。1.1 一次 Agent 任务背后到底要调用多少次模型普通 ChatBot 一轮对话 1 次模型调用输入输出算下来就完事了。Agent 不一样它本质上是“模型驱动的状态机”每一步决策都要模型参与理解用户意图判断要不要进入工作流规划任务决定先调哪个工具、后调哪个工具选择工具参数把自然语言翻译成结构化的 tool call工具返回结果后由模型解读、判断是否继续结果需要总结、写入记忆时又是一次调用。我实际统计过自己跑的一个简历筛选 Agent一次完整的候选人评估平均要触发 9 到 14 次模型调用。按每次调用 3000-6000 tokens 算一次任务轻松烧掉 4-8 万 tokens。如果你用的是旗舰模型这一条流程跑下来可能就是几毛到几美元的消耗。一天跑几百个简历账单直接起飞。1.2 三大隐性成本比模型单价更可怕第一是模型错配。很多 Agent 搭建教程默认“主模型选最强的”于是意图识别、日期解析、关键词抽取这些简单活全用旗舰模型跑成本高一个数量级效果却没有本质区别。第二是上下文膨胀。工具调用场景下每一轮对话都会把系统提示、历史记录、工具返回值拼进去。我在实际项目里见过一个 Dify 工作流跑了几十轮之后单次请求上下文超过 40 万 tokens还没触发api error: 400 this models maximum context length is 1048576 tokens这种报错但单条请求的成本已经翻了十几倍。长上下文不是一次性收费是每一轮都在重复为历史长度付费。第三是循环和重试。解析 JSON 失败就重新调用一次模型、收到限流错误就重试三遍、Agent 一步卡住就反复让模型“再想想”。这些逻辑单独看都不起眼合在一起能把总成本翻倍。2. 技巧一给 Agent 装“短路开关”能不走模型就不走模型控成本的第一原则不是“用便宜的模型”而是“不要为了用 AI 而用 AI”。Agent 里很多环节用规则引擎、代码逻辑处理结果更稳、速度更快、成本为零。2.1 哪些环节不适合让模型出场我踩过的最典型的坑是把一句话分类、固定格式抽取、简单条件判断全部丢给大模型。比如用户输入“帮我查上海明天天气”第一反应是让模型抽取城市和日期。实际上这类结构化信息用正则表达式或者关键词匹配就能搞定连便宜模型都可以省掉。适合“短路”的环节包括硬编码路由根据关键词、分类标签、用户来源直接决定走哪条工作流参数校验日期格式、数字范围、必填字段用代码校验而不是让模型“理解”简单转换大写转小写、Markdown 转纯文本、JSON 字段重命名这些是脚本的活儿幂等去重相同指令重复提交用请求 ID 直接拦截连入口都不用进。2.2 实操规则先运行模型最后兜底我做 Agent 架构时习惯在入口加一道“pre-router”用最轻量的逻辑先处理一批请求。具体做法是输入先过规则引擎命中关键词库、正则库的直接走预设分支规则命中不了、确实需要语义理解的再进入模型层模型层内部再分级简单语义任务用便宜模型复杂任务用贵模型。这个“短路开关”在大多数工作流里能砍掉 40%-60% 的无效模型调用。有一次我给一个客服工单分类的 Coze 工作流做改造加了三层规则兜底之后月 API 费用直接降了一半多而且准确率反而上升了因为结构化数据不再被模型“自由发挥”搞乱。注意短路不是硬砍。如果规则覆盖率太低或者在模糊场景强行写规则会导致用户体验明显变差。我的判断标准是规则命中率至少要稳定在 70% 以上才值得做。3. 技巧二模型分级“配餐”便宜模型干杂活旗舰模型出精品这是成本优化里见效最快、也最容易做过头的一步。“一模型通吃”是 Agent 项目最常见的浪费但“全上最便宜的”又会导致重试率飙升、质量问题频出。关键是把任务按复杂度分层给每一层配正确的模型。3.1 先看价差再定分级策略不同模型每百万 tokens 的价差能到几十倍。旗舰模型和轻量模型之间的差距在“简单任务”上体现得并不明显但成本差是实打实的。举个例子一次工具调用任务里假设有 8 次简单操作意图识别、命名实体抽取、工具参数生成、2 次复杂操作最终总结、多条件推理。如果全部用旗舰模型假设每百万 tokens 10 美元一次任务的模型成本大约是 4 万 tokens * 10 / 100万 0.4 美元。如果把 8 次简单操作换成便宜模型假设每百万 tokens 0.2 美元那么成本就变成 8 次 * 4000 tokens * 0.2 / 100万 2 次 * 4000 tokens * 10 / 100万 0.0064 0.08 0.0864 美元。省了接近八成。具体怎么分级我的实践方案是三层L1 轻量层意图粗分类、格式抽取、文本压缩、简单路由。用 DeepSeek 大众版、智谱 GLM 系列、Kimi 这类性价比模型就够了。L2 中档层工具参数填充、结构化数据转换、一般问答。L3 旗舰层多工具协同推理、长文档总结、最终回复生成。只有这里才值得用 GPT-4o 级别或者各家旗舰模型。3.2 实操写一个简单的 model router如果是在 Dify、Coze 这类平台上节点里通常可以直接配置不同模型分级主要靠工作流分支。如果是自己写 Agent 框架我建议在调用层加一个 router根据任务类型返回对应的模型名。我用过一段比较轻量的路由逻辑伪代码大致是这样def route_model(task_type: str, complexity: str) - str: if complexity low: return deepseek-chat # L1 轻量模型 if task_type in (summarize, plan): return gpt-4o # L3 旗舰模型 return glm-4-flash # L2 中档模型当然不同服务商的模型名和价格会变我强烈建议以官方控制台为准同时把路由结果打印进日志方便后续复盘。经验心得分级之后要监控两个数字一个是 L3 模型的调用占比一个是重试率。理想的曲线是 L3 占比低于 20%、重试率低于 5%。如果你发现便宜模型重试率飙升说明分级分错了那不是省钱是烧钱重试。4. 技巧三上下文瘦身别把历史包袱背到每一轮上下文膨胀是 Agent 成本失控的隐形杀手而且是“越跑越贵”的元凶。很多 Agent 任务跑得越多上下文越长单次调用的输入 tokens 也跟着涨但真正有用的信息其实不到十分之一。4.1 上下文是怎么一点点变胖的有过实操经验的人应该都见过这种场景一个知识库问答 Agent每轮都把所有检索到的文档片段全部拼进 prompt一个多轮工作流系统提示词写了几千字、历史记录几十轮全量带入工具返回的 JSON 冗长无比也原封不动丢给模型再解读一次。我接过一个 Dify 工作流项目的优化上下文经常超过 20 万 tokens用户每问一句话模型都要重新读一遍这 20 万 tokens 的历史。到最后用户问“上次那个候选人电话是多少”成本已经接近一美元一次。存粹是背着一个越来越大的包走路。4.2 实操三种瘦身手段按需组合第一种是滑动窗口裁剪。只保留最近 N 轮对话和必要的系统提示更早的历史从 prompt 里丢出去必要时放到记忆系统里。N 通常是 5-10 轮具体看业务连续性要求。第二种是消息压缩。对话超过阈值时先把旧消息用一次便宜模型压成摘要后续只带摘要不带原文。这个技巧在 Coze 工作流里可以做成“会话压缩节点”在自建框架里可以做成一个前置函数。第三种是结构化记忆。把历史记录沉淀成结构化字段比如用户偏好、已查过的关键词、待办事项存在向量库或内存里。后续请求只拉跟当前任务相关的字段不拉整段历史。另外工具返回值也要做后处理。我在自己的 Agent 里统一要求工具返回只保留核心字段例如简历筛选时只保留“姓名、经验年限、技能集、当前职位”而不是把整份简历原文塞给模型。这样既降低成本也让模型更容易聚焦判断。注意裁剪上下文要小心“失忆”风险。金融、合同审查这类场景关键条款一旦被截断模型可能给出错误结论。我的做法是关键字段永远放摘要里不依赖滑动窗口只有雷同的闲聊内容才允许被压缩。5. 技巧四语义缓存让相似请求别再付第二次钱很多 Agent 处理的是高频、低变需求比如商品推荐、政策问答、报表生成。这些请求之间往往有大量重复内容而每次重复都在白白付费。语义缓存就是给 Agent 加一层记忆让相似请求直接命中历史结果不用再走一遍模型。5.1 缓存到底怎么工作原理很简单请求进来先做一次 embedding 向量化然后在缓存库里做相似度检索。当相似度超过阈值直接把之前的结果拿回来低于阈值才让模型继续跑。这样用一次 embedding 的小成本换掉一次完整 LLM 调用的大成本。算一笔账假设你的请求平均每次模型调用成本是 0.05 美元embedding 一次只要万分之几美元。如果缓存命中率有 50%那么 1000 次请求里省下 500 次模型调用成本从 50 美元变成 25 美元多一点再扣掉缓存开销也能省 45% 左右。5.2 实操什么场景适合加缓存什么场景别乱加适合加语义缓存的场景知识库问答库内容不常变问题表述千变万化但答案稳定规则类咨询请假政策、故障排查手册、产品说明等标准问答数据报表生成参数固定的周报/月报摘要可以直接复用。不适合加缓存的场景涉及实时数据比如“当前库存多少”就不能缓存旧结果强个性化输出生成内容依赖用户 ID、随机性比如营销文案创作合规敏感场景医疗诊断、法律意见这类缓存可能导致误导。实操上我会在模型 API 前面套一层代理请求先查缓存再决定是否转发给模型。缓存的 key 用 embedding 生成value 存模型的返回结果TTL 根据业务新鲜度设置通常是 5 分钟到 24 小时之间。注意语义缓存最怕“只差一点点就命中”的边界请求。相似度阈值设太低比如 0.7会命中语义不同但向量接近的内容回答错误设太高比如 0.95命中率又太低。我一般从 0.85 起步根据测试集的误命中率微调。6. 技巧五批处理与并发控制用调度换账单大家搜“ai agent 怎么扛并发”时第一反应都是上更多机器、扩容、压测。但结合成本视角答案恰恰是“别让所有任务一股脑同时打 API”。调度得好同样的业务量可以少付一大笔钱。6.1 批处理价格打折延迟换成本很多模型服务商都有批量模式比如 offline 批处理接口价格通常是实时模式的 50%。这类接口适合不需要立即返回结果的任务比如夜间批量清洗简历、定时爬取的文档摘要、批量生成商品描述。把实时任务和批处理任务分开能明显压降账单。我的习惯是用户看得见的交互走实时接口系统内部的数据处理、生成草稿、预聚合数据全走批处理。曾给一个文档处理类 Agent 做过改造70% 的任务挪到批处理单月 API 费用降了 40% 以上。6.2 并发不是越高越好这里还是要强调“削峰填谷”。当你把并发拉满去打模型 API很容易触发限流限流之后重试重试又产生费用还有可能因为排队导致超时然后又触发业务层的重试。这种重试风暴是 Agent 成本莫名翻倍的主要来源之一。实操时我会做三件事给 API 请求加队列和限速器按官方的 RPM/TPM 配额留出 20%-30% 余量不踩死线重试策略改成指数退避避免同一时刻集体重试把一次性的大并发任务拆成小批量匀速提交。另外如果用的是 Coze 这类托管平台限流规则通常是平台统一管理自己能控制的空间不大那就更要注意工作流内部不要设计无意义的并发分支。如果发现同一个任务里多个节点都在并发调用同一个模型 API先合并节点再谈扩容。经验心得并发控制优化通常能直接消灭“API error: 429”和后续的连环重试。我在一个数据抓取 Agent 上见过简单加了个令牌桶限速器之后不仅费用稳定了成功率反而从 91% 升到 98%。7. 技巧六记账先行给每次 Agent 运行算一笔明白账最后一个技巧其实应该最先做全链路记账。没有度量就没有优化很多项目成本失控是因为压根不知道一个任务跑完到底花了几次调用、多少 tokens、多少钱。7.1 建一个成本大盘别等账单上门不管你用哪种框架都可以在模型调用层加一个日志记录把每次请求的 model、input_tokens、output_tokens、timestamp、task_id 落库。如果你用 LiteLLM Proxy 或 OpenRouter 这类网关它们自带调用日志和成本统计省不少事自建的话最简单的就是用中间件在响应后把 usage 字段写进日志表。我习惯统计四个核心指标单任务成本中位数大多数任务应该集中在一个较低范围单任务成本 P9595 分位的成本用来发现“少数任务吃掉大部分钱”的情况每千任务消耗 tokens反映 Agent 的平均“废话率”缓存命中率判断缓存策略是否有效。有了这些指标你就能定位到底是哪类任务在烧钱。我见过一个 Agent表面看每任务成本正常拉出 P95 才发现有个“PDF 全文解析”分支单次要烧掉好几美元就因为工作流配置里把一个 MinerU 文档解析的返回值整本塞进了模型上下文。7.2 给典型任务设成本预算跑过阈值就告警更进阶的做法是“成本回归测试”。上线一个新版本工作流之前我先定义几个典型测试任务比如“简历筛选”“问题归类”“报告生成”跑一遍并记录成本基线。如果新版改动后某个典型任务的成本超过基线 30%就要回查是上下文变长了还是调用次数变多了。成本指标可以接告警单任务成本超过阈值就在群里报出来。我自己的项目里阈值是“单任务成本 0.15 美元”超过就查日志大多数问题出在长上下文或者重试上。提示记住看总账的时候把 API 之外的第三方服务费也算进来。一个 Agent 工作流里常常不只是模型费用还有 OCR、文档解析、搜索接口、向量数据库的费用这些都是成本的一部分别只盯着模型调用。8. 踩坑实录三个翻车现场和一张排查速查表写完技巧再来讲几个真实翻车的例子。这些坑不是从文档里看来的是我和团队在项目里一个个踩出来的。8.1 翻车现场一全旗舰模型方案有一个项目一开始架构很“豪华”所有节点全用 GPT-4o 级别模型用户交互倒是很流畅。上线一周账单出来吓一跳日均费用上千。后来加上分级路由把 70% 的简单节点换到便宜模型费用降到原来的 1/4最终总结类节点保留旗舰模型用户体感变化很小。这是最典型的“能力溢出”问题。模型强是好事但不是所有环节都需要那么强。工具参数抽取、关键词判断、意图粗分这些环节便宜模型和小模型完全能顶住。8.2 翻车现场二无限重试死循环另一个项目里Agent 在调用某个外部工具时经常超时于是我在流程里写了“失败后重试 5 次”。结果外部工具恢复慢的时候一次任务光重试就烧掉 6 次模型调用成本翻倍。后来我把重试策略改成指数退避并且加了一个熔断逻辑连续失败 3 次就直接转人工不再让模型反复尝试。这里提醒一句很多模型调用异常是限流导致的你越急着重试越容易触发连环限流。重试之前一定要先看看错误码是不是 429 或者 5xx再决定退避策略。8.3 翻车现场三长会话把成本拖死还有个知识库 Agent用了一段时间后用户反馈“变迟钝了”我看日志才发现上下文已经堆到了十几万 tokens单次问答成本从 0.02 美元涨到 0.5 美元以上。加了滑动窗口和摘要记忆之后成本回落响应速度也回来了。这个问题在长会话 Agent 里特别隐蔽因为它不是突然爆发的而是每天涨一点等注意到时已经很高了。建议每周看一次“单任务 tokens 均值”超出基线就主动压缩。8.4 Agent 成本问题排查速查表下面这张表可以收藏起来遇到成本异常直接对表查。症状可能原因排查方向常用解法单任务成本突然翻倍上下文膨胀看 input_tokens 日志加滑动窗口/摘要压缩费用高但调用次数不多用了旗舰模型处理简单任务按任务类型统计模型分布模型分级路由调用次数暴增循环重试/Agent 死循环看错误码和重试日志指数退避熔断相似请求重复扣费没有缓存看重复率指标加语义缓存API 请求大量 429并发打满配额看限流错误率加队列/限速器上下文超长报错单条消息塞入过多历史检查请求 tokens裁剪历史、结构化记忆工作流某个节点特别贵工具返回全文进入模型看节点级成本分布工具返回后做字段后处理月末账单和预期差很多没有台账和告警检查是否有未记录调用上线成本监控控成本从来不是一刀切地把模型换便宜而是先把链路画出来在每个入口问一句这一步真的需要大模型吗需要多大的模型能不能复用上一次的结果我在实际项目里的体会是把上述 6 个技巧全部落地之后Agent 的 API 成本降到原来的 1/3 到 1/5 是完全可行的而业务质量不会下降甚至因为减少无效调用稳定性反而更好。建议你先做记账再逐条上“短路开关”和“模型分级”这两步最容易见效。等到链路稳定了再打磨缓存和批处理把成本压到极致。 AI Agent成本优化实战：6个技巧让API账单降80%
把 Agent 从 demo 推到生产环境最快让人肉疼的不是代码 bug而是 API 账单。我做过的几个 Agent 项目凡是“跑起来很爽”的月底看账单基本都倒吸一口凉气。普通聊天机器人一次问答最多烧一两次模型调用Agent 不一样一次任务里规划、路由、工具选择、结果解释、记忆压缩各付一次钱十几次调用打底一点都不夸张。更麻烦的是很多人一开始就把旗舰模型接到所有节点上上下文越堆越长重试逻辑又没做限制账单自然直线飙升。这篇文章不是讲怎么把 Agent 做出来而是把“怎么让 Agent 跑得不那么贵”这件事拆透。我会先从成本结构入手然后给出 6 个经过实际业务验证的控成本技巧再到具体踩坑案例和排查表。不管你是在 Coze 这种托管平台上搭工作流还是用 Dify 自建、或者直接撸 Harness / Multi-Agent 框架这篇都适用。1. 先把账单拆开Agent 的成本结构和普通聊天完全不是一回事很多团队看到 API 费用暴涨的第一反应是“换个便宜的模型”实际上模型单价只是冰山一角。Agent 场景下真正让账单失控的是调用次数和上下文长度这两项才是成本大头。1.1 一次 Agent 任务背后到底要调用多少次模型普通 ChatBot 一轮对话 1 次模型调用输入输出算下来就完事了。Agent 不一样它本质上是“模型驱动的状态机”每一步决策都要模型参与理解用户意图判断要不要进入工作流规划任务决定先调哪个工具、后调哪个工具选择工具参数把自然语言翻译成结构化的 tool call工具返回结果后由模型解读、判断是否继续结果需要总结、写入记忆时又是一次调用。我实际统计过自己跑的一个简历筛选 Agent一次完整的候选人评估平均要触发 9 到 14 次模型调用。按每次调用 3000-6000 tokens 算一次任务轻松烧掉 4-8 万 tokens。如果你用的是旗舰模型这一条流程跑下来可能就是几毛到几美元的消耗。一天跑几百个简历账单直接起飞。1.2 三大隐性成本比模型单价更可怕第一是模型错配。很多 Agent 搭建教程默认“主模型选最强的”于是意图识别、日期解析、关键词抽取这些简单活全用旗舰模型跑成本高一个数量级效果却没有本质区别。第二是上下文膨胀。工具调用场景下每一轮对话都会把系统提示、历史记录、工具返回值拼进去。我在实际项目里见过一个 Dify 工作流跑了几十轮之后单次请求上下文超过 40 万 tokens还没触发api error: 400 this models maximum context length is 1048576 tokens这种报错但单条请求的成本已经翻了十几倍。长上下文不是一次性收费是每一轮都在重复为历史长度付费。第三是循环和重试。解析 JSON 失败就重新调用一次模型、收到限流错误就重试三遍、Agent 一步卡住就反复让模型“再想想”。这些逻辑单独看都不起眼合在一起能把总成本翻倍。2. 技巧一给 Agent 装“短路开关”能不走模型就不走模型控成本的第一原则不是“用便宜的模型”而是“不要为了用 AI 而用 AI”。Agent 里很多环节用规则引擎、代码逻辑处理结果更稳、速度更快、成本为零。2.1 哪些环节不适合让模型出场我踩过的最典型的坑是把一句话分类、固定格式抽取、简单条件判断全部丢给大模型。比如用户输入“帮我查上海明天天气”第一反应是让模型抽取城市和日期。实际上这类结构化信息用正则表达式或者关键词匹配就能搞定连便宜模型都可以省掉。适合“短路”的环节包括硬编码路由根据关键词、分类标签、用户来源直接决定走哪条工作流参数校验日期格式、数字范围、必填字段用代码校验而不是让模型“理解”简单转换大写转小写、Markdown 转纯文本、JSON 字段重命名这些是脚本的活儿幂等去重相同指令重复提交用请求 ID 直接拦截连入口都不用进。2.2 实操规则先运行模型最后兜底我做 Agent 架构时习惯在入口加一道“pre-router”用最轻量的逻辑先处理一批请求。具体做法是输入先过规则引擎命中关键词库、正则库的直接走预设分支规则命中不了、确实需要语义理解的再进入模型层模型层内部再分级简单语义任务用便宜模型复杂任务用贵模型。这个“短路开关”在大多数工作流里能砍掉 40%-60% 的无效模型调用。有一次我给一个客服工单分类的 Coze 工作流做改造加了三层规则兜底之后月 API 费用直接降了一半多而且准确率反而上升了因为结构化数据不再被模型“自由发挥”搞乱。注意短路不是硬砍。如果规则覆盖率太低或者在模糊场景强行写规则会导致用户体验明显变差。我的判断标准是规则命中率至少要稳定在 70% 以上才值得做。3. 技巧二模型分级“配餐”便宜模型干杂活旗舰模型出精品这是成本优化里见效最快、也最容易做过头的一步。“一模型通吃”是 Agent 项目最常见的浪费但“全上最便宜的”又会导致重试率飙升、质量问题频出。关键是把任务按复杂度分层给每一层配正确的模型。3.1 先看价差再定分级策略不同模型每百万 tokens 的价差能到几十倍。旗舰模型和轻量模型之间的差距在“简单任务”上体现得并不明显但成本差是实打实的。举个例子一次工具调用任务里假设有 8 次简单操作意图识别、命名实体抽取、工具参数生成、2 次复杂操作最终总结、多条件推理。如果全部用旗舰模型假设每百万 tokens 10 美元一次任务的模型成本大约是 4 万 tokens * 10 / 100万 0.4 美元。如果把 8 次简单操作换成便宜模型假设每百万 tokens 0.2 美元那么成本就变成 8 次 * 4000 tokens * 0.2 / 100万 2 次 * 4000 tokens * 10 / 100万 0.0064 0.08 0.0864 美元。省了接近八成。具体怎么分级我的实践方案是三层L1 轻量层意图粗分类、格式抽取、文本压缩、简单路由。用 DeepSeek 大众版、智谱 GLM 系列、Kimi 这类性价比模型就够了。L2 中档层工具参数填充、结构化数据转换、一般问答。L3 旗舰层多工具协同推理、长文档总结、最终回复生成。只有这里才值得用 GPT-4o 级别或者各家旗舰模型。3.2 实操写一个简单的 model router如果是在 Dify、Coze 这类平台上节点里通常可以直接配置不同模型分级主要靠工作流分支。如果是自己写 Agent 框架我建议在调用层加一个 router根据任务类型返回对应的模型名。我用过一段比较轻量的路由逻辑伪代码大致是这样def route_model(task_type: str, complexity: str) - str: if complexity low: return deepseek-chat # L1 轻量模型 if task_type in (summarize, plan): return gpt-4o # L3 旗舰模型 return glm-4-flash # L2 中档模型当然不同服务商的模型名和价格会变我强烈建议以官方控制台为准同时把路由结果打印进日志方便后续复盘。经验心得分级之后要监控两个数字一个是 L3 模型的调用占比一个是重试率。理想的曲线是 L3 占比低于 20%、重试率低于 5%。如果你发现便宜模型重试率飙升说明分级分错了那不是省钱是烧钱重试。4. 技巧三上下文瘦身别把历史包袱背到每一轮上下文膨胀是 Agent 成本失控的隐形杀手而且是“越跑越贵”的元凶。很多 Agent 任务跑得越多上下文越长单次调用的输入 tokens 也跟着涨但真正有用的信息其实不到十分之一。4.1 上下文是怎么一点点变胖的有过实操经验的人应该都见过这种场景一个知识库问答 Agent每轮都把所有检索到的文档片段全部拼进 prompt一个多轮工作流系统提示词写了几千字、历史记录几十轮全量带入工具返回的 JSON 冗长无比也原封不动丢给模型再解读一次。我接过一个 Dify 工作流项目的优化上下文经常超过 20 万 tokens用户每问一句话模型都要重新读一遍这 20 万 tokens 的历史。到最后用户问“上次那个候选人电话是多少”成本已经接近一美元一次。存粹是背着一个越来越大的包走路。4.2 实操三种瘦身手段按需组合第一种是滑动窗口裁剪。只保留最近 N 轮对话和必要的系统提示更早的历史从 prompt 里丢出去必要时放到记忆系统里。N 通常是 5-10 轮具体看业务连续性要求。第二种是消息压缩。对话超过阈值时先把旧消息用一次便宜模型压成摘要后续只带摘要不带原文。这个技巧在 Coze 工作流里可以做成“会话压缩节点”在自建框架里可以做成一个前置函数。第三种是结构化记忆。把历史记录沉淀成结构化字段比如用户偏好、已查过的关键词、待办事项存在向量库或内存里。后续请求只拉跟当前任务相关的字段不拉整段历史。另外工具返回值也要做后处理。我在自己的 Agent 里统一要求工具返回只保留核心字段例如简历筛选时只保留“姓名、经验年限、技能集、当前职位”而不是把整份简历原文塞给模型。这样既降低成本也让模型更容易聚焦判断。注意裁剪上下文要小心“失忆”风险。金融、合同审查这类场景关键条款一旦被截断模型可能给出错误结论。我的做法是关键字段永远放摘要里不依赖滑动窗口只有雷同的闲聊内容才允许被压缩。5. 技巧四语义缓存让相似请求别再付第二次钱很多 Agent 处理的是高频、低变需求比如商品推荐、政策问答、报表生成。这些请求之间往往有大量重复内容而每次重复都在白白付费。语义缓存就是给 Agent 加一层记忆让相似请求直接命中历史结果不用再走一遍模型。5.1 缓存到底怎么工作原理很简单请求进来先做一次 embedding 向量化然后在缓存库里做相似度检索。当相似度超过阈值直接把之前的结果拿回来低于阈值才让模型继续跑。这样用一次 embedding 的小成本换掉一次完整 LLM 调用的大成本。算一笔账假设你的请求平均每次模型调用成本是 0.05 美元embedding 一次只要万分之几美元。如果缓存命中率有 50%那么 1000 次请求里省下 500 次模型调用成本从 50 美元变成 25 美元多一点再扣掉缓存开销也能省 45% 左右。5.2 实操什么场景适合加缓存什么场景别乱加适合加语义缓存的场景知识库问答库内容不常变问题表述千变万化但答案稳定规则类咨询请假政策、故障排查手册、产品说明等标准问答数据报表生成参数固定的周报/月报摘要可以直接复用。不适合加缓存的场景涉及实时数据比如“当前库存多少”就不能缓存旧结果强个性化输出生成内容依赖用户 ID、随机性比如营销文案创作合规敏感场景医疗诊断、法律意见这类缓存可能导致误导。实操上我会在模型 API 前面套一层代理请求先查缓存再决定是否转发给模型。缓存的 key 用 embedding 生成value 存模型的返回结果TTL 根据业务新鲜度设置通常是 5 分钟到 24 小时之间。注意语义缓存最怕“只差一点点就命中”的边界请求。相似度阈值设太低比如 0.7会命中语义不同但向量接近的内容回答错误设太高比如 0.95命中率又太低。我一般从 0.85 起步根据测试集的误命中率微调。6. 技巧五批处理与并发控制用调度换账单大家搜“ai agent 怎么扛并发”时第一反应都是上更多机器、扩容、压测。但结合成本视角答案恰恰是“别让所有任务一股脑同时打 API”。调度得好同样的业务量可以少付一大笔钱。6.1 批处理价格打折延迟换成本很多模型服务商都有批量模式比如 offline 批处理接口价格通常是实时模式的 50%。这类接口适合不需要立即返回结果的任务比如夜间批量清洗简历、定时爬取的文档摘要、批量生成商品描述。把实时任务和批处理任务分开能明显压降账单。我的习惯是用户看得见的交互走实时接口系统内部的数据处理、生成草稿、预聚合数据全走批处理。曾给一个文档处理类 Agent 做过改造70% 的任务挪到批处理单月 API 费用降了 40% 以上。6.2 并发不是越高越好这里还是要强调“削峰填谷”。当你把并发拉满去打模型 API很容易触发限流限流之后重试重试又产生费用还有可能因为排队导致超时然后又触发业务层的重试。这种重试风暴是 Agent 成本莫名翻倍的主要来源之一。实操时我会做三件事给 API 请求加队列和限速器按官方的 RPM/TPM 配额留出 20%-30% 余量不踩死线重试策略改成指数退避避免同一时刻集体重试把一次性的大并发任务拆成小批量匀速提交。另外如果用的是 Coze 这类托管平台限流规则通常是平台统一管理自己能控制的空间不大那就更要注意工作流内部不要设计无意义的并发分支。如果发现同一个任务里多个节点都在并发调用同一个模型 API先合并节点再谈扩容。经验心得并发控制优化通常能直接消灭“API error: 429”和后续的连环重试。我在一个数据抓取 Agent 上见过简单加了个令牌桶限速器之后不仅费用稳定了成功率反而从 91% 升到 98%。7. 技巧六记账先行给每次 Agent 运行算一笔明白账最后一个技巧其实应该最先做全链路记账。没有度量就没有优化很多项目成本失控是因为压根不知道一个任务跑完到底花了几次调用、多少 tokens、多少钱。7.1 建一个成本大盘别等账单上门不管你用哪种框架都可以在模型调用层加一个日志记录把每次请求的 model、input_tokens、output_tokens、timestamp、task_id 落库。如果你用 LiteLLM Proxy 或 OpenRouter 这类网关它们自带调用日志和成本统计省不少事自建的话最简单的就是用中间件在响应后把 usage 字段写进日志表。我习惯统计四个核心指标单任务成本中位数大多数任务应该集中在一个较低范围单任务成本 P9595 分位的成本用来发现“少数任务吃掉大部分钱”的情况每千任务消耗 tokens反映 Agent 的平均“废话率”缓存命中率判断缓存策略是否有效。有了这些指标你就能定位到底是哪类任务在烧钱。我见过一个 Agent表面看每任务成本正常拉出 P95 才发现有个“PDF 全文解析”分支单次要烧掉好几美元就因为工作流配置里把一个 MinerU 文档解析的返回值整本塞进了模型上下文。7.2 给典型任务设成本预算跑过阈值就告警更进阶的做法是“成本回归测试”。上线一个新版本工作流之前我先定义几个典型测试任务比如“简历筛选”“问题归类”“报告生成”跑一遍并记录成本基线。如果新版改动后某个典型任务的成本超过基线 30%就要回查是上下文变长了还是调用次数变多了。成本指标可以接告警单任务成本超过阈值就在群里报出来。我自己的项目里阈值是“单任务成本 0.15 美元”超过就查日志大多数问题出在长上下文或者重试上。提示记住看总账的时候把 API 之外的第三方服务费也算进来。一个 Agent 工作流里常常不只是模型费用还有 OCR、文档解析、搜索接口、向量数据库的费用这些都是成本的一部分别只盯着模型调用。8. 踩坑实录三个翻车现场和一张排查速查表写完技巧再来讲几个真实翻车的例子。这些坑不是从文档里看来的是我和团队在项目里一个个踩出来的。8.1 翻车现场一全旗舰模型方案有一个项目一开始架构很“豪华”所有节点全用 GPT-4o 级别模型用户交互倒是很流畅。上线一周账单出来吓一跳日均费用上千。后来加上分级路由把 70% 的简单节点换到便宜模型费用降到原来的 1/4最终总结类节点保留旗舰模型用户体感变化很小。这是最典型的“能力溢出”问题。模型强是好事但不是所有环节都需要那么强。工具参数抽取、关键词判断、意图粗分这些环节便宜模型和小模型完全能顶住。8.2 翻车现场二无限重试死循环另一个项目里Agent 在调用某个外部工具时经常超时于是我在流程里写了“失败后重试 5 次”。结果外部工具恢复慢的时候一次任务光重试就烧掉 6 次模型调用成本翻倍。后来我把重试策略改成指数退避并且加了一个熔断逻辑连续失败 3 次就直接转人工不再让模型反复尝试。这里提醒一句很多模型调用异常是限流导致的你越急着重试越容易触发连环限流。重试之前一定要先看看错误码是不是 429 或者 5xx再决定退避策略。8.3 翻车现场三长会话把成本拖死还有个知识库 Agent用了一段时间后用户反馈“变迟钝了”我看日志才发现上下文已经堆到了十几万 tokens单次问答成本从 0.02 美元涨到 0.5 美元以上。加了滑动窗口和摘要记忆之后成本回落响应速度也回来了。这个问题在长会话 Agent 里特别隐蔽因为它不是突然爆发的而是每天涨一点等注意到时已经很高了。建议每周看一次“单任务 tokens 均值”超出基线就主动压缩。8.4 Agent 成本问题排查速查表下面这张表可以收藏起来遇到成本异常直接对表查。症状可能原因排查方向常用解法单任务成本突然翻倍上下文膨胀看 input_tokens 日志加滑动窗口/摘要压缩费用高但调用次数不多用了旗舰模型处理简单任务按任务类型统计模型分布模型分级路由调用次数暴增循环重试/Agent 死循环看错误码和重试日志指数退避熔断相似请求重复扣费没有缓存看重复率指标加语义缓存API 请求大量 429并发打满配额看限流错误率加队列/限速器上下文超长报错单条消息塞入过多历史检查请求 tokens裁剪历史、结构化记忆工作流某个节点特别贵工具返回全文进入模型看节点级成本分布工具返回后做字段后处理月末账单和预期差很多没有台账和告警检查是否有未记录调用上线成本监控控成本从来不是一刀切地把模型换便宜而是先把链路画出来在每个入口问一句这一步真的需要大模型吗需要多大的模型能不能复用上一次的结果我在实际项目里的体会是把上述 6 个技巧全部落地之后Agent 的 API 成本降到原来的 1/3 到 1/5 是完全可行的而业务质量不会下降甚至因为减少无效调用稳定性反而更好。建议你先做记账再逐条上“短路开关”和“模型分级”这两步最容易见效。等到链路稳定了再打磨缓存和批处理把成本压到极致。