複雜任務的「分治法」：建構多 Agent 協作的 SOP 工作流

在處理複雜專案（如撰寫深度產業報告、開發完整功能模組或策劃大型活動）時，最常見的錯誤是試圖用一個「超級 Prompt」讓 LLM 一次性完成所有工作。這種做法會導致模型在執行過程中出現邏輯斷層、細節遺失或嚴重的幻覺。

最高效的解決方式是借鑑軟體工程中的分治法 (Divide and Conquer)：將複雜目標拆解為一系列相互銜接的原子任務，並為每個任務建構獨立的 SOP（標準作業程序）。

本文將分享如何將一個「大目標」轉化為一套可執行的多階段協作工作流。

1. 核心邏輯：從「單點指令」到「流水線」

單點指令的邏輯是：輸入 $\rightarrow$ LLM $\rightarrow$ 結果。
分治工作流的邏輯是：輸入 $\rightarrow$ [分析 $\rightarrow$ 規劃 $\rightarrow$ 執行 $\rightarrow$ 審核] $\rightarrow$ 結果。

在這種模式下，每一個環節的輸出都是下一個環節的輸入，且每個環節都有明確的驗收標準 (Acceptance Criteria)。

2. 實作步驟：建構三層拆解架構

第一層：戰略拆解 (Strategic Decomposition)

不要直接開始寫內容，先讓模型扮演「首席架構師」，將大目標拆分為 3-5 個關鍵里程碑。
實作技巧：要求模型輸出一個 Gantt 圖式的任務清單，並定義每個階段的「交付物」。

Prompt 指令範例：
「我的目標是 [具體目標]。請不要直接執行，而是將其拆解為四個相互依賴的階段。對於每個階段，請明確定義：1. 輸入是什麼；2. 核心處理邏輯是什麼；3. 最終交付物的具體格式和驗收標準。」

第二層：戰術 SOP 化 (Tactical SOP)

為每個里程碑編寫專屬的 Prompt。此時，Prompt 的重點不再是「創意」，而是「確定性」。
- 分析環節：側重於提取關鍵資訊、識別潛在風險。
- 生成環節：側重於結構化輸出、遵循特定風格指南。
- 審核環節：側重於對照驗收標準進行計分和挑錯。

第三層：閉環校驗 (Closed-loop Verification)

在兩個階段之間引入一個「門禁」機制。如果當前階段的輸出不滿足驗收標準，則觸發重新生成，而不是強行進入下一階段。

3. 實戰 Checklist：你的工作流是否足夠穩健？

• [ ] 介面一致性：第一步生成的 JSON 或 Markdown 表格，第二步能否無縫解析？
• [ ] 上下文精簡：在進入第三步時，是否剔除了前兩步中冗餘的討論過程，僅保留核心結論？（防止 Token 浪費和干擾）
• [ ] 角色隔離：是否為不同階段分配了不同的專家角色？（例如：分析階段用「資深研究員」，審核階段用「嚴苛的編輯」）
• [ ] 異常處理：如果 LLM 在某一步產生幻覺，是否有明確的人工干預點或自動回滾機制？

4. Gotchas & 注意事項

• 避免過度拆解：如果一個任務可以透過一次高品質對話完成，不要強行拆成三步，否則會增加溝通成本並導致資訊在傳遞中衰減。
• 警惕「鏈式誤差」 (Cascading Error)：第一步的一個小錯誤會被後續步驟放大。因此，第一步（規劃/分析）必須經過最嚴格的人工審核。
• 動態調整：SOP 不是死板的文件。在運行過程中發現某個環節經常出錯，應立即更新該環節的 Prompt 指令。

總結

面對複雜任務時，放棄對「完美 Prompt」的幻想，轉而追求「可靠的工作流」。透過將大目標原子化、流程化、標準化，你可以將 LLM 從一個不穩定的「靈感來源」轉化為一個高產出的「工業化生產線」。