a16z 最新觀點：當 AI Agent 成為軟體的主要用戶

撰文：深思圈

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

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

軟體必須為 AI Agent 而建

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

這背後的邏輯其實很簡單。當 AI agent 成為主要的軟體使用者時，它們會透過 API、CLI（命令列界面）或者 MCP（Model Context Protocol，模型上下文協議）這樣的協議來與系統交互。而目前看起來最有效的範式是什麼呢？給一個會寫程式碼的 agent 提供對 SaaS 工具的存取權限，讓它能夠存取你的知識工作流程和上下文資訊。這樣的 agent 不僅能夠讀取和理解資訊，更關鍵的是它能夠透過撰寫程式碼或使用 API 的方式來完成任務。

Anthropic 的 Claude Code、OpenAI 正在開發的超級應用，以及 Perplexity 的計算功能，都在朝著這個方向發展。我認為這種能力的複合成長才剛剛開始。想像一下，一個 agent 不僅能理解你說"幫我分析上季度銷售數據"，還能自己寫程式碼去提取資料、進行分析、生成可視化圖表，甚至主動發現你沒有注意到的趨勢。這種能力的邊界在哪裡？我現在還看不清楚。

但這裡有個關鍵問題讓我一直在思考：人們經常說要"為 agent 構建東西"、“向 agent 行銷”、“擁有好的 API 和介面描述語言”。Martin Casado 在對話中提出了一個我非常認同的反向觀點：這種說法幾乎完全錯了。為什麼？因為 agent 恰恰最擅長的就是找到正確的工具和後端系統。它們不會因為你的 API 文件寫得漂亮就選擇你，而是會基於成本參數、系統可靠性、資料持久性等實質性因素來做出選擇。Agent 擁有的是人類使用這些平台的集體智慧。

這個觀點讓我恍然大悟。作為一個產業，我們太過關注界面和介面，卻忽略了本質：我們需要構建更好的系統本身。Agent 會推動我們回歸技術本質，而不是行銷包裝。過去，企業軟體的採購決策往往受到銷售能力、品牌影響力、甚至是商務宴請的影響。但在 agent 主導的世界裡，這些因素的權重會大幅下降。Agent 會基於技術優劣做出更加理性的選擇。這對那些真正專注於技術本身的公司來說，是巨大的機遇。

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

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

這個觀察擊中了要害。想像一下，在一個有 50 個行銷人員的團隊中，負責一條龐大產品線的行銷工作，可能只有一個人真正理解並能夠文檔化整個工作流程。如果你把這些協作工具或 AI agent 放到普通員工面前，讓他們建立自動化流程，他們解釋清楚"要做什麼"的能力其實非常有限。

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

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

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

這個故事讓我意識到，我們現在處在 AI agent 發展的類似階段。你會覺得需要 50 個小型 agent，由一個超級聰明的人來協調它們。但很快，這些東西會相互折疊，最終變成一個技能集合——一段程式碼，我們稱之為 agent——它懂行銷。你可以問它行銷相關的問題，然後下一步，讓它去執行任務。

我認為關鍵的轉折點是：現在你必須是個火箭科學家級別的人才能建立 42 個 agent 並讓它們全部運轉起來。但這種"火箭科學"的門檻很快就會消失，然後一大塊領域專業知識會回歸到領域專家手中。這和電子表格的演化路徑幾乎一模一樣。

企業的恐懼：失控的整合和權限惡夢

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

這些企業 IT 負責人的擔憂不是沒有道理。他們害怕的不僅是 agent 本身，更是人類被授權做整合這件事。當你讓員工可以建立新的整合時，你基本上就是在說"請來破壞我的核心系統"。想像一下，有人在系統 27 和系統 38 之間建立了一個新的 API 連結，如果只是用來產生報告，那個人想錯就錯，是他自己的事。但如果涉及到寫入操作呢？

Aaron Levie 認為，在未來相當長的一段時間內（N 是一個很大的數字），我們會有一個只讀版本的 agent 整合。很多 AI 應用現在都是消費層面的——人類是最終的消費者。但即使在這個層面，企業也面臨著新的挑戰。

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

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

Aaron Levie 自己在測試時就遇到了這個問題。他在嘗試建立一個行銷計畫目錄結構的範例時，陷入了某種循環，不斷建立巢狀目錄。他開玩笑說：“我想知道 Box 對巢狀目錄的深度限制是多少，因為我快要觸及了。”

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

把 AI Agent 當員工對待？沒那麼簡單

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

