大部分的 validation spiral，根源是 workflow 沒設 stop condition
Reddit 上有人把 Sol（GPT 5.6 era 的 agent）卡在 validation phase 這件事命名成 certainty psychosis，我覺得這個詞取得很準。但我想從後端工程師的角度再往深挖一層。
我之前做過一個自動化報表的 agent pipeline，接 Postgres 資料、做聚合計算、最後輸出 PDF。上線初期整個 workflow 跑一次要 90 秒，後來我才發現其中 40 秒都在做「確認」，agent 在 validate schema、validate 欄位對不對、validate SQL 有沒有 injection 風險，一層又一層。問題是這些 validate 每次都 pass，從來沒 fail 過。坑我踩過，才知道這種東西看起來很穩，其實是一堆無效開銷。
後來我給自己定了一個準則：如果一個 check 連續跑了 20 次都 pass，而且你沒有改動任何上游邏輯，它就是 audit，不是 verification。 這兩件事要分清楚，混在一起才是 certainty psychosis 的根源。
Direct verification 的定義，我傾向這樣：在當下這個 request context 下，有哪些東西如果錯了會讓整個任務失敗，而且我現在沒辦法靜態推斷它是對的。這才值得跑一次驗證。Audit 是另一回事，是定期、批次、非同步地確認系統整體健康狀況，不應該出現在每次 agent 跑的 hot path 裡。把 audit logic 塞進主流程的主要原因，是設計時根本沒有明確分界，不知道哪些東西是 runtime 決定的、哪些是 design-time 決定的，所以 agent 就什麼都確認一次，而且是每次。
Material delta 的判斷也值得說清楚。我的標準是：如果這一步的輸出改變了，downstream 任務的結果會不會 materially 不同？ 具體例子，我有一個 step 是 fetch_user_segment(user_id)，回傳的 segment 決定後面走哪條分支，這個有 material delta，值得驗，或者加 cache invalidation 邏輯處理。但如果我在驗「這個 user_id 的格式是不是 UUID」，這是 contract validation，應該在 input layer 做一次，不是每個 agent step 都做一次。簡單說：會影響輸出路徑的不確定性值得驗，不會影響的不要驗。
我自己的實踐是這樣，每個 agent task 在 spawn 的時候帶一個 max_verification_depth，default 2。第一層驗 load-bearing 的輸入，也就是會讓任務走錯路的那些。第二層驗關鍵輸出，也就是會直接暴露給 user 的那些。第三層以上，除非明確設定 audit_mode=true，否則不跑。這不是什麼高深的設計，但有了這個 guardrail 之後，那個 pipeline 從 90 秒降到 48 秒，錯誤率完全沒有上升。那 40 秒全都是在做 certainty psychosis。
當然，有些情況確實需要更深的驗證。Upstream 資料有已知的 staleness issue，任務的後果是 irreversible 的（刪資料、發通知、扣款），或者你在 staging 環境需要較高置信度。這些情況下加一層是值得的，但要明確說「我在加驗證，原因是 X，這是一次性的 setup，不是每次跑都需要」，不是預設全開、然後每次都跑一遍。
核心問題從來不是模型不夠強。給 GPT 5.6 或任何 frontier model 一個沒有 exit condition 的設計，它就只能繼續跑。Workflow 沒有定義終止條件，模型沒有辦法自己決定「夠了」。這是 workflow 設計問題，先別急著換模型。
作者：鍵盤工人