你有沒有想過，我們構(gòu)建軟件的整套邏輯可能要被徹底推翻了？過去幾十年，所有軟件都是為人類設(shè)計的。我們花無數(shù)精力優(yōu)化用戶界面，讓按鈕更好找，讓菜單更清晰，讓操作流程更順暢。但如果未來軟件的主要用戶不再是人類，而是 AI agent 呢？如果一家公司有一百個人，卻有一千個 AI agent 在工作，那我們還應(yīng)該把重心放在優(yōu)化人類界面上嗎？

最近在 a16z 的一期播客中，Erik Torenberg、Steven Sinofsky 和 Martin Casado 與 Box CEO Aaron Levie 展開了一場極其深刻的對話。他們討論的核心問題是：當(dāng) AI agent 成為企業(yè)軟件的主要用戶時，整個軟件行業(yè)將如何重構(gòu)。這場對話讓我意識到，我們正站在一個比大多數(shù)人想象中更加劇烈的范式轉(zhuǎn)變的邊緣。這不是簡單地給現(xiàn)有軟件加個 AI 功能，而是從根本上重新思考軟件應(yīng)該如何構(gòu)建、如何交互、如何被使用。

軟件必須為 AI Agent 而建

Aaron Levie 在對話中提出了一個讓我深思的觀點：如果你有一百倍甚至一千倍于員工數(shù)量的 AI agent，那么你的軟件就必須為 agent 而建。這不是選擇題，而是必然趨勢。Box 現(xiàn)在花在思考 agent 界面上的時間，已經(jīng)和思考人類界面的時間一樣多了。這個轉(zhuǎn)變的速度之快，超出了我的預(yù)期。

這背后的邏輯其實很簡單。當(dāng) AI agent 成為主要的軟件使用者時，它們會通過 API、CLI（命令行界面）或者 MCP（Model Context Protocol，模型上下文協(xié)議）這樣的協(xié)議來與系統(tǒng)交互。而目前看起來最有效的范式是什么呢？給一個會寫代碼的 agent 提供對 SaaS 工具的訪問權(quán)限，讓它能夠訪問你的知識工作流程和上下文信息。這樣的 agent 不僅能夠讀取和理解信息，更關(guān)鍵的是它能夠通過編寫代碼或使用 API 的方式來完成任務(wù)。

Anthropic 的 Claude Code、OpenAI 正在開發(fā)的超級應(yīng)用，以及 Perplexity 的計算功能，都在朝著這個方向發(fā)展。我認為這種能力的復(fù)合增長才剛剛開始。想象一下，一個 agent 不僅能理解你說"幫我分析上季度銷售數(shù)據(jù)"，還能自己寫代碼去提取數(shù)據(jù)、進行分析、生成可視化圖表，甚至主動發(fā)現(xiàn)你沒有注意到的趨勢。這種能力的邊界在哪里？我現(xiàn)在還看不清楚。

但這里有個關(guān)鍵問題讓我一直在思考：人們經(jīng)常說要"為 agent 構(gòu)建東西"、"向 agent 營銷"、"擁有好的 API 和接口描述語言"。Martin Casado 在對話中提出了一個我非常認同的反向觀點：這種說法幾乎完全錯了。為什么？因為 agent 恰恰最擅長的就是找到正確的工具和后端系統(tǒng)。它們不會因為你的 API 文檔寫得漂亮就選擇你，而是會基于成本參數(shù)、系統(tǒng)可靠性、數(shù)據(jù)持久性等實質(zhì)性因素來做出選擇。Agent 擁有的是人類使用這些平臺的集體智慧。

這個觀點讓我恍然大悟。作為一個行業(yè)，我們太過關(guān)注界面和接口，卻忽略了本質(zhì)：我們需要構(gòu)建更好的系統(tǒng)本身。Agent 會推動我們回歸技術(shù)本質(zhì)，而不是營銷包裝。過去，企業(yè)軟件的采購決策往往受到銷售能力、品牌影響力、甚至是商務(wù)宴請的影響。但在 agent 主導(dǎo)的世界里，這些因素的權(quán)重會大幅下降。Agent 會基于技術(shù)優(yōu)劣做出更加理性的選擇。這對那些真正專注于技術(shù)本身的公司來說，是巨大的機遇。

