开发者提 RFC：以原子化预算机制遏制 AI 代理算力失控

随着 AI 代理在生产环境中大规模部署，代理调用 LLM 产生的成本失控正成为新的工程难题。开发者 Ajay Rajput 在 Hacker News 发布 RFC 草案 v3，提出在 LLM 网关层引入「实时预算决策平面」，以原子化的方式为每一次代理运行设置预算上限，让代理能够及时降级或终止，避免出现单周末烧掉数千美元的账单事故。

失控的代理成本：从几千到几万美金的真实账单

AI 代理的调用模式与普通聊天完全不同：观察、思考、行动、循环，每一轮都会把累积的上下文重新发送给模型。当一次运行走到第 20 步、且执行了若干文件读取时，单次调用的输入 token 很容易超过 5 万。RFC 引用了过去一年的若干公开案例：

• 某开发者在一次自主重构的周末中产生约 4,200 美元的 API 费用；
• 一个 35 人团队收到月度约 8.7 万美元的账单；
• 对 30 个团队的审计显示，使用同款工具的开发者间人均成本 p10 与 p90 相差 20 倍。

这些数字虽来自行业二手报道，并非官方事故报告，但 RFC 指出其描述的机制——即无上限的循环把不断增长的上下文反复发送——是结构性的、可复现的。

现有网关的三大缺陷

作者认为，当前的网关预算机制存在三个系统性问题：

• 预算挂错单位：现有网关把预算挂在 API Key、用户或团队上，统计周期以天或月计；而代理真正需要约束的是「一次运行」的美元上限，月度配额可能在几小时内被耗尽，目前主流网关均不强制按运行设上限。
• 执行脆弱且隐式：以 LiteLLM 为例，近期出现的多起预算相关回归（如 #26672、#27381、#27480）暴露了同一种设计缺陷——预算授权散落在回调函数里、缺乏显式的授权节点，因此难以测试、容易静默失效；部分网关还会把价格未知的模型默认视为免费，导致绕过所有预算检查。
• 失败对代理不可见：当预算检查失败时，代理只收到一个不透明的错误，毫不知情自己正在逼近预算上限，也就无法像人一样提前切换更便宜的模型、压缩上下文或干脆收尾。

核心思路：把预算决策变成显式可测试的原语

RFC 主张建立一条「实时预算决策平面」，嵌入网关钩子、Sidecar 或 SDK 中间件，对成功响应不做任何篡改。它的四条核心目标包括：

• 在调用厂商 API 前按运行强制美元上限，并在并发场景下提供明确正确性保证；
• 通过响应头与 RFC 9457 problem-detail 错误，向代理反馈机器可读的预算状态，使其能在中途调整；
• 把每次运行的花费汇总到用户、功能与团队维度，不依赖厂商计费标签；
• 实行「未知价格即拒路由」的硬策略，除非租户显式覆盖。

RFC 明确声明这不是模型网关、不替代厂商抽象，也不是事后成本看板（仪表盘），而是位于它们之上、负责「能不能放行」这一决策的一层。

工作机制：reserve → commit → refund

核心原语被定义为「Budget Decision」，可取值 allow、downgrade、advisory_warn、block，每条决策都有 ID 并连同输入（作用域、估算、有效的输出上限、价表版本）一起落库。

运行流程可以概括为三步：

• 请求进入：解析 run、user、team、key、feature 等作用域，计算有效输出上限，按价表估算本次调用成本。在「硬门」模式下，预留额度采用最坏情况：实际输入 token + 有效输出上限对应 token 全部按输出价计算。
• 原子预留：对所有相关作用域一次性原子预留估算额度；若失败，则按策略走降级或直接阻断，并以 problem-detail 形式返回建议替代路径。
• 结算：厂商返回成功，则按实际开销提交（commit）并释放（release）多余预留；失败则全额 refund。

为防止运行 ID 伪造，RFC 规定 X-Run-Id 必须来自已认证调用方，并在服务端绑定到对应 key、用户和团队；缺失时由服务端签发并通过响应头回传。每条账本写入绑定完整五元组 run_id + user_id + key_id + team_id + feature_id，并对每主体的活跃运行数和 TTL 设置硬性约束。

状态与展望

RFC 目前标注为草案 v3，面向在生产环境部署 LLM 网关的平台工程师征询反馈。它并未声称提供完整实现，而是为后续网关、Sidecar 与 SDK 实现确立统一的决策契约。如果社区采纳，这套机制有望成为代理基础设施中「成本授权」一环的事实标准，与厂商侧的限流、路由策略形成补充。