創(chuàng)業(yè)者思考：如何做 AI Agent 喜歡的基礎(chǔ)軟件？

本篇內(nèi)容轉(zhuǎn)載自「我世界的源代碼」。 作者黃東旭，是 PingCAP 的聯(lián)合創(chuàng)始人兼 CTO。

快到圣誕節(jié)了，在美國，我周圍已經(jīng)彌漫著放假的氣息，這幾天正好有點時間，把最近我一直在反復(fù)思考一個問題寫一寫。我最近越來越清晰地看到了一個趨勢：Infra 軟件的主要使用者，正在從開發(fā)者（人類）迅速轉(zhuǎn)向 AI Agent。

例如數(shù)據(jù)庫，我有直接的體感，在 TiDB Cloud 上，已經(jīng)觀察到一個非常明確的信號：我們每天新創(chuàng)建的 TiDB 集群里，超過 90% 是由 AI Agent 直接創(chuàng)建的，這已經(jīng)是發(fā)生在生產(chǎn)環(huán)境里的現(xiàn)實。

持續(xù)觀察這些 Agent 是如何使用數(shù)據(jù)庫、如何創(chuàng)建資源、如何讀寫數(shù)據(jù)、如何試錯，我學(xué)到了很多，AI 使用方式和人類開發(fā)者非常不同，也不斷在挑戰(zhàn)我們過去對「數(shù)據(jù)庫應(yīng)該如何被使用」的默認(rèn)假設(shè)。

也正因為如此，我開始嘗試從一個更偏本體論的角度重新思考：當(dāng)基礎(chǔ)軟件的核心用戶不再是人，而是 AI 時，它應(yīng)該具備哪些本質(zhì)特征？目前還只是一些階段性的思考和結(jié)論，未必成熟，但我覺得值得先記錄下來。

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

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

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

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

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

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

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

01好的心智模型，

一定是穩(wěn)定且可擴展的

第一個要注意的是，當(dāng)使用者從人類變成 AI，軟件真正暴露給用戶的不再是 UI 和 API，而是它背后的心智模型。

LLM 在訓(xùn)練過程中，已經(jīng)內(nèi)化了大量隱含的假設(shè)和事實約定。其實寫代碼那么多年，我越來越覺得計算機世界里最根本的東西，在被發(fā)明出來之后，其實就很少再發(fā)生本質(zhì)性的變化了。尤其是越靠近底層的部分：文件系統(tǒng)、操作系統(tǒng)、編程語言、進(jìn)程模型、I/O 抽象。這些東西幾十年下來，形態(tài)在演進(jìn)，但核心思想、接口邊界，以及背后的假設(shè)，變化并不大。

當(dāng) AI 在訓(xùn)練過程中接觸了海量代碼（人類屎山）和工程實踐之后，它看到的其實并不是多彩多樣的世界，而是大量重復(fù)的模式：重復(fù)的抽象、重復(fù)的輪子、重復(fù)的選擇、重復(fù)的錯誤修復(fù)方式。這些重復(fù)一旦足夠多，就會沉淀為一種非常強的先驗（畢竟人類的本質(zhì)其實是復(fù)讀機 LOL）

所以，我的一個結(jié)論是：如果你希望設(shè)計的是「給 AI Agent 使用的軟件」，那你必須盡可能去貼合這些古老、卻被一再驗證的心智模型。

這些模型并不新，它們往往已經(jīng)存在了幾十年，例如文件系統(tǒng)，Bash Shell，Python，SQL... 它們共同的特點是：底層心智模型極其穩(wěn)定，上層膠水非常靈活。

在這些心智模型之上，人類構(gòu)建了大量膠水代碼（我一直覺得真正的 IT 世界其實是由這些膠水組成的）。很多看起來復(fù)雜的系統(tǒng)，拆開之后，本質(zhì)上只是圍繞著這些穩(wěn)定抽象做組合和編排。