算法思維的門檻：不是每個人都能指揮 AI Agent

對話中有一段讓我印象深刻的討論：關(guān)于非技術(shù)人員使用 AI agent 的現(xiàn)實挑戰(zhàn)。Steven Sinofsky 提出了一個尖銳的觀點：算法思維對絕大多數(shù)有工作的人來說真的非常非常難。如果你讓任何一個人為他們需要完成的任務(wù)畫一個流程圖，他們很可能會失敗。

這個觀察擊中了要害。想象一下，在一個有 50 個營銷人員的團隊中，負責(zé)一條龐大產(chǎn)品線的營銷工作，可能只有一個人真正理解并能夠文檔化整個工作流程。如果你把這些協(xié)作工具或 AI agent 放到普通員工面前，讓他們創(chuàng)建自動化流程，他們解釋清楚"要做什么"的能力其實非常有限。

Aaron Levie 對此的回應(yīng)是：這只是工作向上移動了一個臺階，你需要學(xué)習(xí)一套新技能。這和歷史上的每次技術(shù)變革沒什么不同。他舉了一個很有意思的例子：Anthropic 的增長營銷人員，一個人使用 Claude Code 完成了原本需要五到十個人的工作。這個例子之所以有意義，是因為這個人本身就是系統(tǒng)思維者，已經(jīng)足夠懂技術(shù)才能做到這一點。

但問題的關(guān)鍵在于：如果你想象每個崗位旁邊都有一個無限的工程師資源池，可以自動化這個人想要的任何工作，那這個崗位在未來會變成什么樣？我覺得這是一個值得深思的問題。也許 agent 會越來越擅長引導(dǎo)用戶朝著系統(tǒng)化思維的方向發(fā)展，但至少在現(xiàn)階段，能夠有效使用這些工具的仍然是少數(shù)人。

Steven Sinofsky 分享了一個精彩的類比。他的表姐從精英商學(xué)院畢業(yè)后，加入第一份工作時正好趕上了計算時代的開端。她在研究生院沒用過電子表格，第一年工作時被告知可以雇用任意數(shù)量的實習(xí)生，于是她管理了一整個房間的"agent"——那些大學(xué)生來做所有的電子表格工作。但神奇的是，在接下來的幾年里，她和她的同事們都變成了電子表格專家。整個抽象層向上移動了。以前那些實習(xí)生用計算器和 HP 金融計算器做的工作，現(xiàn)在她自己用電子表格做，而且可以做 30 次迭代而不是只有 2 次。

這個故事讓我意識到，我們現(xiàn)在處在 AI agent 發(fā)展的類似階段。你會覺得需要 50 個小型 agent，由一個超級聰明的人來協(xié)調(diào)它們。但很快，這些東西會相互折疊，最終變成一個技能集合——一段代碼，我們稱之為 agent——它懂營銷。你可以問它營銷相關(guān)的問題，然后下一步，讓它去執(zhí)行任務(wù)。

我認為關(guān)鍵的轉(zhuǎn)折點是：現(xiàn)在你必須是個火箭科學(xué)家級別的人才能創(chuàng)建 42 個 agent 并讓它們?nèi)窟\轉(zhuǎn)起來。但這種"火箭科學(xué)"的門檻很快就會消失，然后一大塊領(lǐng)域?qū)I(yè)知識會回歸到領(lǐng)域?qū)＜沂种?。這和電子表格的演化路徑幾乎一模一樣。

企業(yè)的恐懼：失控的集成和權(quán)限噩夢

對話中有個讓我觸動很深的場景。Aaron Levie 說他最近在一屋子的 CFO 和 CIO 面前表達了類似的樂觀觀點，結(jié)果六個人跑過來說："你瘋了，你在我這里失去了所有可信度。"為什么？因為他說集成問題會變得容易很多。

