Agent 工作流五種模式：先選對 Workflow，再談 Agent

前言

許多團隊一開始就想打造「完全自主的 Agent」，結果得到的是難以除錯、成本失控、行為不可預測的系統。Anthropic 在《Building Effective Agents》一文中給了一個務實的起點：先分清楚 Workflow 與 Agent，再從五種工作流模式中選對形狀；只有當簡單方案在評測上明顯不夠好時，才往更複雜的架構升級。換句話說，Agent 不是起點，而是最後手段。

一、Workflow 與 Agent 的分界

Workflow 是「預先定義好的程式路徑」編排 LLM 與工具：流程由程式碼決定，模型只負責每一步的生成與判斷。Agent 則是 LLM 自己決定流程與工具使用：模型在執行時規劃下一步、呼叫工具、根據結果調整方向。

這條分界決定了除錯方式與成本結構。Workflow 的行為可預測、可單步測試；Agent 的彈性更高，但每一步都可能偏離，延遲與 token 花費也更難估算。Anthropic 的建議是：預設從最簡單的方案開始——先優化單次提示，再考慮 Workflow，最後才考慮 Agent。

二、五種模式

如圖一，五種模式按複雜度與彈性由低到高排列，且可以互相組合。

1. Prompt Chaining（提示鏈）

把任務拆成固定順序的步驟，前一步的輸出就是下一步的輸入，中間可以插入程式檢查或閘門。例如寫作管線：先寫大綱，程式檢查大綱是否涵蓋要點，通過後才進入正文撰寫。適合任務能乾淨拆成固定子任務的場景。代價是延遲累加，且錯誤會往下游傳遞——閘門的品質決定整條鏈的品質。

2. Routing（路由）

先用一次分類呼叫（通常用較便宜的模型）判斷輸入屬於哪一類，再分派給專門的提示或處理器。例如客服問題分流：退貨、技術支援、帳務各自走不同的處理流程；或依難度分流，簡單問題用小模型，困難問題用大模型。適合輸入分屬少數明確類別的場景。關鍵風險是分類錯誤：分錯類，後面全走錯路，因此要持續監控分類準確率。

3. Parallelization（平行化）

有兩種變體。分段（sectioning）：把任務切成彼此獨立的子任務同時執行，省時間。投票（voting）：同一任務跑多次再彙總結果，換信心——例如用多個不同提示審查同一段程式碼的漏洞，任一發現即標記。適合子任務互不依賴，或需要多視角交叉檢查的場景。代價是 token 花費隨平行數倍增，投票機制本身也需要設計（多數決？任一即報？）。

4. Orchestrator-Workers（編排者－工作者）

中央的編排者 LLM 在執行時動態拆解任務，把子任務分派給工作者 LLM，再彙整結果。與路由的關鍵差別：分解方式是模型依輸入即時發明的，而不是事前寫死的。適合事前無法預測子任務的任務，例如深度研究。Anthropic 的 Research 功能就是這個架構：主 Agent 規劃並派出專門的子 Agent 平行探索，在其內部研究評測中大幅勝過單一 Agent。但 Anthropic 也提醒，這類架構的 token 花費可達十數倍，且只適合能平行展開的廣度型查詢，不適合大多數程式任務或高度相依的共享上下文工作。

5. Evaluator-Optimizer（評估－優化）

一個 LLM 生成，另一個 LLM 評估並給回饋，迴圈直到達標。適合有明確評估標準、且迭代確實能改善結果的任務，例如文案潤飾、程式碼修復。這個模式有兩個必須設好的停損：最大迭代次數與評分門檻。沒有停損的迴圈會在「差不多好」與「更好一點」之間無限燒錢。

三、選型：從問題形狀出發

如圖二，選型可以簡化成一連串判斷：任務能拆成固定步驟嗎？輸入分屬少數類別嗎？子任務獨立嗎？分解方式事前未知嗎？有明確評分標準嗎？第一個回答「是」的，就是起點。如果以上皆非，那就先用直接的 LLM 呼叫——不需要任何模式。

四、實作要點與程式碼範例

以下是一個評估－優化迴圈的簡化骨架，重點在停損與回饋的結構，而非呼叫哪個模型：

def evaluator_optimizer(draft, max_rounds=3, bar=8):
    for round in range(max_rounds):
        score, feedback = evaluate(draft)   # 評估者：給分＋具體回饋
        if score >= bar:
            return draft
        draft = refine(draft, feedback)     # 優化者：針對回饋改，不重寫全部
    return draft  # 達到上限就停，寧可回傳「夠好」，也不要無限迴圈

另外三個實作要點，適用於所有模式。第一，從直接 API 呼叫開始，別先套框架：框架會遮住提示與回應，讓除錯變難；先看懂抽象層在做什麼，再決定要不要用。第二，工具設計值得跟提示工程同等的注意力：格式要貼近模型訓練資料、減少轉義負擔，給模型留「思考」的 token。第三，給 Agent 來自環境的 ground truth：工具回傳結果、測試執行結果，而不是只靠模型自我感覺良好；同時設好人類回饋檢查點與停止條件。

五、常見誤區

第一，把「固定會全部跑完的分工」叫做編排者－工作者：如果分解方式是程式碼事前決定的，那是平行化或提示鏈，不是編排者。第二，沒有評分標準就用評估－優化：沒有明確標準的評估者，只會生產看似專業的空話。第三，跳過 Workflow 直上 Agent：當任務其實有固定結構時，Agent 的自由度只是噪音來源。第四，用框架遮住一切：當框架讓你看不到提示時，你就失去了最重要的除錯手段。

結論

五種模式不是五選一的考卷，而是可組合的積木：路由分流後，每條支線可以是提示鏈；編排者派出的工作者，內部可以是評估－優化迴圈。實作的順序應該是：先用最簡單的方案做出可評測的基線，再針對評測暴露的弱點，換上剛好能補強的那一塊模式。先選對 Workflow，再談 Agent——這是讓 Agent 系統從展示品變成生產系統的第一步。

來源

Anthropic, Building Effective Agents（2024 年 12 月）：https://www.anthropic.com/engineering/building-effective-agents
Anthropic, Multi-Agent Research System：https://www.anthropic.com/engineering/multi-agent-research-system
開源實作範例 building-agentic-systems：https://github.com/mrcloudchase/building-agentic-systems

Dylan House