從這個角度看，設(shè)計給 Agent 使用的軟件，并不是去發(fā)明一套「全新的正確接口」（這也是我不看好以 LangChain 為代表的一系列新的 Agent 開發(fā)框架的原因，因為它太新了，連程序員都懶得學(xué)，更何況 AI 了），而是要主動去順應(yīng)這些已經(jīng)被訓(xùn)練進(jìn)模型里的認(rèn)知結(jié)構(gòu)。換句話說，Agent 不是在等待一個更聰明強大的系統(tǒng)，而是更喜歡一個「它已經(jīng)懂的系統(tǒng)」然后用比人類嫻熟 1000 倍的效率寫膠水代碼擴展它。

好的心智模型的特征是它一定是可擴展的。

以文件系統(tǒng)為例，這是我最近拿來反復(fù)思考的對象。無論是 Plan 9 的 9PFS，還是 Linux 的 VFS，本質(zhì)上都做了一件非常重要的事情：允許你在不破壞原有心智模型的前提下，引入全新的實現(xiàn)。

一個典型的例子是我最近折騰的試驗性文件系統(tǒng) agfs (https://github.com/c4pt0r/agfs)，簡單來說這是個可插拔的文件系統(tǒng)，你可以實現(xiàn)各種各樣稀奇古怪的能力，只要滿足文件系統(tǒng)的接口約束就行，一個典型的例子：vectorfs，在 vectorfs 里，文件依然是文件，目錄依然是目錄，echo、cat、ls、cp -r 這些操作一切照舊；但在這個完全沒有改變的心智模型之下，vectorfs 的實現(xiàn)偷偷做了很多事：

cp 進(jìn)這個 vectorfs 的文件夾中的文檔被自動切分、生成向量、寫入 TiDB 的向量索引；grep 不再只是字符串匹配，而變成了語義相似度搜索；

…

Linux VFS 也是一樣道理，你可以實現(xiàn)一個完全不同語義、完全不同后端的用戶態(tài)文件系統(tǒng)，但只要它遵循 POSIX 約定，就可以被掛載進(jìn)現(xiàn)有系統(tǒng)，立刻成為系統(tǒng)的一部分。對上層來說，世界并沒有改變；對系統(tǒng)本身來說，它卻獲得了持續(xù)演化的能力。這個在 AI 的時代尤其重要，因為 AI Agent 寫代碼的速度是人類的幾千倍，也就是系統(tǒng)的演進(jìn)速度是人類的幾千倍，如果沒有穩(wěn)定的約束很容易就飛了，但是如果抽象是封閉的，那么又沒辦法利用這個效率持續(xù)演化。

在這個基礎(chǔ)上，其實還有一個很自然的推論：軟件生態(tài)到底還重不重要？語法、協(xié)議、這些在 Agent 時代看起來很像舊時代八股文的程序員偏好的東西，到底還值不值得糾結(jié)？

我的結(jié)論是：重要，也不重要。先說「不重要」的那一面。

如果你的軟件是建立在一個正確的心智模型之下，那么它和主流方案之間，很多時候真的只是語法差別。比如 MySQL 的語法和 Postgres 的語法，比如 MongoDB 和其他一些 NoSQL 數(shù)據(jù)庫之間的選擇，這些問題在人類開發(fā)者之間經(jīng)常能吵得頭破血流，但從 Agent 的角度看，其實意義不大。Agent 并沒有「偏好」。它不會在乎語法優(yōu)不優(yōu)雅，也不會在乎社區(qū)文化，更不會糾結(jié)「哪一個更像正統(tǒng)」。只要接口是穩(wěn)定的、語義是清楚的，生態(tài)的是完備的，網(wǎng)上能找到豐富的文檔，它就可以很快適配。這種偏好性的差異，在 Agent 這邊會被完全磨平，幾乎可以忽略。

但這并不意味著生態(tài)完全不重要。

它之所以「重要」，并不是因為語法本身，而是因為流行的軟件，往往對應(yīng)著非常經(jīng)典、非常穩(wěn)固的心智模型，廣泛存在與 LLM 的訓(xùn)練語料中。不管是 MySQL 還是 Postgres，本質(zhì)上都是關(guān)系型數(shù)據(jù)庫，背后都是 SQL 這個模型。而 SQL 本身，就是一個被反復(fù)驗證過的、極其穩(wěn)定的抽象，知識從 pg 遷移到 mysql 或者反過來都是很容易的事情。

所以在這個大的心智模型框架是正確的前提下，你用 MySQL 還是 Postgres，其實都能做 CRUD，都能保證一致性，也都能被 Agent 理解和使用。語法和生態(tài)的差別，更像是方言問題，而不是世界觀的差別。所以對我來說，真正重要的不是生態(tài)表層的差異，而是你軟件背后采用的模型是不是對的、是不是足夠穩(wěn)固。只要這個模型站得住腳，Agent 會自動幫你跨過剩下的那些八股文似的品味之爭。但是這也意味著一個悲傷的推論：今天要在范式級別創(chuàng)新是更加困難了，這也是在前面我不看好類似 Langchain 這樣的編程框架的原因。

02接口設(shè)計：Agent 應(yīng)該如何與你的系統(tǒng)對話？

如果說前面討論的是「Agent 更容易理解什么樣的系統(tǒng)」，那接口設(shè)計關(guān)注的就是另一個問題：Agent 應(yīng)該如何與你的系統(tǒng)對話。在 Agent 作為用戶的時代，一個好的軟件接口，至少需要同時滿足三個條件：

• 可以被自然語言描述

• 可以被符號邏輯固化

• 并且能夠交付確定性的結(jié)果。

其中如果第二條做得足夠好，第三條是自然完成的。

先展開說一下「接口能夠被自然語言描述」這一點，我覺得這里的核心其實不是「要不要支持自然語言輸入」，而是：你的軟件接口本身，是否適合用自然語言來表達(dá)意圖。

舉一個很直觀的例子，像 Cloud Code 就主動放棄了傳統(tǒng)的圖形界面。原因并不復(fù)雜，圖形界面在很多時候，其實是很難被自然語言準(zhǔn)確描述的。你很難用一句話把「點哪里、拖到哪里、選中哪個狀態(tài)」講清楚，而一旦脫離了視覺上下文，這套接口對 Agent 來說就幾乎是不可見的，而編碼絕大多數(shù)場景是在符號和語言打交道。

這里背后還有一個更現(xiàn)實的原因：我們今天使用的模型，本質(zhì)上仍然是語言模型。讓模型去理解一段文字，遠(yuǎn)比讓它去理解一張圖片或者一套隱含的交互狀態(tài)要簡單和可靠得多。所以，對 Agent 友好的接口設(shè)計是：你的系統(tǒng)能力，本身就可以被自然語言清楚地描述出來。

一個常見的反對意見是：自然語言是有歧義的，因此不適合作為嚴(yán)肅系統(tǒng)的接口。但站在 Agent 的視角，這個問題可能需要重新思考。

今天的 LLM，已經(jīng)非常擅長「猜出我們到底想做什么」。這并不是因為語言突然變得精確了，而是因為模型在訓(xùn)練過程中已經(jīng)見過了無數(shù)類似的意圖表達(dá)、上下文約束和任務(wù)模式。成功率也許不是 100%，但在絕大多數(shù)工程場景下，它已經(jīng)足夠高。

例如，在最新的 Claude Code 中，已經(jīng)開始加入預(yù)測你下一步會干啥的功能，我自己的使用經(jīng)驗是，大多數(shù)情況下，預(yù)測是很準(zhǔn)確的。

其實人類在真實世界里完成復(fù)雜工作的方式，本身就是高度依賴自然語言的，無論是和同事討論方案，還是在自己腦子里推演，我們的思考過程就是一連串帶有歧義、上下文依賴、不斷自我修正的自然語言描述。從這個角度看，自然語言并不是一種不精確的 tradeoff，而是人類解決問題時的原生表示。LLM 模型所做的，只是把這種原本發(fā)生在人類之間的推理過程規(guī)模化和數(shù)字化了。

所以啊，與其過分擔(dān)心歧義，不如承認(rèn)一個現(xiàn)實：當(dāng)?shù)讓酉到y(tǒng)軟件的心智模型是對的、接口的語義是穩(wěn)定的、結(jié)果是可驗證的時，上層調(diào)用者（Agent）的少量歧義并不會成為系統(tǒng)性問題。Agent 可以通過上下文、反饋和反復(fù)嘗試來消解它（通常不會錯得離譜），而不需要一開始就被迫進(jìn)入一套過度嚴(yán)格的形式體系。

