代理雲：Databricks 對 AI 與資料基礎建設的願景

Databricks 正在從湖倉架構演進為一套完整的資料與 AI 作業系統。核心論點是，只要資料正確定位且可取得，現代 AI 代理的推理能力就足以改寫傳統軟體範式——實質上是從複雜的應用程式邏輯轉向「把資料放好，然後在上面套上代理」的模型。

Omnigent：AI 代理的元掛鉤

Omnigent 是一個開源的元掛鉤，旨在為各種 AI 代理掛鉤（例如 Claude Code、Codex 與 Cursor）提供共通的 API 與基礎建設層。它解決了不同團隊為相同基本代理需求重複建構框架的碎片化問題。

共通 API 與可移植性

Omnigent 實作了統一的代理會話介面，允許使用者傳送訊息或檔案，並接收串流文字或工具呼叫。這層抽象確保若底層模型或掛鉤 API 變更，開發者不必重寫整個協調器。

協作與持久性

為了將代理從孤立的本機工具提升至企業級軟體，Omnigent 提供：

• 持久會話：能在多個會話間保留歷史與狀態，使用者不必一直開著筆記本電腦才能維持連線。
• 雲端沙盒：隔離的運算環境，代理可以執行程式碼並保有本地函式庫與產物的持久性，無需每次都重新安裝。
• 協作共享：基於伺服器的架構，允許團隊成員安全地共享代理會話與歷史記錄。

代理安全與花費控制

Databricks 主張單純的「允許/拒絕」二元安全政策不足以應付代理。相反地，Omnigent 引入 情境（有狀態）政策。

舉例來說，代理可能被允許讀取機密文件與安裝 NPM 套件，但有狀態的政策會在同一會話中若已讀取機密資料或安裝了可疑的、僅一天的套件，就阻止其將內容推送至公開網站。

此外，Omnigent 也支援 會話層級的花費控制。使用者可以為子代理設定特定預算（例如 $5），超過後必須取得手動授權才能消耗更多 token，防止代理因讀取巨量日誌檔而意外燒掉大量金錢。

LTAP：重新思考資料庫堆疊

Databricks 正在推出 LTAP（Lakehouse Transactional Analytics Processing），作為解決 OLTP（交易型）與 OLAP（分析型）資料庫歷史分離的方案。

CDC 與 HTAP 的失敗

傳統上，公司會使用變更資料捕捉（CDC）將資料從交易型資料庫（如 Postgres）搬移至分析系統。Databricks 把 CDC 稱為「持續的資料腐敗」，因為它脆弱；來源資料庫的簡單結構變更就可能導致整條管線失效，常常讓資料工程師在凌晨 3 點被叫醒。

雖然 HTAP（Hybrid Transactional/Analytical Processing）嘗試打造同時支援兩者的單一引擎，但往往因為妥協而削弱了兩種工作負載的效能。

LTAP 方法：統一儲存層

LTAP 著重於統一 儲存層 而非查詢引擎。透過直接將交易資料寫入欄位式格式（如 Parquet）於資料湖中，分析引擎即可即時讀取，無需 CDC 管線。

這是透過利用儲存叢集中的閒置 CPU，將列式（適合 OLTP）即時轉碼為欄位式（適合 OLAP）。此方式提供了 HTAP 的好處——即時資料可供推理使用——卻不會遭遇單一引擎架構的效能折衷。

「夢想引擎」與資料驅動設計

Databricks 正從頭開發全新資料庫引擎，以避免「第二系統綜合症」以及十多年來被迫改造以支援非設計用途的舊引擎所累積的技術債。

資料庫演算法工廠

團隊並非僅依賴學術論文，而是建立了一個「工廠」，利用十年的追蹤資料——數千兆筆資料點——訓練機器學習模型。此模型能預測特定演算法與資料結構在不同工作負載下的表現（考量延遲、吞吐量、資料稀疏度等維度）。

執行時分派

引擎可在執行時根據查詢與資料的具體特性分派最有效的演算法。例如，若偵測到欄位中的字串密集（如國家代碼），引擎可在雜湊表與陣列查找之間切換，顯著提升效能。

模型策略：從通用到專精

在收購 MosaicML 後，Databricks 已將焦點從競爭「前沿模型」賽（通用大型語言模型）轉向高效能、具高實用價值的專精模型。

• Genie：一個虛擬資料科學家代理，專精於公司特定的資料與機器學習函式庫。
• 專精視覺模型：Databricks 開發了一個文件解析模型，能將 PDF 與 Word 文件轉換為 JSON。據稱此模型的成本比前沿模型低 100 倍，且在此特定任務上精度更高。
• RL 微調：Databricks 正聚焦於強化學習（RL）微調即服務，利用更聰明的基礎模型產生更佳的 RL 追蹤，讓打造專精代理的流程更有效率。