COST / 成本
花費有歸屬
找出用量來源，搭配預算、限制與模型選擇管理支出。
非官方網站依 Databricks 與 Microsoft 官方公開資料整理，本站未獲兩家公司授權或背書。
01 / 先懂產品定位
Unity Gateway把企業 AI 的使用，
變成可管理的日常。
當公司開始使用多種模型、程式開發代理與企業工具，Unity Gateway 提供共同的治理入口：誰能用、花多少、能做什麼、出了什麼問題。
企業 AI 的共同入口
內部應用Coding Agents
Unity Gateway存取 · 成本 · 政策 · 可觀測性
AI 模型MCP 與工具
Unity Catalog資產目錄、身分權限與資料治理
CHOICE / 選擇
模型有彈性
在共同治理入口下，使用託管模型或串接外部供應商。
CONTROL / 控制
操作有規則
把權限、防護、工具控制與紀錄帶進 AI 的執行過程。
第一次接觸 Databricks？先認識它的位置
Databricks 是雲端資料與 AI 平台，讓團隊整理資料、做分析、建立及執行 AI 應用。它的 Lakehouse（湖倉一體）把資料湖的彈性與資料倉儲的分析能力結合，供不同團隊共用資料。Unity Catalog 管資產與權限，Unity Gateway 管經過它的 AI 互動。
初次認識產品可從架構與基本名詞開始；企業導入窗口可接著讀企業導入地圖，再照POC 專章準備環境、測試治理並整理驗收證據。功能與操作細節皆預設展開。
02 / 架構與基本名詞
先把模型、代理與治理分清楚
工作區（Workspace）是團隊使用平台的環境；一個帳戶可包含多個工作區；啟用 Unity Catalog 後，可集中管理使用者與資料存取，帳務則在帳戶層級處理。你通常從工作區的 AI Gateway 頁面管理服務，從 Catalog Explorer 查看資產與權限。
MODEL模型依輸入產生文字、程式等結果。
AGENT代理呼叫模型與工具，執行多步計畫。
MCP / TOOLS工具執行操作；MCP 提供標準連接方式。
ASSETS & ACCESSUnity Catalog管理資料與 AI 資產的存取權。
AI INTERACTIONSUnity Gateway治理經過它的呼叫、路由與用量。
完整元件對照：包含 Model Serving、MLflow 與 SQL Alerts
| 元件 | 主要責任 | 文件所述能力 |
|---|---|---|
| 模型 / Model | 理解輸入並產生文字、程式或其他結果。 | 支援聊天機器人、程式助理與內容生成。 |
| 代理 / Agent | 依任務呼叫模型與工具，執行多個步驟。 | 判斷要取得哪些資料、呼叫哪些工具，並執行計畫。 |
| MCP / 工具 | MCP 是連接代理與工具、資源、提示的開放協定；工具才是實際可執行的能力。 | 透過 MCP server 提供工具與資源。 |
| Unity Catalog | 登錄資產、管理擁有者與存取權。 | 定義哪些團隊可執行某個模型或工具。 |
| Unity Gateway | 治理經過它的 AI 呼叫、成本、路由與互動。 | 在模型或工具被使用時套用統一規則。 |
| Model Serving | 部署並提供模型推論服務。 | 以 REST API 統一提供自訂、基礎與外部模型存取。 |
| MLflow | 記錄應用執行步驟、評估及比較品質。 | 檢視提示、檢索、工具呼叫、延遲與成本。 |
| SQL Alerts | 排程查詢與條件通知。 | 依稽核事件查詢結果監控異常活動。 |
模型從哪裡來？兩條路都能接到 Gateway
DATABRICKS 託管Model Service包含 system.ai 預建服務。
模型後端Databricks 模型由 Databricks 提供推論。
外部供應商Model Service以服務名稱接入。
連線與驗證Model Provider Service集中管理供應商連線。
模型後端外部供應商使用所設定的供應商模型。
可見不等於可用：system.ai 模型仍須核對區域、跨地理區域設定、模型可用性與權限。
Provider Service：直接呼叫與憑證保存方式
Model Provider Service 也可直接查詢。Databricks 可保存加密憑證，呼叫者不會取得其內容；Amazon Bedrock 也可引用既有 service credential。
官方文件中的服務互動與控制
請求帶著身分進入應用或 coding agent 呼叫服務。
控制授權與使用規則依設定檢查權限、預算、速率與政策。
執行模型或工具模型服務路由；MCP 服務呼叫工具。
回傳回應檢查與紀錄依設定檢查內容，記錄用量與追蹤。
Service Policies 為 Beta，須另行啟用；工具使用的身分取決於連線設定。
治理的邊界，就是你接進來的路徑。
若員工或程式仍直接用個人金鑰連到外部模型，這些呼叫不會因公司啟用了 Gateway 就自動受管。官方模型治理教學會設定客戶端入口，並驗證請求是否已寫入 Gateway 用量表。
讀懂文件，先認識這些名詞
常用名詞：Token、BYOK、RAG、身分與預覽狀態
- Token
- 模型處理文字等內容的計量單位；輸入與輸出可能採不同費率。 [08] Model Serving 與推論容量 ↗
- Endpoint / Model Service
- Endpoint 是呼叫入口的通稱；Model Service 是 Unity Catalog 裡受權限管理的模型入口，可連到多個後端。它與部署模型的 Model Serving 不同。 [03] 模型 API 與 Model Services ↗
- BYOK
- Bring Your Own Key：使用公司既有供應商金鑰，由平台管理連線。 [04] 外部模型供應商與 BYOK ↗
- Harness
- 讓代理執行任務的框架或執行環境，例如 Claude Code、Codex。 [20] Omnigent on Databricks ↗
- Trace / 追蹤
- 記錄應用的輸入、中間步驟與輸出，用於理解及分析執行過程。 [15] MLflow 3 for GenAI ↗
- Beta / Public Preview / GA
- 官方平台分類將 Beta 列為不適用正式環境、無介面穩定或 SLA 保證；Public Preview 列為可用於正式環境並提供 SLA；GA 為正式提供。仍須核對個別功能條件。 [45] 預覽與正式發布分類 ↗
- Metastore / Catalog / Schema
- Metastore 是單一雲端區域的治理容器，可供同一區域的多個工作區共用。資料與 AI 資產採
catalog.schema.object三層命名；物件層級依類型而異：例如儲存憑證位於 metastore 下，HTTP 連線也可建立於 schema 層級。 [37] Metastore 與資產層級 ↗ HTTP 連線層級 ↗ - Principal / OAuth
- Principal 是被授權的身分，例如使用者或程式專用的服務主體。OAuth 讓應用經授權取得存取權；每人 OAuth 與共用服務帳號的權限範圍不同。 [19] MCP Services、身分與網路 ↗
- RAG / 檢索增強生成
- 從搜尋索引檢索相關文件，將結果加入模型查詢；AI Search 是官方列出的 RAG 檢索工具。 [32] AI Search 與檢索 ↗
- DBU / Serverless
- DBU 是 Databricks 的用量計費單位，金額需配合產品費率換算。Serverless 表示平台管理運算資源，仍有使用費用。 [31] Databricks Apps ↗ [39] 帳戶、工作區與基本元件 ↗
相關產品怎麼搭配？按工作選擇即可
以下依官方文件整理各產品用途及其治理相關能力。
相關產品：Agent Bricks、AI Search、Genie、Apps 與資料工具
| 想完成的工作 | 會遇到的產品 | 治理與功能範圍 |
|---|---|---|
| 建立企業代理 | Agent Bricks 頁面整合 Databricks AI 能力；可用 Knowledge Assistant 建立領域問答代理、用 Supervisor Agent 協調代理與工具，或以 Python 開發 Custom Agents。 | 負責建立應用；Gateway 治理它呼叫的模型與工具。[30] 建立與部署代理 ↗[38] Agent Bricks 定位更新 ↗ |
| 替模型找公司知識 | AI Search（原 Vector Search）用語意與關鍵字搜尋相關資料，常用於 RAG。 | 索引由 Unity Catalog 治理；AI Search 不支援資料列與欄位層級權限，可透過 filter API 實作應用層存取控制。[32] AI Search 與檢索 ↗ |
| 用自然語言問資料 | Genie One 是商務使用者入口；Genie Agents 由資料團隊設定可信資料、指標與商業規則；Genie Code 是工作區內的程式與資料助理。 | 這些是使用 AI 的介面與能力；Gateway 預算也可涵蓋 Genie 用量。[33] Genie 產品家族 ↗[06] 預算、通知與用量封鎖 ↗ |
| 把應用交給同事使用 | Databricks Apps 在 serverless 平台執行資料與 AI 應用，支援互動儀表板、RAG 聊天介面與資料輸入表單，也能託管自訂 MCP server。 | Apps 執行應用程式，Gateway 管理接入的 AI 呼叫。[31] Databricks Apps ↗[18] MCP 與代理工具總覽 ↗ |
| 先整理資料再提供 AI | Lakeflow pipelines 管理 ETL 流程與資料集依賴；Delta Lake 提供具 ACID 特性的資料表儲存；SQL warehouse 提供分析查詢運算。 | 它們準備、儲存及查詢資料，是資料工作層。[28] Databricks 平台入門 ↗[39] 帳戶、工作區與基本元件 ↗ |
03 / 14 項功能詳解
14 項治理與延伸能力，逐一拆解
依官方文件整理涵蓋 Gateway 治理、紀錄與平台延伸能力。每項都附用途、官方來源及文件限制；「文件已說明」表示有操作文件，不代表對所有區域或帳戶都無條件開放。
成本與模型選擇
成本管理Cost Management文件已說明
預算與支出限制Budgets and Spend Limits部分 Beta
可設定共用或每人每月門檻，選擇寄出警示或封鎖後續用量；也可替特定人員與群組設例外額度。範圍含經 Gateway 的按 token 用量、ai_query 與 Genie；外部模型費用可選擇納入。
導入前看這裡：封鎖採近即時估算，不中斷執行中請求，也不是最終帳單的絕對上限。預算不涵蓋 provisioned throughput 或繞過 Gateway 的獨立 Serving 流量。外部模型納入預算為 Beta，須另行啟用；預算比對使用服務標籤，不使用請求標籤。
智慧路由Smart RoutingBeta
依程式開發任務挑選具備所需能力、成本較低的候選模型。可透過 Unity Gateway CLI 搭配 Codex 或 Claude Code 使用；若要跨不同代理執行框架選擇，需使用 Omnigent。
導入前看這裡：需由帳戶管理員啟用 Smart Routing 預覽；目前僅選 system.ai 模型服務，使用者須有所有候選模型權限。CLI 要以命令列提供任務，互動式根工作階段不適用；跨框架需 Omnigent v0.8.0 以上。
推論容量Inference Capacity相關產品
Model Serving 負責實際提供模型推論。可使用 Databricks 託管基礎模型的按 token 付費方式，或為需要預配置容量的工作負載使用 provisioned throughput；也能接外部供應商。
導入前看這裡：Model Serving 有預設服務限制與支援區域；其 serverless compute 需完成帳戶啟用條件。Foundation Model APIs 支援按 token 計費及 provisioned throughput，適用模型依各方案文件列示。
資產、存取與安全
AI 資產登錄AI Asset Registry部分 Beta
模型服務在 Unity Catalog 中管理名稱、擁有者、說明與權限，可跨共用 metastore 的工作區使用，但仍繼承 catalog／schema 的 workspace bindings。Agent Services 提供代理登錄、Catalog Explorer 探索與權限管理；其 Beta API 的 GET 回應目前不提供 owner 與 full_name 值。
導入前看這裡：Agent Services 為 Beta。官方頁面對執行能力的敘述前後不一致；本站依「Limitations」保守說明：目前提供登錄與權限管理，不承諾可經登錄服務執行代理，亦不支援其 service policies、rate limits 或 SQL DDL。
安全與存取控制Security and Access含 Beta 政策
以 Unity Catalog 權限決定誰能呼叫服務，再以內容政策檢查每次互動。模型 API、供應商連線與 MCP 服務可各自管理授權。
導入前看這裡：呼叫者需有服務的 EXECUTE，以及上層的 USE CATALOG、USE SCHEMA。Model Service 以擁有者權限存取後端，呼叫者不必直接取得底層模型或供應商權限。system.ai 模型服務預設授予帳戶使用者 EXECUTE，實際可用性仍受區域等條件影響。
若要讓所有現有與未來的 system.ai 模型服務只供指定團隊使用，官方提供在該 schema 移除 account users 的 USE SCHEMA 與 EXECUTE，再授予指定團隊的路徑。這是 schema 層級異動；移除 USE SCHEMA 也可能使同在 system.ai 的內建 MCP Services 無法使用，除非呼叫者仍從其他授權取得所需權限。應盤點模型、MCP 及服務 owner 的相依權限後執行；只鎖定 POC 自建服務，並不會自動封鎖其他預設模型入口。
權限與政策變更可能需數分鐘才反映到查詢。擁有者必須持續擁有各主目的地與備援 Model Provider Service 的 EXECUTE；失去其中一項權限會使模型服務請求失敗。
透過 Model Service 路由到 Model Provider Service 時，只套用前者的 Gateway 功能；後者的速率限制、防護、inference tables 等設定會被略過。
服務政策Service PoliciesBeta
依呼叫者、輸入、輸出與工具資訊，讓互動繼續（ALLOW）、拒絕（DENY）或等待人員同意（ASK）。可在呼叫前、回應後檢查；支援 Log 模式的政策可先觀察判定，再改 Enforce 阻擋。Sensitive Data Detection 僅支援 Enforce。
導入前看這裡：政策不取代基本存取權。DENY 以 HTTP 200 回傳封鎖訊息，原因見 databricks_service_policy；Enforce 模式評估出錯也會封鎖，Log 模式不阻擋。外部 MCP 的 ASK 需客戶端支援 MCP 2025-11-25 以上，並在核准後重試呼叫；核准會快取一小時，相同呼叫於此期間不再次詢問。
AI 防護規則AI Guardrails服務政策防護為 Beta
Service Policies 是實施防護的機制。內建 LLM 規則可檢查越獄、不安全內容或幻覺；Sensitive Data Detection 依格式偵測敏感資料；其專題文件列出 Model、Model Provider 與 MCP Services 均可阻擋或遮蔽，MCP 另可在輸入命中時要求核准，輸出命中時則改為阻擋。也可使用 SQL 函式定義自訂政策。
導入前看這裡：Sensitive Data Detection 為 Beta，僅支援 Enforce，且套用所有帳戶使用者，尚不能設定 Principals 與 scope。不支援姓名、地點、組織等自由文字；支援類別未列臺灣身分證字號，官方另示範以 LLM judge 檢查自由文字。LLM 防護判定非確定性，預設只評估單一訊息，不看被保護服務的 system prompt、影像或音訊；模型與供應商服務可擴大輸入的最近回合窗口，MCP 與輸出仍為單訊息。
速率限制Rate Limits文件已說明
模型服務可限制每分鐘請求數（QPM）與 token 數（TPM）；MCP 服務限制 QPM。可設定整體服務、預設每人及特定使用者或群組規則；群組速率額度由成員共用。
導入前看這裡：預設不設限。超限回傳 HTTP 429，官方建議採指數退避重試。用量在回應後計入，且各服務執行個體分別限流，短時間可能略超門檻。每服務最多 20 筆規則，其中最多 5 筆為群組規則。
流量管理與備援Traffic Management文件已說明
依設定權重分流到多個模型後端，適合逐步上線或 A/B 測試；百分比總和須為 100%。分流會自動啟用 session affinity：有工作階段識別 header 的請求固定到同一目的地，未提供則依權重分流。主目的地失敗時，依指定順序嘗試備援。
導入前看這裡：分流最多五個目的地，不能在備援目的地再設定分流。權重決定初次目的地；備援依設定順序重試，不會重新套用分流權重。Smart Routing 則依開發任務挑選模型。
觀測、除錯與稽核
追蹤與可觀測性Tracing and Observability統一追蹤表 Beta
用量表 system.ai_gateway.usage 記錄用量、耗時與呼叫者；inference tables 逐一為模型服務記錄請求與回應。官方建議新部署採統一追蹤表：由 metastore 管理者一次配置，集中同 metastore 工作區的模型與 MCP 服務活動，每列是一個 OpenTelemetry span。
導入前看這裡：統一追蹤採 best-effort；inference tables 透過 Zerobus 以 at-least-once 方式交付，可能重複。兩者都可能缺少 401、403、429、500 錯誤紀錄。統一追蹤單一屬性超過 3 MiB 會截斷；跨步驟共用 trace ID 尚待提供。其他使用者需另取得表與父層權限；官方建議授權前加 ABAC 列篩選。統一追蹤不能取代 Databricks 稽核紀錄。
AI 稽核紀錄AI Audit Logging系統表 Public Preview
用 system.access.audit 查詢誰在何時存取 AI 服務，並依事件參考確認操作欄位。identity_metadata.run_by 與 run_as 可區分相關執行身分；模型訊息內容則由追蹤或 inference tables 記錄。
導入前看這裡：稽核系統表為 Public Preview，多數事件只在工作區所在區域可用。刪除工作區後，該工作區超過 14 天的事件會從此表移除。若要查看 LLM judge 的完整判定，須在 evaluator model service 另啟用 inference table；受保護服務的表不包含 judge 的輸入與判定。
MLflow 追蹤與評估MLflow Tracing相關產品
MLflow 3 串連應用追蹤、自訂或內建評分、人員回饋與版本比較。它協助開發團隊理解模型之外的檢索、工具及代理步驟如何影響品質。
導入前看這裡：需為應用設定 autologging 或自訂 instrumentation。Production monitoring 為 Beta，可對生產 traces 抽樣評分；若 traces 存於 Unity Catalog，須在 experiment 設定 SQL warehouse ID。
安全監控Security Monitoring相關產品
Databricks SQL Alerts 可定期執行查詢，在結果符合條件時通知。官方列出以 audit log 查詢監控異常工作區活動的用法。
導入前看這裡：需先取得查詢資料的權限，再設定排程、條件及通知對象；告警依資料到達與查詢頻率運作。
延伸到實際工作：Coding Agents、MCP 與 Omnigent
讓開發工具共用治理入口
官方整合涵蓋 Claude Code、Codex CLI、Cursor 與 Gemini CLI 等工具。Unity Gateway CLI（ug）協助驗證身分、設定代理與導向服務；用量儀表板可觀察不同工具使用狀況。
需有支援區域的工作區與 Unity Catalog。Unity Gateway CLI 安裝需要 Python 3.12 以上及 uv；手動 Codex 設定要求 Codex CLI 0.118 以上。Cursor 整合目前僅支援 Databricks 提供的模型服務。
MCP：治理代理伸出去的手
可使用內建 MCP Services 或登錄外部 MCP，並以 Unity Catalog 權限控制呼叫。自登錄服務可設定工具選擇與政策；內建服務的工具與政策由 Databricks 管理，須依各服務限制確認可調整範圍。Databricks 管理連線憑證與 OAuth 流程。
共用 principal 讓使用者共用外部憑證；每人 OAuth 代表各使用者存取外部服務。工具選擇只支援精確名稱或前綴比對，不支援排除模式。外部連線經工作區 serverless compute plane，內建 SaaS 服務也受網路政策控制；Restricted 模式須允許目標網域。服務 EXECUTE 與網路允許為兩個獨立條件。
可組合或替換代理框架、共享工作階段，並搭配 Databricks 模型存取與沙箱。需啟用工作區預覽；Databricks Sandbox 有額外區域與預覽條件。Databricks 版僅支援內建 contextual policies，不支援執行任意程式的自訂政策函式。Sandbox host 一律透過 Gateway 存取模型，不接受自帶模型 API 金鑰；也不整合 serverless 出站網路控制，官方要求不要在已啟用該控制的工作區使用。
04 / 官方使用案例
官方文件實際說明了哪些用法？
以下摘要取自所附的操作文件與教學；每張卡片可直接回到原文。功能條件與限制見第 03、06 節。
CODING AGENTS
用 Databricks 身分接入開發代理
代理 → Model Service → 模型。以 Databricks 憑證呼叫，再集中設定權限、速率與預算；開發者機器不必保存供應商金鑰。
MODEL SERVICES
在共同入口管理模型後端
Model Service 管路由，Provider Service 管外部連線；可按權重分流，主目的地失敗時依序嘗試備援。
SERVICE POLICIES
檢查模型與工具互動
請求前、回應後各有內容檢查。敏感資料政策可阻擋或遮蔽支援格式，不涵蓋姓名等自由文字；此功能為 Beta。
MCP SERVICES
治理 GitHub 工具存取
以 system.ai.github 附加政策、授權團隊、連接代理，再驗證工具呼叫。實際允許範圍依政策與工具標記判定。
COST ANALYTICS
依服務與身分分析費用
按服務、模型、身分與標籤歸屬費用。外部模型是每小時彙整的估算，預算使用近即時估算；兩者都不等於最終供應商帳單。
OBSERVABILITY
查閱用量、效能與內容
儀表板看請求數、token、延遲與錯誤率；內容另查 inference tables 或統一追蹤表，仍受各自交付限制。
05 / 教學與 API 選擇
模型治理入門，再延伸到 MCP
本節依模型存取治理教學的三個步驟整理；該文件的 Next steps 也列出 GitHub MCP 治理教學。
模型教學的前置條件
工作區須啟用 Unity Catalog；準備可呼叫的 Model Service 與 EXECUTE 權限、已登入工作區的 Databricks CLI，以及工作區 URL。服務的完整授權條件見模型文件。
01 / 連接讓代理走 Gateway以 ug 處理 OAuth 與客戶端設定。
02 / 設定誰能用、可用多少服務權限、QPM／TPM 與預算。
03 / 驗證送出提示，再查用量在 system.ai_gateway.usage 核對紀錄。
兩個界線：預算使用近即時估算，無法保證最終帳單上限；讀取用量表需要另外授權。
操作位置與設定說明
連接程式開發代理
官方建議使用 Unity Gateway CLI（
ug）處理 OAuth 與客戶端設定，也提供手動設定路徑。首次啟動時輸入工作區 URL 並完成驗證。設定模型存取、速率與預算
在 Catalog Explorer 管理服務的
EXECUTE，設定 QPM 或 TPM；帳戶管理員可建立 Unity Gateway 預算，選擇通知或封鎖用量。預算採近即時估算，不能保證最終帳單上限。確認請求經過治理
從代理送出提示，再查詢
system.ai_gateway.usage確認服務、呼叫者與狀態。查詢系統表需要另外的讀取權限；有服務執行權不代表可讀全部用量紀錄。
延伸教學：GitHub MCP 的四個步驟
官方教學使用 Databricks 提供的 system.ai.github。前提包括 Unity Catalog 工作區、已登入的 Databricks CLI，以及服務上的 MANAGE 與 EXECUTE。MCP 呼叫也需父層 USE CATALOG、USE SCHEMA；system.ai 內建服務通常已有帳戶使用者的預設父層權限。
01 / 政策附加寫入控制github_policy + disallow_writes。
02 / 權限授予團隊 EXECUTE控制誰能呼叫此服務。
03 / 連接設定 Gateway MCP 入口各開發者以 Databricks 身分登入。
04 / 驗證測試工具，再查紀錄確認允許、拒絕與用量紀錄。
Service Policies 為 Beta。工具結果仍依政策與工具標記判定；官方教學對 PR 工具及寫入封鎖的敘述有張力，不能保證所有建立 PR 操作都會放行。
政策名稱、管理員授權與驗證說明
附加內建政策
教學指定
system.ai.github_policy與disallow_writes，將寫入控制明確設為受治理政策。Service Policies 目前為 Beta，需依政策文件啟用。分享 MCP Service
在服務 Permissions 頁面授予團隊
EXECUTE。教學另註明，metastore 管理員要在system.ai授權前，須先取得該 schema 的MANAGE。連接開發代理
將客戶端導向該服務的 Gateway MCP 入口；各開發者以 Databricks 身分登入，並具備服務執行權限。
確認政策與紀錄
依教學驗證允許與拒絕的工具呼叫，再查用量紀錄。原文對 pull-request 工具與寫入封鎖的敘述有張力，因此此處不保證所有建立 PR 操作皆會放行。
先選對 API，才開始接企業應用
以下路徑都接在工作區 URL 後面。呼叫 Model Service 時，模型欄位使用 catalog.schema.service 完整名稱；原生 API 還要對應底層模型的格式。名稱相近的 Responses API 不是同一個入口。
| 使用方式 | 路徑 | 適用條件 |
|---|---|---|
| 統一聊天介面 | /ai-gateway/mlflow/v1/chat/completions | OpenAI 相容的 MLflow Chat Completions，可用於跨供應商的模型查詢；仍須核對所選模型支援的參數。 |
| 統一 Embeddings 介面 | /ai-gateway/mlflow/v1/embeddings | 以 Model Service 名稱呼叫支援的 embedding 模型；向量索引的建置與同步另見 RAG 章節。 |
| OpenAI 原生 Responses | /ai-gateway/openai/v1/responses | 底層必須是支援此格式的 OpenAI（GPT）模型。 |
| Anthropic 原生 Messages | /ai-gateway/anthropic/v1/messages | 對應 Claude 模型；使用 Messages 請求格式。 |
| Gemini 原生 API | /ai-gateway/gemini/v1beta/models/<model-service>:generateContent | 對應 Gemini 模型；服務名稱放在路徑內。 |
| 直接呼叫 Model Provider Service | 使用該供應商支援的 managed path | 以 Databricks-Model-Provider-Service header 指定服務，模型欄位使用供應商的模型名稱；不要與 Model Service 的呼叫方式混用。 |
Supervisor API 已公告退場
/ai-gateway/mlflow/v1/responses 是 OpenResponses 相容的 Supervisor API。查詢總覽仍列為 Beta，但專頁已公告 2026 年 9 月 30 日終止服務，並建議移轉到 Databricks Apps 的 custom agents。本頁 POC 使用 Chat Completions；既有應用應依退場公告盤點移轉。Model Serving 的 /serving-endpoints/open-responses 是另一個入口，詳見API 相容性與治理範圍。
經過 Gateway 的不同路徑，治理能力也不同
啟用 Model Provider Service 的 Forward all URL paths 後，可將未列入 managed paths 的請求原樣轉送。這類 passthrough 不套用 token／成本追蹤、TPM 限制、模型存取控制或 Service Policies。另外，ai_query 批次推論不套用速率限制、防護、inference logging 與備援；用量追蹤及預算涵蓋範圍見批次推論說明，不能拿它替代線上 API 的治理驗收。各入口的正式整合還需核對格式與後端配額。
06 / 企業導入地圖
企業窗口需要的導入知識
先釐清平台角色、環境、身分與資料流，再進入實際 POC。
本頁涵蓋 Unity Gateway 導入的共同基礎與驗證路線。雲別、區域、合約與個別工作負載仍須依企業條件核對；下方將官方能力與本站整理的分工、驗收建議分開說明。
企業導入交付清單：每一項都要有負責人與證據
以下是本站依官方企業平台規劃與本手冊各章整理的工作清單；企業自行訂定驗收門檻。每項記錄負責人、環境、設定版本、驗證日期與證據連結；未採用的選用功能註明原因。
8 項導入交付清單（本站整理）
| 要定案的事項 | 應完成的交付 | 操作依據 |
|---|---|---|
| 場景與治理入口 | 列出客戶端、模型／MCP、是否經過 Gateway，以及例外路徑。 | API 選擇、批次界線 |
| 環境與資料流 | 雲別、區域、workspace／metastore、bindings、出入站網路及資料處理地點。 | 環境與資料邊界 |
| 身分與最小權限 | 員工、app、owner 與後端執行身分；授權、輪替及離職拒絕證據。 | 身分生命週期 |
| 政策與敏感資料 | 覆蓋格式、輸入／輸出階段、誤判與逾時行為、紀錄讀者及保存規則。 | 政策工程、紀錄治理 |
| API、容量與品質 | 真實 SDK 的相容性、後端配額、版本基準及降級後的品質。 | 模型工程 |
| 資料與 Agent 延伸 | 若有 RAG／工具：同步新鮮度、刪除與越權案例、評估資料集。 | RAG 與 Agent |
| 用量、成本與告警 | 費用歸屬、預算覆蓋／排除項、告警執行者及通知失敗處理。 | 成本、營運交接 |
| 上線、變更與復原 | 版本化設定、部署後正反測試、前一版回復、跨區重建與 RTO／RPO。 | 部署與復原 |
先分清楚要導入平台的哪一段
Databricks 的資料處理、模型推論與 AI 治理各有角色。企業可以先完成一個明確場景，再依需求擴充；本指南聚焦 Unity Gateway 導入所需知識，完整資料工程與平台管理仍應搭配各產品官方文件。
接入資料Lakeflow Connect連接檔案、應用程式與資料庫
儲存資料Delta Lake具交易紀錄的資料表
處理資料Lakeflow pipelinesSQL／Python 批次與串流處理
安排工作Lakeflow JobsTasks、相依性與觸發條件
查詢分析SQL warehouse執行 SQL 的運算資源
模型與治理Model Serving · Gateway提供推論、治理模型與工具呼叫
元件與 Gateway POC 的關係
| 工作 | 主要元件 | 和 Gateway POC 的關係 |
|---|---|---|
| 把來源資料帶進平台 | Lakeflow Connect | 連接檔案、應用程式與資料庫；建立知識庫或資料分析場景時再依來源評估。 |
| 儲存與更新資料表 | Delta Lake | 提供具交易紀錄的資料表儲存基礎；Gateway 的紀錄表也需要資料治理。 |
| 清理、轉換與同步資料 | Lakeflow pipelines | 以 SQL／Python 定義批次或串流處理；適用有資料管線的延伸場景。 |
| 排程與串接工作 | Lakeflow Jobs | 安排 tasks、相依性與觸發條件；管線可成為工作的一個 task。 |
| 執行 SQL 與報表 | SQL warehouse | 是查詢運算資源；可查系統表與製作分析，另需運算及資料權限。 |
| 提供模型、管理呼叫 | Model Serving／Unity Gateway | 前者提供模型推論；後者把模型與工具呼叫接入統一權限、政策及用量管理。 |
模型治理 POC 可以從小範圍開始
官方 Coding Agent 教學的前置是已啟用 Unity Catalog 的工作區、可執行的 Model Service、已登入的 Databricks CLI 與工作區網址，並未要求先搬移全公司資料。依這個教學範圍，可以先驗證模型存取、限流與用量；加入 RAG、資料管線或自訂模型時，再補上相應資料與運算準備。
從共同入口看整個平台
Unity Gateway 治理經過它的模型與工具呼叫；Unity Catalog 提供資產、權限與治理基礎。以下依官方能力整理關係，不代表每個情境都要啟用全部服務。
使用端Coding Agents · 內部應用 · 自建 Agent
Unity Gateway模型與 MCP 入口 · 使用政策 · 用量與成本控制
執行端Databricks 模型 · 外部模型供應商 · MCP 工具
Unity Catalog ＋ 企業身分資產權限、群組與服務主體
紀錄與營運System tables / traces → SQL 分析、儀表板與告警
應用加入 MLflow Tracing → 除錯、評估與品質監控
應用加入 MLflow Tracing → 除錯、評估與品質監控
依使用情境選擇閱讀路線
三種情境的閱讀順序
| 需求 | 先了解 | 按需求延伸 |
|---|---|---|
| 讓員工的 Coding Agents 共用入口 | 身分與群組 → 模型權限 → 用量、費用與預算 | MCP 工具授權、trace 存取與保留 |
| 自建 AI 應用或 Agent | 共用入口與身分 → 應用部署 → MLflow Tracing | 評估資料集、scorers、Production monitoring |
| 公司知識庫與 RAG | 資料治理 → AI Search 索引與同步 → 應用身分 | 檢索品質、來源更新與存取範圍 |
上表是閱讀順序建議。AI Search 文件明載不支援資料列與欄位層級權限，不能假設資料表的細粒度權限會直接套用到搜尋索引。
把治理範圍落到實際環境
尚無環境？企業試用與工作區建立步驟
公司還沒有 Databricks 環境時
- 先選企業評估環境：確認雲端、區域與方案；官方 business free trial 可用於商業評估。Free Edition 定位為個人、非商業用途，使用條件不同，不能直接當成企業正式環境。
- 由帳戶管理員建立工作區：AWS account console → Workspaces → Create workspace。Serverless workspace 需支援區域，選 Use serverless compute and default storage，由 Databricks 管理基礎設施；classic workspace 則部署於企業 AWS 帳戶，自動配置路徑另需 AWS 管理權及 VPC／NAT 等配額。
- 確認可用後再配權：工作區狀態為 Running 後，確認 metastore、指派測試身分與模型權限，再檢查 Gateway、目的模型及要測的附加功能。試用不代表所有功能與區域均可用。
Account 帳戶可包含多個工作區
Workspace 工作區連接同區域的 Unity Catalog metastore
Metastore 資產目錄
Catalog → Schema → Object資料表、模型與服務等採三層名稱
儲存憑證等物件直接位於 metastore 下。company_poc.ai.coding_model 為三層名稱示例，並非官方固定命名。
AWS 的 Unity Catalog 初始設定文件要求 Premium 或以上方案。先確認既有工作區：帳戶管理者可在 account console 的 Workspaces 查看 Metastore 欄；有 UC 相容運算的人也可執行 SELECT CURRENT_METASTORE();。查到 metastore ID 才是啟用狀態的具體證據，不必因為要做 POC 就重新建立整套環境。
已綁定的工作區檢查使用者權限仍需具備資產授權
依授權存取
未綁定的工作區即使使用者已獲授權
拒絕存取
一般 catalog 預設可由同 metastore 的工作區存取；自動建立的 workspace catalog 預設只綁定自己的工作區。
窗口先找齊哪些管理者？
下表是依官方管理權限整理的協作分工，企業可由同一人兼任；不是 Databricks 規定的組織編制。確認負責人與權限後，再進行 POC 的允許、拒絕及成本測試。
管理者分工與交接資訊（本站整理）
| 協作對象 | 需確認的管理範圍 | 交給 POC 的資訊 |
|---|---|---|
| 帳戶與企業身分管理者 | Account、SSO、群組同步、workspace assignment 與管理角色。 | 方案、目標工作區、測試人員及群組；需要啟用的預覽功能。 |
| 工作區與資產管理者 | Workspace、catalog/schema、Model Service、擁有者與資產 grants。 | 服務完整名稱、允許使用者、未授權測試身分、紀錄位置及讀取權。 |
| 雲端與網路管理者 | 進站管制、serverless 出站政策、內部服務與私有連線。 | 公司端到 Gateway、Gateway 到模型／MCP 的可達路徑與目的地。 |
| 應用、資安與成本負責人 | 應用驗證方式、資料分類、成本分析、保留期限與營運指標。 | 核准測試資料、需查驗的紀錄、預算與驗收門檻。 |
Account admin、workspace admin、metastore admin 是不同角色。Metastore admin 在平台上是選配，但統一追蹤等個別功能可能要求它；不要把一般測試人員一律設成管理者。
內部應用與排程使用 service principal：建立或確認程式身分、workspace assignment 與資源 grants，再依執行環境選擇 workload identity federation 或 OAuth M2M。若採 M2M，設定正確的 workspace host、client ID 與 OAuth secret，並使用支援 unified authentication 的工具／SDK 更新 token；取得 token 不會額外授予 Model Service 執行權。詳見身分生命週期。
逐段確認網路與資料會經過哪裡
進站公司電腦／應用Proxy、DNS、HTTPS
工作區進站規則Databricks連線後仍需身分與資產權限
對外出站Serverless網路政策
Restricted Access外部模型／MCP允許實際目的地 FQDN
私有連線 · AWSServerlessNCC ＋ PrivateLink
NLB公司 VPC 內服務確認端點建立並連接工作區
出站控制與此私有連線路徑需 Enterprise。私有連線另需帳戶管理權、支援區域，且 NCC 與工作區需同區；網路可能另計費。
選定模型後，另外確認資料處理地理範圍：Foundation Model APIs 可能在來源工作區之外的區域或雲端處理，依模型與 Databricks Geos 而定。付費 Model Serving 的「不拿輸入／輸出訓練模型」不等於零保留；防濫用保留、合作模型供應商條件，以及公司自行記錄的 traces／inference tables，應分別評估。
先看個別功能的成熟度
Beta評估階段不適用正式環境；不保證介面穩定或 SLA
Public Preview可用於正式環境介面穩定，提供 SLA
GA正式推出完整支援，適用正式環境
預覽功能不在合規認證涵蓋範圍內；啟用 compliance security profile 的工作區僅支援特定預覽功能。仍須核對個別文件、預覽開關與工作區條件。
從 POC 走向正式環境，要留下哪些證據？
官方企業規劃涵蓋平台架構、網路、儲存、IaC、運算、可觀測性與高可用／災難復原。以下是據此整理的交接項目；正式門檻、測試時程與容許成本由企業定義，並非官方統一驗收標準。
- 環境與權限：記錄核准的雲端／區域、catalog binding、服務擁有者與執行身分，並保留允許及拒絕案例。
- 資料與營運：記錄模型處理區域、內容保存／讀取規則、費用來源、預算設定、查詢／告警的負責人。
- 應用與回復：保留實際客戶端相容性、延遲與品質結果，文件化失敗處理及回復方式；依使用功能的成熟度決定是否適合正式流量。
- 可重現部署：平台基礎設施可用 Terraform；資料與 AI 工作負載可用 Declarative Automation Bundles。先核對具體資源是否支援，不能以設定檔通過檢查取代實際權限與連線驗證。
管理者總覽：Governance Hub Beta
提供帳戶層級的資料治理、AI、成本與標籤視圖；由帳戶管理員在 account console 的 Previews 啟用，首次資料載入可能需要一天。它沿用既有權限，不負責授予資料存取權：帳戶管理員可看完整資料、AI 與成本頁，工作區管理員可看所屬工作區的成本，metastore 管理員可看所屬 metastore 的資料頁。
07 / 企業 POC 實作
在企業內部，跑完一次可驗收的 Unity Gateway POC
從環境準備、授權呼叫到紀錄驗收，依下方步驟閱讀。路線與驗收表是本站依官方功能整理，門檻由企業定義。
先確認測試範圍與功能狀態
範例服務 poc_ai.gateway.team_chat、workspace 與模型須替換；命令已依官方欄位核對，未在你的租戶執行。Service Policies、Unified Trace、Smart Routing 與外部模型預算各有獨立 Beta 條件，Beta 不適用正式環境。
步驟 1：指定窗口與驗收範圍
先記錄用途、資料範圍、選用模型、呼叫者、費用歸屬、紀錄讀者與結案後保存方式。將模型品質、延遲、錯誤率及費用門檻寫進企業自己的測試計畫；下表把官方權限要求整理成可分工的工作。
| 角色 | 要完成的工作 |
|---|---|
| 帳戶／工作區管理員 | 確認工作區、身分與 entitlement；在各自管理範圍啟用所需 preview、建立預算與告警。 |
| Metastore 管理員／資產管理者 | 準備 POC catalog/schema 與授權；若採統一追蹤，由 metastore 管理員設定。 |
| Model Service 擁有者 | 建立服務與後端、設定限流及政策，持續保有後端模型與 provider 的權限。 |
| 應用、安全與成本窗口 | 分別驗證呼叫、權限隔離、紀錄可見性、費用與品質；整理證據並決定是否擴大。 |
步驟 2：確認環境、地區與功能狀態
- 取得已啟用 Unity Catalog 的企業 workspace，核對 Gateway、模型及資料處理區域。模型出現在
system.ai不等於此工作區能呼叫；到 AI Gateway UI 確認。 - 為測試者設定 Workspace access；若採 Consumer access，還需帳戶啟用 Consumer access to Unity Gateway Public Preview。
- 準備 POC catalog/schema、管理者、獲授權測試者，以及沒有服務權限的有效測試身分。預先取得查詢用量表或儀表板的權限。
- 核心 Gateway 已 GA；service policies、unified trace、Smart Routing 與外部模型納入預算各有獨立 Beta 條件，按實際測試範圍請對應管理員在 Previews 啟用。Beta 依官方規則不適用正式環境。
步驟 3：建立專用服務，按需要加入外部供應商
在 AI Gateway > Create 選擇 POC catalog、schema、服務名稱及 primary destination；也能由 Catalog Explorer 的 Create > Service > Model service 建立。建立者需要父層 USE CATALOG、USE SCHEMA、CREATE SERVICE，以及目的模型的 EXECUTE。Model Service 目前不支援以 SQL 建立或管理。
需要 BYOK：先從 AI Gateway > Providers > Provider 建立 Model Provider Service，選供應商、模型與連線設定，輸入企業核准的供應商憑證，再將它選為 Model Service 的目的地。憑證由 Databricks 加密保存；一般呼叫者使用 Databricks 身分，不取得供應商金鑰。MCP 使用的 HTTP connection 是另一種物件，見步驟 9。
控制要設定在應用實際呼叫的入口
Model Service 路由到 Provider Service 時，只套用前者的 Gateway 功能；後者自行設定的限流、防護、inference logging 與 fallback 會被跳過。因此本 POC 將控制設定在 poc_ai.gateway.team_chat。
步驟 4：授權，再用兩個身分做正反測試
在 Catalog Explorer 給試驗群組父層 USE CATALOG、USE SCHEMA，再於服務 Permissions > Grant 授予 EXECUTE。自建服務預設僅 owner 能呼叫；system.ai 系統服務預設對所有 account users 開放，不能將兩者混為一談。
- 以獲授權的測試者 A 執行步驟 5，確認成功。
- 以有效但沒有服務
EXECUTE的測試者 B 呼叫同一服務，確認拒絕；不要只改模型名稱當作更換身分。 - 撤銷 A 的權限，再次驗證；記錄異動時間。官方指出權限及 service policy 變更可能需數分鐘傳播，並須檢查群組或父層繼承。
服務以 owner 權限存取後端，caller 不需直接取得後端權限。Owner 必須持續保有所有 primary/fallback destinations 的必要權限；權限測試應包含此相依性。
步驟 5：用 OAuth 發送第一個可追蹤請求
先安裝官方 Databricks CLI。人員操作使用 OAuth U2M；背景程式採 service principal 的 OAuth M2M 或適用的 token federation。以下範例需 curl、Python 3 與支援 Chat Completions 的模型；先替換 workspace URL 與服務名。128 是示範輸出上限，不是通用模型預設。
程式碼可左右捲動。
databricks auth login --host 'https://<workspace-url>' --profile ug-poc
databricks auth describe --profile ug-poc
export DATABRICKS_TOKEN="$(databricks auth token --profile ug-poc | python3 -c 'import json,sys; print(json.load(sys.stdin)["access_token"])')"
curl --silent --show-error \
--dump-header poc-response-headers.txt \
--output poc-response.json \
--write-out '%{http_code}\n' \
'https://<workspace-url>/ai-gateway/mlflow/v1/chat/completions' \
-H "Authorization: Bearer $DATABRICKS_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Databricks-Ai-Gateway-Request-Tags: {"project":"unity-gateway-poc","environment":"poc"}' \
--data '{"model":"poc_ai.gateway.team_chat","max_tokens":128,"messages":[{"role":"user","content":"請用一句話介紹資料治理。"}]}'
unset DATABRICKS_TOKEN這是依官方登入、OAuth 與查詢文件組合的範例。保存 HTTP status、回應與可取得的 request ID；不要保存 token 或 Authorization header。切換 A／B 測試身分前先清除 DATABRICKS_TOKEN，再以該測試者登入，避免沿用環境中的另一個身分。databricks auth token 只支援 U2M，不適用 M2M。
若測 coding agent，依官方教學安裝 Unity Gateway CLI 後執行 ug codex 或 ug claude，完成 OAuth 並送出測試 prompt；接著同樣查用量紀錄，確認客戶端實際路徑。
步驟 6：測試速率限制、告警與預算封鎖
在服務 overview 的 Rate limits 設定服務級與每人 QPM／TPM。用企業核准的試驗流量確認超限回傳 429、client 採指數退避，及容量恢復後可重試。短暫 burst 可能超出設定，不以「每一個瞬間絕不超量」作為驗收條件。
帳戶管理員由 Account console > Usage > Budgets > Add budget 建立預算，指定工作區、Unity Gateway resource type 與服務標籤，設定通知及 Block usage。若以標籤篩選，先將該標籤設在 POC Model Service。工作區管理員可使用 Governance Hub 的 Cost 頁管理其工作區預算，但須先由帳戶管理員啟用 Governance Hub Beta。用核准的測試金額驗證告警、封鎖及調高額度後恢復。
BYOK 須先啟用工作區 External Model Spend in Budgets Beta，再勾選 Include external model usage。預算匹配依服務標籤，步驟 5 的 request tags 用於分析；預算不涵蓋 provisioned throughput 或未經 Gateway 的直接呼叫，也不保證最終帳單絕對封頂，進行中的請求不會被中斷。
步驟 7：把同一批 POC 呼叫找回來
由管理員授予用量表讀取權限或提供 Usage Dashboard。先檢查 schema，再依服務、時間與 request tags 尋找步驟 5 的請求；時間窗可依試驗調整。
程式碼可左右捲動。
DESCRIBE TABLE system.ai_gateway.usage;
SELECT event_time, endpoint_name, requester, status_code,
request_id, invocation_id, request_tags,
total_tokens, latency_ms, destination_name, routing_information
FROM system.ai_gateway.usage
WHERE endpoint_name = 'poc_ai.gateway.team_chat'
AND event_time >= current_timestamp() - INTERVAL 1 DAY
AND request_tags['project'] = 'unity-gateway-poc'
AND request_tags['environment'] = 'poc'
ORDER BY event_time DESC;以上依官方 usage schema 使用 endpoint_name；部分教學範例仍寫 service_name／service_type，請以實際表結構核對。一個 request 可能有多個 invocation，不能直接把所有紀錄列數當作外部請求數。
需要檢視內容時，在服務 Inference tables > Set Up 選專用 catalog/schema，讓平台建表；設定者需服務 MANAGE，以及目標 catalog/schema 的 USE CATALOG、USE SCHEMA、CREATE TABLE。若目標 catalog 使用 default storage，還需工作區管理員啟用 Zerobus Ingest Default Storage 預覽。先安排紀錄讀者與保存政策。若企業接受 Beta，也可由 metastore 管理員設定 AI Gateway > Govern > Traces > Set up tracing，但它涵蓋同 metastore 的所有工作區與服務，須一併確認可見範圍。
Inference logs 首次可能需一小時出現，透過 Zerobus 以 at-least-once 交付，可能重複；401、403、429、500 可能缺錄，過大 payload 也不記錄。失敗測試須同時留存 client 結果。成本另核對 Databricks 計費用量與外部 provider 估算，詳見使用追蹤、成本與告警及紀錄與可觀測性。
步驟 8：加入政策，分別驗證輸入與輸出（Beta）
帳戶管理員啟用所需 Unity Gateway Beta 後，在服務 Policies > New policy 選內建 guardrail，設定 rank、支援的 Input／Output 階段，保留 All account users 並透過專用服務的 grants 隔離 POC。官方設定步驟與限制對 custom principals 的說明尚不一致，因此不將自訂適用對象列為本路線前提。
附加自訂政策需服務 MANAGE 及 policy function EXECUTE；建立自訂 UDF 另需 CREATE FUNCTION。內建政策依各自專頁設定：例如 Beta 的 Sensitive Data Detection 由平台管理，沒有可另授予的函式 EXECUTE。自訂 SQL function 沒有 Phase 選項，須以 event:type 區分 request 與 response；可依官方範例測虛構機密代碼與輸出 URL。
LLM judge 政策先以 Log 模式觀察，並在 evaluator model service 啟用 inference table，確認判定後再切 Enforce。flagged=true 只代表 judge 判定；實際阻擋須檢查 caller 回應。DENY 可回 HTTP 200，並以 databricks_service_policy 呈現原因，不能只看非 2xx。用正常 prompt 做對照，保留政策名稱、phase、模式與結果。
步驟 9：驗證路由與企業工具的受管路徑
多模型分支：在服務 Routing > Add another model 加目的地，讓權重總和為 100%，另設定 fallback 順序。用 destination_name 與 routing_information.attempts 確認流向；短樣本不保證精準符合比例，帶 session header 的同一 session 會固定目的地。只在受控試驗後端測 429／5xx 等失敗，確認 fallback 次序。
MCP 分支：自建外部 MCP server 須支援 Streamable HTTP，且可從 workspace serverless compute plane 到達。由 Catalog > Connections > Create connection > HTTP 建連線，再至 AI Gateway > MCPs > Register MCP Server 選 connection 與允許的 tools。官方建議 schema-level connection；只把 USE CONNECTION 給服務作者或管理者，避免一般使用者繞過 MCP Service 的控制。
建立新連線需 schema 的 CREATE CONNECTION；建立 MCP Service 則需 CREATE SERVICE、父層 USE 及該 connection 的 USE CONNECTION。呼叫者需指派至發出請求的工作區、服務 EXECUTE 及父層 USE；per-user OAuth 各自登入，而且需要 Workspace access，僅 Consumer access 無法完成此登入。以 tools/list 確認實際 tool schema，測允許的讀取與應被拒絕的操作。若使用 Databricks 預建的 system.ai.github，不用自行建 connection，可沿官方教學以 system.ai.github_policy 的 disallow_writes 驗證工具政策。
步驟 10：帶著證據結案，再決定移轉或清理
下表是本站依官方行為整理的紀錄格式；企業填入「通過／待處理／未納入」及證據連結。沒有執行的測項，不應填為通過。
| 測項 | 應保留的證據 |
|---|---|
| 入口與身分 | 請求路徑、服務完整名稱、模型、呼叫者、request tags 及相同時間範圍的用量紀錄。 |
| 權限隔離 | A 成功、B 拒絕、撤權後拒絕；註明傳播時間與群組繼承結果。 |
| 限流與預算 | 規則、429／重試恢復、告警及 Block usage 結果；確認預算範圍與估算限制。 |
| 紀錄與敏感內容 | request／invocation IDs、內容紀錄、讀者隔離與保存方案；註明缺錄、延遲及重複。 |
| 選用的政策／路由／MCP | 正反案例、阻擋原因、destination/fallback attempts，以及實際工具與身分。 |
| 費用、品質與維運 | 費用歸屬、企業測試集結果、功能發布狀態、資產 owner、告警與交接負責人。 |
準備正式導入：將身分、最小權限、網路、資料處理區域、紀錄保存與維運責任定案，再於正式範圍重跑相同驗收。可用官方 CLI／REST／SDK／Terraform 管理設定；Gateway 的 DABs resource 範例目前標示 Beta。POC 成功不會改變功能的發布狀態。
停止試驗：保存應留存的證據、停止客戶端與排程、撤銷試驗授權；移除政策後才刪除不用的自訂 policy functions。先停用試驗專用 inference logging，再依保存決策處理其獨立表；刪除 service 不會一併刪表。只刪除試驗專用服務、provider／MCP connection、預算與暫存憑證，不停用仍共享的 metastore trace 或 evaluator logging。system.ai 系統服務不能刪除。
程式碼可左右捲動。
# 只有確認為本次 POC 專用物件後才執行
databricks ai-gateway delete-model-service model-services/poc_ai.gateway.team_chat --profile ug-poc-admin
databricks auth logout --profile ug-poc --delete上例 ug-poc-admin 是管理者另行完成登入的 profile；刪除 Model Service 需要 owner 或 MANAGE。登出 U2M profile 不等於撤銷 provider 的外部憑證；各資源須依實際使用方式處理。
遇到問題時，先查哪一層？
以下依官方前置條件與限制整理排查順序；保留回應內容、時間與 request ID，比只記「連不上」更能定位問題。
| 現象 | 查核順序與依據 |
|---|---|
| 已登入，卻無法呼叫服務 | 核對實際呼叫身分、工作區 entitlement、父層 USE、服務 EXECUTE、owner 的後端權限，以及授權傳播時間。授權及 owner 權限 ↗ |
| 不支援參數／找不到模型 | 先對照API 選擇表確認 native 格式與模型家族；再確認 Model Service 完整名稱、region／cross-geo 可用性。查詢格式與前提 ↗ |
| HTTP 200，但內容被阻擋 | 檢查 databricks_service_policy、phase 及 Log／Enforce；政策 DENY 不一定是非 2xx。政策判定除錯 ↗ |
| 429 或分流比例異常 | 限流採指數退避；路由另查 session affinity 及 routing_information.attempts。不要把所有 4xx 都視為一定會 fallback。限流行為 ↗路由與備援判讀 ↗ |
| 找不到紀錄或 SQL 欄位不存在 | 先 DESCRIBE、核對工作區／服務／時間窗／tags、SELECT 權限及新表交付延遲；401／403 等失敗也可能沒有 inference log，應比對客戶端證據。交付與缺錄限制 ↗ |
| MCP 到不了公司內部服務 | 分別檢查每人 OAuth、serverless 出站 FQDN 與私有連線；遭拒絕連線可查 system.access.outbound_network。MCP 網路診斷 ↗ |
08 / 環境、網路與資料駐留
共用服務之前，先畫清楚網路與資料邊界
治理範圍在哪裡共用？Model Service 可供同 metastore 的工作區使用；仍受 workspace bindings 約束。
網路路徑能不能連到？進入 workspace 的 ingress，與外部 MCP 的 serverless egress，分別受網路政策控制。
資料處理在哪裡推論？核對模型、Databricks Geo 與 cross-Geo 設定；Geo 可包含多個區域。
AWS 網路設定須依實際路徑驗證。Context-based ingress 需 Enterprise；private endpoints、account-level policy 與跨 workspace access 的相關控制仍有 Beta 條件。
四種網路路徑、限制與驗證紀錄
| 路徑 | 官方控制與限制 | 本站整理的驗證方式 |
|---|---|---|
| 公司／應用進入 workspace | Context-based ingress 依身分、來源與 API/UI 類型判斷，需 Enterprise；與 IP access lists 同時使用時，兩者都需允許。對 private endpoints 套用 context-based ingress policy、account-level ingress policy 與 cross-workspace access 目前為 Beta；此狀態不代表所有 PrivateLink 能力的成熟度。 | 先 dry run，查看 system.access.inbound_network；account-level policy 的拒絕目前不記錄，另保留 client 結果。 |
| Gateway 呼叫外部 MCP | Restricted 出站政策需允許 MCP 實際網域；內建 SaaS MCP 也適用。MCP 的 dry run 只有選 All products 才涵蓋。 | 從 connection URL 開始列網域，再查 system.access.outbound_network 找額外被拒絕主機；工具 EXECUTE 與網路允許各自測試。 |
| AWS serverless 到公司私有 MCP | 可經 NCC、PrivateLink 與 NLB；NCC 和 workspace 必須同區。NLB 目的地支援同區／跨區，跨區有額外條件；PrivateLink 網域會隱含加入網路允許清單。 | 確認 endpoint 為 ESTABLISHED、NCC 已附加；核對 URL 主機符合 rule，並確認未使用不支援的 DNS chasing／redirect。 |
| Workspace A 的 serverless 到 B API | 跨 workspace access 為 Enterprise Beta；在 Restricted 模式需要來源 egress 與目的 ingress 共同允許。只適用 serverless，不支援跨雲。 | 分別記錄兩側政策與 workspace ID，不能只用共用 metastore 證明網路可達。 |
資料駐留設定，需由帳戶管理者實際核對
Databricks Geo 可包含多個區域。官方文件指出，US／EU 之外、未啟用 compliance security profile 的工作區，預設開啟 cross-Geo processing。帳戶管理者應在工作區的 Security and compliance 檢查 Enforce data processing within workspace Geography for Designated Services，再對照所選模型與 Designated Services 表；不要只從工作區所在地推論 prompt 處理地點。
推論內容、紀錄與身分資料的保留邊界
資料審查至少分開推論內容、追蹤／紀錄、身分與中繼資料。付費 Model Serving 不使用輸入／輸出訓練模型，但 Foundation Model APIs 可能為防濫用在 workspace 區域保留內容最多 30 天，合作模型也有另外的安全保留條件。Compliance security profile 文件另載明身分與屬性會存於美國及有 workspace 的區域，且不應在名稱、tags 等自訂欄位放敏感資料；外部系統整合的法遵仍需企業逐項確認。
此處 AWS 網路步驟不能直接替代 Azure／GCP 的部署方式。資料流程表與正反測試是本站整理的驗收方法；實際核准範圍仍須使用對應雲端、區域、模型與功能狀態的官方文件。
09 / 身分生命週期與交接
從登入成功，走到可持續管理的企業身分
建立、授權、輪替、離職與交接，都需要能重複驗證的流程。
SSO 負責使用者登入；身分同步負責人員與群組資料；workspace assignment、entitlement 與 Unity Catalog grants 決定能進入哪裡、執行什麼。官方建議透過帳戶群組授權，正式工作負載使用 service principal；以 SCIM 從 workspace 同步遷往 account 同步時，要停用舊 workspace SCIM connector。
OAuth：人員、背景程式與 CI/CD 的三種選擇
| 使用情境 | 官方機制 | 企業需補上的管理 |
|---|---|---|
| 人員使用 CLI／開發工具 | OAuth U2M；支援 unified authentication 的工具可自動更新一小時效期的 access token。 | 手動複製 token 的 client 仍需處理過期；勿把一次登入測試當作長期運作證據。 |
| 背景應用／排程 | Service principal OAuth M2M；可限制 OAuth secret 的 API scopes，scope 建立後不可修改。 | 分開應用身分、資源 grants 與 secret scope；更換 scope 時建立新 secret，驗證後撤銷舊憑證。 |
| 外部 CI/CD／執行環境 | Workload identity federation 以執行環境 JWT 換取 Databricks token，減少保存 Databricks secrets。 | 由帳戶管理者建立 federation policy，核對 issuer、audience、subject 與對應 service principal。 |
OAuth scopes 是 API 存取範圍，不能代替 EXECUTE 或父層 USE 權限。Gateway 管理 API 與實際呼叫路徑應分別核對；官方 API scopes 將建立／修改 Model Services 等操作列於 unity-catalog，不能直接把舊 Model Serving 的 scope 當成所有 Gateway API 的通用設定。M2M 的 authentication scope 能建立其他 scope 的 token，只應給需要管理憑證的整合。
Databricks Apps：誰能開啟應用，和代理用誰的權限執行？
CAN USE 允許開啟與操作 App；後端資源另按程式採用的身分授權。App authorizationApp 專屬服務主體Databricks 為每個 App 建立
後端存取依 App 權限執行使用者共用該服務主體獲授的資源權限
User authorization／OBO轉送使用者 tokenScopes 須經使用者或管理員同意，程式實際使用 token
後端存取依使用者權限與核准 scopes 執行表查詢適用該使用者的 UC 權限、row filters 與 column masks
OBO token 限 App 所在 workspace；資料表的 row filters 與 column masks，不代表外部工具也套用相同控制。
MCP 每人存取另需 ai-gateway user scope、實際使用者的服務 grants，以及首次外部 OAuth 同意。本站整理的驗收：以不同權限的人員比對表查詢、模型與 MCP 的實際呼叫身分和結果。
離職、停用與撤銷授權，需要分別處理
Automatic identity management 在 IdP 刪除人員後會停用其 Databricks 身分，但不自動撤銷 PAT；官方建議另行 revoke。U2M 的「撤銷應用 consent」也不會讓既有 token 立即失效，現有 refresh token 仍可能在到期前換取 access token。應把身分停用、token 撤銷與服務權限查核放進同一份交接流程。
本站整理的交接驗收：記錄 Model Service owner 與每個 primary／fallback destination 的 grants；人員異動或換 owner 後測試所有路由。模型服務使用 owner 的後端權限；失去任一引用 Provider Service 的 EXECUTE 會讓服務請求失敗。另以離職測試身分確認拒絕、以持續使用的程式身分確認成功，並記錄權限傳播所需時間。
10 / Microsoft AAD 串接實作
用 Microsoft Entra ID
登入 AWS Databricks
從兩邊要按哪裡、欄位要貼什麼，到人員同步與工作區授權，一步一步完成。Microsoft Entra ID 就是原本的 Azure Active Directory（AAD）。
本章怎麼使用
主線採 OIDC 登入 → Automatic Identity Management（AIM）→ 工作區授權 → 驗證。這是本站依雙方官方操作文件編排的閱讀順序；Databricks 官方建議使用 AIM 同步身分。已有 SAML 或 SCIM 的企業，可看本章末的替代流程。此處適用 Databricks on AWS，Azure Databricks 的租戶整合步驟需另讀 Azure 版文件。
下方圖片是官方文件原始截圖，可點擊放大；圖中的帳戶、名稱、ID 與 URL 都只是官方範例。本站未登入你的租戶執行設定，也未完成實際企業串接測試。
開始前：準備兩個管理入口
DATABRICKS / AWS
Account console
使用 account admin 登入。帳戶層級 SSO 與 AIM 都從這裡設定；只有 workspace admin 權限並不足以完成本章主線。
開啟 Databricks 帳戶主控台 ↗MICROSOFT / 同一個企業租戶
Entra 管理中心／Azure portal
準備可註冊應用程式、管理憑證與 claims 的身分，以及可核准 Microsoft Graph 應用程式權限的管理員。先確認右上角所選租戶正確。
開啟 Microsoft Entra 管理中心 ↗- AIM 前提：SSO 必須使用相同的 Entra tenant；工作區必須支援 identity federation。本章先完成同租戶 SSO，再啟用 AIM；若要在未配置 SSO 的情況下使用 AIM，或需跨租戶，官方要求聯絡 Databricks account team。
- 先盤點既有連線：若已使用 SCIM，先確認同步範圍與移轉計畫；同一批身分不要同時交由 AIM 和 SCIM 建立，以免重複帳號或權限衝突。
- 備妥測試資料：目標 workspace URL、既有管理員、一般測試使用者與測試群組。以下名稱如
Databricks-AWS-SSO是本站示例，可替換。
01
DATABRICKS
先保留管理員登入與緊急存取
- 保留目前已登入的 account console 視窗，再開另一個瀏覽器視窗執行測試。
- 前往 Security → Identity provider setup → Emergency access，選擇緊急存取使用者並按 Save；至少安排一位 account admin。
- 該使用者到 My preferences → Authentication，完成密碼重設，並在 Multi-factor authentication → Add key 註冊 FIDO2／WebAuthn passkey。官方建議至少一把硬體安全金鑰；TOTP 六位數驗證碼不適用此緊急入口。
完成後：保留可用管理員工作階段，以及已設定密碼與 passkey 的緊急帳號。
A. OIDC：讓公司帳號可以登入
這一段設定的是瀏覽器登入。後面仍須完成身分同步、工作區與資產授權。
02
DATABRICKS
取得專屬的 Redirect URL
- 在 account console 開啟 Security → Identity provider setup。
- 於 Authentication 區塊開啟 SSO 設定。
- 在 Add details → Identity protocol 選 OpenID Connect。
- 複製畫面上的 Databricks redirect URL，保留這個對話框。下一步要把它貼回 Entra。
要拿走的值：Databricks redirect URL。從自己的畫面複製完整網址，包含路徑與參數。
官方文件目前仍使用舊版對話框截圖：Save、Issuer URL、Username Claim 與現行正文的 Enable SSO、Authority URL / Issuer、User attribute claim 不同。導覽和按鈕依最新正文；redirect URL 一律從自己的 Databricks 設定頁複製。
點擊放大檢視 ↗來源：Databricks 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
03
MICROSOFT ENTRA
註冊一個 Web 應用程式
- 在 Azure portal 進入 Microsoft Entra ID → App registrations → New registration。Entra 管理中心可從 Entra ID → App registrations 進入。
- Name 填容易辨識的名稱，例如
Databricks-AWS-SSO。 - Supported account types 選 Accounts in this organizational directory only（單一租戶）。
- Redirect URI 的平台選 Web，貼入上一步的 Databricks redirect URL，再按 Register。
- 在 Overview / Essentials 複製 Application (client) ID。不要把 Object ID 當成 Client ID。
通用 Entra 註冊範例；example-app 和 contoso.org/exampleapp 並非 Databricks 的實際值。請輸入自己的名稱與 Databricks redirect URL。官方 quickstart 的新 UI 可能將帳戶類型改為下拉選單；以欄位意義及現行正文為準。
點擊放大檢視 ↗來源：Microsoft 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
完成後：有一個專用 app registration，以及它的 Application (client) ID。
04
MICROSOFT ENTRA
取得 Issuer 與 Client secret
- 在應用程式 Overview 點 Endpoints，複製 OpenID Connect metadata document 的 URL。
- 將 URL 最後的
/.well-known/openid-configuration移除，留下 Issuer。租戶 ID 與前面的路徑維持原值。 - 前往 Certificates & secrets → Client secrets → New client secret。
- 輸入描述、選到期時間，再按 Add。立即複製 Value；不要複製 Secret ID。離開頁面後無法再次查看完整 secret。
欄位轉換示例；請換成自己的 tenant ID
https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration↓ 移除最後一段https://login.microsoftonline.com/<tenant-id>/v2.0官方通用 Contoso-app 範例；側欄分類可能隨版本改變。圖中尚未產生 secret，未含可用認證資訊。期限依組織政策與官方文件設定。
點擊放大檢視 ↗來源：Microsoft 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
要帶回 Databricks：Client ID、Secret Value、Issuer URL。Secret 只貼到設定欄位，不放入網站、Git 或教學截圖。
05
DATABRICKS ↔ MICROSOFT ENTRA
填入欄位，確認使用者名稱的 claim
| Databricks 欄位 | 從 Microsoft Entra 取得的值 |
|---|---|
| Application (Client) ID / Client ID | 應用程式 Overview 的 Application (client) ID。 |
| Client secret | 剛建立的 client secret Value。 |
| Authority URL / Issuer / Issuer URL | OpenID metadata document URL 移除 /.well-known/openid-configuration 後的值。 |
| User attribute claim / Username Claim | 預設使用 email。如改用其他 claim，Entra 發出的 ID token 必須含該欄位，且 Databricks 端填入相同名稱。 |
若缺少 email，或公司需要自訂 username：在 Entra 的同一個 app registration 開啟 Token configuration → Add optional claim → Token type: ID，選需要的 claim（例如 email）並按 Add。若提示要啟用 Microsoft Graph email permission，依畫面勾選並新增；Databricks 的 User attribute claim 與之對齊。既有帳號需確認 claim 值與既有 username 一致。
AIM 啟用前，先核對 UPN／email 是否對應同一個人
AIM 在解析並建立租戶內成員時使用 UPN 作為 username；B2B guest 優先使用 email。SSO 登入則比對 token 中的 username。若 UPN 與 email 不同，或多個 Entra 物件共用 email，需先依官方身分對應規則確認 SSO claim、Databricks username 與 Entra 使用者一致，避免重複身分或套用錯誤權限。
Optional claim 會依 token 版本而不同；不要假設 upn 一定存在。這裡的登入 claim，與下一段 AIM 的 Graph application permissions 分屬不同設定。
06
DATABRICKS → MICROSOFT ENTRA → DATABRICKS
測試並啟用 SSO
- 確認登入用的管理員可以存取 Entra 應用程式；若 Entra 的 Assignment required? 設為 Yes，先在 Enterprise applications 的 Users and groups 指派測試者與管理員。
- 依目前 Entra SSO 專頁，在 Enable SSO 階段按 Enable SSO。
- Databricks 先以停用狀態保存設定，隨即執行連線測試；依跳出的 Microsoft 登入流程完成驗證。
- 測試通過才自動啟用。若失敗，回到原本保留的管理員視窗修正欄位，再重新測試。
官方介面版本差異
Entra 專頁已描述上述整合測試流程；SSO 總覽與官方原圖仍出現 Save → Test SSO → Enable SSO。若你看到分開的按鈕，就依序儲存、測試，成功後再啟用。圖片用來辨識欄位，按鈕順序請以實際租戶介面為準。
完成後：SSO 顯示啟用且測試成功。接著設定 AIM；單純 SSO 成功尚未完成工作區授權。
Entra 群組指派需 P1／P2，且應用程式群組指派不支援巢狀群組；這個限制與 AIM 支援巢狀成員同步屬於不同機制。
B. AIM：讓人員、群組與成員關係接上來
AIM 透過 Microsoft Graph 讀取 Entra 身分；它與 SSO 共用同一租戶。此段跟隨 Databricks AIM 專頁的逐步設定，使用前面建立的 SSO app registration。
07
DATABRICKS
取得 AIM 的 Issuer 與 Subject
- 前往 Security → Identity provider setup → Identity management。
- 在 Automatic identity management 按 Configure。
- 記下對話框顯示的 Issuer 及 Subject，保持此視窗開啟。
這組 Issuer／Subject 是 AIM federation 的輸入；不要拿前面 Microsoft 的 OIDC Issuer URL 來代填。
08
MICROSOFT ENTRA
新增 Federated credential
回到同一個 SSO app registration，進入 Certificates & secrets → Federated credentials → Add credential，逐欄設定：
| Entra 欄位 | 填入內容 |
|---|---|
| Federated credential scenario | Other issuer。 |
| Issuer | 第 7 步 Databricks AIM 對話框顯示的 Issuer。 |
| Type | Explicit subject identifier。 |
| Value | 第 7 步 Databricks AIM 對話框顯示的 Subject。 |
| Credential details → Name | 填可辨識的憑證名稱；例如 databricks-aim。其餘值依官方步驟保持不變，按 Add。 |
此圖只顯示通用建立入口，不包含 Databricks AIM 的 Other issuer 表單。Issuer 和 Subject 需使用自己 Databricks AIM 對話框的值，並依現行 Databricks 正文填寫。
點擊放大檢視 ↗來源：Microsoft 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
AIM 專頁開頭提到新 application，但其 Step 1–5 明確指向既有 SSO app。此處依逐步操作段落使用 SSO app；若租戶 UI 要求不同，應先向 Databricks 確認。
09
MICROSOFT ENTRA
新增四個 Graph Application permissions
- 在同一個 app registration 選 API permissions → Add a permission → Microsoft Graph → Application permissions。
- 逐一搜尋並勾選下面四個權限，再加入。
- 由有權限的管理員按 Grant admin consent，確認狀態已核准。只有新增到列表、仍顯示 Not granted，尚未完成。
| Application permission | AIM 讀取的內容 |
|---|---|
User.Read.All | 使用者與屬性。 |
Group.Read.All | 群組與屬性。 |
Application.Read.All | 服務主體。 |
GroupMember.Read.All | 群組成員關係。 |
此通用示例右側顯示 email 等委派權限，並非 AIM 所需完整設定。AIM 請選 Microsoft Graph > Application permissions，加入 User.Read.All、Group.Read.All、Application.Read.All、GroupMember.Read.All。
點擊放大檢視 ↗來源：Microsoft 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
Microsoft 通用範例用 Files.Read.All 展示按鈕位置；Files.Read.All 並非 Databricks AIM 所需，不要照抄。AIM 只依 Databricks 指定的四項 Graph application permissions 授權。
點擊放大檢視 ↗來源：Microsoft 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
完成後：四項皆為 Application 類型且取得租戶管理員同意；不能用 Delegated permissions 取代。
Graph 應用程式權限需要可核准的角色
Microsoft 列出 Privileged Role Administrator 或具備所需授權的自訂目錄角色可核准。Cloud Application Administrator／Application Administrator 的一般同意權限不涵蓋 Microsoft Graph application permissions。
10
MICROSOFT ENTRA
把群組 claim 加入 SSO token
- 在同一個 SSO app registration 選 Token configuration → Add groups claim。
- 依 Databricks AIM 步驟選 All groups，按 Add。
完成後：Token configuration 有 groups claim 設定。此步搭配前一步的 Graph 讀取權限。
11
DATABRICKS
測試連線，再啟用 AIM
- 回到 Security → Identity provider setup → Identity management → Automatic identity management → Configure。
- Client ID 填 SSO app 的 Application (client) ID。
- 按 Test connection。成功後按 Enable AIM。
- 官方說明設定約需 5–10 分鐘生效，再繼續驗證。
啟用 AIM 會一併開啟 JIT，且無法單獨關閉 JIT。群組成員變更在驗證／授權活動中更新，並非保證立刻反映所有變更。
完成後：AIM 連線測試通過，狀態已啟用。
C. 指派工作區，再做完整登入驗證
12
DATABRICKS
確認 Unified login 套用範圍
多數帳戶已預設套用 unified login：2023-06-21 之後建立的帳戶，或在 2024-12-12 前沒有設定 SSO 的帳戶，會套用到全部工作區且無法關閉。符合此情況可直接進下一步。
若是已有 workspace SSO 的舊帳戶：在 account console 的 Security → Identity provider setup → Unified login 選目標工作區；官方建議 All workspaces。有 inbound PrivateLink 的環境，先依官方額外設定完成網路配置。遷移時先讓原使用者可存取 account SSO app，測試工作區登入成功，再退役原 workspace SSO app。
13
DATABRICKS
把 Entra 群組指派給工作區
- 以 account admin 進入 Workspaces → 選擇目標 workspace → Permissions → Add permissions。
- 搜尋並選取要授權的 Entra 群組。
- 依工作需求選擇 workspace entitlements，按 Save。
- 或由 workspace admin 使用 Settings → Identity and access → Groups → Manage → Add Group 選取群組與 entitlements。
官方功能示意：候選群組帶有 In Microsoft Entra ID 來源標記。圖中 All Company 是範例名稱，實際請選擇自己的測試群組。
點擊放大檢視 ↗來源：Databricks 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
AIM 管理的群組成員請回 Entra 修改；工作區存取仍需上述指派。要使用 Unity Gateway 的模型／工具，也需對應 Unity Catalog 權限，接續閱讀身分與敏感紀錄治理及POC 權限步驟。
完成後：目標工作區的 Permissions 中可看到該群組及授權。
14
瀏覽器無痕視窗
測試一般使用者登入與身分
- 保留管理員視窗，另開無痕視窗，從 Databricks account console 輸入測試使用者 email，完成 Microsoft 驗證。
- 在右上角使用者資訊確認實際登入身分。
- 再開乾淨的無痕視窗，直接進入目標 workspace URL，完成相同登入流程並核對身分。
- 檢查指定群組與 workspace assignment；依需求驗證要用的模型／工具權限。這個資產驗收步驟是本站串接既有 POC 的編排。
完成標準：account 與 workspace 登入都成功、使用者身分正確、目標群組已指派、所需資產權限通過驗證。
替代流程：公司既有標準是 SAML 2.0
這是 A 段 OIDC 的替代路線。AIM／SCIM 是另一個同步選擇；完成 SAML 後仍需工作區授權與測試。
- Databricks：在 Security → Identity provider setup → Authentication 開啟 SSO，於 Add details → Identity protocol 選 SAML 2.0，複製 Databricks redirect URL（SAML URL）。
- Entra：進入 Enterprise applications → New application → Create your own application，輸入名稱，選 Integrate any other application you don't find in the gallery。
- 應用程式存取：Databricks 官方教學將 Properties → Assignment required 設為 No，代表租戶所有使用者可通過此應用登入檢查。若企業設為 Yes，需先在 Users and groups 指派管理員與使用者；工作區授權仍另行管理。
- SAML 基本欄位：開啟 Single sign-on → SAML → Basic SAML configuration → Edit。將 Identifier (Entity ID) 與 Reply URL 都填成 Databricks 畫面提供的 SAML URL。
- 簽章與身分：在 SAML Signing Certificate → Edit 選 Sign SAML response and assertion 與 SHA-256；在 Attributes & Claims 將 Unique User Identifier (Name ID) 設為
user.mail。 - 取得 Entra 資料：下載 Certificate (Base64)，以文字編輯器開啟
.cer，複製包含 BEGIN／END 標記的完整內容。另複製 Login URL 與 Microsoft Entra ID Identifier。 - 貼回 Databricks：依下表填妥，按 Enable SSO 完成 Microsoft 登入測試；成功後才啟用。接著選身分同步方式，並完成第 12–14 步。
| 設定位置 | 欄位 | 來源 |
|---|---|---|
| Entra | Identifier (Entity ID) / Reply URL | Databricks 提供的 SAML URL。 |
| Databricks | Single sign-on URL | Entra 的 Login URL。 |
| Databricks | Entity ID | Entra 的 Microsoft Entra ID Identifier。 |
| Databricks | x.509 certificate | Entra 下載的 Base64 certificate 完整文字。 |
兩邊都有名叫 Entity ID 的欄位，但來源方向不同；依上表填寫。
官方文件目前仍使用舊版對話框截圖：Save 與現行正文 Enable SSO 不同。圖中的模糊處理由官方原圖提供，本站未加工。URL 和憑證請使用自己的應用程式值。
點擊放大檢視 ↗來源：Databricks 官方文件 ↗ · 圖片權利屬原發布者 · 核對 2026-09-22
替代路線：使用 SCIM 同步使用者與群組
使用 SCIM 時，略過前面的 AIM 啟用步驟。Databricks 建議使用 AIM；此流程提供給選擇 SCIM 的組織。同一批身分不要同時由 AIM 與 SCIM 維護。SCIM 負責建立、更新與停用身分，登入仍需前面的 SSO。
Connector 名稱確實含 Azure：Databricks 的 AWS 官方文件明確指定 Azure Databricks SCIM Provisioning Connector。請依下列流程將它連到 AWS account URL。
- 確認角色與方案。Databricks 需 Premium 或以上方案與 account admin；Entra 需 Cloud Application Administrator。若以群組指派及同步，需相應的 Entra Premium 授權，Microsoft 的群組指派文件列為 P1/P2。
- Databricks：取得 account 同步憑證。開啟
Security → Identity provider setup → Identity management → Set up user provisioning（通用文件亦稱Enable user provisioning），複製 Account SCIM URL 與 SCIM token。AWS URL 格式為https://accounts.cloud.databricks.com/api/2.1/accounts/<account-id>/scim/v2/，以畫面複製值為準。 - Entra：新增同步用 Enterprise app。前往
Entra ID → Enterprise apps → New application，在 gallery 搜尋Azure Databricks SCIM Provisioning Connector，填名稱並按Add。這是同步用 connector，與前面的 OIDC app registration 用途不同。 - Entra：填入連線資料。開啟
Provisioning，Mode 選Automatic；在 Admin Credentials 將 SCIM API endpoint URL（有些介面標示 Tenant URL）填入剛才的 Account SCIM URL，Secret Token填入 Databricks SCIM token。按Test Connection，成功後Save。此處不可填 Entra client secret。 - Entra：核對 mapping 與同步範圍。在
Mappings檢查使用者欄位，Databricks 要求userName與emails.value一致。在Settings → Scope選Sync only assigned users and groups；再到Users and groups → Add user/group，選擇試用的使用者／群組並按Assign。先以少量成員驗證是本章的操作安排。 - Entra：啟動 provisioning。Databricks 官方建議
Properties → Assignment required = No；這個設定控制 app 登入資格，同步範圍仍由 Scope 與指派控制。回Provisioning，將Provisioning Status切為On並Save，開始 initial cycle。 - 兩端驗證。檢查 Entra provisioning 結果，並在 Databricks account 確認使用者與群組真的出現，再完成 workspace 指派。初次同步後的變更可能需等待排程；Databricks 文件列約 20–40 分鐘，Microsoft 通用文件列約 40 分鐘。
Test Connection成功本身不代表人員同步已完成。 - 既有 workspace SCIM 的切換。先確認新的 account connector 同步成功，再停用舊 workspace connector；不要先從舊 connector 移除成員，因為移除可能觸發停用。此處是 workspace SCIM 改為 account SCIM 的流程。
限制要一併確認：此 connector 不同步巢狀群組（nested groups）或 Entra service principals，Entra 群組更名也不會同步；從 account SCIM app 移除使用者會停用其 Databricks account 與 workspace 存取。SCIM token 僅能呼叫 account SCIM API。
卡在哪裡，就回頭檢查哪一層
| 症狀 | 先檢查 |
|---|---|
| Redirect URI mismatch | 比對 Entra 的 Web Redirect URI 與 Databricks 顯示的完整值，包含大小寫、路徑及參數。 |
oidc_metadata_fetch_failure | Issuer 是否多留了 /.well-known/openid-configuration；metadata 及其端點需可公開存取。 |
oidc_code_exchange_failure | Client secret 是否填成 Secret ID、是否已過期；Client ID 與 secret 是否屬於同一 app。 |
oidc_missing_email_claim | ID token 是否含 email 或指定的 username claim；回第 5 步檢查 Token configuration。 |
oidc_state_missing | OIDC 不支援 IdP-initiated 登入；改從 Databricks account／workspace URL 開始，並查 state 回傳。 |
| AIM Test connection 不通過 | 核對 Client ID、federated Issuer／Subject、四項 Graph Application permissions 與 admin consent。 |
| 登入成功，但沒有目標工作區 | 確認 unified login、workspace assignment 及 entitlements；SSO 或同步成功不會自動授予所有 workspace。 |
| 群組變更還沒出現 | AIM 的 browser login 在距上次同步超過 5 分鐘時刷新；其他活動的刷新有不同排程。新啟用先等官方所述 5–10 分鐘。 |
| SCIM 舊成員仍留著／重複使用者 | AIM 不會自動清掉既有 SCIM 同步成員；依官方遷移說明處理 externalId 與殘留關係，避免兩套機制同時建人。 |
| 管理員被鎖在外面 | 使用已配置的 emergency access；若未事先配置且已無法登入，官方指示聯絡支援。 |
Databricks：OIDC 與錯誤排查 ↗Databricks：Entra ID AIM 設定 ↗Databricks：AIM 行為與限制 ↗Databricks：Unified login ↗Databricks：群組與工作區授權 ↗Databricks：緊急存取 ↗
後續維護：到期、停用與交接
- OIDC client secret：記錄到期日；輪替後更新 Databricks SSO 的 secret 並重新測試。若已啟用 AIM 的 federated credential，仍不能因此忽略 OIDC 登入使用的 client secret。
- 使用者停用：依 AIM 官方身分狀態與同步時機驗證停用結果；官方另建議撤銷已停用或從 IdP 移除人員的 PAT。
- 停用 AIM：現有使用者／服務主體仍留在 Databricks，群組成員關係會移除且不再跟隨 IdP 更新。需要改回 SCIM 時，依官方停用與遷移說明規劃交接。
- 緊急登入：已配置的 account admin 可使用
https://accounts.cloud.databricks.com/login/mfa?account_id=<account-id>，以密碼與 passkey 登入；換成自己的 account ID。
11 / 身分與敏感紀錄治理
身分與敏感紀錄治理
讓適合的人，看見適合的紀錄。
身分管理補充：SSO、同步與 OAuth
Databricks 身分分成 users、groups 與 service principals。官方建議將權限配置給群組，並使用服務主體執行正式環境工作負載，減少對個人帳號的依賴。
| 能力 | 用途 | 導入時確認 |
|---|---|---|
| SSO 與 unified login | 由企業身分供應商管理登入。 | 登入政策與緊急存取程序。 |
| Automatic identity management／SCIM | 同步企業人員與群組。Microsoft Entra ID 與 Okta 的 automatic identity management 均已 GA。 | Automatic identity management 需 identity federation；服務主體與巢狀群組同步僅支援 Entra ID。不支援的身分供應商可使用 SCIM。 |
| OAuth | 供 CLI、SDK、應用取得授權。 | 官方建議 OAuth 優先於 PAT；個人與無人值守流程分開設計。 |
狀態以具體發布說明為準：Entra ID 於 2026-05-26、Okta 於 2026-07-03 宣布 GA；驗證總覽仍保留 Public Preview 字樣。Unity Catalog 授權應使用帳戶群組，workspace-local groups 無法取得 Unity Catalog 權限。
能呼叫服務，不代表能讀取完整紀錄
呼叫者EXECUTE ＋父層 USE父層需 USE CATALOG、USE SCHEMA
治理入口Model Service呼叫者獲授此服務的執行權
後端目的地檢查 owner 權限Caller 不需直接獲授目的地權限
紀錄讀者SELECT ＋父層 USE由表擁有者另外授權
內容紀錄Unified Trace TableBeta；查詢時套用已配置的 ABAC row filter
查詢結果政策允許的紀錄依已設定的服務範圍過濾
Trace table 預設僅建表的 metastore admin 可讀。沒有 row filter 時，獲授讀取權的人可能看見跨服務內容。服務 owner 必須持續保有後端所需權限。
System tables 與 MCP 的授權差異
其他物件：System tables 預設對同時具備 account admin 與 metastore admin 的人開放；管理者可另授父層 USE 與 SELECT。MCP Service 需 EXECUTE 與父層 USE，外部系統另有自身憑證與授權。
敏感 payload 與跨團隊分享
Unified trace table 會集中記錄請求內容。官方建議放在專用 catalog/schema，並於分享前使用 ABAC row filters，讓團隊只讀取應有的服務紀錄。這些群組與授權需由管理者建立，不會自動配置。
另一種官方做法是建立遮蔽敏感資料的衍生表：原始表維持嚴格權限，衍生表供較廣泛的分析。兩份資料都需要管理。Gateway 的 Service Policies 是請求執行時的政策，不能用來代替資料表的存取控制。
MCP：共用憑證與每人 OAuth
共用身分讓所有使用者以同一組外部憑證存取；per-user OAuth 讓外部服務以個別使用者身分處理。存取個人郵件、行事曆等資料時，官方要求依使用者授權路徑設定。
從 Databricks Apps 代理代表使用者呼叫 MCP 時，需授權實際呼叫者、為應用宣告 user_api_scopes: [ai-gateway]，並使用 get_user_workspace_client()；首次呼叫仍需使用者完成 OAuth 登入。只授權應用的服務主體並不等於完成每人存取設定。
MCP Service 的 EXECUTE 可依註冊文件以 UI、REST API 或 CLI 授予。Bundles 的 uc_securable 不支援此物件；新版另提供 resources.mcp_services 的 grants（DABs Beta），不可把兩者混為一談。bundle validate 通過仍須在實際身分下驗證存取。
紀錄保留要依儲存方式設定
System tables依各表期限保留若啟用 Configurable Retention Beta，由帳戶管理者為支援表設定共用期限。
Unified Trace Table · Beta自行設定保存政策未設政策會持續增長；可用 Auto-TTL，或排程 DELETE 後 VACUUM。
System tables 的期限不會替 trace table 設定生命週期；單獨執行 VACUUM 不會刪除資料列。
System tables 可調保留期與費用條件
Configurable Retention（Beta）：啟用後支援表預設 395 天，可設 30～3,650 天；不適用 data_classification 與 data_quality_monitoring schemas。Beta 期間免費，官方說明 GA 後超過 395 天將收儲存費。延長不補回歷史資料，縮短有 7 天寬限期。
Auto-TTL 須啟用 predictive optimization；到期後的永久刪除受背景處理與 time travel 保留期影響，並非即時完成。
上線前應明確指定紀錄擁有者、授權範圍與保存期間；這是依官方權限與保留機制整理的導入檢查項目，不代表啟用功能即可自動符合公司的法遵要求。
12 / 政策工程與判定驗收
把政策做成可以驗收、追查與維護的控制
政策的涵蓋範圍、評估成本與失敗方式，都必須納入應用設計。
本章延伸服務政策與POC 政策測試。Service Policies 仍為 Beta；以下驗收順序是本站依官方行為整理，不代表正式環境適用性或偵測準確率的保證。
把存取授權、輸入控制與輸出控制分開
存取授權Unity Catalog grants這個身分可以呼叫嗎？
輸入政策ON CALL呼叫底層服務之前檢查請求
執行模型／MCP 服務執行已放行的呼叫
輸出政策ON RESULT服務回應後、交回 caller 前檢查
輸出檢查發生在服務執行之後。若要防止破壞性工具呼叫，官方範例將控制放在 ON CALL。
Enforce 模式遇到政策錯誤、逾時或缺欄位會拒絕；Log 模式不阻擋。DENY 可能回 HTTP 200，應檢查 databricks_service_policy。
rank 與同順位執行規則
輸入依 rank 由小到大、輸出反向，遇到 DENY 即停止。相同 rank 的阻擋型 LLM judge 可平行執行，其餘政策再依附加順序執行；可在 Policies 的 See execution flow 查實際順序。
多輪判定有窗口，但沒有跨請求記憶
模型與供應商服務的輸入政策可設定 Conversation window；數字計算的是訊息數，不是問答對數。選擇完整對話，只會使用本次請求帶來的 messages；不會讀取伺服器保存的歷史。它不能實作「代理一旦讀過敏感資料，本次 session 的其他工具都禁止使用」這類有狀態的控制。
完整對話可能超過 evaluator 的 context window，評估失敗後會拒絕請求；擴大窗口也增加 token 與延遲。MCP 與輸出評估仍是單訊息範圍。官方範例另區分 OBO actor 與 run-as 身分，可依工具名稱、參數與 OAuth client ID 做控制，不能只靠自然語言要求代理自行遵守。
自訂 SQL 政策不是一般 SQL 查詢
政策函式以 VARIANT 接收並回傳資料，執行時會轉為 CEL，只支援指定 SQL 子集。不能使用 ai_query、子查詢、彙總或 BETWEEN；官方範例也明列不支援 regexp_*。因此不能直接貼上一般 SQL 的正規表示式，就宣稱完成臺灣身分證或企業帳號格式驗證。
讀取 event:... 後，須先轉為對應純量型別再比較；缺少欄位在此政策環境會產生錯誤並拒絕互動，與一般 SQL 回傳 NULL 的行為不同。自訂 SQL 同時跑在輸入和輸出階段，須以 event:type 區分，並分別測試兩種事件的欄位。
把判定證據放在正確的紀錄裡
LLM judge 是另一個 evaluator model service。要查它實際看見的內容、判定與 confidence，需事先在 evaluator 啟用 inference table。受保護服務的表只記自己的請求／回應；輸入先被阻擋時，甚至可能沒有該筆紀錄。
| 要證明的事 | 應查證據 |
|---|---|
| 真的阻擋了呼叫 | 客戶端回應的 databricks_service_policy。HTTP 200 或 evaluator 的 flagged: true，都不能單獨判定是否放行或阻擋。 |
| 為什麼判定命中 | Evaluator inference table 的 request／response；另保存當時的 Log／Enforce 設定，表內沒有 mode 欄位。 |
| 找到同一次互動 | 擷取回應 header databricks-request-id，核對表內 request_id，加上時間範圍；response body 的 id 是不同識別碼。 |
| 誤判與漏判可接受 | 依官方建議先以 Log 觀察 LLM judge，再檢查實際流量的判定；Sensitive Data Detection 僅有 Enforce，須另安排受控測試。 |
內建 LLM 防護沒有另收政策費，但每次 evaluator 呼叫照模型計費，包含政策提示、格式約定、受測內容與判定回應。Evaluator 本身附加的政策在評估時會被略過以免遞迴；不要假設它們形成第二層防護。Judge 紀錄也可能帶有原始敏感內容，須一併套用紀錄讀取與保存規則。
政策套用範圍仍有文件差異
建立頁的 UI 步驟可選 principals，但同頁 Beta Limitations 仍寫僅限個別服務、套用所有帳戶使用者，且沒有 catalog／schema 層級、ABAC 條件或 custom principals。本站不保證可用群組條件大量下發政策；應以實際帳戶功能與官方釐清結果作為驗收依據。
13 / 模型、API 與版本管理
選定模型之後，還要管理 API、版本與推論容量
先分清楚治理入口、模型資產與執行環境。以下官方能力適用於不同產品；自訂模型的部署設定，不會因為使用 Unity Gateway 就自動完成。
| 需求 | 官方提供的方式 | 導入時要決定 |
|---|---|---|
| 直接使用託管基礎模型 | Foundation Model APIs，支援模型可採 pay-per-token 或 provisioned throughput；Model Service 可引用這兩種目的地。 | 選擇符合區域、品質、延遲與容量需求的模型及方案。 |
| 使用企業既有供應商 | Model Provider Service 管理外部連線；Model Service 可同時引用 Databricks 模型與外部供應商。 | 各供應商模型能力、配額與資料處理條件須一起驗證。 |
| 部署公司自訂模型 | Model Serving 部署 MLflow 格式的 Python 模型；Unity Catalog Model Registry 管理模型版本、權限與 lineage。 | 登錄模型、套件依賴與服務容量另行部署；不要把 registered model、serving endpoint 與 Model Service 當成同一個物件。 |
相容 API 也有模型與格式限制
官方能力：Gateway 除了 Chat Completions，也提供 /ai-gateway/mlflow/v1/embeddings。Model Serving 另有 /serving-endpoints/open-responses；它使用 serving endpoint 名稱、無伺服器端對話儲存，須每回合送完整 input，與前述已公告退場的 Supervisor API 是不同入口。
使用 Model Serving Open Responses 呼叫 Gemini 並進行多輪工具操作時，須原樣保留 function_call.encrypted_content；框架只重建工具名稱、參數與呼叫 ID，可能造成下一輪被拒絕。此路徑的治理仍按 serving endpoint 文件核對，不能直接套用 UC Model Service 的授權與紀錄設定。
Function calling 回傳工具名稱與參數，實際執行由應用負責。Structured outputs 只支援部分 JSON Schema；例如 Claude 的 Chat Completions structured outputs 不可搭配串流、tools 或 tool_choice。這些是 Foundation Model APIs 的條件，不能推論所有外部供應商或原生 API 都相同。
本站整理：以真實客戶端建立相容性驗收
逐一測試選用模型的串流完成／錯誤事件、工具多輪回傳、結構化輸出、長上下文及 fallback 後的相同行為。保存 API 路徑、SDK 版本與模型版本；先查各後端配額，再訂 Gateway 限流。Foundation Model APIs 另有 ITPM、OTPM、QPH 限制，max_tokens 的預留量也可能使請求在執行前就收到 429。
自訂模型：從版本參照到實際部署
版本參照指定 alias以可變名稱指向模型版本
部署流程解析版本取得 alias 對應的版本號
Model Serving更新 endpoint部署該版本並確認就緒
只更改 alias，不代表既有 endpoint 已換版；新設定就緒前，新舊設定都會計費。
建立者身分、安全修補與交接細節
Endpoint 的 recorded creator 建立後不能更換；更新時會重新檢查其工作區成員資格與模型權限。呼叫更新 API 的人有權限，仍不能取代 creator 的條件。
Model Serving 不會直接修補既有模型映像；由新模型版本建立的新映像才包含最新安全修補。
本站整理的交付物：模型版本、依賴、signature、品質報告、前一版設定及修補週期；交接時核對 creator 身分、模型權限與實際 served version。
既有 Model Serving 治理，如何移轉到新服務入口？
舊版 AI Gateway on Model Serving 與 Unity Catalog Model Service 的管理物件不同。自訂模型仍依 Model Serving 文件部署；新 Model Service 官方列出的目的地是 pay-per-token、provisioned throughput 與 Model Provider Services，不能由名稱相近推定任意自訂 Python endpoint 都能直接掛接。
| 盤點項目 | 舊 Model Serving 治理 | Unity Catalog Model Service |
|---|---|---|
| 管理物件與授權 | 工作區 serving endpoint 的 ACL；設定治理需 CAN MANAGE。 | UC 服務完整名稱、owner、EXECUTE 與父層 USE；還有後端授權相依性。 |
| 用量與報表 | system.serving.endpoint_usage。 | system.ai_gateway.usage；依新 schema 調整欄位與歸屬。 |
| 政策與備援 | 使用 endpoint guardrails／fallback 的支援矩陣；舊 fallback 僅限外部模型。 | 依 Model Service 與 Service Policies 的功能狀態、路由及限制重新設定。 |
本站整理的移轉順序：盤點現有 URL、payload、模型名稱、憑證、ACL、政策與報表；建立隔離的新服務，以同一批案例比較回應、權限、延遲與紀錄，再分批切換客戶端。保留原設定的回復路徑，完成驗收後才回收舊授權與入口。這是企業移轉工作清單，不代表平台提供一鍵搬移。
14 / RAG、資料工具與 Agent
企業知識庫與 Agent，補上資料更新與品質驗收
只做模型入口治理，可以先完成前面的 POC；需要公司文件問答、工具工作流程或自訂應用時，再加入本節元件。這裡將官方能力與本站整理的交付工作分開。
RAG：資料如何進入索引？
來源同步來源表更新使用 Delta Sync Index
同步方式Continuous／Triggered持續同步，或明確觸發同步
檢索資料索引更新依 endpoint 支援模式同步
應用管理應用程式使用 Direct Vector Access
API／SDK新增、更新、刪除由應用程式送出資料變更
檢索資料直接更新索引不採來源表的 Delta Sync
Standard 支援 Continuous 與 Triggered；storage-optimized 僅支援 Triggered。Continuous 有持續同步運算成本。
AI Search 不支援資料列／欄位權限；應用 ACL 可透過 filter API 實作。
Schema 換版、來源前提與新鮮度驗收
Standard 的來源表須有 change data feed；啟用 row tracking 的表會自動使用。自管 embeddings 若要改為 Databricks 管理，須建立新索引並重新計算。
Schema 改動：修改來源 schema → 建立新索引 → 等待就緒並切換流量 → 刪除舊索引。這是官方的索引更換順序。
本站整理的驗收：保存來源、文件 ID、embedding 模型、同步模式與負責人；測新增、修改、刪除及越權查詢。自建 embedding endpoint 時，官方建議避免 scale-to-zero，以免暖機造成首次索引查詢逾時。
結構化資料：Genie、SQL MCP 與 UC function tools
知識庫檢索以外，代理也可能查詢企業資料表。官方區分三種路線：自然語言商業問題透過 Genie 理解業務語意；已有明確 SQL 的開發與資料工程工作使用 Databricks SQL MCP；固定邏輯、只讓模型填入參數的工作則可包成 Unity Catalog SQL function tool。
| 入口 | 企業導入須確認 |
|---|---|
| Databricks SQL MCP Public Preview | /api/2.0/mcp/sql 可依 UC 權限讀取與寫入，並非唯讀工具。查詢非同步執行，客戶端須輪詢完成；可預先設定 _meta.warehouse_id 指定運算資源，大型結果可能截斷。 |
system.ai.dbsql MCP ServiceBeta | 官方建議需要服務 grants、政策、稽核與用量治理時使用此服務；預設可讀寫，可在內建 system.ai.dbsql_policy 設 disallow_writes=true。直接 managed MCP URL 與受服務治理入口應分別驗收。 |
| Genie One MCP Beta | /api/2.0/mcp/genie 透過 Genie Ontology 理解商業名詞並產生附來源的回答；需啟用 Managed MCP Servers。每次請求仍執行 UC 授權；使用 OBO 時需 genie OAuth scope，且須處理非同步結果。 |
若只開放一組整理好的表與指示，可另外使用指定 Genie Agent 的 /api/2.0/mcp/genie/{genie_space_id}；它和分析整個工作區內容的 Genie One 入口不同。企業還須確認 底層資料、warehouse 與各服務的實際權限，不能只把 URL 接上就視為治理完成。
Agent：從試聊走到可重複的品質評估
官方能力：AI Playground 可比較模型與原型工具呼叫；新 Agent 的匯出路線建議採 Databricks Apps。Knowledge Assistant 適合文件問答；Custom Agents 適合需要自訂 Python 邏輯的應用。Apps 上的 Agent 仍須明確將模型呼叫導向 Gateway；官方 SDK 範例使用 use_ai_gateway=True。
若採 Knowledge Assistant，先核對文件是否實際匯入：超過 100 MB 的檔案，以及超過 500 頁的 PDF、Word 或 PowerPoint 會被略過；以底線或句點開頭的檔名也會略過。本站整理：以來源清單比對成功建立的知識來源，避免把「找不到答案」一律歸因於模型品質。
MLflow evaluation datasets 可從實際 traces、人工案例或合成資料建立，存於 Unity Catalog 並連結 experiment。以同一份資料及 scorers 執行 mlflow.genai.evaluate()，即可比較模型、prompt 或程式變更。RAG 可分別評估檢索相關性、回答是否有依據與正確性；需要標準答案的 scorer 要先準備 expectations。
本站整理的上線門檻：準備公司領域、繁體中文、找不到答案與越權案例，保存品質、延遲及成本基準；更換模型、prompt、工具或索引後重新比較，由業務與平台負責人訂通過門檻。Apps Agent 的人工回饋可用 labeling sessions；目前 MLflow Review App Chat UI 不支援 Apps 部署。
15 / 紀錄與可觀測性
紀錄與可觀測性
出了問題，要去哪裡查？
比較 Unity Gateway 用量紀錄、Inference tables、Unified trace table、Audit logs、MLflow Tracing 與 Model Serving logs。
依問題找到紀錄
用量誰用了多少？
token、延遲、請求者
system.ai_gateway.usagetoken、延遲、請求者
成本費用來自哪裡？
外部費用另查估算表
billing.usage ＋ list_prices外部費用另查估算表
模型內容送了什麼、回了什麼？Inference tables
個別模型服務 payload
個別模型服務 payload
Gateway 互動模型與工具做了什麼？Unified trace table Beta
服務的 OpenTelemetry spans
服務的 OpenTelemetry spans
平台活動誰執行了哪些操作？
依事件定義查核
system.access.audit依事件定義查核
應用步驟Agent 哪一步出錯？MLflow Tracing
模型、檢索與工具步驟
模型、檢索與工具步驟
部署健康模型部署為何失敗？Model Serving logs／metrics
建置、執行與端點指標
建置、執行與端點指標
用量表與 audit 系統表為 Public Preview；外部費用表為 Beta。Unified trace 為 best-effort，不能取代 audit logs。
Inference tables 與統一追蹤怎麼選？
Inference tables 依個別模型服務啟用；Unified trace table 由 metastore admin 設定一次，集中收集該 metastore 下各工作區的 Gateway 流量。官方建議新部署採統一追蹤，但它仍是 Beta，須由帳戶管理員啟用 Enhanced Unity Gateway 預覽。
Trace 不能取代稽核紀錄
Trace 交付是 best-effort；401、403、429、500 錯誤不保證有紀錄。官方比較表也說跨多步流程共用 trace ID 的串聯仍待提供，不能保證自動重建所有 Agent 步驟。
統一追蹤的建立者須為 metastore admin，並具有目標位置的 CREATE TABLE、USE CATALOG 與 USE SCHEMA。其他讀取者需取得表的 SELECT 及父層使用權；官方建議授權前設定 ABAC 列篩選。
兩種表均可使用 default storage catalog，但工作區管理員須先在 Settings > Previews 啟用 Zerobus Ingest Default Storage。Inference tables 不能指定既存表，也不支援 private endpoint 保護的儲存體。
Gateway 追蹤與應用追蹤各有範圍
MLflow Tracing 透過 autologging 或自訂 instrumentation，記錄應用內檢索、工具、模型與子代理的執行步驟。Gateway 紀錄則以通過治理入口的互動為範圍；導入時要確認想觀察的步驟在哪裡執行。
若要持續檢查回答品質，可在 MLflow experiment 設定 scorers，對生產 traces 抽樣評估。Production monitoring 為 Beta；使用 Unity Catalog 儲存 traces 時，須在 experiment 設定 SQL warehouse ID，僅設定應用程式的環境變數無法取代它。首次處理約需 15–20 分鐘。
資料到達、權限與查詢成本
| 紀錄 | 文件說明的交付行為 | 查閱時留意 |
|---|---|---|
| Inference tables | 首次請求後自動建表，資料最久可需一小時出現；透過 Zerobus 以 at-least-once 方式交付。 | 交付可能重複；401、403、429、500 錯誤可能缺錄。超過 10 MiB 的 request／response 不記錄，並標示 logging_error_codes。 |
| Unified trace table | 多數 traces 數秒內到達；新表最久可需一小時。交付為 best-effort。 | 單一屬性超過 3 MiB 會截斷；變更 schema、重新命名或刪除表可能中止寫入。 |
| 用量與計費系統表 | Billing usage 每數小時更新，但 ORIGINAL 記錄通常在 12 小時內才可用，新工作區可能更久；external model spend 每小時更新。 | 不要用單次空白結果判斷「沒有發生請求」。System tables 不適合作為即時監控來源。 |
- Usage tracking 與 inference tables 均是計費功能；system tables 的查詢運算另計費。統一 trace 介面也需選用 SQL warehouse。
system.ai_gateway.usage與system.ai_gateway.external_model_spend是區域資料；前者列 Public Preview，後者列 Beta。未啟用可設定保留期時，這兩表與全域的system.billing.usage免費保留期皆為 365 天。- System Tables Configurable Retention 為 Beta：帳戶管理員啟用後，支援表的預設保留期改為 395 天，可統一設定 30–3,650 天。這是系統表設定，不能用來設定自建 trace table。
- Trace table 的生命週期由使用者管理。可在符合 Auto-TTL 前提（包含啟用 predictive optimization）後設定自動保留規則；永久刪除不是即時完成。也可排程
DELETE後再執行VACUUM；只執行VACUUM不會刪除仍存在的資料列。
先辨識新舊入口
Unity Gateway 使用 system.ai_gateway.usage；legacy Model Serving endpoints 使用 system.serving.endpoint_usage，後者未啟用可設定保留期時，免費保留 90 天。自訂 Model Serving 的建置／執行 logs 屬部署診斷，不等於 Gateway payload 紀錄。
16 / 使用追蹤、成本與告警
使用追蹤、成本與告警
把用量變成可追蹤的營運資訊。
了解 Databricks 用量與計費系統表、外部模型估算、團隊成本歸屬、預算、儀表板與 SQL Alerts。
用量、計費與估算分開看
| 資料表 | 回答的問題 | 使用界線 |
|---|---|---|
system.ai_gateway.usage | 誰用哪些服務、消耗多少 token、延遲如何？ | System tables 總表標示 Public Preview；usage tracking 是計費功能。 |
system.billing.usage | Databricks 實際計費用量來自哪裡？ | 用量不等於美元金額；可配合 SKU 與價格資料分析。 |
system.billing.list_prices | 依牌價估算的金額是多少？ | 保留 SKU 價格歷史；牌價估算不代表公司合約價。 |
system.ai_gateway.external_model_spend | 外部供應商模型的估算花費？ | Beta；依 token、供應商公開價及 price multiplier 按小時估算。僅支援 UC Model Provider Services，目前不支援 Custom provider；實際費用以供應商帳單為準。 |
從內建儀表板開始
由帳戶管理員在 AI Gateway > Govern > Create Usage Dashboard 建立內建儀表板。部分工作區仍顯示獨立的 Create Dashboard／View Dashboard 按鈕。分享時可選擇以擁有者或每位檢視者的權限執行查詢；發布儀表板可讓未直接獲得系統表權限的人閱讀分析。
Cost observability 需儀表板 0.4 版以上。升級到 0.3 版以上會自動建立每 6 小時重新整理的排程；可在儀表板停用。這是儀表板更新排程，不代表每個來源表都每 6 小時更新。
Databricks 計費紀錄的 custom_tags 對應 model service tags；外部模型估算表則另含 endpoint_tags 與 request_tags。逐請求分析也可查 usage 表的 request tags。預算的 tag filters 使用 model service tags，request tags 不影響預算比對。
本站建議的閱讀順序：先確認服務與請求身分，再看團隊用量與費用，最後設定預算及告警。共享程式身分的使用量不能直接當作每位員工的個人用量。
通知、封鎖與排程告警
Budget · Send alert預算達門檻依近即時估算判定
寄信通知可繼續使用通知本身不封鎖請求
Budget · Block usage預算達門檻依近即時估算判定
限制使用阻止後續請求重設或提高門檻後恢復
SQL Alerts按排程查詢資料更新與排程影響時效
條件成立送出通知以查詢結果判斷
Budget 不打斷進行中的請求，不能保證最終帳單不超額。SQL Alerts 並非請求路徑上的預算控制。
預算範圍：經 Gateway 的 pay-per-token、ai_query、Genie；不含 provisioned throughput 與繞過 Gateway 的獨立 Serving 流量。外部模型納入預算為 Beta，須另行啟用並勾選。
外部模型預算的啟用條件
工作區管理員先開啟 External Model Spend in Budgets 預覽；建立預算時勾選 Include external model usage，才會把外部模型估算費用合併計入門檻。
把資料接成日常營運流程
-
取得分析權限
確認 Unity Catalog 與所需 system schemas；由管理者授權查詢或分享儀表板。
-
確認資料時間與歸屬
區分用量時間、資料更新時間與不同費用來源，避免把同一時刻的數字差異視為對帳錯誤。
-
建立報表與通知
先使用內建儀表板；額外需求可用 SQL Alerts 設定查詢、排程與門檻。新版 Alerts 各自擁有查詢定義，不能直接重用已儲存的 SQL query；狀態為
OK、TRIGGERED或ERROR。
預算頁、通知信、billing usage 與外部費用表更新頻率不同。官方文件說明 billing usage 每數小時更新，外部模型費用每小時更新；計費表另說明 ORIGINAL 記錄通常在 12 小時內可用，新工作區可能更久。更新頻率與資料到達時間不同；預算執行使用自己的近即時估算，不受系統表更新時間影響。封鎖也可能提早發生，進行中的請求則不會被中斷。
17 / 部署、變更與災難復原
讓設定可以重現，讓失敗可以復原
POC 證明服務可用；正式導入還要能追查變更、重建環境及交接維運。以下部署順序、回復演練與交接清單是本站依官方文件整理的建議；產品介面與限制則逐項附來源。
把 Gateway 服務與權限納入版本控制
三種服務的官方建立文件均提供 REST API、Databricks SDK、databricks ai-gateway CLI 與 Terraform；不是只有 UI。更新需要擁有者或 MANAGE，變更直接套用到原服務。
| 資源 | Terraform resource | Bundles 資源鍵 |
|---|---|---|
| Model Service | databricks_ai_gateway_model_service | resources.model_services |
| Model Provider Service | databricks_ai_gateway_model_provider_service | resources.model_provider_services |
| MCP Service | databricks_ai_gateway_mcp_service | resources.mcp_services |
這三種資源的 DABs 支援目前標示 Beta，不能由 Bundles 整體狀態推定適用正式流量；亦不能把 serving_endpoints 當成同一類資源。Model Provider 的供應商類型不可修改；MCP Service 名稱建立後不可修改。
- 分環境保存：將 catalog、schema、目的模型、路由、grants 與非機密設定存入 Git；Terraform state 採遠端儲存與鎖定，開發、驗證及正式環境分開。
- 部署前審查：CI/CD 檢查差異與目標環境，金鑰由受控變數注入，不寫入版本庫。Provider 官方 Terraform 範例使用
sensitive = true變數。 - 部署後與回復：本站建議保存前一版設定，以實際呼叫、拒絕案例及紀錄驗證後才擴大流量；回復時重新套用已驗證設定，再做相同檢查。不要把「刪除重建」當作無影響的回滾。
正式交接要能回答的四個問題（本站整理）
- 目前執行的是哪個已審查版本？保存設定差異、部署結果與測試證據，讓接手人能重現。
- 發生錯誤時找誰？分清企業入口、Databricks 管理者及外部模型供應商窗口；通報保留時間、區域、服務名稱與請求識別碼。
- 需要回復時做什麼？列出上一個可用設定、所需權限及回復後查核步驟，並實際演練。
- 誰能決定恢復流量？由企業指定負責人與品質、延遲、錯誤率及費用門檻；官方不替每個應用定義統一驗收值。
失敗發生在哪一層？
單次請求限流後重試Gateway 回傳 429；客戶端採指數退避
模型目的地依序嘗試備援Fallback 按設定順序，不重新套用分流權重
整個區域災難復原第二區環境、資料、身分與入口；定義 RTO／RPO
Managed DR 明列不複寫 secrets、ML models、Model Serving endpoints 與 vector search indexes；Gateway Services 的涵蓋範圍須另行確認。
管理 API、路由觀測與 DR 前提
Gateway 在回應後更新用量計數；並行流量可短暫超過限流值。管理 API 要依 error_code 處理：RESOURCE_EXHAUSTED 可能是配額耗盡，504 不代表伺服器完全未執行。
路由與備援可查 system.ai_gateway.usage.routing_information；含 session 識別標頭的請求可能固定到同一後端。
DR 規劃包含第二區的工作區、metastore、身分、資料與客戶端 URL，並以演練驗證 RTO／RPO。Managed DR 須向 Databricks 申請；兩端需 Enterprise、Mission Critical add-on 與 serverless。
18 / 告警營運與成本交接
把「有紀錄」變成有人接手的營運流程
告警從排程到通知，要走過哪些步驟？
排程開始評估到指定時間執行
運算與身分執行查詢使用 SQL warehouse 與執行者權限
查詢結果判定狀態
OK／TRIGGERED／ERROR通知設定送往接收者可設定恢復與重複通知
Warehouse 無法啟動或失去存取權會回傳 ERROR；排程滿額可能略過評估。沒有通知，不能直接判定正常。
追查通知交付：system.alert.alert_evaluation_history 的 failed_subscriptions 可查寄送失敗；告警系統表為 Public Preview。
執行身分、查詢權限與交接檢查
Alerts API 可用 run_as 指定執行者，再回讀 effective_run_as；指定 service principal 須有 servicePrincipal/user 角色。
- 查 system tables 需
USE CATALOG、USE SCHEMA與SELECT；Gateway 用量與告警系統表皆為區域資料。 - 停止中的 warehouse 可被排程啟動；啟動時間會增加延遲，也會產生運算費。
- 每個 workspace 預設最多 250 個同時 active alert runs；滿額時新排程略過評估，可由歷史紀錄查看缺口。
- 由 Git 新複製的告警排程預設暫停；原擁有者離開時，由 workspace admin 移轉擁有權。
本站整理的交接驗收：保存擁有者、執行身分、來源表、warehouse 與接收窗口；分別測試觸發、恢復、空結果及查詢失敗。空結果的狀態可另行設定；通知目的地由工作區管理員建立。
設定歷史位於 system.alert.alerts；評估及交付位於 system.alert.alert_evaluation_history。未啟用可設定保留期時，兩表免費保留 365 天。
費用歸屬要落到控制邊界
本站建議事先定義 team、cost_center 與環境標籤，再用實際帳務資料驗證。Model Service 的服務標籤進入 Databricks 帳務 custom_tags；request tags 可供分析，但不參與 Gateway 預算比對。因此用共用服務加請求標籤分部門，並不等於每部門已有獨立預算封鎖。
Gateway 預算範圍外的 provisioned throughput、獨立 Serving 流量要另行追蹤；告警 SQL warehouse 也有自己的運算成本。官方建議排程頻率不要高於來源資料更新速度。本站建議為每項額外服務指定費用負責人，將 Gateway 模型費用與整個應用的營運成本一起驗收。
19 / 成本與功能限制
成本怎麼看，哪些能力仍有限制？
計費項目分開看
模型使用推論費用Databricks 託管模型與外部供應商，各按其計費方式
Gateway 紀錄用量與內容紀錄Usage tracking、Inference tables 都會計費
政策評估 · Beta評估模型呼叫內建政策不另收政策費；模型評判依呼叫計費
分析與告警查詢運算查詢與告警使用的 SQL warehouse 另有運算費
外部模型費用是估算，實際以供應商帳單為準；目前 Custom provider 不支援外部費用追蹤。
預算封鎖不保證帳單上限：Budget 採近即時估算，進行中的請求不會中斷。
對帳依據與政策 token 範圍
Databricks 計費用量查 system.billing.usage；外部模型估算按 token、供應商公開價與設定的 price multiplier 計算。資料來源更新頻率不同，當下數字可能不一致。
採模型評判的政策，計費 token 包含政策提示、輸出格式要求、受評內容及評估回應。此處不列未由操作文件核實的產品單價或公司合約價。
功能狀態速查
以下狀態依所列 AWS 文件，核對於 2026-09-21；Azure / GCP 及不同工作區需再確認。
| 項目 | 核對結果 | 對導入的意義 |
|---|---|---|
| Unity Gateway 整體 | 正式提供（GA） | 個別擴充功能仍可能需要另外啟用。 |
| Smart Routing | Beta | 候選模型、客戶端模式與跨框架條件見功能詳解。 |
| Service Policies / LLM Guardrails | Beta | 需帳戶管理者開啟；支援 MCP、Model 與 Model Provider Services，不支援 Agent Services。 |
| Unified Trace Table | Beta | 交付 best-effort；完整多步追蹤串聯仍有限制。 |
| Agent Services | Beta | 本站依文件限制章節列為登錄與權限管理；執行能力待官方釐清。 |
| 外部模型費用納入預算 | Beta | 另行啟用並勾選；採估算金額。 |
Gateway 用量表 system.ai_gateway.usage | Public Preview | 區域資料；功能狀態與核心 Gateway GA 分開核對。 |
外部模型費用表 system.ai_gateway.external_model_spend | Beta | 區域估算資料；更新與保留規則見紀錄章節。 |
| 稽核系統表 system.access.audit | Public Preview | 稽核紀錄的查詢介面仍有自己的預覽狀態。 |
| Omnigent on Databricks | Beta / 相關產品 | 工作區預覽、Sandbox 與區域有各自條件。 |
[09] Agent Services 登錄與限制 ↗[07] Smart Routing ↗[10] Service Policies ↗[11] 統一追蹤表 ↗[06] 預算、通知與用量封鎖 ↗[20] Omnigent on Databricks ↗
Inference Tables 可使用 default storage catalog，但工作區管理員須先在 Settings > Previews 啟用 Zerobus Ingest Default Storage；仍不支援 private endpoint 保護的儲存體，也不能指定既存表。超過 10 MiB 的請求或回應不記錄，並以 logging_error_codes 標示。資料透過 Zerobus 以 at-least-once 方式交付，可能重複；401、403、429、500 錯誤仍可能缺錄。[41] Inference Tables 與限制 ↗
用量表預設查詢者須同時具備 account admin 與 metastore admin 角色，亦可由管理者另行授權。對超過 1 MiB 的非串流、非 embedding 回應，Gateway 不追蹤 token 用量。
ai_query 批次推論的治理範圍不同
以 SQL 或 Python 的 ai_query 呼叫 Unity Gateway，目前只支援 Databricks 提供的 system.ai 模型服務，不支援自行建立的 Model Services。查詢文件列出可追蹤用量，但速率限制、防護規則、Inference Tables 與備援不適用；預算文件則另明列 ai_query 用量納入範圍。
區域支援不等於所有資料皆在同一地區處理
Unity Gateway 的 Model Services 文件明載不支援 AWS GovCloud。AWS 區域文件分別列出模型、AI 功能及 MCP 的支援範圍，部分功能須啟用跨地理區域路由。部分 Designated Services 另以 Databricks Geos 管理處理位置；Geo 可包含多個資料中心區域，不能只看工作區所在區域判定資料處理位置。MCP 與 Unity Catalog HTTP connections 的支援區域依 Custom Model Serving 表列範圍。
20 / 常見問題
容易混淆的地方，一次說清楚
舊文件的 AI Gateway，和這裡是同一套設定嗎？
官方仍保留標示 legacy 的 Model Serving 端點治理文件。本指南以 Unity Gateway 與 Unity Catalog 的 Model Services 為主。舊端點的權限、API 與用量表可能不同；例如舊用量表是 system.serving.endpoint_usage，不要直接套用到新服務。
Unity Gateway 是新的聊天機器人或大型語言模型嗎？
它主要是企業 AI 的治理與使用管理層。應用或代理仍使用底層模型與工具完成工作；Gateway 協助管理這些互動。
一定要把外部模型搬到 Databricks 才能治理嗎？
不一定。Model Provider Services 可連到公司原本使用的外部供應商，集中管理連線與驗證設定。供應商支援、驗證方式與資料傳輸路徑仍須確認。
Smart Routing 和流量分配有什麼不同？
Smart Routing 依開發任務挑候選模型；流量分配依設定百分比選後端。備援則處理初次呼叫失敗後的重試順序。三者解決的問題不同。
接了 MCP，就一定只會看到該使用者本來有權限的資料嗎？
要看驗證設定。每人 OAuth 可代表各自的身分；共用 principal 則用共同憑證。不能只因 MCP 經過 Gateway，就推論外部系統必然採每人權限。
官方如何讓 coding agent 接上 Gateway？
文件提供 Unity Gateway CLI（ug）及手動設定兩條路。ug 處理 OAuth 並寫入支援代理的設定檔；手動教學涵蓋 Claude Code、Codex CLI、Cursor 與 Gemini CLI。需使用支援區域且已啟用 Unity Catalog 的工作區。
會自動保證答案正確、完全沒有資料外洩嗎？
官方未作這種保證。文件明列 LLM judge 的判定非確定性；預設評估單一訊息，不讀取被保護服務的 system prompt、影像或音訊。格式型 Sensitive Data Detection 也只涵蓋列出的類別，不包含姓名等自由文字。
模型資料在哪裡處理、會保存多久？
Model Serving 文件說明，Foundation Model APIs 的資料落地遵循 Databricks Geos 界線；各功能支援區域另見官方區域表。資料保存則有獨立規則：對付費帳戶，Databricks 不會將送入 Model Serving 的輸入與輸出用於訓練模型或改善 Databricks 服務。就 Foundation Model APIs 而言，Databricks 可為防範濫用，在工作區同區保存輸入與輸出最多 30 天；合作模型供應商另有安全用途留存條件。
這份中文網站是官方文件嗎？
這是依 Databricks 官方來源重新整理的繁體中文導讀，並非官方翻譯。技術能力以 AWS 英文操作文件為依據，使用案例與步驟取自官方文件。查核日期、來源類型、原文矛盾與取得限制列在來源索引。
21 / 官方來源索引
繼續深入，直接回到原始文件
本指南在各章節附上官方文件，並於本頁統一提供來源索引。企業基礎、POC、正式維運與主要 Gateway 主張由主代理及三位子代理分工對照官方正文查核；資料核對日期為 。查閱日期不等於官方發布日。
範圍：產品技術依 docs.databricks.com 官方文件，以 Databricks on AWS 英文正文為主；Microsoft Entra ID 專章另核對 learn.microsoft.com 官方文件與原始設定截圖（2026-09-22）。Azure／GCP 需另核對對應文件；未在實際 Databricks 帳戶執行功能驗證。
官方來源仍有差異，本站保留疑點
- 模型查詢總覽仍列 Supervisor API；專頁已公告 2026-09-30 終止服務，本站依退場公告處理。
- Coding Agent 教學的用量 SQL 使用
service_name／service_type，但用量表 schema 列的是endpoint_name。POC 先檢查實際 schema，再使用已列明的欄位。 - Agent Services 同頁描述可呼叫，但 Limitations 又列 runtime invocation 尚未提供；本指南採限制章節，不自行認定已開放。
- Service Policies 文件標示 Beta；格式型敏感資料偵測不涵蓋姓名等自由文字，不能當作所有敏感內容的完整識別。
- GitHub MCP 教學一面說阻擋非 read-only 寫入工具，一面說 pull-request 工具可用；本指南不自行保證建立 PR 的放行範圍。
- 政策建立頁仍要求內建函式
EXECUTE；敏感資料專頁則說 Beta 內建政策由平台管理、無EXECUTE可授予。本站不將前者當作所有內建政策的共同設定步驟。 - 敏感資料專頁已列 MCP 阻擋、遮蔽與輸入核准；Service Policies 總覽的 transformation 限制仍只提 model services，本站依專題頁列能力並保留此差異。
- MCP 治理概覽泛稱工具與政策可適用內建服務，但內建服務專頁限制自訂工具選擇與政策函式；本站採內建專頁的保守範圍。
- 跨 workspace access 與 network policies 對 Full access 的敘述不同；本手冊僅說明 Restricted 模式的雙向允許，不對 Full access 作可達性保證。
- MCP 概念頁仍有舊 Bundles grants 限制；註冊專頁已提供
mcp_services專用資源及 grants 範例，本手冊按新資源說明並保留 Beta 標示。
全部官方參考文件
- 產品與治理總覽 ↗官方文件 · 本站核對 2026-09-21
- Unity Gateway 技術總覽 ↗官方文件 · 本站核對 2026-09-21
- 模型 API 與 Model Services ↗官方文件 · 本站核對 2026-09-21
- 外部模型供應商與 BYOK ↗官方文件 · 本站核對 2026-09-21
- AI 成本分析 ↗官方文件 · 本站核對 2026-09-21
- 預算、通知與用量封鎖 ↗官方文件 · 本站核對 2026-09-21
- Smart Routing ↗官方文件 · 本站核對 2026-09-21
- Model Serving 與推論容量 ↗官方文件 · 本站核對 2026-09-21
- Agent Services 登錄與限制 ↗官方文件 · 本站核對 2026-09-21
- Service Policies ↗官方文件 · 本站核對 2026-09-21
- 統一追蹤表 ↗官方文件 · 本站核對 2026-09-21
- 速率限制 ↗官方文件 · 本站核對 2026-09-21
- 流量分配與備援 ↗官方文件 · 本站核對 2026-09-21
- 稽核事件參考 ↗官方文件 · 本站核對 2026-09-21
- MLflow 3 for GenAI ↗官方文件 · 本站核對 2026-09-21
- SQL 告警與安全事件監控 ↗官方文件 · 本站核對 2026-09-21
- Coding Agents 整合 ↗官方文件 · 本站核對 2026-09-21
- MCP 與代理工具總覽 ↗官方文件 · 本站核對 2026-09-21
- MCP Services、身分與網路 ↗官方文件 · 本站核對 2026-09-21
- Omnigent on Databricks ↗官方文件 · 本站核對 2026-09-21
- 可觀測性工具選擇 ↗官方文件 · 本站核對 2026-09-21
- 預算範圍與限制 ↗官方文件 · 本站核對 2026-09-21
- Service Policies 與防護 ↗官方文件 · 本站核對 2026-09-21
- 用量追蹤與計費說明 ↗官方文件 · 本站核對 2026-09-21
- 模型成本與估算 ↗官方文件 · 本站核對 2026-09-21
- AWS 功能與區域支援 ↗官方文件 · 本站核對 2026-09-21
- GitHub MCP 治理教學 ↗官方文件 · 本站核對 2026-09-21
- Databricks 平台入門 ↗官方文件 · 本站核對 2026-09-21
- Unity Catalog 是什麼 ↗官方文件 · 本站核對 2026-09-21
- 建立與部署代理 ↗官方文件 · 本站核對 2026-09-21
- Databricks Apps ↗官方文件 · 本站核對 2026-09-21
- AI Search 與檢索 ↗官方文件 · 本站核對 2026-09-21
- Genie 產品家族 ↗官方文件 · 本站核對 2026-09-21
- 舊版 Serving Endpoint 治理 ↗官方文件 · 本站核對 2026-09-21
- 模型存取治理入門教學 ↗官方文件 · 本站核對 2026-09-21
- 敏感資料偵測與遮蔽 ↗官方文件 · 本站核對 2026-09-21
- Metastore 與資產層級 ↗官方文件 · 本站核對 2026-09-21
- Agent Bricks 定位更新 ↗官方文件 · 本站核對 2026-09-21
- 帳戶、工作區與基本元件 ↗官方文件 · 本站核對 2026-09-21
- 稽核系統表與預覽狀態 ↗官方文件 · 本站核對 2026-09-21
- Inference Tables 與限制 ↗官方文件 · 本站核對 2026-09-21
- 用量追蹤、儀表板與計費 ↗官方文件 · 本站核對 2026-09-21
- 模型、代理與工具概念 ↗官方文件 · 本站核對 2026-09-21
- 政策建立、ASK 與判定除錯 ↗官方文件 · 本站核對 2026-09-21
- 預覽與正式發布分類 ↗官方文件 · 本站核對 2026-09-21
- 模型服務授權與傳播時間 ↗官方文件 · 本站核對 2026-09-21
- 模型查詢方式與治理範圍 ↗官方文件 · 本站核對 2026-09-21
- 內建 MCP Services 與限制 ↗官方文件 · 本站核對 2026-09-21
- MCP 權限、政策與網路治理 ↗官方文件 · 本站核對 2026-09-21
- MLflow 應用追蹤與 instrumentation ↗官方文件 · 本站核對 2026-09-21
- Production monitoring 條件與限制 ↗官方文件 · 本站核對 2026-09-21
- 系統表範圍、權限與保留期限 ↗官方文件 · 本站核對 2026-09-21
- Unity Catalog 治理 ↗官方文件 · 本站核對 2026-09-21
- Databricks AI 能力 ↗官方文件 · 本站核對 2026-09-21
- 企業正式環境規劃 ↗官方文件 · 本站核對 2026-09-21
- 網路連線與控制 ↗官方文件 · 本站核對 2026-09-21
- Governance Hub ↗官方文件 · 本站核對 2026-09-21
- Model Serving 紀錄與健康監控 ↗官方文件 · 本站核對 2026-09-21
- Zerobus 交付與暫存保留限制 ↗官方文件 · 本站核對 2026-09-21
- 計費用量資料到達時間 ↗官方文件 · 本站核對 2026-09-21
- Auto-TTL 前提與限制 ↗官方文件 · 本站核對 2026-09-21
- 牌價系統表 ↗官方文件 · 本站核對 2026-09-21
- 企業身分管理實務 ↗官方文件 · 本站核對 2026-09-21
- 驗證與存取控制 ↗官方文件 · 本站核對 2026-09-21
- Automatic identity management 與同步範圍 ↗官方文件 · 本站核對 2026-09-21
- Entra ID GA 發布說明 ↗官方文件 · 本站核對 2026-09-21
- Okta GA 發布說明 ↗官方文件 · 本站核對 2026-09-21
- HTTP 連線層級 ↗官方文件 · 本站核對 2026-09-21
- Provider managed paths 與 header ↗官方文件 · 本站核對 2026-09-21
- Supervisor API 退場公告 ↗官方文件 · 本站核對 2026-09-21
- Lakeflow Connect ↗官方文件 · 本站核對 2026-09-21
- Delta Lake ↗官方文件 · 本站核對 2026-09-21
- 資料管線 ↗官方文件 · 本站核對 2026-09-21
- Lakeflow Jobs ↗官方文件 · 本站核對 2026-09-21
- SQL warehouse ↗官方文件 · 本站核對 2026-09-21
- 企業試用與 Free Edition 差異 ↗官方文件 · 本站核對 2026-09-21
- 建立企業試用環境 ↗官方文件 · 本站核對 2026-09-21
- 建立 Serverless workspace ↗官方文件 · 本站核對 2026-09-21
- 建立 Classic workspace ↗官方文件 · 本站核對 2026-09-21
- Unity Catalog 前置與確認方式 ↗官方文件 · 本站核對 2026-09-21
- Workspace-catalog binding ↗官方文件 · 本站核對 2026-09-21
- 管理角色與範圍 ↗官方文件 · 本站核對 2026-09-21
- Service principal OAuth M2M ↗官方文件 · 本站核對 2026-09-21
- Serverless 出站管制 ↗官方文件 · 本站核對 2026-09-21
- AWS 內部資源私有連線 ↗官方文件 · 本站核對 2026-09-21
- 模型處理地區與法遵範圍 ↗官方文件 · 本站核對 2026-09-21
- 建立服務的權限要求 ↗官方文件 · 本站核對 2026-09-21
- 管理預算的角色 ↗官方文件 · 本站核對 2026-09-21
- Preview 啟用及正式環境界線 ↗官方文件 · 本站核對 2026-09-21
- 建立外部 Provider ↗官方文件 · 本站核對 2026-09-21
- 安裝 Databricks CLI ↗官方文件 · 本站核對 2026-09-21
- OAuth CLI 命令 ↗官方文件 · 本站核對 2026-09-21
- 憑證選用順序 ↗官方文件 · 本站核對 2026-09-21
- 自訂政策案例 ↗官方文件 · 本站核對 2026-09-21
- Metastore 區域配置 ↗官方文件 · 本站核對 2026-09-21
- Context-based ingress ↗官方文件 · 本站核對 2026-09-21
- 跨 workspace access Beta ↗官方文件 · 本站核對 2026-09-21
- Geos 預設值與設定位置 ↗官方文件 · 本站核對 2026-09-21
- Designated Services 與區域註腳 ↗官方文件 · 本站核對 2026-09-21
- 法遵責任、身分及中繼資料邊界 ↗官方文件 · 本站核對 2026-09-21
- OAuth U2M 與 token 更新 ↗官方文件 · 本站核對 2026-09-21
- Token federation ↗官方文件 · 本站核對 2026-09-21
- Federation policy ↗官方文件 · 本站核對 2026-09-21
- API scopes 與操作對照 ↗官方文件 · 本站核對 2026-09-21
- App 使用權與資料授權的差別 ↗官方文件 · 本站核對 2026-09-21
- App authorization 與 User authorization ↗官方文件 · 本站核對 2026-09-21
- 多輪窗口與代理身分政策範例 ↗官方文件 · 本站核對 2026-09-21
- Actor、tool 與 event 欄位 ↗官方文件 · 本站核對 2026-09-21
- Model Registry ↗官方文件 · 本站核對 2026-09-21
- Model Serving Open Responses ↗官方文件 · 本站核對 2026-09-21
- Function calling ↗官方文件 · 本站核對 2026-09-21
- Structured outputs 限制 ↗官方文件 · 本站核對 2026-09-21
- 底層配額與 token 預留 ↗官方文件 · 本站核對 2026-09-21
- Endpoint creator 身分 ↗官方文件 · 本站核對 2026-09-21
- 自訂模型更新行為 ↗官方文件 · 本站核對 2026-09-21
- 索引種類、同步及前提 ↗官方文件 · 本站核對 2026-09-21
- 結構化資料工具選擇 ↗官方文件 · 本站核對 2026-09-21
- SQL MCP、寫入政策與服務入口 ↗官方文件 · 本站核對 2026-09-21
- Genie One MCP、前置與權限 ↗官方文件 · 本站核對 2026-09-21
- Managed MCP 入口與 OAuth scopes ↗官方文件 · 本站核對 2026-09-21
- Playground 與匯出路線 ↗官方文件 · 本站核對 2026-09-21
- Apps Agent 與 Gateway ↗官方文件 · 本站核對 2026-09-21
- 建立評估資料集 ↗官方文件 · 本站核對 2026-09-21
- 重複評估與版本比較 ↗官方文件 · 本站核對 2026-09-21
- 各 scorer 的資料需求 ↗官方文件 · 本站核對 2026-09-21
- IaC、環境隔離與變更審查 ↗官方文件 · 本站核對 2026-09-21
- 問題通報的請求識別碼 ↗官方文件 · 本站核對 2026-09-21
- HA、DR 與 RTO／RPO ↗官方文件 · 本站核對 2026-09-21
- Managed DR 要求與排除資源 ↗官方文件 · 本站核對 2026-09-21
- Alerts v2 執行身分 ↗官方文件 · 本站核對 2026-09-21
- 告警條件與進階設定 ↗官方文件 · 本站核對 2026-09-21
- 告警運算與成本 ↗官方文件 · 本站核對 2026-09-21
- Git 與擁有權交接 ↗官方文件 · 本站核對 2026-09-21
- 告警設定與交付紀錄 ↗官方文件 · 本站核對 2026-09-21
- Knowledge Assistant 文件匯入與限制 ↗官方文件 · 本站核對 2026-09-21
- Databricks：Entra ID SSO ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：Entra ID AIM 設定 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：註冊應用程式 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：緊急存取 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：SSO 測試 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft 官方文件 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft 官方文件 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：設定 optional claims ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：指派使用者與群組 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：Federated credential 信任設定 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft 官方文件 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft 官方文件 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：管理員同意與角色限制 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：Unified login ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：群組與工作區授權 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks AWS：Entra SCIM 完整流程 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：account SCIM 與遷移順序 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Microsoft：Provisioning、Mappings 與 Scope ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：AWS account SCIM 2.1 URL ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22
- Databricks：OIDC 與錯誤排查 ↗Entra ID 專章 · 官方文件 · 本站核對 2026-09-22