代理迴圈與工具可靠性

由模型引導的應用程式需要明確的營運迴圈。一旦模型能執行多步驟操作，核心設計問題就很具體：系統如何決定下一步、允許呼叫哪些工具、允許從結果推斷出什麼，又必須在何時停下來？

從架構圖走向可實際營運的 AI 代理，靠的不是宏大的自主性理論，而是有明確邊界的執行循環：檢視目前狀態、選擇下一步動作、觀察執行結果，再決定繼續、轉交人工或停止。循環定義含糊，失敗就會難以預測，也難以重現；循環定義明確，狀態轉換就能納入測試。

本文以虛構的 OptiVerse Travel 旅行 Copilot 與模擬航班、飯店、費率及日期為例，聚焦探討這套執行期迴圈。重點放在貼近正式環境的運作機制，包含工具契約（tool contract）、觀察處理、重試政策、提報規則與失敗模式；更廣泛的全系統治理與可稽核性則留待後續章節。

文章 5 建立了多維度的控制與權限矩陣，並引入核准邊界（approval boundary）的概念。本文將那套框架落實為執行期行為：當系統賦予模型有界的引導控制權，實際迴圈如何運作，又會在哪些環節出錯？

本文不涵蓋的內容

文章 5 討論過何時該選 AI 代理而非固定工作流程，文章 7 涵蓋混合式證據錨定（grounding）與工作記憶（working memory），而文章 10 的總整專案則負責端對端的正式環境治理與稽核。本文專注於銜接其間的執行期機制：迴圈結構、工具契約、觀察處理、重試政策與停止條件。

最小營運迴圈

多數代理式系統都圍繞五個步驟運作：

1. 檢視當前任務狀態（task state）

2. 選擇下一個動作

3. 透過工具或受控生成步驟執行該動作

4. 觀察執行結果

5. 修訂計畫或停止

在「推理、行動、觀察」迴圈（reason-act-observe loop）中，模型參與的是與外部環境互動的受控循環；外部環境涵蓋工具、檢索文件、驗證檢查與明確的系統狀態。

每一步都會改變下一步的走向。單次問答助理只能依初始上下文作答；具備迴圈的系統則能蒐集證據、偵測缺口、修正查詢路徑，或判斷自己不該繼續執行。

不過，許多正式環境任務用確定性管線反而更穩健，固定工作流程同樣能根據中繼觀察切換分支。當預先定義的路徑無法妥善表達下一步該調查什麼，且實測顯示模型引導帶來可量測的效益，這份複雜度就值得承擔。

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

來看 OptiVerse Travel 旅行 Copilot 的一項具體任務：

建立 10 天日本櫻花季無障礙行程：四口之家、含一位輪椅使用者，預算 13,000 至 15,000 美元（JPN-2026-0417）。

完成這項請求可能需要查詢航班機位、檢視飯店無障礙設施細節、確認鐵路周遊券適用範圍，再判斷證據是否足以交付客戶。因此這項任務適合列為代理迴圈的候選；但具分支邏輯的工作流程同樣能查詢動態機位與房況，正式採用模型引導控制前，仍應在代表性任務上實測比較兩種做法。

有界迴圈的運作流程如下：

1. 搜尋偏好出發日期飛往東京的可用航班。

2. 檢視回傳選項，確認偏好日期是否售罄，以及所需的無障礙協助為已確認、無法提供或仍未知。一般機位剩餘數並不能確認個別旅客的協助需求會獲得滿足。

3. 若偏好日期已售罄，且使用者允許日期彈性，便將搜尋範圍放寬至鄰近日期，再次檢查票價與無障礙條件是否相符。

4. 將可行的航班日期，與目標城市輪椅無障礙房型的空房狀況比對。

5. 若飯店可入住日期與調整後的航班衝突，便平移住宿區間並重新驗證空房。

6. 查詢帶有生效日期、適用通路與來源 ID 的最新權威資料，確認鐵路周遊券涵蓋範圍，且只根據通過驗證的結果調整路線。

7. 重新核算總費用是否落在 13,000 至 15,000 美元的預算內。證據齊全後，呈現修訂後的行程表並註明取捨；若用盡允許的搜尋次數後仍超出預算或留有未解衝突，便停止並轉交人工處理。

唯有當模型能在允許的行動集合內自行選擇下一步調查時，這套循環才屬於模型引導控制；若所有分支皆由程式碼硬性規定，即使系統會回應環境回饋，本質上仍是固定工作流程。

ReAct 是參考模式，而非教條

ReAct 模式之所以是重要的歷史參考，在於它將模型產生的推理軌跡、任務行動與環境觀察交錯進行。不過論文結果高度取決於任務型態：在 HotpotQA 上，單獨使用 ReAct 的分數低於思維鏈提示（chain-of-thought prompting），在該比較中表現最佳的提示變體結合了 ReAct 與思維鏈自我一致性（self-consistency），而論文另外列出的監督式微調基準分數更高；相對地，互動式決策基準則顯示出優於論文所測基準的明顯提升（Yao et al., 2023）。

真正值得帶進正式環境的，是推理與行動交錯的做法，而非公開冗長的思維鏈或照搬研究示範的提示格式。正式環境的迴圈需要四項結構要求：

• 模型只能從受限的允許集合中選擇動作

• 每個動作都回傳結構化的觀察結果

• 觀察結果會明確更新任務狀態（task state）

• 由執行器強制套用的明確停止條件

有些系統將規劃維持在有界的內部狀態中，另一些則拆成明確的「規劃器與執行器」（planner-executor），由前者提出步驟、後者負責執行。無論採用哪種架構，模型產生的理由文字都不能當成忠實的稽核紀錄，因為模型解釋可能遺漏真正影響輸出的因素，甚至事後合理化答案（Turpin et al., 2023）。稽核對象應是工具呼叫、觀察結果、狀態轉換、政策決策與環境最終結果。

工具即介面契約

許多介紹常把工具使用形容成讓模型「存取」搜尋 API、資料庫或程式執行器，這種說法過於鬆散。從工程角度來看，工具是具型別的介面契約（interface contract）。

代理迴圈的工具契約通常明定：

• 工具名稱

• 適用與不適用的呼叫時機

• 輸入 schema 與有效引數限制

• 結構化的結果格式

• 具型別的錯誤格式

• 呼叫次數或權限上限

每一個欄位都會影響執行期如何處理模型提出的呼叫。描述含糊會讓工具選擇模稜兩可，寬鬆的 schema 會放行格式錯誤的引數，不一致的回傳字串則會讓觀察處理變得脆弱。每個契約邊界都應直接納入測試，而非把 schema 當成備查文件。

以下與特定供應商無關的教學契約定義了模擬的唯讀航班搜尋工具，並不是可直接送進供應商 API 的 payload。實作時請依模型供應商的工具格式調整 input_schema，並由應用程式另行驗證 result_schema：

{
  "name": "search_flights",
  "description": "Search available flights by origin, destination, date range, and accessibility requirements.",
  "input_schema": {
    "type": "object",
    "properties": {
      "origin": {
        "type": "string"
      },
      "destination": {
        "type": "string"
      },
      "date_start": {
        "type": "string",
        "format": "date"
      },
      "date_end": {
        "type": "string",
        "format": "date"
      },
      "accessibility": {
        "type": "string",
        "enum": [
          "wheelchair",
          "none"
        ]
      },
      "max_results": {
        "type": "integer",
        "minimum": 1,
        "maximum": 10
      }
    },
    "required": [
      "origin",
      "destination",
      "date_start",
      "date_end",
      "accessibility",
      "max_results"
    ],
    "additionalProperties": false
  },
  "result_schema": {
    "oneOf": [
      {
        "type": "object",
        "properties": {
          "status": {
            "const": "ok"
          },
          "options": {
            "type": "array",
            "maxItems": 10,
            "items": {
              "type": "object",
              "properties": {
                "flight_id": {
                  "type": "string",
                  "minLength": 1
                },
                "assistance_status": {
                  "type": "string",
                  "enum": [
                    "unknown",
                    "reported_available",
                    "reported_unavailable"
                  ]
                }
              },
              "required": [
                "flight_id",
                "assistance_status"
              ],
              "additionalProperties": false
            }
          },
          "source_timestamp": {
            "type": "string",
            "format": "date-time"
          }
        },
        "required": [
          "status",
          "options",
          "source_timestamp"
        ],
        "additionalProperties": false
      },
      {
        "type": "object",
        "properties": {
          "status": {
            "const": "error"
          },
          "error_code": {
            "type": "string",
            "enum": [
              "invalid_arguments",
              "access_denied",
              "rate_limited",
              "service_unavailable"
            ]
          },
          "retryable": {
            "type": "boolean"
          }
        },
        "required": [
          "status",
          "error_code",
          "retryable"
        ],
        "additionalProperties": false
      }
    ]
  }
}

