多 Agent 協作與遞迴任務拆解的工程模式

當一個工程目標超出單個 Agent 的上下文容量與處理能力時，我們需要一種把「一個大問題」降解為「一組可交付小問題」的協作方式。多 Agent 協作與遞迴任務拆解的工程模式就是這樣一套組織方法：上層執行者理解整體目標並完成分解，下層執行者在明確邊界內完成局部實現與測試；當某個子任務依然過於複雜時，就繼續向下遞迴拆解，直到每個工作單元都可執行、可驗證。

三層結構：理解、遞迴與局部閉環

• 上層執行者：面向整體目標，回答「要做什麼」，輸出可委派的子任務、約束條件與驗收標準。
• 中層執行者：承接仍然過大的子任務，繼續遞迴拆解，把鬆散的大目標收斂為穩定的任務層級。
• 下層執行者：在職責邊界內完成局部實現與測試，產出可驗證結果並向上交付，形成局部閉環。

為什麼必須遞迴拆解

Agent 的上下文視窗、可調用工具與單次可處理的任務規模都是有限的。如果讓單個 Agent 長期持有整個專案的全部上下文，不僅成本隨規模上升，還容易出現目標漂移、狀態污染與關鍵資訊被稀釋。遞迴拆解把這部分壓力分散到各層：每個 Agent 只需理解自己那一層的目標與約束，複雜目標被逐層降解為可執行、可交付的工作單元，而整體一致性由任務層級來保證。

關鍵機制：任務樹與交接關係

父任務與子任務構成一棵遞迴任務樹。向下流動的是任務委派——目標、邊界約束與驗收標準；向上流動的是結果回收——產出物、驗證證據與尚未解決的問題。協作能否真正成立，取決於三件事：任務層級是否清晰、職責邊界是否互斥、交接產物（介面定義、資料集、測試用例、檢查點）是否被明確約定。缺少其中任何一項，多個 Agent 就會退化為重複勞動與相互衝突的結果。

與「方法演化」的呼應

遞迴拆解的對象不僅是任務本身：拆解的深度、委派的粒度以及結果回收的策略，同樣可以被持續評估與調整。當任務回饋（如某個子任務反覆返工）反過來影響下一次如何拆解時，這套協作流程本身就進入了自我改進的循環，與把「產生候選的方法」納入優化對象的思路一脈相承。