多 Agent 工作流為何越忙？跨專案切換與 AI 審核成本

TL;DR

同一專案內同時跑多個 Agent，常要處理任務相依、程式衝突與整合驗收；跨專案同時進行開發、測試或研究時，檔案可能互不干擾，人的目標、風險與驗收標準卻持續切換。兩種情境都可能讓產出速度超過人工審核能力，成本來源各有不同。較實用的做法是讓各工作線在自己的專案範圍內先完成可自動驗證的部分，再按專案優先順序與風險安排人工審核。

Takeaways｜重點整理

同一專案先處理任務相依與整合。 各 Agent 的修改範圍、驗收條件與合併次序要清楚。
跨專案先區分任務風險。 開發、測試與研究可以同時進行，但需要人當場決策的工作不宜排成一串打斷通知。
審核摘要要看得出專案歸屬。 交代任務目標、可操作範圍、測試證據與待決事項，避免把指令或核准用到另一個專案。
用待審佇列控制人工負荷。 能自動驗證的工作先完成，再集中審查同一專案的結果；高風險例外另行處理。
比較最終交付與返工。 Agent 數量及完成通知都不足以衡量多專案工作的實際效益。

多個 Agent 完成工作之後仍需要人工驗收

假設有三個 Coding Agent 同時處理不同工作：一個釐清需求，一個修改測試，另一個檢查失敗原因。三個視窗都顯示有進度，等到工作完成，卻可能累積出三大份需要審閱的結果。工程師需要知道它們是否使用相同的假設、修改是否互相衝突，以及測試結果能不能支持交付。

Addy Osmani 在 The Orchestration Tax 把協調 Agent 的隱性成本稱為「編排稅」（orchestration tax）。Agent 可以同時執行任務，人的理解與整合判斷仍有容量限制。Simon Willison 的平行 Coding Agent 使用經驗也指出，獨立研究可以一起做，但重要程式修改通常仍得逐件審核、整合並完成交付。

這個落差也能從研究中找到線索。NBER 2026 年工作論文分析 Coding AI 工具的使用，發現程式提交活動的增幅到了專案與正式發布階段會明顯縮小。研究是配對事件研究設計，不能直接推算單一團隊能節省多少工時；它提醒我們，程式產出變快與最終交付變快仍有差距。

跨專案平行工作會改變協調成本的來源

前面的情境都在同一個專案裡：幾個 Agent 可能共用測試資料、修改同一套程式，最後需要協調合併及回歸測試。但有人一天同時處理三個毫不相干的專案：一條 Agent 工作線修測試程式，另一條處理網站版型，第三條整理技術研究。這時候只要工作目錄與存取權限妥善隔離，Agent 之間通常少了共用檔案的衝突。

人要處理的問題反而變得分散。網站的驗收重點可能是手機排版與連結；測試程式需要重現錯誤和回歸證據；研究文章則重視資料來源、論點和公開內容。每切換一個專案，就得重新確認「這個專案要完成什麼、允許改什麼、什麼結果才算過關」。

面向	同一專案的多 Agent 任務	跨專案的不同類型任務
主要工作關係	共用模組、測試環境或修改結果可能相依	各專案的檔案與執行環境可隔離，任務目標未必相同
常見協調成本	修改衝突、執行次序、整合測試	目標切換、優先順序、不同驗收規則與權限
人工審核重點	相依變更能否一起交付	每件工作的風險、交付標準與是否值得現在處理
可先改善的地方	分清負責範圍、合併順序與測試責任	區分專案狀態、降低中斷頻率、安排分批審核

跨專案切換的負擔早就存在。Vasilescu 等人在 2016 年 ICSE 發表的 GitHub 多專案研究指出，參與多個專案的開發者，如果每天集中在較少的專案工作，生產力往往較好；每天頻繁切換專案則和較低的生產力有關。這是 AI Agent 普及前的 GitHub 活動研究，無法直接當成 2026 年多 Agent 併發的效益實驗。它支持我們重新安排人一天需要深入切換多少個專案，而非為 Agent 設定放諸四海皆準的數量限制。

不同類型任務可以安排不同的審核時間

假設同一天下午有三件互不相干的工作。三條 Agent 工作線可以平行執行，但各自需要的人工審核不同：

工作線	Agent 可先完成	需要人工判斷的時機
專案 A：自動化測試修復	蒐集錯誤、執行局部測試、整理程式差異	調整測試策略、擴大修改範圍或涉及高風險變更時
專案 B：網站樣式調整	依明確範圍檢查版型、產出行動裝置截圖	集中檢查手機畫面與實際導覽效果時
專案 C：技術研究	蒐集資料、比對來源、整理待查重點	確認重要來源、文章論點與公開內容時

這是說明分工的假設情境，沒有宣稱三件事已在特定真實環境同時執行。它們也不必在同一分鐘要求人回覆。測試修復若碰到權限或超出範圍，應立即停止並提出問題；網站版型和研究初稿則可以先排入待審佇列。將人工介入時間錯開，有機會減少零碎通知，但具體效益仍需實測。

切換 Agent 與專案都會累積理解成本

你才看完 Agent A 的測試紀錄，Agent B 就送來修改建議；準備確認 B 的程式，Agent C 又要求調整範圍。同一專案內還可能沿用部分背景，跨專案時連產品目標、程式架構與發布規則都得重新回想。每次切換都要找回任務目標、已完成的檢查和仍未排除的問題。

Sophie Leroy 在 2009 年的注意力殘留研究發現，切換工作後，前一項任務仍可能佔據部分注意力，影響後續工作。這項研究談的是一般工作切換，不能直接當成多 Agent 開發的量化測試。另一篇 2018 年軟體開發中斷研究則指出，切換時的任務情境與中斷類型，會影響開發者受到干擾的程度。這些資料提醒我們，跨專案排程需要考慮人多久被迫重建一次背景。

