第23章：Token 预算控制：Agent 的“CFO”与“止损阀”
在 Agent 的世界里，智商（Intelligence）是昂贵的。如果不加控制，一个陷入死循环的 Agent 能在一夜之间烧掉你一年的预算。预算控制不是为了省钱，而是为了生存。
你部署了一个 Research Agent，用户下达指令：“深度分析全球 AI 市场”。 第二天早上，你收到了 OpenAI 的账单扣款短信： $150.00。 你惊呆了。这只是一个任务啊！
查日志发现： Agent 为了追求完美，并行启动了 12 个子 Agent，每个子 Agent 都在疯狂搜索、阅读长达 100 页的 PDF，并且都在用最昂贵的 GPT-4-32k 模型进行总结，还陷入了“搜索-不满意-重试”的死循环。
这就是没有 CFO（财务总监）的下场。 Agent 很勤奋，但它不知道什么叫“成本效益”。在它的逻辑里，只要能完成任务，花多少钱都行。
本章我们来构建 Agent 系统的 财务部。
01. 预算的三道防线：从微观到宏观
在企业财务管理中，预算是分级的。Agent 系统也一样，我们需要建立 三级预算防御体系：
第一道防线：Task 级（单次任务熔断）
- 控制对象：用户的单次 Prompt。
- 逻辑：不管这个任务多重要，单次消耗不能超过 $1.00（约 30k Tokens）。
- 作用：防止“毒 Prompt”或“死循环”导致的单点爆破。
第二道防线：Session 级（会话累计熔断）
- 控制对象：用户的一次完整对话（多轮）。
- 逻辑：如果你跟我聊了 50 轮还在聊，说明要么你在调戏 AI，要么 AI 解决不了你的问题。累计消耗超过 $5.00，强制结束会话。
- 作用：防止用户滥用或恶意刷量。
第三道防线：Tenant 级（租户/公司熔断）
- 控制对象：某个企业客户的总额度。
- 逻辑：这家公司这这个月买的 $1000 套餐用完了，API 自动停机或降级。
- 作用：商业化收费的基础。
02. 背压控制（Backpressure）：高速公路的红绿灯
当预算快用完时，直接报错（HTTP 402 Payment Required）虽然简单，但体验极差。 更优雅的做法是 背压（Backpressure） 。
想象一下早高峰的高速公路，匝道口的红绿灯不是为了把车拦在外面，而是为了控制进入的速度。
背压策略表：
| 预算使用率 | 策略 | 延迟（Latency） | 体验 |
|---|---|---|---|
| < 80% | 绿灯 | 0ms | 秒回，体验丝滑。 |
| 80% - 90% | 黄灯 | +500ms | 稍微有点慢，用户感知不明显。 |
| 90% - 95% | 红灯 | +2000ms | 明显变慢，暗示用户“省着点用”。 |
| > 100% | 路障 | 拒绝请求 | 弹出充值提示。 |
代码实现关键点： 延迟（Sleep）必须在 Workflow 层 做，绝对不能在 Activity 层 做！
- 在 Activity Sleep：占用了 Worker 线程，导致线程池耗尽，整个系统卡死。
- 在 Workflow Sleep：只是挂起了协程，不占用资源，这是 Temporal 的正确用法。
03. 熔断器（Circuit Breaker）：系统的“保险丝”
背压是“减速”，熔断是“断电”。 当系统检测到异常流量（比如某个 User ID 在 1 分钟内发起了 1000 次请求，且全是失败的），必须立刻拉闸。
熔断器状态机：
- Closed（闭合） ：正常状态，请求通过。
- Open（断开） ：检测到故障/攻击，直接拦截所有请求，返回 Error。
- Half-Open（半开） ：过了一段时间（比如 5 分钟），放 1 个请求过去试试。如果成功，恢复 Closed；如果失败，继续 Open。
这保护了后端 LLM 服务不被 DDOS 攻击打挂，也保护了你的钱包不被恶意脚本刷穿。
04. 会计学的智慧：如何精准算账？
1. 幂等性（Idempotency）：防止重复扣款
Temporal 的机制是“失败重试”。 如果 Activity 执行成功了（钱花了），但在返回结果时网络断了。Temporal 会重试这个 Activity。 如果不做幂等处理，你会发现：模型调用了 1 次，账单上却扣了 2 次钱。
解决方案：唯一流水号 Idempotency_Key = WorkflowID + ActivityID + Attempt_Count 在计费时，先查这个 Key 是否存在。如果存在，说明是重试请求，直接返回上次的扣款结果，不再重复扣费。
2. 输入输出差异化定价
这是新手最容易忽略的细节。 GPT-4 的 Output Token 价格是 Input Token 的 2-3 倍。 如果你简单地按 Total Tokens * 单价 计费，要么亏本，要么对用户不公。
正确做法：
Cost = (Input_Tokens * Price_In) + (Output_Tokens * Price_Out)
必须精确到这种程度，你的财务报表才能对得上。
05. 架构师的避坑指南
坑 1：在 Activity 里做限流
后果：Worker 线程全部被 time.sleep() 阻塞，系统吞吐量降为 0。 解法：使用 workflow.Sleep()，利用 Temporal 的定时器机制。
坑 2：只看总价，不看比例
后果：你给所有用户设了 100，普通用户是 $1。
坑 3：并发更新预算
后果：两个并发请求同时读取余额 $10，都判断“够用”，然后同时扣款。结果余额变成负数。 解法：使用 Redis 的 DECR 原子操作，或者数据库的行锁（Row Lock）。
总结
Token 预算控制，是 Agent 系统从“玩具”走向“商业产品”的必经之路。
- 三级预算：构筑了立体的防御纵深。
- 背压控制：提供了优雅的降级体验。
- 熔断机制：守住了系统的安全底线。
- 精准会计：确保了商业模式的可持续性。
有了这一章，你的 Agent 不仅会干活，还学会了 “过日子” 。
下一章预告
钱的问题解决了，接下来是 权 的问题。 Agent 能不能删库？能不能查看 CEO 的工资条？能不能代表公司签署合同？ 这不仅仅是预算问题，更是 权限治理（Governance） 问题。
下一章，我们来聊 OPA（Open Policy Agent）策略引擎：如何用代码定义法律，实现细粒度的权限控制（RBAC/ABAC），给 Agent 戴上“紧箍咒”。
