a16z：當UI不再是產品，軟體的護城河還剩什麼？

編者按：過去二十年，SaaS 的護城河很大程度上建立在 UI 之上。儀表板、欄位、審批流程和使用者習慣，不只是操作介面，也塑造了組織的工作方式和資料秩序。當 AI 可以直接讀取資料、調用工具、執行流程，依賴人類肌肉記憶形成的黏性開始減弱，UI 不再必然是企業軟件的核心介面。

這並不意味著記錄系統失去價值，而是其防禦性正在轉移：從 UI 和使用習慣，轉向數據模型、權限系統、合規責任、業務邏輯、執行閉環和多方協作網路。未來真正有壁壘的軟件，可能不再只是記錄人類工作的數據庫，而是能夠捕捉上下文、發起任務、協調智能體，並在執行過程中持續生成新數據的行動系統。

當軟件走向 headless（去介面化），企業軟件的核心問題也隨之改變：價值不再只是誰擁有數據，而是誰能圍繞數據組織行動。

以下為原文：

上個月，Salesforce 宣布將開放 API，並推出一款 headless（去介面化）產品。本質上，這意味著 Salesforce 正在押注：在 Agent 時代，其核心價值不再主要來自 UI，而是來自數據層。這是一次相當聰明的重新定位。

不過也需要指出，從技術層面看，這次發布似乎並沒有帶來太多實質性變化。Salesforce 如今以「headless 產品」名義重新包裝的 API，很大程度上其實已經存在多年。換句話說，這更像是一場典型的 Salesforce 式行銷發布。

這款新產品的核心思路是，Agent 可以直接訪問記錄系統中的數據，而不必再通過面向人類設計的 UI 完成互動。傳統 UI 的作用，是幫助人類用戶追蹤流程、管理任務和推進工作流；但在 Agent 介入之後，這一層介面的必要性開始下降。

這次發布真正值得討論的地方，不只是 Salesforce 推出了什麼新產品，而是它拋出了一個更底層的問題：如果剝離 UI，只開放底層數據庫，那麼一個記錄系統還剩下什麼？它和一個 Postgres 數據庫、一套設計良好的數據 schema，以及一組 API 之間，究竟還有多大區別？

進一步說，那些曾經讓記錄系統具備長期防禦性的經典因素，是否仍然成立？還是說，新的競爭標準已經出現？

在 SaaS 時代，記錄系統之所以擁有護城河，是因為人類用戶長期生活在它的界面之中。界面承載了操作習慣、組織流程和數據沉澱，也由此形成了較高的遷移成本。但在 Agent 時代，這一優勢正在被削弱。真正具備防禦性的層級，正在一方面下沉到數據模型、權限體系、工作流邏輯和合規能力之中；另一方面上移到網路效應、專有數據生成能力，以及現實世界的執行能力之中。

當軟體走向 headless，護城河究竟會轉移到哪裡？

UI 曾經就是產品本身

所謂記錄系統（System of Record，SoR），指的是某一類商業數據的權威事實來源。它是客戶關係、員工記錄或財務交易等「官方版本」所在的地方，也是其他工具讀取數據、寫回數據的核心系統。CRM 是收入相關數據的記錄系統，HRIS 是人員相關數據的記錄系統，ERP 則是資金與財務相關數據的記錄系統。

這些系統的強大之處，並不只是因為它們存儲了數據，而在於它們最終成為整個組織共同運轉所依賴的「現實版本」。

過去二十年裡，Salesforce 賣給客戶的，其實是一套幫助銷售負責人管理團隊的方式。儀表板、銷售管道視圖、預測工具、動態訊息流，才是真正被購買的產品。它的商業模式建立在向用戶銷售席位之上，而這些席位本質上提供的是對上述功能的訪問權限。底層數據庫固然關鍵，但在產品體驗中更像是一個隱性的基礎設施。

也就是說，真正驅動用戶黏性的，是 UI。

UI 約束了數據規範，塑造了共同語言：線索、商機、客戶帳戶。它讓成千上萬名銷售代表持續輸入那些他們原本未必願意輸入的數據。過去，UI 正是維持數據一致性和可用性的機制。Salesforce 之所以黏性極強，以至於許多銷售負責人在跳槽後仍堅持把 Salesforce 帶到新公司，並不是因為它的界面多麼出色，而是因為它已經變成了一種肌肉記憶。