這份精簡的 schema 已經編入多道營運邊界：強制提供協助需求標記（僅用於標註請求，不等同完整無障礙評估）、拆開起訖日期、拒絕額外欄位、限制回傳筆數，並透過 status 判別欄位區分成功與錯誤分支。JSON Schema 將 format 檢查列為選用，許多驗證器預設不檢查；各家模型供應商對嚴格 schema 的支援程度也不一。因此，伺服器端應再次驗證引數並啟用日期格式檢查，同時另行確認 date_start <= date_end、允許的日期彈性、有效機場代碼與資料來源時效。身分驗證、租戶身分與憑證一律由執行期注入，絕不取自模型產生的引數。

輸出端的結構化同樣關鍵。倘若工具有時回傳純文字、有時回傳任意 JSON 物件、有時又吐出無型別錯誤字串，復原邏輯就只能靠猜測。工具輸出應與工具輸入維持同等嚴格的型別契約。

觀察即環境回饋

許多關於代理迴圈的說明一談到 observe（觀察）步驟就變得玄虛，彷彿模型在做某種內省；其實觀察就是單純的環境回饋。

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

• 通過驗證的工具結果

• 驗證失敗

• 缺少必要欄位

• 呼叫逾時

• 存取控制拒絕

• 未確認或缺漏的無障礙協助欄位

• 查無相符航班或飯店的空結果

每一種結果都應對應明確的狀態轉換規則。

若航班搜尋在鄰近日期找到可行選項，迴圈便可接著確認飯店空房；若目標日期區間查無航班，政策可允許放寬一次搜尋日期區間。遇到飯店無障礙欄位不完整時，系統可改查其他飯店或轉交真人專員；但若合作夥伴訂房 API 回傳存取拒絕，迴圈就不得微調參數，反覆試探同一個被禁止的請求。

正因如此，觀察處理屬於應用程式邏輯，不能只寫進提示詞了事。缺少針對各類結果的明確政策，模型就只能在含糊的錯誤訊號中臨場拼湊復原行為。

此外，所有工具回傳結果都必須視為不受信任的資料。網頁、合作夥伴文件或遭入侵的工具，都可能夾帶企圖劫持迴圈的指令；間接提示注入研究已在整合 LLM 的應用程式中證實這條攻擊路徑（Greshake et al., 2023）。系統應驗證觀察內容並限制大小、記錄來源脈絡，並在模型讀取外部內容後，重新授權每一個新提議的操作。

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

步驟精簡的任務用單一迴圈即可勝任，較複雜的流程有時則適合拆開規劃與執行。在規劃器與執行器拆分的架構中，規劃器負責決定下一個子任務，執行器則在更嚴格的工具與 schema 限制下完成該項有界動作。

以旅行 Copilot 為例，規劃器可能拆出四個子任務：

1. 搜尋目標週飛往東京的航班，保留旅客協助需求，並記錄航空公司是否已確認

2. 在相符的日期區間內，確認京都與東京飯店的空房及輪椅無障礙設施

3. 查詢規劃路段目前的鐵路周遊券適用範圍，並記錄所使用的資料來源版本

4. 唯有當航班、飯店、鐵路、餐飲、稅金、各項手續費與其他必要費用皆已涵蓋時，才彙整總預算結論；否則僅呈現註明範圍限制的小計

執行器接著透過具型別工具逐一完成步驟，並記錄觀察結果。這種拆分可以提升清晰度：執行器每次只需完成一個受限動作，不必每輪重新構思整體策略，提示詞與開放的工具範圍也就能維持精簡。

拆分的代價則是協調成本：系統多了一層介面契約、多一次狀態交接，也多了一個錯誤可能累積的地方。實務上應先從單一有界迴圈做起，確定任務結構真能從角色拆分獲益時再引入。

重試是政策，不是反射動作

