第 5 章 · AI Workflow 與編排：把 AI 串成穩定的流水線

單次呼叫模型能做的事有限。真實產品往往需要很多步：先分類、再檢索、再生成、再檢查……把多次 AI 呼叫（和一般程式邏輯）串成一條流程，就是 AI Workflow（AI 工作流）。這一章也會講清楚一個最常被搞混的區別：Workflow 和 Agent 到底差在哪。

💡 這一章你會懂：workflow 與 agent 的分野、五個能解決 80% 問題的設計模式、以及 n8n / LangGraph 這些工具各自的定位。

先給個具體畫面，你就懂為什麼「一次呼叫」不夠用。假設你要做一個「自動回覆客服 email」的功能：光丟一句「幫我回這封信」給模型，它只能憑信件內容瞎猜——它不知道這位客人買了什麼、訂單到哪了、公司的退款政策是什麼。像樣的做法會是：先判斷這封信在問什麼（退款？出貨？投訴？）→ 去資料庫撈這位客人的訂單→ 根據撈到的資料生成回覆→ 最後檢查語氣有沒有失禮、有沒有亂承諾。你看，這已經是四步、而且中間還混著「查資料庫」這種非 AI 的動作了。這種「多步、AI 與程式邏輯交錯」的東西，就是這一章的主角。

先分清楚：Workflow vs Agent

這是本章、甚至整門課最重要的一個區別：

把這個分野再講白一點：差別的核心在於**「決定下一步要做什麼」的權力，握在誰手上**。

• Workflow：這個權力握在你（開發者）手上。你在寫程式或拉流程圖的時候，就已經把「第一步做 A、然後做 B、如果條件成立就做 C」全部釘死了。模型只是流程裡的一顆螺絲，被叫到的時候做好它那一格的事（分類、生成、翻譯……），做完就把棒子交回給你寫好的流程。路線圖是你畫的，模型不能改道。
• Agent：這個權力交給了模型。你只給它一個目標（「幫我把這個 bug 修好」）和一箱工具（讀檔、改檔、跑測試），接下來每一步要用哪個工具、要不要再試一次、什麼時候算做完，都是模型自己邊做邊決定。它自己在跑一個「觀察 → 思考 → 行動 → 再觀察」的循環。（這個自主循環正是第 7 章 Agent 的主角，這裡先不展開。）

一句話記住這個對比：workflow 是「你排好路線、它照走」；agent 是「你給個目的地、它自己找路」。 火車和計程車的差別，就是鐵軌是誰鋪的。

💡 最重要的實務建議：先用 workflow，不夠用再上 agent。 很多人一上來就想做「自主 agent」，結果又貴又難除錯又不穩。事實上，市面上大多數穩定的 AI 產品，骨子裡是工作流，不是 agent。

為什麼「大多數穩定產品其實是 workflow」？這句話值得多挖一層，因為它反直覺——新聞天天在講 agent，怎麼實際能上線賺錢的反而是 workflow？三個很現實的原因：

1. 能除錯，才敢上線。workflow 的每一步都是你定好的，出錯時你能一格一格看「是路由分錯類？還是生成那步爆掉？」，像看流程圖一樣抓問題。agent 自己決定路徑，這次走五步、下次走十二步，出錯時你連「它為什麼這樣走」都要重新拼湊——難除錯的東西，公司不敢押上真實客戶。
2. 成本與延遲可控。workflow 呼叫幾次模型是固定的、你算得出來，一筆客服信固定花 3 次呼叫，成本好估、速度好保證。agent 為了自己摸索，可能為一件事來回呼叫幾十次，帳單和等待時間都飄忽不定，難以對客戶承諾「幾秒內回覆」。
3. 多數任務其實沒那麼開放。你冷靜拆解就會發現：「回覆客服信」「幫合約抓風險條款」「把會議記錄轉成待辦」——這些聽起來很 AI 的任務，步驟其實是固定的、畫得出流程圖的。既然畫得出流程圖，就沒必要花大錢請一個「自己找路」的 agent，用「排好路線」的 workflow 又穩又省。

換句話說：agent 的「自主」是要付代價的（貴、慢、難控），只有當任務真的開放到你畫不出流程圖時，這個代價才划算。 這也是本章最後那個「四問把關」的由來。

這一章講 workflow（可控的那半邊），第 7 章才講 agent（自主的那半邊）。

🔧 動手試試：挑一件你最近讓 ChatGPT / Claude 幫你做、但覺得「一次講不清楚、要來回好幾輪」的事（例如寫一篇文章、整理一份報告）。試著把它拆成 3～5 個固定步驟寫下來——例如「1. 先列大綱 → 2. 逐段展開 → 3. 統一語氣 → 4. 挑錯字」。你剛剛就手動設計了一條 workflow。如果每一步都畫得出來，恭喜，這件事根本不需要 agent。

