開源 agent orchestrator 已能平行寫碼，但還不能全自動交付

開源 agent orchestrator 已經能顯著提升平行寫碼效率，但在合併、驗收與上線決策上，仍必須保留人類控制。

開源 agent orchestrator 的價值很明確：它們已經把「多個 agent 同時寫碼」變成可用的工程流程，但離「全自動交付軟體」還差很遠。真正成熟的工具，能把任務拆到獨立 git worktree 裡並行執行，卻仍把任務對齊、衝突處理與合併判斷留給人。Augment Code 的評測已經說得很清楚，強的工具主要贏在平行執行，少數才往協調邁進，而沒有任何一款真正消除了人類在最後一關的責任。

第一個論點

這波工具最重要的突破，不是 UI，也不是 agent 數量，而是平行執行終於有了可靠的隔離層。單一 agent 在 IDE 裡慢慢改檔，早就不夠用了；一旦多個 agent 同時碰同一個 repo，就會出現檔案覆寫、port 衝突、狀態難以回復等問題。git worktree 之所以成為共同底座，就是因為它把「每個任務一個隔離空間」這件事做到了最小成本。沒有這層隔離，平行寫碼只是理論。

具體案例也證明了這點。Composio AO、Emdash、Baton、Bernstein、Claude Squad、Crystal/Nimbalyst、Vibe Kanban、Agent Kanban 與 Conductor 系列，雖然介面不同，但都在利用 worktree 讓任務同時展開。Emdash 甚至替每個任務注入獨立的 $EMDASH_PORT，直接解掉共用服務的碰撞問題。這種細節很關鍵，因為它把「可以 demo」推進到「團隊真的能用」。

第二個論點

但平行執行只是起點，真正區分玩具與工具的，是 orchestrator 在協調層做了多少事。Augment Code 的分層很有說服力：最底層只是每次修改都要批准，再上去是 milestone gate，最高才是 spec-driven verification。Claude Squad 只停在第一層；Composio AO 與 Bernstein 則開始處理 retry、CI failure 與 merge gating；Intent 更進一步，把 living spec 當成合併前的約束層。這代表 orchestrator 的價值不在「能不能叫很多 agent」，而在「能不能把風險往前攔」。

Bernstein 是最好的例子。它的流程是 Goal → Planner → Task Graph → Orchestrator → parallel Agents → Janitor → Git merge → main，測試中 Janitor 甚至在進入 merge 前抓到 type error。這不是漂亮的流程圖，而是實際降低壞碼進主幹的機率。當系統能在合併前做出這種檢查，它就不只是排程器，而是在替團隊做真正的工程控管。

反方可能怎麼說

支持者會說，這些工具已經足夠改變日常工作了。若一個團隊能同時派出三到六個 agent，並且讓 orchestrator 負責重試、建 PR、追 CI，那生產力提升非常可觀。對很多工程師來說，瓶頸本來就不是「能不能自動合併」，而是「不要等上一個 agent 做完才能開始下一個」。在這個標準下，Composio AO、Bernstein、Emdash 的確已經有實用價值。

另一個更強的反方論點是，全自動本來就不是正確目標。大多數 production team 不想讓 agent 自己決定什麼進 main，他們要的是可稽核、可回退、可控的自動化。人類保留在 loop 裡，反而比宣稱端到端自治更符合真實工作方式。

這個觀點我同意一半，但結論更進一步：正因為如此，開源 orchestrator 的定位應該是壓縮 review 前的工作，而不是假裝能取代 review。它們最有價值的地方，是降低協調成本、縮短平行開發時間、把風險前移到合併前。凡是試圖跳過人類控制的方案，最後都會在真實團隊裡碰壁；尊重 merge 邊界的工具，才值得長期採用。

你能做什麼

如果你是工程師，先按協調需求選工具：terminal-first 的單人場景可看 Claude Squad；需要桌面可視化與多 agent 任務分派，可看 Emdash；若你要 CI-aware 自動化，Composio AO 或 Bernstein 更合適；若規格一致性最重要，Intent 會更像你要的東西。若你是 PM 或創辦人，不要把這些工具當成自治引擎，而要把它們當成吞吐量放大器：定義哪些步驟可重試、哪些必須人工核准，並把 PR 合併責任固定在人身上。