a16z：Agent 表現(xiàn)不好，可能是缺乏正確的數(shù)據(jù)上下文

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

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

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

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

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

1、現(xiàn)代數(shù)據(jù)棧的崛起
我們之前跟 dbt 的 Tristan Handy 聊過這個(gè)話題，也在自己的參考架構(gòu)文章里寫過。過去十年，數(shù)據(jù)架構(gòu)在攝取、轉(zhuǎn)換、倉庫和存儲(chǔ)各個(gè)環(huán)節(jié)都經(jīng)歷了改造，目標(biāo)是把數(shù)據(jù)集中起來，讓人能快速方便地用上。理想的畫面是：數(shù)據(jù)整理干凈了，團(tuán)隊(duì)寫寫 SQL 就能從數(shù)據(jù)倉庫里提數(shù)據(jù)，做圖表，做儀表板，讓整個(gè)組織都用上商業(yè)智能

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

3、撞墻
樂觀沒持續(xù)多久。很快就清楚了，大多數(shù)這類努力都失敗了。組織們部署 Agent，撞了墻。MIT 發(fā)表了那份著名的「2025 年商業(yè) AI 現(xiàn)狀」報(bào)告，說 AI 部署「大多數(shù)失敗是因?yàn)榇嗳醯墓ぷ髁鳌⑷狈ι舷挛膶W(xué)習(xí)能力、以及與日常運(yùn)營(yíng)的脫節(jié)」

Agent 表現(xiàn)不好，一個(gè)關(guān)鍵原因是缺乏恰當(dāng)?shù)臄?shù)據(jù)上下文。今天的企業(yè)數(shù)據(jù)依然極度分散和混亂。數(shù)據(jù) Agent 連「上個(gè)季度的收入增長(zhǎng)是多少？」這樣的問題都答不好，因?yàn)樗鎸?duì)的是橫跨結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的各種架構(gòu)

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

上下文問題：遠(yuǎn)不止 text-to-SQL

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

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

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

把收入增長(zhǎng)的例子再拆細(xì)一點(diǎn)來看：

1. 1. 假設(shè)一個(gè)數(shù)據(jù) Agent 在組織內(nèi)部建好了。用的是現(xiàn)代基礎(chǔ)模型，連上了所有該連的數(shù)據(jù)源，配了個(gè)漂亮的界面，讓內(nèi)部用戶可以來問數(shù)據(jù)問題

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

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

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

很明顯，數(shù)據(jù) Agent 需要一個(gè)持續(xù)更新的知識(shí)庫，里面裝著業(yè)務(wù)定義和數(shù)據(jù)源信息，才能翻過這些坎兒

上下文層登場(chǎng)

問題的要害在這里：Agent 沒有被給予恰當(dāng)?shù)臉I(yè)務(wù)上下文，連最基本的問題都答不了。這反映的是一個(gè)更大的缺口。在組織內(nèi)部構(gòu)建自動(dòng)化 AI 系統(tǒng)，需要有持續(xù)更新和維護(hù)的上下文。這個(gè)上下文要理解企業(yè)怎么運(yùn)作，數(shù)據(jù)系統(tǒng)怎么組織，還要承載那些把一切串起來的部落知識(shí)

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

上下文管理的既視感

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

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

傳統(tǒng) BI 語境下的語義層，擅長(zhǎng)處理特定的指標(biāo)定義，比如收入、流失率、ARPU。但它們通常是數(shù)據(jù)團(tuán)隊(duì)用非常特定的語法手動(dòng)構(gòu)建的，通過 LookML 這樣的專用層來寫，直接連到 Looker 這樣的 BI 工具上

現(xiàn)代數(shù)據(jù)上下文層應(yīng)該成為傳統(tǒng)語義層所覆蓋內(nèi)容的超集
特定的指標(biāo)定義當(dāng)然可以硬編碼，但一個(gè)現(xiàn)代上下文層要保證 Agent 的自主性，就得包含更多：規(guī)范實(shí)體、身份消解、拆解部落知識(shí)的具體指令、恰當(dāng)?shù)闹卫碇敢鹊?/p>

