「Localhost 已死」這個說法從 2025 年 Devin 爆紅之後就一直是社群裡的主流論述。邏輯很直覺: AI agent 需要隔離的執行環境、要能平行跑多個、要連接 CI/CD 和內部服務 — 這些事情靠一台筆電怎麼撐? 未來一定是雲端平台的天下。從 Ona (前 Gitpod) 執行長 Johannes Landgraf 的 The Last Year of Localhost、Cognition (Devin) 的 Nader Dabit 寫的 The Cloud Agent Thesis，到 DEV Community、Charlie Labs 等一系列文章，論調都差不多。

但進入 2026 年，風向開始變了。小編想聊聊: cloud agent 平台的論述哪裡有道理、哪裡出了問題，以及為什麼開發者用腳投票，選擇把 agent 留在自己的環境裡跑。

Cloud Agent 論述快速回顧

這波論述裡最有代表性的是 Landgraf 和 Dabit 這兩篇，先公平地整理一下他們的核心論點:

Landgraf 的觀點 — Stripe 的 Minions 每週合併上千個 agent 產出的 PR、Ramp 的背景 agent 貢獻 57% 的合併 PR、Ona 自己達到 88.5%。這些公司有什麼共同點? 不是更好的 agent 框架或更聰明的模型，而是早在 AI 時代之前就標準化了雲端開發環境。他的結論: 你的筆電跑不了五個完整的 monorepo 環境，cloud development environment 是背景 agent 的先決條件，localhost 即將終結。

Dabit 的觀點 — Cloud agent 不是「跑在別人電腦上的 local agent」，而是完全不同的品類。Local agent 是配對程式設計 (pair programming)，cloud agent 是委派 (delegation)。PM 可以在 Slack 標記 agent 修 bug、初級工程師從 Jira 觸發遷移、設計師回報問題午餐前就有 PR。不同角色、不同入口、同一個 codebase，大多數人根本不需要裝本機環境。

這兩篇的共同主張: 跑在開發者自己機器上的 coding agent 是一個局部最大值 (local maximum)，真正的槓桿在跑在雲端平台上的組織級 agent。

聽起來很有道理對吧? 但市場選了另一條路。DevConsole 甚至用了「Localhost Renaissance」(本機文藝復興) 來形容這個趨勢: 「創投倒了幾十億進去推 Cloud IDE，但真正做產品的工程師已經回到自己的機器上了。」

市場給出了不同答案

讓我們看看這三個月發生了什麼:

🔹 OpenAI Codex 的轉向 — Codex 在 2025 年 4 月以雲端 agent 身份推出，主打在 OpenAI 託管的 sandbox 裡非同步執行任務、自動開 PR。但到了 2026 年 2 月，OpenAI 重兵投入的卻是 Codex App — 一個 macOS 桌面應用，讓開發者在本機管理多個 agent，用 git worktree 做隔離。VentureBeat 在去年九月的報導中就提到一個耐人尋味的數據: IDE 擴充套件已經成為 Codex 最受歡迎的使用方式，「反映了開發者偏好直接在自己的程式碼旁邊工作」。Cloud 版本還在，但 OpenAI 顯然看到了市場訊號。

🔹 Claude Code 持續稱霸 — Anthropic 的 CLI coding agent，跑在你的終端機裡，直接操作你的本機檔案系統。它可以互動式地跟你一起寫 code，也可以用 Subagent-Driven Development (SDD) 流程在背景長時間自主執行複雜任務。重點是: 不管哪種模式，agent 都跑在你自己的環境裡。根據多份獨立調查，它已經是目前工程師滿意度最高的 AI coding 工具之一。

🔹 OpenClaw 崛起 — 開源的 AI coding assistant，核心價值觀寫在首頁: local-first，工作區和設定都在你的掌控之下。跨平台、可組合、可審計。

🔹 Cursor 加了 cloud agent，但重心還是本機 — Cursor 二月底宣布 cloud agent 功能，每個 agent 跑在獨立 VM 裡。但他們自己的數據是「30% 的 PR 來自 cloud agent」，也就是說 70% 的工作還是在本機完成。Cloud agent 是補充，不是取代。

🔹 Devin 的現實落差 — AwesomeAgents 的深度評測給了 Devin 6.5/10。在複雜任務上，Devin 只有約 15% 的成功率不需人工介入。成本不可預測 (ACU 計費讓預算很難抓)。Augment Code 的對比數據也蠻有說服力: Codex 的 PR 接受率 64%，Devin 只有 49%。評測結論: 擅長範圍明確的重複性工作 (遷移、安全修補、測試生成)，但「日常 coding 伴侶」這個角色它扛不起來。

趨勢很清楚: 開發者工具的重心正在往「自己的環境」收斂，而不是往第三方雲端平台發散。

為什麼開發者選擇自己的環境?

