推特熱議、AI 萬億美元新賽道，「上下文圖譜」到底是什么？創業機會在哪？

最近，關于「上下文圖譜（Context Graph）」的討論在 X 上持續發酵。

先是 SaaS 知名專欄作者 Jamin Ball 寫了一篇文章。Ball 認為，Agent 不僅不會殺死傳統的軟件系統，反而會讓企業內部對數據定義和解釋這事，變得更重要且值錢。

Foundation Capital 合伙人 Jaya Gupta 接著這個話題進一步往下延展。她認為，Ball 只說對了一半。這個理論建立在一個大前提下：Agent 需要的數據已經存在了，只需要更好地訪問和治理就行。

但實際上，企業在日常運營中，有著大量非結構化、隱性的決策信息，包括各種例外情況、臨時的特批、可供參考的過往案例，以及做決策時跨系統的上下文。這類信息，叫做「決策軌跡」。這些決策軌跡積累起來，形成了上下文圖譜。

上下文圖譜的核心是捕捉決策過程，而不只是數據本身。下一個萬億級美元的平臺，關鍵不在于給現有記錄系統加上 AI，在于抓住「數據」和「行動」背后的「推理」過程。

PlayerZero 的創始人 Animesh Koratana，又接著寫了一篇文章，來探討上下文圖譜的構建具體要怎么實踐。他認為，上下文圖譜本質上是組織的「世界模型」，通過積累 Agents 的執行軌跡，來學習組織的動態結構和決策規律。同時，又提出了實踐過程中的三個關鍵點。

我們匯總了兩篇文章的要點，試圖講清楚以下三點：

• SaaS 系統決策背后的「為什么」才是最值錢的；

• 要想收集到這些「為什么」，需要從根本上重新思考數據和決策的捕捉方式；

• 新的捕捉方式，將是下一個萬億美元級別的創業機會。

??關注 Founder Park，最及時最干貨的創業分享

超 17000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

上一代企業軟件，通過成為各個領域的「記錄系統」（Systems of Record），創造了一個萬億美元規模的生態系統。Salesforce 用于管理客戶，Workday 用于管理員工，SAP 用于管理企業運營。成功邏輯很簡單：誰擁有最權威的數據，誰就掌握了核心工作流，誰就能鎖定客戶。

當下的爭論點在于，AI Agents 的存在是否沖擊了傳統的軟件系統。Jamin Ball 最近有篇文章《記錄系統永存》很火。他反駁了「Agent 將顛覆一切」的觀點，認為 Agent 不會取代記錄系統，反而會對「好的」記錄系統提出更高的要求。

我們同意這一觀點。Agent 天然是跨系統、以行動為導向的。工作的用戶體驗（UX）正在與底層的「數據平面」逐漸分離。Agent 將成為新的交互界面，但其背后仍需一個權威的數據源作為支撐。

但 Jamin Ball 只說對了一半。他的理論有個前提是：Agent 需要的數據早就已經存在，我們只需提供更好的訪問權限，并輔以更完善的治理、語義契約和明確的規則。但這忽略了真正讓企業運轉的決策軌跡（Decision Traces）。

決策軌跡是企業運營中關于「為什么」的記錄，包含了各種例外、特批、過往案例以及跨系統的上下文。這些信息，現在正散落在 Slack 的聊天記錄、銷售部門的討論、升級處理的電話會議，以及員工的腦海里。

要理解這一點，關鍵在于區分兩個概念：

• 規則：告訴 Agent 在通常情況下應該怎么做。比如，「報告必須使用官方的年度經常性收入（ARR）數據」。

• 決策軌跡：記錄了在某個具體案例中實際發生了什么。例如，「我們基于 Z 先例，根據 v3.2 版政策，通過副總裁的特批，為這個客戶采用了 X 定義來計算 ARR，并對以下部分進行了調整」。

Agent 不僅需要規則，還必須能訪問這些決策軌跡，才能理解規則在過去是如何被應用、例外在什么情況下被批準、沖突如何解決、決策由誰批準，以及哪些先例在現實中真正起作用。

這恰恰是「Agent 系統」初創公司的結構性優勢所在。它們天然就處于工作流的「執行路徑」上，能夠在決策的瞬間捕獲完整的上下文信息：跨系統收集了哪些輸入數據、評估了哪項政策、調用了哪個例外處理流程、由誰進行了審批，以及最終寫入了什么狀態。

把這些軌跡存下來，你就得到了一個今天大多數公司都沒有的東西：一個關于決策是如何制定的、可供查詢的完整記錄。

我們將這些決策軌跡積累形成的結構稱為上下文圖譜（context graph）。它不是大模型的「思維鏈」，而是一份動態更新的、跨越實體和時間的決策記錄，把「先例」變成了可搜索的數據。

隨著時間的推移，上下文圖譜將成為實現企業自主運營的真正事實來源，因為它不僅解釋了「發生了什么」，更解釋了「為什么允許它發生」。

因此，真正的核心問題不是現有系統能否幸存，而是：一個記錄「決策」而不是記錄「對象」的全新系統，能否崛起，并成為下一個萬億美元平臺？

02沒能捕捉的信息具體是哪些？

當 AI Agent 進入真實的合同審查、報價收款、客戶支持等工作流時，很快就撞上了一堵墻。這堵墻，不是因為缺數據，而是因為缺少決策軌跡。

Agent 遇到的問題，和人類員工每天用判斷力和組織記憶解決的問題，是一樣的。但人類做判斷時依賴的那些關鍵信息，從來沒被當成持久的數據資產存下來。

具體來說，以下幾種關鍵信息是缺失的：

• 存在于經驗中的例外規則。很多決策邏輯，只存在于老員工的經驗里，是口口相傳的「部落知識」（Tribal Knowledge）。比如，「醫療行業的客戶采購流程特別麻煩，我們一般會多給 10% 的折扣。」這在 CRM 系統里是找不到的。

• 來自過往決策的參考先例。商業決策高度依賴先例。「上個季度我們為 X 公司設計過一個類似的方案，這次應該保持一致。」沒有任何一個系統，能把這兩個單子關聯起來，更別說記錄當初為什么要那么設計。

• 跨系統的綜合分析。一個決策，往往是綜合了多個系統信息的結果。一個支持主管決定要不要升級問題。他可能會：在 Salesforce 里看客戶的 ARR；在 Zendesk 里發現兩個未解決的升級請求；在 Slack 里注意到客戶流失風險。整個分析過程只發生在他的腦海里，最終工單上只留下一句「已升級至三級支持」。

• 系統之外的審批流程。關鍵的審批，尤其是高層決策，往往發生在系統之外。一個 VP 可能在 Zoom 或 Slack 私信里批了個非常規的折扣。最終銷售機會記錄里只更新了價格，但誰批準的、為什么批準，這些關鍵上下文完全丟失了。

這就是「從未被捕捉」的真正含義。問題不在于數據是否臟亂或孤立，在于那個連接數據與行動的推理過程，從一開始就沒被當作一種正式的數據來對待。

03上下文圖譜：

把隱性知識變成核心數據

真正的解決方案，是打造一個能捕捉和沉淀決策軌跡的「持久層」。當一家創業公司能做到在 Agent 每次運行時，都生成一條結構化的決策軌跡，它就擁有了當今企業最稀缺的資產。

我們來拆解一個 case：一個續約 Agent 提議給 20% 的折扣。公司政策上限是 10%，除非有「服務影響」的例外獲批。

于是，Agent 開始跨系統干活：

• 從 PagerDuty 調取了三個嚴重等級為 1 的服務事故記錄

• 從 Zendesk 找到了一個「不解決就取消合同」的升級請求

• 引用了上季度 VP 批準類似例外的先例，它把這些信息打包成例外申請，路由給財務部。財務批準。

最終，錄入 CRM 的只有一個簡單事實：「20% 折扣」。

但背后所有的「為什么」，都被完整記錄了下來。

一旦有了這樣的決策記錄，「為什么」就從隱性知識變成了核心數據。時間一長，這些記錄自然會連成一個強大的上下文圖譜（Context Graph）。

這個圖譜，把公司關心的所有東西（客戶、合同、工單、審批人）都通過「決策事件」和「為什么」的鏈接關聯了起來。

公司就能審計自動化系統，把例外變成先例，不用每個季度都在 Slack 里重復踩坑。