一旦迴圈串接外部工具，局部失敗就是常態：訂房 API 可能逾時、單一飯店查詢可能出錯，模型也可能傳入無效欄位。核心工程問題在於哪些失敗類別值得重試，以及重試的邊界何在。

以旅行 Copilot 為例，嚴謹的重試政策可能如下：

• 若工具呼叫因輸入驗證失敗被拒，而且有明顯、符合 schema 又不改變使用者意圖的修正方式，重試一次

• 若偏好出發日期查無航班，且使用者已授權日期彈性，放寬日期區間重試一次

• 若有效查詢回報允許區間內皆為 no availability（無空位／空房），不要無限重試

• 權限未變時，不要重試 access_denied 操作；合法的權限變更必須重新通過授權檢查，單靠人工核准無法憑空補上缺少的存取權

• 連續嘗試不再帶來新資訊時，停止重試

無上限的重試可能製造勤奮的假象，實際上卻不斷累積錯誤與成本。每次額外搜尋都應記錄預期取得的新證據；日期調整也必須限制在使用者授權的彈性範圍內，不能為了湊出結果而放寬硬性條件。

Reflexion 在不更新模型權重的前提下，跨試驗保留模型針對任務回饋寫下的文字反思（Shinn et al., 2023）；有些迴圈也會在某一步失敗後做類似的修正。當失敗訊息包含具體可行的回饋時，修正可能有所幫助，但前提是設下嚴格的次數上限，避免系統陷入「再改一次就好」的無止境飄移。

決定重試前，應先將失敗歸類：

• 暫時性失敗：可安全重試的讀取逾時、速率限制或上游暫時性錯誤（寫入逾時則必須先視為結果可能未知）；

• 可修正的輸入錯誤：可在不改變使用者意圖下修正的 schema 或參數錯誤；

• 對當前請求屬永久性失敗：無效資源或不支援的操作（有效查詢回報沒有空位或空房屬於領域結果，既不是傳輸錯誤，也不代表之後不會再釋出）；

• 政策拒絕：存取被拒或缺少必要核准；

• 結果未知（unknown outcome）：可能已改變遠端狀態的請求遺失回應。

針對可安全重試的暫時性失敗，應設定單次呼叫逾時，並搭配具隨機抖動（jitter）的有界指數退避。遵守 Retry-After 標頭，依 RFC 9110, §10.2.3 規定，其格式可為等待秒數或 HTTP 日期；若剩餘任務期限容納不下所需的等待時間，應停止或延後處理，不得提早重試。同時限制最大嘗試次數與總經過時間，並只在單一架構層執行重試，避免 SDK、工具封裝層與代理迴圈的巢狀重試彼此相乘。

若要自動重試外部可見的寫入操作，目的地服務必須支援冪等性或具同等強度的重複抑制契約；缺少這項契約，重試就可能重複產生副作用（Featonby, AWS）。若接收端不處理冪等鍵，單靠本機產生 UUID 毫無保護作用。唯有意圖與參數完全相同的重試才能沿用同一把穩定操作鍵，且寫入逾時後必須先核對遠端狀態。只要核對程序無法確認寫入是否生效，就必須以 unknown 終止並轉交人工，絕不能任由模型自行推測訂房成功。

提報與停止條件是設計的一部分

可靠的迴圈除了規劃成功路徑，也必須明確定義所有退場出口。

請為執行器定義四種明確的終止狀態：

• complete（完成）：已驗證的證據滿足所有任務條件

• abstain（拒答）：現有證據與權限不足以可靠回答請求

• escalate（提報）：後續步驟需要人工審查、核准或專業判斷

• unknown（結果未知）：可能產生副作用的呼叫結果未明；保留操作鍵並移交後續處理，不宣稱成功或失敗

這些退場狀態應在設計狀態機時一併定案，而非留給提示詞臨場發揮。

旅行 Copilot 的具體停止條件包含：

• 當航班、無障礙房型與鐵路周遊券皆符合授權日期區間與預算時，停止搜尋並彙整行程

• 當搜尋預算用盡仍找不到可行的航班與飯店組合時，停止並拒答

• 當飯店無障礙紀錄含糊或前後矛盾，且無法單靠工具查詢釐清時，提報人工審查

• 當下一步涉及成立正式訂單、刷卡扣款或覆寫旅遊警示時，提報人工審查

• 當迴圈達到工具呼叫次數上限或總延遲預算時，停止執行

