在 Day 27 的計算題裡，我使用的推理系統已經算出 12.0，模型最後卻因為輸出被截斷而交出 18。後來我並沒有重新訓練模型，也沒有換一個更大的 checkpoint；同一個 Qwen-trace distilled model 收到相同的工具結果，第一次回答仍被 final-answer verifier 判錯，系統於是要求它重新核對。第二次回答抽出的答案是 12.0，答對了此題。

同一組 12 道題因此由 Day 27 的 8/12 變成 9/12。多出來的一題發生在模型權重之外：verifier 看見錯誤，系統再給一次有上限的修正機會。

前二十七天從 Base Model、自迴歸生成與 sampling 開始，接著建立 evaluator、計算 test-time compute、整理 teacher data，再嘗試 SFT、RLVR、蒸餾與工具使用。回顧這趟旅程，實驗結果並不總是變好的：SFT 曾經把格式推到 633/640，正確數卻從 Base 的 103/640 降到 54/640；Day 25 最好的 RLVR checkpoint 是 32/256，仍低於 Base 的 41/256；直到 Day 26，distilled candidate 才在另一份凍結的 128 題開發集以 105/128 通過定下的晉級規則。

這三組數字來自不同的資料與評估方式，顯然是不能直接比較，但它們在今天將決定哪些結果可以進入最後的整合：系統採用 Day 26 晉級的 distilled model，接上 Day 27 的三項工具，再把 verifier、狀態保存與有限重試放到外圍。

問題
→ 模型產生 JSON tool call
→ schema validation 與 restricted executor
→ 保存 tool result
→ 模型產生 final response
→ final-answer verifier
→ 接受，或要求一次修正
→ 保存完整題目狀態

Reference answer 在生成期間維持隱藏，只在回答完成後交給 verifier。模型不會在修正 prompt 裡看見正解，只知道上一份回答沒有通過，並被要求重新檢查同一個 tool result；一次修正後仍然錯，系統就停止，不讓 retry 變成沒有上限的抽樣。

每道題各自保存一份 JSON state，依序記錄 tool call 已經產生、工具結果已經落盤、final response 已經評分，以及題目是否完成。每次更新先寫入暫存檔，再取代原本的 state；重新啟動時，已完成的題目直接重用，已有工具結果的題目也不必再次執行工具。

在第一次正式執行時，前六題已經完成，第七題要求計算 7! / (5! * 2!)；模型產生的 calculator call 通過 JSON schema，受限 executor 卻不接受 ! 這種 factorial syntax。當時的程式只處理 tool call 格式錯誤，沒有把「格式正確、執行遭拒」接回修正路徑，於是整個 process 在第七題停止。

停止時留下七份 atomic states：前六份是 complete，第七份停在 tool_ready，正式 summary 尚未寫出。修正 executor rejection 的路由以後，續跑程式沒有刪掉這些紀錄，也沒有重算前六題；它從第七題的既有 tool call 繼續。模型獲得一次修正機會，仍然送出同一串不受支援的 7!，系統便保存 safe error，再進入 final response。最後兩次回答都沒有通過 verifier，這題以錯誤狀態完成。

除了這次真正發生的中斷，實驗還事先安排兩種故障。第一題的 calculator 第一次執行時收到 transient timeout，第二次才回傳 761；第一道搜尋題則在 tool result 已經保存後，故意拋出模擬 process interruption 的例外。driver 捕捉例外並再次進入該題時，直接使用原本的搜尋結果，沒有重新呼叫工具。

calculator-01  timeout → 重試 executor → 761 → complete
search-01      tool result 已保存 → process 中斷 → 從結果恢復 → complete
python-03      executor rejection → 修正仍遭拒 → safe error → complete／wrong

三條路最後都達成 complete，但意義卻不相同：前兩題驗證的是指定故障發生後仍能保留進度，第三題則顯示 bounded recovery 的界線：executor 不放行不支援的語法，模型又沒能在一次機會內改對，系統寧可留下明確的錯誤，也不無限重試。

最後 12/12 份 state 都完成，9 題答對，共有 5 題啟動 final verifier retry。其中 calculator 的 12 與 sqrt(2) 兩題在第二次回答獲救，另外三題仍然錯，而且全落在 Python 類別。12 人選 3 人的題目第一份回答先寫出 220，輸出卻在後續推導中截斷，evaluator 最後抽到 1；重試時模型又把空的搜尋結果解讀成沒有可用資料，乾脆不作答。Verifier 固然可以拒絕答案，卻無法保證下一次生成就會理解錯在哪裡。

因此，9/12 必須寫在 system card，而不能變成 distilled model 的新成績。Model card 記錄的是 Day 26 選了哪一份 checkpoint、它在哪一份 internal development 通過什麼規則，以及 MATH-500 仍是 0 次推論；system card 才記錄工具、executor、verifier、atomic state、retry 與故障恢復。兩種故障注入與 12 道內部教材題，只能說明目前列出的 timeout、process interruption 與 executor rejection 進入了預定路徑，它們並非 production reliability 或 security certification。

即使鐵人賽接近尾聲，我們從頭打造的、基於 Qwen 3 0.6B 模型的推理系統依然會計算錯誤、選錯工具、重複生成，也可能在 verifier 提醒後繼續犯錯，但這些失敗都是有價值的：我們能夠區分哪些能力是來自模型權重，並先經過訓練與 checkpoint selection 的實驗檢查；缺少的外部資訊交給工具，最後答案是否通過交給 verifier，執行進度則交給 state machine，我個人認為這才是一個「推理模型」該具備的完整架構，哪怕只是基於小模型，也有著足夠完善的系統來支持。