在數(shù)據(jù)庫領(lǐng)域，這一點其實最近已經(jīng)有了很好的實踐，比如 Text-to-SQL。它未必百分之百準(zhǔn)確，但它證明了一件事：如果你的系統(tǒng)抽象是對的，那么它的能力天然就適合被語言描述。

我甚至?xí)X得，對于一個「設(shè)計正確」的系統(tǒng)來說，完成一個意圖大多數(shù)情況只有一種正確的方式，這樣的系統(tǒng)也是很自然語言友好的。就像我很喜歡的 Go 語言就遵循這個設(shè)計哲學(xué)。很多人不喜歡這一點，但是我覺得這是一個相當(dāng)有智慧的設(shè)計，極大的減少了產(chǎn)生歧義的空間。

不過也正因為自然語言輸入可以是有歧義的，系統(tǒng)內(nèi)部反而必須盡早收斂到一個無歧義的中間表示。這正是我想說的第二點：系統(tǒng)的符號邏輯能被固化。

自然語言非常適合用來表達(dá)意圖，但它并不適合承擔(dān)執(zhí)行語義。一旦任務(wù)要被復(fù)用，組合和自動化驗證，就必須被壓縮成一種明確、穩(wěn)定、可推理的形式。

這也是為什么，幾乎所有成功的系統(tǒng)，都會在「人類可讀的輸入」和「機器可執(zhí)行的行為」之間，放置一個中間層，例子仍然是： SQL，腳本，代碼，配置文件。。。它們的共同點是一旦生成，就不再依賴上下文解釋。

