AICON：DataAgent生產化路徑

從「模型夠強嗎」到「產品能落地嗎」

巴志欣觀察到，企業對 AI 的提問正在改變。早期，大家關心產品與同類方案相比有何差異；隨著通用大模型快速進步，問題轉為：既然模型已經很強，企業為什麼還需要一個 Agent？答案不在於和通用模型比誰更聰明，而在於能否在企業的真實資料場景裡，穩定完成任務。

• 企業買單的依據，是任務是否真的具備應用價值，而不只是模型展示效果。
• 衡量落地品質，必須同時看任務完成度、準確率與 token 消耗。
• 通用 Agent 擅長跨產品、跨工具的廣泛協作；DataAgent 則應垂直聚焦企業內部的資料與資料工程場景。

General AgentDataAgent垂直聚焦任務完成度準確率token 消耗

「我最終才會為你這個產品買單。」
— 巴志欣

這種垂直聚焦不是縮小能力，而是重新定義價值：讓 Agent 深入企業資料環境，在既有產品與資料工程流程中推動自動化。當問題變得具體，Agent 才能不只「會回答」，更能沿著正確路徑完成工作。

單點工具調用，不足以承接資料工程

一個資料工程任務通常不是呼叫一次工具就結束。以任務維運為例，看到錯誤日誌後，還要檢查資料狀態、追查上游任務、比對更多日誌，再把分散訊息整合成原因判斷與處置方案。這是一段工作流，不是一個答案。

「一個數據工程的任務，它並不是單點去調用工具。它背後是一個很長串的一個工作流。」
— 巴志欣

分享團隊根據線上使用者的真實使用情況整理出高頻場景，包括資料鏈路開發、任務維運與資料探查。這些場景背後都有完整的使用者故事，因此產品不能只把工具堆在一起，而要依照任務情境安排理解、規劃、探查、執行與驗證。

語義層：讓業務語言真正落進數倉

資料場景的第一道難關，是複雜的語義管理。語義不只是替指標加上說明，而是串起資料資產與上層 AI 應用的橋梁。當使用者問的不只是「銷售是多少」，而是帶有時間、趨勢、人員變化與交叉比較的分析問題，僅靠單一指標口徑或 Text-to-SQL，很難保證每次查詢都精準。

• 語義管理的困難，在於複雜業務語句背後往往涉及多個指標、維度與關聯關係。
• 若業務端與數倉端的口徑沒有對齊，AI 查出的數字可能與既有看板不一致。
• 語義的建立需經歷表資訊探查、資料結構理解、維度與指標分析，才能沉澱成可驅動業務的標準。

語義層指標口徑Text-to-SQL資料倉儲資料治理

講者提出的方向，是將語義下沉到原始資料與數倉體系，和結構化資料表、非結構化資訊同等看待。除了指標與維度，企業慣用的行業黑話、別名等語境資訊，也應成為數倉中的資料資產。如此一來，後續分析與 AI 查詢不必反覆猜測業務語言，而有可依循的底層基礎。

在產品能力上，這套語義層涵蓋建立、度量與優化、消費，以及血緣追蹤。企業可對接既有指標管理工具，也可從使用者問答中沉澱語義；若指標口徑更新，後續加工鏈路可隨血緣追蹤而更新，減少人工逐一尋找與修改的負擔。

把上下文變成工程，而不是任憑對話膨脹

資料工程的上下文特別容易失控：探查一張明細表，回傳結果可能成千上萬筆；一段長流程又可能從需求理解，一路延伸到數倉模型、系統節點與 Pipeline 設計。若再把不同問題混在同一段對話裡，先前資訊還可能干擾後續判斷。

• 以多 Agent 分工，分別處理規劃、執行與探查，避免單一 Agent 在跨場景中混淆。
• 工具按需載入，降低不必要的工具與資訊進入上下文。
• 大型結果以受控方式呈現；若使用者需要完整資料，可存放於物件儲存並提供下載，而非將全量內容塞進對話。
• 採分層壓縮策略，優先保留最近幾輪的完整資訊，並將目標、工作與產物等關鍵內容壓縮為摘要。

上下文工程多 Agent工具按需載入物件儲存上下文壓縮

這種設計的重點不是一味縮短內容，而是在長鏈路中保住真正會影響決策的資訊。尤其資料工程裡，目標、已完成的工作與產出物都會左右下一步；壓縮若失去這些脈絡，對話再短也沒有意義。

安全與可靠性，必須走進生產閉環

當 Agent 可以調用資料工具、執行 SQL 或觸及寫入操作時，安全不再只是權限設定，而是如何避免模型幻覺、探查行為或使用者誤操作影響線上資料。對可能造成重大影響的操作，系統必須把「能不能做」與「是否真的要做」分開處理。

• 以沙箱隔離 Agent 的規劃與探查，避免直接影響線上生產資料。
• 系統先識別高風險行為，再由工具層進行二次判斷與攔截。
• 高風險操作必須經使用者確認後才能執行，不能只依賴模型自行判斷。

可靠性同樣不能只做事前測試。講者主張建立事前、事中、事後的閉環：上線前設定品質閾值與評測；上線後追蹤使用者行為、工具調用鏈路與 token 消耗；再定期人工抽檢線上失敗案例，將未覆蓋或不可控的情境帶回測試與迭代體系。

沙箱隔離高風險攔截使用者確認可靠性評估可觀測性

兩條長鏈路：資料開發與任務維運

在資料鏈路開發場景中，Agent 要協助承接的並非單一程式任務，而是從業務需求溝通、口徑釐清、資料表關聯、語義沉澱、數倉建模，到 Pipeline 規劃與上線的一整段流程。分享中的設計，是先將使用者輸入整理為標準化需求文件，再沉澱為數倉中的語義與元資訊，接著規劃模型與鏈路，最後才進入部署。

「從需求到語義到建模到上線的一整條的長鏈路一套設計。」
— 巴志欣

任務維運則呈現另一種長鏈路：系統需要匯集錯誤日誌、上下游任務與相關資訊，重組成可判讀的問題脈絡，再尋找對應的業務知識與處理方案。對方案本身，分享提出先在沙箱驗證；確認可靠後，再提供給使用者。

講者也坦言，這類能力不必一開始就覆蓋所有情境；若能覆蓋企業內部約七到八成的高頻場景，已可為日常探查與維運帶來顯著效率提升。生產化的價值，正在於用可控的範圍，持續累積可複用的可靠能力。

重點回顧

• DataAgent 的競爭力不在於取代通用模型，而在於垂直聚焦企業資料場景，交付可衡量的完成度、準確率與成本表現。
• 從 Tool Calling 到生產化 Agent，必須把單點工具串成可規劃、可驗證的完整工作流。
• 語義層應下沉至數倉，讓指標、口徑、維度與企業別名成為可治理、可追溯的資料資產。
• 上下文工程要以分工、按需載入、受控輸出與壓縮機制，處理資料工程的長鏈路與大量結果。
• 安全與可靠性需要沙箱、風險攔截、使用者確認，以及事前到事後的持續評估閉環。

「它不是一個功能。」
— 巴志欣