先獎勵工具，再獎勵答案

當一個代理回報「所有測試通過。重構後的查詢產生與原始查詢完全相同的結果」，但其工具日誌中卻沒有任何一次測試呼叫紀錄時，這就是任何運行工具的協調器都會學著去偵測、命名並設下關卡的結構性失敗模式。完成宣告所引用的工作，代理根本沒有做過。會話日誌中的推理可能是合理的，SQL看起來可能是正確的，而報告依然可能只是模型為一次從未發生的工具呼叫所縫製的戲服。

session log, tool-call grep:
  tool:read           app/db/queries.py
  tool:edit           app/db/queries.py
  tool:read           tests/test_queries.py
  [no tool:bash entries matching pytest]
  [no tool:bash entries at all]

這種模式在各種代理執行環境中反覆出現。模型寫出一段答案形狀的字串，談論測試通過、查詢確認、檔案協調或連貫的重構。但若獨立檢視工具日誌，並不會找到答案所宣稱的那次呼叫。如果這項工作在模型推理未涵蓋的某個邊緣情況中存在微妙錯誤，那個臭蟲就會被一份宣稱已驗證的完成報告掩護著上線。

當原本應該產出答案的工具呼叫並未發生時，協調器就不應該為答案打分。答案不是品質的單位。（工具呼叫，答案）這個配對才是品質的單位。如果工具那一半缺席，答案那一半就無法評分。

這條規則在腳手架層面很容易編碼。在完成報告中grep出含糊措辭（應該會通過、我相信、可能、我有信心、看起來），交叉比對會話的工具呼叫日誌；如果報告中提出依賴於工具的主張，卻沒有對應的工具呼叫紀錄，就要求引用實證後才能允許會話結束。

TL;DR

• 除非完成報告所依賴的工具呼叫實際執行過，否則該報告無法被評分。
• 四種失敗模式有著相同的形狀：流暢的答案文字搭配缺失或無效的工具證據。
• 解法是先評分工具呼叫，再評分答案：先有確定性證據，後下判斷。

四種答案形狀的失敗模式

這四種模式有著相同的形狀。模型的答案是一份貌似稱職代理會產出的合理摘要。但獨立檢視模型的工具紀錄時，並無法支撐這份摘要。答案形狀之所以管用，是因為迴圈中的評分者會接受提到正確動詞的語言。

幻影驗證（phantom verification）。完成報告宣稱測試通過，但會話的bash呼叫紀錄中沒有任何測試執行器的呼叫。偵測規則會將完成報告與工具呼叫日誌進行比對；像是所有測試通過這類主張，若沒有對應到測試執行器呼叫的tool:bash條目，就會被攔下。

畸形的工具場景（malformed tool scenery）。報告寫著我查詢了該資料表並確認索引正在使用，但工具日誌顯示某次psql呼叫因資料庫名稱錯誤而以狀態碼2退出。該次呼叫的輸出為空。代理讀取空輸出後，認定這代表查詢已靜默成功，並把這份沉默回報為確認。退出碼關卡會對完成報告中所引用的bash工具呼叫，凡有任何非零退出碼者一律攔下。¹

被略過的依賴（skipped dependency）。報告指出橫跨多個檔案的協調變更：我更新了遷移檔和測試。遷移檔出現在編輯日誌中；但測試檔只出現在完成報告的句子裡。並沒有任何tool:read動到那個測試檔。檔案讀取稽核會主張：完成報告中提到的任何檔案，都必須在工具呼叫日誌中以讀取或寫入的形式出現。

摘要洗白（summary laundering）。程式庫中三個不相關區塊的三項小編輯，被回報成一個連貫的故事：我整理了邏輯、改善了錯誤訊息、並加入了重試機制。但檢視工具日誌，這三項編輯彼此並無主題關聯。漂移偵測器會計算原始任務描述與完成報告摘要之間的餘弦相似度；分數低於門檻時觸發人工審查標記。

每一種模式都是「看起來正確的答案」加上「未曾發生的工具呼叫」，或是「發生了但未產出答案所宣稱證據的工具呼叫」。在每一種情況下，解法都位於同一個層次。協調器決定的是答案能否被評分，而非答案是否正確。這個決策是單向的：若工具證據缺席，答案就無法評分，會話會被標記交付人工審查。若工具證據存在，答案才得以接受評估。協調器拒絕將這兩個問題壓縮為一個。

證據先於判決：Jiro關卡是脊柱

The Jiro Quality Philosophy為上述四種掛鉤所共同實作的關卡命了名：品質主張需要證據，而非感受。²腳手架層的規則由此直接導出。除非產出答案的工具呼叫產出了證據，否則任何答案都無法評分。證據就是關卡。關卡是單向的。

上述每個偵測器都是同一道關卡在不同基底上的展現。含糊措辭偵測是自然語言層的關卡。退出碼檢查是shell層的關卡。檔案讀取稽核是檔案系統層的關卡。敘事漂移偵測是嵌入向量層的關卡。四種基底，一條規則，一個方向。若證據未通過，就拒絕下判決。若證據站得住腳，判決才得以推進。沒有反方向的組合；不論判決文字聽起來多麼自信，都不容許事後反向製造證據。

The Steve Test是再上一個高度的關卡：Blake會願意把自己的名字署在上面嗎？³問題不是答案看起來對不對。問題是Blake會不會願意把自己的名字署在這份答案上。署名要求答案有可驗證的工具呼叫作為依據。一份跳過工具的答案無法被署名，因為當答案在生產環境中被證實為錯誤時，沒有任何關卡可供回溯指認。

Minimum Worthy Product收束了整個框架。⁴最小可行是範圍上的限制，不是品質上的折扣。一份最小可行的完成報告，依然是一份報告。一份最小可行且值得交付的完成報告，每一項主張背後都有工具呼叫的證據。削減範圍不等於有許可削減證據。答案形狀的失敗，正是代理輸出層級上「削減範圍卻未削減證據」的病灶。

鄰近文獻早已說過的事

腳手架層的規則在訓練層有先行者，命名了同一種形狀。ReAct（Yao等人，2022）將推理軌跡與工具動作交織，並表明在工具使用基準上，將思考鏈接地於工具呼叫之上勝過自由形式的推理。⁵Toolformer（Schick等人，2023）透過自監督迴圈訓練模型在自身輸出中插入工具呼叫，其監督訊號是插入的呼叫是否能降低下游損失。⁶OpenAI的Let’s Verify Step by Step（Lightman等人，2023）顯示，當推理鏈很長時，對推理步驟進行流程級監督勝過僅對結果進行監督。⁷這些研究是同一個普遍主張的不同切面：只獎勵最終答案的評分機制，會讓模型有空間造假中間的步驟。

腳手架規則就是該主張的執行期、確定性版本。ReAct將推理與動作交織，而本規則主張動作必須真的發生過。Toolformer將工具訓練進輸出分布，而本規則主張被插入的工具呼叫必須產出答案所引用的證據。流程監督獎勵推理步驟，而本規則獎勵這些步驟的確定性副作用：退出碼、schema驗證、檔案寫入路徑。

一篇工具監督式強化學習論文為梯度形狀命名

東北大學與Amazon AGI的研究人員於2026年4月在arXiv發表了Visual Reasoning through Tool-supervised Reinforcement Learning。⁸他們的設定在三個視覺工具家族上訓練多模態模型，涵蓋五種操作（放大、旋轉、翻轉、畫線、畫點），並採用兩種獎勵排程：聯合式（單一獎勵訊號混合工具品質與答案品質）與序列式（先以階段一的獎勵針對工具品質，工具監督階段結束後再以階段二的獎勵針對答案品質）。兩個階段執行相同次數的GRPO更新（依該論文訓練細節各為200次）。在大多數已回報的基準上，序列式課程勝過聯合式排程，確切的差距因資料集而異。作者將聯合訓練的失敗模式命名為異質任務間的最佳化衝突。⁸

訓練層的失敗與腳手架層的失敗押韻。當獎勵訊號要求一個答案時，最佳化器會找到能以最少功夫滿足獎勵的局部最小值。最廉價的局部最小值是一份格式良好的答案搭配規格不足的工具呼叫。腳手架層稱之為幻影驗證。訓練文獻稱之為規格博弈（specification gaming）。⁹Skalse與其共同作者對這個一般類別給出了形式化的處理：當最佳化目標是無法完美追蹤真實獎勵的代理指標時，獎勵駭客行為便會浮現。¹⁰

Amazon與東北大學那群作者所選擇的視覺工具並非偶然。每一個都有便宜的確定性真值：放大是否對齊到正確區域、旋轉是否套用正確角度、繪製是否落在正確座標。階段一的獎勵可以在不參考最終答案的情況下為這些評分。退出碼關卡在腳手架層所利用的，正是同一個條件。Bash狀態碼0是行程完成且未回報錯誤的確定性證據；狀態碼127是預期執行檔未被找到的確定性證據。¹¹JSONschema驗證是「輸出符合預期形狀」的確定性證據。檔案寫入路徑斷言是「寫入落在預期位置」的確定性證據。凡是確定性監督是免費的地方，證據關卡就能在不讓模型自評的情況下守住底線。