在 Agent 作為使用者的場景下，這個中間表示的意義被進(jìn)一步放大了。Agent 可以容忍輸入階段的模糊，通過猜測和多輪修正（與人類）來逼近意圖。因此，一個 Agent 友好的系統(tǒng)接口設(shè)計要明確地回答一個問題：「在什么時刻，歧義被徹底消除？」

當(dāng)這個時刻被清晰地定義出來，系統(tǒng)就獲得了一種新的能力：它可以將一次模糊的意圖，凍結(jié)為一個確定的結(jié)構(gòu)，可存儲、可審計、可復(fù)用，也可以被另一個 Agent 在未來重新加載并繼續(xù)執(zhí)行。自然語言負(fù)責(zé)探索空間，符號負(fù)責(zé)收斂空間。而只有在完成這一步之后，「確定性的結(jié)果」才成為可能。

那什么樣的邏輯符號描述是好的？我個人的一個評價標(biāo)準(zhǔn)是：這個中間邏輯符號描述表示是否可以用盡可能少的 Token，實現(xiàn)最多的可能性。

而我認(rèn)為目前（2025 年底）最好的邏輯符號描述，就是代碼，即使對于非編程 Agent 來說也是。

這并不是一個「節(jié)省成本」的問題，而是一個認(rèn)知密度的問題。我舉個例子，我最近想背單詞，于是找了一份 10000 個單詞的詞表，但是這個詞表只有英文單詞，我希望用 LLM 給我生成一份有中英釋義的版本。最土的辦法，就是直接把整個詞表發(fā)給 LLM，然后說：給每一行加上中文釋義，最后讓 LLM 輸出整個帶中英釋義的詞表。

