Parallel Agent Orchestration

資料來源#

• Agent swarms and the new model economics
• Claude Code Changelog
• Claude Opus 5 System Card
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• Introducing Projects
• OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation
• Organizational Principles Enable Collective Intelligence in Embodied AI
• Patterns and problems in multiagent systems
• Prompting Claude Opus 5
• RCWT: Measuring Task-Budget Displacement from Coordination Content in LLM Calls
• Rewriting Bun in Rust
• Running a Software Factory Efficiently at Uber Scale
• SwarmResearch: Orchestrating Coding Agents for Open-Ended Discovery
• The Shift to Agentic AI: Evidence from Codex
• Uncle Bob on Software Fundamentals in the Age of AI
• Who&When Pro: Can LLMs Really Attribute Failures in AI Agents?

摘要#

這是 OpenAI 的 Codex 使用研究 所描述三種「如何」面向中的兩種——並行（同時執行多個代理程式）與執行時間（代理程式替你長時間工作），兩者共同描繪了代理程式使用前沿的工作流程：由一個人監督一組代理程式，將任務分派給許多同時工作的執行者，而不是親自直接完成工作。 Codex 的 threaded 互動模型讓這件事成為可能——每個代理程式都在大致獨立的工作區執行，因此使用者不必等一項任務完成才開始另一項。本文為 Founder as Agent Orchestrator、Loop Engineering 與 Managers as ICs 定性描述的角色轉變，提供首批確切採用數據：在高強度使用者之中，Codex「與其說是回答請求的助理，不如說是工作流程系統；使用者在其中分派、監控、審查並協調多條工作流。」

證據註記。 empirical——並行度以 2026 年 6 月 11 日前一週不同 threads 中重疊的回合（重疊時間 >30 秒）衡量；執行時間以每日累計的啟用回合延遲衡量（移除 >30 分鐘的間隔，視為等待輸入）。OpenAI 內部數據是前沿預覽，不是整體人口估計。每日累計執行時間可能超過 24 小時，因為重疊回合會加總。

並行度：OpenAI 與外部使用者的落差十分鮮明#

依使用者群體呈現的測量週最高並行代理程式數：

群體	零個並行回合	5 個以上並行代理程式
組織使用者	67.4%	少數長尾
個人使用者	63.9%	少數長尾
OpenAI 員工	10.7%（使用單一工作流程）	28.6%

外部使用者的並行度「相當低」——約三分之二從不讓回合重疊；有重疊的人，大多最高同時執行兩個。OpenAI 員工的情況正好相反：只有 10.7% 曾只執行一個工作流程，28.6% 管理過五個以上並行代理程式。論文稱這與外部使用方式「根本不同」：它要求人類管理、委派工作給並審查一群相對龐大的代理程式——這是監督式工作流程，而非親自動手的工作流程。

執行時間：長時間工作集中在最高端的長尾#

執行時間面向也呈現相同的中位數與前沿落差：

• **OpenAI 員工中位數：**每日約 2.5 代理程式小時（2026 年 6 月 11 日）。這代表有意義的委派工作時段，但不是全天候持續執行——典型使用情形仍是間歇性的。
• OpenAI 員工 p99：每日約 71 代理程式小時——這表示任一小時都可能有數個代理程式同時執行。較 2026 年 4 月 7 日增加約 88%。
• **外部使用者的長尾也在增長：**樣本期間內，每日執行時間 p99 上升約 25%（組織使用者）及 50%（個人使用者），但絕對值仍遠低於 OpenAI。

兩個面向呈現的模式一致：對典型使用者而言，代理程式工作流程仍是零星使用；但一小群高強度使用者正迅速擴大委派出去的工作量——而這群人絕大多數位於 OpenAI，也就是前沿預覽之中。

為何是軟體、為何是現在，以及人類角色的反轉#

論文以讓程式設計成為代理式 AI 領先領域的相同特性，說明並行化何以可行：軟體工作是數位化、可驗證，且能模組化拆成許多子任務——這正是讓一個人能把工作分派給許多獨立代理程式並審查結果的形態。其結果是角色反轉：人類不再是執行者，而成為一批代理程式工作的委派者、監控者、審查者與協調者。這正是行為中顯現出的審查與監督瓶頸——平行執行的代理程式愈多，吞吐量愈受限於你的審查能力，而不是模型的產出能力（Loop Engineering 所說的「你能實際執行多少個，取決於你的審查頻寬」；AI Brain Fry 所說的監督疲勞上限）。

廠商測量：多代理程式成為獨立的一級能力章節（2026 年 7 月）#

以上測量的都是人類如何把工作分派給代理程式。Opus 5 系統卡首次把代理程式把工作分派給代理程式列為主要能力，並在每個代理程式上限為 1M tokens 的條件下，以兩種 harness 對照單一代理程式基準：

• N-agent team——5 或 10 個同儕代理程式，每個都能看到完整任務，指定一名領導者負責協調；使用 Send Message 與 Wait for Message 工具；在 ProgramBench 中，每個代理程式都在自己的 repo checkout 工作，並透過 Git 分享程式碼。
• Async subagents——領導者會啟動長時間執行的子代理程式；子代理程式只能看到領導者的指示（看不到原始任務），可以彼此傳訊息，回報後會閒置，直到再次喚醒。子代理程式數量沒有上限。

結果如下：在 BrowseComp 上，10-agent team 達到 93.6%，比最佳單代理程式設定高 3.1 個百分點；相較單代理程式 10M-token 基準，延遲加速 5.6–5.9 倍——每種多代理程式變體都達到或超越最佳單代理程式設定，在分數—延遲前沿上形成 Pareto 優勢。在 ProgramBench 上，5-agent team 以快 2.2 倍的速度達到相同分數。成本會隨代理程式數量上升：較誠實的說法是以成本換延遲；多代理程式能「透過將工作分散到不同代理程式，有效吸收額外的 token 預算」，而非免費獲勝。

有兩項但書值得記住。數據來自預發布設定，使用尚未發布的 effort 設定，也沒有 safeguards classifiers；Anthropic 表示這些結果「有助於理解相對表現，而非絕對表現」。此外，對齊面向尚未測量：Mythos 5 審查同一張系統卡時指出，Opus 5 會將子代理程式的說法轉述給使用者，卻不先驗證；稽核也承認多代理程式涵蓋不足是其限制（Agentic Honesty & Diligence）。能力章節把多代理程式列為前沿能力；安全章節目前尚未涵蓋它。（部分 harness 端緩解措施，2026-07：Claude Code v2.1.211 表示 Claude「現在會回報仍在執行的代理程式狀態，並等待真正完成，而不是捏造結果」——這能防止虛構尚未完成代理程式的結果，卻無法防止轉述已完成代理程式未經查證的說法。這是不同的失敗模式，但發生在相鄰環節。）

成本制衡：限制委派數量#

Anthropic 的提示指南（vendor-claim，系統卡發布隔天）在能力結果旁附上支出警告：Opus 5 「比先前模型更容易委派給子代理程式」；委派「用於真正獨立且規模可觀的工作軌道時有其效益，但套用在小任務上會增加成本與耗時」。指南建議明確規定何種情況值得啟動子代理程式，或以確定性上限限制可啟動的代理程式數量——並且「如果一個子代理程式就能完成任務，就用一個，不要用好幾個」。擴大分派的傾向被視為需要設下界線的行為，而非值得鼓勵的特性（Instruction Compounding）。

指南也首次由廠商說明系統卡中的 harness 設計所暗示的多代理程式失敗模式：Opus 5「擅長協調子代理程式團隊，能有效運用 writer-verifier 模式，而且代理程式互相覆寫工作成果的情況很少」——而 ProgramBench 的設定（每個代理程式在自己的 repo checkout 工作，透過 Git 分享）正是為了避免這種寫入衝突風險。

設定上限的門檻：狀態放不進去時才分派（2026 年 7 月）#

指南建議限制委派，卻沒有說明該在哪裡設限。OrchBench（arXiv 2607.25656，empirical）透過對 50 個模擬任務 DAG 掃描每個代理程式的 context 上限，提供第一個量化答案：多代理程式相較單一序列代理程式的品質優勢，從 16k 時 +0.302 → 32k 時 +0.172 → 64k 時 +0.060 → 128k 時 +0.007 逐步衰退；在 128k 時，82% 的模型—問題組合中多代理程式品質反而低於單代理程式，微幅正向的平均值完全由最大型（100 個子任務）問題帶動。代理程式預算掃描對廣度也得出相同結論：將上限從 16 提高到 64，代理程式數量增加逾一倍，分數只增加約 0.01。研究也為指南只點出、未量化的成本定了價——在品質提升出現之前，多代理程式計畫消耗的 tokens 約為序列執行的 1.5 倍，來源包括代理程式啟動、跨代理程式通訊與壓縮。