本文主要聚焦于串聯(lián)傳統(tǒng)記錄系統(tǒng)的數(shù)據(jù)上下文。另一個(gè)同樣重要且有重疊的機(jī)會(huì)是，捕獲組織的決策邏輯和工作流邏輯，這樣才能造出真正多用途的 Agent，讓它們?cè)诮M織的全部數(shù)據(jù)和決策上下文之中

全部串聯(lián)起來

基于我們最近跟客戶的交流和對(duì)需求的理解，以下是我們認(rèn)為一個(gè)現(xiàn)代上下文層配合 Agent 化數(shù)據(jù)系統(tǒng)應(yīng)該有的樣子，分步來講：

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

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

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

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

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

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

5、自更新的上下文流
系統(tǒng)搭好了，但數(shù)據(jù)系統(tǒng)永遠(yuǎn)不是靜態(tài)的，上下文層也不應(yīng)該是。上游的數(shù)據(jù)源和格式可能會(huì)變，人員可能有自定義指令想根據(jù)業(yè)務(wù)需求的變化來增刪修改。數(shù)據(jù) Agent 給出了錯(cuò)誤的數(shù)據(jù)需要修正，修正內(nèi)容當(dāng)然也應(yīng)該反饋回上下文層。這樣，上下文層就變成了一個(gè)活的、持續(xù)演化的語料庫

上下文層架構(gòu)

從這整個(gè)過程里，可以看出來一件事：構(gòu)建一個(gè)合格的數(shù)據(jù) Agent 絕非易事
技術(shù)層面有數(shù)據(jù)基礎(chǔ)設(shè)施和工程的挑戰(zhàn)，人力層面有部落知識(shí)收集的挑戰(zhàn)，兩種挑戰(zhàn)攪在一起

OpenAI 團(tuán)隊(duì)最近發(fā)了一篇很好的文章，詳細(xì)講了他們自己內(nèi)部數(shù)據(jù) Agent 的創(chuàng)建過程。寫得很透明，實(shí)現(xiàn)很細(xì)致也很優(yōu)雅，但也說明了走到那一步需要多長(zhǎng)的路。Palantir 在為組織構(gòu)建本體論方面有很長(zhǎng)的歷史，能從混亂的數(shù)據(jù)里理出清晰的上下文，靠這個(gè)建了一門大生意

市場(chǎng)走向

上面說的這些，自然為外部方案打開了一扇窗。現(xiàn)實(shí)地說，不是每個(gè)企業(yè)都能（或應(yīng)該）自己在內(nèi)部建這套東西。各種方案已經(jīng)開始進(jìn)入市場(chǎng)了

我們認(rèn)為還處在早期階段，但以下是正在形成的方案的高層市場(chǎng)地圖：

市場(chǎng)地圖

分幾類來看：

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

現(xiàn)有的「AI 數(shù)據(jù)分析師公司」
已經(jīng)涌現(xiàn)了一批公司，用 AI 讓客戶「跟數(shù)據(jù)聊天」。很多公司在市場(chǎng)上摸爬滾打之后明白了，做好數(shù)據(jù) Agent 的關(guān)鍵其實(shí)在于構(gòu)建上下文層。于是一些公司已經(jīng)把數(shù)據(jù)上下文構(gòu)建變成了產(chǎn)品的核心部分

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

往前看

我們現(xiàn)在，正處在一個(gè)有意思的節(jié)點(diǎn)上。缺乏上下文這個(gè)問題已經(jīng)被看清楚了，但構(gòu)建解決方案的工作仍然處在非常早期的階段

未來令人期待。也許真正自助式分析的愿景終于可以完全實(shí)現(xiàn)了。BI、數(shù)據(jù)分析和數(shù)據(jù)科學(xué)，可以被 AI 真正改變

當(dāng)然，很多問題還是開放的。這個(gè)上下文層會(huì)住在哪里？它可以同時(shí)存在于多個(gè)地方嗎？它會(huì)成為一個(gè)獨(dú)立的產(chǎn)品嗎？