但這個方式的問題非常明顯：它對 Token 的使用極其低效。一個更好的方式，其實是把這個需求先固化成一段邏輯，也就是一段 Python 腳本:

            out.write(f"{word}\t{zh}\n")

一旦這個邏輯被表達(dá)成代碼（或者接近代碼的形式），你就不再需要把所有數(shù)據(jù)都塞進(jìn)上下文里。模型只需要理解一次「代碼規(guī)則」，然后把它應(yīng)用到任意規(guī)模的數(shù)據(jù)上，Agent 只用極少的符號，描述了一個可以被無限重復(fù)執(zhí)行的過程。這就是為什么我堅持編程其實是最好的 Meta Tool 的原因（我不喜歡瘋狂堆 MCP Tool 的風(fēng)氣）。

03AI Infra's Infra 需要具備哪些必要特征？

AI Infra's Infra, 我承認(rèn)這個標(biāo)題有些拗口，但是你能理解這個意思就好。

當(dāng) AI Agent 成為 Infra 的主要使用者之后，很多我們以前覺得理所當(dāng)然的設(shè)計，其實都開始不太成立了。

現(xiàn)在 AI Infra 的用戶已經(jīng)不是那種會被認(rèn)真規(guī)劃、長期維護(hù)的「人類開發(fā)者」了，而是 Agent：它們會非常快地創(chuàng)建資源、試一把，不行就丟掉，再換個方式重來。而且這種嘗試的速度和效率，往往是人類的成千上萬倍，這也直接改變了 Infra 應(yīng)該長成什么樣。

日拋型代碼

先說一個很明顯的點：Agent 產(chǎn)出的工作負(fù)載，本質(zhì)上就是日拋型的。能不能開箱即用、能不能隨時創(chuàng)建、失敗了是不是可以毫無負(fù)擔(dān)地扔掉，這些都比「長期穩(wěn)定運行」重要得多。哪怕成功了，很多時候也只是階段性結(jié)果，并不一定會被保留下來。

這意味著，Infra 的設(shè)計前提已經(jīng)不能再是假設(shè)「一個集群很寶貴」。你必須假設(shè)實例本身是便宜的、生命周期很短、而且數(shù)量會漲得非常快。

我在觀察 AI Agent 使用 TiDB 的時候，有一個特別直觀的感受：它們很喜歡同時拉起多個 branch 并行干活，只要有一個分支跑通了，其他的基本就可以直接放棄了。Agent 寫的 SQL 也好，生成的代碼也好，看起來往往都挺「膠水」的，不追求優(yōu)雅，但只要

能跑、能驗證想法，就完全可以接受。

順著這個思路，其實還有一個很自然的推論。

由于 AI Agent 的出現(xiàn)寫代碼的門檻已經(jīng)被拉得非常低了，低到什么程度呢？低到「寫代碼」這件事本身，已經(jīng)不再是稀缺能力了。很多在過去需要工程師投入大量時間才能完成的東西，現(xiàn)在對 Agent 來說只是一次生成成本的問題。

這件事意味著什么？我覺得一個很重要的變化是：大量過去被忽略、被認(rèn)為「不值得做」的需求，其實都突然變得可行了。不管是某個很小的功能、一次性的工具，還是只服務(wù)于極少數(shù)用戶的場景，只要 Agent 能快速寫、快速跑、快速驗證，這些需求就不再需要被「篩選」掉。