比較適合的設計是讓進度隨時可查，卻減少無必要的通知。已預期的工具呼叫、例行測試與中間發現可以留在紀錄。只有任務完成、遇到阻塞、修改範圍需要擴大或涉及敏感操作時，再把需要判斷的事情交給人。

適合平行的任務應該能獨立完成

獨立探索不同模組、比對文件、調查不同的失敗假設，通常比較容易拆給不同 Agent。它們的輸入、輸出和驗收條件清楚，工作期間也不會互相修改同一份資料。

OpenAI Multi-agent 官方文件建議把子 Agent 用在明確獨立的工作；依賴前一步的短任務可以留在主 Agent，修改相同檔案則需要協調。當需求本身仍模糊時，先釐清範圍，再決定分工，比追求同時開啟的數量更容易維持品質。

審核摘要能減少重讀完整執行歷程

每個 Agent 在要求人審核之前，可以先交一份固定格式的摘要。跨專案工作還應先標明專案名稱、任務目標、可使用的工作範圍與目前版本，讓人一眼知道正在看哪件事：

完成內容： 哪些檔案或系統狀態實際改變，或研究確認了什麼。
驗證證據： 已執行的測試、檢查結果與可以回查的位置。
限制與風險： 哪些地方仍不能確認，是否需要回歸或補充資料。
人工決策： 只有人能接受的取捨、權限或風險。
追查入口： 對應的差異檔、log、截圖或來源連結。

這是工作流設計建議，尚未有特定團隊的實測成效可供宣稱。能透過程式測試、格式檢查或 end-state 比對確認的部分，應先完成再交給人審閱。其他 AI Reviewer 可以提供補充觀點，但可靠的驗收仍需要實際證據與必要的人為判斷。Anthropic 對可信任 Agent 的討論也提醒，自主動作可能誤解使用者意圖，必須配合適當的權限和監督。

跨專案交接需要核對目標與權限

Addy Osmani 在 2026 年 8 月的多專案實務分享中提過一次自己的失誤：原本想替一個網站增加深色模式，卻把相同指令輸入到另一個專案的工作階段，結果開始修改了錯誤的產品。這是作者的親身經驗，說明工作階段切換本身也可能導致專案歸屬判斷錯誤。

跨專案使用 Agent，可以在每張待審工作卡上顯示專案、工作目錄或 repository、目前分支／版本、允許使用的工具、預期交付，以及下一個需要人工核准的動作。涉及不同組織或資料敏感度時，各專案還需要各自的權限、憑證與資料邊界；不要因為使用同一套 Agent 工具，就讓任務直接讀取另一個專案的私人資料。

這些欄位也能幫助人恢復上下文：先看「我現在在哪個專案、上次決定什麼、為什麼停在這裡」，再查看差異檔或允許後續操作。這是根據案例提出的工程改善建議，不是已完成安全驗證的通用框架。

待審工作堆積時需要調整併發量

當好幾條 Agent 都標示「已完成」，工作卻停在待審核清單，新增工作線只會讓驗收壓力繼續增加。可以先將每個任務分成「尚未開始、執行中、待審核、受阻、已完成」幾種狀態，並優先看待審工作有多少、等了多久，以及最後是否經常返工。

待審佇列開始累積時，就暫緩新的高認知工作，安排集中審核。這種做法稱為背壓（backpressure）：讓前段的產出速度配合後段處理能力。跨專案可以把待審項目依專案與風險分組，在一段完整時段內看完相近背景的工作，減少一整天反覆換專案的次數；但安全阻擋和不可逆操作應即時停下，不能只為了批次審核而延後必要核准。可以先從少量且真正獨立的任務開始，根據每週的審核時間及驗收品質調整；工具的預設併發數不等於人類最佳工作負荷。

一個 Selenium 除錯情境可以怎麼安排

假設一支 E2E 測試反覆逾時。不同 Agent 可以分別調查元素定位、測試資料和執行環境，先回報錯誤假設、支持證據及未排除的可能性，避免同時修改同一份腳本。

等主要工作線整理好分析，再對有限範圍進行修正、局部測試與必要的回歸驗證。如果重試持續失敗，應遵守事先設定的停止條件，留下可接續的證據。人要做的是確認修改是否可以接受、是否需要擴大範圍，以及要不要交回人工處理。

這是用來說明責任分工的假設情境，沒有宣稱已在真實專案部署或量測到節省比例。

評估工作流應同時看交付與返工

比較改善前後的工作流，可以記錄每件任務從啟動到驗收的時間、人工審核分鐘數、因證據不足而返工的次數，以及正式接受修改後是否又出現新的問題。若同時處理不同專案，還要記錄一天真正需要人切換的專案數、需要即時回應的中斷次數、待審佇列的等待時間，以及錯誤專案或權限操作是否發生。

這些資料不需要一開始就靠大型平台收集。先從幾件難度相近的任務建立簡單基準，再觀察是否真的減少人工重讀、等待審核和重複處理。跨專案的研究、測試與網站修改，驗收難度及價值不同，應先在相同類型任務內比較，再回頭看整體工作量。當最終驗收沒有改善，即使 Agent 執行更快，也應重新檢查任務拆分和審核流程。

延伸閱讀： 如何有效節省 AI Token？Coding Agent 的成本優化實務；Claude Code Mods 與 Skill、MCP、Hook 的差異。

AI Agent 越多，工作反而越累？多 Agent 協作的審核瓶頸與改善方法