不整虛的！SQL Agent從規劃、建設到落地的完整范例

作者：宋鑫 2025-09-19 07:24:43

首效空間聚焦于數據治理。數據乃后續智能服務之基，唯規范、清潔、口徑一致，方能保障知識精度與模型輸出唯一性。若底表體量臃腫，既拖慢 SQL 執行，又徒增 AI 認知負荷；若指標口徑多元，同一問題即可能衍生多套結果， Agent 精準生成 SQL 更無從談起。因此，構建高質數據環境乃 SQL Agent 落地之前置條件。

一、背景介紹

二、方案演進與設計

三、落地效果與經驗總結

四、未來規劃

一、背景介紹

1、當前取數流程

圖片

當前公司內部數據分析流程如下：產運人員提出數據需求后，數據分析人員并不立即執行查詢，而是啟動一套標準排期流程。排期人員首先核驗現有數據表是否可滿足需求；若無法滿足，則需先編寫腳本清洗并重構數據表，再撰寫 SQL 完成查詢，最終將結果反饋產運。整個過程中，產運人員因不具備 SQL 能力，只能等待結果返回后方可推進后續工作。

2、當前存在的問題

圖片

基于上述流程，當前主要存在三大痛點：

1）查數難。業務場景復雜、數據體量大，底層表規模龐大；同時數據管理缺乏統一規范，臟數據泛濫，業務口徑多元且隨需求頻繁調整，導致定位準確數據耗時費力。

2）取數難。產運人員普遍缺乏 SQL 編寫與解讀能力，復雜查詢完全依賴數據分析人員；數分側亦需投入大量時間撰寫與調試高復雜度 SQL，且既有腳本復用、改造成本高，需求積壓現象突出。

3）使用難。用戶獲取 SQL 后，需經歷復制、粘貼、提交、等待等多環節，操作流程冗長；交互界面友好度不足，體驗欠佳，差錯率居高不下。

公司內部對 2024 年 Q4 取數情況統計顯示，人均跑數量、跑數失敗率及人均跑數時長均存在顯著優化空間。

3、提效空間

圖片

基于上述痛點，可將其歸集為兩大核心問題：一是數據本身質量與規范缺失，二是 SQL 生成流程效率低下。

由此，明確兩大提效空間：

數據治理：通過統一標準、清洗臟數據、固化口徑，解決“查數難”；
智能 SQL 生成：引入 Agent 自動撰寫與改寫 SQL，替代人工，降低“取數難”與“使用難”。

二、方案演進與設計

1、數據是基石

圖片

該環節由機票業務團隊主導，已完成以下工作：

字段補全：對接產運，梳理缺失字段并補充完善；
底層基建：開展數據清洗、統一口徑，對缺失字段埋點回溯，構建輕量級 DWD 中間表，壓縮數據規模；
標準沉淀：建立企業級數據字典，實現指標口徑統一與元數據共享。

2、SQL Agent的初探

圖片

以下回顧 SQL Agent 的完整演進歷程。項目伊始經驗有限，團隊先行構建單體 Agent，注入必要知識庫后即開放生成能力。初版流程如下：

需求判定：用戶輸入問題后，Agent 首先識別其是否屬于 SQL 范疇；若否，則引導用戶重新表述。
場景定位：依據用戶所屬部門加載對應業務知識庫。
信息補全：評估問題完整度，必要時提示用戶補充關鍵信息。
表集遴選：交互結束后，Agent 篩選本次查詢所需表集并獲取元數據。
條件補全：調用工具獲取默認過濾條件。
SQL 生成：整合上述信息生成最終 SQL 并返回用戶執行。

右側展示初版 Agent 的提示詞及運行效果，可見系統通過多工具協同完成信息采集與 SQL 輸出。

3、初次探索存在的問題

圖片

以下闡述 SQL Agent 的演進歷程。初始階段經驗有限，團隊先行搭建原型 Agent，并以必要知識庫灌注，使其具備生成 SQL 之能力。初代流程概覽如下：

需求識別：用戶提出問題后，Agent 先行判定其是否屬于 SQL 范疇；若否，則引導用戶重新表述。
場景定位：依據用戶所屬部門，加載對應業務知識庫。
信息補全：判斷問題完整度，如需補充，則提示用戶提供關鍵信息。
表集遴選：交互完畢，Agent 篩選本次查詢所需表集，并獲取其元數據。
條件補全：調用工具獲取默認過濾條件。
SQL 生成：整合上述信息生成最終 SQL，并返回用戶執行。

