Anthropic 建議企業檢視現有多個 AI 子代理（sub-agent）架構，評估有冇可能合併成一個主要代理，需要時先載入上下文。該公司指出，新模型由 Opus 4.5 開始，包括 Opus 5.5 同 Fable 5.1，已經可以喺單一個循環直接處理複雜計劃，從而降低成本同等待時間。Anthropic 指喺一次架構比較中，單一代理比多代理架構快約兩倍。
呢個建議來自 Anthropic 應用 AI 團隊喺多個企業部署上嘅經驗。該團隊發現，單一代理配合所謂「skills」（技能）機制，喺質量上經常勝過龐大提示詞設計同子代理架構。一間公司嘅例子係：佢喺客服代理入面設咗十幾個專責子代理，結果難以保持一致嘅品牌體驗，用户體驗亦因高延遲而受影響。
Anthropic 將呢個現象稱為代理版「康威定律」（Conway's Law）：架構變成組織圖嘅翻版，每個團隊各自開發自己嘅子代理，最終成百個重疊代理層層堆疊，冇共享標準。隨之而來係所謂「拼圖提示詞」（Frankenprompt）——各團隊各自喺系統提示詞入面加入規則，結果互相矛盾。Anthropic 認為，一個乾淨嘅系統提示詞、四到五個精簡資料工具、加上固定輸出護欄，已經可以覆蓋大部分用例。
Anthropic 以 Claude Code 為例，指針對新模型，系統提示詞已削減超過 80%，部分原因係技能同工具而家只需時才載入。新模型亦會自己評論進度、檢查自己嘅工作，令部分額外控制層變得多餘。
唔代表子代理冇存在價值。Anthropic 指有三種情況仍適合用子代理：單一代理嘅上下文窗口出現可測量嘅效能衰退、多項任務需要並行執行並使用各自嘅上下文窗口、或者單一代理喺工具選擇上出現困難。
Anthropic 亦警告唔好盲目合併。喺一次支援代理測試中，將某個子代理併入後，延遲雖然降低，但一個原本運作正常嘅流程卻被破壞——主要代理開始自行回答，而唔再諮詢正確嘅專責代理。
為方便團隊逐步遷移，Anthropic 已喺 GitHub 公佈一個遷移工具包，引導團隊識別現有模式、評估替代方案、並驗證最佳做法。
阿調搞兩下
寫到呢度，真係要提一提：呢份建議由 Anthropic 自家發出，佢哋係模型供應商，Claude 系列係佢哋嘅產品，Claude Code 係佢哋嘅編程工具。所謂「單一代理優於多代理」嘅結論，出自佢哋自家團隊喺自家客户部署上嘅觀察，未見獨立第三方驗證。模型愈強、上下文愈長，廠商自然有動力推「一個搞掂」嘅敍事——但打工仔問嘅問題永遠係：邊個揸住個掣？如果所有代理最終收到一個，邊個負責確保合併後冇人偷偷改咗規則？