換句話說，代碼的生產(chǎn)能力被極大地釋放了，最終被服務(wù)的對象，也不再只是那一小撮「值得投入工程成本」的用戶，而是更廣泛、更長尾的真實需求，于是我預(yù)計對于基礎(chǔ)軟件的可靠性和總租戶數(shù)量會爆炸性增長，但是對于服務(wù)連續(xù)性和可靠性的需求其實并沒有下降（這也是為什么我認(rèn)為 Supabase 之類因為流量少而 Pause 實例控制成本的方式是不可取的，再小的在線服務(wù)，也是在線服務(wù)）。

不過這一點，我更想放到后面商業(yè)模式變化那一節(jié)里單獨展開去說。因為當(dāng)供給側(cè)的成本幾乎趨近于零時，整個價值分配方式，其實都會隨之發(fā)生變化。

極致的低成本

這里說的「極致的成本」，并不是簡單意義上的「便宜」，而是指在滿足大量長尾需求的前提下，系統(tǒng)的成本還能不能撐得住。

前面提到，AI 把很多原本「不值得做」的需求都變得可行了。但這些需求有一個很典型的特點：訪問頻率非常低。可能一天就一兩個請求，甚至幾天才會被碰一次，但它們確實存在，而且確實有人（或者說有 Agent）在用。

如果你還沿用傳統(tǒng)的模型，比如一個任務(wù)對應(yīng)一個真實的 Infra 環(huán)境，或者像 Postgres 那樣，一個 Agent 任務(wù)背后就是一個 pg 進(jìn)程：你可以想象一下你的用戶規(guī)模起來以后，你要維護(hù)上百萬個這樣的實例，光是管理這些進(jìn)程、心跳、資源、狀態(tài)，本身的復(fù)雜性就已經(jīng)是一個不可承受的開銷了，更不用說機器成本。

所以在多租戶和成本這個問題上，我覺得有一個結(jié)論其實是繞不過去的：你不可能真的為每一個需求、每一個 Agent，提供一個真實的物理實例。

你必須引入某種形式的虛擬化：虛擬數(shù)據(jù)庫實例、虛擬分支、虛擬環(huán)境。它們在資源層面是高度共享的，但在語義層面，又必須是隔離的。

真正難設(shè)計的地方，其實就在這里：在實現(xiàn)極致資源復(fù)用的同時，還要在交互層面讓 Agent 感覺：這是我自己的獨立環(huán)境，我可以隨便折騰。

一個典型的例子來自于 Manus 1.5，他們背后的 Agent 其實在使用 TiDB Cloud 來作為數(shù)據(jù)庫方案，于是這些 Agent 它可以建表、刪表、跑實驗、寫垃圾 SQL，而不會影響別人，也不用擔(dān)心副作用。TiDB X 其實就是為了這個場景設(shè)計的（雖然幾年前我們在設(shè)計的時候沒有預(yù)想今天 AI Agent 的一切，只能說有點歪打正著的幸運）。全棧的 Webapp（Manus 1.5）比 Frontend（Lovable）要更難做，主要的難點就是成本。

如果你做不到這一點，Agent 就會被迫回到「謹(jǐn)慎使用資源」的模式；而一旦 Agent 需要開始「省著用」，整個并行探索、快速試錯，靈活性的優(yōu)勢就會被徹底抹掉。

從這個角度看，這種「看起來像獨占，實際上是虛擬化」的設(shè)計，并不是一個優(yōu)化項，而是想要構(gòu)建一個可規(guī)模化、超低成本 Agent Infra 的前提條件。

單位時間能撬動的算力

還有一個點，我覺得現(xiàn)在很多人討論 AI Agent Infra 的時候很少討論：單位時間，單位任務(wù)，你到底能撬動多少算力？這個指標(biāo)非常重要，因為這是 Agent 要完成復(fù)雜任務(wù)必須關(guān)注的。