這個過程會產生強大的復利效應：被捕捉的決策軌跡成為可搜索的先例，同時每一次自動化決策又會為圖譜增添新的軌跡。

這事兒不需要一步到位。它可以從「human-in-the-loop」開始：Agent 提建議、收信息、跑流程，人類來拍板，但整個過程都被忠實記錄下來。即便是人來做決策，上下文圖譜依然在持續增長，因為它確保了決策的輸入、審批過程和背后邏輯被作為持久化的先例保留下來，而不是消失在海量的聊天信息中。

04構建上下文圖譜，

要解決三個核心問題

那上下文圖譜到底該怎么構建？

答案不是給 Agent 加個記憶庫或者連接到某個 MCP 那么簡單。「Graph」這個詞本身都有點誤導，因為它體現的是一種靜態結構，但我們要處理的東西，動態和不確定性要高得多。

每個公司都在交一筆「碎片化稅（fragmentation tax）」，信息散落在各個系統里，需要人手動拼湊上下文。上下文圖譜，就是為了消除這筆「稅負」而生的基礎設施。

這就需要我們從根本上重新思考數據和決策的捕捉方式。上下文圖譜本質上是一個組織的「世界模型」，通過積累 Agents 的執行軌跡，來學習組織的動態結構和決策規律。

必須要解決的三個核心問題：

雙時鐘問題

為什么這么難？有個直覺幫我理清了思路：我們現有的系統，都只圍繞著時間的一個維度來構建。

• 你的 CRM，只記錄成交價，不記錄談判過程。

• 你的工單系統，只記錄「已解決」的狀態，不記錄排查思路。

• 你的代碼庫，只記錄當前代碼的狀態，不記錄當初的架構爭論。

我們花了萬億美金，構建了現在龐大的基礎設施，只為了記錄「現在是什么」，但幾乎沒有針對「為什么會這樣」做任何事。

過去，人就是推理層，這沒問題。組織的智慧大腦在每個人腦子里，靠開會、聊天就能把事情拼湊起來。現在，我們想讓 AI 做決策，卻發現它根本沒有決策依據。我們要求模型擁有判斷力，卻不給它看「判例」。這就像只給律師看判決結果，卻不給他們看卷宗和庭審記錄一樣。

代碼里一行配置 timeout=30s，Git 記錄顯示，它之前是 5s，有人把它改了。但為什么？Git 的追溯記錄（blame）能顯示是誰改的，但背后的思考過程卻消失了。

這種情況到處都是：

• CRM 顯示「交易失敗」，但沒告訴你，其實你是客戶第二選擇，第一名只比你多一個你下季度才上線的功能。

• 病歷記錄了「換用 B 藥」，但沒說 A 藥其實有效，只是病人保險不報銷了。

• 合同顯示「60 天可解約」，但沒說這是你用責任上限條款換來的，客戶一開始想要 30 天。

我把它叫做「雙時鐘問題」。每個系統都有兩個時鐘：

• 狀態時鐘（state clock）：記錄當前的事實；

• 事件時鐘（event clock）：記錄事情的經過、順序以及為什么發生；

我們把狀態時鐘做到了極致，事件時鐘卻幾乎不存在。

「狀態」很簡單，存數據庫就行。但「事件」很難，因為它轉瞬即逝。狀態可以被覆蓋，但事件必須追加記錄。而事件時鐘里最關鍵的「推理」部分，從沒被當成數據對待，它們只存在在人腦里、Slack 聊天記錄里和沒被錄音的會議里。

這件事很難，還有三個原因：

• 多數系統是「黑箱」：任何真實系統都存在黑箱，遺留代碼、第三方 API、復雜系統里的突現行為，看不透，自然也抓不住背后的推理邏輯；

• 沒有通用標準（Ontology）：每個組織都有自己獨特的實體、關系和語義。「客戶」一詞在 B2B 軟件公司和在消費者電商平臺上的含義截然不同。你沒法預設一個標準，只能讓系統自己學；

• 一切都在動態變化：你建模的對象每天都在高速迭代。你記錄的不是一個靜態的現實，而是在追蹤一個動態的過程。

