Databricks：Unity AI Gateway 预算如何控制编码代理支出

在每月有 500 至 1,000 名员工触及内部支出上限后，Databricks 改变了数千名工程师使用编码代理的方式。该公司如今通过一个网关路由 Claude Code、Codex、Cursor 及其他代理，并为它们设置独立的每日和每月预算。

这一设计解决了编码代理快速普及带来的矛盾。Databricks 希望工程师能够自由使用 AI，但一个无人看管的自动化循环可能在一个下午就耗尽整月额度。其最初的月度上限将高效工作和失控软件视为同一个问题。

新系统做出了一个更具影响力的判断：成本控制应先中断机器，而不是例行中断人。这使 Databricks 与固定的按用户上限、审批工单，以及每个编码工具各自设置控制措施的传统模式形成对立。

这项预算设计罕见地详细介绍了大型工程组织内部的 AI 成本治理。不过，其结果仍由公司自行报告，公开产品文档也未明确部分执行细节。

月度上限失效后，Databricks 做了哪些改变

Databricks 用两个相互关联的控制措施取代单一月度上限，因为正常需求与失控自动化的时间尺度不同。

该公司最初为每位工程师分配默认月度额度。达到额度的员工可以按固定增量申请提高上限，而特别高的申请则需人工审核。每一次提高还会永久生效。

这种安排每月产生数百项申请。重度用户有时会在一个计费周期内重复这一流程数次。处理紧急工作的工程师则没有直接恢复访问权限的途径。

永久提高上限也扩大了后续失误的潜在影响。某位工程师因一个项目需要额外容量，但项目结束后仍保留该容量。组织逐渐积累了更多可能发生意外消耗的账户。

更深层的问题在于结构本身。一个足以遏制持续整个下午的自动化故障的月度上限，会对持续性的工程工作限制过多；一个足以满足高效用户需求的上限，则难以防范高速循环。

因此，Databricks 将短期浪费与长期浪费分开。短期浪费包括意外启动大量代理会话的自动化任务。长期浪费则包括在数天或数周内反复执行的高成本工作流。

每日预算如今处理第一种情况。它刻意设定得低于月度额度，并在公司使用量最低的时段重置。该公司表示，工程师接近每日边界时，会在失去访问权限前收到 Slack 通知。

员工可以确认该活动是有意为之。此操作会在无需审批申请的情况下，将每日额度再提高一个增量。内部门户和命令行界面中也提供同样的选项。

每月预算则处理持续的异常消耗。Databricks 将这一阈值设得足够高，使典型工程师不应触及它。提高额度需要经理将新增容量与具体业务优先事项关联起来。

这些月度例外会到期。根据其公告，Databricks 通常将其设为一个月、三个月或六个月。除非另一个活跃项目足以证明延长合理，员工随后将回到标准级别。

这改变了触发上限事件的含义。达到每日阈值，是在询问人是否有意进行该活动；达到每月阈值，则是在询问组织是否仍支持其背后的项目。

这一区分很重要，因为编码代理可以在单个提示之后继续工作。它们可以搜索代码仓库、编辑文件、执行测试并启动并行任务。因此，当工程师专注于其他事务时，消耗仍可能加速。

Databricks 没有公布实际的内部额度。它明确表示，示例中使用的数字仅为说明用途。读者不应将这些示例视为其他组织的基准。

可迁移的是运营模式。较短的重置周期可发现突发异常，而较长的周期则管理持续需求。将两者关联，可避免任一控制机制独自承担两种职责。

Databricks：两种预算如何管理一位工程师

核心机制是：每位工程师的上限取当前短期额度和获批月度最大额度中的较低者。

每日和每月预算并非互不相关的配额。Databricks 通过固定比例将它们关联起来。当经理提高员工的月度等级时，对应的每日增量也会按比例提高。

这种耦合既为合理项目保留空间，又不会让其失控防护失去意义。持续稳定消耗的工程师应始终低于每日预警水平，而突然激增的消耗仍会触发人工确认。

Databricks 将有效边界描述为两个数值中的最小值。一个反映月度使用量加上下一个短期增量，另一个反映员工获批的月度总容量。

由此产生的事件会告诉系统下一步应采取何种响应。每日上限事件可通过自助确认解决；每月上限事件则转交经理，因为它代表持续性的异常消耗。

Databricks 会在用户达到每日额度约 90% 时开始通知。消息包括当前消耗和剩余额度空间。员工可以在活跃会话被阻断前提高上限。

每日确认次数没有固定上限。运行有意设定的高需求工作负载的人员可能会批准多个增量。每次确认都会提供一个无人看管的流程本身无法提供的人类信号。

这种摩擦很小，但经过刻意设计。若增量太窄，反复提醒会沦为背景噪音；若增量太宽，防护机制会在要求关注前允许过多非预期活动。

