創業者思考：如何做 AI Agent 喜歡的基礎軟件？

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

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

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

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

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

??關注 Founder Park，最及時最干貨的創業分享

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

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

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

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

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

01好的心智模型，

一定是穩定且可擴展的

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

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

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

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

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

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

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

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

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

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

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

…

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

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

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

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

但這并不意味著生態完全不重要。

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

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

02接口設計：Agent 應該如何與你的系統對話？

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

• 可以被自然語言描述

• 可以被符號邏輯固化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

日拋型代碼

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

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

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

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

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

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

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

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

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

極致的低成本

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

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

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

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

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

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

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

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

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

單位時間能撬動的算力

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

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

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

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

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

04在 Agent 時代，

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

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

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

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

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

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

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

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

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

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

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

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

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

05結尾

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

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

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

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

Welcome to the machine。

轉載原創文章請添加微信：founderparker