Multi-Agent Coding 是什麼？同時開很多個 Agent，真的會比較快嗎？（2026 完整解析）

同時開五個 coding agent，以為進度會快五倍，結果卡在合併和 review？這篇帶你算清楚哪些工作值得平行、哪些開再多 Agent 也不會變快！

同時開好幾個 coding agent，到 2026 年已經是按一下的事。Cursor 2.0 在 2025 年 10 月讓多個 agent 各自在 git worktree 裡平行工作；Google 一個月後推出的 Antigravity，有一整個介面專門派工給多個 agent、看它們跑；OpenAI 2026 年 2 月的 Codex app 內建 worktree；Claude Code 則有 agent teams，由一個主 session 把任務分給幾個隊友，官方文件到現在仍標為實驗功能，要自己打開。

功能到位之後，很自然會算一筆乘法：一個 Agent 要做八小時的事，開四個，兩小時做完。

這筆帳漏了三段。開工前要有人把規格定下來，做完要有人把四個分支合起來，最後還要有人看過所有改動。這三段一次只能做一件，Agent 再多也不會變短，整合還會跟著分支數變長。

圖裡的時數是示意，下面會給一段程式，讓你換成自己量到的數字。先講結論：平行能省多少時間，由串行的那幾段決定。想更快，要先縮短它們，再談開幾個 Agent。

快速回答 多開 Agent 只縮短實作那一段；定規格、整合、review 是串行的，一次只能做一件，整合還會跟著分支數變長。用 Amdahl 定律（只能依序做的部分決定加速上限）代入一組示意時數，開 4 個左右最划算，再多總時間反而回升。要讓平行划算，先縮短串行那段：欄位、型別、錯誤格式這些介面約定先寫清楚，驗收交給測試。Worktree（每個 Agent 各用一個資料夾）分得開檔案，介面約定才分得開任務。

任務切得開且能各自驗收，多 Agent 平行才划算

做多 agent 系統的團隊，自己給過兩種提醒。

Anthropic 在 2025 年 6 月公開他們的多 agent 研究系統：一個主 agent 把問題拆給幾個子 agent 同時查資料，在內部評測比單一 agent 好 90.2%。代價寫在同一篇裡：一般 agent 用的 token 大約是聊天的 4 倍，多 agent 系統大約 15 倍。他們也直接說，需要所有 agent 共用同一份 context、彼此依賴很多的工作，目前不適合多 agent；而大部分 coding 任務，真正能平行的部分比研究少。

同一個月，做 Devin 的 Cognition 發了一篇〈Don't Build Multi-Agents〉。他們設想了一個例子：做一個 Flappy Bird 小遊戲，拆給兩個子 agent，一個做背景、一個做鳥。可能的結果是背景做成了超級瑪利歐的風格，鳥既不像遊戲素材，動起來也不像 Flappy Bird。兩邊都照自己的理解完成了任務，合起來卻是兩個遊戲。

這兩篇常被拿來當成正反兩方，我讀起來是同一件事的兩面：平行有用，前提是任務切得開，切開後每一份又能各自驗收。缺了任何一個，省下的時間會在合併時加倍還回去。

Amdahl 定律算總帳：定規格、整合與審查決定加速上限

1967 年，IBM 的電腦架構師 Gene Amdahl 提出一個簡單的論點：一個程式裡有一部分只能依序執行，這部分佔多少比例，就決定了加再多處理器的加速上限。後來大家叫它 Amdahl 定律。

把處理器換成 Agent，道理一樣。一件開發工作裡，實作可以切開分給多個 Agent；但定規格要有人想清楚要什麼，整合要有人把分支合起來、解衝突、重跑測試，review 要有人看過所有改動。這三段是串行的。而且整合比 Amdahl 的模型更糟：每多一個分支，就多合一次。

下面這段 Python 把這筆帳寫出來。四個數字換成你上一次任務實際花的時間：

# Hours from your last task. Replace with your own numbers.
spec = 1.0       # 定規格：一個人想清楚要做什麼
build = 8.0      # 實作：一個 Agent 從頭做到尾要多久
merge = 0.5      # 整合：每多一個分支，合併、解衝突、重跑測試要多久
review = 2.0     # Review：人看完全部改動要多久

