Agent 的價值不在模型,而在迴路:從 Claude Code 看見行動的第一原理

許多人以為 AI Agent 的價值來自更強大的模型,但真正的關鍵在於「迴路設計」。本文將從 Claude Code 的原始碼出發,拆解其 ReAct 核心機制,闡述為何將模型判斷串接工具、狀態與回饋,形成持續行動的迴路,才是區分 agent 與 chatbot 的本質。

Agent 的價值不在模型,而在迴路:從 Claude Code 看見行動的第一原理

AI Agent 的真正價值,並非來自大型語言模型單次推理的優異表現,而在於如何將模型的判斷力,有效地嵌入一個能夠持續行動的迴路(loop)之中。這個迴路串連了工具使用、狀態管理與環境回饋,讓系統從單純的應答者(chatbot)質變為能夠自主完成任務的行動者(agent)。我認為,理解並設計這個迴路,才是打造實用 AI 系統的第一原理,其重要性遠超過對特定模型的追逐。

為什麼單次呼叫模型的 chatbot 模式不夠用?

過去幾年,我們習慣了與大型語言模型(LLM)以「問答」形式互動。無論是 OpenAI 的 ChatGPT 或是 Anthropic 的 Claude,其基本模式都是一次性的請求與回應(request-response)。這種模式在知識檢索、內容生成等任務上表現出色,但它有著根本的限制:被動性。Chatbot 無法主動發起行動,無法與外部世界互動,也無法根據行動結果來修正下一步計畫。它像一個博學的圖書館員,能回答你任何問題,卻無法幫你走出圖書館去完成一項實際的任務。

當任務的複雜度提升,需要多個步驟、與外部 API 互動、或根據執行結果動態調整策略時,單次的模型呼叫就顯得捉襟見肘。以「分析公司最近三個月的銷售數據,找出表現最好的產品線,並產生一份簡報草稿」為例,這類任務就需要一連串的行動:

  • 步驟一: 呼叫資料庫 API 取得銷售數據。
  • 步驟二: 執行程式碼分析數據,找出目標產品線。
  • 步驟三: 根據分析結果,組織語言並生成簡報大綱。
  • 步驟四: 將大綱寫入檔案系統。

這其中的每一步都可能出錯,需要系統具備狀態感知、錯誤處理與自我修正的能力。這正是 Agent Architecture 發揮價值的地方,其核心在於建立一個超越單次問答的行動迴路。

ReAct 框架如何將思考與行動串連起來?

要讓模型從「說」到「做」,關鍵在於賦予它一個行動框架。目前業界影響最深遠的框架之一,是 Google Brain 於 2022 年提出的 ReAct (Reasoning and Acting)。ReAct 的洞見非常直觀:它模仿人類解決問題的模式,將「思考」(Reasoning)與「行動」(Acting)交織在一起。

ReAct 的運作迴路可以簡化為一個不斷重複的循環:Thought → Action → Observation。

  1. Thought (思考): 模型根據當前的任務目標與過往的執行歷史,進行內部推理,生成下一步的行動計畫。例如:「我需要查詢銷售數據,所以我應該使用 query_database 這個工具。」
  2. Action (行動): 系統解析模型的思考,執行對應的工具或 API 呼叫。例如,實際執行 query_database(period='3_months')
  3. Observation (觀察): 系統將行動的結果(無論成功、失敗或回傳的數據)回饋給模型。例如:「資料庫回傳了 583 筆銷售紀錄。」

這個「思考-行動-觀察」的循環會不斷重複,直到任務完成為止。透過這個迴路,模型不再只是一個被動的回答者,而是成為一個主動的規劃者與執行者。它能夠感知環境變化、使用工具、並從行動的結果中學習與修正,這就是 agency 的本質。

我們應該將焦點從「模型能回答什麼」轉向「系統能完成什麼」。前者是智慧的展現,後者是能力的證明。而串起這一切的,正是深思熟慮的迴路設計。

Claude Code 的迴路實踐:一個具體的架構解析

理論雖好,但實踐才是檢驗真理的標準。我們可以從 Anthropic 開源的 Claude Code 專案中,看到一個清晰的 ReAct 迴路實作。在其原始碼中,核心的迴路驅動引擎位於 query.ts 這個檔案,它完美地演繹了如何將單一的模型 API 呼叫,擴展為一個完整的 Agent Run。

這個架構大致可分為三個關鍵角色:

  • Model API: 這是大腦,負責「判斷」。在 Claude Code 中,它通常指向像 claude-3-opus-20240229 這樣的模型。它接收當前的狀態與歷史紀錄,產出下一步的「Thought」與「Action」。
  • Tools: 這是雙手,負責「執行」。這些是預先定義好的函式,例如讀寫檔案、執行 shell command、與其他服務的 API 互動等。模型本身無法執行這些操作,只能「要求」工具層去執行。
  • QueryEngine (query.ts): 這是中樞神經系統,負責「驅動迴路」。它扮演著協調者的角色,將 Model API 的判斷與 Tools 的執行串連起來。它會呼叫模型取得行動計畫,然後調度對應的工具,再將工具的執行結果(Observation)打包,送回給模型進行下一輪的思考。

這個結構的優雅之處在於其關注點分離(Separation of Concerns)。模型專注於高層次的推理與規劃,而繁瑣、具體的執行細節則交由穩定的工具層處理。QueryEngine 則像一個勤奮的專案經理,確保整個流程順暢推進。這種模組化的設計,不僅讓系統更穩定、更容易除錯,也讓我們能夠輕易地為 Agent 擴充新的能力——只需增加新的工具,而無需改動核心迴路。

從這個角度看,一個強大的 Agent,其能力不僅僅取決於底層 LLM 的聰明程度,更取決於這個迴路設計的品質:工具集的豐富與可靠程度、狀態管理的精細度、以及錯誤處理與重試機制的穩健性。

這也是為什麼像 LangChainLlamaIndex 這類 Agent 框架如此重要的原因——它們的核心價值,正是提供了經過驗證的、可擴展的迴路模板。最終,我們看到的是一個典範轉移:從追求單一模型的極致性能,轉向設計一個能讓模型與現實世界有效互動的、強健的系統架構。這條路才剛開始,但方向已經非常明確。

延伸閱讀


我是江中喬,專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity,持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。