InfoQ 在 2026 年 10 月刊登、由 Peihao Yuan 撰寫的文章，處理一個在 AI 代理進入分析流程後常被提出的疑問：既然代理能讀取物件儲存上的檔案、產生分析程式並寫出報告，資料表、目錄、湖倉與 SQL 查詢引擎是否將被取代？湖倉是一種結合資料湖與資料倉儲的分析架構，原本用來統一管理大量結構化與半結構化資料。文章的答案是否定的，理由不是引擎消失，而是引擎的位置改變了。過去工程師直接開儀表板或手寫查詢，現在由代理理解問題、挑選資料、產生受限制的 SQL 或 Python、交由確定性工具執行，最後解釋結果。使用者體驗變了，但精確計算並沒有被淘汰。
這個問題的起點是一場實際完成的災難復原演練。演練中有一個區域被刻意隔離，預期流量會轉移到仍存活的區域。團隊必須逐一對每個服務回答三個問題：接手區域是否吸收了離開隔離區的流量、吸收之後服務是否仍維持可用、延遲是否維持在可接受範圍，還是額外負載造成持續性劣化。指標以三十秒解析度匯出，寫成 Parquet 這種以欄位為導向的壓縮檔案格式，放進相容於 S3 的物件儲存，再由 DuckDB 進行確定性聚合，AI 代理負責分類切換結果並解釋證據。原型在沒有共用湖倉的情況下跑通，並非因為查詢引擎變得多餘，而是它被嵌入代理工作流程。
判斷為什麼不能只靠掃描指標
災難復原分析真正困難的地方，不是取出時間序列，而是決定時間序列代表什麼。假設 A 區被隔離、B 區仍在運作，一次健康的切換應該出現可辨認的順序：A 區的 QPS（每秒查詢數）下降，B 區的 QPS 相應上升，B 區的成功率維持在服務目標之上，尾端延遲可能短暫上升，但不應持續偏高。問題是上述每一句話都需要背景。QPS 上升不自動代表切換成功，因為上升幅度可能不足以承接隔離區失去的流量；成功率下降也不自動代表演練失敗，因為指標可能包含預期中的業務拒絕；切換邊界出現的延遲尖峰可能無害，只要系統很快回到穩定狀態。
因此分析採用兩個基準與一個穩定狀態窗口。歷史基準取前一天同一時間窗口，反映正常的日夜行為；即時基準取演練前一小時，反映最近的服務狀態；穩定狀態窗口排除切換後的短暫過渡期，聚焦持續行為。確定性程式針對每個服務計算四類核心訊號：QPS、錯誤 QPS、成功率，以及包含 p99 在內的延遲百分位數；再據此算出流量吸收比例、SLO（服務等級目標）違反情形、延遲變化與持續劣化的時間長度。代理拿到的是這些事實，而不是自行從數十萬列原始資料裡猜測。
三層架構與自我描述資料
整個流程分成三個邏輯層：資料準備、確定性計算、代理驅動的解釋，並把可重現性當成橫跨三層的要求。資料準備層用可重複使用的 DuckDB 建置邏輯，把原始指標轉換成物件儲存中具備自我描述能力的資產。每次演練的目錄包含可用演練索引、記錄結構定義與列數及檔案大小與校驗和的 manifest、演練設定、三十秒解析度的指標 Parquet，以及服務維度檔。manifest 特別重要，因為一個裝滿檔案的資料夾還稱不上可信的資料資產；取用者必須知道裡面有什麼、用了哪個結構定義、寫入是否完成、日後能否驗證。
DuckDB 這類嵌入式分析型資料庫用在儲存邊界的兩側。匯入時，它讀取原始指標、排序、寫出壓縮 Parquet，並產生供 manifest 使用的驗證統計；分析時，它直接讀取 Parquet，過濾相關窗口、連接服務中繼資料，算出代理所需的事實包。這種做法受益於幾個特性：DuckDB 在行程內執行，可以跟著代理工作流程移動，不必另外架設資料庫服務；它直接讀 Parquet，能把過濾與欄位選擇下推到掃描；它提供聚合與連接所需的 SQL 語意；較大的操作可以溢寫到本機儲存。重點不是 DuckDB 全面優於 Spark、Trino 或代管湖倉，而是這個工作負載當時還不需要共用的分散式引擎。
把確定性計算與機率推理分開
代理沒有收到數十萬列原始指標，也沒有被要求自行計算錯誤數或平均延遲。它收到的是一份緊湊的事實包，例如某服務在切換後穩定窗口的預期接手 QPS 為一千二百、實際觀察到增加九百一十、流量吸收比例零點七五八、成功率基準零點九九九二、演練期間成功率零點九九四一、服務 SLO 零點九九九零、p99 延遲由八十四毫秒升至一百九十一毫秒、持續劣化十八分鐘。代理據此輸出分類、信心水準、支持證據與建議的下一步，例如判定為部分切換，並建議檢查路由容量與下游依賴限制。數字來自引擎，模型的責任是決定這些數字該如何解讀與溝通。
單一門檻規則並不總是夠用。某個服務可能在切換後立刻超過 p99 門檻，但流量其實已正確移轉、可用性也仍在目標內；把任何門檻違反都當成失敗的規則，會把它誤判為劣化。代理可以比較過渡窗口與穩定窗口，看出延遲在幾分鐘內回到基準，進而判定為成功切換但伴隨短暫劣化。更麻煩的是證據彼此衝突：服務吸收了預期流量、自身延遲也恢復，但下游依賴正接近飽和；或者非同步服務出現暫時積壓卻未違反可用性目標，而同樣模式出現在同步依賴就值得升級處理。確定性層仍負責產生流量轉移、延遲、成功率、積壓、依賴飽和度、服務層級與 SLO 狀態等事實，代理則結合服務背景，決定哪些證據最重要。
這套分工可以稱為確定性分割。過濾、聚合、連接、排序、窗口計算、可精確重現的數值結果、成本隨資料量成長的操作、資料品質檢查，交給引擎；挑選相關證據、解釋為何重要、分類切換行為、提出調查方向、處理背景與取捨、在證據不足時放棄下結論，交給代理。這樣做也避開一個常見的反模式：把大型語言模型當成查詢引擎。語言模型不應該讀取數十萬列資料再自行計算錯誤數、百分位數或平均值，因為那既慢、耗費大量 token，也難以重現，更把確定性工作交給機率系統。較安全的模式，是讓確定性引擎產生少量具權威性的事實，允許代理產生受限制的 SQL 或 Python，透過確定性工具執行，再把事實包連同必要背景交給模型，並要求模型引用事實包裡的欄位來說明結論，同時保留輸入、產生的程式碼、執行中繼資料與輸出，以供重播與稽核。
規模、限制與何時該升級
演練資料集包含一百一十二萬七千七百四十八列事實、一千五百二十三個服務，壓縮後的 Parquet 約三點八 MB；上游收集作業以並行工作者執行，約花一小時。這個分析資料集小到足以讓嵌入式引擎在代理附近處理，不需要引進共用資料平台。這點值得注意，因為架構決策應該跟著實際工作負載走，而不是跟著「大數據」這個標籤走。超過一百萬列在設計會議裡聽起來很大，但列數本身不是部署分散式湖倉的充分理由；欄位數、壓縮率、查詢形狀、並行度、存取模式與資料移動量都會影響判斷。
原型要成為工程系統，關鍵在於把可重現性當成第一級需求。每次演練都保留一份重播包，內容包含 Parquet 輸入、manifest 與校驗和、演練設定、產生的 SQL 或 Python、執行中繼資料、確定性衍生事實、模型輸出、代理版本與提示，以及模型識別碼。有了這份重播包，就能離線重跑分析、調查有爭議的結論，或拿同一批證據比較兩個代理版本的行為。資料語意也被明確編碼。一個細微例子是缺失值的意義：缺少 QPS 或錯誤計數，在某些情境下可能代表沒有活動；缺少成功率或延遲資料，通常代表沒有流量可供測量，而不是成功率為零或延遲為零毫秒。把所有缺失值補成零，會製造出假失敗與假恢復。
代理加 DuckDB 不是每個分析系統的最終架構，它只在工作負載形狀合適時成立。文章提出四個訊號，指出輕量架構開始承受壓力的時機，而且每個訊號對應的能力可以逐步引進。第一個訊號是出現獨立取用者：當儀表板、排程工作、筆記本或其他團隊需要直接存取，資料就需要穩定契約，共用目錄能讓他們用名稱找到資料表、理解結構定義、套用權限，並透過標準工具查詢。第二個訊號是資料大到不方便搬到代理環境：到了 TB 等級，查詢應該在資料所在處執行，搭配分割裁剪、述詞下推與分散式處理，只把結果送回代理。第三個訊號是工作流程必須與大型共用資料集連接：當另一邊是組織級權威資料、已登錄在共用目錄中，而且太大或更新太頻繁而不適合安全匯出，較可靠的做法是把新資料登錄到同一個環境，透過共用引擎執行連接。第四個訊號是需要並行寫入或資料表層級的演進：單一寫入者慣例會在多個生產者更新資料、結構定義獨立演進，或讀者需要一致快照時失效；Apache Iceberg 這類開放資料表格式會在 Parquet 檔案之上加入資料表中繼資料、快照、結構演進與交易式提交語意，代管湖倉則可把目錄、開放資料表格式與共用查詢引擎三項能力結合起來。
這些能力有價值，但會帶來整合、治理、運算與維運成本，應該回應真實的共享、規模與交易需求，而不是因為每個 AI 專案都被假定第一天就需要湖倉。真正的架構取捨不是 AI 對 SQL，也不是檔案對資料表，而是代理背後需要多少分析基礎設施。聚焦的工作流程可能用一個小型嵌入式引擎就夠；共用目錄、開放資料表格式與分散式引擎，應該等到共享、規模、寫入並行或治理出現具體需求時再引進。引擎仍然存在，改變的是介面。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。