實務中的代理迴圈：ReAct、工具與失敗模式

多數關於 agent 的工程討論，太早亮出 agent 這個詞，卻太晚才談運營迴圈。其實實務上真正重要的設計問題很簡單：模型一旦能執行不止一步，系統怎麼決定下一步做什麼？能呼叫哪些工具？可以從結果推斷什麼？又該在何時停下來？

這才是從架構概念走向運營代理設計的關鍵轉變。一個有用的迴圈不需要什麼宏大的自主性理論，它需要的是一個受限循環——檢視當前狀態、選擇下一個動作、觀察結果，然後決定要繼續、上報還是停止。迴圈定義模糊，系統就會以模糊的方式壞掉；迴圈定義明確，系統就能測試。

本文聚焦在這個迴圈。我們會用 OptiVerse Travel 的旅遊規劃 Copilot 作為貫穿範例，並緊貼正式環境的關注點：工具合約（tool contract）、觀察處理、重試行為、上報規則和失敗模式。這裡的目標是運營迴圈設計，不涉及更廣泛的系統治理或可稽核性。

第五篇建立了自主性光譜（autonomy spectrum），也引入核准邊界（approval boundary）作為設計概念。本文把那套框架付諸實踐：一旦系統具備受限的模型引導控制，執行時期的迴圈長什麼樣子？它又怎麼失敗？

本文不是什麼

這不是一篇討論「何時選代理、何時選工作流程」的文章——那個決策框架在第五篇已經涵蓋了。也不是關於進階基礎化（grounding）或工作記憶（working memory）的文章，那些留到第七篇。更不是完整的正式環境治理或可稽核性討論，那屬於第十篇。本文聚焦的是運營機制：迴圈結構、工具合約（tool contract）、觀察處理、重試策略和停止條件。

最小運營迴圈

多數代理式系統的核心是一個簡單的模式：

檢視當前任務狀態（task state）
選擇下一個動作
透過工具或受控生成步驟執行
觀察結果
修改計畫或停止

這就是推理-行動-觀察迴圈（reason-act-observe loop）的實務核心。模型不是什麼神奇的自主工作者——它參與的是一個與外部環境互動的受控循環。這個環境包括工具、檢索到的文件、驗證檢查和明確的系統狀態。

為什麼這個迴圈重要？因為每一步都會改變下一步的走法。單次回應的助理只能從當前上下文產出答案。迴圈系統就不同了——它可以收集證據、偵測缺口、調整路徑，也可以判斷自己不該繼續。

話說回來，這不代表每個系統都該做成代理式。許多正式環境的任務用確定性流程處理反而更好。但當完成任務的路徑取決於中間觀察時，固定工作流程就開始力不從心了。這正是代理迴圈（agent loop）派上用場的地方。

受限範例：建立完整行程表

來看 OptiVerse Travel Copilot 的一個具體任務：

建立一個 10 天的日本無障礙行程，適合櫻花季——四口之家、輪椅使用者、$13K–$15K 預算（JPN-2026-0417）。

為什麼這適合代理迴圈？因為系統無法事先知道哪些航班、飯店或鐵路選項是可用的。它可能得檢查航班庫存、檢視飯店無障礙詳情、驗證鐵路通票涵蓋範圍，然後判斷計畫是否夠完整，可以呈現給客戶。

迴圈的受限版本大致如下：

搜尋偏好出發日期飛往東京的航班可用性。
審查返回的選項——偏好日期是否已售罄？無障礙座位是否不可用？
如果偏好日期售罄，擴大搜尋至鄰近日期，檢查價格和無障礙適配度。
將可行的航班日期與目標城市輪椅無障礙房間的飯店可用性比對。
飯店日期與調整後的航班衝突？調整飯店區段，重新驗證可用性。
檢查 JR Pass 對計畫新幹線路段的涵蓋範圍——Nozomi 不包含在基本 JR Pass 中（2023 年 10 月起可另購補充票，但會增加費用），因此系統預設切換至 Hikari 或 Sakura 列車服務並調整轉乘時間，同時將 Nozomi 補充票標記為替代方案供顧問參考。
重新檢查總預算是否符合 $13K–$15K 限制。證據充足就呈現修訂後的行程表，附上取捨說明。在允許的搜尋次數之後計畫仍超預算或有未解決衝突？停止並上報。

