市場終於領悟到，若缺乏正確的脈絡，數據與分析 Agent 簡直形同虛設。
本文為翻譯稿，原文出自 a16z，網址：https://www.a16z.news/p/your-data-agents-need-context
近期在數據與 AI Agent 領域中，脈絡層（Context Layer）與脈絡圖譜（Context Graph）已成為無法迴避的話題。只要與任何從事數據或 AI 的組織交談，不出五分鐘便會觸及「脈絡」這個核心議題。
這不足為奇。過去一年，市場終於想通了一件事：若缺乏正確的脈絡，數據與分析 Agent 基本上就是廢物。
它們無法拆解模糊的問題，讀不懂業務定義，也無法在分散的數據間進行有效推論。
這並非 Agent 之過。現代數據棧經歷了十多年的演進，從分散的數據源走向集中化的數據與清洗過的定義，這本是好事。然而，集中化從未做到完美，過程中引入了大量混亂。其大致演進脈絡如下：
1、現代數據棧的崛起
我們曾與 dbt 的 Tristan Handy 探討過此議題，並在自身的參考架構文章中提及。過去十年，數據架構在攝取、轉換、倉儲與儲存等環節均經歷了改造，目標是將數據集中，讓人能快速且方便地使用。理想的畫面是：數據整理乾淨後，團隊只需撰寫 SQL 即可從數據倉儲中提取數據，製作圖表與儀表板，讓整個組織都能運用商業智慧（BI）。
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 的範疇。
讓我們將「營收增長」的例子拆解得更細緻：
假設一個數據 Agent 已在組織內部建置完成。它採用現代基礎模型，連接所有應連的數據源，並配備漂亮的介面，供內部用戶提問數據相關問題。 查詢來了。「上個季度的營收增長是多少？」這看似簡單的問題。平時只要看一眼 Looker 或 Tableau 儀表板就能回答，對一個高級智能 Agent 來說應該不難吧？
挑戰一：Agent 如何知道該組織中「營收」與「季度」的具體定義？
營收其實是一個業務定義，並未硬編碼在數據倉儲或管線中。用戶想查看的是 run rate 營收還是 ARR？財務季度的劃分在不同組織中可能完全不同，換一家公司，同一個「季度」對應的三個月可能截然不同。究竟該查看哪個時間窗口？幸好數據平台負責人站出來說：「我們建立了語意層，專門解決這個問題，營收定義就包含在裡面。」Agent 理應能將所有語意層作為脈絡吸收。這聽起來頗具前景。但團隊翻閱了幾個 YAML 檔案後發現，這些檔案是由去年離職的數據團隊成員更新的，BI 工具已不再呼叫它們，且也未包含後來新上線的兩條產品線。Agent 根本不知道營收在當下究竟如何計算。 為了繞過這個障礙，有人手動將營收與時間窗口的定義硬編碼進去。數據 Agent 繼續運行，但很快又撞上挑戰二：正確的數據源在哪裡？哪些才是真正的事實來源？
原始數據分散在多張表格與多個數據倉儲中。財務團隊使用的是fct_revenue表格，這可能是對的。但數據團隊還建立了物化視圖，mv_revenue_monthly與mv_customer_mrr也擺在那裡。
很明顯，數據 Agent 需要一個持續更新的知识庫，內含業務定義與數據源資訊，才能跨越這些障礙。
脈絡層登場
問題的癥結在於：Agent 未被賦予恰當的業務脈絡，連最基本的問題都無法回答。這反映了一個更大的缺口。在組織內部構建自動化 AI 系統，需要具備持續更新與維護的脈絡。此脈絡必須理解企業如何運作、數據系統如何組織，並承載串聯一切的部落知識（Tribal Knowledge）。
由此催生了「脈絡層」。當前的討論中湧現許多名稱，如 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 接入
脈絡層建置完成後，透過 API 或 MCP 將其暴露給 Agent，實現即時可存取即可。
5、自更新的脈絡流
系統雖已搭建，但數據系統從非靜態，脈絡層也不應是。上游的數據源與格式可能會變，人員可能根據業務需求變化想增刪修改自定義指令。若數據 Agent 輸出了錯誤數據需要修正，修正內容當然也應回饋至脈絡層。如此，脈絡層便成為一個活躍、持續演化的語料庫。
從整個過程可以看出一件事：構建一個合格的數據 Agent 絕非易事。技術層面面臨數據基礎設施與工程的挑戰，人力層面則面臨部落知識收集的挑戰，兩者交織在一起。
OpenAI 團隊近期發表了一篇優秀的文章，詳細講述了他們內部數據 Agent 的創建過程。文章寫得透明，實現細緻且優雅，但也說明了走到那一步需要多長的路。Palantir 在為組織構建本體論方面擁有悠久歷史，憑藉從混亂數據中理出清晰脈絡的能力，建立了一門大生意。
市場走向
上述內容自然為外部方案打開了一扇窗。現實地說，並非每個企業都能（或應該）在內部自行建置這套系統。各種方案已開始進入市場。
我們認為目前仍處於早期階段，以下是正在形成的方案的高層市場地圖：
可分為以下幾類：
數據引力平台
Databricks 與 Snowflake 等平台已走過數據攝取、轉換、儲存的完整流程，數據引力效應強大。它們已推出 AI 數據分析產品，如 Databricks Genie 與 Snowflake Cortex Analyst，這些產品建基於數據倉儲之上，利用基礎模型進行 text-to-SQL，讓用戶能以自然語言查詢數據。這些平台目前尚未擁有特別成熟的脈絡層功能，但支援輕量級的語意建模，透過併購或內部開發將脈絡層引入平台，這條路是走得通的。
現有的「AI 數據分析師公司」
已湧現一批公司，利用 AI 讓客戶「與數據對話」。許多公司在市場上摸爬滾打後明白，做好數據 Agent 的關鍵其實在於構建脈絡層。因此，一些公司已將數據脈絡構建變為產品的核心部分。
新興的、專門的脈絡層公司
一個新品類出現了，從零開始建置脈絡層。它們需走完我們上述描述的整條路：攝取數據、收集部落知識等。而且每接洽一位新客戶，就得重新走一遍。
往前看
我們現在正處於一個有趣的節點。缺乏脈絡這個問題已被看清楚了，但構建解決方案的工作仍處於非常早期的階段。
未來令人期待。也許真正自助式分析的願景終於可以完全實現。BI、數據分析與數據科學，將被 AI 真正改變。
當然，許多問題仍是開放的。這個脈絡層會住在哪裡？它可以同時存在於多個地方嗎？它會成為一個獨立的產品嗎？