兩項但書表示這還不能直接當作部署規則。工作者是模擬的，因此單代理程式基準只承受壓縮損失——沒有注意力退化，也沒有長 context 回憶失敗——這可能讓它在 128k 時看起來比實際更好。此外，這些是使用固定分解的相依 DAG 工作流程，而非開放式探索；Akshay Nathan 指出，多代理程式真正適合的正是後者。可移植的主張是其趨勢：增加代理程式能緩解 context 壓力；一旦工作狀態放得進單一視窗，剩下的就是協調成本。

在單次呼叫中測量協調成本（2026 年 7 月）#

OrchBench 在計畫層級衡量協調成本，Anthropic 約 15 倍的多代理程式 token 倍率則在系統層級衡量。RCWT（Lelis 與 Cabral-Carvalho，CloudWalk, Inc.，arXiv 2607.12216，empirical）再往下一層，在接收呼叫內衡量：共享狀態、先前代理程式訊息、工具觀察結果與角色提示，都會和目前任務一起組進同一個有限提示中，因此**每個協調 token 都會占用原本可用於任務證據的 token。**固定預算 W = 4096 並掃描協調內容占比時，技術規格回憶任務的準確率在占比達 69% 前都持平，接著在 83% 到 86% 之間急遽下滑——此時剩餘的參考內容區塊只剩幾百個 tokens。

要看清機制，而不是只看標題數字。一項配套消融實驗保留完整任務區塊，只讓整體提示變長：協調比例為 0.95 時——13,262 個協調 tokens，包圍著 698-token 的任務——三個模型中每個受測呼叫都正確回傳所有評分欄位，沒有出現斷崖。因此這裡協調內容的成本是在固定預算下排擠任務證據，而非與任務證據爭奪語意空間。Context Lifecycle Management 說明完整的兩項實驗分析、各視窗數據，以及依任務類型變動約 3.5 倍的保留量；可部署的規則是，名義上的視窗大小與協調內容的百分比都不是安全訊號——真正重要的是剩餘的任務預算，而且必須依任務類型衡量。

**這與本文其他內容有多大關聯——比乍看之下小。**論文提出三項限制：

• **這是單次呼叫協定。**刻意排除回合排程、檢索策略、記憶寫入、工具故障與代理程式拓撲。此處的結果不能擴大到整個 session，更不用說 Bun 的 64 個代理程式或 Cursor 每秒 1,000 次提交。
• **協調區塊只有一種合成範本。**角色／協定文字、代理程式訊息、共享命題與工具 schema——結構類似多代理程式共享 context，卻不是來自真實逐字稿。真實協調內容（大量工具輸出、冗長逐字稿、互相矛盾的代理程式說法）在相同 token 數下可能表現不同；此設計無法區分內容類型與長度。
• 它只測量成本。「對一個代理程式而言是額外負擔的協調區塊，對另一個代理程式而言可能是任務輸入。」RCWT 沒有估算協調帶來的效益。

與 OrchBench 對照時，兩者互補且指向相反方向——並非測量同一件事。OrchBench 的主要失敗是缺少傳遞：計畫未宣告的跨代理程式相依關係，會以 λ = 0.5 受到懲罰；其主要發現是，協調品質受限於資訊被保留的程度。RCWT 衡量相反的過量：協調內容存在，卻把證據擠出視窗。因此 RCWT 不是 OrchBench 缺漏傳遞結果的 token 層級機制；它對應的是相同資源配置取捨的另一端，並為 OrchBench 的 context 上限掃描補上底線：分派工作能紓解每個代理程式的 context 壓力，但代理程式之間傳送的協調內容會部分占回剛釋出的視窗；而 OrchBench 本身的計算已將這類流量計入，序列執行的 tokens 約需 1.5 倍。綜合兩者，誠實的說法是：現在已測量這兩端，但兩者都不是用真實代理程式測量的——OrchBench 的工作者是模擬的，RCWT 的協調內容是合成的，且呼叫是單次的。

上限成為產品預設值（2026 年 7 月）#

上面的指南建議「以確定性上限限制可啟動的代理程式數量」，這是應由 harness 作者撰寫的規則。幾週內，Claude Code 更新記錄（vendor-claim，滾動文件快照日期為 2026-08-03，範圍涵蓋 v2.1.200–2.1.220）顯示 Anthropic 在自己的產品中將同一控制設為預設值——九個版本中推出三種上限：

版本	上限	覆寫設定	Anthropic 說明的目的
2.1.212	每個 session 最多啟動 200 個子代理程式（/clear 會重設預算）	CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION	「防止委派迴圈失控」
2.1.212	每個 session 最多執行 200 次 WebSearch	CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION	「防止搜尋迴圈失控」
2.1.217	最多同時執行 20 個子代理程式	CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS	「避免單一訊息無限制地分派背景代理程式」

2.1.217 也讓 --max-budget-usd 在分派時生效（達到上限時，「會拒絕新的啟動，並停止正在執行的背景代理程式」）；2.1.219 則將動態工作流程的預設規模指引設為中等大小——「目標少於 15 個代理程式」——可透過任何設定檔中的 workflowSizeGuideline 設定。深度則走了相反方向：2.1.217 預設停用巢狀子代理程式啟動，2.1.219 又將深度設為 3 並重新啟用。廣度設了上限，且維持上限；深度則在三個版本內先設限再解除。

有兩點值得從數據中讀出，但都只是暫時性推論：

• **真正會限制使用的是並行度，而非 session 預算。**對本文資料集測得的規模來說，每個 session 200 次啟動相當寬鬆；同時執行 20 個則低於 Bun 的峰值 64，也低於 OrchBench 掃描的 64 個代理程式預算。（機制上的但書：更新記錄所說的上限適用於 Task 工具子代理程式，而 Bun 的 64 個是分布於四個 worktree 分片的動態工作流程代理程式；更新記錄沒有說明這兩個計數器是否相同。）
• 工作流程預設值比廠商自己的頭條數字低一個數量級。「少於 15 個代理程式」是 Boris Cherny 在台上形容能擴展至「數十到數千個代理程式」的功能，其正式推出時所採用的預設值——這個落差見Dynamic Workflows: An Algebra for Agents，本文在那裡討論。

這些數據有多大參考價值——以下為詮釋，請留意。廠商為自家部署加入硬性啟動上限，說明它認為自身部署需要這項控制；而這也正好落在本文記錄分派成本的同一時期。但更新記錄除了「迴圈失控」之外沒有說明理由，沒有測量，也沒有遙測，因此不能用來佐證上文的協調成本或監督負載研究結果；這只是產品決策與研究方向不謀而合，而這些數字（200、20、15、深度 3）是產品預設值，沒有人證明它們是正確門檻。

**值得指出的表面矛盾。**同一份文件既說 writer-verifier 模式有效，也說「不要用子代理程式驗證或複查自己的工作」。調和兩者的方式是：有獨立任務簡報、刻意設計的 maker/checker 分工，與模型自行為自己的輸出啟動驗證者並不相同（Unproductive Self-Verification；Optimizer–Evaluator Decoupling 說明前者為何有效的架構原因）。但指南本身沒有劃出這條界線，因此只看委派章節的 harness 作者，可能會刪掉文件其他地方認可的 maker/checker 分工。

64 個代理程式下的實際限制是什麼（Bun，2026）#

上文談的不是使用遙測，就是基準測試 harness。Jarred Sumner 將 Bun 從 Zig 移植至 Rust 的經驗（Rewriting Bun in Rust，case-study；Anthropic 員工，使用預發布版 Fable 5）是知識庫中首份記錄在真實正式環境 repo 連續 11 天大規模分派工作的案例，重點報告失敗模式，而非分數。其主要規模——64 個 Claude 同時執行，分成 4 個工作流程分片、每片 16 個代理程式，每個分片使用一個 git worktree——不是理想設計，而是四項限制下的結果：

