跳轉到主要內容
這個單元解決什麼問題單次 prompt 解不了的多步任務，靠 workflow 編排：拆解、串接、平行、驗證、收斂。prompt engineering 管「這一句怎麼問」，context engineering 管「視窗裡該有什麼」，workflow engineering 管的是「這些步驟用什麼結構串起來、誰先誰後、哪裡放關卡」。把這層做對，多步流程才會可重複、可審查、不靠運氣，而不是每跑一次結果都不一樣。

​
學習目標

  • 能判斷一個任務何時超出單次 prompt 的範圍、需要 workflow 才能可靠執行，並分清「workflow」與「agent」的界線。
  • 能把複合目標拆解成有依賴關係的步驟，辨識哪些可平行、哪些必須有序（DAG 思維）。
  • 能套用 pipeline、fan-out、barrier、loop-until 等原語，並對應到 Anthropic 歸納的五種具名模式。
  • 能在流程的關鍵節點放入對抗式驗證與收斂關卡，防止上游錯誤靜默傳遞。

​
1. 何時需要 workflow：單 prompt 的天花板在哪

當任何一步的輸出是下一步的輸入、而且這個中間結果難以在同一個上下文裡可靠地維持時，你就需要 workflow。 反過來說，能在一次 prompt、一個上下文視窗內穩定完成的，就別拆，拆了只是徒增延遲與狀態管理成本（見第 8 節常見誤區）。 單次 prompt 會撞到三道牆：
  • 輸出長度：模型單次回應有 token 上限，要它一口氣產出一份長報告加完整程式碼加測試，要嘛截斷，要嘛每段都草草帶過。
  • 上下文深度：任務需要「記住前面算出來的中間結果」再往下做時，這些中間結果會擠在同一個視窗裡互相稀釋，觸發 01-4 講的 lost in the middle 與 context rot。
  • 外部取值：某一步要先去查資料庫、跑測試、抓網頁，拿到結果才能決定下一步怎麼走。單輪 prompt 沒有「停下來取值再繼續」的結構。
典型超出邊界的任務：大型程式碼重構（跨多檔、要先理解再改再驗）、多文件摘要比對（先各自摘要再交叉比對）、迭代品質提升（產出 → 評估 → 修正 → 再評估）、資料管線（抓取 → 清洗 → 轉換 → 載入）。共同特徵都是「中間結果要落地、要被下一步消費」。
workflow 與 agent 不是同一件事Anthropic 在 Building Effective Agents 裡的區分是：workflow 是「LLM 與工具被預先寫好的程式路徑編排」的系統；agent 是「LLM 自己動態決定流程與工具用法、自行掌控如何完成任務」的系統 [1]。差別在「誰決定下一步」。workflow 的步驟與跳轉是你預先以程式碼定義好的，模型只在每個節點內做事；agent 是你給它目標與工具，由它自己規劃步驟。本單元先把 workflow 練到位，因為它可預測、可重現、好除錯；agent 的彈性要付出可控性的代價，那是 01-6 harness 的範疇。實務上絕大多數「看起來需要 agent」的任務，一個設計良好的 workflow 就解決了，而且更穩。

​
2. 拆解與依賴：DAG 思維

把複合目標拆成步驟，最可靠的方法是從終點往回問：「這個最終輸出，直接需要哪些東西？」每個答案再往上追一層「那它又從哪來？」，追到不可再分的原子步驟為止。比起從頭往下想「第一步做什麼」，逆推不容易漏掉隱含的前置步驟。 拆完之後，把步驟畫成一張有向圖：節點是步驟，邊是依賴（A → B 表示 B 要用到 A 的輸出）。這張圖必須無環（acyclic），有環代表 A 等 B、B 又等 A，會死鎖。這就是 DAG（directed acyclic graph，有向無環圖）思維。 DAG 一畫出來，平行機會就自己浮現了：沒有路徑相連的節點，可以同時跑。 這張圖裡，C1、C2、C3 三個摘要步驟互不依賴，可以平行；但它們全都得等 B 完成（要清洗後的資料），也全都得在 D 之前完成（比對要三份摘要都到齊）。D 就是一個天然的屏障點（barrier，見第 3 節）。 拆解最常犯兩種相反的錯：
  • 把可平行的串起來：明明 C1/C2/C3 互不相干，卻一個做完才做下一個。沒有錯誤，只是白白把三步的時間加總，慢三倍。
  • 把有依賴的平行掉：把 D（比對）和 C（摘要）同時發動，D 拿到的是還沒算完的摘要，產出不一致甚至基於空值。這種錯比較隱蔽，因為它「跑得很快」，但結果是錯的。

​
3. 常見模式：從機械原語到具名模式

