編輯｜張倩、陳陳

當(dāng)智能體（Agent）開始深度介入人類世界，關(guān)于豆包 AI 手機(jī)的討論可能只是個(gè)開始。

在此之前，手機(jī)、電腦軟件都是給人用的 —— 人負(fù)責(zé)一步步操作，系統(tǒng)負(fù)責(zé)把信息存好、算好。但現(xiàn)在，Agent 開始接過這些操作：你只需要說清楚目標(biāo)，它就能自己去打開應(yīng)用、填信息、做選擇，最后把結(jié)果交給你確認(rèn)。

這就引發(fā)了一個(gè)問題：當(dāng)人不再需要親自點(diǎn)每一步，原本圍繞「人來操作」設(shè)計(jì)的軟件、系統(tǒng)還有沒有存在的必要？除了豆包 AI 手機(jī)這樣的 to C 場景，其實(shí)企業(yè)也在爭論這個(gè)問題。

最近的討論集中在一個(gè)叫「記錄系統(tǒng)（Systems of record）」的東西上面。有人說 Agent 殺死了記錄系統(tǒng)，也有人說 Agent 只是提高了「好的記錄系統(tǒng)」的標(biāo)準(zhǔn)，還有人說，圍繞 Agent 執(zhí)行流程而搭建的新型「記錄結(jié)構(gòu)」，背后隱藏著萬億美元的機(jī)會(huì)。

那么，記錄系統(tǒng)到底是什么？圍繞它的機(jī)會(huì)存在于哪里？我們總結(jié)了幾篇相關(guān)文章，試圖詳細(xì)分析這些問題。

記錄系統(tǒng)已死？

企業(yè)里的記錄系統(tǒng)，說白了就是公司的「總賬本」和「黑匣子」。誰做了什么、什么時(shí)候做的、數(shù)據(jù)改過幾次、流程走到哪一步，都會(huì)被它原樣記下來，方便之后對賬、追責(zé)、合規(guī)檢查。

上一代企業(yè)軟件之所以能構(gòu)建起萬億美元級(jí)別的生態(tài)，是因?yàn)樗鼈兂蔀榱擞涗浵到y(tǒng)，也就是在某一類核心業(yè)務(wù)數(shù)據(jù)上最終以它為準(zhǔn)。

在過去，很多工作都繞不開這些系統(tǒng)：銷售必須把機(jī)會(huì)錄進(jìn) Salesforce，財(cái)務(wù)要在 ERP 里做憑證，HR 得把請假單走完 Workday 的流程 —— 不填、不走，事情就算沒發(fā)生。

一旦這些系統(tǒng)掌握了數(shù)據(jù)的標(biāo)準(zhǔn)定義和最終確認(rèn)權(quán)，企業(yè)的業(yè)務(wù)流程就必須圍繞它們運(yùn)轉(zhuǎn)，也因此形成了極強(qiáng)的用戶黏性和遷移壁壘。

但智能體出現(xiàn)后，這套邏輯開始被動(dòng)搖。Agent 的思路更簡單：只要能拿到需要的數(shù)據(jù)，就可以直接把事情辦完，未必還要逼著人去更新那條 CRM 或 ERP 記錄。于是，一種新的可能性出現(xiàn)了：Agent 從系統(tǒng)里讀取數(shù)據(jù)，在系統(tǒng)之外完成決策和執(zhí)行，最后只回寫一個(gè)結(jié)果，甚至干脆不回寫。這樣一來，原本必須「經(jīng)過」的記錄系統(tǒng)，可能逐漸退化成一個(gè)只讀的數(shù)據(jù)倉庫，不再是流程的中心。

于是，一些聲音就出現(xiàn)了，比如「Agent 是新的記錄系統(tǒng)」「Workflow 正在吞噬記錄系統(tǒng)」「數(shù)據(jù)才是記錄系統(tǒng)，App 只是薄薄的視圖層」……

最近，美國投資公司 Altimeter Capital 合伙人 Jamin Ball 寫了一篇文章來反駁這種說法。這篇文章題為「Long Live Systems of Record」。文章指出，記錄系統(tǒng)不僅不會(huì)消亡，反而會(huì)變得更加重要。因?yàn)橛涗浵到y(tǒng)回答的問題本質(zhì)上是「真相存放在哪里」。這個(gè)問題之所以重要，是因?yàn)殡S著工作流程越來越自動(dòng)化，脆弱點(diǎn)往往不在 AI 模型，而在于 Agent 是否從正確的系統(tǒng)獲取了正確的數(shù)據(jù)。

博客鏈接：https://cloudedjudgement.substack.com/p/clouded-judgement-121225-long-live

他指出了一個(gè)很現(xiàn)實(shí)的問題 —— 企業(yè)數(shù)據(jù)其實(shí)很混亂。以 ARR（年度經(jīng)常性收入）為例，同一公司的銷售、財(cái)務(wù)、會(huì)計(jì)、法務(wù)部門可能給出完全不同的定義和數(shù)字。當(dāng)你讓 Agent「計(jì)算各細(xì)分市場的 ARR 并發(fā)給董事會(huì)」時(shí)，它該用哪個(gè)版本？

這正是「記錄系統(tǒng)已死」這個(gè)論點(diǎn)讓 Ball 覺得不對勁的地方。自動(dòng)化程度越高，就越需要有人做好那些不起眼的苦活 —— 決定什么是正確答案，以及它應(yīng)該存放在哪里。

記錄系統(tǒng)通過各司其職的方式解決這個(gè)問題：CRM 管客戶、ERP 管財(cái)務(wù)、HRIS 管人員。后來，情況發(fā)生了變化，數(shù)據(jù)倉庫 / 湖倉（warehouse/lakehouse）試圖把所有數(shù)據(jù)倒進(jìn)一個(gè)池子，加上語義模型與指標(biāo)定義，成為「單一事實(shí)來源」。然而，這些倉庫大多活在運(yùn)營世界的下游 —— 銷售仍活在 Salesforce，財(cái)務(wù)仍在 NetSuite 結(jié)賬，倉庫只是回顧性分析工具。