• 共享樹狀工作區中的代理程式幾分鐘內就會互相破壞。第一次完整執行時，「大約兩分鐘後，一個 Claude 在提交前執行了 git stash。另一個執行了 git stash pop。接著有人執行了 git reset HEAD --hard。」修正方式是在工作流程提示中加入命令拒絕清單：絕不可執行 git stash、git reset，或任何不是一次只提交特定檔案的 git 命令；不准用 cargo；「完全不跑慢速命令」。cargo check 被移到每輪 crate 迴圈一開始只執行一次。
• **每個代理程式各用一個 worktree，無法擴展。**直觀的隔離方案因兩項理由遭到否決——Bun 的 repo 太大，無法在磁碟上存放 64 份 checkout；而且「最終必須將變更一起編譯並查看」。以四個 worktree 分片，是磁碟容量與整合需求之間的折衷；隔離粒度由儲存空間決定，而非並行理論。
• **測試套件會妨礙自己的 harness。**其中有記憶體洩漏測試、耗時超過一分鐘的整合測試、會耗盡機器 TCP socket、寫入數 GB 資料或啟動約一萬個程序的測試。「光說『拜託』不足以隔離」——因此使用 systemd-run cgroups 管理記憶體／CPU，並隔離 pid namespace。機器還是多次磁碟空間耗盡並當機。
• **限制規模的資源是 IOPS，而非 tokens 或代理程式數。**提交速率直方圖明顯參差，原因是忘了設定 EC2 IOPS：「只要一個慢速 grep 命令，就足以讓磁碟讀寫凍結好幾分鐘。」

**這直接反駁 Opus 5 提示指南所說「代理程式互相覆寫工作成果的情況很少」。**那項主張是在一個刻意設計來防止這種情況的 harness 中測得（每個代理程式在自己的 repo checkout 工作，透過 Git 分享）。Sumner 的代理程式共享同一個工作樹，立刻互相覆寫；修正方法是提示層級的命令禁令加上 worktree 分片——也就是說，廠商令人安心的數據描述的是 harness，不是模型。在同一份工作副本中分派代理程式的團隊，應預期會發生衝突，而不是期待衝突不會發生。

也值得拿它來對照上面的使用遙測：64 個代理程式比動態工作流程宣稱能達到的「數十到數千個代理程式」低兩個數量級。這是知識庫中，與真實、已發布的正式環境合併相連的最大並行數字；其上限受基礎設施限制，而非認知能力限制。

對協調層進行工程化，並以自身成效衡量（Cursor，2026）#

上文 Bun 的限制，是一場透過逐步試錯爬升到可用形態的長期行動所留下的結果。Cursor 的 Agent swarms and the new model economics（Wilson Lin，2026-07-20，case-study）展示了下一輪迭代：廠商回頭刻意打造協調層；在本文資料集中，這也是獨一無二的案例，它在相同任務、相同模型、相同時間預算下，以新 harness 重跑舊 harness 的測試。

任務是：在無法取得原始碼、測試套件、SQLite 二進位檔與網路的情況下，以 Rust 實作完整的 835 頁 SQLite 手冊。評分方式是 swarm 所建資料庫通過 sqllogictest 的比例——這是 SQLite 專案建立的測試套件，用來檢查不同資料庫引擎對相同查詢是否回傳相同答案。swarm 從未被告知這套測試存在；Cursor 之後會人工檢查每次執行結果，確認有無作弊、走捷徑，以及系統是否「均衡地建置完整，而非只完成測試會檢查的部分」。

節奏問題，以及為此打造的 VCS#

先前的瀏覽器 swarm 在 Git 上每小時最高約提交 1,000 次；新系統每秒最高約提交 1,000 次。Cursor 表示，從頭打造版本控制系統的理由只有部分在於吞吐量：每項變更都會經過 VCS，因此它是最先顯現衝突的地方，好幾種協調機制也都實作在其中。掌握合併層，才能觀察到衝突——使用原版 Git 的 swarm 沒有任何工具能回報單一檔案發生 7,771 次衝突。

這種速度會帶來五種人類團隊不常遇到的失敗模式。閱讀每項修正時，應把它視為一種機制類型，而非 Cursor 的個別細節：

失敗模式	問題所在	修正方式
設計分歧	兩個規劃者彼此不知情，在不同位置以不同方式實作相同概念	提示：規劃者自行做設計決策，不要把決策委派出去；並須確保沒有兩個受委派的子樹決定同一個問題
規劃者之間的角力	兩個知道彼此存在的規劃者透過來回編輯互相爭執——「兩套現實認知，合併工具無法修復意見分歧」	將決策記錄在共享設計文件；相依程式碼帶有回指文件的編譯器檢查參照；協調者合併彼此矛盾的文件，參照再把決議傳遞到下游
合併衝突	工作者不擅長吸收其他代理程式的 context，所以「不是覆寫對方的變更，就是放棄自己的變更」	由中立的第三方代理程式代表各方解決衝突——明確仿照人類合併佇列設計
巨型檔案	熱門檔案愈長愈大，因為沒有單一代理程式負責維持檔案精簡；檔案因此難以傳送、比較與合併，也成為持續衝突的場所	工作者可以標記膨脹的檔案；新提交會被擋下，再由外部代理程式將檔案拆解成模組
僵化	代理程式從有人類介入的程式碼庫學到，即使核心程式碼需要修改，也不要碰它	允許刻意破壞相容性：代理程式可進行範圍外的聚焦修補，並留下註解說明原因；編譯器會將破壞一路傳遞到系統各處，每個遇到錯誤的代理程式都會看到註解並更新自己的工作

規劃者角力的修正方式，對這個 wiki 尤其值得關注：這是一種具型別、由編譯器強制執行的代理程式間資訊傳遞——正是 OrchBench 獨立檢驗、並發現比代理程式數量更能預測協調品質的變數。

重建帶來的變化#

Grok 4.5 設定下，舊 harness 與新 harness 的比較，預算為四小時（舊版執行在第二小時開始前就被暫停）：

指標	舊 swarm	新 swarm
提交數	前兩小時 68,000 次	約為舊版速度的 1/70
合併衝突	暫停前 超過 70,000 次，而且持續加速	完整四小時內 <1,000 次
衝突最多的檔案	7,771 次衝突，由 1,173 個不同代理程式修改	程式碼庫中爭議最多的檔案：47 次
crate 膨脹	54 個 crates，包括三套不同的 SQL 套件	很早就定為 9 個，之後沒有再增加
四小時評分	舊版在不同組合下為 11–77%	新版為 73–85%；每種新版設定最後都通過 100%
引擎程式碼，Fable 5 組合	64,305 行（完整套件通過）	9,908 行（完整套件通過）
引擎程式碼，Opus 組合	19,013 行，達 97%	4,645 行，達 100%

提交速率暴跌這個數據值得記住。提交量增加 70 倍，不代表生產力增加 70 倍——這是 Cursor 自己的解讀，衝突曲線也支持這一點：舊版執行被中止時，衝突仍在加速增加，而非趨於穩定。**分派吞吐量與分派進度是兩回事；直覺上的活動量指標會把方向看反。**程式碼行數也是如此：在兩種混合模型組合下，達到相同評分的 harness，程式碼量只有舊版的四分之一到六分之一。

與 Bun 的經驗對照#

兩場行動都撞上同一面牆，只是在不同階段做出回應。Bun 的代理程式在第一次完整執行後兩分鐘內就互相覆寫；修正方式是提示層級的命令拒絕清單加上 worktree 分片——成本低，但只是避免碰撞，沒有真正解決衝突。Cursor 的答案是專用 VCS，內含公正的調解代理程式，另加巨型檔案拆解 daemon 與允許刻意破壞相容性的協定。同一類失敗模式，多出一個數量級的機制，並且在固定模型、固定預算下明確測量出這些機制值得投入。

審慎看待這些結果。這是廠商對自家基礎設施的描述；其主要比較是不同 harness 版本的比較，約有七項改動一起綁定——沒有消融實驗，因此無法把差異歸因於 VCS、調解者、審查堆疊，或 Field Guide 個別項目。Cursor 也坦承如此：「在這一輪，重要的是比較 harness 版本。」四種組合中有兩種也使用 Cursor 自家的 Composer 2.5 作為工作者。扣除這些限制後，仍成立的是方向與幅度；差異大到不可能把七種機制之間的效益重新分配後，就將協調結構視為次要因素。

從工程化 swarm 到正式推出的產品：單一協調者與訂閱（Cursor Projects，2026-09）#

上面的 swarm 經濟文章是 Cursor 自己的工程經驗。Projects（Robbins 與 Lindh，2026-09-10，vendor-claim）是同一家公司正式推出的產品，其形態比文中描述的遞迴規劃者／工作者樹更單純：一個不親自寫程式碼的協調代理程式，指揮負責實作的子代理程式；預設在雲端執行，需要時才在本機執行，因此關上筆電也不會讓工作停止；共享 context 檔案集合會同步到 Project 使用的每台機器——代理程式會新增研究、產出物，以及對程式碼庫與使用者偏好的認識，讓後續代理程式承接前面代理程式累積的 context，不必重新推導。訂閱功能——由協調者監看 Slack 頻道、按排程執行，或追蹤 PR 事件——讓它可以根據偵測到的訊號採取行動，不必等待使用者提示；這與 Symphony 透過拉取 ticket 佇列、而非由訂閱推送觸發，採取的是同一種脫離聊天回合的做法。

