Agent成本失控？核心不在模型单价，而在编排链路优化

直接说结论：Agent任务成本，核心不在模型单价，而在你设计的整个编排链路。很多团队做Agent，第一反应是盯API账单，算一个任务烧了多少token，其实真正的失控点，都在你看不见的地方。

这几年做Agent应用的优化，大大小小的项目接触了不少，有一个任务从最初的几千次调用跑到几百万次的真实案例，账单曲线像坐了火箭。痛定思痛，把成本管理的整套方法论摸了一遍，今天把这些经验整理成文。这篇文章写给所有正在做Agent开发、准备上Agent功能，或者已经被Agent成本搞得焦头烂额的团队。无论你用的是哪家大模型，底层逻辑相通，方法论可以直接迁移。

1. Agent任务成本失控的典型场景分析

1.1 一个让我印象深刻的成本事故

某公司做了一个文档处理Agent，用来抓取PDF、提取关键信息、生成摘要、归档到知识库。上线第一个月，日均调用大概几千次，账单在预算线以内，大家没太在意。到了第三个月某天，运维同学截图发到群里，账单数字比上个月翻了十倍。

我当时第一反应是"是不是有恶意请求"，查了一圈，没有。流量正常，没有攻击，没有异常用户，PV也没涨多少。后来把用户行为路径一条条拉出来才看明白：每个用户的一个简单提问，背后Agent的动作链条是——先检索知识库（调一次向量检索），再调用LLM做意图判断（一次），再调一次LLM做内容生成（一次），生成后发现格式不对，又调一次LLM做格式修复（一次），再调用一次LLM做自我反思校验（一次），校验不通过，又重跑了一遍完整链路。

一个问题五次大模型调用，其中两次还是因为"格式不对"这种完全可以通过结构化输出规范解决的问题。十倍的账单，不是流量涨了十倍，而是单位任务的调用链涨了十倍。

1.2 为什么会失控：从调用链路上找原因

这其实暴露了Agent成本管理的核心矛盾：Agent越智能，决策路径越复杂，调用的资源就越多。以前做个聊天机器人，一个是请求一个响应，成本固定；现在做Agent，一个请求里可能嵌套好几轮规划、工具调用、反思、重试，每一步都是钱。

我把失控原因拆成五类，大家可以对号入座：

• 规划过度：Agent在每一步都调LLM做"下一步做什么"的决策，有些场景明明规则就够了，非要交给模型。
• 上下文膨胀：多轮会话里，每轮都把历史对话完整塞进去，token量线性增长。
• 无效重试：因为输出格式、参数错误、工具调用失败导致的重复调用。
• 万金油模型：所有任务都用最强模型，明明简单的摘要任务，非要用高级推理模型。
• 缺少审计：没有记录每条链路的实际消耗，出现问题两周后才从账单上发现。

每个问题背后都有对应的解法，下面逐个展开。

2. 成本账单拆解：显性成本与隐性成本

2.1 显性成本：token消耗、工具调用费用、算力资源

我们看Agent任务成本，第一时间看到的是token消耗。一个任务的token通常包含三块：

• 输入token：每次请求发给模型的全部上下文，包括系统提示词、对话历史、检索到的资料、工具返回的结果。
• 输出token：模型生成的回答，包括普通回复、思考过程、结构化输出。
• 缓存token：如果有prompt缓存机制，命中缓存的部分费用通常有折扣。

这块的优化空间其实很有限，因为token单价是模型厂商定的，你能做的只有控制用量，这是第二、第三部分要讲的内容。

工具调用费用是容易被忽略的一块。Agent要调外部API，有些API按次数收费，有些按数据量收费，还有些按结果质量收费。每次工具调用的失败重试，都是双倍的成本。我在某个项目里就吃过亏：Agent的搜索工具，查询一次两块钱，一次任务里重试了四次，光工具费用就是八块，比模型token还贵。

算力资源这块，如果你的Agent跑在自己部署的GPU集群上，那就是显存占用和计算时长的问题。这类成本更刚性，不太容易通过优化提示词来解决，只能从模型选型和架构上入手。

2.2 隐性成本：调试时间、失败重试、等待时间

隐性成本是真正的大头，很多团队的账单好看，开发成本却失控了，因为隐性成本不在API账单里。调试时间是最容易被忽视的：一个Agent行为不符合预期，排查原因可能花半天。这半天的工程师时间，按人力成本折算，远超模型调用费。

失败重试也是典型的隐性成本。我用过一个Agent，工具参数生成经常出错，每次出错重试一次。虽然重试的token不多，但重试之后Agent可能需要修正上下文，把错误信息和新的请求一起再次发给模型，上下文又大了一截。失败重试不仅浪费token，还增加了任务的延迟，用户体感变差。

等待时间这块，更偏向用户体验成本。用户发起一个Agent任务，如果要在服务器上跑几十秒才能出结果，用户可能已经走了。很多团队为了缩短等待时间，会引入多线程并发，结果并发本身就带来了更多成本。

