準備 AI 應用或 AI 產品職位的面試，「能用 workflow 解決，為什麼還要用 Agent？」是很容易答成口號的一題。「Agent 比較智能」「Agent 能自主決策」都不算錯，可是一被追問就接不下去：什麼時候不該用？代價在哪？能不能舉個例子？
這題比較穩的答法，是講一個判斷順序，而不是比較兩個詞誰比較先進。可以引的依據是 Anthropic 在 2024 年 12 月 19 日發表的工程文章 Building effective agents：先找最簡單的解法，單次模型呼叫加上檢索通常就夠；任務定義清楚時 workflow 提供可預測、一致的結果；需要彈性與由模型主導決策時才輪到 Agent，同時要面對它的成本。原文也註明，文中提到的工具生態在 2024 年 12 月之後已有變動，引用時記得帶上日期。
圖解：KeepInAI。依 Anthropic 建議整理的示意判斷順序。
兩者差在誰決定下一步，不在有沒有迴圈
這一問在確認你能不能用一句話分清兩者，而不是各列一串特徵。
Anthropic 那篇的定義很直接。Workflow 是「systems where LLMs and tools are orchestrated through predefined code paths」，由預先寫好的程式路徑來編排模型和工具；Agent 則是「LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks」，由模型自己動態決定流程和工具怎麼用，也自己掌握要怎麼完成任務。
答案骨架就一句：差別在下一步由誰決定。Workflow 的步驟在寫程式時就排好了，模型在每一步裡做事；Agent 的步驟由模型邊做邊決定。口語上常有人說「workflow 像流程圖，Agent 自己琢磨做法」，這個比喻和定義一致，可以拿來開頭，但後面要接上定義，不要只停在比喻。
常見的說錯，是拿「有沒有迴圈」或「會不會用工具」來分。照上面的定義，workflow 本來就會編排工具；後面會提到的 evaluator-optimizer 是一個模型產生、另一個評估、反覆迴圈的模式，原文仍歸在 workflow。所以有迴圈、有工具，都不代表是 Agent。要看的是步驟的順序和走向，是事先寫在程式裡，還是交給模型臨場決定。
判斷順序：先問一次模型呼叫夠不夠
這一問在確認你知不知道 Agent 不是預設選項，以及說不說得出什麼時候才該升級。
Anthropic 的建議是「we recommend finding the simplest solution possible, and only increasing complexity when needed.」先找最簡單的解法，有需要才加複雜度。它還說「For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough.」很多應用把單次 LLM 呼叫配上檢索和範例調好，通常就夠了。
答案骨架可以分三層：
- 先問單次呼叫加上檢索、加上範例夠不夠。
- 不夠，而且步驟可以事先列出，就做 workflow。原文的說法是「workflows offer predictability and consistency for well-defined tasks」，任務定義清楚時，workflow 給的是可預測、一致的結果。
- 需要彈性、由模型主導決策時，才考慮 Agent：「agents are the better option when flexibility and model-driven decision-making are needed at scale」。換成口語，大致就是下一步得看結果才知道。這一句是我們的轉述，不是原文。
原文另有一句把話說得更明白：「add multi-step agentic systems only when simpler solutions fall short.」簡單做法不夠時，才加入多步驟的 agentic 系統。
常見的說錯，是把 Agent 說成 workflow 的升級版，好像越往後越先進。照這個順序，Agent 是條件成立時才選的選項，不是終點。只說 Agent 更強、更靈活，卻講不出什麼時候不該用，聽起來就像在背口號。
五種 workflow 模式，各配一個講得出來的例子
這一問在確認你知道 workflow 不只是把 prompt 一條條串起來，以及每種模式各在解決什麼。Anthropic 那篇列了五種。下面每種一句說明，例子是我們設計的示意情境，不是實測案例。
- Prompt chaining：把任務拆成順序步驟，步驟之間可以加檢查。例如整理客戶會議逐字稿：先抽出待辦事項，用程式檢查每一項都有負責人和期限，通過了再寫成會後信件。
- Routing：先把輸入分類，再分流到專門的後續步驟。例如客服來信先分成退款、帳號、技術問題三類，各自接上不同的提示詞和查詢資料。
- Parallelization：同時跑幾個子任務，或對同一件事重複嘗試，再用程式合併輸出。例如審一則商品文案，同時檢查誇大功效、價格標示和侵權用語三項，最後由程式彙整成一份結果。
- Orchestrator-workers：由一個中央 LLM 動態拆解任務、分派給 worker LLM，再彙整結果。例如一份競品調查需求，中央模型讀完後決定要查哪幾家公司、各查哪些面向，分給 worker 去做，最後合成一份比較。
- Evaluator-optimizer：一個 LLM 產生，另一個評估並回饋，反覆進行。例如翻譯產品說明，一個模型翻，另一個依照公司術語表檢查並指出不一致的地方，修到通過或達到設定的次數上限為止。
Orchestrator-workers 值得多講一句。原文把它歸在 workflow，但要拆成哪些子任務，是中央模型讀了輸入才決定的，不是程式先寫好的。它已經把一部分「怎麼做」交給模型，落在 workflow 和 Agent 之間的灰色地帶。面試時可以順帶點出這一點。我們的理解是，兩者的界線不是一刀切，差在決定權交出去多少。
真的需要 Agent 時，代價也要一起講
這一問在確認你舉得出一個 workflow 做不到、必須讓模型動態決策的例子，而且知道要付什麼代價。
判斷的關鍵是步驟能不能事先列出來。舉個示意例子：客戶回報資料同步失敗，要找出原因。先看錯誤日誌；日誌指向逾時，就去查第三方服務的狀態；指向權限，就去查 API 金鑰和帳號設定；都不是，可能要回頭比對資料格式。每一步要查什麼，取決於上一步看到什麼，總共要查幾步也說不準。可能的分支多到列不完時，很難事先畫成一張完整的流程圖，這才是 Agent 說得通的地方。
代價方面，原文寫得很直白：「Agentic systems often trade latency and cost for better task performance.」以延遲和成本換取更好的任務表現。還有一句：「The autonomous nature of agents means higher costs, and the potential for compounding errors.」自主運作代表成本更高，也可能讓錯誤一路累積。錯誤累積在上面的例子裡很好想像：前面把日誌讀錯了，後面每一步都往錯的方向查。
實務上常見的折衷，是用 workflow 把關鍵流程固定下來，只讓模型在局部做判斷。套到上面的例子，可以固定「先讀日誌」和「最後產出排查報告、交給人確認」這兩端，中間查什麼才交給模型。這是工程經驗，不是研究結論。
常見的說錯，是只講 Agent 的好處，不提延遲、成本和錯誤累積；或者講了 Agent 能處理開放問題，卻沒交代它出錯時會怎樣。
串成一段回答：先講順序，再給例子
把前面幾節串起來，口語回答大約四句就夠。下面是一段示範，不是標準答案：
我會先看單次模型呼叫加上檢索和範例能不能解決，很多需求到這裡就夠了。不夠，而且步驟能事先列出來，我會用 workflow，例如把客服來信先分類再分流，結果比較可預測、一致。只有步驟沒辦法事先列出、得看上一步結果才知道下一步時，像排查一個原因不明的同步錯誤，我才會用 Agent。代價是延遲和成本變高，錯誤也可能一路累積，所以我會用 workflow 固定前後的關鍵步驟，只讓模型在中間做判斷。
例子換成你自己做過的專案，會比照著念有說服力得多。
如果題目換成「設計一個 Agent」，常見的答題框架是依序講：值不值得做、需要哪些能力、邊界和防護怎麼設、怎麼小步迭代。這是經驗整理，沒有一手出處，可以借來組織回答，但不要說成標準流程。
拿自己專案的一個流程標一遍
讀完最實際的下一步，是挑你專案裡的一個流程，把每一步寫下來，標出哪些步驟可以事先列出、哪些必須等模型看到結果才能決定。全部都能事先列出，它就是 workflow，面試時照實說你為什麼沒用 Agent；有一兩步非得由模型決定，那就是你可以講的 Agent 例子，連同成本和錯誤累積怎麼處理一起準備。
如果追問落在「這件事到底值不值得做成 Agent」，站上〈客戶說「做個 Agent」，如何找到值得交付的問題？〉從重放任務、比較替代方案談到定出可驗收的第一版，可以接著讀。