Cursor 自行公布的數據是：新使用者合併 PR 數量多 30%，而主要使用 Projects 的使用者合併數量是其他使用者的六倍。應將此解讀為廠商測量且有選擇偏差，而非因果證據——比較對象是 Cursor 自家使用者，而使用者自行決定採用 Projects 的程度；研究沒有公布控制組或配對樣本，因此 6 倍數字混合了「Projects 讓你更有效率」與「原本就合併最多 PR 的工程師最積極採用 Projects」兩種因素。這篇文章對本文持續探討的監督負載問題，唯一的定性主張是一則遷移經驗，而非測量結果：遷移初期「你會仔細審查每一個 PR」；「隨著修正證明可靠，你會減少審查」，協調者則持續自行工作——這是第一方案例，呼應本文其他地方提到的審查頻寬上限 Loop Engineering 與 DHH (David Heinemeier Hansson)，卻不足以解答這個問題。

**文章沒有提到的事本身就是一項數據。**它完全沒提合併衝突、巨型檔案，或 swarm 經濟文章大半篇幅所述的每秒約 1,000 次提交 VCS，因此本文無法確認「單一協調者」只是先前遞迴式規劃者／工作者樹換上產品名稱，還是確實更扁平的架構，透過其他方式避開了那些失敗模式（例如讓每個 Project 的代理程式數遠低於先前 swarm 的規模）。缺少這些細節，本文將 Projects 視為 Cursor 的第二項、形態不同的數據，而不併入上方 swarm 經濟數據。

隔離本身就是目的：每個代理程式各用一個分支（SwarmResearch，2026）#

本文所有分派案例都把隔離當成成本——磁碟與整合之間的折衷（Bun 的四個 worktree）、需要調解的合併問題（Cursor 的 VCS），或需要編列預算的協調負載（RCWT）。SwarmResearch（Virk、Edds、Xia 與 Zhang，UIUC，arXiv 2607.02807，empirical）則是把隔離當成產品本身的案例：Shepherd Agent 為每個 Search Agent 配置專屬 git branch 與 worktree，讓彼此競爭的解法永遠不會合併；因為任務是開放式最佳化，設計要避免的失敗是整個解法族群都收斂到同一種方法。

直接與 Bun 對照，就能看出兩者對同一問題給出相反答案：

	Bun Zig→Rust (case-study)	SwarmResearch (empirical)
隔離粒度	4 個 worktrees × 16 個代理程式	每個代理程式一個 worktree（探索者預算約 25 個以上）
原因	磁碟放不下 64 份 checkout，而且「最終必須將變更一起編譯並查看」	branch 本來就不該整合；合併罕見且非必要
衝突	代理程式兩分鐘內就互相覆寫；以 git 命令拒絕清單修正	結構上不可能——沒有兩個代理程式共用同一棵工作樹

**關鍵在於平行工作是否必須收斂。**Bun 的 64 個代理程式共同打造一個二進位檔，因此隔離是必須在整合時回收的額外成本；SwarmResearch 的代理程式則探索各種方案，最後只會推出其中一個，因此隔離沒有成本，而保留失敗分支正是目的。每個代理程式一個 worktree 並非一般來說可擴展或不可擴展——當輸出彼此是替代方案而非組成部分時，這種作法恰好可擴展。

其中兩個數字適合放在本文。分派廣度應隨深度調整，沒有任何固定設定能放諸四海而皆準。在 60 次迭代的預算下，掃描固定的 n 個並行代理程式 × k 次序列迭代，組合為 (5,12)、(10,6)、(15,4)、(20,3)、(30,2)：五項任務中有四項的最佳設定是寬而不深；最寬的設定（30, 2）從未是最佳選擇；五項任務中有四項的最佳 (n, k) 不同。允許協調者即時選擇廣度與深度——完全沒有縮放超參數——在五項任務中的四項勝過最佳固定設定，代價是輸出 tokens 增加 7.7%（帳單主要來自 60 個子代理程式）。對照上文 Claude Code 正式推出的上限，實際觀察到 Shepherd 每輪執行約 4–8 個代理程式，比 20 個並行上限低一個數量級。

**而協調者正是最可能陷入自己試圖避免之收斂問題的元件。**SwarmResearch 的 shepherd skill 禁止它告訴 Search Agent 該追求哪個想法——作者發現，指定想法會損害族群多樣性，「否則 Shepherd Agent 本身也可能困在某個想法的局部盆地」——但他們在 §3.5 中也報告，模型仍違反規則，預設幾乎貪婪地集中到排名最高的方案。全域 context 讓協調者更擅長分配資源，卻更不擅長探索；提示無法修正這個問題。

協調是模型屬性，而非 harness 屬性（Anthropic, 2026-08）#

Bun 和 Cursor 都大致固定模型、調整 harness。Anthropic 的 Frontier Red Team（多代理系統中的模式與問題、empirical、第一方來源）則反其道而行——一套 harness、五代模型——指標仍然隨之變動。

所有執行的環境都相同：每個代理程式都有自己的虛擬機器、一個共享論壇，以及一個自行託管的程式碼儲存庫；每個蜂群有 12 小時建置「一款以文字為基礎、可在網頁遊玩、開放世界的奇幻遊戲」。蜂群規模從 10 到 80 個代理程式不等，提示也分成三種版本：

• baseline — 組成團隊並彼此合作；
• prescriptive roles — 指定要組成哪些團隊（核心程式設計、藝術指導、遊戲測試）；
• CEO hierarchy — 指定一個代理程式為 CEO，後續所有代理程式都向它領取任務。

提示版本「沒有造成太大差異」——這是值得保留的低成本負面結果，因為在提示裡加入組織圖，是多數 harness 作者最先想到的做法。Cursor 的協調修正是在機制層面奏效（從程式碼回到設計文件、經過編譯檢查的參照；第三方合併代理程式；分解工作用的 daemon）；單靠角色與階層文字則沒有奏效。而且每款產出的遊戲都同樣糟糕——「它們無法以人類的速度運作，介面難以理解，學習曲線也陡峭得驚人。」Anthropic 自己的看法是：「模型在這個領域的品味不佳，目前仍需要大量人類指導。」

合併吞吐量與程式碼共享是兩個軸，只有一個模型能兼顧#

三種提示類型在各蜂群規模下的平均值，分別得到兩項指標：

• 合併比例 — 模擬結束前合併進 master 的 PR 占比。
• 程式碼共享 — 以一個代理程式的一個檔案為例，該檔案由其他代理程式撰寫的比例；再依該代理程式自身撰寫的檔案占比加權計算。零代表該代理程式從未碰過共享檔案；接近一則代表它只對自己不負責的檔案做少量貢獻。報告數值是代理程式中位數的分數。

世代趨勢才是研究發現，而且並非單調改善：

世代	程式碼共享	合併比例	意義
Sonnet 4.6, Opus 4.6	都提交到相同檔案	非常低	真正的衝突：PR 互相衝突，之後就被放棄
Opus 4.8, Mythos Preview	非常低——每個代理程式各自擁有大量檔案	高	透過幾乎完全不合作來「解決」衝突
Sonnet 5	相對高	高	唯一能同時處理共享資源並維持吞吐量的模型

在 80 個代理程式時，舊模型的失敗可從原始數量看出：Sonnet 4.6 開了 876 個 PR，Opus 4.6 開了 980 個，卻只關閉其中少數；較新的模型則合併了大多數自己開出的 PR。合併比例也會隨蜂群從 10 個擴大到 80 個代理程式而下降，4.6 世代的降幅尤其明顯。

這會改變本文三個方面的看法：

• 衝突率同時是 harness 與模型的屬性。Bun 的代理程式在共享樹狀目錄上兩分鐘內就互相覆寫，解法是禁止特定 git 指令的 deny-list；此處則透過設計將隔離做到極致（每個代理程式一台 VM、自行託管的儲存庫），但較新的模型仍傾向避開共享檔案，而非合併其中。Sumner 的 deny-list 和 Cursor 的協調者，是為某種失敗模式而打造；2026 世代的模型愈來愈常透過各自為政來避開這種失敗。這也表示，供應商聲稱 Opus 5「代理程式互相覆寫工作的情況很少」，完全可能與代理程式幾乎不合作並存。
• **各自為政是一種得分漂亮的協調失敗。**除了程式碼共享以外，本文所有指標都會在代理程式不再碰彼此檔案時改善。若團隊只最佳化合併比例，就會偏好這項實驗指出的問題行為。
• 唯一一筆真實代理程式數量對照蜂群規模的資料。OrchBench從持平到負向的人口曲線，是以模擬工作者測得；這裡則是真實代理程式從 10 增至 80，合併比例隨之下降。這不是品質曲線（每個產品都很差，因此品質沒有拉開差距），只測量協調吞吐量。

蜂群確實有所收穫之處：45 個代理程式探索漏洞#

同一篇文章開頭的實驗是正面案例，與遊戲蜂群的對照正是重點——**當工作天生可平行化，而且代理程式不依賴彼此的輸出時，協調就能帶來效益。**45 個代理程式各自使用一台 VM，共享一個論壇，收到完全相同的提示，在 15 個開源專案中尋找漏洞、彼此審查發現，另由一個仲裁代理程式判定每項提交是否為新發現且有效。協調式 Mythos Preview 代理程式使用 2,700 萬 tokens 找到 266 個漏洞；獨立平行基準組則使用 650 萬 tokens 找到 21 個，兩種方法僅有 12 項發現重疊。完整數字、每個漏洞的 token 數核對方式，以及注意事項，請見LLM 驅動的漏洞研究。

這兩項實驗劃出的分界是：在漏洞蜂群中，「代理程式不會直接依賴彼此的工作：如果一個代理程式漏掉某個錯誤，並不會直接破壞另一個代理程式的工作」；而軟體專案「通常會在演進過程中形成豐富且動態的相依性」。蜂群形式相同、論壇相同，結果卻相反，變因是相依結構——這也與上文SwarmResearch提出的調和方式相同，只是高了一個層次：當輸出是不同選項或彼此獨立的部分時，分流成本低；而當輸出必須匯聚時，分流成本恰好最高。

目前還做不了的事後分析（WHO&WHEN PRO, 2026）#

本文介紹的每種工作流程——64 個並行 Claude、每秒 1,000 次提交的蜂群、每天 71 個代理程式工時的 p99 使用者——都仰賴一個未明說的假設：執行出錯時，你能查明是哪個代理程式在哪個步驟出了錯。Liu、Xi、Zhang 等人（Who&When Pro：LLM 真的能歸因 AI 代理程式的失敗嗎？、arXiv 2607.09996、empirical）直接以 12,326 條失敗軌跡測量這項能力；這些軌跡有黃金標準的代理程式／步驟／模式標籤，而測得的能力不如這項假設所需。

• **「誰」這一半幾乎跟丟銅板差不多。**在多代理程式文字軌跡中，責任代理程式辨識率在十個前沿模型上介於 48.4–57.5%。（論文沒有報告每條軌跡中的代理程式數量，因此無法推導機率基準——但這個數字不足以供人據此採取行動。）
• **「何時」這一半可用於分流，不能當成定論。**文字軌跡中，最佳的精確步驟定位準確率為 73.9%；若容許誤差在一步內，則約為 86–88%。但從長度低於 3K tokens 的軌跡到超過 12K 的軌跡，準確率會從 94% 降至 50%；而最明顯的下滑，正好出現在軌跡不再是單次工具呼叫，而是觀察交錯其中的多步序列時。大規模代理程式群組的執行，完全落在這條曲線較差的一側。
• 「為何」這一半會錯誤命名編排特有的失敗。18 種模式分類的 Macro-F1，在文字軌跡上只有 10.8–22.2，錯誤也有固定模式：規劃、驗證與協調錯誤——委派給錯誤的代理程式、在代理程式邊界間扣住資訊、代理程式看到另一個代理程式的正確答案後放棄自己的正確答案——會系統性地被歸入「推理錯誤」，因為等到失敗顯現時，局部證據看起來就像推理不佳。因此，多代理程式執行的自動事後分析會低報協調的肇因占比、高報模型品質，讓團隊朝更強的模型前進，但真正的修正其實在編排層。

有兩項限制。這是 LLM 閱讀軌跡的結果，並非任何已發布的除錯工具；而且每條軌跡都是在原本成功的執行中注入單一錯誤，因此這些數字代表自然發生、多重成因失敗的上限，而非下限。完整分析請見自動化失敗歸因。

當階層是一種機制，而非角色標籤（ORCH、具身代理程式，2026-09）#

到目前為止，本文中的每種階層不是套在扁平蜂群上的提示文字（就在上文的虛無結果），就是經由反覆嘗試建立的臨時限制集合（Bun、Cursor）。ORCH（Ji、Hyun 與 Chen，Duke，arXiv 2609.11737、2026-09-10、empirical）是第三種形式：由兩種結構上不同的管理者類型組成的階層——一種負責彙整式（並行）工作，一種負責循序式（階段閘控）工作——依任務而選擇和組合，而非寫進提示中；並在 25 項具身野火應變任務上測試，最多包含 50 個異質代理程式，涵蓋八個 LLM。

相較於四種具代表性的固定結構基準組（CAMON、COELA、HMAS-2、Embodied），由人類設計的 ORCH 階層將最終分數提升 63.97%，執行效率提升 74.29%；由評論者監督的 LLM 產生階層，則將相同指標提升 43.63%／52.53%。這項增益與使用哪一個八種 LLM 並無顯著交互作用（Type-II ANOVA），因此並非某一個模型的特例。

**直接對照上文「提示版本沒有造成太大差異」的結果，兩者呈現相同分野——機制勝過文字——而且在第二個領域重現。**Anthropic 的 CEO 階層與指定角色條件，是疊加在其他方面維持扁平的蜂群迴圈上的文字；ORCH 的水平與垂直管理者則是不同的規劃功能，並設有強制階段閘控（垂直管理者會等到滿足該階段完成條件後，才發出下一階段任務），而且每個計畫定案前都必須經過異議與修訂步驟。這裡沒有對同一系統進行受控消融——ORCH 從未測試自己 harness 的純文字版本，Anthropic 也從未在遊戲蜂群上測試結構式階層——因此兩者是相互印證，而非直接定論；但現在已有兩個領域（軟體產物蜂群與具身野火應變）指向相同方向：改變結果的是經過設計的結構，而非一句角色描述。

完整分析包括水平／垂直管理者的形式化定義、評論者與否所造成的結構品質梯度，以及失敗模式的轉變（工作者執行失敗從 51–65% 降至 13–21%，任務分配失敗則相應增加），請見任務專屬的組織階層。

一位操作者抵達上限，且明確說出上限在哪（DHH，2026 年 8 月）#

上文所有測量都是對群體的遙測。DHH以第一人稱經驗呈現相同曲線，並提供他看得到的數字（Lex Fridman #501、2026-08-26、practitioner-opinion、自述）：

• 約 16 條並行執行緒，分散在四到五台實體機器上——放在壁櫥裡的 mini-PC，每台配一個 GL.iNet Comet KVM，並連入同一個 Tailscale 網路。「這就像我發現了多核心程式設計，但我只有兩個核心……如果我有 16 個核心呢？」
• Herdr——tmux 加上每個代理程式的完成通知——作為監督層，因為代理程式分散在多台機器上後，光靠 tmux 分割窗格就無法擴展。基本單位是通知，而非窗格：操作者是被打斷，而不是主動查看。
• 限制資源被直截了當地指出：「我發現人在迴圈中才是這裡的限制。」不是 tokens，也不是機器。這就是上方 p99 並行數據所暗示、卻沒有任何一項測量的相同上限。

依他的說法，為何單一代理程式會打斷工作流。「代理程式同時太快又太慢」——比打字慢，卻又比一件你可以切換出去處理的任務快。只有一個代理程式時，操作者會閒著；那種感覺「不像有效率……反而真的覺得自己有點沒用」。平行處理則藉由讓決策總是待處理，恢復了心流。這是關於操作者感受的主張，值得與吞吐量區分：它解釋了為何實務工作者會把工作分流到超過上方所測協調成本開始造成影響的程度。

他正在打造的退出方式，不是增加平行處理。碰到人類上限後，他改往相反方向前進——AmaBot，一套定時執行的自主系統，會自行處理 Omarchy 的議題與 PR，並且每天寄一封合併／關閉決策摘要給他。「最後我就可以每天看一次那封電子郵件，然後每天做一次決策。我們還沒到那裡，但我想我們會做到。」他也提到 37signals 正在試驗讓代理程式擔任 Basecamp 待辦事項的受派者，理由是以聊天為形態的 harness 並不合適：「聊天……不是正確的形式，因為你坐著等。它會誘使你坐著等。」非同步的工作追蹤工具則不會讓人期待立即回覆。這兩種做法都把並行視為同步介面的症狀，而非目標。

