LangChain如何構建以代理為先的資料棧

在過去一年中，LangChain的資料團隊重新思考了如何讓資料棧支援代理。大多數公司的資料棧圍繞儀表盤、報表和SQL工作流構建，這些仍然有用，但代理改變了資料層需要提供的內容。當代理擁有清晰的定義、可信的來源、業務上下文以及資料背後的邏輯時，它可以回答更多問題。如果沒有這些上下文，代理可能生成SQL，但答案難以信任——它可能錯過公司特定的定義，使用錯誤的表，或者以技術上正確但對業務無實際幫助的方式回答問題。

團隊進行了一次重大的架構轉變，從以傳統BI工具為中心的資料棧，轉向為自助分析、共享上下文和代理使用而設計的棧。結果顯著：他們的自助資料代理現在處理的請求量是三人資料團隊直接處理的約40倍。過去30天內，近100%的已配置使用者（公司三分之一的人）使用了資料代理，共約2200次對話，平均每位使用者每月23次。

在遷移之前，幾乎每個資料請求都要經過資料團隊，當時團隊只有一人。傳統的BI工具適用於預定義報告，但靈活性差，探索性分析難以協作、分享，外部人員除非資料已經建模並暴露在BI層，否則無法自行探索。這造成了瓶頸：公司里人們有好的問題，但回答通常需要資料團隊成員翻譯問題、找到正確的模型、編寫或調整查詢、驗證結果並返回答案。資料團隊花了大量時間處理一次性請求，而不是專注於深入分析、建模和跨職能專案。

團隊需要一種代理優先的棧，能夠同時支援多種使用者：一些人想要精美的儀表盤，一些人想要筆記本和SQL，還有一些人想要對話介面。工程師和技術人員需要靈活性，而業務使用者需要更安全、有指導的探索方式。他們還希望有一個統一的資料工作中心，最終選擇了Hex，因為它支援儀表盤、筆記本和對話分析，並整合了AI功能。使用者透過Hex UI（包括Threads和筆記本）、Slack、CLI工作流、MCP以及LangSmith Fleet與代理互動。這種廣泛的覆蓋範圍對採用很重要，因為人們可以在他們工作的工具中使用代理。

遷移後，團隊在六週內100%遷移了舊BI工具。現在100%的公司員工以某種形式使用代理優先的資料棧。約70%的使用者擁有隻讀訪問許可權，30%擁有代理訪問許可權，且角色透過IT自助服務，任何需要的人都可以請求代理訪問。許多對話對應的是以前會透過資料團隊的問題，但到達資料團隊的問題現在更復雜、更具高槓杆作用。團隊花費更多時間在需要更深業務上下文、更強資料建模或跨職能一致性的工作上。

代理體驗依賴於上下文。上下文來自多個層次：dbt模型定義、語義模型、業務上下文指南、信任訊號（認可）和GitHub實現細節。dbt中的列定義應該不僅說明欄位是什麼，還要解釋業務含義、允許值和預設過濾規則。語義模型定義指標（如ARR、管道）和模型關係，保持定義一致性。Hex工作區指南捕獲不屬於明確定義的業務過程、團隊特定工作流和報告約定。認可訊號幫助代理知道哪些資料來源和資產是可信的，只有資料團隊可以標記認可。GitHub提供dbt倉庫中的實現上下文，使代理能夠檢查底層模型邏輯。

團隊透過可觀測性工具（如Hex的Context Studio或LangSmith）改進系統，檢視對話趨勢、常見警告和上下文差距，從而決定如何提升棧的質量。