五大設計模式（能解決大部分問題）

這五個模式是業界公認的 AI 工作流基本功。學會它們，你就有一套「積木」可以組合。下面每一個都配一個看得到畫面的真實場景，讓你不只知道定義，還知道它長什麼樣。

1. Prompt Chaining（串接）

把大任務拆成幾步，前一步的輸出當後一步的輸入。例：先「產生大綱」→ 再「照大綱寫全文」→ 再「潤稿」。就是第 2 章「拆步驟」的程式版。

為什麼要拆？因為一步做太多，模型容易顧此失彼——你叫它「一次寫出一篇結構好、資料正確、文筆又順的文章」，它常常結構顧到了文筆就垮、或反過來。拆成一步一個小目標，每一步都做得又穩又好，還能在中間插入檢查點。代價是慢一點、多花幾次呼叫，但換來的是品質與可控。

真實場景：一家公司要把英文的產品文件翻成中文並發佈。它的流程是——第一步先請模型翻譯成中文初稿；第二步把初稿丟回去，請模型對照原文校對、修掉翻譯腔和誤譯；第三步再請模型按照公司的用語規範潤飾（例如統一「使用者」不要一下「用戶」一下「使用者」）。三次呼叫、一步接一步，每一步的輸出都是下一步的輸入。你如果想一次叫模型「翻譯、校對、潤飾一次到位」，品質往往比拆三步差得多。

2. Routing（路由）

先用一次呼叫判斷類型，再分派給不同的後續處理。例：客服訊息先分「退款／技術問題／一般諮詢」，各自走不同流程（還能把簡單的丟給便宜模型——呼應第 4 章）。

為什麼要先分類？因為不同類型的問題，最好的處理方式天差地遠。硬用「一套萬用流程」應付所有問題，等於逼一個流程同時要會退款、又要會查技術文件、又要會閒聊，樣樣通樣樣鬆。先花一次便宜的呼叫把問題「分流」，讓每一條支線只專心處理一種問題，整體又準又省。

真實場景：一個線上服務的客服信箱，每天湧進幾百封信。系統先用一次便宜又快的小模型讀信、判斷它屬於哪一類：如果是「我要退款」→ 導進退款流程（去查訂單、確認資格、走退款 API）；如果是「你們的功能壞了」→ 導進技術支援流程（撈系統日誌、比對已知問題）；如果只是「請問你們有中文介面嗎」→ 導進一般問答流程（直接用 FAQ 回答）。分類這一步用小模型（便宜、夠用），只有真正需要動腦的支線才動用大模型——成本可以差好幾倍。

3. Parallelization（平行）

把可獨立進行的子任務同時做，最後合併。例：要審一份文件的「法律、資安、財務」三個面向，三個一起跑，快 3 倍。

為什麼能平行？關鍵是這些子任務彼此不依賴——法律面的審查不需要等資安面的結果。既然互不相干，就沒理由排隊一個做完再做下一個，同時發車最快。這跟前面的 Chaining 剛好相反：Chaining 是「後一步需要前一步的結果，只能排隊」；Parallelization 是「大家互不相欠，一起上」。判斷用哪個，就看子任務之間有沒有先後依賴。

真實場景：一家公司要用 AI 初審每一份要簽的合約。它把同一份合約同時丟給三個各有專長的呼叫：一個專門抓法律風險（有沒有不利的責任條款）、一個專門抓資安問題（資料會不會外流給對方）、一個專門抓財務條件（付款期、罰則合不合理）。三個各看各的、同時進行，最後把三份意見彙整成一張總表給法務主管過目。如果排隊一個一個審，要花三倍時間；平行做，幾乎跟只審一個面向一樣快。

🔧 動手試試：想一件你手上「一份東西要從好幾個角度看」的事——例如請 AI 幫你的履歷從「排版、內容說服力、錯字」三方面各給一次意見。先體會「排隊問三次」有多慢，再想像這三個角度其實可以同時問（它們互不依賴）。你就懂 Parallelization 省在哪了。

4. Orchestrator–Workers（主管–工人）

一個「主管」模型把任務動態拆解成子任務，分給多個「工人」模型做，再彙整。適合「事前不知道會拆成幾塊」的任務。

它跟 Parallelization 有什麼不同？關鍵在**「要拆成幾塊」是誰決定的**。Parallelization 的子任務是你事先固定好的（永遠是法律、資安、財務三塊）；Orchestrator 則是主管模型當場才決定要拆成幾塊、拆成哪些塊——因為你事前根本不知道。這是它比較「聰明」、但也比較接近 agent、比較難控的地方（拆解權交給了模型）。所以能用固定的 Parallelization 解決，就別動用 Orchestrator。

