a16z：Agent 表現不好，可能是缺乏正確的數據上下文

市場終于明白了，數據和分析 Agent 要是沒有正確的上下文，基本等于擺設 本文是翻譯稿，原文出自 a16z，地址： https://www.a16z.news/p/your-data-agents-need-context

最近在數據和 AI Agent 的圈子里，上下文層和上下文圖譜成了一個繞不開的話題。跟任何一個做數據和 AI 的組織聊天，不出五分鐘就會聊到上下文這個話題

這很正常。過去一年，市場終于想明白一件事：數據和分析 Agent，如果沒有正確的上下文，基本上就是廢物

它們拆不開模糊的問題，讀不懂業務定義，也沒辦法在分散的數據之間有效地推理

這怪不了 Agent。現代數據棧經歷了十多年的演進，從分散的數據源走向集中化的數據和清洗過的定義，這是好事。但集中化從來都做不到完美，過程中引入了大量的混亂。大致的演進脈絡是這樣的：

1、現代數據棧的崛起
我們之前跟 dbt 的 Tristan Handy 聊過這個話題，也在自己的參考架構文章里寫過。過去十年，數據架構在攝取、轉換、倉庫和存儲各個環節都經歷了改造，目標是把數據集中起來，讓人能快速方便地用上。理想的畫面是：數據整理干凈了，團隊寫寫 SQL 就能從數據倉庫里提數據，做圖表，做儀表板，讓整個組織都用上商業智能

2、Agent 狂潮
2024 年進入 2025 年，LLM 的能力越來越強，幾乎每一個組織都想在現有的數據棧上搭 Agent。我們以前討論過怎么定義 Agent。從組織的角度看，用更少的時間做更多的事，提升效率，這種天然的吸引力把大家都拉向了 Agent 化的工作流。各公司開始做「跟你的數據聊天」的聊天機器人，做客服 Agent。這股熱潮自下而上和自上而下同時發生。開發者想用上最新最亮眼的 LLM 能力，管理層在施壓要求 AI 落地，提高自動化，降低成本

3、撞墻
樂觀沒持續多久。很快就清楚了，大多數這類努力都失敗了。組織們部署 Agent，撞了墻。MIT 發表了那份著名的「2025 年商業 AI 現狀」報告，說 AI 部署「大多數失敗是因為脆弱的工作流、缺乏上下文學習能力、以及與日常運營的脫節」

Agent 表現不好，一個關鍵原因是缺乏恰當的數據上下文。今天的企業數據依然極度分散和混亂。數據 Agent 連「上個季度的收入增長是多少？」這樣的問題都答不好，因為它面對的是橫跨結構化和非結構化數據的各種架構

多年前「完全自助式分析」的愿景沒有實現。而在數據 Agent 的愿景上，似乎也走上了同一條路

上下文問題：遠不止 text-to-SQL

最初那一波 Agent 部署，到底為什么舉步維艱？

起初很多人覺得，問題在模型那邊，是數據推理能力和 SQL 代碼生成能力不夠。一般的想法是這樣的：模型接收一個自然語言查詢，對現有的數據系統做推理，按照傳統 BI 的方式生成對應的 SQL 代碼，拉取正確的數據，回答問題。如果模型失敗了或者不準確，那就是模型 SQL 寫得不好，等它慢慢變強就行了

這話也不算全錯。模型在代碼生成和數學推理方面的能力確實大幅提升了，但在數據方面仍然落后，Spider 2.0 和 Bird Bench 這些 SQL 基準測試可以佐證。模型能力確實有了飛躍，但我們很快意識到，問題遠遠超出了 text-to-SQL 的范疇

把收入增長的例子再拆細一點來看：

1. 1. 假設一個數據 Agent 在組織內部建好了。用的是現代基礎模型，連上了所有該連的數據源，配了個漂亮的界面，讓內部用戶可以來問數據問題

