北京
周一下午三点，一个工程师在他的 AI 编码代理里提交了一组优化任务。不到两个小时，系统告警弹出，说他这个月可用的 API 额度已经归零。明明离月底还有二十多天，代码补全和自动化重构的请求却被网关无情地拦下了。他翻看账单日志，发现是自己的代理在一个从未测试过的重构循环里不断调用 Claude Code，把整个月的预算烧去了一大半。
这在 Databricks 并不是个例。公司内部有几千名工程师每天混用 Claude Code、Codex、Cursor 等编码代理，消费量已经是研发支出里增长最快的项目之一。单个代理一旦陷入失控的自动化循环，一个下午就能打穿整个月的额度。Databricks 一度用最简单的办法来管这些支出：给每个人设一个默认的月度限额（比如 500 美元），花光了就提交申请提额。本意很直接，但实践起来却发现这套单人单月上限的策略，带来的摩擦比省下的钱更让人头疼。
负责 AI 基础设施的团队很快注意到两件事被强行捏在了一起。一是防止支出失控，也就是避免一个代理在极短时间内烧掉巨额成本的安全阀；二是月度预算管控，帮部门和团队把长期开支控制在计划范围内的财务线。把它们合成一个限额，既拦不住突发的瞬时爆量，又在月底前频繁打断正常开发。工程师因为一次大胆的实验或自动补全稍微用多了几次，就要被迫走审批，而真正要防的代理失控却可能在限额被触发时，已经造成了超过限额数倍的账单。
Databricks 最终的做法是把这两个目标拆开，分别交给日度预算和月度预算去执行。日预算用作应急熔断器，重置周期短，专门对付在几小时内持续提速的代理行为。月度预算则保留原来的财务控制功能，只是不再同时承担防暴冲的职责。这样一来，一个代理哪怕在某个下午异常消耗，也会在日预算耗尽时立刻被截停，整个月的额度还完好无损，只损失当天的份额。
更关键的变化出现在提额流程上。团队发现，绝大多数碰到额度上限的工程师并不是在滥用，而是在做分内的工作——比如重构一个大型模块或者跨项目做批量分析。因此 Databricks 把提高预算的入口做成了自助服务。工程师在触发限额后不需要排队等审批，只要在网关页面上明确选择的项目和预计的额外用量，就能立刻解锁。审批只保留给那些真正例外的情形，比如项目周期拉长超过一个月，需要的额度远超常规区间，而且审批本身也带有时效限制，避免一个短期项目带来的提额变成永久特权。
这套机制能够落地有个前提：Databricks 所有的编码代理，不管用的是哪家的模型、哪款产品，全都必须通过 Unity AI Gateway 发送请求。网关成为了统一执行策略的唯一控制点，无论后台有多少种代理的运营面板，预算规则只在这里设定一次。双层预算、自助解锁、分级审批这些规则也因此能够一致地作用到每一位工程师、每一款工具上，不用再去逐个控制台修改参数或者挨个帮同事救火。
把成本治理的粒度和响应时间从“月度紧急申请”调整成“日度自动熔断加随时自助提额”之后，内部投诉直线下降。研发节奏没有被打断，工程师不再觉得 AI 辅助变成了需要小心翼翼省着用的奢侈品。同时，财务团队第一次拿到了跨模型、跨工具的汇总消费视图，能按项目、团队或者代理商类型一眼看到钱去了哪里，而不是面对散落在各家厂商后台的零碎账单。这也让预算政策的迭代开始基于数据而非口头的感受——哪些工具的日预算触达率偏高、哪个部门常在月中就用完额度，都能被快速抓出来并调整策略。
目前 Databricks 正在把相同的办法推向更多内部团队，同时计划在网关里加入更细粒度的计费标签和自动预警，让失控保护不仅能刹车，还能在真正烧穿之前就给出通知。经过内部这一轮完整的落地验证，团队也更确信，要想在快速扩大 AI 采用的同时不把流程卡死在审批清单上，关键的不是一拍脑袋给每个人画一条死线，而是让控制节点足够智能、足够轻量，把人为决策留给那些真正需要权衡的少数时刻。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
