Databricks Provisioning 用面向 Agent 的自动售卖机取代共享工作区

Databricks 已用一套 provisioning 系统取代了不堪重负的共享工作区模式；该系统横跨三大云平台，为超过 5,000 名活跃用户提供服务。新的 Databricks provisioning 系统为现场工程师提供会自动到期的隔离环境，无需管理员再手动协调访问权限。

该公司将这款内部应用称为现场工程自动售卖机（Field Engineering Vending Machine，FEVM）。它的出现凸显了两种基础设施模式之间的明显张力：一种要求人们共享长期存在的环境并协商解决冲突；另一种则为每项任务创建临时且受治理的资源，其中也包括由 AI Agent 发起的任务。

这一转变之所以重要，是因为 Databricks 的市场拓展（go-to-market）组织如今已拥有超过 7,000 名员工。现场工程师经常需要管理员级控制权限，以构建演示、复现客户问题并测试预览功能。三年前，该团队人数还不足 1,500 人；随着规模扩大，共享工作区变得愈发难以治理。

眼前的故事是一场内部基础设施改造。更宏大的问题则是：当 Agent 能够请求资源、部署代码、加载数据并运行工作流时，谁来控制云资源的 provisioning？FEVM 将自然语言意图转化为云基础设施，但也让管理操作更接近自主软件。

Databricks Provisioning 从共享容量转向临时环境

Databricks 已将隔离基础设施作为其现场工程组织的默认工作单元。

在此前的模式下，少量共享工作区支撑了现场组织的大部分工作。当现场工程团队人数不足 1,500 人时，人工维护尚可管理。随着更广泛的市场拓展组织增长至超过 7,000 名员工，这种安排开始失去稳定性。

这个群体的访问需求也不同寻常。典型的企业工作区可以依靠少数管理员管理大量用户。Databricks 的现场工程师则经常需要管理员级控制权限，因为他们的工作涉及配置、测试和面向特定客户的演示。

多名工程师在同一环境中工作时，可能会彼此干扰。为一次演示所作的改动，可能影响另一位工程师为客户会议做准备。许多团队共享容量时，目录、数据库和工作负载限制也会立即成为运营约束。

与此同时，成本归因也会变得模糊。共享工作区能够显示总消耗，却未必能清楚说明是由哪位工程师、哪个客户场景或哪项实验产生。此后，异常活动就需要跨日志和系统进行人工调查。

FEVM 将运营单元从由群体共享的工作区，转变为与用途和所有者关联的环境。工程师可以选择模板、云服务提供商和区域。请求还可以包含 notebooks、Lakebase 资源或打包资产等附加内容。

系统随后会 provision 该环境，并记录其生命周期。Builder 环境的默认生命周期为 90 天，其他资源类型则可采用不同的存活时间（time-to-live）设置。存活时间策略定义了临时资源何时应到期并被移除。

根据该公司详细的 FEVM 介绍，Slack 通知会报告 provisioning 完成、临近到期及删除发生的时间。这样的可见性让清理工作从一项非正式责任变成了有记录的系统事件。

FEVM 还会独立管理部分资源。一个 catalog 可以在其关联工作区消失后继续保留，随后重新连接到同一区域的另一个工作区。这种分离避免了某项资源的生命周期不必要地控制其周围的一切。

因此，重要变化并不只是更快的请求表单。Databricks 将创建、所有权、到期和删除纳入了一个受治理的流程。无论是人类通过界面点击，还是 Agent 调用底层服务，该流程都适用。

规模让管理访问成为核心问题

压力来自这样一支队伍：他们需要广泛控制权，却不能接受广泛控制权通常带来的混乱。

现场工程团队的运作方式与大多数内部业务团队不同。他们必须快速响应客户场景，且所需配置往往无法等待中央平台团队处理。若将每位工程师都限制在狭窄的用户角色中，依赖测试管理功能的工作就会放缓。

但让数千人在共享工作区内拥有广泛权限，也会形成自己的瓶颈。每个用户都获得了灵活性，但每一次改动都会增加争用、所有权不清或意外干扰的可能性。平台管理员随后要花更多时间协调那些原本应由访问模式加速的活动。