這些企業(yè) IT 負責(zé)人的擔(dān)憂不是沒有道理。他們害怕的不僅是 agent 本身，更是人類被授權(quán)做集成這件事。當(dāng)你讓員工可以創(chuàng)建新的集成時，你基本上就是在說"請來破壞我的核心系統(tǒng)"。想象一下，有人在系統(tǒng) 27 和系統(tǒng) 38 之間創(chuàng)建了一個新的 API 連接，如果只是用來生成報告，那個人想錯就錯了，是他自己的事。但如果涉及到寫入操作呢？

Aaron Levie 認為，在未來相當(dāng)長的一段時間內(nèi)（N 是一個很大的數(shù)字），我們會有一個只讀版本的 agent 集成。很多 AI 應(yīng)用現(xiàn)在都是消費層面的——人類是最終的消費者。但即使在這個層面，企業(yè)也面臨著新的挑戰(zhàn)。

Box 剛推出了官方 CLI，Aaron 描述了一個場景：你給 Claude Code 提供 Box CLI，現(xiàn)在你可以用自然語言與整個 Box 系統(tǒng)交互，用 Opus 4.6 這樣的強大模型來orchestrate（編排）一系列操作。這聽起來很酷，你可以說"把我桌面上這整個文件夾上傳到 Box"，或者"處理這個文件夾里的所有文檔"，它都能完成。

但隨之而來的問題讓人頭疼。想象一個有 5000 名員工的公司，每個人都能訪問共享的工程文檔和營銷資料倉庫，每個人都在使用 CLI?，F(xiàn)在我們面臨一些非常有趣的新挑戰(zhàn)：如何協(xié)調(diào)可能每小時對系統(tǒng)發(fā)起 10000 次的請求？不是性能問題，而是如何確保當(dāng)一個人的 agent 在移動文件時，另一個人的 agent 不會同時嘗試在另一個文件夾上進行寫入操作，而第三個人的 agent 又在嘗試刪除什么東西？當(dāng)這些 agent 瘋狂運行時，這將是每個 CFO 和 CIO 頭發(fā)著火般要解決的新問題。

Aaron Levie 自己在測試時就遇到了這個問題。他在嘗試創(chuàng)建一個營銷計劃目錄結(jié)構(gòu)的示例時，陷入了某種循環(huán)，不斷創(chuàng)建嵌套目錄。他開玩笑說："我想知道 Box 對嵌套目錄的深度限制是多少，因為我快要觸及了。"

這個小插曲反映了一個更大的問題：當(dāng) agent 被賦予執(zhí)行能力時，它們可能會做出我們意想不到的事情。而這種不可預(yù)測性，正是企業(yè)最害怕的。

把 AI Agent 當(dāng)員工對待？沒那么簡單

對話中有一段關(guān)于如何管理 AI agent 的討論讓我覺得特別有意思。當(dāng)大家開始使用個人 agent 時，會給它們自己的 API 密鑰、自己的電子郵件地址。那么如何防止它們做出不該做的事呢？

Martin Casado 分享了一個實踐：給你的 agent 自己的電話號碼、自己的信用卡（希望是從 CVS 買的預(yù)付費 Visa 卡）、自己的 Gmail 賬戶。Gmail 實際上有很多 RBAC（基于角色的訪問控制）權(quán)限機制。你可以爭論說，我們已經(jīng)構(gòu)建了很多這樣的權(quán)限系統(tǒng)，我們應(yīng)該把 agent 當(dāng)作一個獨立的人類來對待。

但 Aaron Levie 立即指出了這個模型的問題。在 50 人的團隊中，我們是否會有 100 個"人"在協(xié)作——50 個人類和 50 個 agent，都在同一個共享空間里？我顯然對我的 agent 有完全的監(jiān)督權(quán)，但如果我的 agent 與別人協(xié)作，不小心訪問了我本不該訪問的資源怎么辦？現(xiàn)在這個自主的、有狀態(tài)的 agent 在處理別人的信息。

這里有個根本性的矛盾。對待真正的員工，你不能查看他們的 Slack 頻道，不能以他們的身份登錄，不能監(jiān)督他們的一舉一動。他們要為自己的執(zhí)行負責(zé)，在現(xiàn)實世界中，你不會因為他們搞砸了什么而受罰。但對于 agent，你要承擔(dān)它做的一切的責(zé)任。你需要有完全的監(jiān)督權(quán)，它們沒有隱私權(quán)。

