AI Agent成本预测：在用户点击运行前估算工作流开销

一次失败的 AI workflow 已经很烦人了。一个成功运行的 workflow 但悄悄比用户支付的费用更贵，则更糟糕。

这就是许多开发者在 demo 生效后会遇到的那个令人不安的缺口。Agent 可以搜索、检索、调用工具、起草输出、从错误中恢复。但在一个用户点击 Run 之前，产品往往无法诚实回答一个简单的问题：这个任务可能花多少钱？

本指南展示如何在产品 workflow 中构建 AI Agent 成本预测，在费用损害定价、可靠性或信任之前就做好预防。

目标不是让每个 token 都可预测。目标是让成本足够透明，这样你的应用可以在资金消失之前选择更安全的路径。

为什么成本预测正在成为一项产品功能

AI 成本跟踪已不再罕见。最近的 AI 成本治理报告突出显示了一个明显的分歧：大多数团队能够在 AI 基础设施费用发生后看到它，但只有极少数能够准确预测它在工作运行之前。

这很重要，因为 agent workflow 不是简单的 API 调用。它们会分叉。

一个普通的 LLM 特性可能长这样：

input -> model -> output

一个 agent workflow 通常更像这样：

input
  -> plan
  -> retrieve documents
  -> call tool
  -> inspect result
  -> retry with different arguments
  -> call another model
  -> summarize
  -> validate
  -> repair output
  -> send final answer

每个分支都可能增加 token、工具调用、延迟和失败处理。如果你的产品只在运行后才计算成本，你不是在预测，你是在看账单。

对于独立开发者和小团队来说，这是痛苦的，因为一次成本错误可能同时损害利润空间、定价、可靠性、信任和支持。

成本预测让你的应用有机会在工作开始之前警告、路由、限制、排队、降级或请求批准。

搜索差距：开发者需要预运行模式，而不是更多仪表板

大多数 AI 成本内容都聚焦于仪表板、提供商定价或通用优化技巧。这些有助于在费用已经存在之后，但它们错过了在 agent 产品中最关键的决策点：

在用户开始一个昂贵的 workflow 之前，应该发生什么？

常见的开发者问题都很实际：在调用前估算 token、为可变工具使用定价、阻止重试浪费、处理试用、清晰展示积分、以及在不泄露数据的情况下跨租户预测。

这是服务不足的角度。产品需要一个预测层，而不仅仅是一张监控图表。

一个简单的心理模型：报价、预留、运行、对账

把每个 agent 运行当作一个有成本合同的工作。

1. Quote       -> estimate likely, low, and high cost
2. Reserve     -> hold budget or credits before execution
3. Run         -> enforce limits while work happens
4. Reconcile   -> compare forecast vs actual and learn

这个模式适用于按积分、座位、任务、使用量或内部计划限制收费的任何场景。

在运行开始之前，估算：

• validation 或 repair 调用的数量
• fallback model 的概率
• 预期的延迟范围

报价不应该假装是精确的。使用范围。

{
  "workflow": "research_report",
  "estimated_cost_usd": 0.42,
  "low_cost_usd": 0.18,
  "high_cost_usd": 1.10,
  "confidence": "medium",
  "reason": "Large source set and possible citation repair step",
  "max_allowed_cost_usd": 1.25
}

一个范围比一个假的精确数字更诚实。

没有执行的预测只是装饰。在工作开始前预留预算：减去估算的积分、持有租户级预算、阻止超出策略的运行、对昂贵的工作请求批准，或在预算紧张时降级到更便宜的路径。

预留阻止了典型的失败模式：用户有 20 个积分，agent 花了 80 个，你的应用要么承担成本，要么创造糟糕的用户体验。

在执行期间，将实际花费与预测进行比较。

有用的运行时检查：

• 如果实际成本超过硬上限则停止
• 如果花费超过预算的 50%、75% 和 90% 则警告
• 如果工作是低风险的则切换模型
• 当上下文增长过大时减少检索窗口
• 在固定预算后停止重试循环
• 在继续昂贵分支之前请求批准

workflow 应该知道它什么时候变得比承诺的更贵。

在工作完成后，比较预测和实际。

forecast_variance = (actual_cost - estimated_cost) / estimated_cost

如果一个 workflow 反复花费是估值的 2 倍，你就有了一个模型问题、prompt 问题、检索问题或产品问题。对账将成本惊喜转化为工程反馈。

从 Workflow 步骤构建预测

不要预测一个大整体。预测每个阶段。

这是一个实用的结构：

这个阶段级预测比单一总数更容易调试。

示例预测对象：

type CostForecast = {
  workflow: string;
  tenantId: string;
  currency: 'USD' | 'credits';
  estimate: number;
  low: number;
  high: number;
  confidence: 'low' | 'medium' | 'high';
  hardCap: number;
  stages: Array<{
    name: string;
    estimate: number;
    high: number;
    assumptions: string[];
  }>;
  policy: {
    requireApproval: boolean;
    downgradeAllowed: boolean;
    stopOnCap: boolean;
  };
};

从粗略的 Token 估算开始

你可以在调用模型之前估算输入 token。它不会很完美，但足够用于路由。

对于许多英语为主的应用，一个快速近似是：

function roughTokens(text: string) {
  return Math.ceil(text.length / 4);
}

对于生产环境，尽可能使用目标模型的 tokenizer。但即使是一个粗略的估算也能 catch 明显的问题，比如用户将一个 90,000 字符的转录文本粘贴到一个本应为短票据设计的 workflow 中。

一个基本的模型调用估算：

type ModelPricing = {
  inputPerMillion: number;
  outputPerMillion: number;
};

function estimateModelCost(params: {
  inputTokens: number;
  expectedOutputTokens: number;
  pricing: ModelPricing;
}) {
  const inputCost = params.inputTokens * params.pricing.inputPerMillion / 1_000_000;
  const outputCost = params.expectedOutputTokens * params.pricing.outputPerMillion / 1_000_000;
  return inputCost + outputCost;
}

然后乘以 workflow 假设：

const plannedCalls = 3;
const retryMultiplier = 1.4;
const validationMultiplier = 1.2;

const forecast = baseModelCost * plannedCalls * retryMultiplier * validationMultiplier;

这不优雅。但它有用。早期预测是为了 catch 糟糕的数量级错误。

使用复杂度带而不是猜测每个分支

试图预测每个可能的 agent 路径会让你发疯。使用复杂度带。

分类器可以在执行前分配这个带。

function classifyRun(input: {
  inputTokens: number;
  attachments: number;
  toolsAllowed: number;
  needsRetrieval: boolean;
  expectedOutput: 'short' | 'medium' | 'long';
}) {
  if (input.inputTokens > 20000 || input.toolsAllowed > 6) return 'risky';
  if (input.attachments > 3 || input.expectedOutput === 'long') return 'large';
  if (input.needsRetrieval || input.toolsAllowed > 1) return 'medium';
  return 'small';
}

这给你的产品一个清晰的策略表面：

• Small runs execute immediately.
• Medium runs execute with a normal cap.
• Large runs show an estimate.
• Risky runs require approval or a trimmed scope.

将工具成本与 Token 成本分开预测

Agent 工具通常被视为免费的，因为它们不会出现在模型发票中。这是一个错误。

工具调用可能通过以下方式花钱：

• 向量搜索查询
• 网页抓取带宽
• 糟糕操作的支持风险

创建一个工具价格表，即使第一批价格是内部估算。

{
  "web_search": { "unit": "call", "estimated_cost": 0.015 },
  "browser_extract": { "unit": "page", "estimated_cost": 0.03 },
  "vector_search": { "unit": "query", "estimated_cost": 0.002 },
  "pdf_parse": { "unit": "page", "estimated_cost": 0.001 },
  "human_review": { "unit": "minute", "estimated_cost": 0.75 }
}

这帮助你避免模型 token 看起来便宜但 workflow 很贵的陷阱。

在 Agent 运行时中使用预算合同

预测应该成为一个运行时合同。

type BudgetContract = {
  runId: string;
  tenantId: string;
  estimatedCost: number;
  hardCap: number;
  spent: number;
  maxModelCalls: number;
  maxToolCalls: number;
  maxRetries: number;
};

function canSpend(contract: BudgetContract, nextCost: number) {
  return contract.spent + nextCost <= contract.hardCap;
}

在每个模型或工具调用之前：

if (!canSpend(contract, estimatedNextCost)) {
  return {
    status: 'stopped',
    reason: 'budget_cap_reached',
    message: 'This workflow needs more budget to continue safely.'
  };
}

这使上限成为真实的。Agent 不仅仅是在 prompt 中被要求保持便宜。运行时强制执行它。

仔细设计面向用户的成本 UX

不要用 token 数学来 overload 用户。大多数用户不关心输入 token 与输出 token 定价。他们关心工作是小的、正常的还是贵的。

好的成本 UX 可以展示：

Estimated effort: Medium
Expected credits: 8-15
Why: This task uses document search and a validation pass.
Limit: The run will stop before 20 credits unless you approve more.

避免吓人或模糊的消息，比如：

