很多 AI agent 团队第一次把预算治理做进系统时，默认都会从“任务结束后再结算”开始。这个思路在短请求场景里没太大问题，但只要任务开始变长、步骤开始变多、外部工具开始收费，它就会迅速暴露出两个尴尬：第一，任务已经跑了很久才发现预算不够；第二，平台根本说不清本次 run 到底该按初始估算、实际消耗，还是补偿后的净成本来扣费。
这类问题最容易在企业客户和高风险自动化场景里炸出来。比如一个跨系统的数据同步 run，先做检索，再跑浏览器，再走人工 review，最后还要调用第三方 API。你如果不在开始前做任何 spend reservation，系统就可能在第 80% 时因为额度耗尽停下；可你如果粗暴地一开始就把最大估算全扣掉，客户又会觉得平台像在先斩后奏。
所以 AI agent 里的 budget hold 不是支付系统的小技巧，而是执行控制的一部分。它决定了系统能不能在任务开始前就知道“这件事大概配不配得上现在的预算”，也决定了任务完成后能不能把预留、释放和最终结算说清楚。
建议配合 AI agent 成本控制与预算治理、AI agent Metering 与 Chargeback、AI agent Deadline 与超时预算 和 AI agent 准入控制与配额闸门 一起看。
先分清：预留不是扣费，释放也不是退款
| 动作 | 真正含义 | 最常见误解 |
|---|---|---|
| Reservation | 预留一段可用预算，保证任务有资格启动 | 以为这已经是最终扣费 |
| Incremental Hold | 执行中扩充预留上限 | 以为是系统在偷偷多收费 |
| Release | 没用掉的预留额度回收 | 以为这是退款逻辑 |
| Final Reconciliation | 根据实际消耗和平台政策形成最终账单 | 以为和初始预留一定完全相等 |
只要这四个动作在产品和账务语义上没分开，客户端看到的“额度变化”就很容易像一团雾。
真正麻烦的是长任务的不确定性，不是预算本身
短任务通常可以粗略估算一次就完事，但长任务不一样。因为它的成本并不是一次性决定，而是随着路径变化不断展开：
- 模型可能触发 fallback
- 工具调用可能因为失败重试多走两轮
- 浏览器 runner 可能从轻模式升级到重模式
- 人工 review 可能把本次 run 拉进更长处理链
也就是说，reservation 真正要处理的不是一个静态总价，而是一条仍在变化的成本路径。系统如果还只会“开始时估一个固定上限”，要么预留过大，让客户体验很差；要么预留过小，到中途又必须停下来补额度。
更稳的做法，是把预算预留做成阶段控制
对大部分 AI agent 长任务来说，更靠谱的方式不是一次性冻结全部预算，而是按阶段做 hold：
- 启动前预留基础执行成本
- 进入高成本工具前追加一段工具预算
- 进入人工 review 或高风险副作用前再次确认剩余预算是否允许继续
这种设计的价值不只是更公平，也更接近任务真实展开方式。因为系统终于可以在关键节点问一句：接下来这一步还值得继续吗？这比任务跑到底后再告诉客户“本次比想象中贵很多”更像一个负责任的平台。
Reconciliation 必须把“系统吸收”和“客户承担”分开
final reconciliation 最容易被做错的地方，是把所有实际消耗都默认记给客户。可 AI agent 平台里，很多成本其实不该直接转嫁：
- 因平台 bug 导致的无意义重试
- 因连接器漂移导致的异常浏览器回放
- 因实验性模型切换导致的额外 fallback
如果这些成本也直接写进最终账单，系统短期看确实省事，长期看却会把平台质量问题伪装成客户用量问题。更合理的方式是让 reconciliation 至少区分三类事实：实际消耗、平台吸收、客户承担。只有这样，账务、工程和客户成功团队才不会永远在同一笔费用上各说各话。
一个典型事故：预算在末尾才检查，导致系统只会“白跑”
某团队的合规审查 agent 要读取文档、抽取证据、跑对比模型，再生成外发报告。他们一开始只在任务结束时检查租户预算是否超限。结果某次月末高峰期，大量企业租户集中触发长任务，平台在最后一步才发现部分账户剩余额度不够。于是出现了很糟糕的局面：
- 前 90% 的计算和工具调用都已经发生
- 任务最后不能交付结果
- 平台又不敢全额向客户收费
- 工程团队只能把大量成本记到“系统吸收”里
修复并不是“预算不足就直接拒绝全部任务”，而是把 spend reservation 前移到执行开始前，并在进入高成本阶段前再次校验。这个改动听起来像财务问题，实际上直接改变了系统对资源的尊重程度。
真正该先补的，是预算状态对执行层可见
如果你现在只能先做一层，优先别去设计更复杂的账单页面，而是让执行层真正看到预算状态：当前已预留多少、已消耗多少、剩余允许继续到哪一步、如果继续会不会越过套餐或租户边界。只要预算还只活在账务系统里，调度器就很难在正确的时间点做正确的停与放。
AI agent 的预算治理，最怕的不是“算得不够精”，而是预算判断永远发生在太晚的地方。任务开始前不看资格，执行中不看阶段，结束后才发现不该跑，这种系统最后只会越来越会白跑。
延伸阅读：
