單一通用代理程式 vs. 多代理程式編碼架構

問題#

單一通用編碼代理程式，是否勝過配有專職測試、QA 與清理代理程式的多代理程式架構？（來自 Agent Harness Engineering 的未解問題）

簡答#

這種說法是非此即彼的錯誤二分法。「多代理程式」把兩種專業化混為一談，而語料對兩者的趨勢正好相反：

專業化若是用來編碼手工設計的任務結構（量身打造的訓練子模型、僵化的編排狀態機），模型進步後，單一通用代理程式會迎頭趕上並超越它。這就是 The Bitter Lesson。
專業化若是提供上下文隔離或評估獨立性（使用全新上下文的審查者、隔離的探索者、與製作者不同的評分器），就不會隨著模型變好而消失，因為它處理的是結構性限制（二次注意力、Goodhart's law），而非模型弱點。

因此：單一通用代理程式勝過量身打造、手工調校的多代理程式系統，但單一整體式上下文代理程式會輸給角色分離的架構。勝出的架構，是將一個強大模型部署在許多全新上下文中（探索 → 解題 → 審查 → 合併），並搭配獨立評分器，而非由各角色專屬訓練元件組成的量身打造流程。

支持「單一代理程式終將超越」的論據——苦澀教訓#

The Bitter Lesson：隨著時間推移，擴展通用方法會勝過手工設計的結構；結構會變成天花板，而非基礎。語料中最明確的實證佐證來自形式數學（Agentic Loops Overtake Bespoke Systems）：

DeepMind 選擇了精密的全功能代理程式（演化搜尋 + 量身打造、經 RL 訓練的 AlphaProof 證明器），用於大規模探索，因為在規劃階段「較簡單的代理式迴圈未展現強勁表現」。
事後比較發現，基本型代理程式——各自執行簡單的產生－編輯－編譯「Ralph loop」的獨立證明子代理程式——解出了全功能系統解出的全部 9 道 Erdős 問題，只是在最難的兩題（#125、#138）成本較高（2×–5×）。
結論：在大多數問題上，專用設備帶來的優勢「縮減成成本差異，而非能力差異」，作者甚至指出這點殘餘優勢的期限：「隨著 LLM 能力增長，這項優勢可能會減弱。」

編排層也有相同趨勢：Symphony 起初把代理程式當作僵化狀態機的節點（Codex 只能實作工單），後來發現「模型能力提升到一定程度後，這種做法限制太多」，於是改為**「目標 + 工具，而非狀態轉移」**（Agent Harness Engineering）。Harness Shrinkage as Models Improve 將這個結論推廣到更廣的情況：用來彌補模型弱點的腳手架，在模型變強後就會變成負擔——每次模型發布都要重新評估量身打造的結構。

但這項結果有兩個前提——這不代表「單一代理程式總是勝出」：

需要足夠強的模型 + 便宜且可靠的驗證器。獨立的 AlphaProof 樹狀搜尋和較小模型的基本代理程式都毫無成果；讓簡單迴圈可行的關鍵，是 Lean 編譯器對每一步進行驗證（The Verifiability Thesis）。可轉移的原則是：若某個領域有便宜且可靠的驗證器，就優先採用能善用它的最簡單迴圈。
在驗證器有雜訊的領域（測試、LLM 評審團）中，這個問題仍未解決；來源本身也指出了這項未解問題。

支持角色分離的論據——哪些做法不會消失#

能在模型進步後留存的多代理程式模式，其專業化基礎是上下文／角色，而非任務先驗。以下三種模式各有佐證：

1. 上下文隔離不受模型影響#

Repository Exploration Subagent（FastContext）提供了決定性的測試。它的**「同模型探索」**基準——由前沿模型本身透過子代理程式介面執行委派搜尋，不經任何專門訓練——相較於整體式解題，已能提升解題率，並減少主代理程式最多 60% 的 token。接著，經訓練的 4B 探索者又帶來 Pareto 改善，但：

「架構上的分離才是持久的勝利；受訓模型只是最佳化。」

探索約占解題器工具使用回合的 56%、token 的 46%；將探索移出解題器的上下文視窗，就是收益所在，與是否使用量身打造的模型無關。Deep Modules for Agents 說明了其機制：Context Window Smart Zone 的智慧區域限制是結構性的（二次注意力），所以在全新上下文中的審查者能在智慧區域推理，而同一上下文中的審查者讀取差異時則落在遲鈍區域——不論模型大小。其 Sandcastle 模式（Planner → 工作樹中的 N 個 Implementers → 使用全新上下文的 Reviewer → Merger）正是為了讓每個代理程式都有自己的智慧區域。

2. QA／審查者之所以不可或缺，正是因為它獨立存在#

Optimizer–Evaluator Decoupling：「提出變更的東西絕不評分該變更。」代理程式若反覆針對自己計算的指標進行調整，最終會學著鑽分數的漏洞，而非達成目標——這是開發迴圈中的 Goodhart。這是結構性修正（移除最佳化器存取評分結果的途徑），而非會逐漸縮減的腳手架。維基記錄了多方獨立得出相同不變條件——Google 的飛輪、Osmani 的製作者／檢查者、迴圈工程的獨立停止檢查者、DRACO 的互斥評審者——這證明它是真正的不變條件，而非單一供應商的偏好。因此，問題中所說的「測試／QA」專業化，正是應該維持分離的部分。