FEVM 通过将控制权转移到隔离环境中来解决这一矛盾。工程师保留配置基础设施的能力，而集中维护的模板定义了初始条件。隔离限制了每次实验的影响范围，无需将每个请求都送入人工工单队列。

Databricks 表示，该系统已在 AWS、Microsoft Azure 和 Google Cloud 上处理了超过 2,600 个活跃部署。它还在一次内部工程活动 BuildCon 的一天内处理了近 1,200 个 provisioning 请求。

这些数字来自 Databricks，尚未获得独立验证。不过，它们仍展现了该公司为之设计的工作负载模式：需求会成批涌现，涉及大量用户，并会创建不应无限期保持活跃的资源。

Databricks 于 2026 年 7 月 23 日发布这份介绍时，该系统拥有超过 5,000 名活跃用户。该公司称，当时尚未遇到可扩展性问题。这一说法描述的是内部经验，而非对客户部署性能的保证。

这一规模也改变了基础设施自助服务的含义。小型平台团队可以容忍非正式例外和直接支持。数千名用户则需要可重复使用的模板、明确的所有权、自动清理，以及供管理员日后检查的记录。

包括基于 Backstage 的系统在内的同类开发者门户，通常会通过共享目录展示经过批准的服务和模板。云服务提供商也提供用于标准化基础设施的服务目录。FEVM 遵循这一广泛的自助服务模式，但将其适配于 Databricks 的现场工作和 Agent 驱动的请求。

因此，竞争压力的目标与其说是某一家供应商，不如说是人工管理共享环境的模式。仍在使用工单和长期 sandbox 的内部平台团队，如今面临一个清晰的替代方案：他们可以提供经过批准的临时环境，同时不放弃集中化策略控制。

不过，临时基础设施并不会消除治理工作。它只是将这项工作转移到模板、身份控制、生命周期策略和审计记录中。平台工程师必须谨慎维护这些组件，因为会有更多用户更频繁地调用它们。

Databricks 也承认这一运营现实。该公司称，将 Git 工作流、企业身份、Slack、电子邮件和多云 Terraform 整合起来，比构建应用界面需要更多投入。这一承认比“自动售卖机”的比喻更具启发性。

精致的请求框只是可见的一面。困难的工作在其背后：身份必须随请求传递，权限必须保持边界，删除必须执行，同时又不能移除本应保留的资源。

该机制将用户意图连接至多云基础设施

FEVM 之所以重要，是因为它将用例而非原始工作区规格视为 provisioning 请求。

工程师无需先列出每项所需资源。用户只需描述目标，例如准备金融服务演示或复现支持问题。FEVM 会将该目标映射到经过审查的模板，并提供云服务和区域的配置选项。

该应用使用通过 Databricks Apps 部署的 React 前端和 Python 后端。应用平台在 Databricks 内部运行应用，并将其与 Unity Catalog、SQL 和 OAuth 身份验证等服务连接起来。

Terraform 执行底层云资源 provisioning。Terraform 是一种基础设施即代码系统，也就是说，团队通过版本化配置定义资源，而不是通过彼此无关的人工步骤创建资源。其声明式工作流可通过提供商 API 管理 AWS、Azure 和 Google Cloud 上的资源。

当 FEVM 收到请求时，它会选择相关的 Terraform 模板并将其发送至基于 Git 的 runner。该工作流会调整权限、provision 所请求的附加内容，并记录生成的资源。这种设计将用户体验与基础设施执行层分离开来。

Lakebase 为该系统存储状态和配置。Lakebase 是 Databricks 的托管 Postgres 服务，其文档将 AI Agent 的应用状态列为支持场景之一。FEVM 会记录每项资源是什么、由谁拥有、为何存在以及何时到期。

这份状态记录至关重要。Agent 能够比人类在多个独立控制台之间导航更快地请求若干相互依赖的操作。如果没有可靠的库存记录，自动化创建基础设施的速度可能会快过管理员理解或移除它的速度。

