根据 2026 年 9 月 16 日的发行说明，Databricks 已使 Unity Gateway API 普遍可用于管理模型服务、模型提供程序服务和 MCP 服务。这一更改为平台团队提供了支持的 API 界面，用于生命周期操作，而当他们仅在管理控制台中执行这些操作时，这些操作通常很尴尬：创建、读取、更新、列出和删除。
一般可用性通知很重要，因为 Unity Gateway 位于企业 AI 部署中变得越来越重要的边界。它不仅仅是将请求路由到模型。它涉及定义存在哪些模型服务、允许哪些提供者服务以及可以向代理和应用程序公开哪些 MCP 服务。一旦可以通过标准开发人员工具管理这些对象，网关治理就开始看起来更像普通的平台工程。
发生了什么变化
新的 GA API 涵盖了三种相关服务类型的管理：模型服务、模型提供者服务和 MCP 服务。 Databricks 表示，该 API 支持跨其开发人员工具创建、读取、更新、列出和删除操作，包括 Terraform 提供程序 1.132.0 或更高版本、Databricks CLI v1.17.0 或更高版本、Python SDK 0.136.0 或更高版本、Java SDK 0.153.0 或更高版本以及版本 0.19.0 或更高版本的 JavaScript @databricks/sdk-aigateway 包。稍后。
该工具覆盖范围是真正的操作信号。对于小型实验来说，纯控制台网关是可以接受的，但生产团队通常需要可重复的配置、可审查的更改以及与部署管道的集成。通过通过 Terraform、CLI 命令和 SDK 公开 Unity 网关管理，Databricks 使网关配置成为可编程控制平面，而不是一组手动设置步骤。
有一个推出警告。 Databricks 发行说明称，发布是分阶段进行的，因此某些帐户可能会在初始发布日期后一周或更长时间收到该功能。因此，团队应将 GA 日期视为可用性的开始，而不是证明每个工作区都可以立即使用该功能。
为什么网关 API 现在很重要
这个时机并非偶然。人工智能网关正在从模型代理层扩展到模型、提供者、工具和代理的治理系统。最近的行业举措已将计费控制、模型路由、托管工具、MCP 服务器和身份策略推入网关层。 Databricks 现在正在通过自动化管理 Unity Gateway 资源来加强这一趋势的管理。
对于开发者来说，近期效果是切实可行的。团队可以在代码中定义或更新网关服务，通过环境促进更改，并对更改进行审查。这对于 MCP 服务尤其重要，因为它们可能公开操作操作而不是被动推理端点。如果代理可以调用更改工作流程、读取企业数据或触发业务流程的工具，则服务定义需要与任何其他生产集成相同的规则。
对于平台团队来说，该版本提高了团队 API 治理的基准。问题不再是组织是否拥有网关，而是其网关资源是否可以被审计、版本控制和复制。手动配置在开发、登台和生产之间留下了太多的漂移空间。 API 管理的配置为团队提供了更严格的变更控制、更清晰的所有权和更可靠的回滚程序的途径。
谁受到影响
最直接的受众是已经使用 Databricks 或评估 Unity Gateway 作为其 AI 基础设施一部分的企业 AI 平台团队。这些团队现在可以将网关资源管理纳入他们用于集群、作业、权限和其他工作区资产的相同工作流程中。
应用程序开发人员也可能间接感受到这种变化。当平台团队可以通过自动化发布模型服务和提供者服务时，开发人员可以获得更可预测的已批准端点目录。这可以减少一次性提供程序集成，并更轻松地标准化应用程序跨环境调用模型的方式。
安全和合规团队也有利益相关。通过基础架构即代码和 SDK 工作流程进行的 MCP 服务管理可以更轻松地提出具体问题：存在哪些服务、谁更改了它们、配置了哪些提供程序以及生产是否与批准的配置匹配。当网关状态分散在票证、控制台屏幕截图和本地脚本中时，这些问题很难回答。
该版本对于构建在网关基础设施之上的公司也很重要，包括向多个业务部门或客户公开 AI 访问权限的经销商和内部平台组。如果网关控制平面是可编程的，则更高级别的系统可以配置批准的资源，应用客户特定的策略并将配置事件馈送到AI API使用分析仪表板或审核工作流程。
网关产品的后果
Databricks 正在发出一个竞争信号：网关管理应该是自动化的。这给其他网关和多模型 API 产品带来了压力，要求它们提供成熟的管理 API，而不仅仅是请求路由。对于像 Model Gate 这样的产品，相关的教训是直接的。管理多个提供商、团队、API 密钥和集成的客户将越来越期望网关对象的生命周期自动化，而不仅仅是 Web UI。
这也改变了买家评估人工智能基础设施的方式。支持统一 AI API 计费但缺乏强大的管理 API 的网关仍可能会造成运营瓶颈。计费、使用分析和访问控制需要连接到配置。如果模型服务和工具服务是在可重复工作流程之外创建的，那么财务和治理数据可能会落后于现实。
MCP 角度尤其重要。模型端点是熟悉的基础设施； MCP 服务更接近代理能力面。他们可以定义代理可以发现什么和做什么。将这些服务置于 Terraform、CLI 和 SDK 管理之下表明代理工具治理正在从实验设置转向企业部署实践。
仍不确定的事情
发行说明建立了 API 界面和支持的工具，但并未回答每个实施问题。团队仍然需要检查权限、审核日志、环境升级和故障处理在自己的 Databricks 帐户中的工作方式。分阶段推出还意味着一些组织可能需要等待才能直接测试该功能。
还有一个更广泛的未知数：企业跨平台标准化 MCP 服务管理的一致性如何。 Databricks 是一种重要的控制平面，但许多组织将跨云、SaaS 平台和独立网关产品进行运营。长期挑战不仅仅是通过 API 创建 MCP 服务。当代理可以跨多个系统使用工具时，它就可以维护策略、可观察性和成本责任。
尽管如此，方向还是明确的。 Unity Gateway 的 GA 管理 API 是 AI 网关工作正在成为基础设施工作的另一个标志。将模型、提供者和 MCP 服务定义视为受管理的生产资源的团队将比那些仍将它们作为临时配置进行管理的团队处于更好的位置。