Agent 設計模式

五種 Workflow 模式

業界已驗證有效的五種 Workflow 編排模式。它們由簡到繁，每種解決特定類型的問題。不追求最複雜的，追求最合適的。

Pattern 1

Prompt Chaining

提示鏈

把一個大任務拆解為多個順序步驟，上一步的輸出直接作為下一步的輸入。每一步都是一次獨立的 LLM 呼叫，專注做好一件事。步驟之間可以插入品質門（programmatic gate），只有通過檢查才進入下一步。

輸入

LLM Step 1

Gate

LLM Step 2

輸出

適用場景

任務能自然拆解為多個固定步驟；需要在中間環節做品質檢查；用準確度換取延遲。

真實例子：生成行銷文案（Step 1）-> 翻譯為目標語言（Step 2）-> 格式化為特定平臺樣式（Step 3）。中間 Gate：檢查 Step 1 輸出是否包含品牌關鍵資訊。

Pattern 2

Routing

路由

先分類輸入，然後將其導向不同的專門處理分支。每個分支可以有獨立的 Prompt、模型甚至工具配置。核心價值：關注點分離，讓每個分支只處理一種類型的輸入。

輸入

分類器

處理分支 A

處理分支 B

處理分支 C

適用場景

輸入類型多樣，不同類型需要完全不同的處理邏輯；需要成本優化（簡單問題用便宜模型，複雜問題用強模型）。

真實例子：客服系統：簡單 FAQ 用 Haiku（快且便宜），退款相關用 Sonnet + 訂單工具，技術故障用 Sonnet + 日誌查詢。一個分類器決定走哪條路，實現成本與效果的最優平衡。

Pattern 3

Parallelization

並行化

讓多個 LLM 呼叫同時執行，再聚合結果。有兩種子模式：
Sectioning（拆分並行）：把一個任務拆為獨立子任務，並行處理後合併。
Voting（多次投票）：同一個任務用相同 Prompt 跑多次，取多數/最佳結果。

輸入

LLM A

LLM B

LLM C

聚合

輸出

適用場景

子任務之間沒有依賴關係；需要提升速度（並行比序列快）；需要提升置信度（多次投票降低隨機性）。

真實例子 - Sectioning：程式碼審查中，一個 LLM 檢查安全漏洞，一個檢查效能問題，一個檢查程式碼風格，最後彙總所有發現。
真實例子 - Voting：內容審核中，同一段文字讓 3 個 LLM 分別判斷是否違規，取多數意見作為最終結果。

Pattern 4

Orchestrator-Workers

編排者-工人

一個中心 LLM（編排者）動態拆解任務並分配給多個工人 LLM。與 Parallelization 的區別：子任務由編排者在執行時動態決定，程式碼裡沒有預先定義。這是最接近 Agent 的 Workflow 模式。

輸入

編排者 LLM

Worker 1

Worker 2

Worker N...

合併

適用場景

子任務不能提前預知（需要根據輸入動態決定）；涉及對多個檔案/資源的並行操作。

真實例子：程式碼修改需求「給專案加國際化支援」。編排者分析程式碼庫後動態決定：Worker 1 改 Button 元件、Worker 2 改 Header 元件、Worker 3 建立語言檔案。不同需求產生不同數量和類型的 Worker。

Pattern 5

Evaluator-Optimizer

評估-優化

一個 LLM 負責生成，另一個 LLM 負責評判，二者形成迭代迴圈：生成者根據評判者的回饋不斷改進輸出，直到評判者認為滿意或達到迭代上限。

輸入

生成者 LLM

評判者 LLM

輸出

虛線框 = 迴圈迭代直到滿足標準

適用場景

有明確的品質評估標準；迭代改進能顯著提升輸出品質；單次生成很難達到要求。

真實例子：文學翻譯中，生成者做初步翻譯，評判者檢查信達雅和風格一致性並給出具體修改建議，生成者根據建議改進。迴圈 2-3 次後輸出終稿。每次迭代的翻譯品質都在提升。

動手試試：模擬排程器

點選上方按鈕查看不同模式的資料流轉動畫

總結

五種模式一覽

模式	核心思想	典型場景	複雜度
Prompt Chaining	順序串聯，逐步處理	文案生成管道	低
Routing	分類導向，專門處理	智慧客服分流	低
Parallelization	並行處理，聚合結果	多維度程式碼審查	中
Orchestrator-Workers	動態拆分，分佈執行	跨檔案程式碼修改	中高
Evaluator-Optimizer	生成評判，迭代改進	高品質翻譯	中

"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."

不要追求最複雜的模式，要追求最合適的。從最簡單的 Prompt Chaining 開始，只在確認簡單方案不夠用時才升級到更複雜的模式。每增加一層複雜度，都要問自己：這個複雜度帶來的收益，值得額外的延遲、成本和除錯難度嗎？