嚴格的驗收與歷史繼承機制

當算力打開候選生成之後，新的難題隨之而來：由 Agent 自動生成的修改，憑什麼可以寫進專案主幹？嚴格的驗收與歷史繼承機制把生成與採納徹底解耦——Agent 提交的任何程式碼都只是候選修改（candidate patch），必須先通過一組驗證閘門，才有資格被承認專案歷史的一部分。

候選性預設原則

Agent 的輸出預設被視為不可信輸入：它在權限、儲存與引用上與已採納版本嚴格隔離，既不能直接讀寫主幹，也不能被其他模組當作穩定依賴。這條原則的唯一目的，就是杜絕「生成即入庫」。只有在通過全部閘門之後，候選修改才獲得與主幹同等的地位。

四層遞進過濾：成本遞增、儘早失敗

• 編譯：語法與介面層面可建構。成本最低、淘汰最快，先把明顯不成立的修改擋在門外。
• 測試：單元測試與整合測試通過，涵蓋既有契約。
• 行為檢查：語意與行為一致性，包含數值容差、等價性與回歸對比，專門防範「測試通過但行為漂移」。
• 上層驗收：面向任務目標與工程約束的最終裁決，包含效能、加速比、可維護性等判斷。

閘門按代價由低到高排列，使絕大多數無效修改在廉價階段被截斷，把昂貴的上層評審留給少量高品質候選——這正是「儘早失敗」的經濟學。

拒絕的價值與歷史繼承

未通過的嘗試不進入主幹，但可以保留為失敗檔案 / 負樣本，用於診斷、去重與防止重複探索——拒絕本身即是一次雜訊過濾。而通過驗收的修改成為新的基線版本，後續執行者在此基礎上繼續演化，形成單調累積的演化鏈，而不是每輪從零重來。作為多 Agent 協作與遞迴任務拆解的合併規則與品質契約，驗收閘道定義了「誰能寫入歷史」，從而決定協作結果是收斂還是熵增。在編譯器重構與科學軟體升級等強正確性約束場景中，這套機制展現出極高的可靠性，並帶來可觀的執行加速比。