這幾個問題交織在一起，讓重建「事件時鐘」成了一個幾乎不可能的任務。大多數「知識管理」項目之所以失敗，是因為它們把這個問題當作靜態任務來處理：導入文檔，建立一個知識圖譜，然后供人查詢。但文檔是被「凍結」的狀態，而「事件時鐘」真正要捕捉的，是整個動態變化的過程。

那如何為一個看不全、無法預設模式、且持續變化的系統構建事件時鐘呢？

把 Agent 看作是有目標的探索者

「本體」問題（Ontology）看起來像個死結。每個公司都不一樣，你怎么可能去定義一套標準的決策流程？

但有一種存在，天生就是用來在任意系統中穿梭的：AI Agent。

當一個 Agent 要解決問題時，它會自己搞清楚該關注哪些東西、它們之間有什么關聯、需要什么信息、能做什么操作。

Agent 解決問題的路徑，就像在系統里走了一遍，畫出了一張地圖。這張地圖不是預設的，而是在實際使用中跑出來的。

我們平時用的嵌入（embeddings）是基于語義的，意思是「含義相近，向量就相近」。但這不夠。我們需要的是能編碼結構的嵌入，意思是「扮演的角色相似」或者「在決策中經常一起出現」。

換句話說，語義嵌入編碼的是「意義」。但組織推理需要的，是對決策的結構和形態進行建模。

所以，信息的核心變了。不再是「意義」，而是推理的形態。它回答的是這些問題：

• 解決一個問題，通常會牽扯到哪些部門和系統？

• 什么事件總是先于另一些事件發生？

• 在整個組織的信息系統里，最常被走通的路徑是哪幾條？

圖表示學習里有一個技術是 node2vec，它的思路很有啟發：你不需要看全整張圖，只要在圖上隨機走足夠多的步數，就能學到圖的結構。哪些節點總是一起出現，它們之間就有很強的關聯。

這個思路把問題反過來了：你不需要先理解一個系統，才能表達它；而是先去充分地遍歷它，表達自然就涌現了。模式（Schema）是結果，不是起點。

怎么走，決定了你能學到什么。在圖里小范圍溜達（局部走），能發現「物以類聚」（同質性 Homophily）。而滿世界亂逛（全局走），則能發現「角色相似」（結構對等性 Structural Equivalence）。

舉個例子： 公司里有兩個資深工程師，一個做支付，一個做通知系統，平時工作毫無交集。

只看局部關系，他倆毫無關聯。但從整體結構上看，他們扮演的角色、處理問題的模式是高度相似的。結構對等性就能說明這一點。

AI Agent，就是有目標的探索者（Informed Walkers），不是隨機的。

它解決問題的過程，就是一次穿越組織信息空間的行走，會接觸系統、讀取數據、調用 API。它走的每一步，都是由當前問題驅動的。一開始可能全局摸排，找到線索后就深入局部。

如果設計得當，無數次 Agent 行走的軌跡，就構成了「事件時鐘」。

每一條軌跡，都是對組織結構的一次采樣。成千上萬次采樣之后，一個通過實際應用學習而來、能反映組織真實運作方式的表示就誕生了。

這里有個很巧妙的經濟模型：公司部署 AI Agent，是為了解決能賺錢的業務問題。而上下文圖譜，只是這個過程中的「副產品」。但這個「副產品」反過來又能讓 Agent 變得更強，解決更復雜的問題，更多的軌跡又進一步豐富上下文，形成一個正向飛輪。但前提是：投入產出比得是正的。AI Agent 創造的價值，必須大于它消耗的算力成本。

上下文圖譜是組織的「世界模型」

上下文圖譜的本質是什么？一個概念很關鍵：世界模型（World Models）。

簡單說，世界模型就是一個通過學習得到的、關于環境如何運轉的壓縮表示。它知道在特定狀態下采取行動會引發什么后果，會推斷接下來會發生什么。

AI 能在自己腦子里，建一個真實世界的「模擬環境」。這個模擬環境雖然是簡化的，但抓住了世界運行的核心規律。

這在機器人領域很好理解。機器人可以在一個模擬物理定律的世界模型里訓練、學習，先在虛擬世界里訓練策略，再把學習到的能力用到到現實世界中。物理模型越精準，模擬訓練就越有效。

