昨天的文章最後留了一個問題：已經有固定流程和一個受限代理了，需不需要再加第二個代理？
這個念頭很合理。第一個 AI 負責找資料，第二個 AI 負責挑錯，聽起來比一個 AI 自己做、自己檢查可靠。流程圖也會立刻變得很像一套完整系統。
但多一個代理，不是多放一顆按鈕。它會多帶一份上下文、一次交接、一組權限和幾條新的失敗路徑。如果沒有先說清楚第二個代理要補哪個缺口，最後很容易只得到一張比較熱鬧的架構圖。
所以 Day 24 不急著組一支 AI 團隊。我想先做一次架構裁決：拿同一個內容工作，攤開固定流程、單一代理與雙代理各自要付的代價，再決定手上的證據夠不夠支持升級。
先講結果。目前的判決是：先不加第二個代理。
不是因為雙代理已經輸了。我根本還沒有一場公平的三方實驗。現在選擇固定流程，代表證據不足，不代表固定流程永遠比較好。
下面直接拿 Day 22 的三來源查核當同一張考卷，看看三種架構到底要怎麼比。
今天沿用 Day 22 的例子。
內容流程要同時讀三份來源。其中兩份是必要來源，一份可以降級。三路結果回來後，系統要交出同一種 merge-decision.v1：資料完整是 complete，少了可選來源是 partial，必要來源缺失或互相衝突則是 blocked。
這份工作可以有三種做法。
固定流程最直接。程式事先知道哪些來源必要、哪些可以降級，也知道遇到衝突就停止。輸入相同，控制器應該走到相同出口。Day 22 的參考實作就是這一型。
單一代理會多一點彈性。它能在受限範圍內選擇先讀哪份來源、是否補查，最後提出一份合併決定。不過工具權限、合法出口和停止條件仍由外層程式控制，不能讓代理自己發明。
雙代理則可能把工作拆成研究者與查核者。研究者整理三路結果，查核者檢查缺漏與衝突，管理者再決定要不要接受。另一種做法是直接把控制權交給查核者，讓它接手後面的回合。OpenAI Agents SDK 的代理編排文件把這兩種形狀分成「代理當工具」與「交接」。前者由管理者保留最後答案；後者會移轉當前控制權。
這兩種雙代理架構不能混在一起算一組。誰看得到哪些上下文、誰能呼叫工具、誰負責最後輸出，都不同。
多代理確實有適合的工作。Anthropic 公開的多代理研究系統把一個廣度很大的研究題拆成多個可以獨立展開的方向，再由主代理整合。這種工作有明顯的平行空間：不同代理可以各查一塊，不需要一直共享同一份短期上下文。
內容產線裡也可能有類似情況。例如一個代理整理來源，另一個代理專門找反例；或是一個代理處理文字證據，另一個代理核對圖片與圖說。前提是兩份工作真的能分開，而且合併後能檢查。
反過來說，如果第二個代理只是把第一個代理的全文再讀一次，然後回答「看起來沒問題」，它增加的是模型用量，不一定增加證據。兩個代理得到同一個錯誤答案，也不會因為形成共識就變正確。
多代理研究也不是一面倒。EMNLP 2024 的研究在兩個特定資料集上觀察到，多代理討論可以減輕單一代理自我反思時的思路退化；作者同時把停止策略、適度對抗與評審公平列為問題。另一邊，ACL 2024 的研究在它測試的推理任務裡發現，提示與示例做得更好的單一代理，幾乎追上最佳多代理討論。
這些研究都不能直接替內容產線選架構。它們比較像兩個提醒：雙代理有可能補到單一代理的盲點，但比較之前，先把單一代理的基準做好，不能故意拿一個很弱的版本當陪跑。
假設固定流程讀的是昨天的來源，單一代理讀今天更新過的版本，雙代理又多拿一個搜尋工具，最後成績當然不能比較。
我把公平條件想成同一張考卷。
三種架構要拿到同一個任務、同一份來源快照、同一份作者答案與同一種輸出格式；可用工具、停止政策和總資源上限也要相同。單一代理與雙代理還要使用相同模型版本。任何一項對不上，就先回 not_comparable，不要急著排第一名。
最容易作弊的是預算。
假設單一代理最多能呼叫模型六次，雙代理的額度也應該是兩個角色合計六次，而不是每個代理各拿六次。工具呼叫與模型文字用量也要按整個架構合計。不然測到的不是「合作有沒有幫助」，而是「多花一倍資源有沒有幫助」。
本次合成政策用的上限是六次模型呼叫、九次工具呼叫與 6,000 token。這些數字只用來把裁決分支跑通，不是任何真實模型的成本紀錄，更不是我正式內容流程的預算。
還有三個很像、卻不能混用的狀態：
not_applicable：固定流程沒有模型版本，這個欄位不適用。not_run：單一或雙代理尚未執行。not_measured：流程可能執行過，但沒有保存這項量測。把三個狀態全部填成 0，報表會很好看，意思卻完全錯了。沒有量到成本，不等於成本是零；沒有跑模型，也不等於模型表現是零。
假設三種架構最後都交出一篇能讀的文字，只靠主觀挑選，很難知道第二個代理到底幫了什麼。
我把觀察拆成三本帳。
第一本記結果：作者答案命中多少、有沒有硬性失敗、無來源主張和錯誤完整度。第二本記資源：模型呼叫、工具呼叫和模型文字用量。第三本記流程成本：協調失敗、重複工作，以及有幾次要人接手。
這些資料不能急著揉成一個總分。假設雙代理多命中一項作者答案，卻新增一個無來源主張，總分仍可能被權重算成「進步」。但在內容產線裡，這種進步我不會接受。
所以這次的政策比較保守：先找出固定流程與單一代理中較好的基準；雙代理必須在事前指定的品質指標上嚴格改善，六項退步指標都不能變差，而且整體仍要留在共同預算內。品質打平就留在較簡單的架構。
const baseline = singleStrictlyImprovesFixed
? singleAgent
: fixedWorkflow;
if (dualHasAnyRegressionAgainst(baseline)) {
return keep(baseline);
}
if (!dualQualityIsStrictlyHigher(baseline)) {
return keep(baseline);
}
return proposeForHumanApproval(dualAgent);
注意最後一行是 proposeForHumanApproval()。即使未來真的量到雙代理比較好，控制器也只能提出換架構，不能直接替我改掉正式流程。
第二個代理帶來的不只有成本，還有新的錯法。
它可能重做第一個代理已經做完的搜尋，可能因為交接摘要少了一段來源限制而誤判，也可能在多輪討論裡慢慢偏離原題。每次交接的護欄範圍也要重新確認，不能假設入口檢查會自動罩住所有子流程。OpenAI Agents SDK 的護欄文件就把第一個代理的輸入護欄、最後輸出的輸出護欄，以及函式工具護欄分開說明。
問題漂移研究在十項任務的實驗設定中觀察到，多代理辯論會隨回合偏離原始問題；低品質回饋、缺乏進展與指令不清都是成因。Free-MAD則討論多輪共識帶來的模型用量、從眾與錯誤傳播。
這些論文的數字不能搬來當我的內容流程數據，但問題類型很有用。真正做三方測試時，不能只保存末稿，還要留下工具選擇、交接、停止原因與人工介入的軌跡。OpenAI 的代理評估指南也把結果評分與軌跡評分拆開；追蹤文件則列出模型生成、工具呼叫、交接和護欄等可記錄事件。
軌跡能回答「它做過什麼」，不能單獨證明「它做對了什麼」。正確性仍要回到來源與作者答案。
目前沒有同條件的真實模型紀錄，但我可以先測另一件事：如果資料真的進來，這套採用規則會不會做出自相矛盾的決定？
我準備了六組固定合成情境：
| 情境 | 裁決結果 |
|---|---|
| 三種架構都沒有受控執行紀錄 | 證據不足，維持固定流程 |
| 單一與雙代理使用不同模型 | 不可比較，維持固定流程 |
| 三種架構品質打平 | 選固定流程 |
| 單一代理改善，雙代理沒有再改善 | 選單一代理 |
| 雙代理命中較多，但硬失敗增加 | 拒絕雙代理，選單一代理 |
| 雙代理命中較多，且退步指標都未增加 | 若真實觀察成立，才提出雙代理 |
六組合成情境都走到作者定義的分支，結果是 6／6。這個數字驗的是裁決程式，不是固定流程、單一代理或雙代理的成功率。
其中一組甚至刻意讓雙代理拿到較高的品質命中數，但同時增加一次硬失敗。裁決器仍拒絕升級。另一組讓雙代理嚴格改善，而且沒有任何退步，才走到 would_adopt_dual_if_observed。欄位名稱故意保留「如果觀察成立」；它不是「已採用雙代理」。
這次參考執行器宣告的真實模型呼叫與外部呼叫都是 0。六組資料是固定合成政策情境，作者答案也沒有獨立時間先後證據。它能證明分支可重算，不能證明架構表現。
另外，這篇素材確實曾讓代理研究團隊分頭找官方文件、反方研究與本地證據。那是研究分工，不是受控實驗。三路任務、提示、上下文與遙測都不同，不能拿研究過程冒充三種架構的比較結果。
現在回到今天的判決。
目前沒有同任務、同來源、同模型、同工具、同停止政策與同總預算的三種架構真實紀錄。裁決器因此回 insufficient_evidence，暫時選擇 fixed_workflow。
老實說，這個答案沒有「兩個 AI 互相辯論」那麼吸睛。但它比較誠實。架構不是角色越多越成熟；第二個代理要能說出自己補了哪個缺口，還要留下足以比較的資料。
之後若補齊受控執行紀錄，雙代理在事前指定的品質指標上穩定改善，也沒有增加硬失敗、無來源主張、錯誤完整度、協調失敗、重複工作或人工負擔，裁決就可以重跑。現在先不增加，不是把門鎖死。
Anthropic 的代理工程建議主張從最簡單可行的方案開始，只在複雜度確實改善結果時才增加它。Microsoft 的單一與多代理選擇指南也把狀態管理、延遲、重複上下文、成本、監控與除錯列為多代理要付的代價。這些都是選型原則，真正的採用依據仍要回到自己的同條件資料。
Day 25 會往外走一步。內部用了固定流程、單一代理或雙代理，都不會因此取得外部發文權。下一篇會把預覽、批准、建立、等待、發布與回覆拆成可觀察狀態，看看一個「送出」按鈕背後到底要守住哪些邊界。
iThome鐵人賽
看影片追技術