Agent 改變了這個(gè)格局：首先，Agent 天然是跨系統(tǒng)的 —— 當(dāng)你讓它「運(yùn)行從報(bào)價(jià)到回款的工作流」時(shí)，它需要在 CRM、CPQ、賬單、收款等多個(gè)系統(tǒng)間穿梭協(xié)調(diào)。其次，Agent 天然是面向行動(dòng)的，不只是生成報(bào)告，而是要在底層系統(tǒng)中采取實(shí)際改變狀態(tài)的行動(dòng)。這意味著 Agent 的能力上限取決于它對「哪個(gè)系統(tǒng)擁有哪項(xiàng)真相」以及「這些真相之間的契約是什么」的理解程度。這也是為什么 Ball 認(rèn)為這對 Databricks 這樣的公司是個(gè)利好 —— 它們有可能成為 AI Agent 的引力中心，并開始自己構(gòu)建這些 Agent。

Ball 認(rèn)為，Agent 正在迫使我們把工作的用戶體驗(yàn)與真相源分離。前端可以是聊天窗口或自然語言界面，但底層仍需要有東西宣告「這是權(quán)威記錄」。數(shù)據(jù)倉庫和湖倉可能成為 Agent 工作流的天然基底，但它們需要進(jìn)化 —— 從為人類查詢設(shè)計(jì)，變成能為 Agent 提供明確規(guī)則和沖突解決機(jī)制。與此同時(shí)，傳統(tǒng)的 CRM、ERP 不會(huì)消失，而會(huì)進(jìn)化成「帶 API 的狀態(tài)機(jī)」，主要服務(wù)于機(jī)器而非人類界面。

所以，記錄系統(tǒng)不是在消亡，而是在被解構(gòu)和重新組裝。對定義良好的真相源的需求只會(huì)增長。Agent 不是在取代記錄系統(tǒng)，而是在提高對好的記錄系統(tǒng)的標(biāo)準(zhǔn)。贏得這輪周期的公司，將是那些在堅(jiān)實(shí)的真相源之上構(gòu)建出色 Agent 體驗(yàn)的公司。

上下文圖譜：價(jià)值萬億美元的新機(jī)遇

Ball 的文章反駁了 Agent 會(huì)摧毀一切的敘事，認(rèn)為 Agent 并不會(huì)取代記錄系統(tǒng)，而是抬高了一個(gè)優(yōu)秀的記錄系統(tǒng)應(yīng)具備的標(biāo)準(zhǔn)。

這一觀點(diǎn)也得到了風(fēng)險(xiǎn)投資機(jī)構(gòu) Foundation Capital 合伙人 Jaya Gupta、Ashu Garg 的支持，他們?yōu)榇诉€撰寫了一篇文章。這篇文章在 X 上有上百萬的閱讀量。

文章鏈接：https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/

文章首先肯定了 Ball 的觀點(diǎn)，Ball 指出 Agent 是跨系統(tǒng)的，會(huì)讀取 CRM、ERP、工單、日志、Slack 等，這些 Agent 以行動(dòng)為導(dǎo)向，不是只回答問題，而是會(huì)直接做事（審批、下單、升級(jí)、發(fā)折扣）。因此人不再直接點(diǎn)系統(tǒng)，Agent 成為工作的主要界面（UX），原來的系統(tǒng)退到后端負(fù)責(zé)存最終事實(shí)。但底層仍然必須有權(quán)威事實(shí)來源（System of Record），否則 Agent 不知道什么算真。

Ball 的論述默認(rèn)了一個(gè)前提，即 Agent 需要的數(shù)據(jù)，其實(shí)已經(jīng)被系統(tǒng)化地存好了。問題只在于如何讓 Agent 更好地訪問這些數(shù)據(jù)，并輔以更完善的治理機(jī)制、語義契約，以及明確規(guī)定在不同場景下應(yīng)采用哪一種數(shù)據(jù)定義。

其實(shí)，這只是問題的一半，另一半是真正驅(qū)動(dòng)企業(yè)運(yùn)轉(zhuǎn)、卻長期缺失的一層：決策軌跡（decision traces）。

具體來說，企業(yè)真正跑起來，并不只是靠那些已經(jīng)被寫進(jìn)系統(tǒng)里的規(guī)則、字段和流程，而是靠大量具體決策是如何被做出來的。這些內(nèi)容稱為 decision traces（決策軌跡），包括：

• 例外（exceptions）：在某些特殊情況下，為什么允許破例
• 覆蓋（overrides）：為什么最終結(jié)果覆蓋了默認(rèn)規(guī)則
• 先例（precedents）：過去遇到類似情況時(shí)是怎么處理的
• 跨系統(tǒng)上下文（cross-system context）：當(dāng)時(shí)綜合參考了哪些系統(tǒng)里的信息

問題在于，這些真正決定事情為什么這樣發(fā)生的信息，幾乎從未被正式記錄在任何系統(tǒng)中。它們通常存在于 Slack 的聊天記錄、Deal desk 的內(nèi)部討論、客戶或事故升級(jí)時(shí)的電話會(huì)議以及員工個(gè)人的經(jīng)驗(yàn)和記憶里。

這才是最關(guān)鍵的部分。

真正重要的區(qū)分在于：規(guī)則和決策軌跡并不是一回事。規(guī)則只告訴 Agent 在一般情況下應(yīng)該怎么做，例如報(bào)表中應(yīng)使用官方 ARR 定義；而決策軌跡記錄的是某一次具體決策是如何產(chǎn)生的，使用了哪種定義、基于哪個(gè)政策版本、是否獲得了例外審批、參考了哪些歷史先例，以及最終做了哪些調(diào)整。

Agent 不僅需要規(guī)則，更需要能夠訪問這些決策軌跡。只有這樣，它才能理解規(guī)則在過去是如何被應(yīng)用的，在哪些情況下允許破例，沖突是如何被解決的，由誰做出了最終決策，以及哪些先例才真正支配著現(xiàn)實(shí)運(yùn)作。

這正是系統(tǒng)型 Agent 創(chuàng)業(yè)公司所具備的結(jié)構(gòu)性優(yōu)勢所在。它們位于實(shí)際執(zhí)行路徑中，能夠在決策發(fā)生的當(dāng)下看到完整的上下文：跨系統(tǒng)收集了哪些輸入、評估了哪些政策、觸發(fā)了哪條例外流程、誰進(jìn)行了審批，以及最終寫入了什么狀態(tài)。將這些信息持久化之后，就會(huì)形成一種當(dāng)前大多數(shù)企業(yè)并不存在的資產(chǎn)，即可查詢的、結(jié)構(gòu)化的決策生成記錄。