舉個簡單的例子。現(xiàn)在不管是 ChatGPT，還是你在自己機器上跑的 Coding Agent，大多數(shù)交互模式都是一樣的：你問一句話，它把這句話發(fā)到某個 API 背后（可能是 OpenAI，也可能是 Anthropic），在他們數(shù)據(jù)中心的某一塊 GPU 上做推理，然后再把答案返回給你。你再問下一句，再來一輪。這意味著，從系統(tǒng)層面看，你單位時間能調(diào)動的算力資源，本質(zhì)上就被鎖定在「單次請求對應(yīng)的一塊 GPU」上。它當(dāng)然很強，但它的工作方式更像是「串行對話」，而不是「并行干活」。我們從 2022 年 ChatGPT 開始就習(xí)慣了這樣單機的基于人和機器一來一回對話的交互模式，而現(xiàn)實世界很多復(fù)雜任務(wù)是需要依靠大規(guī)模團隊分工合作的。

想象一個最簡單的場景：比如我想把今年 NeurIPS 的論文快速讀一遍，可能是幾百篇，然后挑出有意思的給我匯報。傳統(tǒng)的 Agent 邏輯大概率就是一篇一篇讀，最多做一點緩存或者總結(jié)模板，本質(zhì)上還是順序推進(jìn)。而如果換一個思路，把它當(dāng)成一個「分布式 Agent 團隊」的問題，事情會完全不同。你可以把任務(wù)拆成幾百個小塊，直接分發(fā)給 100 個、1000 個 Agent 并行去讀。它們讀完以后，各自把摘要、關(guān)鍵結(jié)論、疑點和引用發(fā)回來，再由一個匯總的 Agent 去做二次歸納、交叉驗證、結(jié)構(gòu)化輸出。你可以把它理解成一種「wide research」式的工作流，這是最簡單的一種分布式模式。

在這種模式下，你單位時間對一個任務(wù)能撬動的算力就不再是一塊 GPU，而是一個可以按需擴展的規(guī)模：剛才那個例子里，可能就是 100、1000，甚至更多。

而這恰恰會反過來提出一個非常具體的 Infra 問題： 如果 Agent 會天然傾向于這種并行探索，那你的系統(tǒng)是不是能讓它低成本快速地開 1000 個工位？能不能穩(wěn)定地分發(fā)任務(wù)、收斂結(jié)果、去重、糾錯？失敗是不是可控、可回放？成本是不是實時可見？這里面可能是一個 K8s 和 Hadoop 級別的機會。

04在 Agent 時代，

過去不太經(jīng)濟的商業(yè)模式變得合理了

在商業(yè)模式這一塊，我其實最想強調(diào)的第一個變化是：在 Agent 時代，很多過去不太經(jīng)濟的商業(yè)模式，突然變得合理了。

這個問題我們做基礎(chǔ)軟件、做數(shù)據(jù)庫的人，其實體感非常強。過去只要一提「定制化需求」，基本就是一個 red flag: 我的人是最貴的，為了一個小客戶、一個沒有普適性的場景去投入研發(fā)是不行的。

舉一個更容易理解的例子，假設(shè)有一個沒有任何計算機背景的小超市老板，他其實一直都很想做一個庫存管理系統(tǒng)，或者一個小小的網(wǎng)店，能幫他管商品、管訂單。但現(xiàn)實是，過去他很難一下子拿出十幾二十萬，去雇一個開發(fā)團隊，把這些東西按他的想法做出來，更別說后續(xù)的運維。

而從傳統(tǒng)軟件公司的角度看，這個需求同樣是不成立的，我不可能為了你一個小超市去投入一個團隊；更何況，即便做出來了，你的付費能力本身也是有限的。

所以在過去，需求其實一直都在，但它們被「經(jīng)濟性」擋在了門外。不是沒有人需要，而是沒有一種合理的方式，用足夠低的成本去滿足這些長尾的需求。

