Workflow vs Agent

TL;DR

• Workflow：路徑寫死的 LLM 流水線——chain / route / parallelize，每一步都是你決定的
• Agent：模型自己決定下一步——更靈活，但更難 debug、更難 eval、成功率較低
• 大部分 production case 用 workflow 就夠了，不要為了 agentic 而 agentic

一個情境：客服信件處理

老闆又丟了一個任務：「客服信件量太大，幫我做個自動處理系統。」

你坐下來想，流程其實很清楚：

收信 → 分類（退款 / 帳號 / 技術 / 其他）→ 套對應模板草稿 → 客服審 → 寄出

每一步要做什麼、用哪個 prompt、輸出什麼格式，都可以事先畫出來。這就是一個 workflow——不是 agent。

換另一個情境：「幫我訂下週去東京的機票，預算三萬內，能轉機就轉機，不能轉就直飛，順便挑個離車站近的飯店。」

這個任務你寫不出固定流程——要查幾個航空公司？查到一半預算超了要不要改方案？飯店比價要看幾家？模型要自己決定下一步。這才是 agent 的場景。

對照表

	Workflow	Agent
流程路徑	你寫死	Claude 自己決定
步驟數	已知	未知，可能會 loop
成功率	高、可預期	較低、較不穩
Eval 難度	容易（每步分開測）	難（路徑太多）
適合	已定義好的問題	任務參數無法事先列舉
比喻	GitHub Actions	「自己決定要 push 到哪」

兩個一起讀的觀察：workflow 把大任務切成小任務、每個小任務 Claude 只專注一件事，所以準確率比 agent 高。Agent 的彈性是用「成功率」跟「可觀測性」換的。

為什麼 workflow 比較準

把「寫一篇有 5 條限制的技術文章」塞進一個 prompt，Claude 常常會違反其中幾條。但拆成兩步——先寫初稿、再用第二個 prompt 修——準確率立刻升高。

原因很簡單：單一 prompt 要它同時兼顧多件事，注意力會分散。切開後每一步只專注一個目標，就跟人類做事一樣。

這也是為什麼大部分「看起來像 agent」的 production 系統，拆開來其實是 workflow——只是包了一個會講人話的對話介面。

你其實已經寫過 agent 了

回想 Section 4 的 multi-turn tool use：

你給 Claude tools → Claude 決定要不要 call → 你執行 → 把結果丟回去 → 重複直到 stop_reason=end_turn

這個 loop 就是最基本的 agent。Agent = LLM + tools + loop + 結束條件。下一篇會把它拆得更細。

什麼時候才該升級到 agent

問自己三題：

1. 我事先列得出所有可能的流程分支嗎？（列得出 → workflow）
2. 使用者輸入的範圍封閉還是開放？（封閉 → workflow）
3. 我有辦法eval 每一步嗎？（沒辦法 → 先別做 agent）

三題都偏向「不」才考慮 agent。即使如此，先用 workflow 把能處理的部分處理掉，agent 只負責真的需要動態決策的那一段。Claude Code 就是這樣設計的——多數工作其實是固定 pattern，只有「這個 task 該分幾步、用哪些 tool」交給模型決定。

接下來

下一篇會把 workflow 拆成三個基礎招式——chaining、routing、parallelization。這三個 pattern 不是抽象概念，而是你會在每個 production LLM 系統裡反覆看到的組合元件。理解它們之後，agent 也只是這些 pattern 的動態組合。