在几乎所有 AI Agent 项目中，成本失控都会以一种非常相似的方式出现。
前期评估时：
「模型调用不贵，一个月也就几百、几千块。」
上线一段时间后：
「为什么账单翻了十倍？我们明明没加新功能。」
这不是个例，而是 Agent 项目的结构性结果。
一个必须先澄清的事实
AI Agent 的成本，从来就不是「模型调用费」。
模型费用只是最容易被看到、也是最容易被低估的那一部分，也就是你认为模型调用和实际的模型调用是两码事。
真正让成本失控的，是 Agent 的运行方式。
如果说传统系统的成本主要来自：
-
• 请求量 × 单次计算成本
那么 Agent 系统的成本模型更接近：
-
• 行为次数 × 行为链路长度 × 不确定放大系数
而这个「放大系数」，正是很多团队在 Demo 阶段完全没有意识到的部分。
成本为什么在 Demo 阶段几乎不可见？
因为 Demo 运行在一个极端理想化的前提下：
-
• 单用户 -
• 单任务 -
• 极短会话 -
• 无失败重试 -
• 无异常分支
也就是说，你根本想想不到如何设计一个错误的、甚至死循环的Demo， 此时你看到的成本，本质上是：
一次「理想路径」的执行成本。
但真实业务中的 Agent，很少走理想路径。
一旦进入生产环境，下面这些「隐性成本源」会被迅速放大。
成本失控的第一层原因：行为不可预测
传统系统的行为是确定的：
-
• 一个请求 -
• 一条固定路径 -
• 可提前估算复杂度
而 Agent 的行为具有三个典型特征：
-
1. 路径动态生成 -
2. 执行次数不固定 -
3. 失败往往伴随重试或自我修正
举一个常见但容易被忽略的例子：
-
• Agent 认为「结果不够好」 -
• 自动重新规划 -
• 再次调用同一组 Tool
从逻辑上看，这是一种「更聪明」的行为。
但从成本角度看：
一次业务请求，悄无声息地变成了多次完整执行。
而这个过程，往往没有任何显式告警，这样原来你认为的一次业务调用，可能会放大成 10 次甚至 100 次的业务调用估算。
第二层原因：Tool 调用是成本的真正放大器
很多团队在算成本时，只关注：
-
• LLM Output Token
却忽略了一个事实：
在 Agent 系统中，模型调用往往只是「决策成本」，而不是「执行成本」。
真正昂贵的，通常是 Tool：
-
• 外部 API -
• 内部系统接口 -
• 数据库查询 -
• 任务型计算
而 Agent 与 Tool 的关系，存在一个天然的放大效应：
-
• 一次推理 → 多次 Tool 调用 -
• 一个 Tool 失败 → 多次重试 -
• 一个决策偏差 → 一整条链路被放大
最终结果是：
模型输出只占账单的一小部分，Tool 才是成本黑洞。
第三层原因：成本无法归因
这是最容易被低估、但杀伤力最大的一个问题。
在很多 Agent 系统中，成本呈现为：
-
• 混合账单 -
• 无法区分是哪个 Agent -
• 无法定位是哪个能力 -
• 无法判断是否「值得」调用
于是成本讨论往往演变成：
「好像都挺有用的，但就是太贵了。」
一旦成本无法归因，就不可能进行理性决策：
-
• 不能裁剪 -
• 不能限流 -
• 不能优化
最终只能选择：
整体关掉，或者整体硬扛。
第四层原因：缺乏「成本刹车系统」
在传统系统中，特别是微服务系统，我们习惯使用：
-
• QPS 限流 -
• 超时 -
• 熔断
但在 Agent 系统里，这些机制往往并不存在于正确的位置。
原因很简单：
-
• 行为是动态生成的 -
• 成本发生在 Tool 层 -
• 决策层并不知道执行层的真实代价
结果就是：
Agent 并不知道自己「花了多少钱」。
没有成本感知，自然也谈不上自我约束。
一个高度抽象但真实的成本失控场景
下面简单抽象一下典型的失控场景：
-
• Agent 接到一个复杂任务 -
• 为了「把事情做好」，不断补充信息 -
• 多轮搜索 + 多次内部系统查询 -
• 每一步都「看起来合理」
但从系统视角看：
-
• 单个请求消耗了数十倍于预期的资源 -
• 并发一上来，整体成本瞬间爆炸
此时你才发现：
Agent 在逻辑上是自洽的，但在工程上是失控的。
成本控制，必须从「运行方式」入手
降低 Agent 成本，几乎无法通过「调模型参数」解决。
真正有效的控制点在于：
-
• 是否能限制单个能力的资源上限 -
• 是否能隔离高风险 Tool -
• 是否能在异常行为出现前中断执行
这也是为什么容器、调度、隔离在 Agent 系统中如此重要。
你不需要让 Agent 更节俭，因为 Agent 的节俭可能随时影响系统的性能，
你需要的是让系统具备「强制节俭」的能力。
5 个成本问题
同样的，在 Agent 进入真实业务前，我设计了几个问题， 来帮助大家在设计和实现 Agent 系统的时候更好的理解和控制成本：
-
1. 一次完整任务，最多允许消耗多少资源？ -
2. 单个能力是否有明确的资源与调用上限？ -
3. 成本能否精确归因到具体 Agent / 能力？ -
4. 异常行为出现时，是否能自动中断？ -
5. 当前成本结构，是否支持规模化增长？
这些不是优化问题，而是生死问题，我们在没有很好架构支持的时候， 甚至可以简单把这些问题的答案硬编码进系统，这样虽然让系统变得不那么智能，甚至失败， 但是在控制成本的同时，也更容易发现问题。
一个结论
AI Agent 的成本问题，本质上不是「贵不贵」，而是「有没有上限」。
没有上限的系统，在任何规模下都会失控，等到真正失控的时候，就会面临两难抉择：停掉或优化系统，还是硬抗。
写在最后
很多团队在 Agent 项目中都会经历同一个阶段：
-
• Demo 阶段： 「这东西真强，而且不贵。」 -
• 上线阶段： 「这东西确实强，但我们用不起。」
问题不在于 Agent 不值得， 而在于：
你是否为它设计过「成本边界」。
--- END ---