（同一頁的注意事項：解耦帶來的是獨立性，而非正確性——獨立評審者仍可能穩定地判錯，例如一致性－偏誤悖論；如果最佳化器自行撰寫評分規準，指標設計仍然是耦合的。）

3. 「清理」角色是真實且反覆出現的工作#

Agent Harness Engineering：OpenAI 起初把20% 的工程時間花在手動清理「AI slop」上（代理程式會複製既有模式，包括不良模式）。解法是一個專門且持續執行的角色——背景代理程式負責掃描偏差、評估品質，並提出針對性的重構／文件整理 PR——持續「垃圾回收」以償還技術債。專責清理的代理程式與解題器並不重複。

綜合比較，見下表#

「專業代理程式」類型	編碼的內容	苦澀教訓的判定	保留嗎？
量身打造的訓練子模型（例如 AlphaProof 證明器）	任務先驗／領域結構	優勢 → 只剩成本差異 → 隨模型進步而變成負擔	僅適用於不斷前移的艱難前沿；每次發布都重新檢查
僵化的編排狀態機	手工編寫的控制流程	被「目標 + 工具」超越	不要——提供目標，而非狀態轉移
隔離的探索者／搜尋子代理程式	上下文隔離	持久；不受模型影響的收益	是
使用全新上下文的審查者	上下文隔離（智慧區域）	持久；結構性（二次注意力）	是
獨立評分器／QA	評估獨立性	持久；結構性（Goodhart）	是
背景清理／文件整理者	持續管理熵	持久；持續存在的真實工作	是

實務上左右結果的三項注意事項#

驗證器是否可用，決定了上限。 完美的驗證器（Lean、可通過的測試套件）→ 高自主性，最簡單的迴圈勝出。有雜訊／沒有驗證器 → 保留獨立審查者與人工關卡（Agentic Loops Overtake Bespoke Systems、Verification as the New Bottleneck）。
多代理程式會把瓶頸轉移到你的審查頻寬。 平行分流受限於人類審查能力，而非模型產出能力——OpenAI 有 28.6% 的工作者曾同時使用 5 個以上代理程式；真正的限制在監督，而非生成（Parallel Agent Orchestration）。
依角色選擇模型，不要每個位置都用最強模型。 在探索者／規劃者的位置使用便宜、聽從指令的模型，在綜合／審查位置使用強模型。分析單位應是組合：Ministral 3 8B + Opus 在 HotpotQA 的得分為 74.27%，Opus + Opus 則為 31.71%（Opus 擔任規劃者時會繞過解題器的工具）（Client-Side Agent Optimization、Opus 4.6 → 4.7 Changes and Multi-Agent Coding Considerations）。

值得指出的一項張力#

Vibe Coding vs. Agentic Engineering（Ambrosino）認為，在前沿能力上，自主單代理程式開發已經超越編排式迴圈（「迴圈已經落伍一週了」），因而推向整體式代理程式；Deep Modules for Agents 和 Optimizer–Evaluator Decoupling 則主張角色分離。依照上述任務先驗與上下文隔離的界線，兩者可以相容：Ambrosino 預測會消失的是手工編寫的編排，而非上下文／評估上的分離——迴圈的控制邏輯會遷移到模型中；全新上下文的評分器則不會消失。

資料來源#

Agent Harness Engineering — 雙代理程式（Initializer/Coding）架構；20% 的 AI slop 清理 → 背景重構代理程式；Symphony 的「目標，而非狀態轉移」；本文要回答的未解問題
The Bitter Lesson — 擴展通用方法勝過手工設計結構；任務先驗與部署／上下文豁免的區別
Agentic Loops Overtake Bespoke Systems — 基本 Ralph loop 在 9/9 道 Erdős 問題上追平量身打造的 AlphaProof+演化系統；優勢縮減成成本差異
Deep Modules for Agents — Sandcastle 的 Planner/Implementers/Reviewer/Merger；使用全新上下文的審查者；智慧區域限制是結構性的
Repository Exploration Subagent — 「同模型探索」（未經訓練）已經勝出：架構分離是持久收益，主代理程式 token 最多可減少 60%
Optimizer–Evaluator Decoupling — 「最佳化器絕不評分自己的工作」；QA／審查者分離是一項結構性（Goodhart）不變條件
Opus 4.6 → 4.7 Changes and Multi-Agent Coding Considerations — 依角色選擇模型、使用全新上下文的 Writer/Reviewer、各代理程式的上下文預算
Parallel Agent Orchestration — 審查頻寬是平行分流的主要限制；採用並行作業的數字
Client-Side Agent Optimization — 組合選擇；Ministral+Opus 得分 74%，Opus+Opus 得分 31%
Harness Shrinkage as Models Improve — 用來彌補模型弱點的腳手架會變成負擔；每次發布都重新評估
Verification as the New Bottleneck — 為何獨立審查者步驟能持續發揮作用