構建多智慧體工作流的經驗教訓：從單智慧體瓶頸到五種實用模式
本文分享了構建多智慧體工作流的實踐經驗，從單智慧體的侷限出發，介紹了使用協調者和子代理的多智慧體架構，並詳細闡述了五種經過驗證的工作流模式，幫助開發者突破AI編碼的效率瓶頸。
在AI編碼工作流中，許多開發者很快就遇到了單智慧體的天花板：一個代理無法處理複雜專案，往往導致耗時且結果不佳。本文透過廚房的比喻，深入介紹了多智慧體工作流的實踐方法，並總結了五種經過驗證的模式。
單智慧體的問題在於期望過高且任務分解不足。當專案從簡單的HTML遊戲轉向更實際的應用時，開發者會發現自己花費大量時間等待AI“合成”、“瀏覽”，最終得到糟糕的程式碼和膨脹的上下文視窗。而多智慧體架構引入了一位“主廚”（協調者），負責將訂單分解為可驗證的任務，並分派給多位“廚師”（子代理）執行。每個子代理擁有獨立的上下文視窗，專注於自己的任務，從而避免了單智慧體上下文膨脹和效率低下的問題。
多智慧體工作流近期變得更為實用，原因包括底層模型效能提升和流行AI編碼代理簡化了多智慧體編排。例如，OpenAI的Codex工作流和Anthropic的Claude Code及MCP生態系統都支援這種架構。最大的突破在於速度：Codex Spark的執行速度約為每秒1200個token，使得引入並行和驗證步驟變得可行。一個實際案例中，使用Codex和Figma MCP將網站複製到Figma的任務，單智慧體工作流平均耗時36.5分鐘，需要12次人工干預且全部失敗；而多智慧體工作流僅需5.2分鐘，2次人工干預，首次嘗試即成功。
這種架構帶來了三個直接優勢：
- Token效率：有效上下文視窗從約20萬擴充套件到2500萬以上。協調者不直接讀寫檔案或檢視工具呼叫結果，而是透過delegate_task生成子代理，每個子代理擁有全新的上下文視窗，從而避免了上下文丟失和頻繁壓縮。
- 控制力：可以透過順序執行的工作流嚴格控制每個步驟。協調者按照指令碼生成每個階段的子代理，包括任務分解、探索、測試、文件等步驟。內部試驗表明，這種順序迴圈將手動干預減少了84.3%。
- 速度：可以並行執行明確定義的任務。生成五個吉祥物變體，並行僅需約一分鐘，而順序執行需五分鐘，速度提升約5倍。
文章還總結了五種實用的多智慧體工作流模式：
- 預備線（Prep Line）：多個子代理獨立生成多個選項，然後人工篩選最佳結果。適合設計探索、程式碼變體或測試生成。例如，為Parchi建立50個吉祥物變體，使用5個Codex Spark子代理各生成10個，然後挑選最佳。
- 晚餐高峰（Dinner Rush）：多個子代理同時處理不同的獨立任務，共同完成一個目標。此模式借鑑了MoonshotAI的“群”概念，適合構建應用的多個獨立元件。關鍵要求是任務不共享檔案。
- 順序套餐（Courses in Sequence）：將專案分成多個波次，每個波次內並行，波次之間順序依賴。適合大型重構或全面重建。每個波次的子代理只需獲取與自身任務相關的上下文。
- 備料到上菜（Prep-to-Plate Assembly）：子代理順序執行，每個完成一個小任務並驗證，然後傳遞給下一個。適合長期研究或多步驟流水線，狀態儲存在檔案和任務佇列中，而非對話歷史。
- 戈登·拉姆齊（Gordon Ramsay）：增加專門的驗證子代理，對編碼結果進行檢查，確保質量。這是一種紀律而非架構，將編寫程式碼的子代理與檢查程式碼的子代理分離。
這些模式都基於一個核心原則：將問題分解為小而明確的任務，並讓每個子代理擁有最小必要上下文。透過實踐這些模式，開發者可以突破單智慧體的限制，構建更可靠、高效的AI工作流。隨著模型速度的持續提升，多智慧體工作流將成為AI編碼的主流正規化。