以情境管理而非技能來證成角色專業化（Martin，2026-08）#

本文多數按角色分工的流程，都是從勞動分工角度提出論據。Robert C. Martin則採用五角色關卡，並以完全不同的理由支持這種做法（AI 時代的軟體基本原則——Uncle Bob、2026-08-19、practitioner-opinion）——設置角色是為了讓每個情境視窗維持精簡，也避免每次工作階段的方向受到污染，而不是因為某個角色比其他角色更擅長自己的工作。

階段	產出
規格撰寫者	人類文件 → Gherkin 驗收測試 + 以人類視角編寫的 QA 程序
程式撰寫者	單元測試加上實作；讓 Gherkin 測試通過
清理者	複雜度／涵蓋率分析與一般性審查；清理程式撰寫者留下的混亂
強化者	透過變異測試達到 100% 涵蓋率——「毫不留情」
QA	將 QA 文件編譯成可執行、能驅動 UI 並產生確定性結果的指令碼

他提出的優點都關乎情境，而非能力：「當你讓代理程式專注於單一任務，就能控制情境視窗。『中間部分遺失』的問題會小很多，因此你可以在頂端多加幾條規則，它們也更容易遵守。你也可以建立一套系統，讓代理程式誕生、完成任務、然後消失，這樣下一個代理程式就會帶著乾淨的情境進場。」Matt Pocock在同一段對話中提出更精準的說法——工作階段早期就會形成一條軌跡，之後便沿著它前進，因此實作者的「先讓它能動」和強化者的「達到 100% 涵蓋率」是互不相容的方向，無法共用同一個視窗（Context Window Smart Zone）。

成本，皆為自述且未測量。每個代理程式的啟動成本是 10–15 秒，「接著它還得重新弄清楚整個情境」——本文其他地方以合併衝突計價的協調成本，在此則以冷啟動而非合併衝突支付。從頭到尾，一件單一代理程式五分鐘就能完成、但結果不太可靠的任務，交給整套關卡需要大約一小時；人類則要半天：「生產力提升四倍、五倍。」他也提到正在嘗試代理程式彼此交接任務，「其中的溝通成本高得不得了，但 token 數仍比人類少得多，速度也還是比較快。」

有兩點值得保留。平行處理幾乎只是附帶一提——他提到一次跑三個程式撰寫者，而且筆電還能支援更多，但依他的說法，這套關卡的價值在於循序執行，每個階段都縮小下一個階段可能出錯的範圍。而「誕生、完成任務、消失」的形式，則是 harness 對本文通常視為情境管理問題的限制所提出的解法；這使它成為一個案例，說明Context Window Smart Zone與編排設計其實是同一項決策。

四層自主性分類，且每層各自設置升級閘門（Uber，2026-08）#

上文每種 harness 都以並行程度或執行時間衡量——一個人監督多少個代理程式執行個體。Uber 對軟體工廠的描述（Medisetty，2026-08-27、case-study）提供另一個軸線：四層代理程式使用方式，依操作者對成本、品質與模型選擇保有多少控制權排序。從專門化程度最高到最低——具名的受管理代理程式，每個 SDLC 階段各一個（Minion：意圖→PR；uReview：PR→審查；Agentic XP：XP 完成→讀取報告；Conan AI：警示→AI RCA；Fawkes：cron→維護），每個都描述為「代理程式驅動 + 人在迴圈中」，並以各自的成果單位計價（每個合併 PR 的成本、每次審查的成本、每個警示的成本、每次清理的成本）——接著是通用互動式代理程式（每次查詢的成本）、使用 3,600 多項共享技能的互動式工作階段（每個工作階段的成本），再到沒有任何鷹架、也「沒有任務邊界」的原始工作階段。介紹明確指出最高層級日常處理的工作：自動化代理程式執行程式碼審查、自我修復 CI 失敗、具視覺驗證的端對端 PR、值班分流及程式碼維護，「並由人類審查／升級處理」。

這不是本文其他地方追蹤的並行軸線——它是 N 種代理程式，各自有更窄的任務邊界，也相應擁有更窄、成本更低的審查範圍，而非一個人監督 N 個同類執行個體。升級閘門依層級移動，而非依代理程式數量移動；Uber 表示，某一層的任務越窄，就越能在固定模型上進行基準測試並作 Pareto 最佳化（完整成本公式與 Pareto 基準分析見每任務成本優先於每 token 成本）。沒有任何層級提供人類審查成本的金額——人在迴圈中只是最高層級的一項設計屬性，並非已測量的額外成本——因此這種分類釐清了逐層監督的形式，卻沒有提供本文監督負荷未解問題所需的數字。

**值得對照上文模型選擇各節保留的一項槓桿：**Uber 預設讓子代理程式使用較弱、較便宜的模型，因為子代理程式的任務定義明確，不需要前沿推理；主要模型則負責分解任務與評估結果——這和Willison上方自我委派提示中的做法相同（「誰來挑選模型」），只是把個別實務工作者的指示提升為全組織預設。

延伸閱讀#

• 每任務成本優先於每 token 成本 — 同一來源的完整成本公式、uReview 明確的 Pareto 生產點，以及其餘降低 token 的槓桿清單

• Robert C. Martin（Uncle Bob） — 五角色關卡；角色邊界以情境管理與軌跡而非專業分工為依據

• 讓不切實際的品質工具重獲新生 — 清理者與強化者實際執行的工作

• 自動化失敗歸因 — 將上方的除錯假設量化：多代理程式文字軌跡中的代理程式辨識率為 48–57%，超過 12K tokens 後步驟準確率減半，而協調錯誤類別會系統性地被重新標記為推理錯誤——這是在現有最有利條件下測得（一個注入錯誤，其餘執行已知成功）

• Orchestration Sets Token Economics — 以兩種方式計算委派成本。當代理程式共享逐字稿時，它是token 倍增器：每個參與者都得重讀持續變長的對話，並攜帶自己的角色前言；因此 Writer 引用 Anthropic 自己的數據——代理程式的聊天 token 用量約為 4 倍，多代理程式系統約為 15 倍，而 token 數量可解釋其研究評估中約 80% 的效能差異——並稱共享逐字稿的多代理程式協作「天生就是 token 倍增器」。當子代理程式的情境範圍受到限制時，它則是情境防火牆：回傳內容限制為 8 KB 的摘要，引文放在主模型不會讀取的 metadata sidecar 中，委派深度有上限，重試時具冪等性，因此委派探索不會使主迴圈膨脹。同一篇論文發現，在六個模型中，委派只有在最強的兩個模型上才達到可用的可靠度門檻（0.85–0.86；快速級模型為 0.42–0.45）——這是基本機制本身的能力下限。由供應商撰寫，COI 總計為 100%

• 情境生命週期管理 — 協調成本落點：接收端呼叫的情境預算內，與任務證據競爭有限視窗。該頁完整說明 RCWT 的兩項實驗（固定預算懸崖與任務完整性虛無結果）、剩餘預算參數 θ，以及不同任務家族間約 3.5 倍的差距；並提出一般情況——一個呼叫的視窗會同時被代理程式自身累積的歷史以及編排層注入的協調內容占用，只有後者在編排者的直接控制範圍內

• Claude Opus 5 — 第一份把多代理程式 harness 當成能力進行基準測試的系統卡：10 個代理程式的團隊在 BrowseComp 上達到 93.6%、延遲加快 5.6–5.9 倍，並承認安全面仍有多代理程式落差

• 角色平均化，而非消除角色 — 「IC 管理代理程式」的具體實踐：由平均化角色執行的代理程式群組

• 共享 Harness，差異化介面 — 這種邊際能力的產品化及其限制：OpenAI 的 Ultra（多代理程式模式）上線後被移到進階設定中，因為它會消耗速率限制；子代理程式逐字稿預設隱藏——面向大眾推出的並行功能，是使用者大多看不到的並行功能。Akshay Nathan 依任務型態提出的準則（多代理程式模式適合「極其複雜、像開放式探索，或高度可平行化」的工作，「但大多數任務都不屬於這兩類」），是供應商對何時不需要這種前沿工作流程的說明（practitioner-opinion，沒有測量數據）

• 從對話轉向委派 — 並行與執行時間是該研究用來衡量委派深度的三種「如何」邊際能力中的兩種（另一種是系統化）