讓它成為代理迴圈的關鍵，不是步驟數量，而是下一步取決於前一步的環境回饋。系統不是在照腳本走，而是在受限任務內做修正。

ReAct 作為參考模式，而非教條

ReAct 模式是一個有用的參考框架。它的核心貢獻在於展示：模型生成的明確推理軌跡——以文字形式呈現——當與工具使用交錯時能改善動作品質。論文證明，模型在每個動作前先生成推理步驟，表現優於不加解釋就行動、或光推理不行動的情況。這個發現把代理討論從單次提示推向了與外部環境的結構化互動。

關鍵在於推理與行動的交錯，不在於品牌。正式環境的系統不需要暴露冗長的思維鏈，也不需要模仿研究示範。真正需要的是同樣的結構紀律：

模型應該有一組有限的允許動作
每個動作應該產出結構化的觀察
觀察應該更新任務狀態（task state）
迴圈應該有明確的停止條件

有些系統裡，推理步驟是簡短的隱藏規劃狀態。另一些系統裡，它是明確的規劃器-執行器拆分——一個元件提議步驟，另一個在更嚴格的控制下執行。兩種都可以理解為推理-行動-觀察系統。

工具是介面合約

工具使用常被描述成模型「可以存取」搜尋 API、資料庫或程式執行器。這種說法太籠統了。更精確地說，工具是介面合約（interface contract）。

對代理迴圈（agent loop）而言，工具合約（tool contract）通常包括：

工具名稱
工具何時應該被使用的描述
輸入 schema
有效引數的約束
結果格式
錯誤格式
迭代或權限限制

這些欄位不是行政瑣事——它們直接影響行為。工具描述寫得模糊，工具選擇就跟著模糊。Schema 太薄弱，呼叫就容易格式錯誤。結果格式不一致，觀察處理就變得脆弱。

假設旅遊 Copilot 有一個航班搜尋工具：

json

{
  "name": "search_flights",
  "description": "Search available flights by origin, destination, date range, and accessibility requirements.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "date_range": { "type": "string" },
      "accessibility": { "type": "string", "enum": ["wheelchair", "none"] },
      "max_results": { "type": "integer", "minimum": 1, "maximum": 10 }
    },
    "required": ["query", "date_range"]
  }
}

即使是這麼小的 schema，也編入了重要的運營邊界。它告訴模型工具的用途、預期的欄位，以及單次呼叫允許的搜尋範圍。max_results 不受約束的話，迴圈可能浪費時間拉取太多選項。accessibility 沒有文件記載的話，模型可能隨意推測工具不接受的欄位值。

輸出端也一樣。如果工具有時回傳原始文字、有時回傳 JSON 物件、有時回傳模糊的錯誤字串，迴圈就很難控制。觀察處理在工具輸出跟工具輸入同樣結構化時效果最好。

觀察是環境回饋

observe（觀察）步驟是許多解釋開始變模糊的地方。觀察不是什麼神秘的內省——它就是環境回饋。

在運營系統中，觀察可能是：

成功的工具結果
驗證失敗
缺少的欄位
逾時
存取控制拒絕
低於閾值的可用性信心分數
未找到匹配航班或飯店的信號

每一種結果都應該以不同方式影響下一步。

航班搜尋在鄰近日期回傳幾個可行選項？下一步可能是驗證飯店可用性。目標日期範圍回傳零結果？迴圈可能擴大一次搜尋窗口。飯店無障礙檢查回傳不完整的房間資料？迴圈可能換一間物件重試，或上報給人類代理。合作夥伴預訂 API 的存取被拒絕？迴圈不該繼續用同一個被禁止請求的微小變體反覆嘗試。

所以觀察處理是系統設計的一部分，不只是提示工程的事。迴圈需要有策略地解讀不同類別的結果，否則模型只能從模糊的證據中自行臨場發揮恢復行為。

規劃器-執行器拆分及其適用時機

單一迴圈對緊湊的任務可能就夠了，但有些系統把規劃和執行分開會更好。在規劃器-執行器模式中，一個元件決定下一個子任務，另一個元件在更嚴格的控制下執行。

以旅遊 Copilot 為例，規劃器可能產出：

搜尋目標週飛往東京的航班，過濾輪椅無障礙座位
驗證匹配日期窗口內京都和東京的飯店可用性及無障礙設施
檢查計畫新幹線路段的 JR Pass 鐵路涵蓋範圍——預設使用 Hikari 或 Sakura 列車服務（Nozomi 需在基本通票外另購補充票）
僅在航班、飯店和鐵路全部符合 $13K–$15K 預算和無障礙約束時才進行合成

執行器接著透過工具執行每一步，紀錄觀察結果。這種拆分可以提高清晰度——執行元件不需要每一輪都重新想出整個策略，只要完成下一個受限的動作就好。

不過代價是複雜性。規劃器-執行器系統多了一層介面、多了一個狀態表示，也多了一個錯誤可能累積的地方。許多團隊太早加入這種分離。更穩健的做法是從最小迴圈開始，只在任務結構明確受益時才拆分角色。

重試是策略，不是反射

工具一旦進入迴圈，故障就是家常便飯。預訂 API 可能逾時、飯店可用性檢查可能對某間物件失敗、工具呼叫可能因為模型傳了錯誤的欄位而被拒絕。設計問題不在於故障會不會發生，而在於哪種故障值得重試。

重試應該有選擇性，而且有上限。

旅遊 Copilot 的一個合理策略：

工具呼叫因格式錯誤的引數失敗，且修正很明顯？重試一次
原始航班搜尋在偏好日期返回零結果？用更寬的日期窗口重試一次
工具報告 no availability（無可用性）？不要無限重試
存取拒絕的操作？不要重試，除非工作流程包含人類核准路徑
重複嘗試不再帶來新資訊？停止重試

你可能會想：多搜幾次不是更認真嗎？其實不然。重複的工具使用可能製造勤奮的假象，實際上卻在累積錯誤和成本。一個搜了五次、每次微調日期範圍卻從來沒改過約束條件的迴圈，不是在推理，是在拖延。

有些代理系統會在失敗步驟後加入反思性修正。當失敗中包含可據以行動的回饋時，這是有用的。但恢復迴圈仍然需要設限。一個總是想「再修正一次」的系統，可能會無止境地飄移。

上報和停止條件是設計的一部分

實用的迴圈不只需要成功路徑，也需要明確的出口。

三個最重要的出口：

complete（完成）：任務有足夠的證據來產出請求的輸出
abstain（拒答）：任務無法用可用的證據和權限可靠地完成
escalate（上報）：任務需要人類審查、核准或解讀

這些結果應該在設計階段就規劃好，不是到最後一刻才臨時拼湊。

旅遊 Copilot 的停止條件可能包括：

航班、無障礙飯店和鐵路選項全部在預算和日期窗口內對齊？停止並合成
搜尋預算用盡後仍找不到可行的航班和飯店組合？停止並拒答
飯店無障礙資料模糊或矛盾，無法僅靠工具查詢解決？上報
任務需要發出預訂、對客戶信用卡收費或覆蓋旅遊警示？上報
迴圈超過最大工具呼叫次數或延遲預算？停止

值得注意的是，這些條件結合了證據充足性、風險和運營預算。系統不只可能因為出錯而失敗，也可能因為花太久、成本太高或超越權限邊界而失敗。

代理迴圈中常見的失敗模式

一旦引入迴圈，故障就從孤立變成連鎖的。一個錯誤的觀察可能扭曲下一個動作，一套薄弱的重試策略可能產出代價高昂的螺旋。以下是幾個最常見的失敗模式：

無效的工具引數

模型用錯誤的欄位名稱、錯誤的型別或不可能的參數組合來呼叫工具。嚴格的 schema 有幫助，但無法完全消除問題。系統仍然需要引數驗證，以及驗證失敗時的明確回應路徑。

錯誤的工具選擇

迴圈在該查飯店可用性的時候卻去搜航班，或在驗證基本航班是否可預訂之前就去查鐵路涵蓋範圍。這通常源於工具描述寫得不好，或提示詞過度強調行動而非證據收集。

工具結果解析錯誤

即使工具呼叫是正確的，觀察被錯誤解析也會在下游出問題。比如迴圈把空陣列誤讀為硬故障，或忽略結果中的可用性信心分數，下一步就會走偏。

過早總結

這是最具破壞性的失敗模式之一。迴圈只收集了部分證據就急著生成一份漂亮的行程表——任務其實還沒有充分的基礎化。輸出看起來完成了，底層的證據軌跡卻薄弱或前後不一致。