這組條件同時涵蓋證據充足度、權限邊界與營運預算：即使回傳的行程正確無誤，迴圈仍可能因為超出延遲上限、燒光預算或逾越權限而失敗。

代理迴圈常見的失敗模式

一旦引入多步驟迴圈，錯誤就會沿著步驟連鎖傳遞：一次誤讀觀察可能帶偏下一個工具呼叫，一條過於寬鬆的重試規則也可能引發代價高昂的失敗螺旋。請留意以下七種反覆出現的失敗模式：

無效的工具引數

模型傳入不存在的欄位名稱、錯誤型別或自相矛盾的參數組合。嚴格的 JSON Schema 能攔下結構錯誤，卻攔不下所有無效組合，因此伺服器端驗證應搭配確定性的錯誤格式，讓執行器明確判斷是否允許一次修正重試。

錯誤的工具選擇

當測例需要查詢飯店空房時，迴圈卻去查航班；或尚未確認去程機位就先查鐵路周遊券。成因可能是工具描述重疊、提示詞鼓勵過早行動、任務狀態錯誤、schema 問題或模型判斷失誤；動手改提示詞或 schema 前，應先檢視實際請求與工具追蹤紀錄。

工具結果解析錯誤

即使工具呼叫本身正確，若執行器誤判回傳內容，下一步決策仍會走偏，例如把空的 options 陣列當成傳輸崩潰，或把狀態為 "unknown" 的未確認協助當成已確認提供。

過早綜合結論

迴圈只蒐集到局部證據，尚未驗證關鍵限制條件，就急著產出看似完整的行程表。流暢的文字極易掩蓋底層證據的缺漏或衝突，必須靠完成閘門先行檢查必要證據 ID。

毫無新資訊的重複迴圈

執行器反覆送出等效查詢或來回微調日期，任務狀態卻毫無實質進展，既浪費 token 與延遲預算，還會營造「系統正在努力處理」的假象。

缺少提報路徑

迴圈遇到含糊或矛盾的資料，或碰上權限邊界時，若狀態機缺少正式的 escalate 移交路徑，就會在理應交由人工判斷的問題上徒勞打轉。

錯誤連鎖放大

前期在航班日期或無障礙房型驗證上的小失誤，一路帶入後續的鐵路查詢與預算加總，最終將局部誤判放大成看似合理卻無法使用的行程表。

這些失敗模式不代表代理迴圈不可行；合起來看，它們說明迴圈需要明確契約、狀態追蹤與硬性預算上限。

營運設計實務準則

從原型走向正式環境時，六項設計準則能讓代理迴圈的行為更可預測。

第一，維持精簡的動作空間。只向模型開放當前任務確切需要的工具；多餘的工具會擴大選擇歧義、出錯空間與受攻擊面。

第二，強制執行嚴格的輸入與輸出 schema，確保每次呼叫與觀察在工具邊界兩側都通過驗證。

第三，將觀察結果寫入明確的結構化任務狀態（task state），別讓模型從不斷膨脹的原始對話紀錄中自行拼湊現況；明確的狀態讓迴圈更容易檢視，也能減少意外偏移。

第四，區分可復原錯誤與終止型錯誤：可修正的引數格式錯誤或許值得重試一次，access_denied 在權限未變時則不應重試。

第五，在最初設計執行器時就內建停止條件，涵蓋證據門檻、最大嘗試次數、總時間上限與核准閘門（approval gate）。

第六，將完整軌跡與最終回答一併納入評估，檢視實際呼叫了哪些工具、回傳哪些觀察、何處觸發重試，以及迴圈是否在該停的時候停下來。

實作練習

請以七個明確狀態實作迴圈執行器：plan、call、observe、complete、abstain、escalate 與 unknown。每次狀態轉換都必須儲存工具名稱、通過驗證的引數、結果類別、嘗試次數、政策決策、呼叫延遲與操作鍵。

設定最多受理 8 次工具嘗試（含被拒引數、重試與狀態核對查詢），以及 30 秒的總經過時間上限（涵蓋規劃、等待與工具呼叫）。在環境支援時取消或限時中止執行中的呼叫，同時留意：停止本機執行器並不會復原遠端已完成的寫入。接著執行以下五組測試資料：

