如何估算 AI 智能体的成本

AI 智能体不是只发一次请求——它会发几十次，而且每一步都会重新发送不断增长的对话。这就是为什么智能体的账单主要由输入 token 主导，也是为什么聊天应用里那种“每个回答的价格”直觉在这里行不通。下面介绍如何在智能体运行前估算成本，以及钱到底花在了哪里。

公式#

一次请求的成本是输入 token 数乘以输入价格，加上输出 token 数乘以输出价格。价格按每百万 token 报价：

request_cost = input_tokens / 1,000,000 × input_price
             + output_tokens / 1,000,000 × output_price

一个任务的成本是智能体在解决该任务期间发出的所有请求的成本之和。

为什么智能体以输入为主#

每一步智能体都会向模型发送：

• 系统提示词和工具定义；
• 到目前为止的全部历史——更早的消息、模型之前的回答和工具结果（文件内容、命令输出、搜索结果）；
• 新的指令。

模型通常只回复一条简短消息或一次工具调用。然后工具结果被追加到历史中，下一步又会把全部内容重新发送一遍。因此每一步的输入都在增长，而输出保持很小。

一个具体示例#

条件（假设值——请替换为你自己智能体的数字）：

• 系统提示词和工具定义：6,000 token；
• 每一步向历史中增加 1,500 token 的工具结果和 500 token 的模型输出；
• 任务需要 30 步；
• 模型：DeepSeek-V4-Flash，每 1M 输入 token $0.0221，每 1M 输出 token $0.10（当前价格）。

第 n 步的输入是 6,000 + (n − 1) × 2,000 token。30 步下来：

• 总输入：30 × 6,000 + 2,000 × (0 + 1 + … + 29) = 180,000 + 870,000 = 1,050,000 token；
• 总输出：30 × 500 = 15,000 token；
• 成本：1.05 × $0.0221 + 0.015 × $0.10 ≈ 每个任务 $0.0247。

输入占 token 总量的 98.6%，也几乎占了全部成本。输入占多大比例取决于具体场景：长回答、生成的文件和推理模型会提高输出占比，而精简历史记录和缩短工具输出会降低输入占比。

同一任务在当前价格下跑遍所有模型，并附上 OpenRouter 的参考价格作对比：

用代码估算#

把同样的计算写成一个函数——修改假设和价格即可：

def estimate(steps, base_tokens, tool_tokens, out_tokens, price_in, price_out):
    """Token totals and cost of one agent task. Prices: $ per 1M tokens."""
    grow = tool_tokens + out_tokens            # what each step adds to the history
    total_in = steps * base_tokens + grow * steps * (steps - 1) // 2
    total_out = steps * out_tokens
    cost = (total_in * price_in + total_out * price_out) / 1_000_000
    return total_in, total_out, round(cost, 5)

# example rates, $ per 1M tokens — put in the current ones from the pricing table below
print(estimate(30, 6_000, 1_500, 500, price_in=0.10, price_out=0.40))
# (1050000, 15000, 0.111)

注意其中的二次项：步数翻倍，输入大约会变成四倍。长会话之所以昂贵，不是因为某一步特别贵，而是因为每一步都要携带全部历史。

实测，而不是猜测#

每个响应都包含 usage.prompt_tokens（输入）和 usage.completion_tokens（输出）。在真实任务的每一步记录它们，乘以当前费率，就能得到实际成本。仪表盘还会按模型和按天显示用量。

当前费率——与定价页面上的数据相同：

降低成本的七种方法#

1. 为不相关的工作开启新任务。 新会话不会携带上一个会话的历史。
2. 给智能体片段，而不是整个文件。 给一个函数及其调用方，而不是一个 3,000 行的模块。
3. 精简工具输出。 长日志和命令输出会在会话剩余时间里一直留在历史中——限制它们，例如用 | tail -n 50。
4. 总结长会话。 许多智能体可以压缩历史；在上下文变长之前使用它。
5. 在不需要长回答的地方，用 max_tokens 限制回答长度。
6. 为每一步选用合适的模型。 常规步骤不需要推理模型。
7. 保持预付费预算。 余额是预付费的：用完后，请求会以 HTTP 402 停止，而不是累积出一笔无上限的账单。

要查看同样的工作负载在不同模型之间以及与 OpenRouter 的对比，请使用首页上的成本比较。