為智能體時代做準備：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 將成為這些智能體運行的資源層——不僅是配置工具，更是智能體工作流的核心基礎設施。