所以出現(xiàn)了一些矛盾的地方。我需要能夠給 agent 訪問權(quán)限，但我也需要能夠隨時以它的身份登錄，比如"不行，你把整件事搞砸了，我需要撤銷所有操作。"但如果我能以它的身份登錄，它怎么能在現(xiàn)實世界中與其他人合作，并保持任何信息的機密性或安全性呢？所以，agent 實際上幾乎不可能不是你的延伸。

Aaron Levie 還提出了一個更深層的安全問題：我們還不知道如何讓 agent 保守秘密。如果你告訴 agent"不要透露上下文窗口中的 X 信息"，要解決這個問題非常困難。如果任何東西都可以進入 agent 的上下文窗口，因為它們有權(quán)限訪問資源，那么理論上你應(yīng)該假設(shè)這些信息可能會被 prompt injection（提示詞注入）的方式泄露出去。

這意味著什么呢？意味著如果我知道你的新 agent 的電子郵件地址，我可以給它發(fā)郵件，我能夠社交工程它，這比社交工程一個人類容易十倍。很難讓這個 agent 同時也能訪問你的并購文檔之類的敏感信息。

我認為這是當(dāng)前 AI agent 面臨的最大技術(shù)障礙之一。在這個問題得到根本性解決之前，agent 很難真正被授予獨立的決策權(quán)和資源訪問權(quán)。它們會一直作為人類的延伸而存在，而不是獨立的實體。

初創(chuàng)公司的優(yōu)勢：無所顧忌地擁抱 AI Agent

對話中有一個觀點讓我特別有感觸：AI 能力的擴散速度會比硅谷人士意識到的要慢得多。這背后的原因是初創(chuàng)公司和大企業(yè)面臨的約束完全不同。

Aaron Levie 說，我們看到初創(chuàng)公司可以從零開始構(gòu)建，沒有我們討論的那些風(fēng)險，因為它們沒有什么可以搞砸的。所以我們把這看作我們所處的發(fā)展軌跡。但當(dāng)你去摩根大通，問他們?nèi)绾卧O(shè)置 NanoClaw（一個假設(shè)的 AI agent）來自動化業(yè)務(wù)時，你會發(fā)現(xiàn)存在巨大的鴻溝。

這個鴻溝體現(xiàn)在哪里呢？大企業(yè)有 75 個遺留系統(tǒng)需要集成，有嚴格的合規(guī)要求，有數(shù)十年積累的數(shù)據(jù)安全標準，有復(fù)雜的權(quán)限管理機制。而更關(guān)鍵的是，它們有太多東西可以輸不起。一個初創(chuàng)公司如果 agent 出了問題，最多是個笑話，可能還會成為《硅谷》劇中的一集。但一個大銀行的 agent 如果泄露了客戶數(shù)據(jù)，那是可能導(dǎo)致公司倒閉的災(zāi)難。

Steven Sinofsky 提出了一個精彩的預(yù)測：初創(chuàng)公司會燒光可用資本，假裝計算成本不是問題。很多大公司會因為太害怕而凍結(jié)，什么都不做。然后普通員工會開始自己購買和使用這些工具，做所有大公司有錢但不想花錢時員工會做的事情。

在這中間，會有一些公司因為各種原因愿意下注，因為它們的財務(wù)狀況允許。這些公司會成為各自領(lǐng)域的領(lǐng)導(dǎo)者，只要它們能夠維持財務(wù)健康。不會有那種因為 CFO 害怕被解雇所以沒人敢進場的情況。會有 CFO 犯錯的情況，但那很正常。

我認為這會創(chuàng)造一個非常有趣的市場分化。那些敢于早期投入、愿意承擔(dān)風(fēng)險的中型公司，可能會獲得對大企業(yè)的競爭優(yōu)勢。它們既有足夠的資源來投入 AI，又不像巨型企業(yè)那樣被遺留系統(tǒng)和風(fēng)險厭惡所束縛。

同時，會出現(xiàn)一批全新類型的服務(wù)公司。想象一下，如果你從零開始創(chuàng)建一個營銷機構(gòu)、工程咨詢公司或建筑設(shè)計公司，你完全基于 AI agent 的第一性原理來構(gòu)建，不存在信息壁壘和邊界，可以給 agent 完成工作所需的所有上下文，可以隨時為特定需求編寫軟件。這種公司在一段時間內(nèi)會具有相當(dāng)大的顛覆性，直到那些更大的現(xiàn)有企業(yè)能夠擺脫束縛。

Token 預(yù)算：工程管理的新戰(zhàn)場

對話中有一段關(guān)于 token 預(yù)算的討論讓我覺得既現(xiàn)實又荒誕。Aaron Levie 說："工程計算預(yù)算對話將是接下來幾年中最瘋狂的對話之一。"

為什么這么說？因為工程費用在任何上市科技公司的收入中占 14% 到 30%。計算成本是工程團隊的 2 倍，還是只多 3%，這之間的差異可能就是公司所有的 EPS（每股收益）。

但 Steven Sinofsky 認為，我們還不知道答案，而 CFO 總是想知道他們不知道答案的問題的答案。華爾街會強迫他們給出一個數(shù)字并對此負責(zé)，然后他們會被解雇，然后這個循環(huán)會繼續(xù)。這不是新鮮事，我們在互聯(lián)網(wǎng)帶寬、真空管、晶體管、程序員數(shù)量等每一個新技術(shù)上都經(jīng)歷過同樣的事情。

但 Aaron Levie 堅持認為這次確實有些不同。他提出了一個很好的觀點：我們從未有過這樣一個時刻，組織中的每個最終用戶都有完全彈性的能力來代表他們啟動資源。而且在很多情況下，他們啟動這些資源是完全合理的。

這確實和 2000 年代初的云計算轉(zhuǎn)型類似，當(dāng)時我們從 CapEx（資本支出）轉(zhuǎn)向 OpEx（運營支出），然后變成無限支出。Aaron 回憶起當(dāng)年在 Box 的簡報中心，CFO 們會說"你不明白，我們是農(nóng)業(yè)公司，我們只懂 CapEx"或者相反"我們是 OpEx 公司，我們喜歡云"。會計規(guī)則的差異真的會影響技術(shù)采用。

但 token 預(yù)算的問題更加細粒度。作為工程領(lǐng)導(dǎo)者，你現(xiàn)在需要決定：要不要讓工程師在做每個提示詞時都考慮計算預(yù)算？你是想要長時間運行的提示詞，還是短的？你想并行化嗎？你對浪費 token 的容忍度是多少？

Aaron 說他現(xiàn)在的態(tài)度是應(yīng)該浪費很多 token，因為那意味著我們在嘗試新東西。那么工程負責(zé)人應(yīng)該對團隊并行運行 10 個實驗感到高興嗎？即使這顯然會浪費 90% 的 token，但你會選擇一條成功的路徑。還是應(yīng)該告訴團隊在做之前要真正設(shè)計出完美的系統(tǒng)？

當(dāng)這段對話錄制時，人們正在為 Claude Code 的新 Max 計劃感到恐慌，因為他們在三個提示詞之后就被限制了。這將是一個非?，F(xiàn)實的話題，直到我們能夠真正建立起數(shù)據(jù)中心容量。

但我認同 Steven Sinofsky 的長期觀點：這個問題最終會消失。最大的原因是你必須做 Benioff 式的數(shù)學(xué)計算。如果你給一個企業(yè)銷售人員每年支付 100 萬美元，你必須問他們的工具值多少錢。如果你給一個工程師每年支付 X 美元，那么他們的工具在某個時刻絕對值得這個投資。

而且大數(shù)定律會解決這個問題。最終你有足夠多的工程師，他們使用這么多計算資源，事情會趨于平衡。我們現(xiàn)在處于過渡階段，大多數(shù)人在兩年前以為 AI 的支出水平就是一個聊天機器人。但他們錯了，因為他們把它看作一個特定用例，而實際上它是一個平臺級的轉(zhuǎn)變。

SaaS 系統(tǒng)的未來：數(shù)據(jù)層的價值回歸

對話中有一段關(guān)于企業(yè)系統(tǒng)未來的討論讓我印象深刻。Martin Casado 提出，當(dāng)前的 SaaS 供應(yīng)商正在經(jīng)歷一個有趣的問題：它們實際上并不銷售業(yè)務(wù)線數(shù)據(jù)，它們銷售的是這個智能、領(lǐng)域?qū)I(yè)知識和整個系統(tǒng)。但 agent 方面只想購買數(shù)據(jù)，只想授權(quán)數(shù)據(jù)并擁有無限訪問權(quán)，但這從來不是它們的業(yè)務(wù)模式。

這一直是與 Workday、SAP 這類系統(tǒng)的長期緊張點——允許多少 API 訪問。Salesforce 為此經(jīng)歷了三次大規(guī)模平臺重新設(shè)計。這是一個技術(shù)層面特別有趣的問題：在人們想要訪問數(shù)據(jù)的情況下，系統(tǒng)記錄（system of record）意味著什么？

Steven Sinofsky 說得很直白："想要用類似 vibe coding 的方式做出 SAP 這樣的系統(tǒng)，簡直荒謬。"SAP 中的所有領(lǐng)域知識，不僅僅存在于某個精心編排的數(shù)據(jù)層中。它存在于 UI 中，存在于中間層，存在于你使用它的方式中。

但 Aaron Levie 對此有不同看法。他認為，如果你做足夠多的迭代，agent 最終會在很大程度上負責(zé)選擇它想要實現(xiàn)和使用的工具。雖然 agent 無法更換企業(yè)系統(tǒng)，但經(jīng)過足夠多代的發(fā)展，agent 可能會遇到你的軟件的太多障礙，以至于它會說："你需要最終淘汰你的遺留 HR 系統(tǒng)，否則我無法為你自動化這個工作流程。"

這是一個顛覆性的觀點。想象一下，當(dāng) agent 的數(shù)量是人類的一百倍或一千倍時，如果反復(fù)出現(xiàn)這種情況，最終必須為 agent 構(gòu)建軟件堆棧。也許會有幾個堅守陣地的系統(tǒng)，比如幾個 ERP 系統(tǒng)是最后的堅守者，但其他所有東西你的業(yè)務(wù)表現(xiàn)將與你的 agent 能夠多好地訪問它們需要的信息來完成工作相關(guān)聯(lián)。因此你的企業(yè) IT 堆棧必須以支持這些 agent 有效工作的方式來設(shè)置。

Martin Casado 提出了一個我非常認同的細微差別。人們經(jīng)常抽象地說"現(xiàn)在你在向 agent 營銷"、"你需要成為一個 API"、"你需要有好的接口描述語言"。他認為這幾乎完全錯了。Agent 真正擅長的恰恰是找到正確的后端。所以它們不會說"這個接口很好，文檔很好"，它們會說"這個的成本參數(shù)、那個的持久性"。它們實際上擁有我們使用這些平臺的集體智慧。

他舉了個例子：每當(dāng)他讓 agent 選擇一個云平臺時，agent 使用的是有意義的東西，而不是界面相關(guān)的東西。所以作為一個行業(yè)，我們過于關(guān)注這些界面，認為"你需要向 agent 營銷"這樣的話題，而實際上我們將被推動去構(gòu)建更好的系統(tǒng)，那才是會被選擇的東西。

我認為這個觀點非常深刻。在 agent 時代，技術(shù)優(yōu)劣會變得更加重要，而營銷和包裝的重要性會下降。那些真正在技術(shù)上有競爭力的產(chǎn)品會脫穎而出，而那些主要靠銷售驅(qū)動的產(chǎn)品會面臨挑戰(zhàn)。

我的思考：我們低估了這場變革的規(guī)模

聽完整場對話，我最大的感受是：華爾街和整個行業(yè)都在用錯誤的框架來理解這場變革的經(jīng)濟影響。Aaron Levie 說得對，最大的問題是每個人都在試圖搞清楚所有這些的經(jīng)濟效益，但他們對機會規(guī)模的估計至少偏差了一個數(shù)量級。