for n in (1, 2, 4, 8, 16):
    total = spec + build / n + merge * n + review
    print(f"{n:>2} 個 Agent：{total:5.1f} 小時，快 {(spec + build + merge + review) / total:.1f} 倍")

print(f"Agent 無限多、整合不花時間，最多也只快 {(spec + build + merge + review) / (spec + review):.1f} 倍")

用示意的數字跑出來是這樣：

 1 個 Agent： 11.5 小時，快 1.0 倍
 2 個 Agent：  8.0 小時，快 1.4 倍
 4 個 Agent：  7.0 小時，快 1.6 倍
 8 個 Agent：  8.0 小時，快 1.4 倍
16 個 Agent： 11.5 小時，快 1.0 倍
Agent 無限多、整合不花時間，最多也只快 3.8 倍

三件事值得看。第一，最划算的是 4 個左右，再多總時間反而回升。第二，就算整合完全不花時間，上限也只有 3.8 倍，因為定規格和 review 那 3 小時誰也幫不了你。第三，數字裡最敏感的是 merge：把它從 0.5 降到 0.1，最划算的 Agent 數會往上跑，這就是為什麼「任務切得乾淨」比「開得多」重要。

Review 那段在真實團隊裡已經開始塞車。軟體工程分析公司 Faros AI 在 2025 年分析一萬多名開發者的工作紀錄，AI 用得多的團隊，合併的 PR 多了 98%，PR 審查時間也多了 91%。日本 @IT 2026 年報導的一份調查裡，322 名負責 code review 的工程師有 86.3% 說審查負擔變重了。Agent 開得越多，排在你桌上等看的分支就越多。

16 個 Agent 寫出 C 編譯器：用測試與 GCC 取代人工審查

看到這裡，可能會覺得多 agent 平行開發只是噱頭。Anthropic 研究員 Nicholas Carlini 在 2026 年 2 月公開的實驗，結果正好相反。

他用 Claude Code 的 agent teams 讓 16 個 Claude 同時寫一個 C 編譯器，用 Rust 從零開始。兩週內跑了將近 2,000 個 Claude Code session，花了不到 2 萬美元，做出一個 10 萬行、能在 x86、ARM、RISC-V 上編譯 Linux 6.9 核心的編譯器。

這個實驗能平行，條件寫得很清楚，剛好對到前面那筆帳的三段串行：

• 任務本來就切得開。每一個沒通過的測試，大多是一個獨立的 bug。Agent 在一個資料夾裡寫一個小檔案，標記「這個我在做」；兩個 Agent 搶到同一個時，Git 同步會讓後到的那個換一個做。不用有人坐在中間派工。
• 驗收不用等人。每份修正有大量測試可以跑，還有 GCC 這個現成的編譯器可以對答案：同一段程式，GCC 編出來的結果就是標準答案。Carlini 寫道，驗證任務的機制必須近乎完美，否則 Claude 會去解錯的問題。
• 整合交給 Agent 自己。合併衝突很常見，他說 Claude 自己處理得來；後期新功能常弄壞舊功能，他再加一道 CI，擋下會弄壞既有程式的 commit。

換成 Amdahl 的語言：串行那幾段，被換成了機器做得到的事。規格本來就有，C 語言標準和現成的測試套件寫好了；review 由 GCC 對答案代替，整合由 Git 和 CI 代替。串行的比例幾乎歸零，16 個 Agent 才有意義。

但它也失效過一次，而且失效的方式很有教育意義。

開始編 Linux kernel 之後，面對的是一整個彼此牽連的大專案，沒辦法拆成幾千個獨立的小測試。結果每個 Agent 都撞上同一個 bug，各自修好，再互相蓋掉對方的修正。16 個 Agent 退化成 16 個人擠在同一行程式前面。

修法還是靠 GCC：讓 GCC 編大部分的 kernel 檔案，只隨機挑一部分交給新編譯器。哪個組合出錯，就知道 bug 在那幾個檔案裡，每個 Agent 分到的錯誤也就不同。他沒有加 Agent，他把問題重新切開。

這個案例也有沒說完的部分。編譯器沒有自己的組譯器和連結器，產出的程式碼比 GCC 關掉所有最佳化還慢，開機需要的 16 位元 x86 那段也還是叫 GCC 處理。Carlini 自己在文末寫，他對這件事感到不安：測試都過了，很容易以為工作做完了，但這很少是真的；程式設計師部署自己從沒親自驗證過的軟體，是一個真正的隱憂。串行的 review 沒有消失，它被延後了。

Worktree 只分得開檔案，事先寫好介面契約才分得開任務

C 編譯器有現成的標準答案。大多數產品開發沒有。

Cognition 那篇文章裡最值得記的一句是：每個動作都帶著隱含的決定，決定互相衝突，結果就會出錯。放到一般專案裡，長這樣：

A 改訂單資料表，B 寫對應的 API，C 補測試。看起來是三份檔案、三個分支，可以同時開工。但訂單的狀態欄位叫什麼、能不能是空值、舊資料怎麼補，A 還沒決定。B 只能猜輸入輸出，C 只能替猜測寫測試。每個分支的測試都是綠的，合起來之後，B 假設舊資料沒有這個欄位，A 卻替舊資料補了預設值。這個衝突不會出現在 Git 的合併畫面上，要等舊資料經過新 API 才會爆。

Cognition 在原文用一張圖畫出這種拆法，標題直接寫「幾乎一定不可靠」：兩個子 Agent 中間沒有任何連線，各自的決定要到最後合併才第一次碰頭。

Worktree 解決的是另一件事：讓每個 Agent 在自己的資料夾裡改檔案，不會互相覆寫。它不會替你決定 pending 是不是預設狀態。要讓三條線真的能各自往前，得先把它們之間的介面講好：欄位叫什麼、型別是什麼、能不能是空值、出錯時回什麼。工程上把這種事先講好、雙方都照著做的約定叫做契約（contract）。

Worktree 分得開檔案，契約才分得開任務。

Claude Code 的 agent teams 文件也是同樣的建議：依序進行的工作、改同一個檔案、彼此依賴很多的工作，用單一 session 比較有效；兩個隊友改同一個檔案會互相覆蓋，要把工作切成每人負責不同的檔案。

開工前先問五個問題，決定用單一 Session 還是多 Agent

要不要把一件工作拆給多個 Agent，開工前問五個問題。任何一題答不出「是」，先處理那一題，或乾脆用一個 Agent 做：

工具的選法，跟著這張表走。只要幾份互不相干的調查或小修，Claude Code 的 subagent 或 --worktree、Codex app 的 worktree 就夠了：各做各的，結果交回來給你看。真的需要 Agent 之間互相討論、分工的，才考慮 agent teams 這類功能。Anthropic 的文件建議大多數情況先開 3 到 5 個隊友，手上有 15 件獨立任務時，3 個是好的起點；每個隊友都是獨立的 Claude，token 用量跟著人數線性增加，超過某個數量之後，多開的隊友不會讓工作等比例變快。

如果任務還在探索期，規格每天都在改，先用一個 Agent 走一段：查清楚資料怎麼流、列出改法和風險，讓人把介面定下來，再分派實作。太早切開，每條線會帶著不同的假設往前跑。

最後，下一次真的平行開工時，記下四個時間：定規格花多久、每條線實作多久、整合花多久、你看完所有改動花多久。把數字丟回上面那段程式，你就知道自己的團隊開幾個最划算。我的判斷是，大多數團隊算完會發現，該花力氣的地方是 merge 和 review 這兩個數字，Agent 的數量反而是最後才需要調的。

多 Agent 常見三大誤解：開越多越快、有 Worktree 就不衝突

開越多 Agent 越快。只有實作那段會變短。串行的部分決定上限，整合會跟著分支數變長，過了某個數量，總時間反而變長。

有 worktree 就不會衝突。Worktree 擋的是檔案互相覆寫。兩個分支對同一個欄位的意思理解不同，各自的測試都會過，衝突要到合併後、真實資料經過時才出現。

Agent 之間能互傳訊息，就不用先定規格。Agent teams 的隊友確實能互相溝通，但 Anthropic 自己的建議是：彼此依賴多的工作，用單一 session 比較有效。傳訊息能減少誤會，取代不了一份大家照著做的介面約定。

總結：能平行的交給 Agent 縮，串行的規格與測試靠自己縮

要讓平行開發划算，先處理的是那三段串行。規格寫清楚，Agent 才不用各自猜；驗收寫成測試，review 才不會全部堆到你桌上；問題先切開，大家才不會擠在同一個 bug 前面。16 個 Agent 能各做各的，靠的是一套幾乎完美的測試和一個現成的標準答案。

能平行的那段，交給 Agent 縮；串行的那段，只能靠你自己縮。

驗收怎麼寫，才能接手 review 那段工作，可以接著讀〈AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）〉。

常見問題

同時開幾個 coding agent 最划算？

看串行那幾段多長。代入一組示意時數（定規格 1 小時、實作 8 小時、每個分支整合 0.5 小時、review 2 小時），4 個左右最划算，再多總時間反而回升。Anthropic 的 agent teams 文件建議大多數情況先開 3 到 5 個隊友。最準的是記下自己上一次任務的這四個時間，代進去算。

有 git worktree 就不會衝突了嗎？

Worktree 讓每個 Agent 在自己的資料夾改檔案，擋的是檔案互相覆寫。兩個分支對同一個欄位理解不同，例如舊資料有沒有預設值，各自的測試可能都會過，衝突要到合併後、真實資料經過時才出現。要把任務分開，先講好介面：欄位叫什麼、型別、能不能是空值、出錯時回什麼。

Claude Code 的 agent teams 適合什麼工作？

Agent teams 由一個主 session 把任務分給幾個隊友，官方仍標為實驗功能。文件建議：依序進行、改同一個檔案、彼此依賴很多的工作，用單一 session 比較有效。幾份互不相干的調查或小修，subagent 或 --worktree 就夠了；Agent 之間真的要互相討論、分工，才用 agent teams。

16 個 Claude 寫出 C 編譯器，為什麼平行行得通？

這是 Anthropic 研究員 Nicholas Carlini 2026 年 2 月的實驗：每個沒通過的測試多半是獨立的 bug，任務切得開；有大量測試和 GCC 可以對答案，驗收不用等人；合併衝突由 Claude 自己處理。後來編 Linux kernel 時大家卡在同一個 bug，他把問題重新切開，沒有多加 Agent。

延伸閱讀

• Plan、Build、Verify、Ship 是什麼？AI 寫程式變快後，進度要怎麼算？（2026 完整懶人包）
• AGENTS.md 怎麼寫？規則寫越多，Agent 反而越貴？（2026 完整教學＋範例）
• Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）
• 用手機遙控 Claude Code 可以嗎？哪些事還是得回到電腦前？（2026 完整懶人包）

參考資料

案例與研究

• Nicholas Carlini（Anthropic）, Building a C compiler with a team of parallel Claudes（2026-02-05） https://www.anthropic.com/engineering/building-c-compiler
• Anthropic, How we built our multi-agent research system（2025-06-13） https://www.anthropic.com/engineering/multi-agent-research-system
• Walden Yan（Cognition）, Don't Build Multi-Agents（2025-06-12） https://cognition.com/blog/dont-build-multi-agents
• Gene M. Amdahl, Validity of the single processor approach to achieving large scale computing capabilities, AFIPS Spring Joint Computer Conference（1967） https://doi.org/10.1145/1465482.1465560

工具文件與公告

• Anthropic, Orchestrate teams of Claude Code sessions（Claude Code 文件，2026-10-16 檢視） https://code.claude.com/docs/en/agent-teams
• Anthropic, Run parallel sessions with worktrees（Claude Code 文件，2026-10-16 檢視） https://code.claude.com/docs/en/worktrees
• OpenAI, Introducing the Codex app（2026-02-02） https://openai.com/index/introducing-the-codex-app/
• Google, Build with Google Antigravity, our new agentic development platform（Google Developers Blog, 2025-11-20） https://developers.googleblog.com/en/build-with-google-antigravity-our-new-agentic-development-platform/
• Cursor, Cursor 2.0（2025-10-29） https://cursor.com/blog/2-0

審查負擔數據

• Faros AI, The AI Productivity Paradox: AI Engineering Report 2025（2025-07-23） https://www.faros.ai/blog/ai-software-engineering
• @IT（ITmedia）, 日本 code reviewer 審查負擔調查報導（2026-06-16） https://atmarkit.itmedia.co.jp/ait/articles/2606/16/news041.html