這些長期積累的決策軌跡，構(gòu)成了一張上下文圖譜（Context Graph）。它并非模型的思維鏈，而是一份跨實(shí)體、跨時(shí)間連接的活的決策記錄，使歷史先例變得可搜索、可復(fù)用。隨著時(shí)間推移，這張圖譜將成為自治系統(tǒng)真正的事實(shí)來源，因?yàn)樗忉尩牟恢皇前l(fā)生了什么，更解釋了為什么這些行為被允許發(fā)生。

因此，真正的核心問題并不在于現(xiàn)有的記錄系統(tǒng)是否還能存續(xù)，而在于是否會(huì)出現(xiàn)全新的記錄系統(tǒng)，專門用于記錄決策本身，而不僅僅是記錄業(yè)務(wù)對象，以及它們是否會(huì)成長為下一代萬億美元級(jí)平臺(tái)。

哪些信息是記錄系統(tǒng)無法捕捉到的？

隨著 Agent 被部署到真實(shí)業(yè)務(wù)流程中，例如合同審核、報(bào)價(jià)到回款（quote-to-cash）、客服問題處理，團(tuán)隊(duì)正在遇到一個(gè)單靠數(shù)據(jù)治理無法解決的瓶頸。

這個(gè)瓶頸并不是缺數(shù)據(jù)，而是缺決策軌跡。

Agent 遇到的，正是人類每天依靠判斷力和組織記憶才能解決的那些模糊地帶，但支撐這些判斷的關(guān)鍵信息，從來沒有被當(dāng)作長期資產(chǎn)保存下來。

具體來說，缺失主要體現(xiàn)在以下幾個(gè)方面：

• 存在于人腦中的例外邏輯。比如：醫(yī)療行業(yè)客戶的采購流程特別復(fù)雜，通常會(huì)多給 10% 的折扣。這種經(jīng)驗(yàn)并不在 CRM 里，而是通過入職培訓(xùn)、私下交流等方式代代相傳。
• 過往決策形成的先例。比如：上個(gè)季度給公司 X 設(shè)計(jì)過類似的交易結(jié)構(gòu)，這次應(yīng)該保持一致?，F(xiàn)實(shí)中，沒有系統(tǒng)會(huì)把這兩筆交易關(guān)聯(lián)起來，更不會(huì)記錄當(dāng)初為什么選擇了那種結(jié)構(gòu)。
• 跨系統(tǒng)的信息綜合?？头?fù)責(zé)人會(huì)查看 Salesforce 里的客戶 ARR，在 Zendesk 里看到兩個(gè)未解決的升級(jí)工單，再讀一段 Slack 里提示客戶有流失風(fēng)險(xiǎn)的討論，然后決定升級(jí)處理。這一整套綜合判斷發(fā)生在他的腦子里，而系統(tǒng)里最終只留下了一條記錄：已升級(jí)至三級(jí)支持。
• 發(fā)生在系統(tǒng)之外的審批鏈路。一位 VP 可能在 Zoom 電話或 Slack 私聊中批準(zhǔn)了一個(gè)折扣。CRM 里只記錄了最終價(jià)格，卻完全看不到是誰批準(zhǔn)了這次偏離規(guī)則的決定，也不知道原因是什么。

這正是從未被捕獲（never captured）的真正含義。

問題不在于數(shù)據(jù)臟、不一致或分散，而在于把數(shù)據(jù)轉(zhuǎn)化為行動(dòng)的那段推理與判斷過程，從一開始就沒有被當(dāng)作數(shù)據(jù)來對待和保存。

上下文圖譜是長期存在的基礎(chǔ)層

當(dāng)創(chuàng)業(yè)公司在 Agent 實(shí)際執(zhí)行工作的那一層（編排層），對每一次執(zhí)行都輸出一條決策軌跡時(shí)，它們就獲得了一種當(dāng)今大多數(shù)企業(yè)幾乎從未擁有過的資產(chǎn)：一份結(jié)構(gòu)化、可回放的歷史記錄，清楚地展示了上下文是如何一步步轉(zhuǎn)化為行動(dòng)的。

在實(shí)際運(yùn)行中，這個(gè)過程往往是這樣的：一個(gè)續(xù)約 Agent 提議給予 20% 的折扣，而公司政策規(guī)定續(xù)約折扣的上限是 10%，除非獲得服務(wù)影響的例外審批。于是，Agent 會(huì)自動(dòng)從 PagerDuty 中調(diào)取最近發(fā)生的三起 SEV-1 嚴(yán)重事故，在 Zendesk 中發(fā)現(xiàn)一個(gè)若問題未解決將取消合同的升級(jí)工單，同時(shí)還找到了上一季度一位 VP 曾批準(zhǔn)過類似例外的續(xù)約討論記錄?；谶@些上下文，Agent 將例外申請?zhí)峤唤o財(cái)務(wù)部門，財(cái)務(wù)審核并批準(zhǔn)。最終，CRM 系統(tǒng)里只留下了一個(gè)結(jié)果事實(shí)：該客戶獲得了 20% 的折扣。

但如果只看 CRM，企業(yè)只能知道結(jié)果是什么，卻完全不知道這個(gè)結(jié)果為什么合理、基于哪些信息、是誰在什么背景下批準(zhǔn)的。而當(dāng)這些過程被完整記錄為一條決策軌跡時(shí)，「為什么」就第一次成為可保存、可查詢的數(shù)據(jù)。企業(yè)不再需要在 Slack 里反復(fù)追溯歷史，也不必每次遇到類似情況都重新討論一遍，而是可以直接參考過往先例，讓例外逐步沉淀為可復(fù)用的決策經(jīng)驗(yàn)。

有了這張圖譜，企業(yè)第一次能夠?qū)徲?jì)和調(diào)試自治系統(tǒng)，并將原本一次性的例外決策沉淀為可復(fù)用的先例，而不再是每個(gè)季度都在 Slack 里重新討論同樣的邊界問題。

真正讓這一體系產(chǎn)生復(fù)利效應(yīng)的是反饋循環(huán)：被捕獲的決策軌跡會(huì)成為可搜索的歷史先例，而每一次新的自動(dòng)化決策，都會(huì)為圖譜再增加一條新的軌跡。系統(tǒng)越用越懂業(yè)務(wù)，并不是因?yàn)槟Ｐ妥兞?，而是因?yàn)榭捎玫臎Q策經(jīng)驗(yàn)在不斷積累。

