同樣是調用模型和工具，有的任務適合按順序推進，有的需要先分類、並行處理，或根據反饋反覆修改。還有一些任務，下一步要做什麼，只能等拿到新的信息後再判斷。這些執行方式的差別，首先來自任務本身的結構。
讀 Anthropic 的《Building effective agents》，我關注的是：任務怎樣組織，執行過程由誰決定。 原文將這些系統統稱為 Agentic Systems，區分為 Workflow 與 Agent。本文從三個層次展開：
- 控制結構： Workflow 與 Agent 有什麼區別，哪些執行安排由程序確定，哪些判斷交給模型。
- 五種 Workflow： 串行、分流、並行、動態拆分與反饋迭代，分別解決什麼任務結構問題。
- Agent 的運行： 模型怎樣依據環境反饋決定下一步，什麼時候繼續、什麼時候停止，以及這種靈活性的代價。
1. Workflow 和 Agent 到底差在哪裏？h2
核心區別是：執行過程主要由誰決定。 有沒有 Tool、調用了幾次 LLM、是否存在循環，都不足以單獨區分兩者。
Workflow：程序規定基本路線
以寫文章為例，程序可以提前規定：生成大綱 → 檢查大綱 → 根據大綱寫正文。模型負責生成每一步的內容，但步驟的順序、檢查的時機，以及檢查失敗後怎麼處理，都由程序安排。
原文用 predefined code paths 描述這種結構，也就是預定義的代碼路徑。這裏的“預定義”不等於每一次執行都完全一樣：程序可以設置分支、並行和循環，模型也可以在節點中做判斷。關鍵是這些判斷仍在事先設計的結構內發生。
Agent：模型動態決定執行過程
再看“修復一個陌生項目裏的 GitHub Issue”。開始時很難知道要查多少文件、改幾個模塊、需不需要補測試，以及測試失敗後該往哪裏排查。
模型可能先搜索類名，讀到代碼後轉去檢查另一個模塊，修改後運行測試，再根據失敗信息繼續定位。下一步不是一開始就全部排好的，而是由模型根據當前信息決定的。
兩者都可以多步執行，但組織方式不同：Workflow 是讓模型完成流程裏的任務，Agent 則把更多行動選擇交給模型。
2. 為什麼不應該一上來就用 Agent？h2
Agent 的靈活性有代價。執行路線越開放，就越難提前預測會調用多少次模型和工具，也越容易增加延遲、成本與失敗路徑。
Anthropic 建議先尋找最簡單的可行方案。對不少應用來説，改好 Prompt，補充檢索信息和上下文示例，一次調用就已經足夠。需要多階段處理時，再考慮 Workflow；只有固定結構難以表達任務的不確定性時，才需要進一步引入 Agent。
因此，選型可以先問兩個問題：一次調用能否完成？如果不能，執行結構能否提前設計？ 前者決定要不要增加步驟，後者幫助判斷這些步驟應該由程序編排，還是由模型動態探索。
下面五種 Workflow，就是五種不同的編排方式。它們都允許多次調用，但每一種增加調用的理由不同。
3. Prompt Chaining：固定步驟，一個接一個做h2
Prompt Chaining 適合能清晰拆成固定順序的任務。 前一步的輸出成為下一步的輸入，每次調用只處理其中一個環節。
怎麼工作？
仍以寫文章為例：
生成大綱 → 檢查大綱 → 根據通過檢查的大綱寫正文
“寫一篇結構合理、內容完整、語言自然的文章”同時包含好幾個目標。拆成鏈以後，第一步先解決結構問題，下一步檢查結構，最後再展開正文。原文還舉了另一個更簡單的例子：先生成營銷文案，再翻譯成另一種語言。
拆分的價值在於，每次調用面對的問題更集中，中間結果也更容易檢查。如果正文偏離預期，可以進一步定位是大綱本身有問題，還是正文沒有遵循大綱。
Gate：先檢查，再決定是否繼續
鏈條不必只是一路向下。程序可以在中間加入 Gate，也就是檢查關口。例如，檢查大綱是否覆蓋指定主題、是否包含必要章節；通過才寫正文，不通過則返回修改或終止。
原文強調的是程序化檢查。結構完整性、字段和長度等條件，可以直接由代碼驗證。這樣做是為了避免前一步已經跑偏，後面的調用還繼續擴寫。
適合什麼任務，代價是什麼？
它適合步驟穩定、前後有依賴，而且拆分後每一步確實更容易完成的任務。代價是串行調用增加，等待時間與成本通常也隨之上升。如果一次調用已經足夠好，拆成三步未必更划算。
記住它的結構：固定順序，逐步處理，中間可以檢查。
4. Routing：先分類，再選擇處理路線h2
Prompt Chaining 關心的是“下一步做什麼”，Routing 關心的是：這條輸入應該交給哪一種處理流程？
怎麼工作？
假設客服系統要處理普通諮詢、退款申請和技術問題。可以先由 Router 判斷類別，再進入對應路線：
用户問題 → Router 分類 → 諮詢流程 / 退款流程 / 技術支持流程
普通諮詢可能只需要查知識庫；退款需要訂單信息和業務規則；技術支持則需要故障排查。把它們分開，每條路線都可以使用更合適的 Prompt、工具和上下文。
為什麼要先分開？
如果全部塞進一個通用 Prompt，優化退款規則時，可能影響普通諮詢的回答；任務類型越多，規則之間也越容易互相干擾。Routing 的價值是分離職責，再分別優化，而不是單純多加一次分類調用。
Router 不一定是 LLM，也可以是規則、傳統分類模型或其他算法。還可以按難度路由：常見問題交給速度快、成本低的模型，複雜問題交給能力更強的模型。
適合什麼任務，代價是什麼？
它需要輸入確實存在有意義的類別，而且分類能夠比較準確。如果入口把技術問題分進退款流程，後面的處理再完善，也很難答對。分類本身也會增加一次處理，因此要看專門路線帶來的收益是否值得。
記住它的結構：先判斷輸入類型，再進入專門路線。
5. Parallelization：可以獨立做的事情同時做h2
有些工作不需要等待彼此的結果，可以同時執行，再彙總輸出。原文把 Parallelization 分為 Sectioning 和 Voting。兩者外形相近，但分工目的不同。
Sectioning：不同子任務，分別處理
例如審查一段代碼，提前分成安全、併發和性能三個方向：
同一份代碼 → 安全審查 / 併發審查 / 性能審查 → 彙總發現
每個調用只關注一個維度，既可以減少整體等待，也能讓判斷更集中。原文還舉了用户請求處理與安全篩查並行的例子：一條分支負責回答，另一條專門檢查請求是否合規。
這裏的前提是子任務能夠獨立執行。如果性能分析必須先知道併發審查的結論，就不能把兩者簡單視為完全並行的工作。
Voting：同一個任務，多次獨立判斷
Voting 不按維度分工，而是讓同一個任務產生多份判斷。例如，用不同 Prompt 分別檢查同一段代碼是否存在漏洞，然後按規則彙總。
同一個問題 → 獨立判斷 A / B / C → 聚合結果
這裏的“投票”不一定是簡單多數決。原文的漏洞檢查例子會使用不同 Prompt，分別尋找問題；內容分類則可以設置不同的投票門檻，平衡誤報與漏報。具體怎樣聚合，取決於任務希望得到什麼結果。
適合什麼任務，代價是什麼？
不同工作可以獨立拆開時，用 Sectioning；同一個問題需要多個角度或多次嘗試時，用 Voting。並行可以降低總等待時間，但總調用量和 Token 消耗通常更高，最後還需要合理的彙總規則。
記住區別：Sectioning 是不同事情分別做，Voting 是同一件事多次判斷。
6. Orchestrator-Workers：運行時決定怎麼拆任務h2
Orchestrator-Workers 也有多個 Worker，最後也要彙總。但它與前面的固定並行分工有一個關鍵區別：子任務不是提前列好的，而是讀完當前輸入才決定的。
怎麼工作？
一箇中心 LLM，也就是 Orchestrator，先分析任務，拆出子任務並分派給 Worker，再綜合它們的結果：
輸入任務 → Orchestrator 動態拆分 → Workers 執行 → 綜合結果
例如實現一個跨模塊需求。有的需求需要改 Controller、Service 和數據庫遷移；另一個需求可能只涉及緩存配置和迴歸測試。不能提前規定每次都讓三個 Worker 修改同樣的三個模塊，拆分方式必須取決於當前代碼和需求。
這也是它與固定 Sectioning 的區別。安全、併發、性能審查是預先確定的分工維度；具體需求涉及哪些文件、各文件怎麼改，則需要分析當前任務才能知道。
為什麼原文仍把它歸為 Workflow？
動態發生在“拆出什麼子任務”這一層，外圍仍然可以遵循預定義的“分析 → 分派 → 彙總”結構。局部由模型決定，不代表整個執行過程都交給了模型。 這解釋了為什麼它雖然靈活，仍被原文列在 Workflow 中。
適合什麼任務，代價是什麼？
它適合可以分解，但無法提前預測具體子任務的複雜工作，例如多文件代碼修改、跨來源信息搜索。相比固定分工，它多了分析任務、安排 Worker 和綜合結果的調用，換來的是按當前輸入調整分工的靈活性。
記住區別：固定並行提前知道怎麼分，Orchestrator-Workers 運行時才決定怎麼分。
7. Evaluator-Optimizer：根據明確反饋改進結果h2
前面幾種模式主要討論任務怎麼走、怎麼分。Evaluator-Optimizer 解決的是：第一份結果還不夠好，怎樣有方向地修改？
怎麼工作？
一個調用負責生成結果，另一個負責評價並提出反饋，再把反饋交回生成環節：
生成候選 → 評價與反饋 → 根據反饋修改 → 再次評價
原文以文學翻譯為例。初稿可能意思基本正確，但語氣不合適、雙關沒有表達出來，或某些用詞生硬。Evaluator 指出這些具體問題，Generator 再針對它們修改。
它不是反覆要求“再寫一次”。反饋需要説明哪裏不足，以及改進方向是什麼，這樣下一輪生成才有依據。
什麼條件下反饋才有用？
Anthropic 給出兩個判斷：人類提出明確反饋時，結果能夠被明顯改善；LLM 也有能力提供這類反饋。換句話説，任務要有可用的評價標準，評價者還要能識別與這些標準有關的問題。
如果只得到“很好”“還可以更好”這樣的結論，循環很難產生有針對性的改善。能指出具體問題、指導下一輪修改的反饋，才是這個模式有價值的地方。
適合什麼任務，代價是什麼？
它適合存在清晰質量標準，而且反饋迭代能帶來明顯收益的任務。生成、評價和修改會增加調用次數與等待時間，因此要看這種改善是否值得額外開銷。
記住它的結構：生成 → 評價 → 按反饋修改，而不是無方向地重試。
8. 五種 Workflow 放在一起，應該怎麼看？h2
把它們放在一起時，我更關注各自解決的結構問題，而不是名字。可以用下面這張錶快速對照：
| 模式 | 核心問題 | 適用的任務結構 |
|---|---|---|
| Prompt Chaining | 怎樣把任務逐步做好？ | 順序固定，前一步輸出供後一步使用 |
| Routing | 這條輸入該交給誰？ | 類別明確，適合分開處理 |
| Parallelization | 哪些工作可以同時做？ | 子任務獨立，或需要同一任務的多份判斷 |
| Orchestrator-Workers | 這次應該拆成哪些任務？ | 拆分方式依賴當前輸入 |
| Evaluator-Optimizer | 怎樣進一步改善結果？ | 標準清楚，反饋能指導修改 |
這些模式可以組合，並不是只能選一個。例如，客服入口先 Routing，技術問題進入固定排查鏈，其中資料檢索並行執行，最後再檢查答案是否覆蓋問題。它同時使用了分類、串行、並行和評價，但仍可以是一個 Workflow。
因此，模式是組織任務的積木，不是整套系統只能貼一個的標籤。把每一部分為什麼這樣組織講清楚，比把整套系統叫得更復雜更有用。
9. 什麼時候 Workflow 不夠，需要 Agent？h2
五種 Workflow 可以組織複雜任務，但基本執行結構仍由開發者提前設計。如果問題是開放式的，所需步數難以預測，下一步還取決於剛獲得的信息，就很難預先寫出完整路徑。 這時才需要考慮 Agent。
例如調查“一個服務為什麼突然變慢”。問題可能來自數據庫、緩存、網絡或最近一次部署。讀到監控結果前，很難知道該走哪條排查路線；看完慢 SQL 後，也可能需要回頭檢查調用方的變化。
Agent 的價值就在這裏：讓模型依據新信息調整行動，而不是要求開發者提前列出所有可能分支。需要交給模型的，是這部分無法預先確定的執行路線。
10. Agent 怎樣工作？h2
Agent 通常從用户給出的目標開始，必要時先澄清任務，再進入一個反饋循環：
目標 → 模型決定下一步 → 使用 Tool → 獲得環境反饋 → 再次決定
以 Coding Agent 為例，它修改代碼後運行測試，讀到失敗信息，再決定繼續修復、補充調查，還是請求幫助。這裏影響下一步的，是實際得到的結果，而不是模型對結果的預想。
原文把這種來自環境的反饋稱為 ground truth，例如工具調用結果和代碼執行輸出。模型説“修好了”是一項判斷，運行相關測試得到的結果，則是可以用來核對這一判斷的觀察。行動改變環境，反饋再影響下一次行動。
人類檢查點和停止條件，也是循環的一部分。 Agent 可以在關鍵環節向人類獲取反饋，遇到阻塞時請求幫助；任務完成後返回結果，也可以由最大迭代次數等條件終止執行。它不是一個必須一直運行下去的循環。
這樣的執行方式也帶來更高成本，以及錯誤累積的可能：一次誤判可能影響後續搜索、修改和判斷。環境反饋與人類檢查點讓系統有機會及時調整路線，但自主執行並不意味着每一步都會正確。
11. Workflow 還是 Agent：最終怎麼選？h2
可以按下面的順序判斷：
- 一次調用已經足夠，就保持簡單。 先優化 Prompt，補充檢索信息和上下文示例，不必為了多步而引入多步系統。
- 整體路線能提前設計，就選擇 Workflow。 根據任務結構安排串行、分類、並行、動態拆分或反饋迭代，讓模型在明確的結構內完成工作。
- 路線必須在運行時探索，再考慮 Agent。 當下一步高度依賴環境反饋，固定路徑難以覆蓋任務時，模型的自主決策才有明確價值。
這不是從“低級”到“高級”的升級順序。一個複雜任務也可能有明確流程，而一句話描述的任務可能需要開放探索。任務複雜程度，與執行路徑能否預先確定，是兩件不同的事。
最終還要比較任務質量、成本和延遲：新增調用、Worker 或自主性，是否真的改善了結果？對我來説，這篇原文給出的選型主線很清楚：先看任務結構，再安排控制方式；複雜度只有改善結果時，才值得增加。
幾個關鍵問題，串起這些模式h2
把前面的模式放在一起，有幾個問題能幫助説明它們之間的聯繫與區別。
調用了工具、執行了很多步，就算 Agent 嗎？
不一定。“檢索 → 生成 → 檢查”可以完全由程序編排。按本文采用的定義，要看模型是在預設結構裏完成任務，還是根據環境反饋持續決定接下來採取什麼行動。調用次數和工具數量，不能單獨説明這一點。
Parallelization 和 Orchestrator-Workers 都有多個 Worker，區別在哪裏？
看具體子任務是否提前確定。預先安排安全、併發和性能三個審查方向，是固定的並行分工；讀完當前需求後，才決定涉及哪些模塊、分別交給誰處理，是 Orchestrator-Workers。區別在拆分方式，不在 Worker 數量。
Sectioning 和 Voting 都是並行，為什麼要分開？
Sectioning 是分工：不同調用解決不同子問題。Voting 是增加判斷視角：同一個問題產生多份結果，再按規則彙總。前者關注如何拆工作，後者關注如何綜合同一任務的多份判斷。
Orchestrator-Workers 能動態拆任務，Evaluator-Optimizer 也會循環，為什麼仍是 Workflow？
因為局部決策可以是動態的，整體結構仍然可以由程序預先規定。前者遵循“拆分 → 分派 → 彙總”，後者遵循“生成 → 評價 → 修改”。模型在這些結構內做判斷，並不意味着它已經主導整個執行過程。動態拆分和循環，都不是 Agent 獨有的特徵。
怎樣判斷增加自主性是否值得？
要和更簡單的方案比較：它是否解決了原先難以覆蓋的任務，質量提升了多少，又增加了多少成本、延遲和失敗風險。Workflow 能穩定完成的部分，可以繼續交給程序；真正需要邊執行邊探索的部分，再交給 Agent。選擇依據是任務收益，不是模式名稱。