该界面还提供模板目录。Databricks 描述的示例包括 AWS 上稳定的 serverless 环境、多云配置，以及已配置 Lakebase autoscaling 的环境。模板让中央团队能够在请求到来之前编码经过批准的默认设置。

这一结构建立了一条从意图到行动的受控路径：

• 人类或 Agent 陈述用例。

• FEVM 选择经过批准的资源模式。

• 请求者选择允许的参数。

• Terraform 创建云资源。

• Lakebase 记录所有权和生命周期状态。

• 通知展示 provisioning 和删除事件。

• 到期策略移除临时基础设施。

每一步都在减少歧义。自然语言可以表达目标，但经过批准的模板决定了系统实际会创建什么基础设施。这一边界将受治理的 Agent 访问与连接到云凭证的不受限制聊天机器人区分开来。

该机制还支持复合工作流。Databricks 描述了一个场景：工程师要求 Agent 创建工作区、部署本地 Databricks Asset Bundles、从 Amazon S3 上传数据，并为仪表板运行 hydration 脚本。

hydration 脚本会用所需数据或配置填充新环境。从用户角度看，一项请求便可触发整个序列。从平台团队角度看，每项操作仍需要经过身份验证的工具、经过批准的参数以及可观察的状态。

这正是 Model Context Protocol 发挥作用的地方。MCP 是一项开放标准，让 AI 应用能够通过通用接口连接工具和数据源。官方 MCP 概览将其描述为一种让智能体访问外部工作流并执行操作的方式。

Databricks 表示，FEVM 将 MCP 作为聊天界面、外部服务和智能体的中央控制点。集中发布的 Claude skills 可以绕过图形界面，直接调用 FEVM API。skill 文件会告诉智能体如何调用获批准的工作流。

这并不意味着语言模型会直接配置基础设施。智能体会向受控服务提交请求，由该服务应用模板和身份规则。Terraform、Git 工作流以及 FEVM 的后端负责执行会产生实际影响的操作。

这种分离是核心工程决策。自然语言负责表达意图，而确定性的基础设施系统负责执行。模型可以帮助选择和协调工具，但不会取代其底层的状态管理或生命周期控制。

智能体优先访问提高了错误模板的代价

让安全请求变得容易的同一层抽象，也可能将配置错误传播给数千名用户。

Databricks 表示，新模板会经过审查、加固和反复测试。该公司还指出，由于 FEVM 会对真实后端基础设施自动执行管理操作，其团队是在安全例外机制下运行的。

这一披露指出了主要的不确定性。FEVM 将权限集中在一个便捷的界面之后。如果权限、身份映射或模板存在错误，智能体便可能以一致且高频的方式调用这条有缺陷的路径。

人工流程会带来摩擦，但这种摩擦有时能让操作人员有时间注意到异常请求。自动化消除了这段停顿。替代方案必须使用策略检查、受限参数、审批边界和完整的审计记录。

因此，模板质量成为一道安全边界。模板可以决定哪些网络路径存在、哪些身份获得访问权限、哪些数据可用，以及哪些资源会在删除后保留。审查质量与部署速度同样重要。

自然语言带来了另一层不确定性。请求可能不完整、含糊，或基于错误假设。FEVM 必须将意图转换为已知用例，而不能在未察觉的情况下扩大请求者所要求的范围。

Databricks 尚未公布有关失败请求、策略拒绝、错误模板选择、清理错误或平均配置时间的详细指标。这些衡量标准比单纯的部署数量更能反映运营质量。

该公司也未说明，在智能体启动多步骤工作流后，人类需要多频繁地介入。即使基础设施请求成功，如果数据加载、bundle 部署或下游脚本失败，最终环境仍可能无法使用。

成本可见性也需要同样严格的审视。FEVM 将资源与所有者和用途关联，从而改善了归因能力。不过，公开说明并未提供云支出的前后对比、闲置资源减少情况，或平台自身的运营成本。

