最近，關(guān)于「上下文圖譜（Context Graph）」的討論在 X 上持續(xù)發(fā)酵。

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

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

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

上下文圖譜的核心是捕捉?jīng)Q策過程，而不只是數(shù)據(jù)本身。下一個萬億級美元的平臺，關(guān)鍵不在于給現(xiàn)有記錄系統(tǒng)加上 AI，在于抓住「數(shù)據(jù)」和「行動」背后的「推理」過程。

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

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

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

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

• 新的捕捉方式，將是下一個萬億美元級別的創(chuàng)業(yè)機會。

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

超 17000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

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

• 最精準的AI產(chǎn)品曝光渠道

上一代企業(yè)軟件，通過成為各個領(lǐng)域的「記錄系統(tǒng)」（Systems of Record），創(chuàng)造了一個萬億美元規(guī)模的生態(tài)系統(tǒng)。Salesforce 用于管理客戶，Workday 用于管理員工，SAP 用于管理企業(yè)運營。成功邏輯很簡單：誰擁有最權(quán)威的數(shù)據(jù)，誰就掌握了核心工作流，誰就能鎖定客戶。

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

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

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

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

要理解這一點，關(guān)鍵在于區(qū)分兩個概念：

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

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

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

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

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

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

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

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

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

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

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

具體來說，以下幾種關(guān)鍵信息是缺失的：

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

• 來自過往決策的參考先例。商業(yè)決策高度依賴先例?！干蟼€季度我們?yōu)?X 公司設(shè)計過一個類似的方案，這次應(yīng)該保持一致?！箾]有任何一個系統(tǒng)，能把這兩個單子關(guān)聯(lián)起來，更別說記錄當初為什么要那么設(shè)計。

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

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

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

03上下文圖譜：

把隱性知識變成核心數(shù)據(jù)

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

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

于是，Agent 開始跨系統(tǒng)干活：

• 從 PagerDuty 調(diào)取了三個嚴重等級為 1 的服務(wù)事故記錄

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

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

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

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

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

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

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

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

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

04構(gòu)建上下文圖譜，

要解決三個核心問題

那上下文圖譜到底該怎么構(gòu)建？

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

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

這就需要我們從根本上重新思考數(shù)據(jù)和決策的捕捉方式。上下文圖譜本質(zhì)上是一個組織的「世界模型」，通過積累 Agents 的執(zhí)行軌跡，來學習組織的動態(tài)結(jié)構(gòu)和決策規(guī)律。

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

雙時鐘問題

為什么這么難？有個直覺幫我理清了思路：我們現(xiàn)有的系統(tǒng)，都只圍繞著時間的一個維度來構(gòu)建。

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

• 你的工單系統(tǒng)，只記錄「已解決」的狀態(tài)，不記錄排查思路。

• 你的代碼庫，只記錄當前代碼的狀態(tài)，不記錄當初的架構(gòu)爭論。

我們花了萬億美金，構(gòu)建了現(xiàn)在龐大的基礎(chǔ)設(shè)施，只為了記錄「現(xiàn)在是什么」，但幾乎沒有針對「為什么會這樣」做任何事。

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

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

這種情況到處都是：

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

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

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

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

• 狀態(tài)時鐘（state clock）：記錄當前的事實；

• 事件時鐘（event clock）：記錄事情的經(jīng)過、順序以及為什么發(fā)生；

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

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

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

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

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

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

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

那如何為一個看不全、無法預(yù)設(shè)模式、且持續(xù)變化的系統(tǒng)構(gòu)建事件時鐘呢？

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

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

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

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

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

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

換句話說，語義嵌入編碼的是「意義」。但組織推理需要的，是對決策的結(jié)構(gòu)和形態(tài)進行建模。

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

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

• 什么事件總是先于另一些事件發(fā)生？

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

圖表示學習里有一個技術(shù)是 node2vec，它的思路很有啟發(fā)：你不需要看全整張圖，只要在圖上隨機走足夠多的步數(shù)，就能學到圖的結(jié)構(gòu)。哪些節(jié)點總是一起出現(xiàn)，它們之間就有很強的關(guān)聯(lián)。

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

怎么走，決定了你能學到什么。在圖里小范圍溜達（局部走），能發(fā)現(xiàn)「物以類聚」（同質(zhì)性 Homophily）。而滿世界亂逛（全局走），則能發(fā)現(xiàn)「角色相似」（結(jié)構(gòu)對等性 Structural Equivalence）。

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

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

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

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

如果設(shè)計得當，無數(shù)次 Agent 行走的軌跡，就構(gòu)成了「事件時鐘」。

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

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

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

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

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

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

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

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

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

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

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

狀態(tài)告訴你「是什么」，事件時鐘告訴你「系統(tǒng)是如何運轉(zhuǎn)的」，后者是模擬的基礎(chǔ)。

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

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

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

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

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

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

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

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

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

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

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

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

這個想法，對讓數(shù)據(jù)更好用有點幫助，但解決不了捕捉?jīng)Q策軌跡的根本問題。

運營系統(tǒng)巨頭：困在「當前狀態(tài)」和「數(shù)據(jù)孤島」里

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

它們的邏輯是：「我們有數(shù)據(jù)，現(xiàn)在我們加智能?！?/p>

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

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

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

數(shù)據(jù)倉庫廠商：困在「只讀路徑」上

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

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

它們的想法是：數(shù)據(jù)平臺將取代傳統(tǒng)的記錄系統(tǒng)，成為 AI Agent 的基礎(chǔ)。

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

數(shù)據(jù)是在決策發(fā)生之后，才通過 ETL 進到數(shù)據(jù)倉庫的。當數(shù)據(jù)到了 Snowflake，關(guān)鍵的決策上下文早就丟了。

一個只能事后看結(jié)果的系統(tǒng)，能告訴你「發(fā)生了什么」，但沒法告訴你「為什么」。

Agent 初創(chuàng)公司：具有編排路徑的結(jié)構(gòu)性優(yōu)勢

相比之下，「Agent 系統(tǒng)」創(chuàng)業(yè)公司的核心優(yōu)勢在于，它們從第一天起就處在工作流的「編排路徑」或「執(zhí)行路徑」上。

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

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

這就是上下文圖譜。它將是 AI 時代企業(yè)最寶貴的單一資產(chǎn)。

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

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

06初創(chuàng)公司的三條路

面對這個機會，創(chuàng)業(yè)公司有三條路可以走：

路徑一：直接取代現(xiàn)有的記錄系統(tǒng)。

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

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

路徑二：模塊化滲透

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

路徑三：創(chuàng)造全新的記錄系統(tǒng)

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

不管走哪條路，Agent 的可觀察性都會成為至關(guān)重要的基礎(chǔ)設(shè)施。Arize 就在做這件事，它想成為這個新時代的 Datadog，幫助企業(yè)監(jiān)控、調(diào)試 Agent 的決策質(zhì)量。

07給創(chuàng)始人的關(guān)鍵信號

創(chuàng)業(yè)機會的信號有重疊，但也各有側(cè)重。

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

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

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

一個指向「新記錄系統(tǒng)」機會的特殊信號

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

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

問題不在于舊系統(tǒng)會不會死——它們會的。

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

我們賭后者。

今天正在構(gòu)建上下文圖譜的創(chuàng)業(yè)公司，正在為這個未來打下基礎(chǔ)。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker