成本模型 · aibuddy Docs

Agent 成本模型应该先写公式，再填价格。模型单价、缓存倍率、区域倍率、batch 折扣和运行时费用都会变化；公式稳定，价格快照只是代入项。

基本公式

一次任务的直接成本可以写成：

task_cost =
  input_tokens × input_price
+ cache_write_tokens × cache_write_price
+ cache_read_tokens × cache_read_price
+ output_tokens × output_price
+ tool_runtime_cost
+ external_api_cost
+ retry_cost

如果任务涉及人工审核或失败兜底，还要单独计入：

total_cost =
  task_cost
+ human_review_minutes × loaded_hourly_cost / 60
+ failure_rate × fallback_cost

这里的重点是不要把 API 账单等同于总成本。API 账单通常只是可见度最高的一层。

示例任务

下面保留一个合成示例，用于说明账单结构。

任务：用户要求 Agent 整理最近 20 封邮件，并按项目分类。Agent 在 12 步内完成：先读取邮件元数据，再通过工具应用标签。

这个例子选择 12 步，是因为它处在中等任务区间：极短任务会被启动开销主导，长程任务会被 history 和失败恢复主导。中等任务更适合观察各项成本如何叠加。

示例账单

下面的数字是合成样例，不是报价。价格按某个公开模型价格快照代入，绝对值未来会变；比例用于说明“哪些项会变大”。

来源	Token / 用量	计费方式	示例成本	占比
System prompt（cache 命中）	2.5K 写入 + 27.5K 读取	cache write / read	$0.018	9%
Tool descriptions（cache 命中）	1.2K 写入 + 13.2K 读取	cache write / read	$0.008	4%
Conversation history（未 cache）	26.4K	input	$0.079	41%
Tool results（未 cache）	14.4K	input	$0.043	22%
Model output	3.0K	output	$0.045	23%
Sandbox + storage	1 session、少量存储	运行时分摊	~$0.001	<1%
合计	—	—	$0.194	100%

这里的 cache 指 prompt caching：相同静态前缀首次写入后，后续请求按较低价格读取。不同供应商、模型、缓存 TTL 和区域设置的价格不同，实际测算应以当前官方价格页为准。

观察 1：History 会放大

在多步 Agent 中，每一步通常都需要看见部分历史：用户目标、已执行动作、工具结果、错误信息和当前状态。如果完整重放 history，第 N 步会携带前 N-1 步的内容。

这会让累计输入快速增长：

history_tokens ≈ per_step_history × (1 + 2 + ... + n)

真实系统不一定严格是 O(n²)，因为可以裁剪、压缩、外化状态或只读取必要事件。但趋势仍然成立：任务越长，history 管理越重要。

因此，compaction、memory-system、进度文件、结构化状态和可恢复 Session 都不是“体验优化”，而是经济模型的一部分。

观察 2：缓存靠稳定前缀

Prompt cache 的收益来自“相同内容被重复读取”。System prompt、工具描述、策略说明、固定输出格式应该尽量稳定。

常见破坏方式包括：

在 system prompt 中塞入每次变化的用户数据。
每轮动态重排工具描述。
把时间戳、随机 ID、临时状态放在静态前缀中。
为了微调几个词频繁改动长 prompt。

相比把 prompt 从 12K 手动缩到 11K，让 12K 中的大部分稳定命中 cache 往往更有价值。

观察 3：Output 贵，但不能只压短

多数模型的 output 单价高于 input。直觉上，这会鼓励减少长篇解释、少写无效计划、多用工具完成动作。

但“压短 output”不能变成盲目禁言。必要的计划、检查点和错误解释能减少后续重试。更好的目标是：

减少对用户不可见、不可验证、不可复用的长篇推理。
让工具返回结构化结果，而不是让模型复述大量原始内容。
在关键节点输出简洁状态，帮助用户和后续 Agent 接手。

模型选择是乘法项

在同样 token 用量下，模型选择会按单价比例放大或缩小整张账单。下面是一个按公开价格快照计算的示意，不应作为长期价格表：

模型档位	适合任务	相对成本直觉
低成本模型	分类、抽取、格式转换、低风险常规动作	单步便宜，但可能需要更多兜底
中间模型	多数产品默认 Agent 任务	成本和可靠性较均衡
高能力模型	长程规划、复杂代码、主观质量判断、高风险决策辅助	单步更贵，但可能减少绕路

模型路由的目标不是永远用最便宜模型，也不是默认用最强模型，而是让任务风险、失败成本和模型能力匹配。

实际测算字段

上线后应记录这些字段，而不是只看总账单：

字段	为什么重要
`input_tokens` / `output_tokens`	判断成本来自输入膨胀还是输出过长
`cache_write_tokens` / `cache_read_tokens`	判断静态前缀是否真的命中
`tool_result_tokens`	判断工具返回是否过大
`steps` / `retries`	判断是否存在绕路或循环
`model` / `route_reason`	判断模型路由是否合理
`runtime_seconds`	判断沙箱、浏览器、外部服务是否成为成本项
`human_review_minutes`	判断自动化是否只是把成本转移给人工
`failure_reason`	判断成本失控来自模型、工具、权限、数据还是产品设计

这些字段会进入成本控制与 ROI 的预算、监控和收益测算。