2. 2. 查詢來了。「上個季度的收入增長是多少？」一個看起來很簡單的問題。平時看一眼 Looker 或者 Tableau 儀表板就能答上來，對一個高級智能 Agent 來說應該不難吧
   3. 挑戰一：Agent 怎么知道這個組織里「收入」和「季度」到底是怎么定義的？ 收入其實是一個業務定義，并沒有硬編碼在數據倉庫或管道里。用戶要看的是 run rate 收入還是 ARR？財務季度的劃分在不同組織里可能完全不一樣，換一家公司，同一個「季度」對應的三個月可能完全不同。該看什么時間窗口？

3. 3. 好在數據平臺負責人站出來說：「我們建了語義層，專門解決這個問題，收入定義就在里面。」Agent 應該能把所有語義層作為上下文吃進去。聽起來有前途。但團隊翻了幾個 YAML 文件之后發現，這些文件是去年離職的一個數據團隊成員更新的，BI 工具已經不再調用它們了，而且也沒有包含后來新上線的兩條產品線。Agent 根本不知道收入在今天到底怎么算

4. 4. 為了繞過這個障礙，有人手動把收入和時間窗口的定義硬編碼進去了。數據 Agent 繼續跑，但很快又撞上了 挑戰二：正確的數據源在哪里？哪些才是真正的事實源？ 原始數據分散在多張表和多個數據倉庫里。財務團隊用的是 fct_revenue 表，可能是對的。但數據團隊還建了物化視圖， mv_revenue_monthly 和 mv_customer_mrr 都擺在那里

很明顯，數據 Agent 需要一個持續更新的知識庫，里面裝著業務定義和數據源信息，才能翻過這些坎兒

上下文層登場

問題的要害在這里：Agent 沒有被給予恰當的業務上下文，連最基本的問題都答不了。這反映的是一個更大的缺口。在組織內部構建自動化 AI 系統，需要有持續更新和維護的上下文。這個上下文要理解企業怎么運作，數據系統怎么組織，還要承載那些把一切串起來的部落知識

由此催生了上下文層。今天的討論里冒出來很多名字，Context OS、Context Engine、上下文數據層、本體論（ontology），等等。底層概念是一樣的：把企業所有混亂的數據串聯起來，在上面加一個幫助 Agent 理解業務邏輯的上下文層，封裝好，讓 Agent 能用上

上下文管理的既視感

這里停一下...我們說的這些，聽起來跟語義層（semantic layer）是不是太像了？

確實有相似之處。但如果 Agent 工作流要真正走向自主化，它們需要的東西比目前語義層所能提供的更多

傳統 BI 語境下的語義層，擅長處理特定的指標定義，比如收入、流失率、ARPU。但它們通常是數據團隊用非常特定的語法手動構建的，通過 LookML 這樣的專用層來寫，直接連到 Looker 這樣的 BI 工具上

現代數據上下文層應該成為傳統語義層所覆蓋內容的超集
特定的指標定義當然可以硬編碼，但一個現代上下文層要保證 Agent 的自主性，就得包含更多：規范實體、身份消解、拆解部落知識的具體指令、恰當的治理指引，等等

本文主要聚焦于串聯傳統記錄系統的數據上下文。另一個同樣重要且有重疊的機會是，捕獲組織的決策邏輯和工作流邏輯，這樣才能造出真正多用途的 Agent，讓它們扎根于組織的全部數據和決策上下文之中

全部串聯起來

基于我們最近跟客戶的交流和對需求的理解，以下是我們認為一個現代上下文層配合 Agent 化數據系統應該有的樣子，分步來講：

1、接入正確的數據
第一件事是確保所有正確的數據都是可訪問的。這是基本功。理想情況下，組織應該在用某種形式的現代數據棧，通過湖倉一體架構做一定程度的統一。即便如此，還得確保 Agent 能訪問它需要的所有數據，可能超出倉庫和操作型應用里已有的范圍。內部系統里沉淀的部落知識，GDrive 里的，Slack 里的，都算