組織也一樣，只不過它的「物理定律」不是牛頓力學，而是「決策動力學」：

• 一個異常審批是怎么通過的？

• 一次故障是怎么逐級上報的？

• 在某個功能開關開啟的情況下，修改配置會發生什么？

狀態告訴你「是什么」，事件時鐘告訴你「系統是如何運轉的」，后者是模擬的基礎。

一個足夠強大的上下文圖譜，就成了一個組織的「世界模型」。它搞清楚了決策是怎么走的、連鎖反應是怎么發生的、不同部分是怎么互動的。掌握了這些，你就能開始模擬未來了。

在 PlayerZero，我們在做代碼模擬。我們會問模型：「如果我這樣改代碼，線上會出什么問題？影響哪些客戶？」這種模擬不是魔法，而是對成千上萬次歷史軌跡進行推理的結果。

模擬，是檢驗理解程度的試金石。如果你的上下文圖譜能回答「如果... 會怎樣？」，那它才算成了。否則，充其量只是一個搜索引擎。

這對當前關于持續學習（continual learning）的爭論也有新的啟發。很多人覺得 AI 沒法在工作中持續學習，所以潛力有限。

但世界模型提供了另一種思路：基礎模型可以不變，但推理依據的「世界模型」可以持續更新。

Agent 每次解決問題，都在為世界模型提供新的證據。決策時，它基于這個不斷豐富的世界模型進行推理和模擬，看起來就像它「學會」了新東西一樣。軌跡越多，推理就越精準。

并且，因為世界模型支持模擬，還可以實現反事實推理。不僅能問「過去類似情況是怎樣的？」，還能問「如果我采取這個行動，會發生什么？」。AI Agent 可以想象多種結果，然后評估優劣，做出選擇。

這正是經驗豐富的員工與新員工的核心區別。他們不是大腦結構不同，而是腦子里有一個更精準的「世界模型」。他們能下意識地模擬出「周五發版，周末就要加班救火」這種后果。這不是檢索記憶，這是推理。

所以，未來可能不是死磕模型的持續學習，而是給模型打造一個能持續進化的世界模型。

基礎模型是引擎，而上下文圖譜就是那個讓引擎能夠發揮作用的世界模型。

05為什么大廠做不了這個事？

Jamin Ball 很看好大廠，認為數據倉庫會變成「事實注冊表」，CRM 變成「帶 API 的狀態機」。

這個想法，對讓數據更好用有點幫助，但解決不了捕捉決策軌跡的根本問題。

運營系統巨頭：困在「當前狀態」和「數據孤島」里

Salesforce 推出了 Agentforce，ServiceNow 有 Now Assist，Workday 也在為 HR 部分構建 Agent。

它們的邏輯是：「我們有數據，現在我們加智能。」

但它們的 AI 繼承了母體平臺的兩大缺陷：

「當前狀態」陷阱。Salesforce 的核心是基于「當前狀態」的存儲。它只知道一個銷售機會現在是什么樣，但不知道在三個月前決策制定時是什么樣的。當一筆折扣被批準后，所有支撐決策的上下文都丟失了。你沒法「回放」現場，自然沒法審計和學習。

視野盲區。這些系統本質上是數據孤島。一個客戶支持決策，上下文可能散落在 Zendesk、CRM、計費系統、PagerDuty 和 Slack 里。沒有任何一個大廠能看到全景。

數據倉庫廠商：困在「只讀路徑」上

Snowflake 和 Databricks 被認為是未來的「事實注冊表」層。它們也在瘋狂投入 AI。

Snowflake 推出了 Cortex，還收購了 Streamlit；Databricks 收購了 Neon，并發布了 Lakebase 和 AgentBricks。

它們的想法是：數據平臺將取代傳統的記錄系統，成為 AI Agent 的基礎。

但它們有個致命問題：它們在數據的「讀取路徑」（read path），而不是「寫入路徑」（write path）。

數據是在決策發生之后，才通過 ETL 進到數據倉庫的。當數據到了 Snowflake，關鍵的決策上下文早就丟了。

一個只能事后看結果的系統，能告訴你「發生了什么」，但沒法告訴你「為什么」。

Agent 初創公司：具有編排路徑的結構性優勢