無新資訊的重複迴圈

系統一直搜尋、重新檢查或調整日期，但狀態沒有任何有意義的改變。浪費 token、增加延遲，還可能誤導人以為迴圈正在「努力工作」。

缺失的上報

迴圈遇到模糊性或權限邊界，卻沒有正式的路徑來移交控制權。結果就是它一直嘗試解決一個應該交給人類審查的任務。

複合錯誤

航班搜尋或飯店驗證中的早期錯誤，一路傳播到規劃和合成階段。因為後續步驟依賴先前的觀察，迴圈系統可能把一個小錯誤放大成一份具有誤導性的最終行程表。

這些失敗模式不是反對代理迴圈（agent loop）的論點，而是支持紀律化迴圈設計的論點。

運營設計的實用指南

如果你正在從代理概念走向實作，幾條設計規則就能幫上不少忙。

第一，保持動作空間小。模型只該有實際需要的工具。多餘的工具只會增加模糊性和出錯的可能性。

第二，讓工具 schema 嚴格、輸出結構化。介面應該在執行前後都容易驗證。

第三，把觀察以明確的任務狀態（task state）儲存，別讓模型從原始對話中重建歷史。這讓迴圈更容易檢視，也減少意外的偏移。

第四，區分可恢復的故障和終端故障。格式錯誤的引數值得重試一次。存取控制拒絕通常不值得。

第五，及早定義停止條件。證據閾值、最大迭代次數、延遲預算和核准邊界（approval boundary）應該是初始設計的一部分。

第六，把迴圈當成一個系統來評估。光問最終答案聽不聽起來合理是不夠的。你需要檢視軌跡：呼叫了哪些工具、回傳了什麼觀察、哪裡發生了重試，以及迴圈是否該更早停止。

為什麼這比代理品牌更重要

團隊常花太多時間爭論一個產品「算不算」代理，花太少時間規定迴圈合約。這是本末倒置。

從工程角度來看，有意義的問題是運營性的：

模型可以自行做什麼決定
它可以呼叫什麼工具
它會收到什麼觀察
步驟之間保留什麼狀態
什麼觸發重試
什麼觸發上報
什麼強制停止

這些問題對可靠性的影響，遠大於架構上的標籤。一個動作空間窄、工具合約（tool contract）乾淨、停止規則明確的適度系統，通常會贏過一個規格不足的宏大迴圈。

橋樑：當基本 RAG 不再足夠

一個簡單的推理-行動-觀察迴圈，通常足以檢索證據、檢視結果並產出有根據的答案。但有些任務會打破基本檢索背後的假設。系統可能需要在多個步驟中對更大的證據封包進行推理，或者維護一組包含文件和中間發現的工作集，又或者在即時檢索與為當前任務組裝的較長期上下文之間取得平衡。

這就是下一個設計層次浮現的地方。代理迴圈（agent loop）是這個問題常出現的場景，但不是唯一的場景。換句話說，一旦反覆的調查工作需要一個穩定的案件資料封包，而不是每輪都跑一次全新的 top-k 檢索，你就得認真思考混合基礎化（hybrid grounding）、工作記憶（working memory），以及標準 RAG 何時不再能提供夠穩定的上下文。

這就是通往下一篇的橋樑。我們會探討當簡單的 RAG 不再足夠時會怎樣，以及為什麼當系統需要反覆推理相同的證據——而不只是擷取它——混合檢索和工作記憶模式（working memory pattern）會變得不可或缺。

來源附註

本文參考以下主要與官方來源：

Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." 交錯推理、行動與觀察的核心參考。arxiv.org/abs/2210.03629

Schick, T., Dwivedi-Yu, J., Dessi, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." 關於學習式工具使用決策的參考。arxiv.org/abs/2302.04761

Shinn, N., Cassano, F., Gopinath, A., et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." 關於不更新權重的有界文字回饋與修正迴圈參考。arxiv.org/abs/2303.11366

Anthropic. "Building effective agents." 簡單可組合代理模式，以及避免不必要框架複雜度的實務參考。anthropic.com/engineering/building-effective-agents

Anthropic. "Tool use with Claude." 工具 schema、結果處理與迭代限制的官方參考。docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview

National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 有界控制、測試與治理語言參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence