# Workflow、AI Agent，傻傻分不清楚？

> 不知道大家有沒有注意到，最近只要有新的 AI 工具推出，就會出現 XXX 已死的說法。其實這說...

Published: 2025-10-08
URL: https://kaochenlong.com/workflows-vs-agents

---

不知道大家有沒有注意到，最近只要有新的 AI 工具推出，就會出現 XXX 已死的說法。其實這說法滿有趣的，因為每次新技術出現，總會有人跳出來評論舊技術沒用了，更有趣的是這些評論者很可能本身並沒在用那些他口中說快死或已死的技術。

但這無所謂啦，沒什麼好吵的，技術就是這樣的，總是不斷推出新的技術，不然人類社會怎麼進步？

只是，大家討論到工作流程自動化的時候，常會把 Workflow 和 AI Agent 這兩個詞混在一起討論？其實這是個很好的問題。兩者都能幫我們自動化處理任務，但它們的設計哲學和適用場景其實不太一樣。就像你應該不會沒事開著法拉利（如果有的話）去載水泥、鋼筋一樣，不是哪個比較好，而是要看你想做什麼還有合不合適的問題。

&lt;!-- more --&gt;

## 你想要自己開車，還是想要司機幫你開？

在我看來，Workflow 和 Agent 最大的差別，就在於「控制權」這件事。

### Workflow：你掌握方向盤

想像一下你自己開車出去玩，你需要決定走哪條路、在哪個路口轉彎、什麼時候該加速減速...每個決策都掌握在你（或導航系統）手上，迷路也是你的問題。這就是 Workflow 的精神。

在 Workflow 裡，你明確定義了「what」和「how」：

- 要做什麼（what）
- 怎麼做（how）
- 什麼時候做這個、什麼時候做那個
- 遇到 A 情況就走這條路，遇到 B 情況就走那條路

就像你握著方向盤，車子就會一板一眼地照著你規劃的路線前進。

### Agent：你僱用了一位司機

Agent 不太一樣。就像搭計程車，你只需要告訴司機「我要去台北 101」，至於要走哪條路、遇到塞車怎麼繞、紅綠燈怎麼走...這些決定都交給司機（或導航系統）自己判斷。

在 Agent 裡，你主要定義「what」，讓 AI 決定「how」：

- 你說明目標和期望結果
- AI 自己決定達成的路徑
- AI 會根據情況調整做法

你可能會想：「司機會不會給你偷繞遠路？」的確是有可能，這也是為什麼 AI 給你的答案如果沒能力驗證的話可能會有的風險。

&gt; Workflow 給你掌控權，但缺乏彈性；Agent 給你彈性，但你得放棄一部分掌控權。這是取捨，並不是對錯。

再讓我們更仔細地看看這兩者的差異。

### 1. 可預測性 vs 自主性

Workflow 就像搭捷運：每天同樣的路線、同樣的站、同樣的時間表。你知道從 A 站到 B 站要多久，每次都一樣。這就是可預測性。

Agent 比較像搭計程車：雖然目的地一樣，但司機可能會根據路況選不同的路。今天走忠孝東路，明天可能改走市民大道。同樣的起點和終點，但過程可能完全不同。這就是自主性。

你有沒有想過，為什麼有些任務就是要可預測？因為在某些場景下，「過程」和「結果」一樣重要。比如說金融交易、醫療流程、法規遵循等場景如果每次做法都不一樣，那可能會有點麻煩。

### 2. 結構複雜度 vs Prompt 複雜度

這是個很有趣的現象。

Workflow 的複雜度在「結構」上。你可能會看到一個流程圖裡面有幾十個、甚至上百個節點，分支來分支去、有平行處理、有條件判斷...如果沒有視覺化工具的話，可能看不懂在幹嘛。

但是，Agent 的複雜度在 Prompt 上。別被簡單的架構騙了！一個看起來很簡單的 Agent，它的 Prompt 可能長達幾千個字，裡面要考慮各種邊界情況、異常處理、安全限制，要寫一個好的 Prompt 並沒有比寫程式來的簡單。

我認為，這兩種複雜度其實是同一件事的不同表現形式。複雜的問題就是複雜，我們只是選擇把複雜度放在哪裡而已。

### 3. 設計思維的差異

這一點可能更根本一些。

當你在設計 Workflow 時，你的腦袋裡想的是：

- 「流程應該怎麼走？」
- 「遇到這種情況要怎麼辦？」
- 「這個步驟完成後，接下來做什麼？」

但設計 Agent 時，你想的是：

- 「我要達成什麼目標？」
- 「這個 Agent 需要什麼能力？」
- 「在什麼範圍內它可以自己做決定？」

