Agent 的工具呼叫為什麼會在上線後突然壞掉？很多時候，模型沒有變，工具的「語意」也沒有變，變的是介面。

這篇 2026-10-16 提交的論文把問題稱為 interface drift：部署後 tool description、argument schema，甚至候選工具清單發生變動，讓原本學會的 function calling 對不上新的介面。這個切角很重要，因為我們常把失敗歸咎於模型能力，卻忽略了 agent 依賴的是一組會演化的契約。

作者提出不需要 retrain 的 SchemaShield-Lite，核心不是盲目多試幾次，而是分三層處理：先做 schema validation；若模型叫了不存在的 tool name，就在新的 candidate set 上重試；最後只做一次 constrained repair，修正能被約束明確判斷的輸出。以 Qwen3.5-9B 測試，DICE-300 accuracy 從 0.717 升到 0.813，BFCL-200 從 0.580 升到 0.805；它修復了兩組 drift failures 中的 19/22 與 33/45，實驗中未觀察到 repair harms。ablation 也指出，candidate-set drift，尤其加入 distractor tools，傷害最大。

但要精確解讀：這些是特定 benchmark、模型與 drift 設定下的證據，不等於所有 agent 工作流都已可靠。論文展示的是介面漂移的可修復性，不是推理錯誤、權限錯配、工具副作用或惡意輸入都能被處理。

為什麼單純 retry 不夠？如果工具清單已變，模型每次看到的仍是同一個模糊描述，重試只是重新抽樣同一個錯誤分布；schema 不合法時，也可能把錯誤參數再生成一次。這裡真正增加的是驗證訊號，以及讓候選集合參與重新決策。retry 是時間上的重複，SchemaShield-Lite 則是改變模型面對的約束。

對部署者而言，tool description 與 argument schema 應視為版本化 API，記錄 breaking change，並保留相容層或 migration。每次發布都要用固定的 function-calling 回歸集，分測 schema drift、tool-name drift 與 distractor tools。validation 必須在執行工具前完成，repair 只能落在 schema 能確定的邊界，不能替模型猜高風險參數；一次 constrained repair 仍失敗，就交給 fallback 或人工確認。並記錄原始輸出、漂移版本、修復內容與副作用。

嚴格來說，這不是替 agent 買可靠性保固，而是把一類常被混在模型能力裡的介面故障，拆成可以測試、版本化與有限修復的工程問題。這個拆分，可能比單一 benchmark 的提升更值得帶回部署現場。