四個原語（primitive）是你編排時實際操作的積木；Anthropic 把它們組合成五個更高層的具名模式。先掌握積木，再認得組合，遇到新框架只是換語法。 四個機械原語：
  • pipeline（串接）：A → B → C，每步輸出餵給下一步。適合線性轉換。對應 Anthropic 的 prompt chaining：把複雜任務拆成依序的步驟，每步之間可以插程式化檢查點（checkpoint）確認進度再往下 [1]。
  • fan-out（扇出）：同一個輸入同時送給多個平行步驟。適合對同一份資料做多視角分析（同時查安全、效能、型別）。
  • barrier（屏障）：等所有平行分支都完成才繼續。fan-out 之後通常接 barrier 再聚合。fan-out + barrier 合起來就是 Anthropic 的 parallelization，它又分兩種變體：sectioning（把任務切成互不相干的子任務同時跑）與 voting（同一個任務跑多次拿多個獨立結果再表決）[1]。
  • loop-until（收斂迴圈）：重複執行直到驗證通過或達上限。適合品質迭代與自我修正。對應 Anthropic 的 evaluator-optimizer：一個 LLM 呼叫產出、另一個給評分與回饋，在迴圈裡逼近合格 [1]。
barrier 是有代價的，預設用 pipeline一個常見的過度同步：先 fan-out 三個分支、用 barrier 等全部完成、再把結果統一往下送。但如果三個分支裡有一個特別慢，barrier 會讓另外兩個快的乾等。除非下一步真的需要所有分支的結果一起到齊（例如要跨全部結果去重、或比對彼此），否則讓每個分支各自獨立往下走（pipeline 化）才不浪費。判準：下一步是否需要「跨分支的全局資訊」？需要才設 barrier，不需要就別擋。
何時模式會「升級」成 agent？ 上面四個原語的跳轉都是你預先定義好的。當「要拆成哪些子任務」這件事本身得由模型看了輸入才能決定，預先寫不出來，你就需要 Anthropic 的另外兩個模式：
  • routing（路由）：先用一個分類步驟判斷輸入屬於哪一類，再導向對應的專門處理。本質還是 workflow（路由表是你定的），但多了一層動態分派。
  • orchestrator-workers（協調者-工作者）：一個中央 LLM 動態拆解任務、把子任務分派給 worker、再綜合結果 [1]。和 parallelization 的關鍵差別是：子任務不是預先定義的，而是 orchestrator 看了輸入才決定的。到這一步，你已經一腳踏進 agent 領域了，控制權部分交給了模型。
一個你手邊就有的具體 workflow：對抗式程式碼審查 場景：審查一個分支的改動。用 pipeline 把「審查」和「驗證」兩階段串起來，並對多個維度 fan-out。 
維度清單 = [正確性， 安全性， 效能， 風格]
對每個維度（pipeline，互相獨立、不設 barrier）：
  階段 1：spawn 一個子代理審查該維度 → 回傳 findings（結構化）
  階段 2：對每條 finding，spawn 獨立子代理「對抗式查證」→ 回傳 verdict
最後：收集所有 verdict.isReal == true 的 findings
為什麼這樣設計：四個維度互不相干，pipeline 化讓「正確性」的查證在「效能」還在審查時就能開跑，不被最慢的維度拖住（對照上面的 barrier 警告）。階段 2 的對抗式查證是第 4 節的重點，先記住它的位置。Claude Code 的子代理（Task 工具）與 SDK 層的 orchestrator 模式正是為這種編排設計的（截至 2026-05）[2]。

​
4. 驗證與收斂：在關鍵節點放對抗式驗證

不放驗證的後果很具體：上游一個小錯，會在後續每一步被當成正確前提繼續放大，等到三步後產出明顯不對時，你已經難以歸因是哪一步壞的，而且中間每一步消耗的 token 全部白費。驗證關卡的價值，是把錯誤擋在它還便宜的時候。 「驗證」最弱的形式是讓同一個模型自己檢查自己，但模型傾向認同自己剛才的輸出，效果有限。更強的是對抗式驗證（adversarial verify）：用不同視角、或獨立的模型呼叫，去「挑戰」前一步的輸出，而不是「確認」它。 兩個關鍵設計手法：
  • 角色換成挑剔者：驗證步驟的 prompt 不要寫「檢查這個結果對不對」，要寫「試圖反駁這個結論，不確定時預設判為不成立」。把舉證責任反過來，假陽性才壓得下去。
  • 多視角而非多份相同：若一個結論可能以多種方式出錯，給每個驗證者不同的鏡頭（正確性、安全性、能否重現），比跑三份一模一樣的檢查更能抓到不同的失效模式。這正是 Anthropic parallelization 裡 voting 的用法 [1]。