右側展示了 Agent 的提示詞與運行效果，可見系統通過多工具協同完成信息采集與 SQL 輸出。

4、首次拆分-優化 Agent

圖片

以下為拆分后的流程說明。原單體 Agent 被解耦為「SQL 生成 Agent」與「SQL 優化 Agent」：前者保留需求識別、表集遴選及初版 SQL 編制職責；后者獨立承擔后置優化，包括格式修正、語法校驗、默認條件補全及內置邏輯注入。

流程保持不變，生成 Agent 完成初版 SQL 后直接交付優化 Agent；優化 Agent 完成上述檢查后輸出最終語句并返回用戶。右側給出優化 Agent 的提示詞與效果示例，可見其對原語句補充默認條件并完成格式統一。

該版本上線后，SQL 準確率顯著提升，但仍存在以下待解決問題。

5、存在的問題

圖片

這一版跑通了以后，我們交付給用戶進行試用，隨后暴露出哪些問題呢？

首先，雖然我們將語法檢查拆出來了，并且效果有提升，但是我們發現，生成的sql還是有小概率語法錯誤，

其次，有些工具可能一次調用并不能滿足我們的場景，并且任務復雜，沒有一個任務規劃。

基于此，我們決定引入react機制，讓ai先思考，然后在行動，觀察結果，根據結果在思考決定下一步行動，直到解決問題。

6、引入React機制

圖片

現將單體 Agent 拆分為「SQL 生成 Agent」與「SQL 優化 Agent」。生成 Agent 承繼原有需求識別、表集遴選、元數據獲取及初步 SQL 編寫功能；所有后置優化、格式修正、語法校驗、默認條件補全及內置邏輯注入等職責，則遷移至獨立優化 Agent。

流程如下：生成 Agent 完成 SQL 初稿后，直接交付優化 Agent；優化 Agent 對語句執行格式統一、語法檢查、條件補全及邏輯增強，最終輸出可執行 SQL 并返回用戶。右側列出優化 Agent 的提示詞及效果示例，可見其對原 SQL 補充默認條件并統一格式。

此版本上線后，SQL 準確率顯著提升，但仍存若干待解問題。

7、還有哪些問題？

圖片

引入 React 機制后，SQL 準確率再獲顯著提升。然而，隨著應用規模擴大，新的瓶頸逐漸暴露：

語義鴻溝：SQL 語義精確而自然語言含混，二者映射存在固有模糊性；
交互薄弱：Agent 缺乏主動澄清能力，無法就需求中的歧義項進行追問與確認；
入口疏離：用戶需跳轉至低頻使用平臺，拉長了操作鏈路。

鑒于生成 Agent 同時承擔“規則確認”與“SQL 生成”兩類異質認知任務，團隊再度拆分架構，并以公司 IM 工具為統一交互入口，使服務直達用戶常駐場景。

8、規則映射-引入問題細化Agent

圖片

本輪架構調整，新增“問題細化 Agent”，專司需求澄清與規則確認，原有生成 Agent 僅承擔 SQL 生成任務。其流程如下：

前置步驟保持不變：識別業務域并加載對應知識庫。
需求澄清：問題細化 Agent 對 SQL 關鍵要素逐一確認，包括分組字段、排序字段、指標口徑及同名異義項等，并將待確認信息回傳用戶。
用戶補充：用戶直接在飛書機器人界面完成補充或確認。
后續流轉：確認結果回傳系統，繼續執行 SQL 生成與優化流程。

入口已整體遷移至飛書機器人，用戶無需切換平臺即可完成交互。右側展示問題細化 Agent 的提示詞及運行示例：當用戶提出“查詢昨日總積分排名第二的代理商”時，Agent 主動追問時間范圍、分組維度等信息；用戶確認無誤后，流程即刻推進。

9、神奇的現象

圖片

該版本上線后，整體表現已趨穩定：同名異表、遺漏分組等差錯顯著減少。然而，伴隨使用深入，出現一類新型異常。

左側所示用例頗具代表性——用戶僅提出“查詢昨日積分第二名的代理商”。表面看需求明確、SQL 亦不復雜，但 Agent 在兩種等價卻結果迥異的語句間隨機切換，用戶最終所需為第一種，遂反饋“AI 答案不準，可否固化”。初期結論將其歸因于模型固有隨機性。隨著同類案例增加，團隊重新審視，并經差異比對與模型追問，確認根源在于用戶文本表述存在歧義。