但 Agent 正在開始顛覆這一模式。它們不再需要通過 UI 與軟體互動，而是可以直接讀取和寫入底層數據。這也催生了一批繞過傳統介面的新工具和替代方案。Salesforce 並不是唯一的例子：我們近期也曾討論過，SAP 周圍正在生長出一整個更適合 AI 調用的生態系統。

與此同時，能夠操作電腦的 Agent，也會讓偏好、培訓、未文檔化的上下文等傳統人類層面的因素，隨著時間推移逐漸變得不再重要。換句話說，成為一個持久記錄系統所需滿足的條件，正在變化。

過去的評分標準

在討論 Agent 時代會發生什麼變化之前，有必要先更精確地回到一個問題：過去到底是什麼讓記錄系統具有黏性？

前幾個因素，主要都與人類如何使用軟體，以及人類自身的偏好有關。軟體之所以難以被替換，很大程度上依賴 UI、使用習慣、人類工作流，以及已經嵌入組織流程的制度安排。

第一，它被訪問的頻率有多高？

CRM 每天都會被 GTM 團隊以及更多相關部門使用。正是這種高頻使用，讓它成為關鍵基礎設施。而建立在其上的人類層——例如團隊例會、操作習慣、管理節奏等經過多年形成的組織慣性——往往才是最難遷移的部分。原因在於，它甚至經常不會被識別為「需要遷移的東西」。

第二，它是只寫入，還是既讀又寫？

真正有黏性的記錄系統，通常是一個讀寫雙向的系統。以 CRM 為例，它不是一個只負責存檔的寫入系統，而是會被持續讀取。每一通電話記錄、每一次階段更新、每一個任務創建，都是由某個使用者輸入的，而這個使用者通常也在意這些數據之後如何被使用。

這種雙向流動意味著，任何替代品都必須能夠承接實時運營數據，而不只是導出一份歷史數據。遷移過程中幾乎不存在一個絕對安全的切換時點。因此，一旦企業完成上線，往往就會長期留在原供應商體系內。

與之相反，候選人追踪系統（ATS）通常更接近「只寫入」系統。候選人被錄用或拒絕之後，企業再回頭使用這些數據的理由就相對有限。

第三，有多少未被文檔化的 SOP？

真正關鍵的業務上下文，往往並不寫在任何 wiki 裡，而是沉澱在管理員和系統集成商多年搭建出來的工作流規則中。

以銷售系統為例，這些未被文檔化的上下文可能包括：超過 10 萬美元的企業級交易需要 VP 審批；EMEA 區域的交易必須經過隱私審查；戰略客戶的折扣只有在季度末才能繞過財務審批。

這些上下文，往往決定了一件事能否被及時推進，或者能否在不違反關鍵流程的情況下完成。遷移系統，意味著要重新拆解每一條自動化規則；否則，企業就可能直接丟失一部分組織記憶。

第四，內部或外部依賴有多複雜？

核心問題在於：有多少內部系統、團隊流程，或外部利益相關方依賴這個記錄系統？

內部連接性，指的是有多少下游軟體或工作流依賴它。外部連接性，則指審計師、會計師、監管機構等外部主體，是否需要直接訪問其中的數據。ERP 就是典型例子。

無論是內部還是外部，只要連接性越高，遷移時需要拆解和重建的關係就越複雜。

第五，從合規角度看，數據有多關鍵？

這裡的核心問題很簡單：這個系統是否具有合規關鍵性？

像薪酬系統、ERP、人力資源數據這類合規關鍵系統，必須提供一個在法律上站得住腳的事實來源，並具備嚴格的管理員權限控制。任何遷移都可能需要審計師和監管機構直接介入。這使得它們的黏性顯著更強。

銷售數據和 Zendesk 這類客戶支援工具則處在另一端。企業當然在意連續性和上下文，但如果數據發生遷移，或有人獲得訪問權限，通常並不會立刻引發監管層面的風險。

並不是所有記錄系統都擁有同等程度的切換成本。把 CRM 和 ATS 放在同一組維度下比較，差距會非常明顯。

ATS 是一種服務於有限流程的工作流工具，它圍繞招聘展開。一旦候選人被錄用或拒絕，相關記錄大多就變成了一次性寫入的數據。它的集成範圍更窄，用戶群體也更小、更集中。

