Stephen Toub 在 2026 年 1 月 6 日從三萬五千英尺高空用手機開了九個 pull request，七個被合併。他在 dotnet/runtime 工作，事後寫下的觀察很直接：AI 改變了程式碼生產的經濟學，一個人加上手機就能比整個團隊審查得更快。
這句話點出真正的問題：當單一工程師就能用 coding agent 塞爆團隊的 review 容量，重點就不再是讓代理寫程式，而是如何吸收產出。Firecrawl 的文章整理了多家公司公開的架構，歸納出一個共通的答案：AI software factory。
代理很便宜，閘門才是設計核心
Firecrawl 的 TL;DR 把 AI software factory 拆成五個階段，每個階段都有一道閘門。代理本身是最便宜的部分。
| 階段 | 決定什麼 | 公開案例 |
|---|---|---|
| Intake | 哪些工作值得開始 | Sentry 的 Seer 先對每個 issue 評分可操作性 |
| Isolation | 代理在哪裡執行、不互相碰撞 | Stripe 約 10 秒啟動預熱 devbox |
| Tools | 代理能碰什麼 | Stripe 的 Toolshed 透過 MCP 暴露約 500 個內部工具 |
| Verification | 變更是否正確 | Spotify 的 LLM judge 否決約 25% 的代理 session |
| Merge gate | 誰負責 | Faire 要求代理寫的 PR 要有兩個人類審查 |
Firecrawl 的結論很明確：每一家成功做出來的公司都是先建閘門，再放代理。Spotify 的 Fleetshift 在 2023 年就上線，比他們有代理可以放進去早了兩年。生成能力會隨著花費擴張，審查能力不會，這個不對稱就是整個設計問題。
五個階段，每道閘門擋住一種浪費
Firecrawl 把五個階段拆開來談，每個階段都有對應的公開架構。
Intake：先過濾，再派工。 天真的做法是每個 open issue 都派一個代理，但 Sentry 的 Seer 會先對每個進來的錯誤評分可操作性，只調查過門檻的。Shopify 走另一條路，把 intake 放在 Slack，規定代理只在公開頻道工作、拒絕 DM。Shopify CEO Tobi Lütke 說這是刻意的：公開的代理 session 可以被搜尋，任何人都能跳進來。
Firecrawl 也示範了一個 dedup gate 的實作。用 developer index 查詢某個依賴是否已經有人修過，關鍵在於 repos[0].indexed 這個欄位。如果寫成 if not results: spawn_agent()，就分不出「沒人回報過」和「這個 repo 沒有覆蓋」，閘門會 fail open。讀 indexed 並把 false 當成未知、轉給人類或重試，是一行程式碼的修正。
Isolation：兩個代理共用一個工作目錄是最快的浪費方式。 Firecrawl 列出三種模型，成本由低到高：git worktrees 隔離檔案和分支，適合單機 2 到 5 個代理；containers 多隔離了依賴和網路；cloud sandboxes 連並行都隔離，適合 Stripe devbox、Ramp on Modal、Spotify on Kubernetes 這種規模。
Tools：代理能碰什麼。 Stripe 的 Toolshed 透過 MCP 暴露約 500 個內部工具，Shopify 則用 credentials proxy 和 gateway 控管。
Verification：在人類介入之前先驗證。 Stripe 在 5 秒內跑完 lint 和測試，再進 capped CI；Spotify 用 deterministic checks、LLM judge 和 CI 三層。
Merge gate：人類坐在最後一道關。 Faire 要求代理寫的 PR 要有兩個人類審查，其他公司也都是人類 review。
先建 session log，其他才能拋棄
Firecrawl 特別提到 Anthropic 的 managed agents 架構，把 software factory 拆成 brain（模型和 harness，無狀態）、hands（可拋棄的 sandbox）和 session（持久的 append-only event log）。Shopify 在 Under the River 裡直接引用這個架構。
Firecrawl 的建議很實際：如果只從這篇文章建一樣東西，就建 session log，因為它讓其他所有東西都可以拋棄。
這跟我們之前談過的 OpenRouter Shell 工具如何改變代理的執行邊界 是同一條思路：代理的價值不在單次執行，而在可重播、可稽核的執行紀錄。
從哪裡開始
Firecrawl 的建議是從 git worktree 開始，成本最低。Claude Code 用 --worktree 參數就能每個 session 開一個獨立工作目錄，也可以把 isolation 釘在特定 subagent 上，讓 refactoring agent 永遠有自己的樹。
但真正的起點不是工具，而是 intake 的過濾條件。Microsoft 在 dotnet/runtime 十個月的數據顯示，1 到 50 行的代理 PR 成功率是 76 到 80%，效能相關的工作只有 54.5%。Copilot 的 coding agent「擅長實作定義清楚的變更、很會調查問題、相對不擅長設計架構」。把這個事實寫進 intake 規則，比任何 sandbox 設定都更能省下後面的浪費。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。