成本控制与 ROI
Agent 成本管理有两面：一面是“不要失控”，另一面是“值得花”。前者靠预算和熔断，后者靠业务基线和保守测算。
成本控制
预算要分两类
只用 token 上限或只用金额上限都不够。
| 预算 | 控制什么 | 局限 |
|---|---|---|
| Token budget | 控制任务规模、上下文长度和运行步数 | 不直接等于财务风险，模型价格变化会改变金额 |
| Spend budget | 控制真实账单和毛利风险 | 不说明任务是否过长，也容易受模型价格波动影响 |
更稳妥的做法是两者同时存在：token budget 约束 Agent 行为，spend budget 约束商业风险。
分层预算
成本上限应按粒度分层，而不是只设一个总额度：
| 层级 | 例子 | 作用 |
|---|---|---|
| 单步预算 | 单次模型调用最大 input / output | 防止一次请求吞掉过多上下文 |
| 单任务预算 | 一次 Agent 任务的 token / 金额上限 | 防止长任务无边界扩张 |
| 用户预算 | 日/月额度、并发任务数 | 防止少数重度用户拖垮毛利 |
| 组织预算 | 团队、客户、环境级限额 | 支持采购和财务对账 |
| 全局熔断 | 异常时暂停任务、工具或模型路由 | 控制系统性事故 |
预算触发后不一定立刻硬停。常见策略是：
- 软停止：当前 step 完成后保存进度，告知用户预算已到。
- 降级继续：切换到更便宜模型或更小工具结果。
- 请求确认：让用户批准继续消耗预算。
- 硬中断：检测到循环、异常峰值或危险动作时立即停止。
模型路由
模型选择是最大的乘法项之一。路由规则应显式记录“为什么用这个模型”，否则成本问题很难复盘。
可用的路由维度包括：
- 任务风险：是否会影响客户、资金、权限或生产数据。
- 验证难度：结果能否用测试、schema、规则或人工快速确认。
- 上下文需求：是否需要长上下文、跨文件理解或多轮规划。
- 失败成本：失败后是重试即可，还是需要人工重做。
- 延迟要求：用户是否愿意等待更强模型。
不要把“贵模型 = 高级用户权益”设计得过于简单。更好的方式是：高级 tier 获得更高预算和更强默认路由，但低风险任务仍可落到低成本模型。
缓存和上下文
缓存命中率低通常不是价格问题，而是 prompt 组织问题。应持续监控：
- 静态前缀是否稳定。
- 工具描述是否每轮重排。
- 历史消息是否被无差别重放。
- 工具结果是否过长。
- compaction 是否过早、过晚或丢失关键信息。
缓存、compaction、memory、progress file 和 session log 都属于成本控制面。它们决定 Agent 是否能带着足够上下文继续工作，而不是把全部历史反复塞回模型。
用户可见性
后台限流只能防止最坏情况，不能教会用户怎样更经济地使用 Agent。产品层至少应让用户知道：
- 当前任务已消耗多少预算。
- 继续运行预计还会消耗多少。
- 任务为什么需要升级模型或请求更多预算。
- 停止后哪些进度可以保留。
可见性不是为了吓退用户，而是让用户把 Agent 当成有成本的执行资源，而不是无限聊天框。
ROI 测算
先建立人工基线
最简单的收益模型是人力对照：
| 字段 | 含义 | 示例 |
|---|---|---|
| 任务频率 | 每用户每月执行次数 | 20 次 |
| 人工任务时长 | 人完成同任务所需时间 | 15 分钟 |
| 人工全成本时薪 | 工资、福利、管理和设备折算 | ¥300 / 小时 |
| Agent 单任务直接成本 | API + 工具 + 运行时 | ¥1.4 |
| 人工审核时间 | 每次 Agent 结果需人工检查多久 | 2 分钟 |
| 审核成本 | 审核时间 × 人工时薪 | ¥10 |
| 可自动化比例 | 任务中适合 Agent 处理的比例 | 70% |
不要直接用“人工成本 - Agent API 成本”得出收益。更保守的公式是：
per_task_value =
automation_rate × human_cost
- agent_direct_cost
- review_cost
- failure_rate × fallback_cost示例修正
沿用上表：
human_cost = ¥300 × 0.25 = ¥75
agent_direct_cost = ¥1.4
review_cost = ¥300 × 2 / 60 = ¥10
automation_rate = 70%
failure_rate = 5%
fallback_cost = ¥75 + ¥1.4
per_task_value =
0.70 × ¥75
- ¥1.4
- ¥10
- 0.05 × ¥76.4
= ¥52.5 - ¥1.4 - ¥10 - ¥3.82
≈ ¥37 / 任务这个结果比理想测算低很多，但更可信。采购方真正关心的不是演示里一次任务省了多少钱，而是部署后在真实流程中能稳定释放多少时间。
还要计入采用率
ROI 常被高估，是因为默认所有人都会用、所有任务都适合用。实际应加入采用率：
monthly_value =
users
× monthly_task_frequency
× adoption_rate
× per_task_value采用率受很多因素影响：入口是否顺手、结果是否可信、用户是否愿意交给 Agent、失败后是否容易恢复、组织是否允许相关数据进入模型。
不适合交给 Agent 的任务
成本收益报告必须明确排除这些任务：
- 单步、低频、低价值任务：启动成本可能超过节省。
- 不可逆动作：付款、发客户邮件、公开发布、删除数据等，至少需要 HITL。
- 验证成本高于执行成本的任务：人检查结果比自己做还慢。
- 敏感数据不能进入模型的任务：需要专用流程、脱敏或本地化方案。
- 成功标准不清楚的任务：无法评估，就无法控制失败成本。
明确“不适用范围”会让 ROI 更保守，但也更可信。
监控指标
上线后至少跟踪：
| 指标 | 说明 |
|---|---|
| Cost per successful task | 每个成功任务的真实成本，比总 token 更有业务意义 |
| Cost per user / org | 发现重度用户、异常组织和毛利风险 |
| Cache hit rate | 低命中率通常说明 prompt 或工具描述变得动态 |
| Output / input ratio | 判断模型是否在长篇解释而不是行动 |
| Retry rate | 识别工具、权限、模型路由或产品设计问题 |
| Human review minutes | 判断自动化是否把成本转移给人工 |
| Escalation rate | 判断低成本模型是否过度承担复杂任务 |
| Budget termination rate | 判断预算是否太紧或 Agent 是否经常绕路 |
总结
成本控制负责让 Agent 不失控，ROI 测算负责判断 Agent 是否值得运行。两者必须放在一起看：一个便宜但总失败的 Agent 没有价值；一个昂贵但能稳定替代高成本人工流程的 Agent 可能非常划算。
成熟的 Agent 经济模型不是“每 token 多便宜”，而是“每个成功结果需要多少总成本”。