收斂關卡（尤其 loop-until）必須有三個明確的出口條件，缺一個都可能在生產環境變成資源黑洞：
  1. 通過標準：用結構化的 pass / fail schema，不要用「看起來還行」這種模糊判斷。
  2. 最大重試次數：迭代到第 N 次仍不過就停，別無限迭代。
  3. 逾時退出：單輪或整體超過時間上限就中止。
loop-until + 對抗式驗證的收斂迴圈 任務：產生一段要併入主幹的程式碼，要求通過測試且無明顯安全問題。 
bugs_confirmed = []
for round in 1..MAX_ROUNDS:          # 最大重試上限
    候選 = 生成步驟（任務， 前一輪回饋）
    # 對抗式：3 個獨立 reviewer，各自試圖反駁「這段是安全且正確的」
    votes = parallel(reviewer_1, reviewer_2, reviewer_3)
    refute_count = count(v for v in votes if v.refuted)
    if refute_count == 0:            # 通過標準：無人能反駁
        return 候選                  # 收斂，跳出
    回饋 = 彙整（votes）               # 把反駁意見餵回下一輪
return 失敗（"未在上限內收斂"）        # 出口：別讓它無限轉
三個 reviewer 平行跑（fan-out + barrier 等票），多數能反駁就打回重來。沒有 MAX_ROUNDS 這行，一旦遇到模型怎麼改都過不了的案例，這個迴圈會燒到你發現帳單為止。Claude Code 的 Stop hook 可以充當這個收斂哨兵，在每回合結束時做確定性的 pass / fail 檢查（截至 2026-05）[2]。

​
5. 概念階梯定位

在工程四層裡，workflow 佔 L3：它向下依賴 L2 context 的品質，向上需要 L4 harness 兜底（四層由淺入深，見 01-3 prompt、01-4 context、本單元 workflow、01-6 harness）： 
L1 Prompt engineering   ── 單次請求怎麼寫
L2 Context engineering  ── 視窗裡該有什麼
L3 Workflow engineering ── 多步驟用什麼結構串（本單元）
L4 Harness engineering  ── 讓整套穩定運轉的外殼（監控、權限、kill switch）
兩條邊界要記牢：
  • 向下接 context：workflow 的每一個節點，本質上都是一次 context 組裝。節點產出的品質，上限由你給它的 context 品質決定（見 01-4）。workflow 結構再漂亮，單個節點的 context 設計爛，產出一樣爛。workflow 放大良好設計，也放大爛設計。
  • 向上接 harness：workflow 只描述「步驟怎麼串」，它不負責「跑壞了誰來踩剎車」。把監控、權限邊界、記憶持久化、kill switch 加上去，才是完整的 agentic harness（見 01-6）。只做好 L3 卻不設 L4 的 kill switch，等於裝了賽車引擎卻沒有剎車。
這個定位也直接破掉兩個常見誤判：把 workflow 當成能修復爛 prompt 的萬靈丹（它不能，它只放大），以及把某個 agentic 框架當成做 workflow 的唯一選項（多數時候一段帶迴圈與條件判斷的程式就夠了）。

​
工具對照

把多步編排落地，主要有三類載體，適用場景不同（截至 2026-05）：
  • Claude Code 的子代理編排：在 orchestrator prompt 裡用 Task 工具 spawn 多個子代理，每個子代理有獨立上下文、自己的工具集，只回傳最終結論而非過程 [2]。適合「編排對象就是 LLM 工作」且想留在 Claude 生態內的情況。Anthropic 於 2026-05-28 推出研究預覽的 Dynamic Workflows 作為更大任務的編排層、以及以 git 共享工作區協作的 Agent Teams（截至 2026-05，研究預覽）[2]。
  • n8n：視覺化低程式碼 workflow，節點對應步驟，強項是整合大量外部服務（資料庫、API、訊息平台）。其 AI 能力以 LangChain 為底，提供 70 個以上 AI 節點，AI Agent 節點預設走 Tools Agent，並支援「工具執行前需人工核准」的 human-in-the-loop（截至 2026-05）[4]。適合流程橫跨許多 SaaS、且希望非工程角色也能看懂改動的場景。
  • LangGraph：以 Python / TypeScript 把流程描述成圖，三個原語是 State（所有節點共享的狀態）、Node（讀寫 state 的函式）、Edge（直接或條件跳轉）。1.2 版（2026-05-11 釋出）把一次 agent 執行當成可持久的圖執行（durable execution），靠 checkpointing 在每個節點存檔，server 重啟也能從斷點續跑 [3]。適合需要細粒度控制、狀態持久化與 human-in-the-loop 的 agentic 流程。
