[Agent 模式 part 1] - Workflow 型和 ReAct 型，誰更像你？

你有沒有發現，自己工作中也分裂成兩個人，有時按規則做事，有時根據現實應變。其實AI Agent 也一樣。想像一下下面的場景

客戶問：「我想查詢上個月的訂單」。

Agent A

Agent : 連接「訂單歷史資料庫」 ❌ 連線失敗（資料庫正在維護）

Agent : 系統回答客戶：「抱歉，我們的系統現在無法查詢。請稍後再試。」

結果：客戶必須稍後重試，專業一點的 Agent 就是會請人介入談話

Agent B

Agent : 連接「訂單歷史資料庫」 ❌ 連線失敗（資料庫正在維護）

Agent 觀察：思考：「主資料庫不通。但我的目標是『找到訂單』，不是『從主資料庫查訂單』。 有其他方式嗎？我們有備份系統嗎？」

Agent 行動：查詢「訂單備份硬碟」觀察：✓ 找到訂單

Agent : 系統回答客戶：「由於我們的主資料庫正在維護，我從備份系統為您找到了上個月的訂單： - 9 月 15 日：$299 。如果您需要信息，建議在 2 小時後重新查詢，屆時主系統將恢復。」

結果：解決客戶問題

AI Workflow vs AI Agent

今年大家都在討論 Agent Agent Agent ，但是其實我發現到很多公司說的 Agent 更像是 AI Workflow ，在一個穩定的框架下，有固定流程跟規則

但是我所認知的 Agent ，是能夠滿足三個條件

  1. 知識庫提取能力
  2. 工具調用能力
  3. 一定的容錯或是除錯能力的

因為只要Agent 需要調用外部工具，就會有一萬種理由失敗，這時候除錯能力的高低就會嚴重影響 Agent 的robonest (或是你可以說魯棒性)，像剛剛 Agent B這種根據現實狀況動態調整的，會比較偏向真正的 AI Agent

Workflow 通常都是會在 make.com or N8N 畫出一個 DAG 流程圖，來做特定的事情。為了解決一些外部系統不可空的意外，這裡 N8N or Make.com 通常會用很多可以做很多 Error Handling 的處理，

但是有運營過的都知道，Workflow 就算竭盡所能地窮舉，也會出現很可怕無法維運的 DAG 圖，像是上面那張。我之前在做數位回單，的確用 make.com 為了 Error handling ，也畫出類似密度的 DAG 圖，那時候的經驗是除非作者，其他人根本就無法維運，最後出問題還是得打電話給作者。

另外一個問題，是 Workflow 的假設：「我能預測所有情況，所以我預先規劃好了所有步驟」

但是現實世界不是預定好的

我們就算怎麼窮舉，也會遇到完全無法預料的狀況，像是誰會知道前幾天 AWS/Azure 也會大當機…. 邊界情況層出不窮，Workflow 面對每一個新情況都說：「對不起，我沒有預案」

可以針對現實狀況除錯的 AI Agent : ReAct 模式

既然我們看到 Agent A : AI Workflow 的問題，那我們怎麼做出 Agent B 可以根據現場狀況除錯的 Agent 呢？這時候就要先來看經典的 ReAct 模式了

ReAct （Reason + Act）讓語言模型在單一循環中交替產生推理（Thought） 與行動（Action） 。具體而言，代理首先觀察到用戶問題，接著產生一段內部推理內容（如思考下一步該搜尋什麼），然後發出一個行動指令（如執行 Tool 或查詢資料庫）。環境執行該行動並返回觀察結果（Observation） 給代理。隨後模型根據新的資訊再進行推理、決定下個行動，以此迭代，直到產生最後答案。

ReAct 的設計想法並不難,它就源自於你我日常解決問題的方法。舉個例子:

  • 你寫了一段程式(類似思考了一番)
  • 然後放到編譯器裡執行一下(類似 Action,執行某種動作),
  • 然後得到執行結果(來自現實環境的反饋),
  • 再然後透過觀察(看看執行結果),來決定下一步動作,
  • 是修復細節問題呢?
  • 提交程式碼。