更重要的是，這一切并不要求從第一天起就實(shí)現(xiàn)完全自治。它可以從 human-in-the-loop 開始：Agent 負(fù)責(zé)提出方案、收集上下文、流轉(zhuǎn)審批，并記錄完整的決策軌跡。隨著相似案例反復(fù)出現(xiàn)，系統(tǒng)因?yàn)橐呀?jīng)擁有了一套結(jié)構(gòu)化的歷史決策與例外庫，便可以逐步自動(dòng)化更多環(huán)節(jié)。

即便在最終拍板仍由人類完成的情況下，這張圖譜也會(huì)持續(xù)增長，因?yàn)楣ぷ髁鲗訒?huì)把決策所依賴的輸入、審批過程和理由作為可持久的先例保存下來，而不是讓這些關(guān)鍵信息消失在 Slack 對話中。

為什么傳統(tǒng)巨頭很難構(gòu)建上下文圖譜

Jamin Ball 對現(xiàn)有企業(yè)軟件廠商的前景持相對樂觀態(tài)度。他認(rèn)為，現(xiàn)有玩家可以演進(jìn)到新的架構(gòu)中：數(shù)據(jù)倉庫成為真相注冊表（truth registry），而 CRM 則演變?yōu)閹?API 的狀態(tài)機(jī)。這是一種漸進(jìn)式演化的敘事，而非被徹底取代。

但這種路徑最多只能改善數(shù)據(jù)的可訪問性，卻無法解決一個(gè)更關(guān)鍵的問題，捕獲決策軌跡。

像 Salesforce、ServiceNow、Workday 這樣的運(yùn)營型系統(tǒng)，天然是孤立的、并以當(dāng)前狀態(tài)為核心。他們的共同敘事是：我們已經(jīng)有數(shù)據(jù)，現(xiàn)在只需要加上智能。

問題在于，這些 Agent 會(huì)繼承其母系統(tǒng)的架構(gòu)缺陷。

以 Salesforce 為例，它擅長記錄當(dāng)前這個(gè)機(jī)會(huì)單長什么樣，卻并不知道在某個(gè)折扣被批準(zhǔn)時(shí)，世界當(dāng)時(shí)是什么狀態(tài)。當(dāng)折扣通過審批后，支撐這一決策的上下文并不會(huì)被保存。你無法回放當(dāng)時(shí)的狀態(tài)，自然也就無法審計(jì)這次決策、從中學(xué)習(xí)，或把它當(dāng)作可復(fù)用的先例。

而真實(shí)的業(yè)務(wù)決策幾乎從來不是發(fā)生在單一系統(tǒng)中。比如一次客服升級(jí)，往往依賴于 CRM 里的客戶等級(jí)、計(jì)費(fèi)系統(tǒng)中的 SLA 條款、PagerDuty 里的近期故障記錄、Slack 中關(guān)于客戶流失風(fēng)險(xiǎn)的討論等因素。

但沒有任何一家傳統(tǒng)廠商位于這個(gè)跨系統(tǒng)的執(zhí)行路徑中。每個(gè)系統(tǒng)只看得到自己那一小塊現(xiàn)實(shí)，因此也無法捕獲完整的決策上下文。

一個(gè)只在事后、只在讀取側(cè)看到數(shù)據(jù)的系統(tǒng)，不可能成為決策譜系（decision lineage）的權(quán)威記錄系統(tǒng)。它可以告訴你發(fā)生了什么，卻永遠(yuǎn)無法告訴你為什么會(huì)這么發(fā)生。

而上下文圖譜恰恰要求系統(tǒng)在決策發(fā)生的那一刻、處于執(zhí)行路徑之中，才能捕獲完整的輸入、判斷、例外和批準(zhǔn)過程。這正是傳統(tǒng)決策系統(tǒng)在結(jié)構(gòu)上最難補(bǔ)齊的一環(huán)。

Databricks 在整合相關(guān)能力方面確實(shí)走得更遠(yuǎn)一些，但接近 Agent 的構(gòu)建位置，并不等同于身處決策真正發(fā)生的執(zhí)行路徑中。

系統(tǒng)型 Agent 創(chuàng)業(yè)公司具備一種結(jié)構(gòu)性優(yōu)勢：它們位于編排路徑（orchestration path）之中。

當(dāng)一個(gè) Agent 對升級(jí)請求進(jìn)行分流、響應(yīng)一次事故，或決定是否給予折扣時(shí)，它會(huì)從多個(gè)系統(tǒng)中拉取上下文、評估規(guī)則、解決沖突并采取行動(dòng)。編排層能夠看到完整的全景：收集了哪些輸入、適用了哪些政策、批準(zhǔn)了哪些例外，以及背后的原因。正因?yàn)樗趫?zhí)行工作流，才能在決策發(fā)生的當(dāng)下捕獲這些上下文，不是事后通過 ETL，而是以數(shù)據(jù)形式實(shí)時(shí)記錄下來。

這就是上下文圖譜，也將成為 AI 時(shí)代企業(yè)最有價(jià)值的資產(chǎn)之一。

當(dāng)然，傳統(tǒng)巨頭不會(huì)坐視不管。他們會(huì)通過并購補(bǔ)齊編排能力，封鎖 API、引入高昂的數(shù)據(jù)外流費(fèi)用以抬高抽取成本，就像云計(jì)算巨頭曾經(jīng)采用的策略一樣；他們還會(huì)構(gòu)建自家的 Agent 框架，推動(dòng)所有東西都留在自家生態(tài)內(nèi)的敘事。

但捕獲決策軌跡的前提，是在提交決策的那一刻就身處執(zhí)行路徑中，而不是在事后再補(bǔ)上一層治理。傳統(tǒng)廠商或許能讓數(shù)據(jù)抽取變得更困難，但他們無法強(qiáng)行插入一個(gè)自己從未參與過的編排層。

創(chuàng)業(yè)公司的三條路徑

系統(tǒng)型 Agent 創(chuàng)業(yè)公司會(huì)走上不同的發(fā)展路徑，而每條路徑都伴隨著各自的取舍。

第一種路徑是從一開始就替換現(xiàn)有的 system of records。這類公司會(huì)圍繞 Agent 執(zhí)行重新構(gòu)建 CRM 或 ERP，使事件溯源（event-sourced）的狀態(tài)管理和政策捕獲成為架構(gòu)的原生能力。由于傳統(tǒng)廠商根基深厚，這條路難度極高，但在技術(shù)或范式發(fā)生切換的關(guān)鍵窗口期，它仍然具有可行性。

