Token 即成本：核心概念

成本结构与传统 SaaS 的差异

传统 SaaS 的成本由固定基础设施（服务器、带宽、存储）与接近零的边际用户成本构成，可按”用户数 × 月费”建立线性预算模型。

LLM 驱动的 agent 产品打破了这种线性关系。计费单位从”用户数”切换为”推理工作量”——每次 tool 调用、每段 history 重发、每次重试、每次 context 压缩均直接产生 API 费用。直接后果：

• 100 个用户中，约 5 个重度使用者通常贡献 80% 的账单（power-law 分布，非线性叠加）
• 同一任务，agent 走错路径一次的成本可能超过其做对十次的成本总和
• 同一产品运行 1 个月与 3 个月的成本曲线存在显著差异——cache 命中率、history 长度、模型版本均随时间漂移

非工程角色（产品、销售、采购、客服、内部使用方）若沿用传统 SaaS 预算模板，估算结果会系统性偏低。因此 token 成本概念需要在所有相关方之间形成共识，不应局限于工程团队内部。

Token 的三重资源属性

每个 token 同时占用三类资源：

资源类型	量化关系	业务影响
金额	API 单价 × token 数量	月度账单
延迟	token 数量大致正比于处理时间	用户响应等待时长
容量	token 数量 = context 占用	任务执行深度与记忆持续时长

任何 token 优化均需先明确目标维度。三个维度通常呈相互替换关系而非同步增减：

• 压缩 history 释放容量并降低未来成本，压缩本身是一次 LLM 调用，当期金额上升
• 切换至更强模型，单步费用上升、总步骤数下降，金额可能升高、延迟下降
• 切换至更便宜模型并增加兜底步骤，金额下降、延迟与失败率上升

不存在”全维度优化”，仅存在”明确选定目标维度并接受对应代价”。

三条基本规律

1. Input 便宜、cached input 更便宜、output 昂贵、history 成本最高——history 既是历史 output，又作为 input 参与后续每一轮调用
2. 未发生的 token 比节省的 token 价值更高——将 prompt 设计为静态以触发 cache 命中，收益通常大于手动缩减 prompt 内容
3. 失败成本 ≥ 成功成本——agent 走错路径并重试时，前序步骤的 token 已计费且不可退还

参考账单：12 步任务

具体数字便于建立直觉，详细分项见下一节。

任务场景：用户请求 agent 整理 Gmail 收件箱，将最近 20 封邮件按所属项目分类。Agent 在 Claude Sonnet 4.6 上以 12 步完成。账单约 $0.19，分项构成：

• 41% Conversation history——历史对话重复发送
• 23% Model output——模型回复内容
• 22% Tool results——工具返回值（计入 history）
• 13% System prompt + tool descriptions——静态部分，cache 命中后的单价
• < 1% Sandbox + 存储

中等长度任务（约 10-15 步）的成本构成大致服从 40 / 25 / 20 / 15 的比例分布。Conversation history 始终是最大成本项。

章节导读

章节	主要内容	适用读者
cost-model	$0.19 账单的逐项推导；不同模型执行同一任务的成本对比	工程、产品、财务
controls-and-roi	成本上限设置与监控机制；将人力时间折算为 ROI 测算的方法	运维、销售、采购

仅阅读一节时建议选择 cost-model——分项账单数据较抽象论证更具说服力。