为什么智能体成本预测已经失效 —— 以及我们该如何应对

你的财务团队想要一个数字。AI 智能体系统每月会花费多少钱？你根据平均 Token 使用量给出了估算，乘以预计的请求量，并加上了安全余量。三个月后，实际账单是预测值的 3 倍，而且没人能解释原因。

这并非预算编制的失败，而是建模的失败。传统的成本预测假设单次请求的成本会聚集在一个可预测的平均值附近。智能体系统在每一个层面上都打破了这一假设。执行路径是多变的。每次请求的 LLM 调用次数是多变的。每次调用的 Token 数量是多变的。这些变量之间的相互作用产生了一个带有“肥尾”（Fat tail）的成本分布，从而吞噬了你的利润。

根本问题：随机执行路径

传统的 API 接口具有确定性的成本特征。一个请求进来，访问数据库，返回响应。你可以测量平均成本，计算标准差，并以合理的准确性进行预测。

智能体工作流则完全不同。一个被赋予“研究此市场并提供建议”任务的智能体，可能需要 3 个推理循环，也可能需要 30 个。它可能调用 2 个工具，也可能调用 12 个。每次工具调用可能第一次就成功，也可能触发一连串的重试。单次请求的成本不是一个数字 —— 它是一个分布，而这个分布的特性导致了传统预测方法的失效。

核心问题在于，智能体成本随输入的**熵（Entropy）而非规模（Volume）**而伸缩。一千个简单的查询可能比一百个模糊的查询成本更低。但你的预测模型不知道用户下个月会发送哪种类型的查询，你的用户自己也不知道。

生产环境的数据证实了这一点。团队经常报告在同一工作流中，最便宜和最昂贵的请求之间存在 10 倍的成本差异。某个部署项目为一个研究智能体预测了 $4,000/月 的费用，结果实际达到了 $11,200 —— 这不是因为流量增加了，而是因为用户开始提出更复杂的问题，在模糊查询下触发了 10-14 层的循环链。

为什么 Token 预算是必要的，但还不够

最明显的应对方式是限制成本：为每个请求设置最高 Token 预算，并在智能体超过限制时将其终止。这可以作为一种熔断机制，但它是一个糟糕的规划工具。

Token 预算上限截断了工作，而不是改变了策略。当一个智能体在推理中途达到预算上限时，它不会优雅地简化其方法 —— 它会直接停止。用户得到的是部分答案或错误。你控制了成本，但破坏了价值。

这种区别至关重要：Token 预算上限和**成本感知规划（Cost-aware planning）**解决的是不同的问题。上限是说“在 $X 元处停止支出”。成本感知规划则是说“既然你有$X 元，请选择一种能在该预算内提供最佳结果的策略”。前者是护栏，后者是架构。

关于成本增强规划的研究使这一点变得具体。当原生尖端模型（GPT-4.1, Claude 3.7）在多步规划任务中面临严格的预算约束时，其成功率会降至 2% 左右。而同样的模型在使用成本感知树搜索（Cost-aware tree search）时，成功率可达 71-73% —— 这不是通过增加支出实现的，而是通过探索更便宜的解决方案路径并及早修剪昂贵的分支实现的。预算不仅仅是一个限制；它是一个重塑智能体策略的规划输入。

大多数生产系统只实施了上限，而没有进行规划。他们设置了 max_tokens 并称之为成本管理。其实不然。

预测中遗漏的智能体成本五个层面

Token 成本是每个人都在盯着的项目。但在生产环境的智能体系统中，Token 往往不到总成本的一半。一个完整的成本模型需要包含五个层面：

Token 消耗。 循环中每次 LLM 调用的输入和输出 Token —— 包括推理、重新规划和重试尝试。这是出现在你的 API 账单上的内容。

工具执行。 智能体进行的每一次外部 API 调用、数据库查询和函数调用。有些工具很便宜（如键值查找），有些则很昂贵（例如每次查询 $0.01 的网页搜索 API，智能体每个会话可能会调用 40 次）。工具成本的差异往往高于 Token 成本的差异。

状态与内存。 向量数据库查询、Redis 缓存、会话持久化和长期记忆检索。将 RAG 的 top-k 从 10 减少到 4 可以降低 25% 的检索成本，但大多数团队从未单独测量这一层。

计算基础设施。 Kubernetes Pod 扩缩容、冷启动损耗、突发流量下的自动扩容延迟。智能体产生的负载模式具有峰值且不可预测，难以通过预留容量来平摊成本。

可观测性开销。 日志记录、追踪和指标保留。当你追踪分布式智能体中的每一次工具调用、每一个推理步骤和每一次重试时，对于低量级、高复杂性的工作流，可观测性成本可能会超过推理成本。

预测误差会在这些层面上叠加。如果你对 Token 的估计误差为 30%，对工具调用的误差为 50%，并且完全忽略了可观测性成本，那么总误差并不是这些误差的平均值 —— 它会在整个架构栈中成倍增加。

单次请求成本是一个错误的指标

传统的单位经济效益问题 —— “单次请求的成本是多少？” —— 假设了请求是正确的衡量单位。对于 Agent 系统而言，事实并非如此。

一个更好的指标是 单次达成结果成本 (Cost per Accepted Outcome, CAPO)：即交付一个真正满足你意图的结果所产生的全部加载成本。该指标捕捉到了一个现实：Agent 在得出有用答案之前，会产生失败的尝试、部分结果和重试链。三次失败尝试后跟着一次成功，意味着你的 CAPO 是单次尝试成本的 4 倍 —— 而单次请求指标永远无法反映出这个数字。