自动过期可以减少被遗弃的基础设施，但默认 90 天仍足以让昂贵资源不断累积。不同工作负载类型需要不同限制。延期策略也需要审查，避免临时环境通过例行续期变成永久环境。

多云支持扩大了挑战。AWS、Azure 和 Google Cloud 拥有不同的身份系统、配额、区域服务和故障模式。通用请求界面可以向用户隐藏这些差异，但平台团队仍必须对其进行管理。

平台限制也是另一个压力点。Databricks 提到涉及 Unity Catalog 和 Lakebase 资源的硬性限制。集中式生命周期管理有助于避免触及这些上限，但无法消除它们。需求仍可能超过可用容量，或造成区域资源争用。

根据其 Postgres 文档，Lakebase 本身支持事务型应用状态、自动扩缩容和隔离分支。FEVM 的可靠性仍取决于其自身的 schema、协调流程和恢复逻辑如何使用这些能力。

Databricks 表示，团队曾两次重构 FEVM，包括对数据库 schema、前端和状态管理的改动。这一历程表明，该设计需要经过大量迭代。它也提醒人们，不应将当前架构视为简单的参考实现。

该公司使用 AI 加速编码，但表示人类仍掌控架构。对于一个管理特权基础设施的系统而言，这种分工是合理的。生成式代码可以加快实现，而人类审查仍负责把控边界和故障恢复。

FEVM 所报告的规模证明员工希望获得更快的配置能力。但它尚未证明，由智能体发起的请求能提供与经过仔细审查的人类请求同等的可靠性、安全性或成本控制。这些主张需要更长期的运行数据和更清晰的指标支撑。

真正的对手是长期存在的共享工作空间

FEVM 以隔离取代协调，但代价是让中央平台策略变得更加重要。

共享工作空间起初看似高效。团队复用共同基础设施，避免重复设置，并将资源集中在一个可见的位置。当大多数用户需要广泛控制权，而客户工作又需要彼此不兼容的配置时，这些优势便会削弱。

在 Databricks 当前的规模下，共享环境会把协调转化为隐性劳动。工程师必须避免冲突，管理员必须追踪归属，团队必须决定谁能更改公共资源。一场关键演示可能取决于另一位用户不会修改同一环境。

隔离式配置颠倒了这种关系。每位工程师都能获得一个按用途构建的环境，无需与其他所有人协商。平台团队负责标准化模板和生命周期规则，而不是调解单个工作空间的冲突。

这种转变也改变了企业评估利用率的方式。共享环境可能看起来很高效，因为许多人使用同一个工作空间。但这一指标忽略了等待时间、配置漂移、演示失败和排查投入。

临时环境可能看起来效率较低，因为系统会创建更多工作空间。但当资源归属清晰且自动完成清理时，它们仍可能带来更低的运营浪费。Databricks 尚未公布足够的成本数据来证实这一结果，但该设计使其具备可衡量性。

这种模式类似软件交付中使用的临时开发环境。团队为某个分支、测试或审查创建干净环境，并在工作结束后将其移除。FEVM 将类似的生命周期应用于数据和 AI 现场工程。

智能体因素强化了隔离的必要性。通过图形界面操作的人通常会按顺序执行操作。智能体则可以协调多个工具，并根据一条指令创建多项资源。

将这些操作放在拥挤的共享工作空间中，会增加意外交互的可能性。隔离环境为工作流提供了一个有边界的位置。它也为管理员提供了更清晰的归因、过期和删除单位。

不过，如果库存管理和清理失效，隔离也可能导致资源蔓延。答案不只是隔离本身，而是将隔离与集中管理的状态、所有权、通知和生命周期执行结合起来。

这也是为什么“自动售货机”这一标签既有用又不完整。自动售货机展示有限目录，并交付可预测的商品。FEVM 还必须验证请求者身份、理解意图、创建分布式基础设施、监控限制，并最终撤销每一项变更。

该平台更像内部控制平面，而非简单应用。控制平面是决定应当存在哪些资源并协调其生命周期的管理层。FEVM 位于用户或智能体与底层云平台之间。

这一位置让 Databricks 能够直接测试其自身的应用、数据库、治理和智能体技术。它也促使该公司将成功的内部使用案例展示为更广泛平台的证据。

读者应当区分这两项主张。FEVM 可以是可信的内部解决方案，但这并不证明每家企业都能轻松复现它。Databricks 的现场组织拥有专业知识、深入的平台访问权限，以及维护跨企业系统集成的授权。

其他企业可能依赖不同的数据平台、身份提供商、工单系统、策略引擎和云账户。它们的集成工作量可能超过构建用户界面所需的投入。Databricks 自己的说明称，这些集成构成了 FEVM 工程难度和价值的重要部分。

这里的教训并不是每家公司都需要一台完全相同的自动售货机，而是智能体驱动的基础设施需要一条受治理的服务边界。一旦软件智能体能够发起复杂工作流，长期存在的共享工作空间和临时凭据就会变得更难以辩护。

三个信号将表明 FEVM 是否已准备好迎接智能体时代

下一项考验是，Databricks 能否在扩大智能体访问的同时，维持可预测的安全性、清理效果和运营结果。

第一个信号是 FEVM 自然语言界面的计划扩展。Databricks 希望工程师描述客户情况，由系统识别合适的基础设施。更好的意图处理能力将强化这样一种观点：基于用例的配置可以取代人工规格定义。

有价值的证据不会是又一次成功请求的演示。Databricks 应披露该界面多频繁地选择正确模板、要求澄清、拒绝不受支持的请求，或需要人工纠正。

较低的纠正率将支持智能体优先模式。频繁的错误分类则表明，对于特权基础设施操作而言，目录搜索仍比开放式语言更安全。

第二个信号是面向基于工具访问的更广泛 MCP 集成。Databricks 表示，交付这一集成是其下一阶段的优先事项之一。MCP 将让更多智能体客户端通过通用工具接口访问 FEVM，而不必依赖专用图形工作流。

关键问题在于，FEVM 如何在这些客户端之间划定权限范围。强大的身份传递、受限工具、清晰审批和完整审计轨迹将强化这一设计。宽泛凭据或不清晰的委托关系则会削弱它。

安全团队还应关注，智能体操作是否仍能与其人类发起者区分开来。一份有用的审计记录应当关联员工、智能体会话、所选模板、请求用途、生成的资源以及后续删除。

第三个信号是向更广泛的市场拓展组织扩展。更多用户将检验模板在原有现场工程受众之外是否仍然易于理解。他们也会带来新的工作负载模式和支持需求。

仅凭采用数据无法解决这一问题。更有力的指标包括配置成功率、获得可用环境所需时间、策略拒绝率、过期资源清理情况、每个用例的成本，以及人工介入频率。

Databricks 可以通过长期公布这些运营结果来强化其论点。若只关注活跃用户和部署总量，却不解释失败、成本和安全例外，则会削弱其论点。

对开发者而言，FEVM 展示了代理如何通过基础设施工具执行操作，而无需获得不受限制的云访问权限。对企业采购方而言，它为代理治理提供了一项具体检验：每项操作都应有负责人、用途、策略路径和到期规则。

知识工作者也应关注，因为同样的模式将扩展到其他业务系统。代理将请求访问权限、组装项目环境、检索上下文并协调工具。控制层的质量将比聊天界面的流畅程度更为重要。

构建类似工作流的团队还需要在资源配置服务之外保留持久的文档。一个可搜索的知识库可以保存模板决策、事故发现以及供工程师审查代理操作时使用的运维上下文。

Databricks 的资源配置已经在异常庞大的内部规模上运行，但其最具影响力的阶段仍在前方。值得关注的是，自然语言请求能否始终保持边界约束、MCP 访问能否保留身份信息，以及更广泛的采用是否能在不扩大风险的前提下改善结果。

如今，每个平台团队都面临一个明确的实际问题：你的基础设施能否说明每项资源由谁请求、为何存在，以及何时会消失？如果代理无法在这些边界内运行，更快的资源配置只会更快地制造不确定性。