ERP 則處在另一個極端。總賬本身就是審計軌跡，會計師、審計師和監管機構都會成為遷移過程中的直接利益相關方。

替換 ATS 是痛苦的，但仍然可承受。替換 CRM 像是在做開胸手術。替換 ERP，則像是在病人跑馬拉松的同時給他做開胸手術。

傳統上，記錄系統並沒有真正利用專有數據、網路效應這類護城河來源；通常來說，工作流本身就已經足以形成壁壘。某種程度上，將工具與網路結合起來的，更多是消費級業務；歷史上的 SoR 並沒有走上這條路徑。

專有數據。許多記錄系統雖然沉澱了大量客戶數據，但並沒有真正圍繞這些數據展開深度利用，而且在很多情況下，合同條款也不允許它們這麼做。因此，儘管 CRM 擁有豐富的數據集，理論上也可以匯總不同客戶的數據，生成跨客戶的洞察，但它們從未以真正有意義的方式做到這一點。當然，Salesforce 的 Einstein 這類產品曾做過一些嘗試。

網路效應。對記錄系統來說，最理想的護城河本該是網路效應：例如，CRM 會因為軟體賣家能夠在其中找到買家而變得更有價值。但和數據一樣，歷史上記錄系統的網路效應一直很弱，甚至可以說幾乎不存在。

如果 UI 消失了，Agent 到來之後，軟體還剩下什麼？

Agent 並不需要瀏覽器。它需要的是 API、上下文、指令，以及執行動作的能力。有兩件事讓這一切能夠規模化發生：一是 LLM 已經具備足夠強的推理能力，因此 Agent 如今可以讀取上下文、制定計劃、選擇工具、執行動作並複盤結果，而在大多數任務中不再需要人類介入；二是 MCP 標準化了工具訪問方式，為 Agent 調用外部能力提供了一套通用接口。

一個擁有 MCP 訪問權限的 Agent，可以在毫秒級時間內、大規模完成過去人類用戶在平台上執行的操作，而且不需要瀏覽器。在上下文充分的情況下，能夠操作電腦的 Agent 甚至可以直接使用既有軟體介面，而不一定需要 API。

簡單來看，軟體買家現在有三條路徑：

第一，繼續使用既有系統，並在其上堆疊 Agent。
通過既有系統的 CLI 和 API 使用它們，既可以使用廠商原生的 Agent 產品，比如 Salesforce 的 Agentforce、SAP 的 Joule，也可以在其上自建 Agent。當然，這裡暫且假設 API 是完整且可用的，也暫且忽略「headless 化」在實際運營中可能帶來的複雜性。

第二，完全自建記錄系統。
企業可以從零開始搭建自己的數據模型、運營邏輯、權限體系、審計追踪、系統集成，以及自己的 Agent 堆棧。這一路徑很可能會借助第三方 Agent 開發工具和數據庫工具。

第三，購買 AI 原生替代品。
企業也可以購買新一代從一開始就為 Agent 時代設計的軟件。這類產品強調機器可讀性，將 Agent 編排作為一等能力，而不是在舊系統之上打補丁式地增加一個 AI 功能。這類產品也可能是 headless 的。

那麼，舊有評分標準中哪些東西會被保留下來？

由人類行為和偏好驅動的因素會逐漸減弱，比如訪問頻率、讀寫雙向屬性等與人類肌肉記憶相關的指標。Agent 或許會削弱「肌肉記憶」作為城堡的價值，但它們不會消滅運營邏輯和業務上下文的城堡。某種意義上，它們反而會讓這些邏輯變得更加重要，因為 Agent 要安全地執行任務，必須依賴清晰的規則、權限和流程定義。

未被文檔化的 SOP，在短期內仍然重要。
組織內部沉澱在工作流規則中的制度邏輯，正是 Agent 代表你正確執行任務所需要的東西。同時，這也是最難重建的部分。至少目前，它還無法被乾淨地導出，尤其是在部分流程仍然需要人類參與的情況下。不過，捕捉上下文正在變得越來越容易；隨著 Agent 替代更多人工勞動，這一因素的重要性也會逐漸下降。