其實就是現實狀況中人處理問題的方式，傳說中的摸著石頭過河，找方向(Reason)->實踐(Action)->收集回饋->實踐(Action)->收集回饋->….->到達目的地。

優點： 就是對環境感知極強，魯棒性相比起 workflow 好非常多，很適合知識問答/研究型的 Agent (需要查網路），或是像網路遊戲這種高密度交互IO的 Agent 。

缺點： 幾乎每一步思考都需要一個 LLM ，速度慢。基本上每次推理要把之前推理的 context 都放進去，token 容易爆炸。因為出問題後，解決問題的思路會比較無法控制，容易產生幻覺，debug 困難。最大的問題就是摸著石頭過河是沒有明確方向性的，很容易走到局部最優解，而非全局最優解的行動路徑。

相比起來，workflow 的優點也不少，速度快，人易於理解跟掌握，遇到問題好除錯。

不管ReAct 問題再多，我認為 ReAct 是 AI Agent 的基本入門

因為「人」最強的其中一個部分就是「不論環境如何變化，人都可以非常彈性的改變方式解決問題」，而無法跟外界環境交互跟除錯的 Agent ，真的只是 workflow 不是 類人的 Agent 。

要怎麼解決 ReAct 的問題？有更好的模式嗎？

當然很多人都試著提出很多模式來優化 ReAct 的問題。這個文章系列，接下來會講其他 Agent 模型的優缺點，像是 Plan & Exec ，REWООO，LLM Compiler ，Basic Reflection，LATS (Language Agent Tree Search)。

我比較喜歡的 Plan & Exec

當然太學術的我會略過。不過這些東西基本上大部分就是 ReAct 跟 Workflow concept 的優化跟組合。

有更簡單的方式嗎？看看工具怎麼做

另外一個簡單的方式，就是 Claude Code 一樣，Claude Code 加入「人」(兼顧效率跟魯棒性) 在他的模式裡面。 Claude Code 的交互介面一開始就設計成跟人交互，而非完全自主完成。

Claude Code 在小任務上通常可以自我除錯，不需要人來介入。但是在關鍵節點，或是邊際狀況上，他會主動的提示人這裡有問題，要跟人對齊。

這裡 Claude Code 就一直在「自主性」和「人類對齊」之間找平衡

再回到剛剛的場景

客戶打電話問：「我想查詢上個月的訂單」。

真人客服 A

真人客服 A : 連接「訂單歷史資料庫」 ❌ 連線失敗（資料庫正在維護）

真人客服 A: 回答客戶：「抱歉，我們的系統現在無法查詢。請稍後再試。」

真人客服 B

真人客服 B: 連接「訂單歷史資料庫」 ❌ 連線失敗（資料庫正在維護）

真人客服 B：思考：「主資料庫不通。但我的目標是『找到訂單』，不是『從主資料庫查訂單』。 有其他方式嗎？我們有備份系統嗎？」

真人客服 B 行動：查詢「訂單備份硬碟」觀察：✓ 找到訂單

真人客服 B 回答客戶：「由於我們的主資料庫正在維護，我從備份系統為您找到了上個月的訂單： - 9 月 15 日：$299 。如果您需要信息，建議在 2 小時後重新查詢，屆時主系統將恢復。」

有沒有感覺也很像日常生活會遇到的場景

Agent 思考模型跟人一樣

在我們的日常生活，也很常遇到不同類型的人，有些人是 ReAct ，有些人是 Workflow 類型。ReAct 的人腦袋靈活，但是很多時候不好控制，野路子很多也容易失控。Workflow 類型的人雖然呆板，但是往好的方面想也是「一絲不苟」。

想想 Claude Code 要在「自主性」和「人類對齊」上找平衡

我們人也不就是一直在 ReAct 跟 Workflow 上追求一個 tradeoff ？