ReAct Framework

ReAct 框架的三個步驟各自負責什麼，缺少其中一個會怎樣？

三步驟的分工非常清楚：Thought 是 Agent 用語言模型進行的純文字推理——它不呼叫任何工具，只是讓 LLM「思考」：我現在的目標是什麼、我有哪些工具可用、我接下來應該做什麼、為什麼。這一步讓決策過程可見、可追蹤。

Action 是 Thought 推理後的具體執行——呼叫 API、查鏈上數據、搜尋網路、或在加密場景中簽署交易。這一步 Agent 真正和外部世界互動，產生真實結果。

Observation 是把 Action 的執行結果讀回給 LLM——「API 回傳了什麼」「工具說了什麼」——作為下一輪 Thought 的輸入。沒有 Observation，Agent 等於在無視工具的實際結果，仍舊靠訓練資料的幻覺做判斷。

缺少任一步的後果：沒有 Thought，Agent 變成盲目執行的腳本，無法應對未預期情況。沒有 Action，Agent 只是個思考機器，想得再好也什麼都不做。沒有 Observation，每一輪 Thought 都是在幻覺上疊幻覺，越跑越偏。三步完整才構成閉環。

ReAct 和 Chain-of-Thought（CoT）有什麼差別？為什麼光靠 CoT 不夠？

Chain-of-Thought（CoT）是讓 LLM 在給出最終答案前，先把推理過程一步一步寫出來（「讓我先想一下……」）。它顯著提升了複雜問題的回答品質，但有一個根本限制：CoT 只能用訓練資料裡的知識推理，無法獲取任何即時資訊。

舉例說明差別：你問「現在 ETH 的鏈上資金流入是正還是負」。CoT 只能用 LLM 訓練截止日前的知識回答（而且會猜，而且可能信心十足地猜錯）。ReAct 的 Agent 會在 Thought 步驟判斷「我需要查即時鏈上數據」，然後在 Action 步驟真的去查，Observation 步驟讀入真實結果，再做判斷。

簡單說：CoT 讓 LLM 想得更清楚；ReAct 讓 Agent 想清楚後還能去查證、執行。在加密場景，幾乎所有有價值的判斷都需要即時資料——市場價格、鏈上狀態、協議利率——這正是光靠 CoT 做不到的。ReAct 是 CoT 的擴展，不是替代。

ReAct 迴圈失控的常見原因有哪些？怎麼在架構上預防？

ReAct 最容易出問題的三個場景：

第一，無限迴圈：Thought 步驟反覆認為「還需要更多資訊」，不斷發出 Action，直到 Token 預算耗盡才停。通常發生在任務目標設定模糊（「幫我分析市場」比「幫我查 ETH 過去 24 小時漲跌幅並給出一句話結論」更容易觸發）或工具回傳格式 Agent 無法解析時。

第二，工具汙染：Action 調用的工具回傳了錯誤或被惡意注入的資料，Observation 讀入後 Thought 在錯誤資訊上繼續推理，越跑越偏。這是惡意 MCP Server 攻擊的核心機制。

第三，第一步假設錯誤被放大：Thought 第一輪做出了錯誤假設，後續每一輪 Action 和 Observation 都在強化那個錯誤，最終給出看起來很有邏輯但完全錯誤的結論。

架構層面的預防：設定最大迴圈次數（通常 5-15 輪）強制終止；對 Observation 資料做合理性驗證（數值超出歷史範圍就觸發警報）；關鍵 Action（特別是簽署交易）加人工確認閥門；只授權使用審計過的白名單工具。

實際部署 ReAct Agent 時，Thought 步驟的 Prompt 設計有什麼關鍵要素？

Thought 步驟的品質幾乎決定了整個 Agent 的推理品質，而 Thought 的品質很大程度上取決於 System Prompt 怎麼設計。幾個關鍵要素：

第一，給 Agent 明確的工具清單和描述。每個工具的名稱、用途、參數格式必須清楚列出。Agent 的 Thought 步驟會閱讀這些描述來決定調用哪個工具。描述模糊的工具會讓 Thought 做出錯誤的工具選擇。

第二，給 Agent 明確的終止條件。告訴 Agent 「當你取得了足夠的資訊可以回答問題時，輸出 Final Answer」，否則 Agent 可能永遠覺得「還需要再查一次」。

第三，給 Agent 行動邊界。明確說明什麼可以做（查詢數據、分析市場）、什麼不能做（未經確認不得簽署超過 X 美元的交易）。

第四，舉例示範 Thought 的格式。在 System Prompt 裡給一個 Thought/Action/Observation 的例子，讓 Agent 知道正確的輸出格式。格式不一致會讓後台的解析邏輯出錯。

這些設計細節決定了一個 ReAct Agent 在真實場景能不能用，而不只是演示用。