Martin Casado 分享了一個實踐：給你的 agent 自己的電話號碼、自己的信用卡（希望是從 CVS 買的預付費 Visa 卡）、自己的 Gmail 帳戶。Gmail 實際上有很多 RBAC（基於角色的存取控制）權限機制。你可以爭論說，我們已經構建了很多這樣的權限系統，我們應該把 agent 當作一個獨立的人類來對待。

但 Aaron Levie 立即指出了這個模型的問題。在 50 人的團隊中，我們是否會有 100 個"人"在協作——50 個人類和 50 個 agent，都在同一個共享空間裡？我顯然對我的 agent 有完全的監督權，但如果我的 agent 與別人協作，不小心存取了我本不該存取的資源怎麼辦？現在這個自主的、有狀態的 agent 在處理別人的資訊。

這裡有個根本性的矛盾。對待真正的員工，你不能查看他們的 Slack 頻道，不能以他們的身份登入，不能監督他們的一舉一動。他們要為自己的執行負責，在現實世界中，你不會因為他們搞砸了什麼而受罰。但對於 agent，你要承擔它做的一切的責任。你需要有完全的監督權，它們沒有隱私權。

所以出現了一些矛盾的地方。我需要能夠給 agent 存取權限，但我也需要能夠隨時以它的身份登入，比如"不行，你把整件事搞砸了，我需要撤銷所有操作。"但如果我能以它的身份登入，它怎麼能在現實世界中與其他人合作，並保持任何資訊的機密性或安全性呢？所以，agent 實際上幾乎不可能不是你的延伸。

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

這意味著什麼呢？意味著如果我知道你的新 agent 的電子郵件地址，我可以給它發郵件，我能夠社交工程它，這比社交工程一個人類容易十倍。很難讓這個 agent 同時也能存取你的併購文件之類的敏感資訊。

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

初創公司的優勢：無所顧忌地擁抱 AI Agent

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

Aaron Levie 說，我們看到初創公司可以從零開始構建，沒有我們討論的那些風險，因為它們沒有什麼可以搞砸的。所以我們把這看作我們所處的發展軌跡。但當你去摩根大通，問他們如何設定 NanoClaw（假設的 AI agent）來自動化業務時，你會發現存在巨大的鴻溝。

這個鴻溝體現在哪裡呢？大企業有 75 個遺留系統需要整合，有嚴格的合規要求，有數十年的資料安全標準，有複雜的權限管理機制。而更關鍵的是，它們有太多東西可以輸不起。一個初創公司如果 agent 出了問題，最多是個笑話，可能還會成為《矽谷》劇中的一集。但一個大銀行的 agent 如果洩露了客戶資料，那是可能導致公司倒閉的災難。

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

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

我認為這會創造一個非常有趣的市場分化。那些敢於早期投入、願意承擔風險的中型公司，可能會獲得對大企業的競爭優勢。它們既有足夠的資源來投入 AI，又不像巨型企業那樣被遺留系統和風險厭惡所束縛。

同時，會出現一批全新類型的服務公司。想像一下，如果你從零開始建立一個行銷機構、工程諮詢公司或建築設計公司，你完全基於 AI agent 的第一性原理來構建，不存在資訊壁壘和邊界，可以給 agent 完成工作所需的所有上下文，可以隨時為特定需求撰寫軟體。這種公司在一段時間內會具有相當大的顛覆性，直到那些更大的現有企業能擺脫束縛。

Token 預算：工程管理的新戰場

對話中有一段關於 token 預算的討論讓我覺得既現實又荒語。Aaron Levie 說：“工程計算預算對話將是接下來幾年中最瘋狂的對話之一。”

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

但 Steven Sinofsky 認為，我們還不知道答案，而 CFO 總是想知道他們不知道答案的問題的答案。華爾街會強迫他們給出一個數字並對此負責，然後他們會被解雇，然後這個循環會繼續。這不是新鮮事，我們在網路帶寬、真空管、晶體管、程式員數量等每一個新技術上都經歷過同樣的事情。

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

這確實和 2000 年代初的雲端轉型類似，當時我們從 CapEx（資本支出）轉向 OpEx（營運支出），然後變成無限支出。Aaron 回憶起當年在 Box 的簡報中心，CFO 會說"你不明白，我們是農業公司，我們只懂 CapEx"或者相反"我們是 OpEx 公司，我們喜歡雲"。會計規則的差異真的會影響技術採用。

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

Aaron 說他現在的態度是應該浪費很多 token，因為那代表我們在嘗試新東西。那么工程負責人應該對團隊並行運行 10 個實驗感到高興嗎？即使這顯然會浪費 90% 的 token，但你會選擇一條成功的路徑。還是應該告訴團隊在做之前要真正設計出完美的系統？

