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

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

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

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

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

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

超 17000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

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

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

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

• 最精準的AI產品曝光渠道

01好的心智模型，

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

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

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

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

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

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

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

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

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

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

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

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

…

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

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

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

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

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

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

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

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

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

• 可以被自然語言描述

• 可以被符號邏輯固化

• 并且能夠交付確定性的結果。

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

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

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

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

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

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

例如，在最新的 Claude Code 中，已經開始加入預測你下一步會干啥的功能，我自己的使用經驗是，大多數情況下，預測是很準確的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI Infra's Infra, 我承認這個標題有些拗口，但是你能理解這個意思就好。

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

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

日拋型代碼

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

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

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

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

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

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

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

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

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

極致的低成本

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

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

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

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

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

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

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

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

從這個角度看，這種「看起來像獨占，實際上是虛擬化」的設計，并不是一個優(yōu)化項，而是想要構建一個可規(guī)?；⒊统杀?Agent Infra 的前提條件。

單位時間能撬動的算力

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

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

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

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

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

04在 Agent 時代，

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

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

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

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

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

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

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

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

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

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

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

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

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

05結尾

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

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

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

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

Welcome to the machine。

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