在眾多進(jìn)軍 AI SDR 領(lǐng)域的創(chuàng)業(yè)公司中，Regie 選擇了這一路徑。它構(gòu)建的是一個(gè) AI 原生的銷售互動(dòng)平臺(tái)，試圖取代為人工操作、依賴碎片化工具鏈的傳統(tǒng)產(chǎn)品（如 Outreach、Salesloft）。Regie 的設(shè)計(jì)目標(biāo)是服務(wù)于人機(jī)協(xié)作的混合團(tuán)隊(duì)：Agent 作為一等公民，可以自主進(jìn)行客戶挖掘、生成外聯(lián)內(nèi)容、執(zhí)行跟進(jìn)、處理線索路由，并在必要時(shí)升級(jí)給人類處理。

第二種路徑并非替換整個(gè)系統(tǒng)，而是替換其中的關(guān)鍵模塊。這類創(chuàng)業(yè)公司聚焦于例外和審批高度集中的子流程，在這些環(huán)節(jié)中成為決策的 system of records，同時(shí)將最終狀態(tài)同步回原有的傳統(tǒng)系統(tǒng)。

Maximor 正是在金融領(lǐng)域走的第二條路徑：在不替換總賬（GL）的前提下，自動(dòng)化現(xiàn)金管理、關(guān)賬以及核心會(huì)計(jì)流程。ERP 仍然作為賬簿存在，但 Maximor 成為對賬邏輯所在的權(quán)威事實(shí)來源。

第三種路徑是創(chuàng)建全新的 systems of record。這類創(chuàng)業(yè)公司通常從編排層起步，但它們會(huì)持久化企業(yè)過去從未系統(tǒng)化保存過的東西 —— 決策過程本身。隨著時(shí)間推移，這種可回放的決策譜系會(huì)成為真正的權(quán)威資產(chǎn)，Agent 層也不再只是自動(dòng)化工具，而是企業(yè)在回答「我們當(dāng)初為什么這么做？」時(shí)所依賴的系統(tǒng)。

PlayerZero 正是這一模式的典型代表。生產(chǎn)工程（Production Engineering）位于 SRE、支持、QA 和開發(fā)的交叉地帶，是一種經(jīng)典的「膠水型職能」，長期以來依賴人來承載軟件系統(tǒng)無法捕捉的上下文。PlayerZero 從自動(dòng)化 L2/L3 支持切入，但其真正的核心資產(chǎn)，是它所構(gòu)建的上下文圖譜：一套反映代碼、配置、基礎(chǔ)設(shè)施與客戶行為在現(xiàn)實(shí)中如何相互作用的動(dòng)態(tài)模型。這張圖譜最終成為回答「為什么會(huì)出問題？」以及「這次改動(dòng)會(huì)不會(huì)影響線上？」等現(xiàn)有系統(tǒng)無法回答的問題的事實(shí)來源。

隨著越來越多創(chuàng)業(yè)公司沿著這些路徑前進(jìn)，Agent 的可觀測性（observability） 將成為關(guān)鍵基礎(chǔ)設(shè)施。隨著決策軌跡不斷累積、上下文圖譜持續(xù)擴(kuò)展，企業(yè)將需要在規(guī)模化條件下監(jiān)控、調(diào)試并評估 Agent 的行為表現(xiàn)。

Arize 正在為這一全新技術(shù)棧構(gòu)建可觀測性層，幫助團(tuán)隊(duì)洞察 Agent 的推理過程、識(shí)別失敗原因，并評估其決策隨時(shí)間推移的表現(xiàn)。正如 Datadog 成為了應(yīng)用監(jiān)控領(lǐng)域的關(guān)鍵基礎(chǔ)設(shè)施，Arize 也有望成為監(jiān)控并提升 Agent 決策質(zhì)量的核心基礎(chǔ)設(shè)施。

給創(chuàng)業(yè)者的關(guān)鍵信號(hào)

決定從哪里切入的信號(hào)之間有重疊，但并不完全相同。有兩個(gè)信號(hào)適用于上述三種機(jī)會(huì)路徑：

高人力密度。

如果一家公司有 50 個(gè)人在手動(dòng)完成同一個(gè)工作流（例如工單路由、請求分流、跨系統(tǒng)數(shù)據(jù)對賬），這本身就是一個(gè)強(qiáng)烈信號(hào)。這些崗位之所以存在，是因?yàn)闆Q策邏輯過于復(fù)雜，無法用傳統(tǒng)工具直接自動(dòng)化。

例外密集型決策。

常規(guī)、確定性的流程并不需要決策譜系，Agent 只需照規(guī)則執(zhí)行即可。真正有價(jià)值的切入點(diǎn)，出現(xiàn)在邏輯復(fù)雜、先例重要、且視情況而定才是誠實(shí)答案的地方。例如：交易審批（deal desk）、承保決策、合規(guī)審查，以及升級(jí)處理（escalation management）等場景。

還有一個(gè)信號(hào)，專門指向全新 system of record 的機(jī)會(huì)：位于多個(gè)系統(tǒng)交匯處的組織職能，往往是最重要的信號(hào)之一。

例如，RevOps 之所以存在，是因?yàn)樾枰腥嗽阡N售、財(cái)務(wù)、市場和客戶成功之間進(jìn)行協(xié)調(diào)；DevOps 的出現(xiàn)，是因?yàn)楸仨氂腥诉B接開發(fā)、IT 和支持團(tuán)隊(duì)；而 Security Ops 則處在 IT、工程和合規(guī)之間。

這些膠水型職能本身就是一個(gè)明確信號(hào)。它們之所以出現(xiàn)，正是因?yàn)闆]有任何一個(gè) system of record 能夠完整掌管這些跨職能的工作流，于是組織架構(gòu)中不得不設(shè)立一個(gè)角色，來承載軟件系統(tǒng)無法捕捉的上下文。

如果一個(gè) Agent 能夠自動(dòng)化這樣的角色，它做的就不僅僅是把步驟執(zhí)行得更快，而是能夠?qū)⒃摻巧居脕碜雠袛嗟臎Q策、例外和先例系統(tǒng)性地保存下來。這正是通往新一代 system of record 的路徑：不是通過替換現(xiàn)有巨頭，而是通過捕獲一種只有當(dāng) Agent 真正嵌入工作流之后，才會(huì)顯現(xiàn)出來的真實(shí)。

重新想象記錄系統(tǒng)

問題并不在于 記錄系統(tǒng)是否還能存續(xù)，它們一定會(huì)。真正的問題在于：下一批萬億美元級(jí)平臺(tái)，究竟是通過在既有數(shù)據(jù)之上疊加 AI 構(gòu)建起來的，還是通過捕獲讓數(shù)據(jù)真正產(chǎn)生行動(dòng)力的決策軌跡構(gòu)建起來的。