该公司表示，其对增量进行了校准，使稳定的月度消耗不会产生通知。这一主张比可用等级数量更重要。一个反复中断预期行为的护栏，会促使用户规避它或不加区分地批准。

Databricks 通过群组成员关系实施等级。所有人从基础级别开始，进入更高群组后，适用阈值便会变化。这样可避免不断扩大的、附着于个人的任意数值集合。

每日等级调整大多自动进行。随着使用量接近当前上限，计划任务可以提升用户等级，但每天仅一次。月末时，另一项流程会将所有人恢复到基础级别。

月度等级则通过独立路径调整。经理从少量粗粒度级别中选择，而非协商大量渐进式调整。Databricks 表示，较高等级约为基础级别的两倍和五倍，之后还有一个实际不受限制的选项。

这种粗粒度结构迫使管理者对业务价值作出判断。经理批准的是项目规模的例外，而不是反复处理小额申请。其到期机制也防止临时工作造成永久风险敞口。

这一机制借鉴了生产可靠性中的重要理念。系统通常区分突发异常与持续资源压力，因为二者需要不同响应。编码代理治理如今也需要同样的区分。

每日警报类似异常检测器，每月审核则类似容量规划。两者结合比单一固定上限能产生更有价值的信息。

这种方法也为工程师在事故期间提供了退出路径。调查客户问题的员工可以立即确认有意活动，从而无需在生产工作受阻时等待集中委员会审批。

不过，自助服务并不等于无限制支出。每次确认都会成为与身份关联、可观察的事件。重复确认可为后续调整工作流、路由或项目预算提供依据。

一个网关取代一组供应商控制台

Databricks 之所以能够实施统一政策，是因为每个受支持的编码代理都通过共享控制点发送模型流量。

单个工具已提供管理控制。Anthropic 为 Claude Code 提供组织和用户级支出上限，而 OpenAI 为 Codex 提供用户和工作区限制。当工程师使用多种产品时，这些控制措施就更难协调。

Databricks 表示，其工程师经常混用 Claude Code、Codex、Cursor 及其他代理，有些人会同时使用多个。一个供应商控制台内的上限无法看到通过另一供应商产生的消耗。

Unity AI Gateway 位于这些客户端与其调用的模型之间。该网关验证每位员工身份、计量请求，并记录由哪个模型处理工作。因此，预算可以随用户跨工具生效。

该公司表示，网关处理面向 Claude、GPT、Gemini 和开源模型的请求。工程师在使用受治理配置时，无需在机器上使用独立的提供商密钥。Unity Catalog 决定谁可以访问每项模型服务。

这一路由层将碎片化消耗转化为统一的政策界面。网关会在允许更多活动前检查适用于用户的所有预算，同时为管理者和财务团队生成汇总的使用记录。

这份编码代理教程将公开设置描述为测试版功能。管理员将外部代理配置为使用网关端点，然后应用权限、速率限制和支出控制。

速率限制和预算解决的是不同问题。速率限制控制短时间段内的请求或 token 数量；预算则跟踪货币消耗，而货币消耗会因模型选择和每个请求的大小而变化。

身份对于两者都至关重要。共享 API 密钥很难区分高效工程师和故障后台流程。按用户进行身份验证可让网关归因消耗，并应用个性化阈值。

集中式路由也为 Databricks 的模型优化提供了路径。未来的路由器可将常规工作发送给更高效的模型，同时为高难度任务保留前沿模型。该公司表示，此类路由仍在开发中。

这一计划揭示了更广泛的竞争压力。编码代理供应商日益提供自己的分析和控制功能，但客户很少只统一使用一种代理。当使用跨越多个提供商时，企业需要工具层之上的治理。

Anthropic 的管理控制包括细粒度支出上限和 Claude Code 使用分析。OpenAI 的使用分析则按用户、产品和模型细分 credit 消耗。

Google 还通过 Cloud Monitoring 报告 Gemini Code Assist 的活动情况。其指标包括活跃用户、被接受的建议、API 调用和 token。不过，Google 指出，部分测量仅覆盖 IDE 内的活动。

这些原生控制台仍然很有价值，因为它们揭示了产品特有的信号。中央网关则提供了另一种优势：跨客户端和模型的一致归因。许多组织需要的是这两个层面，而非一个万能仪表板。

Databricks 的模式迫使平台团队决定权威应当落在哪里。如果每个供应商控制台都保持独立，政策就会逐渐偏离，财务部门也会得到同一工程职能的多个视图。

如果所有流量都经过网关，组织将获得一致的控制，但也要为该网关的可用性和配置承担责任。一次路由错误可能会同时影响所有接入的智能体。

这正是本文讨论的核心：分散的供应商控制与集中化、基于身份的治理之间的较量。Databricks 选择了集中化，因为其工程师早已跨越产品边界工作。这一选择让政策能够被执行，而不只是被记录。