這是兩種完全不同的思考方式。Workflow 是「控制導向」的，Agent 是「目標導向」的。

## No Code/Low Code 工具的尷尬處境

說到這裡，我也觀察到一個有趣的現象，就是所謂的 No Code 或 Low Code 工具的生存空間或甜蜜點正在被擠壓...

### 簡單問題：Agent 獲勝

以前我們可能會用 No-Code 工具來做一些簡單的自動化，比如「收到表單就發通知信」、「定時爬個資料存到試算表」。但現在你會發現，一個設計良好的 Agent 可能一下子就搞定了，而且不用設定一堆節點或參數。舉幾個例子：

- 簡單的資料處理和轉換
- 基礎的 CRUD 操作
- 制式的客服回覆

這些任務用 Agent 可能比用 No Code 工具還快、還直覺。

### 複雜問題：Workflow 或直接寫 code

一旦問題變複雜，No Code 工具也不見得是好選擇。

No Code 工具用久了多少都會遇到有些工作流程做到一半卻發現「咦，這個好像有點難做到」，然後開始想各種變通方案，最後整個流程變得超級複雜、難以維護。這時候你可能會想：「我還不如直接寫 code 算了。」這類問題包括：

- 多層審核流程
- 複雜的業務規則引擎
- 需要合規稽核的作業流程

這些場景如果規則明確，Workflow 或直接寫程式會是更好的選擇。光靠 Agent 的 Prompt 要涵蓋所有狀況，複雜度不會比較低。

### 甜蜜點正在縮小

如果你是在兩邊游移的人，慢慢也會發現，No Code / Low Code 工具的「甜蜜點」正在縮小：

- 簡單的那一端被 Agent 取代了
- 複雜的那一端直接用 Workflow 或寫 code 更有效率
- 剩下的空間主要是需要視覺化協作、讓非技術人員也能參與設計的場景

我不是說 No Code 工具會消失，但它們的定位確實在改變。

目前坊間的那些 No Code 平台也不是吃素的，也都知道這個問題，所以早就開始整合 AI 功能。但這並沒有改變問題的本質：如果問題本質上適合 Agent，那就用 Agent；如果適合 Workflow，那就用 Workflow。

平台只是工具，重點還是你對問題本質的理解。

## 該選哪一個？

問自己一個最簡單的問題：「這個流程能不能出錯？」

如果答案是「不能」或「最好不要」，那就選 Workflow。為什麼這麼說？因為 Workflow 提供的是可靠性和可追蹤性：

- 不能出錯的流程，例如金融交易、醫療流程、法規遵循
- 需要完整審計追蹤，每一步都要留下記錄，方便日後稽核
- 規則明確且穩定，業務邏輯很清楚，不太會變動
- 多人協作需要視覺化，團隊成員都要能看懂流程在做什麼
- 合規要求嚴格，有法規或公司政策的限制

Workflow 用起來可能有點老派，但想想看，如果你處理的是客戶的錢或是你的錢，使用者的個資、或是會影響他人權益的流程時，可靠性比酷炫更重要。

那什麼時候適合用 Agent？當問題本身就不確定、需要彈性應變的時候。例如：

- 處理非結構化輸入，自然語言、圖片、各種格式的文件
- 情境變化大，很難事先窮舉所有可能的情況
- 快速原型開發，想先驗證想法，還不確定最終要怎麼做
- 任務目標明確但路徑多樣，知道要什麼結果，但達成方式很多種
- 可以容忍一定程度的不確定性，結果有些變異是可以接受的

線上客服 Chatbot 就是個很好的例子。每個使用者的問題都不一樣，我們不可能為每種問題都設計一條 Workflow 路徑。這時候 Agent 的彈性就很重要。「可以容忍不確定性」這個前提很重要。如果你的任務是「幫客戶退款」，這種涉及金錢的操作，我會建議還是用 Workflow 比較保險。

## 混合架構？

前面提到，那些 No Code 平台早就注意到這件事，所以紛紛都採用 Workflow + Agent 的混合模式，很受歡迎的 n8n 就是一個很經典的例子。

- 用 Workflow 控制關鍵決策點和資料流向
- 在特定的地方嵌入 AI Agent 節點處理非結構化或需要彈性的部分

結合兩者優勢，有可控性，又有靈活性。我個人很喜歡這種混合的設計，畢竟真實世界的問題，往往不是非黑即白。有些部分需要精確控制，有些部分需要靈活應變，把兩者結合起來才是最實用的解決方案。

工具可能有好有壞，不過通常沒有誰會取代誰，只有適不適合，重點是你有沒有用對地方 :)


