Workflow 還是 Agent?依 Anthropic 的定義做企業架構選擇

依 Anthropic 在《Building Effective Agents》裡的分野:Workflow 是「用預先寫好的程式路徑,去編排 LLM 與工具」的系統;Agent 則是「讓 LLM 自己動態決定流程與工具用法、自主掌控如何完成任務」的系統。 一句話記住差別——Workflow 的路徑是你決定的,Agent 的路徑是模型當下決定的。

這個定義聽起來抽象,但它決定了你的系統會不會在半夜出事、成本會不會失控、以及出錯時你查不查得到原因。企業選型時,九成的爭論其實只是沒把這條線畫清楚。

Workflow vs Agent:差別不在「聰不聰明」,在誰握著方向盤

我們常被問:「你們幫我做的到底是 Workflow 還是 Agent?」很多人以為 Agent 比較高級、比較「AI」,Workflow 是陽春版。這是誤解。

真正的差別是控制權歸屬。Workflow 裡,每一步該做什麼、下一步跳去哪,是工程師在程式碼裡寫死的;LLM 只負責在某個節點做它擅長的事，例如分類、抽取、改寫。流程本身是確定的。Agent 相反：你給它目標和一組工具，它自己判斷要呼叫哪個工具、呼叫幾次、什麼時候算完成。路徑在執行當下才長出來。

Anthropic 還特別提醒一個更上位的詞：Agentic System（代理型系統）。它是 Workflow 與 Agent 的統稱。也就是說，「有沒有用到 LLM 自主性」是一條光譜，不是二選一的開關。企業要選的，往往不是「要不要 Agent」，而是「這個環節該落在光譜的哪一格」。

一張表看懂該用哪個

這張表的用法不是「挑一邊」，而是逐環節拆。一個真實系統通常兩者都有：外層用 Workflow 把關鍵步驟釘死，只在某個「開放度高」的節點放進一小段 Agent 自主性。

我們踩過的坑：先上 Agent，後悔莫及

去年一個製造業客戶，想做「工單自動派修」。第一版團隊很興奮，直接上了全自主 Agent：丟進故障描述，讓它自己查手冊、判斷零件、開派工單、通知師傅。Demo 很漂亮。

上線兩週，問題來了。同一種故障，Agent 這次查三份文件、下次查七份，token 成本差三倍。更糟的是，有一次它自作主張把一張高階維修單派給了實習技師——因為它「推理」出這樣比較快。出事後我們想追為什麼，發現根本沒有可讀的決策軌跡。

我們把它拆了重做。派工這種「錯了會出人命」的決策，收回 Workflow，用寫死的規則加一次 LLM 分類；只有「該查哪些手冊、怎麼摘要」這種開放環節，保留 Agent。成本回到可預估，稽核也查得到了。使用率從導入初期的兩成，三個月後爬到七成。

這件事給我們的判準很簡單：能用 Workflow 解的，就別用 Agent。 Anthropic 在同一篇文章裡其實講了同一句話——先找最簡單的解，只有當任務真的需要動態決策與彈性時，才付出 Agent 的複雜度與不可預測性代價。Agent 不是預設值，是最後手段。

架構決策的三個實戰提問

要把這條線畫在對的位置，我們進場時只問三件事。

第一，這個環節的步驟，我能不能今天就在白板上畫完？畫得完，它就是 Workflow 的料。畫不完、會因輸入爆炸出無數分支，才考慮 Agent。

第二，錯一次的代價多大？代價高、又受監管的環節，寧可犧牲彈性也要可預測、可稽核，那就別讓模型自己開車。

第三，我有沒有能力觀測它的每一步？如果你打算放進 Agent，就必須同時準備好決策日誌、工具呼叫上限、以及人工覆核的斷點。沒有這些，Agent 的自主性只是把風險藏進黑箱。

多數企業真正需要的，是一個以 Workflow 為骨架、在少數節點嵌入 Agent 的混合系統——而不是一個什麼都自己想的全自主代理。

這也是我們在 Tenten 做 Agentic 工作流時的一貫做法：先照 Anthropic 的定義把每個環節歸位，把確定性留給 Workflow，把彈性留給真正需要它的地方，再派工程師進場，盯著它從 Demo 一路撐到有人天天在用。畢竟能跑的架構不稀奇，上線後還沒被關掉的，才算數。