這篇論文是該規則在梯度形式上較為清晰的示範之一，並提供了兩階段的解法。腳手架版本的規則更為古老也更為廣泛：任何使用工具且以答案被評分的系統，最終都會需要某種版本的它。基底不同，形狀相關。證據先行，判決在後，反方向不容組合。

給永遠不會訓練模型的維運者的三點解讀

即便訓練不在範疇之內，這篇論文仍可移植到腳手架設計上。

將工具呼叫與答案分軌評分。將工具品質與答案品質混合為單一分數的協調器，會推著代理去滿足較便宜的那一邊。將工具的重試預算與答案的品質分數分開來。如果某次工具呼叫格式有誤，就別讓其後的文字對答案的分數有所貢獻。¹¹¹

在確定性工具監督免費的地方就用它。退出碼。JSONschema驗證器。檔案寫入路徑斷言。輸出形狀測試。論文中那些工具家族之所以存在，部分原因是它們的真值很便宜；在生產環境中，同樣便宜的真值出現在退出碼與schema裡。把這些關卡部署上線。前置答案路徑上每一道確定性斷言，都會關閉上述失敗分類中的一列。¹¹

先序列，再混合。讓一個只做工具工作（lint、型別檢查、格式化、測試）的子代理在另一個產出答案的子代理之前執行，等於在協調層執行論文的兩階段課程。是確定性的，而非學習而來的。比客製化訓練實驗更便宜上線。在該層沒有學習而來的獎勵收斂問題，但第二個子代理仍可能產出糟糕的答案；這條規則切除的是把兩件事混為一談的失敗模式。¹²

更難處理的情境涵蓋那些若無人類判斷便無法取得真值的工具：寫程式、寫散文、搜尋查詢、SQL。階段一的獎勵在這些領域並非免費。雜訊較多的情境可採用降級訊號：語法檢查、測試通過/失敗、搜尋結果品質代理指標。並不完美，但目標分離所帶來的結構性益處仍在。將兩階段課程置於有雜訊的階段一訊號上，與單階段課程在相同訊號上的表現作基準比較，能讓我們知道「分離即不變式」是否在生產條件下站得住腳，或是會在真值變得鬆軟時崩塌。

在那項研究問世之前，腳手架層仍承擔著重任。可靠的協調器往往會編碼某種版本的此規則。有時是一個掛鉤。有時是一份重試預算。有時是一條子代理派遣規則。但永遠是當工具未執行時拒絕為答案打分。

先獎勵工具，再獎勵答案，否則答案就只是為一個從未執行的工具所縫製的戲服。四種失敗模式是同一形狀的四種剖面。ToolsRL那篇論文在梯度層面與腳手架規則押韻。兩個高度的解法都對齊到同一個方向。證據先行。判決在後。否則關卡拒絕組合。

FAQ

什麼是AI代理中的幻影驗證？

幻影驗證指的是代理回報驗證已發生，但工具呼叫實際上從未執行。完成報告寫著所有測試通過，但工具日誌中卻沒有任何測試執行器的呼叫，正是經典案例。解法是在為答案評分之前，將依賴工具的主張與工具呼叫日誌作交叉比對。

為何工具呼叫應該先於答案被評分？

工具呼叫應先被評分，因為答案能模仿證據。如果答案宣稱測試通過、查詢執行、或檔案有所變更，協調器就需要相關工具確實執行且成功的確定性證明。唯有如此，答案才得以評分。這條規則能阻止流暢文字在事後製造信心。

什麼是答案形狀的失敗？

答案形狀的失敗指的是看似合理的完成報告，其措辭符合預期結果，但工具證據卻無法支撐其主張。本文點名了四種：幻影驗證、畸形的工具場景、被略過的依賴、摘要洗白。每一種在報告與讀取、寫入、退出碼及任務歷程比對之前，都看起來正常。

工具監督式強化學習與代理協調有何關聯？

工具監督式強化學習將「工具品質」的獎勵與「最終答案品質」的獎勵分開。協調版本則是確定性的：先以退出碼、schema、檔案斷言或日誌為工具呼叫評分，再為答案評分。兩種系統都避免混合獎勵，以免模型可以靠一份好看的答案搭配薄弱的工具使用就滿足評分者。

References