• 成功的唯讀航班與飯店搜尋；

• 回傳 Retry-After: 2 的速率限制；

• 可透過單次重試修正的無效引數；

• 不得重試的存取拒絕；

• 模擬飯店保留可能已寫入後發生回應逾時。

先用腳本固定的觀察結果驗證確定性行為，若環境具備模型引導規劃能力，再讓每組測例從乾淨環境各跑三次（三次執行僅作教學初篩檢查，並非正式環境可靠性的統計證明）。同時評核軌跡政策合規性與最終環境狀態。tau-bench 結合了最終資料庫狀態檢查與必要回覆資訊檢查，並跨多次試驗統計一致性；但該論文特別指出，單看最終結果獎勵仍可能漏掉「未經確認即擅自執行」等程序違規，因此本練習要求額外檢查軌跡中的授權紀錄（Yao et al., 2024）。

請使用模擬時鐘測試期限與 Retry-After 等待規則，無須串接真實訂房系統。每次受理嘗試在進入驗證前即計入次數，等待或發送呼叫前先確認剩餘時間，並將工具回傳的 retryable 視為不可信的轉接層提示，不得覆寫執行器政策。預期行為如下：

再補上三組格式異常的工具回傳測例：options 為數值、同時混用 ok 與錯誤欄位，以及無效的 source_timestamp 時間戳記；啟用 format 檢查後，三者皆須在結果驗證階段被攔下。另加入一組無法定論的核對結果，驗證即使工具嘗試預算已經用盡，執行器仍會保留該筆保留操作鍵並以 unknown 終止。模擬保留工具必須以不可分割的單一步驟，同時寫入操作鍵與保留紀錄（上方的唯讀 search_flights schema 並非保留 API）。

刻意破壞的案例

假設訂房沙箱已成功建立保留紀錄 H-447，但 HTTP 回應中途遺失。缺乏防護的執行器一看到 timeout，就產生新的請求鍵重新送出，結果又建立第二筆保留 H-448；最終回覆宣稱只保留了一間房，資料庫裡卻有兩筆有效保留。

修復方式是將人工核准與正規化參數綁定至單一操作鍵：一旦寫入回應遺失，先查詢保留資料表核對現況，且唯有在目的地明文支援重複抑制契約時，才允許以同一把操作鍵重試。操作鍵必須依租戶與操作類型限定範圍、綁定正規化請求內容、拒絕內容不符的重用，並在程序重啟與整個重試有效期間持續留存。測試必須在環境中恰好只存在一筆保留時才算通過；若核對後仍無法確認結果，系統必須以 unknown 終止並轉交人工，不能另起新意圖重試。

為什麼這比代理標籤更重要

許多團隊花大量時間爭論某項功能「算不算真正的 AI 代理」，卻沒把迴圈契約寫清楚。

從工程角度來看，真正重要的是以下七個營運問題：

• 模型可以自行決定哪些事

• 模型可呼叫哪些工具

• 工具會回傳什麼型別的觀察

• 步驟之間留存哪些任務狀態

• 哪些失敗會觸發有界重試

• 哪些情境會觸發提報

• 哪些條件會強制停止迴圈

把這七個問題回答清楚，比架構名稱更能決定系統行為。精簡的動作空間、經過驗證的契約與明確的停止規則，讓失敗更容易重現與測試；比較效能時應以任務實測為準，不要預設較簡單或較複雜的迴圈一定勝出。

完成標準

只有符合以下條件，迴圈執行器才算完成：

• 每個行動與觀察都符合具型別契約；

• 租戶身分與憑證來自執行期，而非模型引數；

• 權限與輸入未改變時，存取拒絕與永久失敗不重試；

• 暫時性重試遵守延遲政策，且不超過兩種預算；

• 外部可見寫入使用冪等性與結果核對；

• 注入的工具內容不能擴張權限或選擇禁止操作；

• 所有測試資料在重複試驗中都進入已宣告終止狀態；

• 副作用後逾時的測試只產生一筆保留；

• 不必拿模型理由文字當證明，單憑追蹤紀錄就足以評核政策合規性與最終環境狀態。

知識檢核

不要回頭查看文章，直接回答：

1. 為什麼模型產生的推理文字不能當成稽核紀錄？

2. 哪一類失敗在重試前必須先執行狀態核對？

