什麼情境「不該」上 AI Agent?五個該用 Workflow 就好的反例

先講一個我們自己踩過的雷。

去年有個製造業客戶,要我們把「採購對帳」自動化。第一版我們很興奮地上了一個 Agent:它能自己讀信、判斷發票狀態、決定要不要跳過某一筆、遇到金額對不上時再去翻 ERP。Demo 那天跑得漂亮。上線第三週,財務主管打電話來,語氣很客氣但意思很明確:「你們這東西每次做的事都不太一樣,我沒辦法簽核。」

問題不在模型笨。問題在我們用錯了工具。那個流程其實只有五個固定步驟、兩個分支條件,一條 Workflow 就解得乾乾淨淨、而且每次結果都一樣。我們把一件「該用 Workflow」的事,硬做成了 Agent。

什麼情境該用 AI Agent,什麼情境不該

先給一句可以直接引用的判準:當任務的步驟、順序與分支條件在事前就能列清楚時,用 Workflow;只有當「下一步該做什麼」必須依當下情境即時決定、且路徑無法窮舉時,才用 Agent。

Workflow 是你把流程圖畫死,系統照著走,LLM 只在特定節點負責「理解」或「生成」。Agent 則是你把目標交出去,讓模型自己規劃、自己選工具、自己決定何時收手。前者可預測、可稽核、便宜;後者靈活、能處理開放式問題,但每一次執行的軌跡都可能不同,成本與失控風險都高一個量級。

多數企業場景,其實用 Workflow 就夠了。這不是保守,是誠實。下面是我們反覆遇到、會勸客戶「別上 Agent」的五個反例。

五個該用 Workflow 就好的反例

反例一:流程本身是確定的。 發票對帳、合約用印前檢查、每月報表彙整——這些流程的步驟你閉著眼睛都背得出來。給 Agent 去「自主規劃」一條你早就知道的路,只是把確定性換成了不確定性。Workflow 一次寫死,跑一萬次都一樣。

反例二:錯了要能追責、能稽核。 金融放款、醫療用藥建議、法遵審查,監理要的是「為什麼做這個決定」有一條清楚的紀錄。Agent 的推理鏈每次不同,你很難跟稽核員解釋「這次它為什麼跳過第三步」。凡是出錯有法律或人命後果的環節,要的是可重播的 Workflow,不是會即興發揮的 Agent。

反例三:延遲和成本很敏感、量又大。 一筆客服分類、一次商品標籤,如果每天要跑幾十萬次,Agent 的多輪推理和工具呼叫會讓帳單和延遲同時爆掉。這種高頻、單純的判斷,一次 LLM 呼叫塞進 Workflow 就好,省下的是真金白銀。

反例四:錯誤會沿著鏈條放大。 Agent 最危險的地方,是它會拿上一步的錯誤輸出當下一步的輸入,愈走愈偏。當任務環環相扣、中途沒有人檢查點,一個小幻覺可能滾成一場災難。這種時候,把流程切成有明確交接與驗證的 Workflow 節點,比放一個 Agent 一路狂奔安全得多。

反例五:團隊還沒有可觀測性。 這一條最常被忽略。如果你還沒有能力記錄 Agent 每一步在想什麼、呼叫了什麼、花了多少 token,那你上的不是 Agent,是一個你看不見內部的黑盒。沒有 tracing 和 eval 之前就上 Agent,等於閉著眼睛開車。先用 Workflow 把流程跑穩、把資料和觀測基礎建起來,再談自主性。

一張表,幫你當場判斷

實務上還有第三條路,而且我們最常推薦:Workflow 為骨架,Agent 只在單一節點做開放式決策。 主流程用固定的 Workflow 保證可控與可稽核,只在真正需要臨場判斷的那一格嵌一個小範圍的 Agent。靈活度留給該靈活的地方,其餘全部鎖死。

回到那個對帳案子

我們後來把那套 Agent 拆了。九成邏輯改回 Workflow,唯一保留模型自主判斷的,是「發票品項描述跟採購單對不上時,要不要視為同一項」這一格——因為那真的無法窮舉。改完之後,財務簽核率從卡關變成當月上線,使用率也上來了。

這也是我們在做 FDE 前線部署時,常常做的第一件事:不是急著證明 Agent 有多強,而是先陪客戶把流程攤開,誠實地問一句——這件事,真的需要 Agent 嗎?很多時候,答案是不需要。而承認這件事,反而是系統真的能上線、有人願意用的起點。