當這段對話錄製時，人們正在為 Claude Code 的新 Max 計畫感到恐慌，因為他們在三個提示詞之後就被限制了。這將是一個非常現實的話題，直到我們能夠真正建立起資料中心容量。

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

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

SaaS 系統的未來：資料層的價值回歸

對話中有一段關於企業系統未來的討論讓我印象深刻。Martin Casado 提出，當前的 SaaS 供應商正在經歷一個有趣的問題：它們實際上並不銷售業務線資料，它們銷售的是這個智能、領域專業知識和整個系統。但 agent 方面只想購買資料，只想授權資料並擁有無限存取權，但這從來不是它們的商業模式。

這一直是與 Workday、SAP 這類系統的長期緊張點——允許多少 API 存取。Salesforce 為此經歷了三次大規模平台重新設計。這是一個技術層面特別有趣的問題：在人們想要存取資料的情況下，系統記錄（system of record）意味著什麼？

Steven Sinofsky 直言不諱：“想用類似 vibe coding 的方式做出 SAP 這樣的系統，簡直荒謬。” SAP 中的所有領域知識，不僅僅存在於某個精心編排的資料層中。它存在於 UI 中，存在於中間層，存在於你使用它的方式中。

但 Aaron Levie 有不同看法。他認為，如果你做足夠多的迭代，agent 最終會在很大程度上負責選擇它想要實現和使用的工具。雖然 agent 無法更換企業系統，但經過足夠多代的發展，agent 可能會遇到你的軟體的太多障礙，以至於它會說：“你需要最終淘汰你的遺留 HR 系統，否則我無法為你自動化這個工作流程。”

這是一個顛覆性的觀點。想像一下，當 agent 的數量是人類的一百倍或一千倍時，如果反覆出現這種情況，最終必須為 agent 構建軟體堆疊。也許會有幾個堅守陣地的系統，比如幾個 ERP 系統是最後的堅守者，但其他所有東西你的業務表現將與你的 agent 能夠多好地存取它們需要的資訊來完成工作相關聯。因此你的企業 IT 堆疊必須以支援這些 agent 有效工作的方式來設定。

Martin Casado 提出了一個我非常認同的細微差別。人們經常抽象地說"現在你在向 agent 行銷"、“你需要成為一個 API”、“你需要有好的介面描述語言”。他認為這幾乎完全錯了。Agent 真正擅長的恰恰是找到正確的後端。所以它們不會說"這個介面很好，文件很好"，它們會說"這個的成本參數、那個的持久性"。它們實際上擁有我們使用這些平台的集體智慧。

他舉了一個例子：每當他讓 agent 選擇一個雲平台時，agent 使用的是有意義的東西，而不是界面相關的東西。所以作為一個產業，我們過於關注這些界面，認為"你需要向 agent 行銷"這樣的話題，而實際上我們將被推動去構建更好的系統，那才是會被選擇的東西。

我認為這個觀點非常深刻。在 agent 時代，技術優劣會變得更加重要，而行銷和包裝的重要性會下降。那些真正具有技術競爭力的產品會脫穎而出，而那些主要靠銷售驅動的產品會面臨挑戰。

我的思考：我們低估了這場變革的規模

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

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

同樣的事情發生在雲端計算上。人們看待雲時，認為我們只是把伺服器業務（每年大約 6 萬台）搬到別人的資料中心。沒有人想到使用量會增長一千倍。

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

我認為 AI 會帶來類似甚至更大規模的市場擴張。當每個知識工作者身邊都有一個或多個 agent 在工作時，軟體的使用量、資料的處理量、計算的消耗量都會呈指數級成長。這不是一個零和遊戲，不是簡單地把現有工作從人類轉移到 agent，而是會創造出全新的可能性和價值。

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

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

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

但在短期內，我們會看到巨大的混亂和不確定性。企業會在投入多少、如何控制成本、如何管理風險之間掙扎。初創公司會大膽押注並快速行動。會有失敗，也會有成功。但長期來看，方向是明確的：軟體必須為 agent 而建，API 會比 UI 更重要，系統的品質會比行銷更重要，計算成本會持續下降而使用量會指數級上升。

我們不是在經歷一個簡單的工具升級，而是在經歷一次計算範式的根本轉變。那些理解這一點並採取行動的公司和個人，將定義未來十年的科技格局。而那些仍用舊框架思考的人，可能會發現自己被遠遠甩在後面。

這場變革才剛剛開始。