成本模型
Token 成本、工具成本、重试成本与单任务成本估算。
一句话理解：Agent 的单任务成本 = 所有模型调用的 Token 费用 + 工具费用 + 失败与重试的摊销 + 人工兜底成本；其中 Token 费用会随步数“滚雪球”，只看“一次对话多少钱”一定会算错。
做 Chatbot 时，成本很好估：一问一答，输入几百 Token，输出几百 Token。做 Agent 时，很多团队沿用这个直觉，上线后才发现账单是预估的几倍甚至十几倍。Anthropic 在介绍其多 Agent 研究系统的工程文章中提到，在他们的数据里，Agent 消耗的 Token 大约是普通聊天的 4 倍，多 Agent 系统大约是 15 倍。
成本算不清，商业模式就无从谈起：你没法定价，也没法判断“这个任务值不值得让 Agent 做”。这一课给出一套可以直接套用的成本模型和计算方法。
为什么 Agent 的 Token 会滚雪球
模型本身不记事。Agent 每走一步，Harness 都要把 系统指令 + 工具定义 + 用户输入 + 之前所有步骤的输出和工具结果 重新发给模型。于是：
第 1 步输入：系统指令 + 工具定义 + 用户输入
第 2 步输入：第 1 步的全部 + 第 1 步输出 + 第 1 个工具结果
第 3 步输入：第 2 步的全部 + 第 2 步输出 + 第 2 个工具结果
……
第 n 步输入：S + (n-1) × d其中 S 是固定前缀（指令、工具定义、用户输入），d 是每步新增的内容（模型输出 + 工具结果）。一次运行的总输入 Token 约为：
总输入 ≈ n × S + d × n × (n-1) / 2注意第二项是 n 的平方级。步数翻倍，输入 Token 远不止翻倍。这就是为什么“精简工具返回值”和“减少无效步骤”对成本影响巨大。
用本课后面的假设值（S = 6,500、d = 1,800）画出来（图 1），每一步的输入都比上一步多一截：
成本的四个组成部分
| 组成 | 计算方式 | 常被忽略的点 |
|---|---|---|
| 模型费用 | Σ(输入 Token × 输入单价 + 输出 Token × 输出单价) | 推理模型的思考 Token 通常按输出计费；缓存读写单价不同 |
| 工具费用 | 付费 API、搜索、地图、浏览器与沙箱运行时长 | 浏览器和沙箱按时长计费，慢任务更贵 |
| 失败与重试 | 失败的运行也要付费，按成功任务摊销 | 成功率 80% 时，每个成功任务要承担 1.25 次运行的成本 |
| 人工兜底 | 转人工比例 × 人工处理时长 × 人力单价 | 这部分常常比 Token 费用还高 |
所以真正该看的指标是 每个成功完成的任务花多少钱，而不是每次运行花多少钱。
算一笔账：订单售后诊断
下面所有单价都是 假设值，只用于演示计算方法。实际测算请使用你所选模型在官方价格页上的当前价格。
假设条件：
| 项目 | 假设值 |
|---|---|
| 输入单价 | ¥20 / 百万 Token |
| 输出单价 | ¥100 / 百万 Token |
| 缓存读取单价 | 输入单价的 10% |
| 缓存写入单价 | 输入单价的 125% |
| 固定前缀 S | 6,500 Token（指令 + 工具定义 + 用户输入） |
| 每步新增 d | 1,800 Token（模型输出约 300 + 工具结果约 1,500） |
| 步数 n | 8 次模型调用（7 次工具调用 + 1 次输出结论，结论约 800 Token） |
第一步：不使用缓存。
总输入 = 8 × 6,500 + 1,800 × 8 × 7 / 2 = 52,000 + 50,400 = 102,400 Token
总输出 = 7 × 300 + 800 = 2,900 Token
输入费用 = 102,400 × 20 / 1,000,000 ≈ ¥2.05
输出费用 = 2,900 × 100 / 1,000,000 ≈ ¥0.29
单次运行模型费用 ≈ ¥2.34第二步：开启提示缓存。 每一步的输入里，之前已经发过的前缀都可以命中缓存，只有新增部分需要写入：
写入缓存 = 6,500 + 7 × 1,800 = 19,100 Token → 19,100 × 25 / 1,000,000 ≈ ¥0.48
读取缓存 = 102,400 − 19,100 = 83,300 Token → 83,300 × 2 / 1,000,000 ≈ ¥0.17
输出费用不变 ≈ ¥0.29
单次运行模型费用 ≈ ¥0.94（下降约 60%）两种情况对比如图 2：
第三步：加上工具、失败与人工。
| 项目 | 假设 | 每任务成本 |
|---|---|---|
| 模型费用（含缓存） | 见上 | ¥0.94 |
| 工具费用 | 订单查询与知识库检索 API 共 ¥0.05 / 次运行 | ¥0.05 |
| 重试摊销 | 平均每个任务运行 1.1 次 | (0.94 + 0.05) × 0.1 ≈ ¥0.10 |
| 人工兜底 | 15% 转人工，每次 6 分钟，人力 ¥1 / 分钟 | 0.15 × 6 ≈ ¥0.90 |
| 合计 | ≈ ¥1.99 |
把四项画成一根条（图 3），各部分的分量一目了然：
结论很有启发性：开启缓存之后，人工兜底已经和模型费用差不多高。此时继续压 Token 的收益有限，提升成功率、减少转人工才是降本的主战场。如果原来专员人工处理一单要 15 分钟（约 ¥15），这个 Agent 的单任务成本约为人工的 13%，ROI 的测算方法见 商业化与 ROI。
第四步：看尾部。 如果某类复杂异常需要 16 步：
总输入 = 16 × 6,500 + 1,800 × 16 × 15 / 2 = 104,000 + 216,000 = 320,000 Token步数翻倍，输入 Token 变成约 3.1 倍。上线前的估算只是起点，上线后要用 Trace 统计真实的步数与 Token 分布，按 P50 和 P95 分别核算，并为长尾设置预算上限。
降低成本的手段
| 手段 | 原理 | 代价与注意 |
|---|---|---|
| 提示缓存 | 固定前缀按低价读取，详见 提示缓存 | 前缀必须稳定；动态内容要放在后面 |
| 精简工具返回 | 降低每步新增量 d | 需要改工具，可能要提供“简洁 / 详细”两种返回格式 |
| 减少无效步骤 | 降低 n，效果是平方级 | 合并工具、改进工具描述、把确定性步骤交给程序 |
| 模型路由 | 简单步骤用小模型，详见 模型选型与路由 | 路由错误会降低成功率，要有评测兜底 |
| 上下文压缩 | 清理旧工具结果、摘要历史，详见 长任务的上下文管理 | 可能丢失关键细节 |
| 批处理 | 不需要实时结果的任务走批处理接口，部分厂商提供明显折扣 | 结果延迟返回，只适合离线任务 |
| 预算上限 | 最大步数、单任务最大花费，详见 停止条件 | 触顶的任务要有体面的失败呈现 |
Anthropic 在工具设计的工程文章中举过一个例子：同一个工具，“详细”返回格式约 206 Token，“简洁”格式约 72 Token。每步省下的 Token，会在后续每一步里被重复省下。
常见误区
- “按平均步数估算就行。” Token 随步数平方增长，少数长任务会贡献不成比例的成本。必须看分布并设置上限。
- “换个便宜模型就能降本。” 如果便宜模型成功率下降、步数变多、转人工变多，每个成功任务的总成本反而可能上升。
- “失败的运行不花钱。” 失败运行消耗的 Token 一分不少，而且往往比成功运行更长（反复尝试后才放弃）。
- “成本只算 Token。” 工具、沙箱、人工兜底和审批等待的人力时间都是成本。
产品经理检查清单
- 是否有一张包含模型、工具、重试、人工四项的单任务成本表？所有单价是否标明来源与日期？
- 成本是按“每次运行”还是“每个成功任务”计算的？
- 是否基于真实 Trace 统计了步数与 Token 的 P50 / P95，而不只是估算？
- 是否设置了单任务的最大步数与最大花费？触顶后如何处理？
- 提示缓存是否生效？缓存命中率有没有进入监控？
- 定价方案能否覆盖 P95 任务的成本？
练习
用电子表格为你关注的一个 Agent（例如 SEO 诊断 Agent）建一个成本模型（45–60 分钟）：
- 估计 S、d、n 以及输出 Token，写出总输入与总输出的公式。
- 查阅你选用模型的官方价格页，填入当前单价，并注明查询日期。
- 分别计算无缓存、有缓存两种情况的单次运行成本。
- 加入成功率、重试率和转人工比例，算出每个成功任务的成本。
- 把 n 改成 2 倍，观察成本变化，写一句结论。
延伸阅读
- Anthropic：How we built our multi-agent research system
- Anthropic：Writing effective tools for agents
- Claude 文档：Prompt caching
- Claude 文档：Batch processing
下一步
成本之外，用户最直接感受到的是“慢”。下一课「延迟优化」讲如何用 Trace 找到时间花在哪里，并用并行、缓存、流式与路由让 Agent 快起来。