摘要： 文章以多家公司案例說明 AI software factory 的重點不是代理本身，而是 intake、isolation、tools、verification 與 merge gate 五道閘門。例如 Spotify 的 LLM judge 約否決 25% 代理 session，Faire 要求代理寫的 PR 由兩名人類審查，藉此控制生成速度超過審查容量造成的風險。
2026 年 1 月 6 日，Stephen Toub 在三萬五千英尺的高空用一支手機送出九個 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 讓 lint 與測試在 5 秒內結束，之後才進 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 設定所能帶來的效果。