把工具定義丟給模型、等它回傳要呼叫哪個函式、執行、把結果塞回對話，再問一次——這個迴圈寫起來不到一百行，卻是最容易在 production 出事的地方。OpenRouter 在 2026 年 9 月 17 日發布的 TypeScript 教學，把重點放在迴圈的停止條件，而不是串接本身。
迴圈本身很簡單，難的是它什麼時候停
根據 OpenRouter 的教學，工具呼叫迴圈的定義是：反覆把對話與可用工具送給模型，執行模型要求的工具呼叫，附加結果，再問模型下一步。迴圈在模型不再要求工具、或應用程式自訂的停止條件觸發時結束。
關鍵分工寫得很清楚：模型決定要呼叫哪個工具，但解析參數、執行函式、決定迴圈何時必須停止，都是應用程式的責任。這代表「模型很聰明所以會自己收斂」不是設計假設，而是需要被程式碼兜住的風險。
迭代上限要在工具執行前檢查
教學裡的 runAgent() 預設 maxIterations = 10，而且檢查的位置很講究：在模型回應之後、任何工具執行之前。
理由在教學中直接說明——工具結果只有在下一輪模型請求才有用。如果模型在最後一輪仍然要求工具，迴圈會直接停止而不執行它們，因為執行只會產生模型永遠看不到、也無法回報的副作用。
同一段程式碼還擋掉不合法的上限值。Number.isSafeInteger() 會拒絕 0、1.5、NaN，也會拒絕超過 Number.MAX_SAFE_INTEGER 的值，因為在那個範圍 iteration++ 不再產生相異值，永遠碰不到上限。這類防呆看起來瑣碎，但它決定的是一個參數打錯時，迴圈是報錯還是無聲地跑下去。
重複呼叫的指紋計數，門檻為什麼是三次
教學用一個 Map 記錄「工具名稱加參數字串」的指紋，同一個指紋出現三次就中止。
門檻選三次而非兩次，教學給的理由是：兩次會誤殺那些在空結果或暫時性失敗後重試一次的模型；三次允許那一次重試，同時仍能快速停住卡死的模型。教學也明講，這個門檻與 maxIterations 預設值都是應用程式的選擇，不是 OpenRouter 的預設值。
教學另外提醒，production 環境應該先正規化解析後的參數再比較，否則只是重新格式化、內容相同的呼叫不會被算成重複；也可以針對不同工具設定不同上限。
失敗要回到模型，但只限某一類失敗
executeToolCall() 把工具參數當成 JSON 字串解析，並把 JSON.parse() 放在 try 區塊內。無效 JSON、未知的函式名稱、執行失敗，都會被包成工具結果回傳，而不是讓迴圈崩潰——模型因此有機會改參數、換工具，或直接說明失敗原因。
但教學劃出界線：驗證、網路與其他請求層級的錯誤應該離開迴圈，交給外層應用程式處理。把可預期的解析與執行錯誤餵回模型，跟把基礎設施故障餵回模型，是兩件不同的事。
每個工具結果都要帶回原本的呼叫 ID
回傳的工具訊息包含 role: "tool"、toolCallId 與 content。教學指出，toolCallId 是模型把結果對應回原始呼叫的方式；一次回應可能包含多個呼叫，每一個都需要自己的結果。
教學的示範執行中，第一輪就回傳了兩個 get_weather 呼叫，由迴圈平行執行，第二輪沒有工具呼叫，於是回傳文字答案。教學也說明，實際執行的迭代次數、答案措辭與延遲都可能不同。
對產品團隊的實際意義
這份教學沒有提出新的抽象層，反而強調不需要 agent framework 也能建出並理解這個控制流，小型實作即使日後搬進函式庫也有價值。
真正可帶走的是那幾個停損點：迭代上限、重複呼叫門檻、錯誤分類的邊界。它們都是應用層的決策，也正好是模型無法替你決定的部分。如果你正在評估工具呼叫的可靠性，這類「停在哪裡」的設計，和模型選擇一樣值得放進 review 清單；同樣的取捨也出現在 圖片模型計價單位不同時，帳單才是真相那類容易被忽略的細節裡。
教學最後提到，模型可用性會變動，選模型前應查詢目前支援 tools 參數的清單；而 models 參數提供有序的模型備援。至於教學後段關於 fallback、並行控制與 MCP 工具的內容，在取得的素材中並未完整呈現，這裡不做推測。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。