先釐清一個常見誤解: Dabit 把 local agent 等同於「pair programming」、cloud agent 等同於「delegation」，這是一個假二分法。跑在自己環境裡的 agent 一樣可以背景執行、長時間自主工作。Claude Code 可以用 SDD 流程派出多個 subagent 平行處理任務；Codex App 可以同時開多個 agent session，用 git worktree 隔離，甚至遠端操控。這些都不是「你盯著螢幕看 agent 一行一行寫 code」的 pair programming。Augment Code 的對比評測講得很直白: 「Devin 感覺像把工作委派給遠端外包商；Codex 感覺像跟一個你可以調整參與度的夥伴合作。」

真正的差異不是互動模式，而是誰擁有執行環境。 在自己環境裡跑的 agent (不管是筆電、公司的 server、還是自家的 cloud VM)，你有完整的控制權。Cloud agent 平台則是把工作交給別人的基礎設施。這才是根本的分界線。

小編整理了幾個核心原因:

1. 自己的環境 vs 別人的平台

這是最根本的差異。不管是互動式還是背景跑，agent 在你自己的開發環境裡運作: 你的檔案系統、你的依賴、你的設定、你的內部服務。你有完整的存取權和控制權。

Cloud agent 平台則是把工作交給一個你不控制的基礎設施。你的程式碼、環境變數、API 金鑰、資料庫連線資訊，全都要送到別人的沙盒裡。Landgraf 的文章花了很大篇幅講 Ona 怎麼用 VM 隔離、kernel 層監控、短期憑證來解決安全問題。這些都是好工程，但它們存在的前提是: 你把東西送出去了，所以需要這些防護。在自己環境裡跑的 agent 根本不需要面對這個問題。

更實際的是: 你的開發環境跟生產環境之間的距離越近，agent 產出的品質就越高。自己環境裡的 agent 天然能跑你的完整測試套件、連你的 staging 資料庫、打你的內部 API。Cloud agent 平台要達到同樣的整合度，需要大量的網路設定、VPN tunnel、secrets 管理，而且每一層都是潛在的故障點。

2. 回饋循環的可選擇性

在自己環境跑 agent，你可以自由選擇介入的深度。簡單任務? 丟出去背景跑，回來收 PR。複雜任務? 即時監控，看到 agent 走偏了三秒內糾正。同一個工具，兩種模式自由切換。

Cloud agent 平台則幾乎只有一種模式: 描述任務 → 等待 → 收結果。當 session 出問題，你看不到它在做什麼、沒辦法跳進去直接改一個指令或檔案。Devin 評測裡提到的一個痛點就是: 「當 session 出問題，你只能在聊天裡重新引導它，不能直接介入修正。」AgentRank 的 Devin 2.2 評測更不客氣: 過去用戶直接叫它「被過度炒作的初級實習生」。

這不是「要不要 pair programming」的問題，而是你有沒有選擇權的問題。自己的環境給你全光譜的介入選項，cloud agent 平台把你鎖在「委派 → 等待」這一端。

3. 「可委派工作」的比例被高估了

Dabit 在文章裡列了一長串 cloud agent 擅長的事: 重構、bug 修復、測試覆蓋、CVE 修補、依賴升級、文件維護、CI 除錯。他也承認了一句: 「如果一個初級工程師拿到明確指示就能處理的，cloud agent 就能處理。」

問題是: 你每天的工作裡，有多少比例是「給初級工程師明確指示就能搞定」的? 而且這些工作，跑在自己機器上的 agent 一樣能做，根本不需要上到別人的雲端平台。Claude Code 的 SDD 流程、Codex App 的多 agent 管理，處理這類明確任務綽綽有餘。

Cloud agent 平台的真正價值主張其實不是「能跑背景任務」(localhost 也能)，而是「讓不懂 Git 的 PM 也能在 Slack 派任務」。這個需求是真實的，但它的市場比「讓工程師更有生產力」小太多了。

4. 成本可控，模型選擇更自由

Claude Code 和 Codex 都是按 API token 計費，用多少付多少，花費透明可控。Devin 的 ACU (Agent Compute Unit) 計費模式讓很多用戶抱怨「跑完一個任務才知道花了多少錢」。對個人開發者和小團隊來說，這是一個很現實的考量。

更關鍵的是模型選擇權。在自己環境跑 agent，你可以自由切換背後的模型: 用 Claude 跑複雜架構設計、用 GPT 處理日常任務、甚至用 Ollama 跑開源模型 (Qwen Coder、DeepSeek 等) 來壓低成本或保護隱私。Cloud agent 平台則把你鎖定在它選的模型上 — Devin 用自己的模型組合，你沒得選。隨著開源模型的 coding 能力快速追上來，這個靈活度差距只會越來越大。

5. 開發環境不需要「標準化到雲端」就能跑 agent

Landgraf 的核心論點是: 你需要先把開發環境搬上雲端、標準化，agent 才能大規模跑。Stripe 和 Ramp 之所以成功，是因為它們花了好幾年做雲端 devbox。

但 2026 年的現實是: 本機環境標準化的工具已經成熟了。Dev Container 規範、Nix、docker compose、甚至簡單的 Makefile + shell script，都能讓「新人 clone 下來十分鐘跑起來」這件事在本機實現。你不需要把環境搬到別人的雲端才能標準化。