我覺得 Agent 改變的，恰恰是這一點。AI Agent 第一次把「計算」這件事，真正意義上地民主化了。寫代碼、試想法、做原型，這些過去必須由專業(yè)工程師完成的事情，現(xiàn)在可以被 Agent 以極低的邊際成本實現(xiàn)。很多以前算不過賬的事情，并不是需求消失了，而是成本終于降到足夠低了。

所以我現(xiàn)在越來越覺得，一個真正成功的 Agent 公司，最終不應(yīng)該是一家「賣 token 的公司」。

仔細(xì)想一想就會發(fā)現(xiàn)，單純賣 token 這件事，本身是有結(jié)構(gòu)性問題的。隨著用戶越來越多、任務(wù)越來越復(fù)雜，模型調(diào)用次數(shù)和上下文長度都會持續(xù)增長，而 token 的邊際成本并不會自動下降，哪怕 Token 單價在變得越來越便宜也好，只要你賣得越多，成本也隨之增長（而且別的競爭對手也會降價），這在商業(yè)上其實是非常脆弱的。從這個角度看，很多現(xiàn)在靠大量消耗算力來驅(qū)動的 Agent 公司，本質(zhì)上商業(yè)模型是站不穩(wěn)的。除非能像前面說的那樣，把「每一次都要重新推理」的事情，轉(zhuǎn)化為「一次構(gòu)建、反復(fù)使用」的服務(wù)，否則規(guī)模一上來，成本遲早會反噬增長。

于是真正能跑通的模式，或一家成功的 AI Agent 公司反而更像是一家把目標(biāo)用戶群體放大了 100 倍、1000 倍的云服務(wù)公司。關(guān)鍵不在于 token，成本，而在于你能不能把原本持續(xù)燃燒的 token 消耗，逐步沉淀成一些「boring」的在線服務(wù)，或者更進(jìn)一步，沉淀成靜態(tài)、確定性、可以被復(fù)用的系統(tǒng)能力。一旦做到這一點，邊際成本就會被極大地攤薄，甚至接近于零。

有意思的是，這并不意味著你最終提供的東西是「全新的形態(tài)」。云服務(wù)還是云服務(wù)，數(shù)據(jù)庫還是數(shù)據(jù)庫，很多底層能力本身都很傳統(tǒng)。真正發(fā)生變化的，是使用這些服務(wù)的用戶群體，被 Agent 放大了幾個數(shù)量級。

所以說到這里，我還是想再提一次 Manus 1.5Full stack webapp 這個例子（不好意思，又是這個 case），最近他們正好官宣了 ARR 過 100M USD, 還是比較應(yīng)景的。

一方面，它確實是我們 TiDB Cloud 的客戶；但更重要的是，我覺得它背后的商業(yè)模式設(shè)計，真的非常有意思，也非常有代表性。它并不是簡單地在賣算力、賣 token，或者靠一次次推理去換收入，而是在努力把 Agent 的「單次關(guān)鍵推理成本」，轉(zhuǎn)化成有規(guī)模化效應(yīng)的傳統(tǒng)云計算生意。

05結(jié)尾

寫到這里，也快要結(jié)尾了，其實說來說去，我的想法也挺簡單的，Agent 時代來了，很多我們作為程序員習(xí)以為常的前提，確實需要重新想一想了。代碼不再稀缺，軟件也不再是需要精心維護(hù)的東西，系統(tǒng)被創(chuàng)建、試用、丟棄，都會變得非常自然。

這并不是說工程不重要了，恰恰相反。只是工程的重點變了：不再是把某一個系統(tǒng)打磨到極致，而是去設(shè)計那些能被 AI 大規(guī)模使用、反復(fù)試錯、低成本運行的基礎(chǔ)能力。

放下對「我是不是在寫代碼」「我是不是在控制系統(tǒng)」的執(zhí)念，反而會更容易看清接下來要做什么。很多真正重要的事情，其實都回到了老問題上。

世界已經(jīng)切換到另一個使用方式了，沒必要太抗拒。

Welcome to the machine。

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