CAPO 还揭示了单次请求指标所隐藏的东西：失败长尾的成本。跟踪分布而非平均值能暴露成本曲线的形态：

• 中位成本 告诉你基准效率。
• P95 成本 告诉你重试风暴和工具调用级联发生的地方。
• 失败成本占比（失败运行成本 ÷ 总成本）告诉你你在那些没有产生价值的工作上花了多少钱。

一项 FinOps 分析发现，两个拥有相同许可证的客户之间存在 10 倍的成本差异，这完全可以用工作流标准化来解释 —— 其中一个客户的用户触发级联重试的频率要高得多。其单次请求的平均值几乎完全相同，但成本分布却大相径庭。

真正有效的方法：决策循环成本建模

与其根据平均值进行预测，不如从决策循环开始建模成本：

第 1 步：映射决策图。 每个 Agent 工作流都有一个由可能的执行路径组成的有向图。映射节点（LLM 调用、工具调用、条件分支）和边（成功路径、重试路径、回退路径）。这就是你的成本拓扑。

第 2 步：为每个节点定价。 为每个节点分配成本分布（而非单点估算）。一个 LLM 推理步骤的成本可能在 0.02 美元到 0.15 美元之间，具体取决于输入上下文长度。一个网络搜索工具调用的每次调用成本可能为 0.01 美元，但在每个工作流中可能会发生 1-40 次。

第 3 步：模拟图。 在决策图中运行蒙特卡洛模拟，从每个节点的成本分布中进行采样并遵循分支逻辑。一千次模拟可以为你提供完整工作流的成本分布 —— 包含百分位数，而不只是平均值。

第 4 步：针对生产环境进行验证。 将你的模拟分布与实际生产成本数据进行比较。差距会揭示哪些节点的成本模型校准有误，或者哪些分支概率是错误的。

这种方法不会给财务部门一个单一的数字。它给他们一个带有置信区间的范围：“80% 的请求成本在 0.03 美元到 0.40 美元之间，但由于复杂的多步推理链，5% 的请求成本将达到 0.80-2.50 美元。” 这是诚实的，而且是可操作的 —— 昂贵的长尾变成了设计目标，而不是意外惊喜。

塑造策略而非仅限制支出的护栏

有效的 Agent 成本控制需要在多个层面设置护栏，每个层面都有不同的目的：

循环限制 封顶了推理与行动循环的次数。一个限制在 6 个决策跳跃内的 Agent 的行为方式，与一个允许 20 个跳跃的 Agent 根本不同 —— 它会更积极地规划并尽早确定路径。一个团队通过实施 6 跳上限并配合激进的 Prompt 压缩，在一夜之间将 Token 消耗降低了 38%。

工具调用上限 专门限制昂贵的操作，而不是平等地限制所有操作。每个工作流 5 次网络搜索的子上限几乎不需要成本即可实施，但能防止“失控研究”模式 —— 即 Agent 在几十个查询中循环往复，只为完善一个本该在前期以不同方式提出的问题。

分层 Token 预算 为不同的工作流阶段分配不同的预算。规划阶段获得的预算比执行阶段少。反思阶段获得的预算最少。这迫使 Agent 在简洁至关重要的地方保持简洁，只在有回报的地方详尽表达。

租户级支出上限 配合异常检测，防止任何单个客户或团队消耗不成比例的资源。这在多租户 SaaS 中尤为关键，因为一个客户复杂的工作流可能会影响共享基础设施成本。

关键洞察在于，设计良好的护栏不仅能防止超支，还能以通常能提高输出质量的方式改变 Agent 的行为。一个被迫在预算内规划的 Agent 比一个拥有无限资源的 Agent 能做出更好的决策，其原因与有截止日期的工程师比有无限时间的工程师能编写更好的代码是一样的。

没人愿意承担的组织问题

AI Agent 的成本预测失败有一个技术原因（随机执行路径），但之所以持续存在则是出于组织原因：没人负责预测。

工程团队负责 Agent 架构但不负责成本目标。财务团队负责预算但无法对随机系统建模。产品团队负责用户体验但看不到单次达成结果成本的数据。结果是，预测变成了项目审批期间的一次性练习，基于无法反映生产负载的基准测试，并且随着使用模式的演变从未得到更新。

解决方案是结构性的。必须有人 —— 无论是 FinOps 工程师、平台团队还是专门的成本负责人 —— 需要负责生产成本数据与预测模型之间的反馈闭环。他们需要访问每个工作流的成本分布，而不仅仅是汇总的 API 账单。而且他们需要拥有设置影响 Agent 行为的护栏的权力，而不仅仅是在超出预算时发出警报。

Gartner 估计，到 2027 年，超过 40% 的 Agentic AI 项目将由于成本上升和业务价值不明确而被取消。这些取消中的大多数并不是因为 Agent 不起作用 —— 而是因为成本不可预测，且没人构建使之可预测的基础设施。

展望未来

Agent 成本预测之所以失效，是因为我们正试图将确定性的预测工具应用于一个随机系统。未来的发展需要三个转变：从单点估算转向成本分布，从单次请求指标转向单次结果指标，以及从 Token 限制转向具备成本意识的 Agent 规划。

从理论上讲，这些都不难。蒙特卡洛模拟（Monte Carlo simulation）是一项成熟的技术。成本增强搜索（Cost-augmented search）已有相关的研究论文。决策循环成本建模则是纯粹的工程问题。真正的障碍在于组织层面：建立监控基础设施、明确责任归属，并接受“视情况而定”其实是对“这需要多少成本？”这一问题的正确回答——只要你能量化它取决于什么。