真實場景：你叫系統「幫我研究一下這家公司值不值得投資」。這件事事前無法固定拆法——因為要查幾個面向、每個面向查什麼，得看這家公司是什麼行業才知道。於是「主管」模型先讀題、當場規劃：這次要查「財報表現」「主要競爭對手」「近期新聞風評」「管理團隊背景」四塊，接著把這四塊分派給四個「工人」模型各自去查、各寫一段，最後主管再把四段彙整成一份投資摘要。換一家公司，主管可能就拆成完全不同的幾塊。這種「拆幾塊、拆什麼由模型臨場決定」的彈性，是它跟固定式平行最大的差別。

5. Evaluator–Optimizer（產出–評審）

一個模型負責產出，另一個模型負責評審打分並給修改意見，來回幾輪直到夠好。例：翻譯 → 評審挑毛病 → 再翻 → 再評。

為什麼要分兩個角色？因為**「創作」和「挑錯」是兩種不同的心態，同一個模型一口氣做完，往往看不到自己的毛病**——就像自己寫的文章很難校出自己的錯字。拆成「產出者」和「評審者」兩個角色，評審專心挑刺、產出者專心改進，來回幾輪，品質會明顯往上爬。這招特別適合**「好壞有明確標準、值得多磨幾輪」**的任務。

真實場景：一家公司要把行銷文案翻成道地的日文。第一個模型先翻譯出一版；第二個模型扮演「嚴格的日文母語編輯」，評審這版哪裡讀起來像機器翻的、哪裡敬語用錯、哪裡不夠有廣告感，並列出具體修改意見；然後把這些意見丟回給第一個模型重翻；再交給評審看一次。這樣來回兩三輪，直到評審說「這版夠道地了」才停。比起翻一次就交出去，成品的品質差非常多——代價是多花了幾輪的時間和呼叫成本。

flowchart LR
    subgraph 五種積木
    A[Chaining<br/>一步接一步] 
    B[Routing<br/>先分類再分流]
    C[Parallel<br/>同時多路]
    D[Orchestrator<br/>主管拆解分派]
    E[Evaluator<br/>產出↔評審]
    end

💡 這五種可以互相組合。真實產品常是「路由 → 平行檢索 → 串接生成 → 評審」這樣拼出來的。

把上面那句「組合」講成一個完整故事你就更有感了。回到開頭那個「自動回覆客服 email」的例子，一個成熟的版本可能長這樣：先 Routing 判斷這封信是退款還是技術問題 → 走進退款支線後先 Parallelization 同時去撈「訂單資料」和「退款政策」 → 拿到資料後用 Chaining 一步生成回覆草稿、一步套上公司的禮貌用語 → 最後用 Evaluator 檢查草稿有沒有亂承諾、語氣有沒有失禮，不 OK 就退回重寫。你看，一個像樣的產品，往往就是這五塊積木拼出來的——沒有一個模式能單獨包辦，但湊在一起就很強。

🔧 動手試試：拿你在本章第一個「動手試試」拆出來的那條流程，回頭對照這五大模式，替每一步貼一個標籤——「這步是 Chaining、那步其實是 Routing……」。貼不上標籤的步驟通常是「純程式邏輯」（例如查資料庫、寄信），那也完全正常，工作流本來就是「AI 積木 + 程式邏輯」混搭而成的。做完這個練習，你對五大模式就從「背定義」升級成「會辨認」了。

工具生態：No-code 與 Code 兩條路

你不一定要寫程式才能做工作流。依你的角色選工具：

No-code / Low-code（拖拉即可）

用視覺化介面把節點連起來，適合非工程師、快速做自動化：

這裡花點篇幅講一下 n8n，因為它是本章標題點名、也是最適合新手上手的一個。你可以把它想成一塊數位樂高板：畫面上每一個方塊叫節點（node），代表一個動作——「收到一封新 email」是一個節點、「呼叫 AI 模型」是一個節點、「把結果寫進 Google 試算表」又是一個節點。你用拉線的方式把這些節點串起來，資料就會像水一樣，從左邊的節點流到右邊的節點。最左邊通常是一個**觸發器（trigger）**節點——它決定「這條流程什麼時候啟動」（例如每天早上九點、或每次收到新訊息）。整條線拉完、打開開關，這個自動化就會 24 小時替你跑，完全不用寫一行程式。前面講的五大模式，在 n8n 裡幾乎都能用「拉節點」拼出來：Routing 就是拉一個判斷節點再分岔出幾條線、Parallelization 就是從一個節點拉出好幾條線同時跑。

Code（寫程式，彈性最大）

要精細控制、要進版控、要接進既有系統，就用框架：