2、自動化上下文構建
數據都能訪問了，下一步是開始建上下文層。用 LLM 的好處是，初始的上下文收集工作很大程度上可以自動化。重點要放在高信號的上下文上。比如回顧歷史查詢記錄，可以高效地找出被引用最多的表和最常見的 join。dbt 或 LookML 這樣的數據建模工具，能為業務指標提供清晰的定義

3、人工精修
自動化上下文構建也許能覆蓋語料的大部分，但拼不出完整的圖景。讓 Agent 自己去收集所有內部知識，想法很誘人，但一些最重要的上下文是隱式的、條件性的、跟歷史偶然相關的，只存在于團隊內部的部落知識里

人工輸入提供了最后那些關鍵的連接，讓 Agent 的真正自動化成為可能。比如：「CRM 數據，2025 年之后所有北美新交易看 Affinity，之前的全球線索看 Salesforce。」

這樣上下文層就可以變成一個多維語料庫，代碼和自然語言共存，捕獲 Agent 可能需要的一切上下文。就像開發者可以設置 .cursorrules 文件來引導 Agent、控制輸出行為一樣，數據從業者也可以維護自己的規則和指引

4、Agent 接入
上下文層建好了，把它暴露給 Agent，實現實時可訪問就行。通常通過 API 或 MCP 來完成

5、自更新的上下文流
系統搭好了，但數據系統永遠不是靜態的，上下文層也不應該是。上游的數據源和格式可能會變，人員可能有自定義指令想根據業務需求的變化來增刪修改。數據 Agent 給出了錯誤的數據需要修正，修正內容當然也應該反饋回上下文層。這樣，上下文層就變成了一個活的、持續演化的語料庫

上下文層架構

從這整個過程里，可以看出來一件事：構建一個合格的數據 Agent 絕非易事
技術層面有數據基礎設施和工程的挑戰，人力層面有部落知識收集的挑戰，兩種挑戰攪在一起

OpenAI 團隊最近發了一篇很好的文章，詳細講了他們自己內部數據 Agent 的創建過程。寫得很透明，實現很細致也很優雅，但也說明了走到那一步需要多長的路。Palantir 在為組織構建本體論方面有很長的歷史，能從混亂的數據里理出清晰的上下文，靠這個建了一門大生意

市場走向

上面說的這些，自然為外部方案打開了一扇窗。現實地說，不是每個企業都能（或應該）自己在內部建這套東西。各種方案已經開始進入市場了

我們認為還處在早期階段，但以下是正在形成的方案的高層市場地圖：

市場地圖

分幾類來看：

數據引力平臺
Databricks 和 Snowflake 這樣的平臺，數據攝取、轉換、存儲的全流程都走過了，數據引力效應很強。它們已經在做 AI 數據分析產品，比如 Databricks Genie 和 Snowflake Cortex Analyst，建在數據倉庫之上，用基礎模型做 text-to-SQL，讓用戶可以用自然語言查數據。這些平臺目前還沒有特別成熟的上下文層功能，但支持輕量級的語義建模，通過收購或內部開發把上下文層引入平臺，路是走得通的

現有的「AI 數據分析師公司」
已經涌現了一批公司，用 AI 讓客戶「跟數據聊天」。很多公司在市場上摸爬滾打之后明白了，做好數據 Agent 的關鍵其實在于構建上下文層。于是一些公司已經把數據上下文構建變成了產品的核心部分

新興的、專門的上下文層公司
一個新品類出現了，從零開始建上下文層。它們要走完我們上面描述的整條路：攝取數據、收集部落知識，等等。而且每接一個新客戶，就得重新走一遍

往前看

我們現在，正處在一個有意思的節點上。缺乏上下文這個問題已經被看清楚了，但構建解決方案的工作仍然處在非常早期的階段

未來令人期待。也許真正自助式分析的愿景終于可以完全實現了。BI、數據分析和數據科學，可以被 AI 真正改變

當然，很多問題還是開放的。這個上下文層會住在哪里？它可以同時存在于多個地方嗎？它會成為一個獨立的產品嗎？