連接性仍然難以拆解，而且會向更深處延伸。
連接性的含義正在發生變化。它不再只是為了配合人類工作，而是要維持傳統上彼此割裂的職能和軟件之間的連接。

一個 CRM Agent 需要把銷售、帳單、客戶成功等不同環節的數據和上下文串聯起來。如果你的平台還成為多個外部組織之間的 Agent 進行交易的節點，比如買家、賣家、合作夥伴都通過這裡完成互動，那麼依賴關係會進一步加深。

既有廠商疊加 Agent 時，可能很難在不同底層軟件的基本對象和邏輯之間順暢協作；企業如果只靠一個自建數據庫和一組 Agent，也會面臨類似問題。

合規關鍵數據仍然重要。
涉及監管機構、監管風險或法律風險的數據，仍然需要一個單一、可信的數據事實來源。如果客戶已經信任現有產品，他們切換系統的可能性就會更低。

以薪酬和會計數據為例，Agent 可能確實需要訪問這些數據，但企業通常不太可能選擇在內部自建並長期維護這類系統。

在一個完全 Agent 化的世界裡，最難解決的問題之一是：哪些 Agent 被授權做什麼？它們代表誰行動？這些行為如何被審計？如果一個記錄系統能夠成為 Agent 之間互動的身份與權限層，它就會獲得一種真正難以被替代的結構性角色。這裡的壁壘不僅是它持有什麼數據，而是它執行著怎樣的信任架構。

往前看，對於 AI 原生創業公司而言，一組新的因素將變得越來越重要，並決定它們能否形成防禦性。

第一，重建這個記錄系統到底有多難？

數據會在幾個層面變得更加重要。

首先，在短期內，關鍵在於提取並重建記錄系統底層數據的難易程度。AI 正在讓這件事變得更容易，一批工具正在幫助用戶完成這類遷移和重建。

短期內，既有廠商可以、也很可能會讓這件事變得更難：它們可以讓 API 難用、設限、不完整，或者在經濟上變得不划算，甚至根本不提供 API。但隨著提取工具不斷進步，尤其是能夠操作電腦的 Agent 能力提升，數據重建會變得越來越容易。

與此同時，新公司也正在從郵件、電話、語音 Agent 和內部文檔中重建一套更豐富的數據。AI 降低了重建一個記錄系統前 80% 的成本。真正區分一個有用切入口和一個真正替代品的，是剩下 20%：異常情況、審批流程、合規要求，以及邊緣場景下的工作流。

第二，是否擁有真正有意義的專有數據？

其次，數據本身會變得更有價值。

真正具備防禦性的數據，並不是你導入的數據，而是你的產品獨特地促成其產生的數據。我們常說「數據圍牆花園」：這些數據要麼是專有的，要麼受到監管約束，要麼需要持續更新。一個在收集權威且完整數據上投入大量資源的軟體供應商，相比通用型供應商或缺乏這類數據的競爭對手，會擁有明顯優勢。

數據還有另一個重要方向：它是否依賴產品內部產生的動作。

最好的公司不會只是儲存從別處輸入的數據。它們會因為自己處在流程之中，持續產生新的數據尾跡，例如觀察到的行為、響應率、時間模式、流程結果、行業基準、異常模式，以及 Agent 的執行軌跡。

關鍵在於：數據如今就是上下文。

第三，是否掌握動作層？

在舊世界裡，儲存記錄本身就已經足夠。但在新世界裡，Agent 會直接採取行動，防禦性可能會轉向那些能夠形成閉環的產品：從採取行動，到捕捉結果，再到利用反饋優化未來決策。

對 ERP 來說，這可能包括審批支出、觸發薪資發放、核對發票、發送通知等。能夠閉環的產品更具防禦性，因為它們嵌入了執行過程，而不僅僅停留在觀察層面。它們會生成獨特數據，隨著使用而持續改進，也會因為一旦移除就會破壞工作流而變得更難替代。

當然，隨著上下文越積累越多、邊緣場景處理得越充分，這裡的價值也會進一步上升。

第四，是否包含現實世界的執行環節？

有些商業模式與現實世界的運營連接在一起，而這些環節不會被完全自動化。最明顯的例子，是擁有運營網絡的公司，比如 DoorDash。它們歷史上並不屬於記錄系統，但在這裡很有啟發意義。

