AI智能体预算管控：花钱权限该内置还是外部授权？

一个被忽视的问题：谁来批准AI花钱？

随着AI智能体（Agent）逐渐从实验室走向生产环境，一个看似琐碎却极其关键的问题浮出水面：当一个智能体决定「我需要再调用一次模型」时，究竟谁有权决定它是否可以再花掉这2美元？

在Reddit的一场技术讨论中，有开发者提出了一个颇具启发性的观点——不应该把智能体的预算问题当作单纯的FinOps（财务运营）功能，而应该把它视为一个授权（Authorization）问题。这个视角的转变，可能会重塑我们设计多智能体系统的方式。

传统做法是在智能体运行时内部设置token上限或max_iterations（最大迭代次数）。这些手段对于约束单次执行确实有用，但本质上仍然是智能体在自我监管。而自我监管天然存在缺陷：一个失控或被攻击的智能体，同样可以绕过自己给自己设定的限制。

**FinOps（Financial Operations）**是云计算时代兴起的一套财务管理实践框架，旨在让工程、财务和业务团队协同管理云资源支出，强调「实时可见性、归因与优化」。在AI时代，FinOps的挑战被进一步放大：LLM调用的成本高度依赖于输入/输出token数量，而token消耗往往难以在调用前精确预测，单次长链推理（如多轮ReAct循环）的成本可能比预期高出数倍。这使得传统FinOps的「事后分析」模式显得力不从心——等到账单出来再优化，对于失控的自主智能体已经太晚。这正是本文所探讨的「授权前置」思路相对于纯FinOps视角的增量价值所在。

从「自我约束」到「外部授权」

讨论中提出的核心主张是：让运行时去「请求」资源，而由智能体之外的某个组件来「强制执行」花费策略。 这一流程大致如下：

智能体
  ↓  "我想再调用一次模型"
策略层 / 网关
  ├─ 身份验证（identity）
  ├─ 剩余预算（remaining budget）
  ├─ 速率限制（rate limit）
  └─ 模型策略（model policy）
  ↓
ALLOW / REJECT（放行 / 拒绝）

这个架构的精妙之处在于它把「花钱的意图」和「花钱的授权」彻底解耦。智能体只负责表达需求，真正的裁决权交给了一个独立的网关层。这类似于现代系统安全中「最小权限原则」的思路——组件不应该拥有对自身行为不受约束的信任。

为什么这个边界如此重要？

当系统中只有一个智能体时，内部限制或许够用。但一旦多个智能体、多个版本、多个团队共享同一批模型供应商时，问题就变得棘手了。

你显然不希望每一个智能体的实现都各自发明一套「我最多能花X美元」的逻辑。这不仅会造成策略碎片化，还会带来严重的治理隐患：没有统一的视图能告诉你整个组织到底在AI调用上花了多少钱，也没有统一的闸门能在预算耗尽时真正「刹车」。

这一架构理念与软件安全领域的策略执行点（Policy Enforcement Point, PEP）模式高度一致。在传统的访问控制体系（如XACML标准）中，系统被明确拆分为「策略决策点（PDP）」和「策略执行点（PEP）」：前者负责裁决是否允许某个操作，后者负责在操作发生前强制执行该裁决。将此映射到AI智能体场景，智能体本身相当于发起请求的客体，网关层同时承担PDP和PEP的角色。这种设计的核心价值在于不可绕过性——即使智能体的代码被篡改或提示词被注入攻击（Prompt Injection），外部策略层依然能作为最后一道防线。这也解释了为何「外部授权」相比「内部限制」在安全性上有本质差异，而不只是架构风格的偏好问题。

Lyzr Open Controller的分层预算思路

原帖作者特别提到了 Lyzr Open Controller 的做法，认为它在这个问题上提供了有价值的参考。它的LLM网关把预算设置在多个层级上：

• 组织级（organisation）
• 团队级（team）
• 智能体级（agent）
• 版本级（version）
• 虚拟密钥级（virtual-key）

这种分层预算设计的意义在于，预算不再是某个孤立智能体的属性，而是一个可以从宏观到微观逐级收敛的治理体系。

更关键的一点是：当预算耗尽时，网关会直接「拒绝」调用，而不仅仅是生成一条告警。 这是一个容易被低估的设计决策。告警是被动的、事后的，而拒绝是主动的、强制的。在真正的成本失控场景中，一条无人查看的告警邮件毫无意义，只有硬性的执行闸门才能守住底线。

生态中的其他玩家

有意思的是，这个「网关/代理」问题并非只有一家在解决。讨论中也提到了几个成熟的开源与商业方案：

• LiteLLM：广受欢迎的LLM代理层，支持统一接口、成本追踪和限流。
• Portkey：提供AI网关能力，包括缓存、路由和可观测性。
• OpenRouter：聚合多家模型供应商，处理路由和计费。

这些工具都在不同程度上承担了网关/代理的角色。它们的存在说明，业界已经普遍意识到在智能体和模型供应商之间插入一个中间层的价值。真正的分歧在于：这个中间层应该承担多少「授权决策」的职责，而不仅仅是「流量转发」。

理解这些工具的定位差异有助于选型。LiteLLM本质上是一个兼容OpenAI接口的代理服务器，核心价值是通过统一API屏蔽不同供应商的接口差异，同时附带基本的成本记录和限流能力，适合需要多供应商切换的团队。Portkey在此基础上增加了语义缓存（对相似请求复用结果以节省成本）和更完善的可观测性仪表盘。OpenRouter则更像一个模型市场路由器，专注于按需选择性价比最优的模型，计费由平台统一处理。这三者的共同局限是：它们主要解决「流量层」问题（路由、缓存、计费记录），对于「谁有权发起这次调用」这类身份与策略绑定的授权问题，支持程度参差不齐，通常需要配合自建逻辑或专用工具来补全。

核心争论：花费到底是谁的属性？

归根结底，这场讨论指向一个尚无定论的架构问题：

花费权限应该是智能体自身的一个属性，还是一个智能体必须通过的外部授权决策？

支持「外部授权」的一方认为，只有把决策权外置，才能在多智能体共享、模型路由动态变化的复杂环境中保持一致性和可控性。当底层的模型路由发生变化时（比如从GPT切换到Claude，或供应商价格调整），一个独立的策略层可以透明地处理这些变化，而无需修改每一个智能体的代码。

而现实中，很多团队仍然把预算硬编码在智能体逻辑里，图的是实现简单。但这种便利往往以牺牲可治理性为代价——当规模扩大时，技术债会集中爆发。

给实践者的启示

对于正在构建生产级AI智能体系统的团队，这场讨论提供了几点值得思考的方向：

1. 把预算当作授权问题，而非仅仅是财务监控功能。
2. **优先选择「拒绝调用」而非「仅告警」**的强制执行机制。
3. 在多智能体场景下，尽早引入统一的网关层，避免每个智能体各自为政。
4. 设计分层预算，让治理能力从组织级贯穿到单次调用级。

随着AI智能体自主性的不断增强，「让智能体自己决定花多少钱」将越来越危险。把花钱的权力从智能体手中拿出来，交给一个独立、可审计、可强制执行的授权层，或许才是构建可信AI系统的必经之路。