三者的取捨：除錯可見性 n8n（視覺化）最直觀；細粒度控制與可測試性 LangGraph 最強；想完全留在 Claude 生態、編排對象就是 LLM 子任務，Claude Code 子代理最省事。
概念Anthropic Claude（主範本）OpenAIGoogleGitHub CopilotCursor
多步任務編排入口Claude Code Task 工具 / 子代理；SDK orchestrator 模式Agents SDK / Responses API（含工具呼叫）Vertex AI Agent Builder；Gemini API function callingCopilot coding agent（雲端自主、開 PR）Background agents
平行子任務（fan-out）orchestrator prompt 內 spawn 多個 Task 子代理，各自獨立上下文Agents SDK 多代理 handoff需確認原始出處需確認原始出處Background agents 平行
loop-until / 自我修正orchestrator 條件判斷再呼叫；Stop hook 作收斂哨兵Agents SDK 迴圈 + guardrails需確認原始出處需確認原始出處需確認原始出處
外部 workflow 整合n8n、LangGraph 皆可呼叫 Claude APIn8n、LangGraph 皆支援 OpenAIn8n、LangGraph 皆支援 Gemini經 API 整合經 API 整合
對照表只給座標，不給細節各 cell 的精確機制名稱、版本與設定路徑屬快變動事實，部分以較穩定的描述呈現；無法確認的標「需確認原始出處」，精確名稱以該工具官方文件為準。本表用途是讓你知道「同一個編排概念在你的工具叫什麼」，深入設定見 Part II 與 Part IV。

​
動手做

兩個練習，從紙上拆解到實際編排：
  1. 把一個現有手動任務畫成 DAG。 挑一個你平常手動跑的多步流程（例如：蒐集資料 → 各別摘要 → 交叉比對 → 撰寫報告）。畫出節點與依賴邊，標出哪些節點可平行（沒有路徑相連的）、哪些必須有序。再問每個節點三件事：輸入從哪來、輸出給誰用、通過標準是什麼。哪個節點最該加驗證關卡（通常是「錯了會被下游當正確前提放大」的那個）？
  2. 用 Claude Code 實作一個最小 pipeline。 三步串接，第二步驗證第一步的輸出： 
    # orchestrator prompt 的骨架（交給 Claude Code 主代理執行）
步驟 1：派子代理 A 讀取 src/ 並產出「模組依賴清單」（結構化 JSON）。
步驟 2：派子代理 B 對抗式查證該清單，逐項確認檔案與符號真的存在；
        不存在的標記為 invalid。schema 不通過則退回步驟 1 重做（上限 2 次）。
步驟 3：僅以通過查證的項目，產出重構建議。
    把「驗證」獨立成一個帶 pass / fail 與重試上限的節點，就是這個練習的重點。再加一個 Stop hook 做確定性收尾檢查，這個 pipeline 就有了收斂哨兵。

​
常見誤區

反模式清單
  • 把 workflow 當成萬靈丹：workflow 只是結構。某個節點的 prompt / context 設計爛，再好的流程也救不回來，反而會把爛輸出原樣傳下去放大。先把單節點做對，再談編排。
  • 跳過驗證節點：假設上游輸出正確、直接串下一步。錯誤往往三步後才浮現，既難歸因又把中間每步的 token 全浪費掉。錯誤要擋在它還便宜的時候。
  • 過度拆解：把本可一次 prompt 完成的任務硬拆成五步，徒增延遲與狀態管理複雜度。先確認單 prompt 真的勝任不了再拆。
  • 濫設 barrier：凡 fan-out 必接 barrier 等全部完成。下一步若不需要跨分支的全局資訊，barrier 只會讓快的分支乾等最慢的。預設 pipeline，barrier 是例外。
  • loop 沒有出口：loop-until 不設最大迭代與逾時。一旦遇到收斂不了的案例，生產環境會無限消耗資源直到你發現帳單。
  • 該用 workflow 卻硬上 agent：把控制權交給模型動態決定（orchestrator-workers）看起來省事，代價是可預測性與可重現性。能用預先定義路徑的 workflow 解的，就別交給模型自由發揮。

​
自我檢核

通過本單元的標準
  1. 給你一個多步任務，你能不能講清楚它為什麼超出單 prompt 的範圍（輸出長度、上下文深度、還是外部取值）？答不出來，可能根本不需要拆。
  2. 你設計的 workflow，能否對每個節點回答「輸入從哪來、輸出給誰用、通過標準是什麼」？任何一個節點答不出來，設計就還沒成熟。
  3. 你的 fan-out 後面那個 barrier，是真的需要跨分支的全局資訊，還是只是順手擋了一下？
  4. 你的 loop-until 有沒有明確的最大迭代上限與逾時退出？
  5. 你能分清自己現在做的是 workflow（路徑預先定義）還是 agent（模型自己決定路徑）嗎？兩者的可重現性代價不同。

​
來源與延伸閱讀

事實主張依官方文件，快變動項標註截至 2026-05；採 IEEE 編號制。