更廣泛地說，任何能夠把軟件閉環延伸到服務、履行、物流、現場運營或支付環節的公司，都擁有一種不同於純 SaaS 的防禦性。這類公司不只是儲存記錄，也不只是推薦動作；它們會派遣人員、移動貨物，或完成具體服務。

對創業者來說，這意味著機會可能出現在這樣一些市場：軟件越來越能夠做決策，Agent 越來越能夠協調流程，但最後一公里仍然需要現實世界的執行。例如，與現場服務綁定的垂直軟件，就是一個典型方向。

第五，是否存在網路效應？

歷史上，大多數記錄系統的網路效應都很弱，因為它們主要是內部軟件。但在 Agent 時代，如果一個系統嵌入了多方工作流，網路效應可能會變得重要得多。

如果一個系統負責調解多方之間的重複互動，比如買家與賣家、雇主與員工、公司與審計師、供應商與客戶、付款方與服務方，那麼每增加一個參與方，都可能讓這個網路對下一個參與方更有價值。

其中一種方式，是共享工作流協同：產品成為流程雙方進行交易、交換上下文、處理異常的場所。

另一種方式，是基準與智能：系統可以基於網路中觀察到的模式，呈現行業常態、異常情況和行動建議，這一點又與前面提到的資料價值相互強化。

第三種方式，是信任與標準化：一旦交易對手方開始依賴同一套軌道來完成審批、交接、合規或支付，這個產品就不再只是一個資料庫，而是市場本身的協同基礎設施，因此也會更難被替代。

第六，買方的技術能力有多強？

在一個任何人理論上都可以自建 Agent 的世界裡，不同買方真正具備的建設能力仍然差異巨大。尤其是在垂直行業，以及那些過去並沒有強大內部工程資源的職能型買方中，他們自己搭建、維護並持續改進資料庫、工作流邏輯、Agent 堆疊和治理層的機率仍然很低。

成本在這裡同樣重要。DIY 理論上可能減少軟體授權費用，但往往會把支出轉移到實施、維護和內部複雜性上。

這意味著，在那些運營複雜但技術供給不足的品類中，仍然存在真實機會。例如製造業、建築業後台、工業流程、現場服務工作流，以及會計等領域。

還有一些因素也同樣重要，並且會逐漸成為軟體的基本門檻。

比如，本體論需要變化。很多「自建資料庫」的想法，低估了對象模型本身承載的價值。既有軟體是為儀表板、報表和人類使用者構建的，它們捕捉的是工作流中的對象，比如商機、工單、候選人等。

但 Agent 時代的 schema 需要捕捉推理、動作、狀態追蹤、異常處理、任務委派，以及跨系統協同。原生對象模型可能不再是商機、工單和候選人，而是任務、意圖、線程、策略或結果。

同樣，權限體系也需要更新。它不再只是管理人類使用者，而是要管理 Agent。這包括：誰可以做什麼，通過哪個 Agent，在什麼策略下，需要哪些審批，留下怎樣的審計軌跡，以及如何進行回滾和異常處理。

當然，所有這些都離不開成本問題，例如搭建和維護 Agent 及資料庫需要多少錢，API 存取成本有多高。這又會重新回到幾個核心問題上：資料重建有多難，依賴關係有多少，以及系統到底嵌入了多深。

那麼，結論是什麼？

隨著既有軟體廠商走向 headless，它們實際上是在做一個隱含押注：數據層仍將是價值的核心來源。在某些品類中，尤其是金融服務這類深受合規約束的領域，這一押注或許還能在一段時間內成立，headless 化的進程也可能來得更慢。

但對軟體創業者而言，隨著既有廠商開始去界面化，如何與它們競爭、如何構建具備長期防禦性的軟體，問題正在發生變化。

下一代記錄系統已經開始呈現出不同形態：它們不再只是用於記錄人類工作的數據倉庫，而是更具 Agent 屬性——能夠捕捉上下文、主動發起工作，並記錄執行過程中產生的數據尾跡。

更進一步，最有趣的公司將會延伸到現實世界的執行層：它們會協調現場工作人員、物流服務商、服務團隊和實體資產，或者處在多個參與方之間，成為多方協作的中間層。

這些公司將混合舊世界的多種商業模式。而傳統記錄系統的核心，也就是數據，將逐漸退到後台，成為支撐整個系統運轉的底層基礎。

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia