推特?zé)嶙h、AI 萬(wàn)億美元新賽道，「上下文圖譜」到底是什么？創(chuàng)業(yè)機(jī)會(huì)在哪？

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

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

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

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

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

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

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

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

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

• 新的捕捉方式，將是下一個(gè)萬(wàn)億美元級(jí)別的創(chuàng)業(yè)機(jī)會(huì)。

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

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

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

進(jìn)群后，你有機(jī)會(huì)得到：

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

• 不定期贈(zèng)送熱門新品的邀請(qǐng)碼、會(huì)員碼；
  

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

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

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

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

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

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

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

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

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

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

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

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

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

隨著時(shí)間的推移，上下文圖譜將成為實(shí)現(xiàn)企業(yè)自主運(yùn)營(yíng)的真正事實(shí)來(lái)源，因?yàn)樗粌H解釋了「發(fā)生了什么」，更解釋了「為什么允許它發(fā)生」。

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

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

當(dāng) AI Agent 進(jìn)入真實(shí)的合同審查、報(bào)價(jià)收款、客戶支持等工作流時(shí)，很快就撞上了一堵墻。這堵墻，不是因?yàn)槿睌?shù)據(jù)，而是因?yàn)槿鄙贈(zèng)Q策軌跡。

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

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

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

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

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

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

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

03上下文圖譜：

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

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

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

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

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

• 從 Zendesk 找到了一個(gè)「不解決就取消合同」的升級(jí)請(qǐng)求

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

最終，錄入 CRM 的只有一個(gè)簡(jiǎn)單事實(shí)：「20% 折扣」。

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

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

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

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

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

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

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

要解決三個(gè)核心問題

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

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

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

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

必須要解決的三個(gè)核心問題：

雙時(shí)鐘問題

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

• 你的 CRM，只記錄成交價(jià)，不記錄談判過(guò)程。

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

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

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

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

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

這種情況到處都是：

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

• 病歷記錄了「換用 B 藥」，但沒說(shuō) A 藥其實(shí)有效，只是病人保險(xiǎn)不報(bào)銷了。

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

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

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

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

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

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

這件事很難，還有三個(gè)原因：

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

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

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

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

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

把 Agent 看作是有目標(biāo)的探索者

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI Agent，就是有目標(biāo)的探索者（Informed Walkers），不是隨機(jī)的。

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

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

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

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

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

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

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

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

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

組織也一樣，只不過(guò)它的「物理定律」不是牛頓力學(xué)，而是「決策動(dòng)力學(xué)」：

• 一個(gè)異常審批是怎么通過(guò)的？

• 一次故障是怎么逐級(jí)上報(bào)的？

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

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

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

在 PlayerZero，我們?cè)谧龃a模擬。我們會(huì)問模型：「如果我這樣改代碼，線上會(huì)出什么問題？影響哪些客戶？」這種模擬不是魔法，而是對(duì)成千上萬(wàn)次歷史軌跡進(jìn)行推理的結(jié)果。

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

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

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

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

并且，因?yàn)槭澜缒Ｐ椭С帜M，還可以實(shí)現(xiàn)反事實(shí)推理。不僅能問「過(guò)去類似情況是怎樣的？」，還能問「如果我采取這個(gè)行動(dòng)，會(huì)發(fā)生什么？」。AI Agent 可以想象多種結(jié)果，然后評(píng)估優(yōu)劣，做出選擇。

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

所以，未來(lái)可能不是死磕模型的持續(xù)學(xué)習(xí)，而是給模型打造一個(gè)能持續(xù)進(jìn)化的世界模型。

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

05為什么大廠做不了這個(gè)事？

Jamin Ball 很看好大廠，認(rèn)為數(shù)據(jù)倉(cāng)庫(kù)會(huì)變成「事實(shí)注冊(cè)表」，CRM 變成「帶 API 的狀態(tài)機(jī)」。

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

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

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

它們的邏輯是：「我們有數(shù)據(jù)，現(xiàn)在我們加智能。」

但它們的 AI 繼承了母體平臺(tái)的兩大缺陷：

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

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

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

Snowflake 和 Databricks 被認(rèn)為是未來(lái)的「事實(shí)注冊(cè)表」層。它們也在瘋狂投入 AI。

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

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

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

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

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

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

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

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

因?yàn)樗趫?zhí)行工作流，所以能在決策發(fā)生的瞬間，把所有上下文作為核心記錄（first-class record）實(shí)時(shí)抓下來(lái)。

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

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

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

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

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

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

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

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

路徑二：模塊化滲透

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

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

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

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

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

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

所有機(jī)會(huì)都適用的兩個(gè)信號(hào)

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

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

一個(gè)指向「新記錄系統(tǒng)」機(jī)會(huì)的特殊信號(hào)

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

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

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

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

我們賭后者。

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

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