2026-07-04 · 6 分钟阅读
如何在账单到来之前阻止 Agent 失控烧钱
如果你以预付费 Token 模式销售 AI 功能，你一定担心过某个客户——或某个 Agent 循环——在几秒内耗尽全部余额。这种担心是有道理的。
我们构建 FluxMeter 正是因为目睹了这种故障：一个 Agent 循环在不到一分钟内消耗了约 200 美元的 Token。计费系统事后才发现，因为它只是周期性检查用量，而不是在每次 LLM 调用前拦截。
为什么批量分析无法应对 Agent 循环
传统计量管道为人类节奏的 API 流量而设计。你摄入事件，每 30–60 秒汇总一次，再更新计费数据库中的余额。当用户每分钟只发几个请求时，这完全够用。
Agent 循环完全不同。一个工具调用型 Agent 每分钟可以发起数十次 LLM 请求，每次流式输出数千 Token。等汇总任务运行时，损失已经造成——预算耗尽，你无法阻止下一次调用。
事后分析回答的是「他们花了多少？」请求前拦截回答的是「下一次调用是否应该被允许？」对于预付费 Token 产品，只有第二个问题才真正重要。
请求前检查模式
FluxMeter 分两层拦截预算。首先是请求前检查：在每次 LLM 请求前调用 GET /budget/{customerId}/check?estimated_cost_usd=0.05。若 allowed 为 false，则阻止调用并向用户返回明确错误。
其次是窗口后扣减：调用完成后，将 Token 数量 POST 到 /ingest。Flink 管道（或 Lite 模式汇总 worker）聚合用量并以微美元精度原子扣减 Redis 余额。
流式响应需要增加预留步骤：流式输出前 POST /budget/{id}/reserve 预留估算额度，流结束后对账。有效余额扣除进行中的预留，防止客户在长流式响应中超额消费。
亚秒级拦截的价值
Lite 模式下预算检查目标延迟低于 10ms。这足够快，可以放在每次 LLM 请求的关键路径上，而不会明显拖慢产品。
另一种选择——承担 Agent 失控的成本——要昂贵得多。一个未受控的循环可在几分钟内烧掉数百美元。亚秒级检查是廉价的保险。
Full 模式可扩展到每秒 100 万+ 事件，适用于高流量平台，拦截语义保持一致。
Q1 预算超支为何成为新常态
公开信号很明确：FinOps Foundation 报告 2026 年 98% 团队在管理 AI 支出 — 两年前仅 31%。高管称许多客户在 Q1 就烧完全年 AI 预算。
模式可预测：Agent 使用超出工程团队、Token 组合转向昂贵模型，而财务仍按月批量对账。拦截层在热路径上止血；智能层解释利润率为何变化、下一步做什么。
快速上手
FluxMeter 开源（Apache 2.0）且可自托管。运行 make demo 即可在本地启动 Lite 模式（docker-compose）——API、Redis 和汇总 worker，无需 Flink。
通过 Stripe Meters、Lago、Orb、Metronome 或 OpenMeter 导出对接现有计费栈。FluxMeter 是拦截层，计费平台仍是账本系统。