大家都會用 Coding Agent 寫 code，但幾乎沒人在講怎麼讓 Coding Agent Scale Up。 對我們團隊來說，關鍵不是換一個更強的模型，說白了就兩件事： 一套 Agent 真的會遵守的軟體品質管理流程， 以及 每個 Agent 一台獨立的 Linux box。
一個 Coding Agent 跑在你的筆電上，沒問題。麻煩是從第二個 Agent 開始的。
兩個 Agent 在同一台機器上，就是共用同一份檔案系統、同一個套件管理器、同一組 port、
同一套語言 toolchain、同一個瀏覽器 profile。一個 Agent 跑
npm install，
另一個 Agent 編譯的依賴就被換掉了；一個佔走 port 3000，另一個的 dev server 就起不來；
一個 Agent 跑 E2E 開瀏覽器，直接把你正在用的桌面搶走。
這些狀況都不會炸得很漂亮，而是間歇性地壞——這更麻煩，
因為你整個下午都在判斷「這 bug 到底是 code 的問題，還是環境的問題」。
而且這些 Agent 全都跑在那台放著你 SSH key 的筆電上。
你可以用 per-task container、tmux 紀律、加上很多小心來勉強撐住。 但撐不住的是：這些 Agent 終究還是在搶同一台機器的狀態。
所以我們乾脆不共用了。每個 Agent 拿到自己的一台 Linux box——真的 root、真的檔案系統、真的網路—— 要裝什麼就裝進自己那台。box 在多次執行之間是持續存在的，所以 toolchain 跟 cache 明天還在。
| Agent | box 裡裝什麼 | 為什麼不能共用 |
|---|---|---|
| Engineer | CLI toolchain、編譯器、語言 runtime | 裝套件會直接改掉其他人編譯時依賴的東西 |
| QA | 瀏覽器、E2E 測試框架、測試資料 | 要模擬各種環境，而且得能整個砍掉重來 |
| Reviewer | 乾淨的 checkout，沒有 build 產物 | 工作目錄髒掉，就無法回答「這份 code 從零真的 build 得起來嗎」 |
| DevOps | 部署憑證、基礎設施工具 | 爆炸半徑——這台最不該讓人在裡面做實驗 |
| PM | issue 系統、文件，不碰 code | 規劃這件事，根本就不該碰得到工作目錄 |
於是規則就很簡單：誰都不會污染誰的環境，也不會炸到你的筆電。 Engineer Agent 把自己 box 的套件管理器搞爛，對 QA Agent 完全沒影響。 真的遇到一台 box 進入沒人解釋得了的狀態，就砍掉重開一台—— 這跟你花一個下午 bisect 自己的機器，是完全不同的下午。
光有隔離，你只是得到五個 Agent 平行地製造混亂。另一半是： 每個角色的職責都寫成一份 Agent 會載入的 skill——它能碰什麼、必須產出什麼、 以及對這個角色來說「做完了」是什麼意思。
我們的是串成一條鏈：PM skill 把工作拆成 issue，Engineer skill 在自己的 box 裡 test-first 實作一張 issue， Reviewer skill 拿 diff 對照 issue 的驗收條件，QA skill 端到端跑過一輪，最後 deploy skill 出貨。 每一關都有 exit criteria，所以 Agent 不能靠「宣稱自己做完了」把工作往前推。
這就是讓 PM 跟 Engineer 完全不互相踩線的關鍵。他們不是在同一個工作區裡協調然後祈禱， 而是互相交付產出物——一張 issue、一個 PR、一份測試報告——中間有明確的邊界。 而 box 讓這個邊界是物理上的，不只是說說而已。
這套 runtime 是我們自己做的，也開源了，所以細節是我們的做法—— 但重點是這個「形狀」，你用別的工具也能兜出來。
它不會讓 Agent 變得更會做事。 隔離拿掉的是一整類環境造成的失敗，但對一個爛計畫毫無幫助—— 而五個 Agent 平行執行一個爛計畫，只會產生五倍的善後。
瓶頸會變成 review，而且會落到你身上。 平行的 Agent 產出的 diff，多到一個人沒辦法認真讀完。 這才是這套架構真正會撞到的限制，而我們認為目前還沒有漂亮的解法。
commit 數是很糟的代理指標，而且會誤導你。 再講一次開頭的但書，因為大家最容易抓著這個數字不放： 平行 Agent 送的小 commit 會在結構上把它灌大。要看的是真正出貨、被 review 過、而且能動的改動。