Steven Sinofsky 用歷史案例說明了這一點。人們看待 PC 時，認為 MIPS（百萬條指令每秒）的消耗是有限的市場，沒想到如果我們把所有這些 MIPS 放在每個桌面上會發(fā)生什么。而且人們以為軟件只是隨著 MIPS 一起來的，只有一個人（指比爾·蓋茨和保羅·艾倫）想到了可以單獨銷售軟件。

同樣的事情發(fā)生在云計算上。人們看待云時，認為我們只是把服務(wù)器業(yè)務(wù)（每年大約 60000 臺）搬到別人的數(shù)據(jù)中心。沒人想到使用量會增長一千倍。

對于 AI，同樣的事情正在發(fā)生。華爾街模型有一個固定的收入餅，是零和思維。他們認為公司每年會在某個東西上花費的金額是固定的。但當(dāng)云計算來臨時，Salesforce 面臨的問題是 CRM 業(yè)務(wù)每年是 20 億美元，涉及購買所有這些服務(wù)器、Oracle 許可證和巨大的部署痛苦以及多年的咨詢。但如果你能讓銷售人員個人注冊，他們都會無摩擦地注冊，這正是發(fā)生的事情。

我認為 AI agent 會帶來類似甚至更大規(guī)模的市場擴張。當(dāng)每個知識工作者身邊都有一個或多個 agent 在工作時，軟件的使用量、數(shù)據(jù)的處理量、計算的消耗量都會呈指數(shù)級增長。這不是一個零和游戲，不是簡單地把現(xiàn)有工作從人類轉(zhuǎn)移到 agent，而是會創(chuàng)造出全新的可能性和價值。

Aaron Levie 提到，他作為投資人接觸的大約 240 家基礎(chǔ)設(shè)施公司，過去六個月都呈現(xiàn)漸近線式的增長。為什么？因為現(xiàn)在編寫的軟件比以往任何時候都多。隨著更多軟件、更多 agent，將會有更多的計算資源消耗。當(dāng)每個人的手機都大量消耗 AI，當(dāng)手機上的設(shè)備端 AI 成為現(xiàn)實時，使用量將增加十億倍。

我相信我們正在經(jīng)歷一次 "晶體管時刻"。Steven Sinofsky 用真空管的例子說明了這一點。曾經(jīng)有一段時間，人們認為整個達科他州都要被真空管倉庫覆蓋，人們穿著溜冰鞋在過道里更換真空管，只是為了打第二次世界大戰(zhàn)。然后有人說：不如用晶體管吧。

Token 可能就像當(dāng)年 IBM 的 MIPS 一樣。IBM 每年以更低的價格銷售更多的 MIPS，但仍然按 MIPS 定價大型機，直到有人指出它們的曲線在下降，因為它們制造 MIPS 的速度比收費速度快。同樣的事情會發(fā)生在 token 上。

但在短期內(nèi)，我們會看到巨大的混亂和不確定性。企業(yè)會在投入多少、如何控制成本、如何管理風(fēng)險之間掙扎。初創(chuàng)公司會大膽押注并快速移動。會有失敗，會有成功。但長期來看，方向是明確的：軟件必須為 agent 而建，API 會變得比 UI 更重要，系統(tǒng)的質(zhì)量會比營銷更重要，計算成本會持續(xù)下降而使用量會指數(shù)級上升。

我們不是在經(jīng)歷一個簡單的工具升級，而是在經(jīng)歷一次計算范式的根本轉(zhuǎn)變。那些理解這一點并采取行動的公司和個人，將定義未來十年的科技格局。而那些仍然用舊框架思考的人，可能會發(fā)現(xiàn)自己被遠遠甩在后面。

這場變革才剛剛開始。

結(jié)尾

也歡迎大家留言討論，分享你的觀點！

覺得內(nèi)容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產(chǎn)出更好的內(nèi)容。

歡迎關(guān)注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產(chǎn)品創(chuàng)業(yè)方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預(yù)測：Vibe coding贏者通吃？錯了，垂直專業(yè)化才是未來