后来我给任务设计了任务延后校验机制：不在用户等待期间反复让模型自检，而是在结果返回之后，用低成本的方式并行校验。这样用户体感快了，成本反而下降了，因为模型不用为不必要的反思付费。

3. 运行时控制三板斧：预算、缓存、上下文瘦身

3.1 设置预算上限：给Agent带上一把锁

预算控制是成本管理的第一道防线。没有预算上限的Agent，就像没有保险丝的电表，火烧起来了才知道有问题。

我的做法是三层预算嵌套：

• 单次任务预算：一个Agent任务最多允许消耗多少token，超过就中断，返回兜底结果。比如一个文档分析任务，设定上限是2万token，如果跑偏了，超过2万立即停止。
• 每用户预算：按用户维度设置上限，防止个别用户高频调用打爆账单。比如免费用户一天最多消耗1万token，付费用户5万。
• 总预算：整个应用层的月度上限，到了阈值自动熔断或者降级到轻量模型。

预算上限的实现方式，需要在每次模型调用的返回结果里统计usage数据，累加到当前任务计数器上。一旦超过阈值，不是直接报错，而是让Agent走降级路径——比如返回一个缓存结果，或者交给人工处理，或者用规则引擎生成一个简化答案。

有人担心设了上限会影响正常体验，我在实际项目里的经验是：真正合规的任务，消耗都很稳定，几乎不会触顶；触顶的那些，大概率是链路出了问题。预算上限更多是保护机制，而不是限制器。

3.2 引入缓存机制：同一批问题别付两次费

缓存是成本管理里性价比最高的一招，没有之一。

我见过太多Agent任务，同一个问题，不同用户问了一遍又一遍，每次都是完整调用大模型生成答案。这本质上是在浪费钱。实际上大部分应用，核心问题的答案是可以复用一段时间的。

缓存分两种：

• 精准缓存：完全相同的请求，直接命中缓存。适合FAQ类的Agent。
• 语义缓存：语义相似的请求，从缓存里找相近答案。需要引入向量检索，把用户问题转成向量，去缓存库匹配相似度高的历史答案。相似度超过阈值就直接复用。

我这里有一个实际案例：一个电商客服Agent，接入语义缓存之后，成本下降了四成，而且回答速度大幅提升。因为大多常见问题本来就该有标准答案，不需要每次都让模型重新组织语言。

缓存的TTL设置也有讲究。我习惯按业务类型区分：价格类问题缓存几分钟就够了，规则类问题可以缓存几天，政策类问题一有变动立即失效。这类配置，在Agent产品的运营后台直接可视化调整，也不复杂。

3.3 上下文瘦身：别让历史对话拖垮每轮请求

多轮对话是Agent的常态，但很多Agent把多轮对话里的全部历史每一轮都发给模型。假设一轮对话是1000token，聊十轮之后，每轮请求都要带1万token的上下文，这是个累加的乘法效应——每轮成本都在涨。

上下文瘦身的思路是分层摘要：只保留最近几轮的完整上下文，更早的历史，定期用LLM生成一个摘要放在系统提示词里。模型不需要每句话都记住，只需要记住核心事实和用户意图。

还有一个容易忽略的地方：系统提示词。很多团队的Agent系统提示词越写越长，动辄3000token，而且每个请求都会带上。其实系统提示词里的很多内容是静态的，比如"你是一个客服助手""回答要礼貌"这种，完全可以通过prompt缓存来大幅度降低成本。大部分模型厂商都提供prompt缓存，之前调过的前缀token会优惠收费，甚至免费。前提是系统提示词的文本保持稳定，不要频繁改动开头部分。

工具返回的结果也要瘦身。Agent调用搜索工具，返回了十条结果，每条都几百字，然后全部塞进上下文让模型分析。更合理的做法是：把工具返回结果做摘要，或者只提取关键字段传给模型，特别长的工具结果，先进行一次格式清洗。

4. 可观测性建设：让每一笔成本都有账可查

4.1 日志埋点：完整链路的结构化记录

成本管理的第一步是能看到成本，不是看到月度账单，而是看到每个任务、每一步的消耗。这是一切优化的基础。如果只知道"上个月花了三万"，根本没法定位，必须知道"哪类任务、哪个环节花的钱最多"。

我在每个Agent任务里会记录这些字段：

• 任务ID、会话ID、用户ID
• 模型名称、调用次数、每次的输入/输出token数
• 工具名称、调用次数、每次的耗时与费用
• 任务总耗时、总成本、是否被预算截断
• 用户最终是否满意（是否追问、是否反复重试）
• 上下文快照的大小、缓存命中情况

这些埋点埋好之后，按任务类型、用户类型、时段等维度去聚合，成本就变成了一堆可以随时查询、切片的量。我习惯把Agent执行日志和成本日志分开存。全量链路日志可以存在对象存储里，按天分区，成本明细则存在结构化数据库里，方便按维度做聚合分析。

4.2 成本归因：按任务类型、调用环节做聚合分析

埋点数据有了，接下来关键的动作是成本归因。每个任务的总成本可能是多个环节累加的结果，归因分析就是拆解出每个环节各自花了多少钱。

