Day 17｜模型越強，不代表系統越可靠

Day 16 最後問該不該養著一個長 session。當時我心裡還藏著一個更直覺的答案：主控放最強的模型，總該最穩吧。事實剛好反過來。我把那份寫給主控的派工規則檔，整段交給系列裡最貴的那個模型（總經理用），它的安全機制把整段判成「網路安全類不當內容」，直接拒收，一條規則都沒執行。同一份文字交給經理入口那個較便宜的模型，照跑，什麼事都沒有。規則一個字沒改，換上更強的模型，系統反而停在第一步。

事故：規則沒變，換了交付方式就過了

同一份規則，我試過三種組合。

第一種，把規則全文貼進使用者訊息，交給最貴的那個模型：整段被判成網路安全類，拒收。第二種，同一個模型、同一份檔案，但訊息裡只寫一句「先去讀那份規則檔」，讓 session 自己把檔案讀進來：正常執行。第三種，經理入口用的是較便宜的模型，規則以系統提示的方式注入：同一份文字完全不受影響。

所以擋下它的不是規則內容本身，而是「這段文字從哪個入口、以什麼身分進來」。貼進訊息像使用者的要求，自己讀檔進來則是工作素材。這是我的判讀：入口的身分也在判斷範圍裡，而這層判斷在不同模型上落點不同。

這不是第一次。自製記憶系統裡有一條 2026-08-31 的摘要：我當時以為模型被「降級」是額度用完，追下去才發現根因是安全機制誤判，觸發了「被拒後自動退回舊代模型重試」，而且這個狀態會鎖住整個 session。表面照常，後面每一輪其實都換了人做，而且不報錯。

另一種型態出現在執行者身上。9 月上半，記憶系統陸續記著幾次 Opus 執行者在一般任務中途被同一套機制判成網路安全類而中止：掃描程式庫、跑修復、做抽取。處置都一樣：改派 Sonnet 執行者，或改寫輸入後重派，最後都完成了。

但口徑要先講清楚。記憶系統裡是人寫的摘要，不是機器紀錄；能在事件紀錄裡交叉查到的，全期只有 2 筆，而且兩筆發生在同一分鐘（2026-09-14 11:37），都是 Opus 執行者、都被判成網路安全類。兩個來源筆數對不上，我不硬湊成一個數字。

證據：失效存在，但不在你以為的位置

上框是最貴的那個模型，下框是經理入口的較便宜模型。只有「全文貼進使用者訊息 × 最貴的模型」這一格被拒收；同一個模型改成自己讀檔就通過。同一個模型之內，決定結果的是交付方式。

這張圖回答開頭的矛盾：更強的模型沒讓規則更可靠，反而多帶一種失效模式。

接著問：這種失效在整體裡佔多大？以下都是本輪重跑的數字，逐輪用量紀錄從 2026-09-05 起、派工稽核紀錄從 09-14 起，都算到 09-27。

派工稽核紀錄全期 1301 筆，結果分布是：一次通過 722、未複核 430、重試後通過 42、帶警告通過 25、硬失敗 36、被擋 46。硬失敗約佔 2.8%；其中因模型端安全機制誤判而硬失敗的只有 2 筆，佔硬失敗約 5.6%。其餘硬失敗除 2 筆測試阻擋外，多是環境、逾時、驗收未達標這類一次性原因；被擋的 46 筆多屬瀏覽器連線與環境判定，不是模型誤判。

疑似靜默降級：逐輪用量紀錄出現舊一代模型的，全期只有 1 輪，日期 2026-09-06；同期總輪數 3066，佔比約 0.03%。單輪即滅入口逾時 3 筆；子 agent 被中止的退出碼 0 筆。

由上而下依日期排列，每格只寫日期、被判成哪一類、怎麼處置、幾筆。最後一格發生在寫這篇的同一輪。

最後一格是 2026-09-27，就是這一輪。一件替這個系列盤點數字的工作派給隔離環境內的執行者，被標記中止，單輪無產出：退出碼 1、跑了 8 輪、約 34 秒。改寫輸入內容後重派。

保留一個不利口徑。執行者被安全機制中止、能查證的事件是事件紀錄 2 筆加本輪 1 筆，共 3 筆，相對 3066 輪。樣本太小，只能說「這類失效存在，而且已被機制記錄」，不能說常發生，也不能算機率。另外，派工稽核裡除了安全機制中止，沒有其他模型專屬的失效分類，越權、幻覺這類我無從估算；記憶系統之外還有沒有沒被記下的誤判，也查不到。

解法：把可靠性放進機制，不寄望模型

三種失效，處置裡都沒有「換更好的模型」這一項。

規則拒收的處置是固定交付方式：總經理入口的規則改成「先讀檔」的固定寫法，經理入口維持原本的全文注入。兩個入口各用驗證過能通的方式，不求一致。

靜默降級分兩層。機制層在啟動腳本裡，把「被拒後自動退回舊代模型重試」這個設定關掉，讓誤判變成看得見的失敗，而不是悄悄換人。提醒層是一支 hook，真的降級時會出聲。Day 13 講過它的限制：它無法代我切回去，只能由我手動處理。

執行者被中止的處置寫進派工規則：這類事件歸為環境阻擋，不計入升階次數，改派或改寫輸入後重派。如果把誤判當成執行者能力不足，系統就會一路往更貴的模型升，而更貴的模型正是誤判發生的地方。

這三條的共同點是：失敗會被看見、會被分到固定類別、每一類都有寫死的處置。模型會換代，判斷邊界會移動，但這三件事不會跟著模型走。

本輪那筆新事件就照這套走完：被標記、單輪無產出、歸類、改寫輸入、重派，沒有人臨場判斷該不該換模型。可靠性不是某個模型給的保證，是這些處置被寫死之後，換誰上場都跑得通的結果。

新問題：哪個位置該放哪個模型

這篇推翻的是一個很自然的假設：越重要的位置放越強的模型。實際上，最貴的模型坐在主控，帶來的是一種便宜模型在自己的入口（系統提示注入）沒碰上的失效；而除了本輪那筆，記錄到的執行者中止事件都落在 Opus 執行者身上。

但「更強不等於更可靠」只是否定句，沒告訴我怎麼選。主控要判斷力，執行者要穩定，中層經理兩邊都要一點。哪個位置放哪個模型，憑的是什麼？憑感覺挑，下次換代就會再踩一次。

更麻煩的是，這個決定散在入口設定、派工規則和我的腦袋三處。今天我記得總經理入口要先讀檔，下個月換了模型，這件事可能只剩在某次事故摘要裡。位置與模型的對應，得有一個地方明確寫下來，並且跟著失效紀錄一起改。

明日預告：Day 18｜多模型派工：為什麼選型表要寫死在檔案裡