• Agentic Work Systematization — 彼此相鄰的能力邊際；可重用技能讓平行／可重複的委派更易管理，因此能同時執行多項工作

• 創辦人作為代理程式編排者 — 本文量化的質性角色：創辦人／工作者作為眾多專門代理程式的編排者；此處則提供最初的並行／執行時間採用數據

• 身為 IC 的經理 — 執行一群代理程式，是 IC 成為經理的具體形式：高強度使用者管理、委派工作並審查一組代理程式工作者

• 驗證成為新的瓶頸 — 平行分流受人類審查能力限制；並行會讓監督瓶頸成為決定性限制

• 迴圈工程 — worktree + 子代理程式是安全平行處理的基本工具；「決定你能同時執行幾個代理程式的，是審查頻寬，而非工具」正是本文指出的上限

• 開放式探索 Harness — 當隔離是目標而非成本時採用分流：每個代理程式各用一個 git 分支和 worktree，避免競爭中的方案被互相還原；編排者在每個深度調整寬度，而非固定採用 (n, k)；研究發現固定組態中最寬的那種永遠不是最佳選擇。這也是反駁 Bun 拒用 worktree 的案例——當平行輸出是不同選項而非整體的不同部分時，每個代理程式各用一個 worktree 才能擴展

• Multi-Agent Collective Intelligence — 架構面（代理程式彼此協調）對照本文的使用面（一個人協調多個代理程式）

• 編排計畫模擬 — 本文供應商證據所欠缺的測量：刪除工作者、只對編排計畫評分的基準測試，呈現情境限制的交叉點、逐漸飽和的代理程式預算，以及在 100 個子任務規模下，代理程式數量與品質無相關（-0.021），轉移涵蓋度仍能預測品質（0.614）的發現。這也是外部唯一一次測量Claude Code 的動態工作流程，並將它用作真實執行組

• 動態工作流程：代理程式代數 — 系統卡中手工打造 harness 的產品化版本：Claude Code 的動態工作流程會讓模型撰寫多代理程式編排程式（Bun 沙盒中的循序／平行組合器），由「使用工作流程」觸發；Bun Zig→Rust 移植是已發布的方法論，也是本文 64 個代理程式限制條件的來源

• 最佳化器與評估器解耦 — Cursor 蜂群的審查面：堆疊彼此不相關的觀點，而非仰賴一位完美審查者；將「允許審查者看見什麼」納入設計軸線，並直接提出經濟論據（「審查的成本遠低於它所稽核的工作」）

• 每任務成本優先於每 token 成本 — 同一批四次 Cursor 執行的經濟效益：模型組合不同、品質相當，總成本卻相差 8 倍；只因負責規劃的對象不同，工作者支出就從 $9,373 降至 $411

• Client-Side Agent Optimization — 規劃者／工作者分配是複合抽象，Cursor 在四小時的正式環境建置而非基準測試上執行；該蜂群也透過設計移除了使 Opus 成為 HotpotQA 最差規劃者的失敗模式（此處的規劃者無法實作）

• Agent Context Files — Cursor 蜂群中的兩種協調機制是情境檔案：相依程式碼會帶著指回共享設計文件、經過編譯檢查的參照；另一種是每個代理程式都擁有、啟動時自動注入的 Field Guide

• Scale-Dependent Prompt Sensitivity — 為何比較中少了一個模型：GPT-5.6 Sol 因對字面措辭與強調措辭敏感而未納入測試，會產生「其他模型都沒有的失控循環」——過度思考在長時間執行的代理程式中變成無限執行

• Cursor — 供應商本身，以及如何看待其第一方蜂群主張

• AI 腦力耗竭 — 監督多條平行工作流的認知成本；限制每個人能擴展到多大並行規模的監督疲勞上限

• 規劃／執行分工 — 並行處理意味著人類保留規劃／協調角色，同時將執行工作分散給代理程式

• 可配置的人類參與 — 與本文使用遙測資料相對照的受控基準測試：改變一個人參與的方式（時機／管道／權限），發現效益不是單調變化——這是本文監督負荷未解問題之下的設計空間觀點

• Engineer PM Convergence — 並行編排工作流程是使用數據中 IC 朝管理／PM 角色匯流的表現

• Task Time-Horizon Scaling — 長時間執行的單一代理程式（執行時間邊際能力）位於 METR 逐漸上升的可靠任務長度上限之下

• OpenAI — 其內部使用情況是高並行工作流程的前沿預覽

• Codex — 本文所測量的執行緒互動工具及其並行能力

• AI-Native Startup Lifecycle — 這為 20–50 人規模的工程領導力增添第二個面向：「管理編排 AI 撰寫程式碼的系統」，而非管理撰寫程式碼的人；據稱這種人才極為少見

• Agent Behavioral Homogeneity — 為何 30 個代理程式的蜂群會產生 18 個相同分支名稱，而共享工作佇列會接受 240 萬個請求中的 117 個：情境、鷹架與底層模型是區分代理程式的全部因素，因此每個代理程式會同時找到相同的好捷徑與壞捷徑。這說明了為何分流不會讓錯誤自行平均消失

• Multiagent Turf War — 與合併衝突無關的分流失敗：在 Claude Code 中，彼此代理程式持有來自不同主事者的矛盾指令，且擁有真實 root 權限，最終升級為帳戶鎖定與偽裝的終止迴圈。本文測量的並行處理假設所有代理程式都為同一個人工作

• 軌跡內平行規劃（SPRINT） — 比本文低一層的平行處理：不是一個人管理多個代理程式，而是單一模型在單一答案中執行彼此獨立的步驟；透過訓練而非編排實現。只有一個情境，因此沒有協調成本，但有落後分支成本——每一輪都要等最慢的分支

• DHH（David Heinemeier Hansson） — 明確指出上限的具名操作者：五台機器上約 16 條執行緒，以 tmux 加通知進行監督，結論是解法在於非同步摘要，而非增加並行處理

• 以工單驅動的代理程式編排 — 在聊天回合之外派送代理程式的另一種機制：Symphony 從工單佇列提取工作，Cursor Projects 則訂閱 Slack／排程／PR 事件訊號並推送工作；兩者都讓派送與同步提示脫鉤，但尚未在同一項任務上相互比較

• 任務專屬的組織階層 — 在具身領域重現機制勝過文字的分野：不同的水平／垂直管理者類型與強制階段閘控，勝過四種固定結構基準組 63.97%／74.29%；而本文的 CEO 階層／指定角色提示文字套在扁平蜂群上則「沒有造成太大差異」

待解決的問題#

• OpenAI 的 p99 執行時間為每天 71 個代理程式工時，是在格外有利環境下呈現的前沿預覽。當阻力降低時，外部使用情況中的並行程度是否真的會趨近這個數字？還是大量平行處理只出現在與模型密切相關的工作中？
• 加總重疊的執行時間可能超過每天 24 小時——它測量的是代理程式投入的心力，不是人類的注意力。每個並行代理程式實際增加多少人類監督負荷？負荷會在哪裡飽和（AI 腦力耗竭）？更精確的問題：HAS-Bench重新界定了負荷的形式，而非測量負荷本身——在受控（由 LLM 模擬）的基準測試中，人類輸入的價值取決於設定，而且不是單調變化（時機／管道／權限恰當時才有最佳點；自主性提高後，報酬遞減，有時甚至帶來負效益）；因此每個代理程式的監督成本可能呈現有峰值的報酬曲線，而不是碰到牆之前都線性增加的成本。但該基準測試是單一人類、單一任務，所以無法測量真實並行監督負荷。
• 並行程度的測量期間為一週。管理 5 個以上代理程式是穩定做法，還是只在特定大型任務附近短期爆發？
• 真實協調內容是否像合成範本一樣占用任務預算？RCWT 的區塊只是角色／協定文字、代理程式訊息、共享命題與工具結構描述的一種手寫組合，而且它與評分的若干事實主題重疊；而本文記錄的協調流量則是密集的工具輸出、冗長逐字稿、設計文件與互相矛盾的代理程式主張。可驗證的做法是：用真實多代理程式軌跡中的協調區塊（Bun 的 worktree 分片、Cursor 的蜂群）重跑固定預算測試，將內容類型與 token 數量分開變動，並檢查懸崖是否仍落在相同的剩餘預算位置。若保留預算取決於內容，「測量任務的剩餘預算」就還不是可通用的規則。
• Claude Code 已發布的分流預設值（每個工作階段 200 次生成、並行 20 個、少於 15 個工作流程代理程式、深度 3）只有數值，沒有理由或測量依據。這些值是否對應 Anthropic 曾測量的任何內容——例如失控迴圈發生率曲線、品質與代理程式數量關係測試——還是只是為了限制某種病態行為而選的整數？這個問題尚未解答之前，本文中的產品與研究趨同仍只是趨同。(觸發條件：Anthropic 發布遙測數據或限制值的理由，或第三方如同OrchBench在模擬中所做的方式，對同一套 harness 測試不同代理程式數量。)