我的归因分析框架：

• 按任务类型归因：文档总结、代码生成、数据分析、客服问答各自占比多少。
• 按调用环节归因：规划、执行、反思、校验分别花了多少钱。
• 按失败归因：成功任务的成本 vs 失败任务浪费的成本。
• 按用户归因：哪些用户消耗了最多的资源，是合理的还是异常的。
• 按时段归因：高峰期的成本因子，是否可以使用排队降级策略。

基于归因结果，我基本每周都能发现一个可以优化的点。比如有一次发现某类任务的"反思"环节占了百分之四十的成本，仔细观察是提示词里让模型"逐步验证"，模型就真的一步一步检查，每一步都消耗token。后来把这个环节改成只输出最终结果与异常标记，成本立刻下降了三分之一，准确率反而没受影响。

5. 长期成本治理：从设计层面控住成本

5.1 Agent职责边界设计：别让一个Agent干所有事

一个典型的成本失控模型是：一个超级Agent，什么用户问题都能处理，什么问题都往最大的模型里丢。表面上很"智能"，实际上每一类任务的成本都无法单独优化。

我的建议是把Agent拆成小的专业分工，各司其职：

• 网关Agent：负责识别用户意图，把任务路由给对应的子Agent。这个Agent不需要很强的推理能力，常用小模型就够。
• 执行Agent：负责具体任务，比如数据查询、代码执行。按任务复杂度，再分一级。
• 审查Agent：负责校验执行结果，只在关键任务上启用。

这个做法的好处是：意图识别用低成本模型，简单任务用低成本模型，只有复杂任务才启用高成本模型，成本能控制在较低水平。而且单个Agent职责清晰，它的prompt和few-shot示例都可以精简，对上下文的消耗也小。

我见过很多团队，不是不知道这个道理，而是产品迭代节奏太快，来不及做角色拆分就上线了。等到账单出来才开始重构，往往要伤筋动骨。建议在Agent应用设计阶段就做任务分类和路由设计，这比事后优化省太多事。

5.2 任务分级策略：什么样的任务配什么样的模型

不是所有任务都需要最强的模型。任务分级是成本管理中收益最直接的手段，也是最容易被忽略的手段。

我的分级策略：

L0和L1可以覆盖大概六到八成的实际任务。真正需要L3的任务，每天占比可能不足百分之五。把六到八成的任务从贵模型换到便宜模型上，整体账单的变化非常可观。

任务分级的实现方式可以在网关Agent的prompt里直接指定分级规则，也可以通过独立的意图分类模型实现。我自己更倾向用一个非常轻量的分类器做预判，然后按分类结果决定走哪个链路。分类器即使判断错了，顶多是成本高一点，不会影响功能。

6. 我的实操经验与几处关键教训

6.1 三个你大概率踩过的坑

第一个坑是忽视工具返回的内容量。工具大模型返回几百KB的数据，Agent会把这些数据全部塞到上下文里，结果模型还没开始干活，光输入token就爆了。这种其实是工程问题，解决思路是在工具层做数据截断、摘要、或者在工具返回值里用结构化的方式表达关键信息，而不是把原始数据一股脑交给模型。

第二个坑是提示词频繁改开头。prompt缓存要求前缀稳定，但你今天加了一个示例，明天换了一个措辞，缓存命中率就一路下滑。很多人以为prompt缓存是自动的不用管，其实它对前缀稳定性是有要求的。团队里应该指定一个人专门管prompt版本，其他人想改，走评审流程，避免一天改八次。

第三个坑是让Agent做它本来不需要做的事。我见过一个Agent，用户只是问"今天天气怎么样"，结果Agent自己决定去搜索、去对比历史数据、去生成一篇天气预报分析报告。看似很酷，其实消耗的成本比普通天气查询高了十倍。这个问题的解法是，在设计阶段就定义好"最小必要动作"——Agent只做达成目标所需的最少步骤，不要过度发挥。

6.2 我实践下来的推荐配置

最后分享一套我目前用下来比较顺的组合配置。

单次任务的预算上限设为预估成本的两倍，低于这个阈值，任务基本都能正常完成，超过的就是异常链路。每用户每日预算上限设置在合理区间，高消费用户单独出策略。语义缓存优先覆盖客服问答、知识库检索、固定流程操作这几类高频场景。上下文采用最近N轮+历史摘要的方案，系统提示词控制在2000token以内并保持稳定。任务分级策略严格落地，六七成任务走低成本链路。

这套机制配上日志埋点，我实际操作后，月度成本大概能降一半以上，同时用户平均等待时间从原来的十几秒降到了五秒以内。

成本管理不是一次性的事，它是随着Agent链路调整、用户分布变化、模型迭代持续更新的过程。我现在的习惯是每周固定时间看一次成本归因报表，半个月调整一次分段策略。Agent成本管理与其说是一个技术问题，不如说是一个持续优化的工程习惯。哪个任务花多少钱，花得值不值，自己心里有数，这感觉比裸奔式的上线安心太多了。