CourseFoundry 技術筆記

Codex 多代理什麼時候值得拆？用可重做實驗做決策

發布日期：2026 年 11 月 1 日 · 約 6 分鐘閱讀

多代理可以平行處理彼此獨立的工作，但新增代理也會增加協調與整合工作。要判斷它是否適合某個任務，先固定輸入和驗收標準，再確認執行紀錄裡真的出現委派。

用五步比較，不先假設多代理比較快

1

固定任務、輸入和驗收規則

選一個範圍小、可以完整重跑的任務。保存輸入版本或雜湊、輸出格式、不可違反的限制，以及同一份人工可判讀的品質 rubric。每次改動都記下原因。

2

建立單代理基準

先讓一個 Agent 完成任務，記錄符合 rubric 的項目、漏項、重試、人工修正和總時間。基準不穩時，先改善任務規格，不要用多代理掩蓋它。

3

只拆真正獨立的子任務

為每個 worker 指定不同的輸入範圍、交付物和限制。短小或前後相依的工作留給主 Agent；需要共同修改同一份檔案或狀態時，先設計協調方式。

4

確認 runtime 實際建立了 subagent

提示詞寫了「請分工」不代表已經委派。Agents API 的事件串流會以 agent.session.subagent.created 回報 subagent 建立；再讀回 session 中的 subagent 與各自結果，核對每份輸出對應的輸入和負責範圍。

5

用相同 rubric 評分並計入全部成本

把兩種方式放在同一套品質標準下比較，並記錄重試、人工修正、時間與可讀回用量。計入主 Agent、subagent、重試及工具／執行環境費用；不完整的用量資料要標成未知。

合成情境：檢查三份互不相依的設定檔

假設有三份匿名合成 JSON 設定檔，各自檢查四個欄位：必填鍵、資料型別、允許值、與來源規格的一致性。兩種做法都用同一份 rubric，主 Agent 最後都必須整理出檔名、發現、依據與未確認事項。

設計要保留的證據可得出的結論
單代理依序檢查三份檔案每個檔案的檢查結果、對應規格與 rubric 評分。建立這個任務的單代理基準；不能推論其他工作也適合單代理。
三個 subagent 各檢查一份檔案，由主 Agent 整合建立 subagent 的事件、各自的任務／結果讀回，以及主 Agent 的整合結果和同一份 rubric 評分。若缺少委派事件或某份結果，就不能把這次執行算作已驗證的多代理實驗。
這是流程示意，不是效能測試。沒有實際執行紀錄就不填分數，也不能從任務彼此獨立直接推斷多代理一定更快或更省。

可複製的實驗紀錄表

每次重跑都留下一列。輸入、rubric 或環境不同時，另開紀錄，避免把不同條件的結果混在一起。

任務與輸入版本／SHA-256：
執行日期、模型與環境：
驗收 rubric 版本：

方式（單代理／多代理）：
品質符合項目／總項目：
遺漏、重試與人工修正：
總執行時間：
委派事件與 subagent 結果讀回：
Recorded usage（未知時填未知）：
未計入或未知的成本：
決策（採用／維持單代理／停止）與依據：

用量和成本資料的邊界

Agents API 的 session 與 turn usage 是 best-effort 記錄；值可能尚未到齊、之後改變，或在未知時為 null。空值不是零，也不是最終帳單。成本評估還要涵蓋 root Agent、subagents、每次重試、工具呼叫和適用的 sandbox／第三方費用。

同一任務要重做數次，記下每次的差異與失敗。只有在這個任務的品質達標，且時間、資源與成本都足以核對時，才決定保留多代理方案；單次結果不能代表一般效能。

先維持單代理或停止拆分的情況

遇到這些情況，先縮小任務、補齊觀測或改善單代理規格。若你正在整理 AI 新聞，也可參考來源查核與摘要驗收流程。

官方文件