This may use tokens depending on your model provider and context window.

这在技术上是真实的，实际上毫无用处。

对于面向开发者的产品，添加一个详细视图：

• estimated model calls
• tool call budget
• retry risk
• fallback probability

最好的 UX 是透明的，而不需要让用户成为你的 FinOps 团队。

定价计划需要预测类别

将 workflow 映射到预测类别，这样不是每个 AI 动作都被视为相同的。

这使得限制更容易解释和更安全地执行。

关注这些预测准确性指标

当你测量它时，预测层会变得更好。跟踪预测与实际方差、P50/P90/P99 实际成本、上限命中率、批准率、降级率、重试成本份额、工具成本份额、租户利润率和置信度校准。

最有用的指标通常是每个成功结果的成本，而不是每次模型调用的成本。

cost_per_success = total_workflow_cost / successful_runs

一个失败率一半的廉价 workflow 可能比一个首次就能工作的高价 workflow 更贵。

需要避免的常见错误

错误 1：只预测 Token

Token 是账单的一部分，不是全部。包含工具、重试、解析、队列、validation 和 fallback。

错误 2：用平均成本作为上限

平均成本不是安全的上限。使用高百分位实际值。如果平均运行花费 5 个积分但 P90 花费 30 个，你的上限应该知道这一点。

错误 3：让重试在没有预算的情况下花费

重试在测试期间感觉无害。在生产中，它们可能成为一种隐藏的税收。给重试它们自己的预算。

错误 4：在运行后才显示成本

用户在工作开始前对限制更宽容，而不是在长时间等待后的惊喜失败。

错误 5：对待所有租户相同

按租户、计划、workflow 和输入大小进行预测。

一个最小化实施计划

如果你从零开始，不要构建一个巨大的 FinOps 平台。添加一个薄层：

1. 为模型和工具创建一个定价配置。
2. 在第一次模型调用之前估算输入大小。
3. 为每次运行分配一个复杂度带。
4. 生成一个带有 low、estimate、high、confidence 和 hard cap 的报价。
5. 在执行前预留积分或租户预算。
6. 在每次模型和工具调用之前检查预算。
7. 按阶段记录实际成本。
8. 完成后对预测与实际进行对账。
9. 每周审查高方差 workflow。
10. 从实际运行中更新乘数。

这足以防止最严重的惊喜。

这在你的 AI 架构中处于什么位置

AI agent 成本预测连接你的 LLM gateway、工具 gateway、workflow 引擎、计费系统、可观测性堆栈、策略引擎和产品 UI。

把它想象成昂贵 AI 工作的起飞前检查，也是更广泛的生产成本控制集群的自然组成部分。

AI agent 成本预测不是关于完美预测。是关于给你的产品足够的预知来做出更安全的选择。

在用户点击 Run 之前，你的应用应该知道可能的成本范围、最坏情况上限、风险分支，以及当 workflow 开始偏离时该怎么做。

如果你能报价、预留、运行和对账，你就可以把 AI 成本从一个惊喜账单变成一个产品控制系统。

常见问题

什么是 AI agent 成本预测？

AI agent 成本预测是在 workflow 运行前估算其可能成本的做法。它包括模型 token、工具调用、重试、validation、fallback 和 workflow 复杂度。

成本预测与成本跟踪有何不同？

成本跟踪告诉你 workflow 运行后发生了什么。成本预测在执行前估算可能发生什么，这样产品可以设置上限、显示警告、预留积分或选择更便宜的路径。

token 估算在模型调用前能足够准确吗？

可以，对于有用的范围来说是可以的。它们不会是精确的，但粗略的 token 计数加上 workflow 乘数可以在执行开始前 catch 昂贵的输入和高风险的工作。

用户应该看到每次 AI 运行的准确美元成本吗？

并不总是。许多用户更喜欢小、中、重的简单范围。面向开发者的产品也可以暴露模型调用、工具、重试和硬上限的详细估算。

要跟踪的最佳第一个指标是什么？

从按 workflow 的预测与实际方差开始。它很快显示哪些 workflow 是可预测的，哪些需要更好的乘数，哪些可能需要产品或工程更改。

重试如何影响 AI workflow 成本？

重试可以成倍增加成本，因为每次重试可能触发另一次模型调用、工具调用、validation 步骤或 fallback。给重试它们自己的预算，并在预期值低时停止它们。

定价计划应该如何处理昂贵的 agent workflow？

将 workflow 分组为预测类别，如 tiny、normal、heavy 和 extreme。然后将每个类别映射到计划限制、积分、批准或附加组件，而不是将每个 AI 动作视为相同的。