前幾天我們透過 n8n 與 Dify 工作流 (Workflow)，打造了一套極度穩定的自動化管線，甚至為系統裝上了多模態的「眼睛」。但你可能會發現一個問題：這個系統非常死板。

在工作流中，資料的流向是我們預先「寫死」的。如果發生 A，就執行 B。但真實世界的高階軟體工程師解決問題時，並不是照著固定的 SOP 走的。遇到一個未知的 Bug，工程師可能會先去查閱 Log，根據 Log 的結果決定要去 Google 搜尋，還是去翻閱 GitHub 的源碼，最後才統整出解決方案。

我們希望 AI 也能具備這種「根據當下情況，動態決定下一步」的能力。這就是從 Workflow 晉升為 Agent（智慧代理） 的核心差異。而支撐這個自主思考能力的最底層心法，就是著名的 ReAct 框架。

1. 什麼是 ReAct 框架？
ReAct 是 Reasoning (推理) 與 Acting (行動) 的結合。它要求大語言模型在給出最終答案前，必須展現出它的「思考過程」，並根據思考結果去「呼叫外部工具」，再根據工具回傳的「觀察結果」進行下一步思考。

這是一個不斷循環的迴圈 (Loop)，直到 AI 認為已經獲得足夠資訊為止。

2. ReAct 的運作拆解（以系統除錯為例）
假設使用者詢問：「今天早上結帳系統一直跳 500 錯誤，請幫我查明原因並給出修復建議。」
一個具備 ReAct 能力的 Agent 在後台的運作軌跡會長這樣：

• Thought (思考 1)： 使用者想知道結帳系統的 500 錯誤原因。我必須先去系統日誌庫找出早上的錯誤 Log。

• Action (行動 1)： 呼叫 Database_Query_Tool 執行 SQL 查詢。

• Observation (觀察 1)： 工具回傳結果：Error: Connection timeout to Stripe API endpoint.

• Thought (思考 2)： 錯誤原因是連線到 Stripe API 逾時。我需要知道我們系統目前設定的 Stripe Timeout 閾值是多少，這應該記錄在內部開發者文件中。

• Action (行動 2)： 呼叫 RAG_Knowledge_Search 搜尋「Stripe Timeout 設定」。

• Observation (觀察 2)： 工具回傳文件片段：「目前結帳服務的 Timeout 統一設定為 3 秒。」

• Thought (思考 3)： 3 秒可能太短導致逾時。我已經掌握了錯誤根源與現有設定，可以給出最終答案了。

• Final Answer (最終回答)： 向使用者統整錯誤原因，並建議將設定檔中的 Timeout 從 3 秒調高至 5 秒。

3. 架構師的權衡：Workflow vs. Agent
身為工程師，我們必須理解導入 Agent 的代價 (Trade-off)。
Workflow 屬於確定性系統 (Deterministic)，每一次執行的路徑與消耗的 API Token 都是可預期的，適合用在需要極度穩定、不可出錯的標準作業流程。
Agent 則是非確定性系統 (Non-deterministic)，它極度靈活，能解決未知問題，但它可能會在思考迴圈中迷失方向（俗稱 Agent Loop 死結），且因為不斷自問自答與呼叫工具，會消耗大量的 Token 與運算時間。

掌握了 ReAct 的心法，我們就理解了 Agent 的大腦是如何運轉的。明天 [Day 21]，我們將回到 Dify 介面，實作你的第一隻專屬 Agent，並為它裝備強大的工具箱！