Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla
三句話摘要
企業數據代理存在的三個結構性問題：歧義、陳舊和偏好，需要從架構設計而非單純擴大模型著手解決。 企業數據代理的成敗取決於架構設計和管理流程，而非單純依賴更強大的模型——需要分層的真理來源、自動化的上下文生命週期，以及身份感知的偏好路由。 真理來源應分層設計。將知識庫按清晰度與靈活性分為三層：語義層（最清晰但最不靈活）、規範表格（中等靈活性）、資料庫圖（最靈活但維護成本最高）。代理應從最清晰的層級開始逐步過渡，這樣既能確保準確性又能提升靈活性。
重點整理
重點- 1
真理來源應分層設計。將知識庫按清晰度與靈活性分為三層：語義層（最清晰但最不靈活）、規範表格（中等靈活性）、資料庫圖（最靈活但維護成本最高）。代理應從最清晰的層級開始逐步過渡，這樣既能確保準確性又能提升靈活性。
- 2
建立上下文生命週期機制。嵌入經常更新的活資料來源（如 GitHub、CRM、語義層），並配合回饋循環捕捉每個錯誤事件。定期記錄、評估和更新代理上下文，才能跟上業務變化的速度。
- 3
偏好問題需要身份路由。由於不同團隊對同一指標的定義和計算方法存在主觀差異，最終解決方案應根據用戶或團隊的身份將代理路由到正確的指標定義，而非依賴單一標準答案。
實用技巧與重點
乾貨- 真理來源三層結構：語義層（KPI 定義、指標計算方法、業務定義）、規範表格（參數查詢組）、資料庫圖（表與列的連接關係圖）
- 80% 問題可由前兩層解決，剩餘 20% 才需資料庫圖
- 活資料來源包括：GitHub、CRM 工具、Tableau、DBT、語義層
- 回饋循環的兩部分：事件捕捉記錄（數據正確性、定義更新、篩選條件變更）+ 自動化評估（對比過去問題與實際答案的接近度）
- 偏好解決方案：語義層存儲多種計算方法、代理記憶（如 MemZero）、身份路由機制
結論
結論“企業數據代理的成敗取決於架構設計和管理流程，而非單純依賴更強大的模型——需要分層的真理來源、自動化的上下文生命週期，以及身份感知的偏好路由。”
完整解析
詳細企業數據代理常常失敗，但根本原因往往被誤解。當代理給出錯誤答案時，人們直覺地認為需要更大的模型、更新的技術或更多的上下文知識庫。然而，伊希塔·達加指出，這些表面解決方案並未觸及問題核心。真正的挑戰在於代理對知識結構的管理方式。
第一個核心問題是歧義。代理無法判斷應該使用哪個真理來源——是該查詢哪個表、哪一列，還是應該訪問哪個知識庫？當一個企業擁有多個資料來源時，代理無法區分優先級。解決方案是將真理來源分層：最頂層是精心整理的語義層，包含所有 KPI 定義和業務規則，代理可以直接參考；中層是一組規範查詢表，賦予代理更多靈活性去選擇查詢邏輯；底層是完整的資料庫圖，允許代理在必要時進行復雜聯接。這種分層方式讓代理從最清晰的答案開始，逐步過渡到更動態的資料來源，效率和準確性兼顧。
第二個問題是陳舊。企業環境變化極快，KPI 定義、流程、篩選條件不斷更新，但維護代理的上下文卻異常困難——文檔頻繁過時，技能配置難以同步。解決方案是建立「上下文生命週期」：嵌入經常自動更新的活資料來源，確保代理總是獲取最新資訊；同時建立回饋循環，捕捉用戶報告的每一個錯誤或變更需求，記錄這些事件，並定期評估代理性能。通過自動化評估對比過去數天的提問與實際答案，可以驗證上下文是否仍然準確。
第三個問題是偏好，也是最具挑戰性的。假設 A 團隊和 B 團隊都需要計算「完成里程碑的平均時間」，但 A 團隊是從上一里程碑完成到當前里程碑完成，而 B 團隊是從當前里程碑開始到下一里程碑開始。兩種計算都沒錯，但結果完全不同。這是純粹的主觀偏好問題。目前業界還沒有完美解決方案，嘗試過的方法包括在語義層存儲多個定義讓用戶選擇、或使用代理記憶存儲個人偏好，但都無法根本解決問題。真正需要的是根據用戶或團隊身份自動路由到正確指標的機制。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