对于正在构建类似工作流的工程组织而言，一个可搜索的技术知识库可以保留获批例外背后的决策依据。仅靠成本记录无法解释，为什么一次昂贵的智能体会话是必要的。

自助服务消除了工单，但没有消除问责

Databricks 将大多数日常额度事件视为合理工作，颠覆了“异常消耗应先进入审批队列”的传统假设。

这是这一设计中最有意思的部分。许多成本控制系统要求用户在工作得以继续前，先证明额外消耗的价值。Databricks 则要求用户确认短期额度提升，并将审批留给持续性的例外情况。

这一政策反映了中断的成本。工单不仅会占用管理员的时间，也会打断工程师的工作流，并可能延迟调试、测试或事故响应。

Databricks 表示，在典型月份中，有 500 至 1,000 名工程师会达到此前的月度限额。在这种频率下，审批会变成例行运营工作，而非有意义的审查。反复提出请求也会使真正特殊的情况更难被识别。

替代工作流在触及日度边界时要求更少的证明。一项操作即可确认某人知晓当前消耗，并希望继续进行。该信号能够阻止无人看管的软件运行，同时让有意开展的工作恢复。

自动化循环无法点击自己的 Slack 通知。cron 作业同样无法打开内部门户并确认当前消耗是有意为之。因此，人工确认形成了一道适度的门槛，专门针对自主活动。

这道门槛是行为层面的，并非技术上的绝对限制。工程师可以反复批准昂贵的工作，却不改进底层方法。这也是为什么月度最高限额仍需要管理层判断。

经理不会审查每一次突发消耗，而是判断持续高于常态的消耗是否属于重要项目。例外会附着于该项工作，并在批准期限到期后结束。

这种分工赋予员工自主权，但不会把整个预算决策都转交给他们。工程师控制短期连续性，经理控制长期偏离正常范围的情况。

这一模式符合 FinOps 的原则：团队应为自身的技术使用负责。FinOps AI framework也将细粒度数据、不可预测的支出和跨平台分摊列为 AI 的独特挑战。

不过，问责需要的不只是一个阈值。经理需要了解是哪个代码仓库、工作流、任务和模型产生了这些消耗。仅有月度总额无法说明这项工作是节省了时间，还是反复生成了无法使用的输出。

Databricks 表示，网关使用数据会进入 Unity Catalog，并可出现在用于内部分析的同一 Lakehouse 表中。这为将成本与工程元数据关联提供了基础。该公司尚未公布完整的投资回报率方法论。

这一缺失可以理解，但很重要。较少的工单量证明新工作流降低了行政摩擦，却不能证明每次额外的智能体会话都创造了与之成比例的工程价值。

该公司还表示，工程师已不再节制使用。这是内部观察，而非独立测量的生产力结果。更高的采用率可能代表有价值的委派、实验，也可能代表本可避免的重复。

因此，成熟的项目应在支出之外追踪结果。相关信号包括被接受的改动、完成的任务、被回退的代码、审查工作量、事故解决情况，以及按工作流划分的模型使用情况。

这些测量也有局限性。被接受的代码行数可能鼓励冗长表达，任务数量则可能掩盖难度。只有组织谨慎定义“结果”，每项结果的成本才有意义。

Databricks 在解决所有测量问题之前，先构建了执行层。这种顺序有其合理性，因为无边界的消耗会立即阻碍采用。但随着对成本失控的担忧下降，价值问题会变得更加重要。

公开产品仍存在执行层面的疑问

Databricks 展示了一种经过验证的内部模式，但客户应将该模式与目前针对每种公开工作负载所记录的精确控制措施区分开来。

7 月 28 日的公告称，Unity AI Gateway 对编码智能体的支持已向所有 Databricks 客户开放。公告还将日度预算、临时覆盖和用户驱动的阈值提升描述为影响未来产品开发的内部机制。

这种措辞很重要。该公司的下一步计划包括原生日度预算周期、会到期的覆盖，以及用于自助提升的权限模型。因此，内部工作流的部分环节似乎依赖于围绕网关构建的自动化。

公告前更新的公开预算文档主要聚焦月度支出。它还列出了影响跟踪、覆盖和使用阻断的限制。

例如，文档称，外部模型推理和预置吞吐量目前不由这些预算跟踪。它还说明，在该页面中，按用户覆盖和阻断仅适用于 Genie 预算。

另一份 beta 教程称，管理员可以设置网关级支出预算并阻止编码智能体使用。这些页面可能描述了不同的发布阶段、云环境或功能配置。Databricks 应为正在设计生产控制措施的客户澄清其适用边界。

近实时执行也允许出现一定程度的超额。文档警告称，达到阈值后，正在进行的请求可能仍会完成。阻断生效前也可能出现短暂延迟。

这种行为在按量计费系统中很常见，但智能体增加了风险复杂性。一次用户操作可能产生多次模型调用，并发会话也可能让多个请求持续处于活跃状态。组织应测试最坏情况下的风险敞口，而非假定存在完全硬性的边界。

报告延迟带来了另一项区别。Databricks 表示，执行采用近实时跟踪，而计费系统表可能每隔数小时才更新。因此，警报、仪表板和 SQL 查询在同一时刻可能显示不同的总额。

这些时间差异会影响事故复盘。工程师可能在相应记录出现在财务查询之前就收到警告。运营流程应明确哪个界面负责即时决策。

集中路由还依赖于完整覆盖。使用直接供应商密钥、不受支持的集成或其他计费路径的工程师，可能脱离网关的视野。只有当身份和路由政策阻止这些替代方案时，该架构才能发挥作用。

Databricks 表示，其所有内部编码智能体流量都通过该网关。客户需要在自己的环境中验证这一条件。覆盖大部分流量的政策，可能会让人对剩余流量产生错误的信心。

自助确认也引入了自己的失效模式。频繁的警报可能训练员工形成条件反射式批准，尤其是在截止日期临近时。Databricks 认识到这一校准问题，但没有公布其内部使用的阈值公式。

组织将需要各自进行调优。模型价格、工作时间、项目形态和智能体行为因团队而异。适合交互式开发的阈值，可能不适用于计划执行的测试生成或迁移工作。

隐私和劳动问题也值得关注。按用户记录的支出可以支持成本分摊，但不应变成简单化的员工绩效评分。高消耗可能反映困难的任务，低消耗可能反映高效工作或采用程度有限。

最稳妥的解读应当保持有限。Databricks 描述了一种可信的控制模式，并报告称审批摩擦有所减少。它尚未确立通用的预算比例，也未独立验证生产力提升。

客户应从观察开始，识别正常使用分布，并通过受控工作负载测试执行机制。在将其作为财务边界依赖之前，他们还应确认哪些请求类型计入每项预算。

三个信号将显示该模式能否扩展

下一项考验是，Databricks 能否将其内部自动化转化为清晰的原生产品控制，同时不重新制造它已消除的摩擦。

第一个信号是对日度预算周期和自助提升的原生支持。Databricks 表示，这些能力正在影响其产品路线图。它们的到来将减少复现内部工作流所需的定制自动化。

具体细节将比功能标签更重要。客户需要可配置的重置时间、基于身份的通知、可审计的确认记录和清晰的权限设置。他们还需要在多个请求同时跨越阈值时具备可预测的行为。

如果这些控制措施伴随一致的文档推出，Databricks 将强化其网关级治理的理由。如果它们仍依赖内部脚本或有限预览，客户就更难采用这一模式。

第二个信号是临时月度覆盖。到期机制是该公司论点的核心，因为它能防止一个项目永久扩大未来的风险敞口。原生的项目范围例外将把这一原则转化为可复用的控制措施。

一项有用的实现应记录批准经理、业务理由、生效期限和受影响的身份组。它还应自动恢复原状，而无需再提交一张工单。

如果 Databricks 推出这一生命周期，网关就不再只是计量层。它将开始编码工程、财务和管理层如何共同为智能体消耗承担责任。

第三个信号是更智能的模型路由。Databricks 表示，希望让常规任务使用高效模型，同时将前沿系统留给更困难的工作。这将在预算边界介入前，先解决昂贵工作流的问题。

路由将需要可信的评估。如果一个更便宜的请求带来更多重试、审查工作或有缺陷的代码，其价值就很有限。Databricks 需要将模型选择与任务结果关联，而不只是与 token 消耗关联。

成功将巩固该公司的核心论点。治理能力可在塑造消耗方式的同时提升采用率。若路由效果不佳，预算只能在低效决策已经发生后管理症状。

更广泛的市场也会作出回应。OpenAI、Anthropic 和 Google 正持续增加使用分析、限额和企业管理功能。对于坚定采用单一供应商的组织而言，它们原生提供的控制能力可能已足够。

混合工具的工程环境则有不同需求。这类团队需要一层随身份在不同客户端和模型之间流转的策略层。Databricks 正将 Unity AI Gateway 定位为承担这一角色的产品。

工程负责人现在应审视自身的智能体流量：有多少工具会产生消耗？自主循环能以多快速度升级？哪些例外情况应获得即时、自助式恢复？

Databricks 的操作指南提供了一个实用起点，但其核心启示关乎组织管理。短期异常与长期投资决策不应共用同一种审批机制。

关注原生日度控制、会过期的临时覆盖规则，以及结果感知型路由是否会如承诺般推出。这些信号将共同表明，Databricks 构建的是可迁移的治理模型，还是一套高效的内部定制方案。