Jaya Gupta、Ashu Garg 的判斷是后者。而那些正在構(gòu)建上下文圖譜的創(chuàng)業(yè)公司，正是在為這一未來奠定基礎(chǔ)。

從操作上下文到?jīng)Q策圖譜

對于上述文章觀點(diǎn)，專注于為 Agent 構(gòu)建「操作上下文層」的基礎(chǔ)設(shè)施公司 Graphlit 的創(chuàng)始人兼首席執(zhí)行官 Kirk Marple 認(rèn)為，這是他見過的對企業(yè)級(jí) AI 未來走向闡述得最清晰的一次。

Jaya Gupta 和 Ashu Garg 指出，下一批萬億美元級(jí)平臺(tái)，并不會(huì)通過在現(xiàn)有的 System of Record 上簡單疊加 AI 而誕生，而是會(huì)通過捕獲一種企業(yè)從未被系統(tǒng)性保存過的東西來建立：決策軌跡。它們展示了規(guī)則是如何被應(yīng)用的、例外是在何時(shí)被批準(zhǔn)的，以及某個(gè)行動(dòng)為什么被允許發(fā)生。

Marple 認(rèn)為 Jaya Gupta 和 Ashu Garg 的判斷是正確的。但他指出這個(gè)論點(diǎn)還隱含了一個(gè)更值得關(guān)注的前提：如果不先解決操作上下文（operational context）的問題，就不可能真正捕獲決策軌跡。

在有意義地記錄為什么做出某個(gè)決策之前，Agent 必須先理解：誰負(fù)責(zé)什么、實(shí)體之間如何關(guān)聯(lián)、事物在什么時(shí)候發(fā)生了變化，以及信息是如何在不同系統(tǒng)之間流動(dòng)的。

正是這一基礎(chǔ)層，構(gòu)成了上下文圖譜得以成立的底層支撐。而在當(dāng)前的企業(yè)技術(shù)版圖中，這一層在很大程度上仍然是缺失的。

上下文圖譜的核心論點(diǎn)

Jaya Gupta 和 Ashu Garg 文章首先從對當(dāng)前 AI 格局的反思展開。像 Salesforce、Workday、SAP 這樣的 System of Record，之所以能夠成長為萬億美元級(jí)平臺(tái)，是因?yàn)樗鼈冋莆樟藱?quán)威、標(biāo)準(zhǔn)化的數(shù)據(jù)。而當(dāng)下的爭論在于：在 Agent 崛起之后，這些系統(tǒng)還能否繼續(xù)存活。

文章給出的答案是：Agent 并不會(huì)取代 System of Record，但它們暴露出了一個(gè)長期缺失的層級(jí)。正如文中所說：

規(guī)則告訴 Agent 在一般情況下應(yīng)該發(fā)生什么；決策軌跡記錄的是某一次具體發(fā)生了什么。比如用戶采用了 X 定義，在 v3.2 政策下，獲得了 VP 的例外批準(zhǔn)，基于先例 Z，并做了這些調(diào)整。

這個(gè)洞察非常犀利。

例如上文提到的，當(dāng)一個(gè)續(xù)約 Agent 在折扣政策上限為 10% 的情況下，仍然提出 20% 的折扣方案時(shí)，它會(huì)從多個(gè)系統(tǒng)中拉取上下文：來自 PagerDuty 的事故歷史、來自 Zendesk 的升級(jí)處理記錄，以及此前一次獲得批準(zhǔn)的相似先例。

在一般系統(tǒng)上，情況是這樣的，財(cái)務(wù)最終批準(zhǔn)后，CRM 里只留下了一個(gè)結(jié)果事實(shí)：20% 折扣。

所有讓這個(gè)決策變得合理、可理解的關(guān)鍵信息如輸入來源、政策評估過程、例外路徑、審批鏈條全部消失了。連接數(shù)據(jù)與行動(dòng)的推理過程，從一開始就沒有被當(dāng)作數(shù)據(jù)來保存。

作者將這些決策軌跡長期累積后形成的結(jié)構(gòu)稱為上下文圖譜，即一份跨實(shí)體、跨時(shí)間縫合而成的、活的決策軌跡記錄，使先例變得可以被搜索和復(fù)用。

也正是在這里，這篇文章超越了大多數(shù)同類分析。上下文圖譜并不僅僅意味著更好的治理或更完善的語義契約，而是提出了一種全新的 記錄系統(tǒng)類型 —— 它記錄的不是對象本身，而是決策本身。

Agent 所需要的兩層上下文

Kirk Marple 還補(bǔ)充道，要真正構(gòu)建上下文圖譜，需要兩個(gè)彼此不同、但層層遞進(jìn)的上下文層，而現(xiàn)實(shí)是：絕大多數(shù)企業(yè)兩層都不具備。

其中最底層、也是最關(guān)鍵的一層，叫做操作上下文（Operational Context）。

為什么操作上下文是基礎(chǔ)？

因?yàn)樵谀隳軌蛴涗洖槭裁茨硞€(gè)決策被做出之前，Agent 必須先理解這個(gè)決策發(fā)生在怎樣的組織環(huán)境中。也就是說，Agent 不能只是看到一堆文本或數(shù)據(jù)，而要理解真實(shí)的組織結(jié)構(gòu)、角色和關(guān)系。

第一身份解析（Identity Resolution）就是操作上下文中最基礎(chǔ)的一步。

比如以 Sarah Chen 舉例：同一個(gè)人，可能在郵件里是發(fā)件人，在 Slack 里是被 @ 的對象，在會(huì)議紀(jì)要里是某個(gè)發(fā)言者。如果系統(tǒng)無法判斷這些不同來源中的 Sarah Chen 其實(shí)是同一個(gè)人，那么在 Agent 眼里，她就會(huì)變成多個(gè)互不相關(guān)的碎片。

一旦身份是碎片化的，后果會(huì)非常嚴(yán)重：Agent 無法判斷誰參與過哪些討論、無法知道誰對某個(gè)賬戶或項(xiàng)目負(fù)責(zé)、無法識(shí)別誰有審批權(quán)限、誰的意見具有權(quán)重。

在這種情況下，記錄為什么做出了某個(gè)決策是沒有意義的，因?yàn)闆Q策的參與者、責(zé)任人和背景本身就是模糊的。

