Databricks Unity Gateway CLI 将编码智能体选择置于统一控制平面之下
在六个月内四大模型家族相继变化后，Databricks 推出了 Unity Gateway CLI，使编码智能体的选择成为企业不断变化的目标。Databricks Unity Gateway CLI 为管理员提供了一条受治理的统一路径，用于管理模型、工具、技能、使用情况和支出。开发者仍可通过 ug claude 或 ug codex 等命令打开自己偏好的智能体。
这种组合也带来了核心张力。Databricks 并非要求工程组织统一采用某一种编码智能体，而是希望它们统一采用所有智能体底层的网关，随后无需重新搭建每位开发者的配置即可调整模型和策略。
主要替代方案是直接进行厂商特定的管理。OpenAI、Anthropic、Google 和其他厂商都能治理各自的产品，其控制机制通常围绕原生环境设计。Databricks 押注于：企业会更重视共享控制平面，而非各个厂商技术栈更紧密的独立集成。
Databricks Unity Gateway CLI 集中管理智能体配置
此次发布将编码智能体配置从逐个开发者处理的任务，转变为集中发布的基础设施。
管理员可在 Unity Gateway 中配置获批智能体、默认模型、Model Context Protocol 服务器、可复用技能、路由行为和支出策略。MCP 是一项标准，使 AI 智能体能够通过一致的接口调用外部工具并获取上下文数据。
管理员发布配置后，CLI 会在开发者启动智能体时获取并应用该配置。Databricks 表示，组织还可以锁定选定设置，并通过其设备管理系统分发 CLI。
初始界面刻意保持精简。开发者可输入 ug claude、ug codex、ug gemini、ug opencode、ug copilot 或 ug pi。随后，CLI 会验证用户身份，将所选程序连接至 Unity Gateway，应用组织配置，并打开该智能体熟悉的终端界面。
Cursor 的定位更为有限。开源 CLI repository 表示，Unity Gateway 可为 Cursor Agent 配置 MCP 服务器，但 Cursor 的模型仍通过开发者的 Cursor 账户运行。这一区别很重要，因为对某个智能体界面的支持，并不保证所有客户端都能获得完全相同的模型路由。
配置同步是更大的变化。如果管理员修改默认模型，开发者下次通过 ug 启动相关智能体时便会看到新的选择。该公司还介绍了基于群组的逐步发布机制，使平台团队能够先让有限群体测试新模型，再扩大部署范围。
这一设计将智能体框架与其背后的模型分离。智能体框架是负责规划工作、调用工具、编辑文件和管理编码会话的软件。语言模型提供推理和生成能力，但周边框架决定这些能力如何作用于代码仓库。
因此，一个团队可以继续使用 Claude Code 作为界面，同时调整其网关允许使用的模型配置。另一组则可以继续使用 Codex，同时获得同样获批的 MCP 工具和支出规则。
这种方式解决了真实存在的运营负担。每个智能体通常都有各自的配置文件、身份验证约定、工具注册格式和环境变量。支持多个智能体可能会成倍增加配置脚本，并导致开发者所遵循的策略不一致。
Databricks 目前会管理受支持客户端的文件，并在本地保存已应用配置的记录。其代码库文档称，该工具会在修改文件前进行备份，并提供 ug revert 用于恢复这些备份。ug doctor 命令可诊断配置问题，而 ug status 会报告已配置的工作区、模型、技能和生成的文件。
其结果并非一个新的编码智能体，而是一个部署层，使多个智能体都像同一企业服务的客户端一样运行。这一变化引出了本次发布的核心竞争：共享网关对阵彼此独立的厂商控制平面。
编码智能体的增长正在给平台团队带来压力
最直接的压力落在平台、安全和财务团队身上：他们必须治理开发者采用速度快于企业策略跟进速度的工具。
Databricks 于 2026 年 9 月 24 日推出该 CLI。其发布公告指出，GPT-6、Claude Opus 5.5、Gemini 3.8 和 Grok 4.7 都是在此前六个月内发布的。公告还提及了包括 Kimi K3、GLM-5 和 DeepSeek V4.1 在内的开放权重模型。
该公司估计，如今大约每五天就会出现一个新的前沿模型。这一估计是 Databricks 的描述，并非标准化的行业衡量指标。不过，这样的发布节奏解释了为何固定的企业默认选择会迅速过时。
模型质量只是一个变量。较小的模型可能以更低成本完成常规编辑，而能力更强的模型可能在全仓库迁移中表现更好。可用性、延迟、上下文处理、工具使用和区域要求也都可能改变合适的选择。
在没有共享层的情况下，企业面临两个不太理想的选择。它们可以统一使用一家提供商，并接受另一款模型可能更适合某项特定任务的事实。或者，它们可以支持多个智能体和提供商，然后在这些体系中重复实施身份、预算、日志和工具策略。
第二种路径保留了选择权，但增加了管理覆盖面。开发者可能为一个智能体使用一种凭据，为 MCP 服务使用另一种令牌，再为模型提供商使用单独的密钥。使用记录可能最终散落在不同控制台中，归因方式也未必一致。
Unity Gateway 试图整合这些路径。根据该公司的治理文档，模型和 MCP 请求可以通过一个通用层传递，该层会应用权限、速率限制、服务策略和使用记录。Unity Catalog 提供底层访问模型。
这种架构让管理员能够向指定用户或群组授予模型访问权限，而不必分发提供商密钥。智能体使用 Databricks 凭据进行身份验证，网关在转发获批请求时提供已存储的提供商凭据。
Databricks 在模型服务层面记录了每分钟请求数和每分钟令牌数的限制。这些限制可以全局应用，也可以按用户应用。使用情况系统表会记录到达网关流量的请求者、服务、响应状态及其他运营数据。
当编码智能体能够调用工具时，这一点尤其重要。模型响应会消耗令牌，但智能体会话还可能搜索代码仓库、查询数据库、调用内部函数或联系外部服务。工具访问带来的策略问题，比单独的模型访问更广泛。
集中式 MCP 注册为平台团队提供了经过筛选的工具集。管理员无需要求每位开发者将服务器定义粘贴到多个本地配置文件中，而是可以发布获批服务，并使其适用于兼容的智能体。
团队仍需要为代码仓库、API 和操作流程提供准确的内部文档。可搜索的工程知识库可以提供这类上下文，而网关则治理智能体如何访问获批工具。
这种压力既是短期的，也是结构性的。平台团队需要一种即时方式来接入最新智能体，同时避免重复实施控制措施。从长期来看，它们还需要防止治理模式被绑定到某一家模型厂商的发布周期。
这正是该产品面向开发者偏好多样化组织的原因。如果所有工程师都使用同一厂商和模型，额外的管理层可能带来有限收益。当不同团队坚持使用不同框架、但安全团队仍要求一条可追责的统一路径时，其价值便会更强。
一个网关如今正与独立的厂商控制平面竞争
Databricks 押注于，集中式可移植性比在各厂商原生企业环境中管理每一个编码智能体更重要。
厂商原生控制平面具有明显优势。其管理员可以治理产品独有的功能，包括执行环境、代码仓库连接、审批模式、保留设置和专用遥测。
例如，OpenAI 在其关于安全运行 Codex的说明中描述了工作区控制、沙盒机制、策略要求和面向智能体的遥测。这些控制针对的是完整智能体的行为，而不仅仅是其模型和工具流量如何抵达网关。
Anthropic 和其他智能体厂商也遵循相同的大致模式。每家厂商都可以围绕自己的框架、模型家族、权限系统和更新节奏优化管理。当企业承诺使用单一产品时，这种垂直整合可以简化支持工作。
Unity Gateway 提出的是一种横向模式。网关成为稳定的策略边界，而智能体界面和默认模型可以变化。它无需取代所有原生安全机制也能创造价值。只要足够多的流量通过其控制措施，集中式身份、成本和工具策略便具有实际意义。
当一家公司希望切换模型时，这一区别最容易看出。在厂商特定部署下，团队可能需要更新本地配置、配置新凭据、修改允许列表并重新创建使用情况报告。具体工作取决于智能体和提供商。
使用 Databricks Unity Gateway CLI 时，管理员可以修改已发布的默认模型。下一次启动会应用该默认值，而无需每位开发者编辑智能体设置。群组控制可在评估期间将这一变更限制在选定用户范围内。
外部提供商支持扩大了这一价值主张。Microsoft 的 Azure Databricks 文档称，Claude Code 和 Codex 可以通过注册在 Unity Catalog 中的提供商服务进行路由。这些服务可以代表 OpenAI、Anthropic、Amazon Bedrock 或其他受支持的提供商。
智能体将请求发送至 Unity Gateway 端点，而请求标头会标识目标提供商服务。网关提供已存储的密钥、检查访问权限并记录使用情况。开发者无需在自己的机器上保存上游提供商密钥。
这种可移植性存在边界。底层模型必须与所选智能体兼容，并且每个框架都可能要求特定于提供商的请求行为。网关无法自动让每个模型支持每项专有智能体功能。
受支持智能体矩阵也因能力而异。一些客户端接受集中配置的模型、MCP 服务器和技能。Cursor 目前会接收 MCP 配置，但其模型流量不会转移至 Databricks。外部提供商路由对于某些智能体的发展程度也高于其他智能体。
这些差异使 Unity Gateway 无法成为适用于所有编程工具、可完全互换的统一接口。该平台必须跟上多个独立开发客户端不断变化的配置格式和身份验证行为。
这个开源项目让维护工作一目了然。其适配器会为 Codex、Claude Code、Gemini CLI、OpenCode、GitHub Copilot CLI、Pi 和 Cursor 写入特定于代理的文件。每一次上游配置变更，都可能转化为 Databricks 的兼容性工作。
不过，开放性也让采购方能够审查集成方式。团队可以查看代码库，在受控环境中测试变更，并了解 CLI 管理哪些文件。当工具会修改开发者机器上的设置时，这种透明度十分有用。
因此，横向路线是在深度与一致性之间作出取舍。厂商原生系统可以控制更多产品专属行为；Unity Gateway 则可在更广泛的界面集合中提供统一的身份、模型访问、MCP 注册、预算控制和报告能力。
胜负不会仅由功能清单决定。企业将评估这些共享控制是否覆盖了它们真正需要管理的风险，以及该网关带来的运维负担是否小于它消除的负担。
智能路由将模型选择与支出关联起来
该产品的经济逻辑，取决于能否在不要求开发者为每次会话管理模型选择的前提下，将常规工作路由至成本更低的模型。
编程请求的差异很大。重命名一个变量，并不需要与诊断跨多个服务的分布式故障相同的推理能力。若每项任务都使用获批模型中能力最强的一款，即使工作本身很简单，企业也可能支付高昂成本。
Unity Gateway 的 Smart Routing 会为主会话选择模型，也可为委派给子代理的工作单独选择模型。Databricks 表示，其内部编程基准测试显示，这种方法可节省 35% 的成本。
这一数字应被视为内部评估结果，而非普遍适用的结论。其他组织能够实现的节省幅度，将取决于其任务构成、可用模型、路由准确性、供应商条款以及对重试的容忍度。
如果更便宜的首次尝试反复失败，或生成需要更多审查的代码，最终成本可能更高。反过来，将每个请求都路由至高能力模型，也可能把预算浪费在可预测的简单修改上。一个有用的路由器必须能够可靠地区分这些情况。
Databricks 还支持具备预算意识的默认设置。当使用量达到设定阈值时，管理员可以为新的启动建议使用成本更低的代理或模型。活跃会话会继续运行，而不会在工作中途切换模型。
该公司的支出控制区分共享预算、每用户限额，以及针对特定用户或群组的覆盖规则。管理员可以触发警报、阻止后续网关请求，或同时采取两项措施。
预算执行依赖近乎实时的估算。已经运行的请求可以完成，因此最终消耗可能超过阈值。对外部供应商支出的估算，也可能与最终供应商账单不同。
默认设置并不等同于硬性限制。Databricks 表示，智能默认设置会影响新的启动，但不会阻止获得授权的开发者选择其他可用模型。Unity Catalog 权限或预算拦截可提供更严格的执行方式。
Smart Routing 还有进一步限制。它目前适用于 Claude Code 和 Codex，其文档列出的候选范围仅限于 system.ai 下的模型服务。Databricks 表示，它不能与自定义模型、外部供应商、Unity Catalog 位置或该命名空间之外的其他模型服务结合使用。
这些限制缩小了可移植性的叙事空间。组织可以通过网关集中管理外部模型，但未必能将它们纳入同一套自动优化循环。寻求供应商中立路由的采购方应仔细测试这一边界。
追踪机制提供了反馈渠道。Databricks 表示，Unity Gateway 可以将模型活动、本地工具调用和技能调用收集到统一的追踪表中。随后，管理员可以调查反复发生的工具故障、过大的输出，以及其他消耗令牌却未推动任务进展的模式。
该公司称，它通过这一流程与 Genie One 一起识别出七个 MCP 工具缺陷。Databricks 估计，修复这些问题每年避免了 120 万美元的 AI 支出浪费和生产力损失。
同样，这一数字是该公司基于自身环境作出的估算。它将直接模型支出与对生产力损失的估计合并计算，因此读者不应将其视为可直接迁移的投资回报率基准。
一个客户案例提供了不同规模的信号。Concurrence CTO John Xing 表示，在采用 Unity Gateway 后，该公司通过约 36 万次请求路由了超过 610 亿个编程代理输入令牌。他称，公司已能以身份维度集中了解使用情况和支出。
这份证言证明，至少一家实名客户已让该系统处理了大规模生产流量。但它未披露延迟、错误率、代码采纳率、安全结果，或该组织如何衡量开发者满意度。
因此，其经济价值主张仍是一种机制，而非保证结果。集中式路由创造了让成本与任务复杂度匹配的机会；追踪可以暴露浪费；预算可以约束消耗。实际节省仍取决于相关策略与真实工程工作的匹配程度。
集中治理仍存在覆盖缺口
网关只能治理实际经过它的流量、客户端和工具。
除非组织通过设备策略、凭据、网络控制或内部标准强制使用受管路径，否则开发者可以直接启动原生代理，绕过控制平面。Databricks 明确指出，在 Unity Gateway CLI 之外运行的原生 Claude Code 和 Codex 会话，无法获得其 Smart Routing 功能。
因此，流量覆盖率是评估中的首要问题。管理员应确定每个模型请求、MCP 调用和委派任务是否都经过网关。部分路由可能造成不完整的审计记录，却仍营造出集中控制的表象。
第二个问题是本地执行。网关可以授权模型并记录工具流量，但编程代理还可能读取文件、运行 shell 命令、安装软件包，或修改开发者机器上的代码库。这些操作取决于运行框架的沙箱机制、审批系统和本地策略。
这正是原生企业控制仍然重要的原因。模型治理并不能替代终端安全、代码库权限、分支保护、代码审查、密钥管理或代理自身的执行边界。
MCP 进一步扩大了信任边界。获批服务器仍可能暴露广泛能力、返回不可信内容，或触发副作用。管理员需要审查各个工具、限制凭据，并决定哪些操作需要确认。
身份维度的归因有助于调查，但归因本身并不能让工具变得安全。追踪记录可以在事后显示是谁发起了操作。预防性控制仍必须限制该身份和代理被允许执行的操作。
配置所有权同样会带来张力。开发者通常会维护经过精细调校的代理设置、本地 MCP 服务器和工作流专属指令。集中配置可能覆盖或冲突于这些选择。
Databricks 通过备份、受管文件、锁定设置、试运行预览和回滚命令来缓解这一风险。企业在大规模部署前，仍应在具有代表性的开发者环境中测试升级。
兼容性是另一项持续挑战。编程代理供应商可能更改配置架构、身份验证流程、模型要求或 CLI 行为。Unity Gateway 必须足够快地适应，避免一次集中更新同时中断所有受支持客户端。
公开代码库已经包含有关平台支持和供应商组合的报告。单个问题并不能证明产品整体上不可靠，但它们说明了多代理网关带来的集成负担。
集中化也可能扩大影响范围。错误的默认设置、无效的 MCP 注册、过期的身份验证路径或过于严格的策略，都可能同时影响众多开发者。分批发布和回滚流程是必需条件，而非可有可无的便利措施。
组织在评估时应区分三项主张。Unity Gateway 可以集中管理选定的配置；它可以治理通过其服务路由的流量；它可以从受支持客户端收集证据。任何一项都不意味着它控制每个代理执行的所有操作。
可信的试点项目应测试绕过路径、本地工具行为、故障恢复、配置冲突和审计完整性。它还应将网关记录与供应商账单及客户端遥测数据进行比较。
最强的部署模式将采用分层控制。Unity Gateway 可以作为模型和工具流量的边界；原生代理控制可以限制执行；现有软件交付系统则可继续执行审查、测试和发布策略。
三项信号将显示网关战略是否奏效
接下来的考验在于，Databricks 能否将广泛兼容性转化为可衡量的采用率，同时不削弱策略覆盖。
第一个信号是代理和供应商之间的支持一致性。采购方应关注模型路由、Smart Routing、MCP 注册、技能、追踪和外部供应商访问，是否会在所有受支持客户端中持续可用。
更高的一致性将强化共享控制平面的论点。持续存在的例外情况，则会推动企业转向代理专属管理或混合架构。Cursor 仅支持 MCP 配置以及当前的 Smart Routing 限制，为比较提供了清晰基线。
第二个信号是独立的成本和质量证据。Databricks 已公布 35% 的节省结果，以及一项可观的内部减废估算。客户现在需要报告：在纳入重试、人工审查、延迟和失败工具调用后，路由是否确实降低了总任务成本。
已完成任务成本降低的证据，将验证这一路由机制。仅基于令牌价格的节省说服力较弱，因为低价请求仍可能带来昂贵的工程返工。
第三个信号是生产环境中的治理覆盖率。企业应衡量有多少比例的代理模型调用和工具调用出现在网关记录中，然后测试策略是否能稳定阻止被禁止的访问。
高覆盖率且绕过行为很少，将支持 Databricks 的核心论点。受管会话与原生会话之间持续存在的缺口则会削弱这一论点，尤其是在开发者可以在批准路径外安装或启动客户端的组织中。
Databricks Unity Gateway CLI 在一个关键时点推出。模型选择不断扩展，编程代理正获得更深入的访问权限，而各供应商独立的控制台并不会自然形成一个企业范围的统一策略层。
Databricks 给出了明确的回答：保留开发者偏好的界面，但让网关成为持久的控制点。这一方案比强迫每位工程师使用同一个代理更灵活，却也比安装另一个命令行工具提出了更高要求。
平台负责人现在应开展一个有边界的试点：使用两个智能体、若干任务类别，并进行明确的绕过测试。在扩大部署前，比较已完成任务成本、追踪覆盖率、开发者阻力和恢复时间。
决定性的问题不在于 ug codex 或 ug claude 能否成功启动，而在于：一个网关能否以足够完整的方式同时治理二者，让安全团队信任记录、财务团队信任支出数据，并让开发者继续使用获批准的路径。