3. 為什麼重試只應在單一架構層執行？

4. 無法確認外部操作結果時，正確的終止狀態是什麼？

5. 刻意破壞的訂房保留測試驗證了什麼？

參考答案

1. 模型產生的理由可能遺漏關鍵影響因素或事後合理化答案；可稽核的事實是工具呼叫、觀察結果、政策決策、狀態轉換與實際環境結果。

2. 可能已產生外部副作用的呼叫在遺失回應後進入「結果未知」（unknown outcome）狀態時。

3. 巢狀重試層會讓嘗試次數相乘，引發重試風暴或重複執行工作。

4. 在本執行器中應以 unknown 作為終止狀態，後續再由獨立追蹤的核對程序或人工審查流程釐清結果。

5. 驗證在模擬目的地的重複抑制契約、穩定操作鍵與狀態核對配合下，即使遺失回應仍只會產生一筆保留紀錄；但這不代表任意真實訂房端點皆具備相同保證。

銜接下一篇：當基礎 RAG 不再足夠

精簡的「推理、行動、觀察」迴圈通常足以應付單純的證據查詢，但有些多步驟調查會超出單輪獨立檢索的能力。這類調查可能需要跨步驟推理越來越多的文件、留存已驗證的中繼發現，或在即時查詢與為當前案件組裝的穩定工作集之間取得平衡。

無論是在代理迴圈還是分階段管線中，一旦反覆調查需要穩定的案件資料包（case packet），而非每輪重跑一次無狀態的 top-k 檢索，檢索架構與工作記憶（working memory）就會成為核心設計課題。

完成用 RAG 建立證據錨定與記憶、狀態與知識兩篇先備內容後，請接著閱讀混合檢索與證據資料包。該篇把稀疏與密集檢索、重新排序（reranking）及有界工作上下文視為各自獨立的工程選項。反覆推理同一批證據，是評估重用與時效的理由，並不代表必須採用上述所有機制。

接續共用本機實作

下載並解壓縮旅行 Copilot 實作包，或直接使用儲存庫中的 examples/travel-copilot 目錄，並在該目錄內執行指令。環境只需 Python 3.9+；請先閱讀 README.zh-TW.md，且跨篇練習共用同一個 out 目錄。檢視 tool_loop 並執行本機動作演練：程式會讀取前一步通過的評估結果、刻意模擬已提交操作的回應遺失，並在完成一次權威狀態查詢後停止。

python3 lab.py capstone --out out

進入動作階段前，請依序執行 pipeline、retrieve 與 evaluate。本實作採用虛構紀錄、小型雙語詞彙字典、摘錄式回答與本機 SQLite 供應商資料庫；核准流程為模擬實作，不會呼叫任何模型 API、真實訂房、付款、OCR 或影像分析服務。它實作了整體架構中一段可實際檢視的垂直切面，後續擴充邊界均已明列於 README。

來源與延伸閱讀

本文參考以下主要論文與官方文件：

• 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., Dessì, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." 學習式工具呼叫決策的參考文獻。arxiv.org/abs/2302.04761

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

• Anthropic. "Building effective agents." 以簡潔可組合模式建置代理、避免過度框架化的實務指南。anthropic.com/research/building-effective-agents

• Anthropic. "Tool use with Claude." 工具 schema 設計與結果處理的官方文件。platform.claude.com/docs/en/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

• Turpin, M., Michael, J., Perez, E., and Bowman, S. R. "Language Models Don't Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting." 2023. 證實模型產生的理由文字未必忠實反映決策依據。arxiv.org/abs/2305.04388

• Greshake, K., Abdelnabi, S., Mishra, S., et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." 2023. 證實外部檢索內容可劫持整合工具的 LLM 應用程式。arxiv.org/abs/2302.12173

• Featonby, M. "Making retries safe with idempotent APIs." Amazon Builders' Library. 穩定操作識別碼、安全重試與副作用核對實務指南。aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs

• Yao, S., Shinn, N., Razavi, P., and Narasimhan, K. "tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains." 2024. 跨重複試驗的最終環境狀態與必要回覆資訊評估；指出單靠通過獎勵仍可能漏判政策違規。arxiv.org/abs/2406.12045

• RFC 9110, §10.2.3：明定 Retry-After 支援等待秒數與 HTTP 日期兩種格式。