讓 Agent 查企業資料時，最直覺的做法往往是給它資料庫 schema，再讓模型依問題自行產生 SQL。Demo 很快就能完成：使用者用自然語言提問，幾秒後畫面出現一張看似正確的報表，彷彿過去排隊等 IT 寫查詢的日子終於結束了。
但站在技術主管的位置，我反而會先踩煞車。因為企業查詢真正困難的，從來不只是 SQL 語法，而是資料語意、權限、有效條件、效能與責任。讓 Agent 自由寫 SQL，不是消除了這些問題，只是把它們藏進一段每次都可能不同的生成結果裡。
能執行，不代表答案成立
一段 SQL 能通過 parser、能在資料庫執行，最多只能證明語法與物件名稱沒有錯。它不會自動證明商業定義正確。
企業系統裡，同一個「營收」可能有接單、出貨、開票或入帳口徑；同一張訂單可能因版本、取消、拆單或跨期而需要不同排除條件。庫存也不只是加總數量，還可能涉及可用、保留、在途、待驗與呆滯狀態。這些規則常藏在 view、stored procedure、報表程式，甚至資深同仁多年累積的判斷裡。
模型看得懂欄位名稱，不等於理解組織採用的定義。最危險的結果不是查詢失敗，而是它順利執行、數字也很像真的，最後被帶進會議或決策流程。技術錯誤通常會報錯；語意錯誤則可能穿著漂亮圖表一路過關。
自由查詢同時放大四種風險
第一是資料越界。資料庫帳號若能讀取整個 schema，Agent 就可能因模糊問題、錯誤 join 或提示注入，碰到不屬於這個使用者、部門或任務的資料。只在 prompt 寫「不要查敏感欄位」，不是存取控制。
第二是效能不可預測。缺少條件的大表掃描、錯誤的多對多 join、沒有上限的明細查詢，都可能把一次普通問答變成資料庫事故。人類開發者寫錯 SQL 已經會出事；讓模型在每個問題上即席發明新查詢，只是把測試範圍變成無限大。
第三是結果不可重現。相同問題在不同時間、不同模型版本或不同上下文下，可能產生不同 SQL。若沒有保存查詢版本、參數與資料時間點，事後很難回答「這個數字當時到底怎麼來的」。
第四是責任模糊。當答案錯了，問題究竟出在欄位定義、查詢邏輯、權限範圍、資料延遲，還是模型理解？如果所有層次都混在一段生成 SQL 裡，調查只能從猜測開始。
我更傾向把已驗證查詢封裝成工具
比較穩健的方式，不是讓 Agent 直接面對任意 SQL，而是把常用且已驗證的資料需求封裝成具名能力。例如「查詢某期間的出貨趨勢」、「取得某工單的生產進度」或「列出需要人工確認的異常紀錄」。底層仍然可以是 SQL，但對 Agent 暴露的是清楚的工具契約。
這個契約至少要包含：
- 明確的用途與商業定義；
- 有型別的輸入參數、格式、範圍與上限；
- 依使用者身分與任務套用的資料權限；
- 固定或受控的查詢模板；
- 結果欄位的語意、單位、時區與更新時間；
- 超時、筆數限制、快取及錯誤處理；
- 工具版本、呼叫紀錄與可追溯的查詢識別碼。
MCP 可以是承載這類能力的一種介面，但重點不是用了哪個協定，而是不要把原始資料庫權限偽裝成一個萬能工具。工具層的價值，在於把原本散落的資料規則變成可審查、可測試、可授權的產品介面。
型別不只防止格式錯誤，也限制意圖範圍
很多人提到 typed tool，想到的是日期要符合格式、數字不能傳成字串。這當然有用，但對企業 Agent 而言，型別更重要的作用是縮小可表達的行為。
若工具參數允許任意 where_clause、table_name 或整段 SQL，它形式上雖然是工具，實際上仍然把資料庫控制權交給模型。相反地，若參數只能選擇已核准的時間區間、組織範圍、彙總粒度與狀態，系統就能在執行前驗證意圖，也能預估成本與風險。
這和 API 設計很像。好的 API 不會因為「彈性」就讓呼叫端直接操作內部資料結構；它會提供穩定的業務能力，並保留服務端維護不變條件的責任。Agent 不該因為會說自然語言，就獲得比其他應用程式更寬鬆的介面。
不是所有問題都能事先做成報表
當然，若只允許固定查詢，也可能退化成另一套僵硬的報表系統。企業裡確實會有探索性分析，無法預先列出每一種問題。
我的做法會是分層，而不是在「完全固定」和「任意 SQL」之間二選一。
高頻、正式、會進入決策或後續動作的查詢，應優先產品化成受控工具。低風險探索可以進入唯讀分析環境，使用去識別資料、resource limit、查詢 timeout 與結果筆數限制，並保留完整 SQL 與執行計畫。若查詢結果要寫回正式系統、對外發布或觸發動作，則必須升級審查，不能因為前一步是自然語言提問就自動取得更高權限。
此外，Agent 也可以提出「新工具候選」：保存使用者問題、生成 SQL、驗證結果與人工修正，讓資料團隊把重複出現且有價值的查詢，逐步升級成正式能力。這樣既保留探索速度，也不必讓每一次正式查詢都成為現場實驗。
真正要管理的是資料能力，不是 SQL 產生器
我並不反對模型協助寫 SQL。它很適合做草稿、解釋既有查詢、找出可能的 join，或在隔離環境加速分析。問題在於，我們不能把「模型會寫 SQL」直接等同於「Agent 已具備可靠的企業資料存取能力」。
後者需要的是語意契約、最小權限、資源限制、版本、測試與稽核。當欄位定義改變時，哪些工具受影響？查詢版本升級後，舊報表能否重現？使用者看到的結果是否符合他的資料範圍？一次回答用了哪個定義與資料時間點？這些才是正式環境每天會遇到的問題。
自然語言介面會讓查資料變得更容易，這是好事。但入口越簡單，底層責任越不能省略。對我來說，成熟的企業 Agent 不是能對任何資料庫自由下 SQL，而是能在清楚邊界內，呼叫一組可信、可理解、出了問題查得到原因的資料能力。
把 SQL 藏在受治理的工具後面，不是限制 Agent 的聰明；而是讓它產生的每一個數字，終於有資格被人拿去做事。