💡 選擇原則：非工程師或快速驗證 → n8n / Dify；要進產品、要控制細節 → 程式框架或自己刻（第 11 章你會發現，自己刻其實沒想像中難）。

再補一個更根本的觀念：no-code 工具沒有魔法，它只是把「寫程式」這件事換成「拉節點」。 你在 n8n 裡拉的每一條線、每一個節點，本質上都對應到程式裡的一段邏輯（一次呼叫、一個 if 判斷、一個迴圈）。所以這兩條路不是「初學者走 no-code、高手走 code」的高低之分，而是看情境選工具：要快速驗證一個點子、給非工程師用、或流程不太複雜，拖拉最爽；要精細控制、進版本控管、接進公司既有的大系統，寫程式才罩得住。很多團隊是先用 n8n 拉個雛形驗證想法，確認可行後再用程式重寫成正式版——兩條路接力用，不是二選一。

🔧 動手試試：去 n8n 官網（有免費方案或可自架）或 Dify，開一個最陽春的流程——例如「手動觸發 → 呼叫一次 AI 模型問一個固定問題 → 把回答顯示出來」。光是親手把兩三個節點拉起來、跑一次看到資料流過去，你對「工作流」這個抽象詞的體感，會比讀十頁文字都強。

什麼時候該從 Workflow 升級到 Agent？

當你發現——「這個任務的步驟我根本沒辦法事先畫成流程圖」，那就是該考慮 agent 的時候。

反過來說，這也是本章的核心分界線：只要你畫得出流程圖，就用 workflow（火車，照你鋪的鐵軌走）；畫不出來、每次該做什麼都得看狀況臨場決定，才輪到 agent（計程車，司機自己找路）。前面反覆強調「先用 workflow」，就是因為大多數任務其實都畫得出流程圖，只是你還沒冷靜拆解而已。

判斷四問（四個都「是」才值得上 agent）：

1. 複雜：任務多步、且無法事先完整規劃？
2. 值得：結果的價值撐得起 agent 更高的成本與延遲？
3. 可行：模型的能力真的做得到這個任務？
4. 可補救：萬一它做錯，錯誤抓得回來（有測試、有審核、能回退）？

只要有一個「否」，就退回用更簡單、更可控的 workflow。

用一個對比把這四問講活：「幫我把這份合約的付款條款抓出來」 vs 「幫我把這個開源專案的某個 bug 修好」。前者你畫得出流程圖（讀合約 → 找付款相關段落 → 抽出來 → 格式化），第 1 問就是「否」，用 workflow 就好，別浪費錢。後者呢？要改哪個檔、改完要不要跑測試、測試沒過要不要再改——每一步都得看上一步的結果臨場決定，你事前畫不出這張流程圖（複雜✓），修好一個 bug 省下工程師大把時間（值得✓），現在的模型讀 code 改 code 確實做得到（可行✓），而且改錯了有測試會擋、有版控能回退（可補救✓）。四問全過，這才是真正該上 agent 的場景——這也正是第 11 章你要親手打造的東西。

🔧 動手試試：拿兩件你想交給 AI 的真實任務，各自跑一遍上面的「四問」。你會發現絕大多數任務卡在第 1 問就出局了（步驟其實畫得出來）——這正好親身驗證了本章那句話：大多數穩定產品其實是 workflow，不是 agent。 真能四問全過的任務，遠比你以為的少。

重點回顧

• Workflow = 路徑你定好（火車）；Agent = 模型自己決定（計程車）。先用 workflow，不夠再上 agent。 差別的核心是「決定下一步的權力握在誰手上」——你，還是模型。
• 大多數穩定產品其實是 workflow，不是 agent：因為 workflow 好除錯、成本可控、而且多數任務本來就畫得出流程圖；agent 的「自主」要付出貴、慢、難控的代價。
• 五大設計模式：Chaining、Routing、Parallelization、Orchestrator–Workers、Evaluator–Optimizer——可自由組合，真實產品往往是它們拼出來的。分清楚兩組容易混的：Chaining（有先後依賴、排隊）vs Parallelization（互不依賴、同時）；Parallelization（拆法你固定）vs Orchestrator（拆法模型臨場決定）。
• 工具兩條路：n8n / Dify（no-code、拉節點、快）與 LangGraph / LlamaIndex（code、細）。no-code 沒有魔法，只是把寫程式換成拉節點，常見做法是先拉雛形、再用程式重寫。
• 升級到 agent 前，用複雜／值得／可行／可補救四問把關；只要一個「否」，就退回 workflow。

工作流讓 AI 能跑複雜流程，但它回答的內容仍受限於「模型腦中學過的東西」。下一章，我們讓它能引用你的、最新的知識——這就是紅遍半邊天的 RAG。