相比之下，「Agent 系統」創業公司的核心優勢在于，它們從第一天起就處在工作流的「編排路徑」或「執行路徑」上。

當一個 Agent 需要處理升級請求、響應服務事件或決定折扣時，它會從多個系統中拉取上下文信息，評估規則，解決沖突，然后執行操作。這個「編排層」能看到完整的決策圖景：收集了哪些輸入、應用了哪條政策、批準了什么例外，以及背后的原因。

因為它在執行工作流，所以能在決策發生的瞬間，把所有上下文作為核心記錄（first-class record）實時抓下來。

這就是上下文圖譜。它將是 AI 時代企業最寶貴的單一資產。

大廠肯定會反擊。它們會嘗試通過收購來補齊編排能力、會鎖定 API 接口并收取高昂的數據出口費，讓數據提取變得困難。還會構建自己的 Agent 框架，然后鼓吹「生態內循環」。

但這改變不了一個事實：捕捉決策軌跡，需要在決策提交時身處執行路徑之中，而不是事后打補丁。大廠沒法把自己硬塞進一個從未參與過的、跨系統的編排層。

06初創公司的三條路

面對這個機會，創業公司有三條路可以走：

路徑一：直接取代現有的記錄系統。

打造一個「AI 原生」的 CRM 或 ERP，架構原生支持事件溯源和策略捕捉。這很難，但有機會。

Regie 就是這么干的，它要做的不是另一個 Outreach/Salesloft，而是一個全新的、為「人機混合」團隊設計的銷售互動平臺。Agent 在其中扮演核心角色：它可以開發潛在客戶、生成營銷內容、執行跟進、分配任務，并在必要時將復雜問題上報給人類同事。

路徑二：模塊化滲透

不取代整個系統，而是盯住那些例外和審批特別集中的特定工作流，成為這些決策的記錄系統。 Maximor 在金融領域就是這個打法。它自動化了現金、關賬等流程，但并不替換企業原有的總賬（GL）系統。ERP 還是那個賬本，但 Maximor 成了所有對賬邏輯的權威來源。

路徑三：創造全新的記錄系統

從一個跨系統的編排層切入，但核心戰略是把企業從未有過的「決策軌跡」儲存下來。 時間一長，這份能回溯的決策記錄本身，就成了最權威的資產。 PlayerZero 是個典型。它從自動化 L2/L3 生產環境支持入手，最終構建了一個關于「系統為何出故障」的上下文圖譜，能回答任何現有系統都答不了的問題。

不管走哪條路，Agent 的可觀察性都會成為至關重要的基礎設施。Arize 就在做這件事，它想成為這個新時代的 Datadog，幫助企業監控、調試 Agent 的決策質量。

07給創始人的關鍵信號

創業機會的信號有重疊，但也各有側重。

所有機會都適用的兩個信號

高人力成本的流程。如果一個公司有 50 號人，天天在手動處理工單、對數據，這就是一個明確的信號。這說明決策邏輯太復雜，傳統工具搞不定。

充滿例外的決策場景。常規的、確定性的工作流并不需要決策脈絡，Agent 只需要按部就班地執行。機會在那些邏輯復雜、先例很重要、答案總是「看情況」的地方。比如：銷售方案審批、保險承保、合規審查、升級管理。

一個指向「新記錄系統」機會的特殊信號

那些處在系統交叉點的部門。為什么會有營收運營（RevOps）、開發運維（DevOps）、安全運營（Security Ops）這些部門？就是因為沒有任何一個單一系統能搞定跨職能的工作流。公司只好創造一個新角色，由人來傳遞軟件抓不住的上下文。

一個能自動化這種角色的 Agent，不只是提升效率。它能把這個角色要做的決策、例外和先例，都沉淀下來。這就是通往一個全新記錄系統的路：不是顛覆某個現有系統，而是通過捕捉一類全新的、只有當 Agent 深入工作流之后才可見的事實。

問題不在于舊系統會不會死——它們會的。

真正的問題是，下一個萬億美元平臺，到底是靠給現有數據加上 AI 功能，還是靠捕捉那些能讓數據產生行動的決策軌跡？

我們賭后者。

今天正在構建上下文圖譜的創業公司，正在為這個未來打下基礎。

轉載原創文章請添加微信：founderparker