Git worktree 讓你在本機隔離多個 agent 的工作區。是的，Landgraf 說 monorepo 裡開五個 worktree 筆電會爆掉 — 但多數團隊不是 Stripe 等級的 monorepo，而且如果真的需要更多算力，你可以開自己的 VM 或用自己公司的 cloud 資源，不需要把整個開發環境託管給第三方平台。

Anthropic 自己也是這個立場

值得注意的是: 連製造 Claude 的 Anthropic，產品策略也是站在「自己的環境」這邊。Latent Space 最近專訪了 Anthropic 的 Felix，主題就叫 Why Anthropic Thinks AI Should Have Its Own Computer。Felix 一句話總結他的看法:

「Silicon Valley overall is undervaluing the local computer.」 (整個矽谷低估了本機電腦)

他用了一個很傳神的比喻: 「如果你雇了一個開發者，但告訴他『你不需要電腦，我們會寄 email 給你裝著程式碼，你也寄 email 回來』，這顯然不會很有效率。」AI agent 也一樣。

Anthropic 的具體做法是 Claude Cowork — 用輕量 VM (macOS 上用 Apple Virtualization Framework、Windows 上用 Host Compute System) 在你的機器上開一個隔離環境給 agent 用。Felix 列舉的優勢跟我前面講的幾乎一模一樣:

  • 資料親近性: 不用把整個工作環境複製到雲端
  • 認證穩定: 不用把帳號 cookie 搬上雲端 (異地登入觸發風控)
  • 權限簡化: 用作業系統現有的權限就好，不用為每個雲端服務搞 API token
  • 工具自由: agent 自己 pip install、npm install，不用預先配置

Felix 點出一個關鍵: 真正要做到 agent 能「委派並走開」，需要的不是雲端平台，而是給 agent 一個它自己的電腦 — 一個有完整工具鏈、可以安裝依賴、可以網路存取、但跟主機隔離的環境。這個環境不必、也不應該在第三方雲端，它就在你的機器上。

當製造 Claude 的公司自己都這樣想，「localhost 即將終結」這個論述就更站不住腳了。

Cloud Agent 不是沒用，是定位錯了

小編不是說 cloud agent 毫無價值。Stripe 和 Ramp 的數據是真實的，那些 agent 確實每週合併上千個 PR。但注意: 這些都是大型企業，有標準化的開發環境 (Landgraf 自己也強調了這一點)、有明確定義的重複性任務、有專門的平台團隊來維護整套基礎設施。

Cloud agent 的甜蜜點是: 組織級的、範圍明確的批次自動化。大規模遷移、安全修補、合規檢查、測試補充。這些工作確實適合「描述任務 → agent 非同步執行 → 收到 PR」的模式。

但 cloud agent 陣營犯的錯誤是把這個甜蜜點泛化成整個軟體開發的未來。「localhost 即將終結」這個宣言太過了。對絕大多數開發者來說，不管是互動式開發還是背景自動化，agent 跑在自己掌控的環境裡就是比較好 — 更靈活、更安全、更便宜、整合度更高。

有意思的是，連 cloud agent 的倡導者自己都在用行動承認這一點。Cursor 的數據顯示 70% 的工作還是在本機，他們並沒有把 cloud agent 當作唯一路徑。OpenAI 最重要的新投資是桌面端的 Codex App，不是雲端的 Codex sandbox。

真正的分界線不是 local vs cloud

小編覺得這場辯論最容易搞混的地方是把「local vs cloud」跟「互動 vs 非同步」混為一談。Dabit 的文章就犯了這個錯: 他把 local agent 釘死在「pair programming」上，把非同步執行當成 cloud agent 平台的專利。

但現實是: 在自己環境跑的 agent 早就能非同步了。Claude Code 的 SDD 流程可以派出多個 subagent 平行處理複雜任務；Codex App 讓你同時管理多個背景 agent session；你甚至可以在自家的雲端 VM 上跑 Claude Code，讓它整夜工作。這些都是「非同步」和「背景執行」，但環境是你自己的。

真正的分界線是誰擁有執行環境:

  • 自己的環境 (不管是筆電、辦公室的 server、還是自家公司的 cloud VM) → 你擁有完整控制權，可以互動也可以背景跑，安全邊界你自己管
  • 第三方平台 (Devin、Ona 等) → 你的程式碼和 secrets 送到別人的基礎設施，介入能力受限，多一層平台依賴

開發者選了前者，不是因為守舊，也不是因為只想 pair programming。而是因為自己的環境天然就有更好的整合度、更靈活的介入選項、更簡單的安全模型，而且現有工具已經能在這個基礎上做到非同步和平行化了。

Cloud agent 平台要說服開發者，需要回答的不是「模型夠不夠聰明」的問題，而是「你為什麼要把開發環境交給我們」的問題。目前看來，除了 Stripe 等級有專門平台團隊的大企業有動力這樣做之外，多數團隊的答案是: 不需要。

延伸閱讀

Cloud Agent 論述:

反面觀點:

產品動態: