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）改進系統，查看對話趨勢、常見警告和上下文差距，從而決定如何提升棧的質量。