Stripe 跑了幾百個 Agent 之後放棄 localhost 的原因，徹夜親測後完全理解了

昨晚的黑客松有一條規則：晚上八點設定好規格與測試框架之後，早上八點之前不碰鍵盤。整整 12 小時，全部交給 Agent。

就是這個實驗，讓我完全理解了 Stripe 為什麼在發布 Minions 平台時，以及 Ramp 在分享自行打造的背景 Agent——Inspect時，都異口同聲地說「localhost 的時代結束了」。

在筆電上同時跑多個 Agent，衝突就此開始

多個 Agent 在同一台機器上運作，狀態很快就會亂掉。密鑰衝突、連接埠重疊，而且只要機器進入睡眠，整個 12 小時的執行迴圈就全毀了。

Stripe 和 Ramp 在公開各自的 Agent 架構時，有一個共同點：兩者都選擇了為每個 Agent 分配獨立 VM 和開發容器的架構。

Stripe 的 Minions 在稱為「devbox」的隔離環境中執行。機器規格與工程師日常使用的完全一致，但與生產資源和網際網路完全隔離。啟動只需 10 秒，並且不需要 git worktree 的額外開銷就能支援並行任務執行。

Ramp 的 Inspect 建構在 Modal Sandbox 之上。每個 Session 都擁有獨立的完整開發環境，包含 Postgres、Redis、Temporal 和 RabbitMQ。Session 之間完全不會互搶資源，加上檔案系統快照技術，啟動幾乎是即時的。

Coding Agent 需要佔用我的筆電和注意力，但背景 Agent 兩樣都不需要。親身實驗時，就親眼看到機器睡眠一次，整個執行迴圈就跟著停擺。在雲端 VM 上，這種事根本不會發生。

按順序派任務給 Agent，只能做出簡單功能

這是這次黑客松最痛的一課。循序執行的 Agent 能產出基本的 CRUD，問題在於一旦出現相依性，麻煩就來了。後面執行的 Agent 反覆覆蓋或破壞前面已完成的模組。

這裡有必要區分「Agent Fleet」和「Agent Swarm」的概念。

Agent Fleet 是把同一個變更同時套用到多個 Repo 的模式。Stripe 能夠每週合併超過 1,000 個 PR，靠的就是這個架構——把相同的 migration、相同的 lint 修正，一次推送到幾百個服務。

Agent Swarm 是把不同部分分配給不同 Agent，最終收斂成一個完整結果的模式。前端、後端、測試各由不同 Agent 負責，再以 PR 為單位合併。

不採用並行執行後以 PR 合併的架構，就無法打造複雜的產品。實際跑過一遍之後，並行加上 merge review 的組合，完成度明顯優於循序執行。

Rate limit 和 Agent 間溝通，要靠基礎設施解決，不是靠 Prompt

在 12 小時的執行過程中，避開 rate limit 幾乎是不可能的任務。更複雜的是，還需要讓 Agent 能夠 review 彼此提交的 commit，並自動重新判斷規格中模糊的地方。

有句話說得很準：「在系統提示詞裡寫『不要刪檔案』是懇求，不是控制。」

Stripe 在執行層解決了這個問題。Minions 從架構上就封鎖了對生產資源和網際網路的存取，因此不需要額外的權限檢查也能安全執行。400 多個 MCP 工具都集中放在名為「Toolshed」的內部伺服器上，並為每個 Agent 精心策劃可用的工具集合。

Ramp 則透過 GitHub OAuth 確保 PR 一定以真實使用者帳號建立，歸屬於個人帳號而非 App ID，從架構上就防止了程式碼在未經 review 的情況下直接合併。

在執行層鎖定權限範圍、留下稽核紀錄、限制故障影響範圍——少了這些，資安團隊不可能核准自律 Agent 上線。

個人變快了，組織不見得跟著變快

有一種現象可以稱之為「假山頂（false summit）」：引入 Coding Agent 後，PR 大量湧現，但交付週期卻紋絲不動。Review 堆積、CI 紅燈、merge 衝突越來越多。

黑客松裡也一樣，Agent 快速產出程式碼不是問題，問題在於合併與驗證這些產出的瓶頸，把所有時間都吃掉了。

Stripe 用自動化消除了這個瓶頸。Minions 採用混合式 Orchestration，將 Agent 執行迴圈與確定性程式碼操作交錯進行。在保留 Agent 創造力的同時，確保 lint、測試、git 操作都能可靠完成。CI 測試也限制最多重試兩次，避免陷入無止盡的迴圈。

Ramp 以「已合併的 PR 數量」作為核心成功指標。Inspect 建立的 PR 超過 50% 實際被合併，而 Inspect 本身有超過 80% 的程式碼是由 Inspect 自己寫的。

要讓組織速度跟上，背景 Agent 必須在人之前搞定 PR review、CI 失敗分析和 merge 衝突解決。本質上是從「in the loop（親手操作）」轉換為「on the loop（只看結果）」。

決勝點不在於產出速度，而在於合併架構

讓 Agent 快速產出已經是解決了的問題。Stripe 每週有超過 1,000 個 PR 由 Agent 產出，Ramp 超過一半的 PR 也是 Agent 完成的。

真正的決勝點，在於設計一套能夠安全合併 Agent 產出結果的系統：隔離的執行環境、並行後合併的架構、基礎設施層級的治理，以及自動化驗證。這四樣缺一不可，否則 Agent 終究只是跑得快的玩具。