Stripe 用幾百個 Agent 跑完整個開發流程後放棄 localhost，通宵親身試驗後我明白了

昨晚個 Hackathon 得一條規則：晚上 8 點設定好 Spec 同 Harness，早上 8 點前唔好再碰鍵盤。12 小時內完全靠 Agent 完成一個產品。

就係呢個實驗，讓我在 12 小時內親身體會到 Stripe 喺發布 Minions 平台、Ramp 喺分享自家 Background Agent Inspect 心得時，都異口同聲講「localhost 已經唔夠用」的原因。

係你部機跑多個 Agent，狀態一定搞到亂晒

多個 Agent 喺同一部機上同時跑，狀態一定會撞車。Secret 衝突、Port 撞埋，仲有部機一入睡眠，12 小時嘅 Loop 就即刻全廢。

Stripe 同 Ramp 公開佢哋嘅 Agent 架構時，有個共同點：兩者都係為每個 Agent 分配獨立 VM 同開發容器。

Stripe 嘅 Minions 喺佢哋稱為「devbox」嘅隔離環境入面執行。係同工程師日常用嘅相同機器規格，但係同生產資源同互聯網完全隔離。10 秒內就可以 Spin Up，毋須 git worktree 嘅額外開銷，可以並行執行多個 Task。

Ramp 嘅 Inspect 係建喺 Modal Sandbox 之上。每個 Session 都有獨立嘅全棧開發環境，包括 Postgres、Redis、Temporal 同 RabbitMQ。Session 之間完全唔爭資源，加上 Filesystem Snapshot，啟動時間近乎即時。

Coding Agent 需要你部機同你嘅專注力，Background Agent 兩樣都唔需要。我喺通宵跑嘅時候親眼見到，部機入咗睡眠模式，整個 Loop 就停晒。喺雲端 VM 就唔會有呢個問題。

順序派 Task 畀 Agent，出嚟嘅只會係簡單功能

今次 Hackathon 最慘痛嘅體會係呢個。順序執行嘅話，簡單 CRUD 係做到，但係一旦出現依賴關係，問題就嚟㗎喇。後面跑緊嘅 Agent 覆寫或者衝撞咗前面已經完成嘅模組，呢個情況一再出現。

呢度要分清楚 Agent Fleet 同 Agent Swarm 嘅分別。

Agent Fleet 係將同一個改動同時應用到多個 Repository 嘅模式。Stripe 能夠每週 Merge 超過 1,000 個 PR，正係靠呢個架構。同一個 Migration、同一個 Lint 修正，一次過推到幾百個服務入面。

Agent Swarm 係將不同部分交畀唔同 Agent 負責，最後收斂成同一個結果嘅模式。前端、後端、測試分別由不同 Agent 負責，再以 PR 為單位合併。

唔係並行執行後再以 PR 為單位合併，就唔可能做出複雜嘅產品。親身試過之後，並行加 Merge Review 嘅組合同順序執行相比，完成品質差距相當明顯。

Rate Limit 同 Agent 之間嘅溝通，要靠基礎設施解決，唔係靠 Prompt

喺 12 小時嘅 Loop 入面，唔中 Rate Limit 係唔可能嘅。加埋要由另一個 Agent 去 Review 某個 Agent 提交嘅 Commit，仲要自動重新判斷 Spec 入面模糊嘅部分，整個流程更加複雜。

有句話講得好：「喺 System Prompt 寫『唔好刪檔案』係請求，唔係控制。」講嘅就係呢個問題。

Stripe 喺執行層解決咗呢個問題。Minions 原生封鎖咗對生產資源同互聯網嘅存取，所以唔使做權限檢查都可以安全執行。400 個以上嘅 MCP 工具全部托管喺內部叫做「Toolshed」嘅伺服器上，為每個 Agent 精選佢可以用嘅工具集合。

Ramp 則透過 GitHub OAuth 確保 PR 必須由真實用戶帳號建立，唔係 App ID，係歸屬於個人帳號。咁樣從架構上防止咗代碼喺未經 Review 嘅情況下就 Merge。

喺執行層鎖定權限範圍、留下 Audit Log、限制失敗影響範圍——缺少呢啲，安全團隊唔會批准自主 Agent 嘅部署。

個人快咗，組織唔一定跟得上

有個現象可以叫做「假山頂（false summit）」：引入 Coding Agent 之後，PR 大量湧現，但 Cycle Time 一動不動。Review 積壓、CI 失敗、Merge 衝突越堆越多。

Hackathon 入面，Agent 快速生成代碼根本唔係問題所在。時間全部消耗喺合併同驗證結果呢個樽頸位。

Stripe 用自動化解決咗呢個樽頸。Minions 採用混合式 Orchestration，將 Agent Loop 同確定性代碼操作交錯執行。保證 Lint、測試、git 操作必定完成，同時保留 Agent 嘅靈活性。CI 測試最多執行兩次，防止陷入無限 Loop。

Ramp 以成功 Merge 嘅 PR 數量作為核心成功指標。Inspect 所建立嘅 PR 當中，超過 50% 真正被 Merge，而 Inspect 本身超過 80% 嘅代碼亦係由 Inspect 撰寫。

Background Agent 要比人更早處理 PR Review、CI 失敗分析同 Merge 衝突解決，組織嘅速度先至跟得上。本質係由「in the loop（親身操作）」轉換到「on the loop（只審視結果）」。

勝負關鍵唔係砌嘅速度，而係合併嘅架構

讓 Agent 快速生成代碼已經係解決咗嘅問題。Stripe 每週超過 1,000 個 PR、Ramp 超過一半 PR，全部都係 Agent 生成嘅。

真正嘅勝負關鍵，係設計一套能夠安全合併 Agent 成果嘅系統：隔離執行環境、並行後合併嘅架構、基礎設施層面嘅治理，以及驗證自動化。四樣缺一，Agent 充其量只係一件跑得快嘅玩具。