为智能体时代做准备：Databricks如何构建自助基础设施自动售货机

在 Databricks，现场工程组织的使命是帮助客户成功。这意味着构建演示、重现问题、在真实工作负载上测试功能，并随时准备向潜在客户展示平台的可能性。在 AI 时代，这一点比以往任何时候都更加重要——一周可能带来根本性的变革。随着 Databricks 的发展，以快速、受治理且成本可控的方式赋能现场组织变得既重要又具有挑战性。

为了解决这个问题，我们构建了现场工程自动售货机（FEVM）。就像一台好的自动售货机一样，理念很简单：你说出需求，你得到它，用完后它自动消失。最重要的是，FEVM 以 Databricks 原生组件为核心，并将智能体视为一等公民。

三年前，现场工程团队不到 1500 人，少数共享工作区覆盖了大多数用例，手动维护也还能运转。但 Databricks 增长迅速，GTM 现在超过 7000 人，现场工程占了很大比例。曾经适用于一个规模的基础设施需要重新设计以适应新的规模。共享工作区中多名工程师在同一环境中工作会相互干扰，平台限制（如目录、Lakebase 实例和并发工作负载）成为现实问题，成本归属变得模糊，可观察性也面临挑战。

FEVM 的核心洞察是：如果每位工程师都能拥有自己的隔离环境，几分钟内配置完毕，集中管理并自动清理，情况会怎样？当 Databricks Apps 可用后，我们有了明确的构建机会。过去我们用一系列独立作业维护环境，每个作业执行一项任务，总是稍微落后于现实。Apps 让我们将所有功能抽象到一个单一界面背后：用自然语言描述你要完成的任务，我们就会配置相应的基础设施。

这就是 FEVM 的核心设计原则：基于用例的配置。你不是请求“一个工作区”，而是描述你要做什么——构建金融客户演示、重现支持问题、运行黑客马拉松——然后获得为特定目的配置的环境。这一切通过 MCP 抽象，意味着聊天、外部服务和智能体都通过单一控制点提供服务。借助 Claude 等工具，只需添加一个简单的 .md 技能文件，你就可以用自然语言通过命令行请求新环境，几分钟后即可登录。

FEVM 采用 React 前端和 Python 后端，通过 Databricks Apps 部署。Terraform 在后台运行，负责在 AWS、Azure 和 GCP 上进行实际云资源配置。状态和配置数据库运行在 Lakebase 上，跟踪每个资源：它是什么、谁拥有它、用途和过期时间。

当现场工程师打开 FEVM 时，会看到一个搜索界面。他们可以浏览模板目录，选择合适的环境类型——例如 AWS 上的稳定无服务器、多云设置或预配置了 Lakebase 自动扩展的环境——并配置云提供商、区域，描述构建内容，命名后即可部署。最近，我们还启用了智能体优先工作流，允许用户使用集中发布的 Claude 技能；智能体可以自动执行 UI 操作，直接调用底层 FEVM API。这在多步骤和多工具工作流中尤其强大：例如，用户可以告诉智能体启动新工作区、部署多个 DAB、上传 S3 中的数据，然后运行脚本填充仪表板。

当用户或智能体请求新资源时，后台会获取相应的 Terraform 模板，提交给 Git Runner，调整权限，并添加用户请求的“附加组件”，如 Lakebase、笔记本或 UC Volume 中的预打包资产。构建环境默认存活 90 天，可延期，其他资源类型具有可配置的 TTL。配置完成后会发送 Slack 通知，资源接近过期时再次通知，删除时也会通知。透明度是核心设计目标：每个生命周期事件都可见。

我们还在同一界面管理共享资源。独立目录具有独立生命周期，删除工作区后目录保留，在同一区域创建新工作区时目录自动重新附加。这种资源级生命周期管理很重要，因为 Unity Catalog 和 Lakebase 有严格的平台限制，集中控制可以防止这些限制成为瓶颈。

在内部活动 BuildCon 期间，FEVM 一天处理了近 1200 个配置请求。工程师们创建环境、完成工作、让它们过期，没有协调开销或资源争用。目前我们管理着超过 2600 个活跃部署，跨越三个云，没有遇到扩展性问题。

我们两次重新架构了 FEVM：重新设计数据库模式、重建前端、重新思考状态管理。我们使用 AI 加速编码，但在架构上始终掌握主导权。结果是一个值得信赖的系统，可以在规模上运行。

下一步，我们将专注于三个方面：扩展自然语言配置界面、交付 MCP 集成以实现基于工具的访问，以及在整个 GTM 组织中扩展支持。随着智能体承担更多现场工程师的工作，FEVM 将成为这些智能体运行的资源层——不仅是配置工具，更是智能体工作流的核心基础设施。