Agent 经济学

传统 SaaS 常用“用户数 × 月费”估算收入，用服务器、带宽、存储估算成本。这个模型在 Agent 产品里会失真，因为用户并不直接消耗“席位”，而是在消耗一次次推理、工具调用、上下文重放、失败重试和人工接管。

理解 Agent 经济学的目标，不是记住某个模型今天的价格，而是能回答三个问题：

1. 一次任务为什么贵？
2. 哪些成本会随任务长度放大？
3. 怎样把成本控制和业务价值放进同一张表？

成本从哪里来

Agent 的一次任务通常包含六类成本：

成本项	说明	常见控制手段
Input tokens	system prompt、用户输入、历史消息、工具结果重新进入上下文	prompt cache、上下文裁剪、检索粒度控制
Cached tokens	静态前缀被缓存后，后续读取按较低价格计费	保持 system prompt 和工具描述稳定
Output tokens	模型生成自然语言、计划、解释或工具参数	减少无效推理输出，鼓励直接调用工具
Tool / runtime	浏览器、沙箱、数据库、外部 API、文件系统等执行成本	工具限流、批处理、沙箱生命周期管理
Retry / failure	走错路径后的重复推理、回滚、重做	eval、预算中断、用户确认点
Human review	人工审核、接管、纠错、流程培训	HITL 只放在高风险节点

其中 token 仍然是最容易被量化的一项，但它不是全部成本。一个看似便宜的 Agent，如果频繁失败、需要人工反复收尾，整体经济性仍然可能很差。

Token 的三重属性

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

资源	含义	业务影响
金额	token 数 × 当前模型单价	账单和毛利
延迟	输入处理和输出生成都需要时间	用户等待时长
容量	token 占用上下文窗口	任务能走多远、能保留多少状态

优化前要先说明目标是哪一个。很多选择不是“更优”，而是换一种代价：

• 压缩 history 可以降低后续 input，但压缩本身也要花 token，且可能丢失细节。
• 更强模型单价更高，但可能少走弯路、少重试，总成本未必线性上升。
• 更便宜模型能降低单步费用，但可能增加步骤数、失败率和人工接管。
• 更长上下文能减少交接成本，但也可能让每一步携带更多历史。

因此，Agent 成本优化不是单纯“省 token”，而是决定哪些 token 值得花，哪些任务不该让 Agent 做。

三条基本规律

静态内容要尽量可缓存。 System prompt、工具描述、固定策略说明如果每步都变化，就会破坏 prompt cache。相比手工删掉几百个 token，保持大段静态前缀可命中缓存通常更重要。

长任务的 history 会放大成本。 多步 Agent 往往要把前序消息和工具结果重新放回上下文。若不裁剪、不压缩、不外化状态，历史成本会随步骤数快速增长。

失败成本通常不低于成功成本。 失败路径已经消耗的 token、工具调用和人工时间无法退回；如果失败发生在长任务后段，补救成本可能超过一次成功执行。

一个示例账单

下面的示例只用于建立直觉，不是报价。假设用户让 Agent 整理最近 20 封邮件并按项目分类，任务运行 12 步。按某一组公开模型价格快照和合成 token 用量估算，账单约为 $0.19。

分项大致如下：

• 41% Conversation history：历史消息和工具结果在后续步骤中反复进入 input。
• 23% Model output：模型回复、计划和工具参数。
• 22% Tool results：工具返回内容进入上下文后继续产生后续成本。
• 13% System prompt + tool descriptions：静态前缀，假设 cache 命中良好。
• < 1% Sandbox + storage：本示例中较小，真实系统可能因任务类型变化。

这个比例不是定律。它说明的是：在中等长度、多步、会重放历史的 Agent 任务中，history、tool results 和 output 往往比启动时的 system prompt 更值得关注。

章节导读

章节	主要内容	适用读者
成本模型	用公式和合成样例拆解 input、cache、output、工具、失败和人工审核成本	工程、产品、财务
成本控制与 ROI	预算、模型路由、缓存、熔断、监控，以及更保守的成本收益测算	运维、销售、采购

如果只读一篇，建议从 成本模型 开始。它把“Agent 为什么贵”从抽象判断落到可计算的字段上。