所以，要談上下文圖譜，先要解決操作上下文；而操作上下文的第一步，就是把組織中的人和實(shí)體從碎片化文本，變成統(tǒng)一、可理解、可推理的對象。

在真實(shí)的企業(yè)決策中，人并不是只看某一個(gè)系統(tǒng)、某一條數(shù)據(jù)就做判斷的，而是基于對組織整體運(yùn)作方式的理解來行動(dòng)。這種理解主要體現(xiàn)在三個(gè)方面，而它們恰恰是當(dāng)前系統(tǒng)普遍缺失的。

第二，是所有權(quán)和關(guān)系。

在組織中，很多關(guān)鍵信息并不是寫在系統(tǒng)里的，而是大家都知道。比如：誰負(fù)責(zé)某個(gè)客戶賬戶，哪個(gè)工程師對某個(gè)關(guān)鍵服務(wù)負(fù)最終責(zé)任，一次客服升級(jí)和產(chǎn)品路線圖之間有什么關(guān)系。這些信息要么只存在于人的腦海中，要么零散分布在 CRM、工單系統(tǒng)、項(xiàng)目管理工具中，卻從未被統(tǒng)一建模成可以被查詢、可以被推理的關(guān)系數(shù)據(jù)。對 Agent 來說，如果這些關(guān)系是隱形的，它就無法判斷該找誰這件事影響了什么。

第三，是時(shí)間狀態(tài)。

決策永遠(yuǎn)發(fā)生在某一個(gè)時(shí)間點(diǎn)，而不是現(xiàn)在。但大多數(shù)系統(tǒng)只保存當(dāng)前狀態(tài)。真正重要的問題是：在當(dāng)時(shí)，合同條款是什么？客戶當(dāng)時(shí)的 ARR 是多少？是否已經(jīng)有歷史異常？如果 Agent 只能看到現(xiàn)在的結(jié)果，卻無法還原當(dāng)時(shí)的狀態(tài)，就不可能理解決策為什么是合理的，更無法復(fù)盤和復(fù)用。

第四，是跨系統(tǒng)的綜合判斷。

人做決策時(shí)，往往會(huì)同時(shí)參考多個(gè)系統(tǒng)：CRM、工單系統(tǒng)、內(nèi)部溝通工具、事故平臺(tái)等，并在腦中完成信息整合，得出一個(gè)判斷。但這個(gè)綜合過程幾乎從不被系統(tǒng)記錄下來。系統(tǒng)只記錄了最終動(dòng)作（比如已升級(jí)到 Tier 3），卻完全丟失了為什么升級(jí)。

因而操作上下文 = 身份 + 所有權(quán) + 關(guān)系 + 時(shí)間理解 + 跨系統(tǒng)綜合能力。只有具備這一層，Agent 才能像人一樣理解組織如何運(yùn)作；也只有在此基礎(chǔ)上，后續(xù)的決策軌跡、上下文圖譜才有可能成立。

在操作上下文已經(jīng)具備的前提下（也就是 Agent 已經(jīng)搞清楚了誰是誰、誰負(fù)責(zé)什么、實(shí)體如何關(guān)聯(lián)、當(dāng)時(shí)世界處于什么狀態(tài)），才有可能進(jìn)一步構(gòu)建決策上下文（Decision Context），主要體現(xiàn)在三個(gè)方面：

第一，決策軌跡（Decision Traces）。也就是把一次決策的全過程記錄下來：輸入信息是什么？評估了哪條政策？是否觸發(fā)了例外？最終是誰批準(zhǔn)的？這些不再是隱含在人的判斷里的信息，而是被顯式保存為結(jié)構(gòu)化記錄。

第二，先例成為可復(fù)用的工件（Precedent as Artifact）。當(dāng)類似情況再次出現(xiàn)時(shí)，Agent 不需要從零開始判斷，而是可以直接查詢：我們之前是怎么處理這種情況的？當(dāng)時(shí)的結(jié)果如何？這讓經(jīng)驗(yàn)不再只存在于個(gè)人或 Slack 對話中，而是變成組織可繼承、可學(xué)習(xí)的資產(chǎn)。

第三，可審計(jì)性（Auditability）。不僅能回答發(fā)生了什么，還能夠回答為什么它被允許發(fā)生。而且這種解釋是建立在完整上下文之上的，包括當(dāng)時(shí)的狀態(tài)、參與者、規(guī)則和例外，而不是事后拼湊的理由。

總結(jié)來看，如果 Agent 不知道參與者是誰、實(shí)體之間如何關(guān)聯(lián)、決策發(fā)生時(shí)世界處于什么狀態(tài)，那么所謂的決策軌跡就是空洞的、不可復(fù)現(xiàn)的。

因此我們可以說操作上下文是地基，決策上下文是建立在地基之上的結(jié)構(gòu)。

但絕大多數(shù)企業(yè)，這兩層上下文其實(shí)都不存在。

為什么 RAG 和 AI Memory 都不夠用

市場目前主要用兩種方式來應(yīng)對上下文缺失的問題：RAG 和 AI 記憶平臺(tái)。但這兩種方法都無法解決操作上下文的問題。

RAG 檢索的是文本片段，而不是對組織的理解。

當(dāng)你問「Sarah 對 API 集成說了什么？」時(shí)，RAG 只會(huì)去找包含這些關(guān)鍵詞的文檔。它并不知道 Sarah 是一個(gè)有完整互動(dòng)歷史的人，也不知道 API 集成是一個(gè)涉及三個(gè)團(tuán)隊(duì)的項(xiàng)目，更無法理解這次討論是如何在 Slack、郵件和會(huì)議紀(jì)要之間逐步演變的。RAG 存儲(chǔ)的是相似性，而不是語義和關(guān)系。

而 AI Memory 平臺(tái)保存的是聊天記錄，而不是組織現(xiàn)實(shí)。

它們記錄的是與 AI 對話中說了什么，卻并不建模那些讓組織變得可理解的關(guān)鍵要素：實(shí)體、關(guān)系以及時(shí)間狀態(tài)。比如，用戶討論了 Acme 的定價(jià)這樣的記憶，并不等同于理解 Acme 這個(gè)客戶賬戶的歷史關(guān)系、相關(guān)干系人結(jié)構(gòu)以及過往的決策路徑。

問題的根源是結(jié)構(gòu)性的。

這些方案把組織知識(shí)當(dāng)作需要被向量化的文檔或需要被記住的對話。但事實(shí)上，組織知識(shí)本質(zhì)上是一張圖：人連接到賬戶，賬戶連接到項(xiàng)目，項(xiàng)目連接到?jīng)Q策，決策再連接到結(jié)果，而且這一切都在隨時(shí)間不斷演化。

沒有這張圖，Agent 就是上下文失明的。它們或許能檢索到相關(guān)文本，卻無法真正理解：誰負(fù)責(zé)什么、決策是如何一步步形成的、以及哪些先例才真正支配著現(xiàn)實(shí)世界的運(yùn)作。

操作上下文層到底長什么樣？

那么，真正要構(gòu)建這樣一個(gè)基礎(chǔ)性的操作上下文層，究竟需要什么？其核心能力包括：

身份統(tǒng)一的實(shí)體（Identity-resolved entities）：人、組織、地點(diǎn)、事件都需要被建模為權(quán)威、唯一的實(shí)體，最好與 Schema.org 這類通用標(biāo)準(zhǔn)保持一致。比如 Sarah Chen 不應(yīng)該是在不同工具中以不同文本形式出現(xiàn)的碎片，而應(yīng)是一個(gè)統(tǒng)一的實(shí)體，連接著她參與過的所有對話、文檔和決策。

多模態(tài)數(shù)據(jù)接入（Multimodal ingestion）：操作上下文層需要接入整個(gè)企業(yè)的信息來源：Slack、郵件、會(huì)議錄音、文檔、代碼、CRM、項(xiàng)目管理工具等。關(guān)鍵不在于把文本抽出來，而在于保留原有結(jié)構(gòu)和語義。

時(shí)間建模：不僅記錄當(dāng)前狀態(tài)，還要記錄狀態(tài)如何隨時(shí)間演變。Agent 需要理解發(fā)生了什么變化、是什么時(shí)候變的、變化的順序是什么，而不是只看到最終結(jié)果。

關(guān)系映射：實(shí)體之間必須顯式建模，比如某個(gè)人屬于哪個(gè)團(tuán)隊(duì)，一份文檔是為哪個(gè)項(xiàng)目服務(wù)的。這些關(guān)系在圖中是一等公民，而不是隱含在文本里的背景信息。

Agent 可互操作性（Agent interoperability）：上下文層必須能夠通過標(biāo)準(zhǔn)協(xié)議被任何 Agent 訪問，而不是被鎖定在某一個(gè)模型或廠商的生態(tài)中。

企業(yè)級(jí)部署能力：對于有數(shù)據(jù)合規(guī)和治理要求的企業(yè)，上下文層需要支持在自有基礎(chǔ)設(shè)施中運(yùn)行，滿足安全與合規(guī)需求。

從操作上下文到?jīng)Q策圖譜

第一，從操作上下文走向決策圖譜是企業(yè) AI 的必然路徑。

Foundation Capital 提出的上下文圖譜觀點(diǎn)，本質(zhì)上指向一個(gè)方向：企業(yè) AI 不只是需要更強(qiáng)的模型，而是需要能夠記錄和理解決策是如何發(fā)生的的基礎(chǔ)設(shè)施。要做到這一點(diǎn)，必須先解決操作上下文問題 —— 也就是身份、實(shí)體、關(guān)系和時(shí)間狀態(tài)的建模。只有在此基礎(chǔ)上，決策軌跡才有意義。

第二，決策軌跡比傳統(tǒng)的 Agent 可觀測性更高一個(gè)抽象層級(jí)。

當(dāng)前的 Agent / LLM 可觀測性主要關(guān)注執(zhí)行層面：調(diào)用了什么工具、輸入輸出是什么、延遲和資源消耗如何。這對調(diào)試很重要，但它并不等同于決策軌跡。真正有價(jià)值的決策軌跡描述的是：在什么政策下、基于哪些上下文、觸發(fā)了哪些例外、由誰批準(zhǔn)、參考了哪些先例。這是一種業(yè)務(wù)語義層面的記錄，而不是技術(shù)執(zhí)行日志。

第三，決策軌跡要成為新的 System of Record，必須標(biāo)準(zhǔn)化。

如果決策軌跡最終要承擔(dān)權(quán)威事實(shí)來源的角色，它就不能被各個(gè)平臺(tái)以私有格式各自保存，否則跨系統(tǒng)查詢先例將無法實(shí)現(xiàn)。這意味著，像實(shí)體層有 Schema.org、可觀測性層有 OpenTelemetry 一樣，決策層也需要行業(yè)級(jí)標(biāo)準(zhǔn)來描述政策、例外、審批和先例等要素。

因此，有意義的決策圖譜不可能憑空出現(xiàn)，它必須建立在操作上下文之上；而一旦操作上下文、決策記錄和工作流執(zhí)行逐步打通，就會(huì)自然演化出一種新的企業(yè)事實(shí)層，不是記錄對象是什么，而是記錄為什么這樣決策。

為什么現(xiàn)在尤為重要

有三個(gè)變化在同一時(shí)間點(diǎn)匯聚，使得當(dāng)下成為一個(gè)關(guān)鍵窗口期：

第一，ChatGPT 引爆了企業(yè)對上下文的真實(shí)需求。

每一家組織都希望 AI 能真正理解自己的業(yè)務(wù)，而不是只會(huì)使用在公共互聯(lián)網(wǎng)數(shù)據(jù)上訓(xùn)練出來的通用模型。這種需求是真實(shí)存在的，而且不會(huì)消失。

第二，MCP 讓 Agent 之間的互操作變得標(biāo)準(zhǔn)化。

Model Context Protocol 提供了一種將上下文暴露給任意 Agent 的標(biāo)準(zhǔn)方式。上下文層只需要構(gòu)建一次，就可以同時(shí)服務(wù)于 Cursor、Claude、自研 Agent，以及未來出現(xiàn)的新工具。

第三，幾乎所有公司都在嘗試部署 Agent，但缺少讓它們真正發(fā)揮作用的上下文層。

這正是文章所指出的核心缺口：Agent 正在不斷撞墻，而這些問題并不是單靠治理、權(quán)限或規(guī)則就能解決的。Agent 需要操作上下文才能正確推理，也需要決策上下文才能從歷史先例中學(xué)習(xí)。

總得有人來構(gòu)建這層上下文基礎(chǔ)設(shè)施，這才是人們該關(guān)注的方向。

https://x.com/JayaGup10/status/2003525933534179480

https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/

https://x.com/KirkMarple/status/2003944353342149021