資料來源#

• 具身 AI 中的組織原則如何促進集體智慧 — Ji、Hyun 與 Chen（Duke），arXiv 2609.11737，2026-09-10，empirical。此處引用其水平／垂直管理者機制，以及相較基準的整體提升幅度，作為第二項跨領域佐證：影響協調成果的是結構性階層，而非角色提示文字。完整討論見任務專屬組織階層

• DHH：程式設計的未來、AI、代理式工程、Vibe Coding 與 Linux｜Lex Fridman Podcast #501 — DHH、Lex Fridman #501（2026-08-26，practitioner-opinion，自述）：透過 Herdr 與 Tailscale 在 4–5 台機器上執行約 16 個執行緒；「人在迴圈中就是瓶頸」；一個代理程式打斷工作流的「太快也太慢」說法；AmaBot，以及聊天並非正確互動形式的論點

• 邁向代理式 AI：來自 Codex 的證據 — §5.1「回合並行」；§5.2「長時間執行的代理程式」；§6 結論

• Claude Opus 5 System Card — §8.11（多代理程式 BrowseComp 與 ProgramBench；N 代理程式團隊與非同步子代理程式 harness；延遲／成本方法，以及發布前設定的注意事項）。解析風險：此 PDF 的原始 markdown 會錯置表格列——在 §4 安全防護表（4.1.1.A、4.2.B、4.3.1.B、4.3.2.A、4.4.2.B、4.4.3.B）、§5.1 代理式安全表（5.1.1.A–5.1.3.A）以及表 8.13.6.A 中，模型名稱會落在數值欄位裡；若照字面讀取某一列，就可能把一個模型的分數錯配給另一個模型。此處引用的數值已於 2026-08-03 對照 PDF 核實，並有正文或圖表佐證；引用原始 markdown 中的表格列前，務必先核對 (2026-09-05 使用 docling 2.126 重新解析：錯置數量由 24 降為 15；此處列出的表格仍須對照 PDF 核實後才能引用。)

• 以 Rust 重寫 Bun — Jarred Sumner，bun.com（2026-07-08，case-study）：「錯誤的起步」、「把編譯器錯誤當成工作佇列」、「更多錯誤的起步」、「統計資料」——4 個 worktree × 16 個代理程式的配置、git 命令拒絕清單、cgroup 隔離，以及 IOPS 上限

• OrchBench：透過確定性模擬獨立評估多代理程式協調計畫 — Ren 等人（arXiv 2607.25656，2026-07-28，empirical）：上下文限制掃描（表 6 與 19；從 16k 時的 +0.302 降至 128k 時的 +0.007；128k 時，單一代理程式在 82% 的模型—問題組合中領先）、代理程式數量上限掃描（圖 4），以及相較循序基準約 0.66 的 token 效率。工作者是模擬的——參見協調計畫模擬，了解這些結果所能界定的範圍

• Claude Code Changelog — Anthropic，Claude Code CHANGELOG（vendor-claim）。持續更新的文件，於 2026-08-03 擷取快照，範圍限於 v2.1.200–2.1.220；即時檔案之後已有更新，原始文件的 published: 刻意留白。僅有發布說明——沒有理由說明或測量數據。此處用於三項扇出上限（2.1.212 的每個工作階段啟動上限與 WebSearch 上限；2.1.217 的並行上限及 --max-budget-usd 強制執行）、啟動深度的反轉（2.1.217 關閉 → 2.1.219 深度 3）、少於 15 個代理程式的工作流程預設值（2.1.219），以及修正仍在執行中的代理程式回報虛構內容的問題（2.1.211）

• 代理程式群與新型模型經濟 — Wilson Lin，cursor.com（2026-07-20，case-study，廠商撰寫）：「代理程式的版本控制系統」、「每秒 1,000 次提交時的失敗模式」、「SQLite 實驗」、「深入探討執行結果」——提交率與衝突數據、五種協調失敗模式及其修正方法、crate 蔓生與引擎行數比較，以及保留測試集 sqllogictest 評分方法。網頁文章，沒有表格，也沒有解析出的圖表；所有引用數字均來自正文。初次擷取漏掉的兩則註腳（斜線柱代表單模型執行；GPT-5.6 Sol 因提示敏感度引發失控循環而遭剔除）已在匯入時對照原始 HTML 補回

• SwarmResearch：為開放式探索協調程式碼代理程式 — Virk、Edds、Xia 與 Zhang（UIUC），SwarmResearch: Orchestrating Coding Agents for Open-Ended Discovery，arXiv 2607.02807，2026-07-02，empirical。此處引用 §2.3（每個代理程式各自使用分支與 worktree）、§3.1 + §3.4 + 表 2（固定的 (n, k) 掃描、由協調器引導的比較，以及 +7.7% 的協調器 token 額外開銷），以及 §3.5（觀察到的波次規模約為 4–8 個代理程式；Shepherd 接近貪婪的預設行為，以及違反自身「不得預設想法」的防護條件）。表 2 已對照 PDF 確認無誤，並按解析結果引用；表 1 在原始資料中遭合併且錯置，本頁不予引用——復原後的 15 項任務比較見開放式探索 harness

• 多代理程式系統的模式與問題 — Anthropic Frontier Red Team，Patterns and problems in emerging multiagent systems，anthropic.com/research/multiagent-systems（建立於 2026-08-18，無署名，網頁上沒有發布日期；編譯時指定為 empirical——原始資料沒有 evidence: 欄位，且這是 Anthropic 對自家模型進行的第一方研究，未公開程式碼、提示或逐字稿）。此處完整引用「衡量協調」一節：45 個代理程式的漏洞搜尋群及其獨立平行基準（詳見由 LLM 驅動的漏洞研究）、12 小時奇幻遊戲的群體設計（每個代理程式各有一台 VM、共用論壇、自行託管的儲存庫）、三種提示變體及其無效結果、合併比例與程式碼共用指標的定義、世代模式，以及兩項實驗在相依結構上的差異。**解析備註：**此節的數值結果出現在圖表替代文字與說明，而非正文或表格——80 個代理程式時的 876／980 個 PR 數，以及「合併比例隨群體規模增加而下降」的趨勢，都是從圖表推估且屬約略數值；正文則提供世代排序與指標定義

• RCWT：衡量 LLM 呼叫中協調內容造成的任務預算排擠 — Lelis 與 Cabral-Carvalho（CloudWalk, Inc.），RCWT: Measuring Task-Budget Displacement from Coordination Content in LLM Calls，arXiv 2607.12216，2026-07-13，empirical。此處僅用於協調成本的論述：§1（任務預算排擠及不納入的工作階段動態）、§4.1 + 表 A1（W = 4096 時的固定預算斷崖）、§4.3（完整任務消融測試的無效結果，比例為 0.95）、§5.3–5.4（成本而非效益、協調差異）。表 A1 已對照 PDF 確認無誤；表 2 在解析時儲存格遭合併，本頁不予引用（復原後的逐探測值見上下文生命週期管理，該文提供完整數值分析）

• AI 時代的軟體基本功：Uncle Bob 專訪 — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：規格撰寫者／編碼者／清理者／強化者／QA、誕生—工作—消亡的上下文、每個代理程式 10–15 秒的啟動時間、相較半天人工作業基準，約 5 分鐘 → 約 1 小時。所有數字皆為受訪者自述的印象

• 在 Uber 規模下高效營運軟體工廠 — Uday Kiran Medisetty，Uber Engineering blog，2026-08-27（case-study，第一方）：四層代理程式分類（從具名管理代理程式到原始工作階段），以及將子代理程式預設為較弱模型的調整手段。完整成本方程式分析見任務成本高於 token 成本；各來源備註見來源章節

• Introducing Projects — Alexi Robbins 與 Fredrika Lindh，Cursor blog，2026-09-10（vendor-claim，廠商撰寫，無獨立稽核）：單一協調器／子代理程式的配置、預設使用雲端並提供本機退路、跨機器共用的上下文檔案組、訂閱項目（Slack／排程／PR 事件），以及 30%／6× 的 PR 合併數據——此數據由廠商以 Cursor 自行挑選的用戶群衡量，沒有對照組。完整的實體端分析見Cursor；各來源備註見來源章節