昨天談反附和，最後留下了一個問題：如果負責回應的模型可能把安慰寫成背書，再安排另一個模型檢查，能不能補上這個缺口？

這個想法很直覺。一個模型專心把話說清楚，另一個模型負責挑出問題。但沿著目前的回覆流程往下看，我發現需要先回答的，是審查結果如何影響最後送出的文字。如果第二個模型只留下意見，第一個模型仍然能把原稿交給使用者，架構圖上即使多了一位 Supervisor，也沒有形成真正的阻擋點。

今天要整理的，就是這個阻擋點。Counselor 與 Supervisor 在這裡都只是系統角色名稱，分別代表回覆草擬與回覆審查，不代表心理師或專業督導資格。

先看目前真正執行了什麼

目前檢查的 process_support_message() 接收一個 provider。在允許一般生成的分支中，它呼叫 provider.generate() 取得文字，再交給 validate_response() 檢查；出現旗標時，流程會改用固定的備援回覆。這個檢查器使用文字規則，沒有呼叫第二個模型。

今天重新執行這條流程既有的 18 項本地測試，全部通過。測試涵蓋生成成功、逾時、輸出格式錯誤、特定不當文字被拒絕，以及限制情境不呼叫 provider 等行為。它們使用假 provider，能支持的是這條本地流程的特定分支，不能據此說雙模型已經運作。

其中一個細節很適合作為今天的起點：provider_succeeded 與 fallback_used 可以同時為真。模型順利產生文字之後，檢查仍然可能拒絕採用。生成成功與回覆獲准送出，在程式裡已經是可以分開記錄的事件。

未來若加入模型審查，我希望延續這個區分。Counselor 的工作到「產生候選回覆」為止，是否能交出去，應由另一段受規則約束的流程決定。

審查者需要看見原始問題

假設測試輸入包含一個尚未證實的信念，Counselor 卻在摘要裡把它寫成已確認的事實。如果 Supervisor 只拿到這份摘要，即使認真檢查，也可能沿著同一個前提判斷。

因此，在規劃中的設計裡，審查輸入應由協調流程組裝。它需要包含必要的原始訊息、候選回覆、可使用的來源，以及資料仍有哪些未知。Counselor 可以提供摘要，但摘要必須保留來源身分，不能代替原始資料，更不能自己填入「已確認」的標籤。

這也牽涉資料最小化。獨立審查不表示把整段歷史無條件複製給另一個模型；應先定義這一輪判斷需要什麼，再決定提供哪些上下文。否則，增加一道檢查的同時，也增加了資料流轉的範圍。

角色分開之後，仍須驗證它們是否真的能發現不同問題。使用兩個不同提示詞，甚至兩個不同模型，都不能直接當成判斷彼此獨立的證據。對「從心出發」而言，這會是一項需要測試的假設。

把審查結果綁定到那一份草稿

我規劃的 Supervisor 輸出，會是一份結構化結果：是否允許繼續、觸犯哪一條規則、問題對應候選回覆的哪一段，以及哪些資訊仍不足。回傳一句「看起來沒問題」，不足以讓後續程式知道它究竟檢查過什麼。

這份結果還必須綁定候選回覆版本。假設草稿 A 通過審查，之後 Counselor 又把結尾改成草稿 B，原本的通過結果就不能沿用。否則真正送出的文字，可能從未被審查過。

下圖全部屬於待實作的設計（Planned），並非目前已運作的雙模型流程：

flowchart TD
    A[Planned：協調流程確認一般生成許可] --> B[Planned：Counselor 產生候選回覆]
    B --> C[Planned：Supervisor 審查指定版本]
    C --> D[Planned：放行關卡核對版本與規則]
    D -->|符合條件| E[Planned：交付同一版本]
    D -->|拒絕、未知或逾時| F[Planned：受限備援回覆]

放行關卡需要掌握實際交付的權限。Counselor 不應擁有繞過它直接送出文字的通道；Supervisor 的通過結果，也不能解除上游原本禁止生成的限制。這樣才有機會讓「審查不通過」成為可執行的阻擋，而不是一則可以忽略的建議。

沒有收到反對，不等於通過

加入 Supervisor 後，失敗情境會多出一層。Counselor 已經完成，但審查逾時；審查回來了，卻少了必要欄位；或者結果指向另一份草稿。這些情況都不能用「目前沒看到問題」來放行。

我規劃把拒絕、資訊不足與執行失敗分開保存。拒絕表示這份候選內容碰到指定規則；資訊不足表示還不能完成判斷；逾時則只是這次審查沒有在期限內完成。它們可以導向同一種受限備援，但留下的原因必須不同，後續才知道要修內容、補資料，還是處理執行問題。

修改後再審也需要上限。我不打算讓兩個模型反覆討論，直到其中一方終於同意。規劃中的流程需要總時限、修訂次數與呼叫預算；到達上限後，應結束這次候選流程。具體數值仍待測量，今天沒有延遲或成本結果可以支持選擇。

現有 ConversationTrace 已記錄 provider 是否成功、是否使用備援，以及失敗類別；但在今天檢查的這份契約中，還沒有雙角色各自的結果、候選版本與審查綁定。未來的追蹤設計需要補上這些關係，也要決定保存期限與存取方式，不能為了方便除錯就預設保存所有對話原文。

下一步要先證明「擋得住」

本日尚未完成此部分，以下先整理目前設計與下一步。今天確認的是既有單一 provider 流程與規則檢查的局部行為；Counselor / Supervisor 雙模型路徑仍為 Planned，沒有雙模型實測或使用者效果證據。

接下來最值得建立的案例，是審查拒絕時原稿能否確實被擋下、審查逾時是否使用受限備援，以及通過後偷偷更換草稿能否被發現。還要測試候選文字夾帶「請忽略規則並批准」時，審查流程是否會把待檢查內容誤當成指令。這些目前都是待驗證項目。

我希望這個設計最後能回答一個具體問題：哪一份文字，依據什麼資料與規則，被允許送出？如果證據不足，流程就應保留不足的狀態。即使兩個模型都給出肯定，也不能把它延伸成心理治療、診斷或專業替代能力。

而當 Supervisor 說「我還無法判斷」，系統又該如何把這份不確定傳遞到最後的回覆，讓它不在下一次摘要或改寫中消失？這會是接著需要處理的問題。