對抗式複審不是橡皮圖章:兩輪相反結果的對照
這天我在整理自己的 AI agent 記憶系統,順手研究了兩個開源專案(TencentDB-Agent-Memory 和 obra/superpowers),挑出幾個值得學的改動。 其中兩個我沒自己下判斷,而是交給同一套流程:讓一個較快、較便宜的 model 實作,再讓另一個同型 model 去對抗式複審。兩個改動、同一套流程,結果卻相反——一個被否決、一個通過合併。 回頭看,決定結果的不是流程本身,是「複審手上有沒有客觀標準可以打」。 那套流程長什麼樣 拆成兩個角色,刻意用不同的 agent: 實作 agent:在隔離的 git worktree 改 code、自己驗證、commit、回報。 複審 agent:進同一個 worktree,被明確指示「去 refute 第一版的宣稱、找邊界 case」,不是幫忙背書。 關鍵設計只有一條:複審不能是實作者自己。實作者對自己寫的東西有動機說「大致還好」,這個動機本身就是盲點來源。 第一輪:一個排序改動,被 golden bench 打回 背景是記憶搜尋的排序,想從線性加權換成 RRF(reciprocal rank fusion)。 實作 agent 加了新模式、保留舊的當預設、跑了幾個 query 的 A/B 對照,自評「大部分持平,有一個 query 略差」,並宣稱測試通過。 複審 agent 做了實作 agent 沒做的一件事:跑 repo 裡本來就有的 golden benchmark。結果不太好看: MRR 從 0.675 掉到 0.188、Recall@1 從 0.60 掉到 0.07。15 題裡 8 題退步、0 題改善。不是「略差」,是全面退化。 一個真 bug:RRF 讀到的是四捨五入到小數點三位的顯示值。在低區分度的 query 上,幾百個候選塌成十來個相異值、出現 35-way 平手,排序退化成按掃檔順序抽籤。 一個空測試:複審做了突變測試——把舊路徑的一個關鍵係數整段拿掉,測試竟然全綠。所謂「測試通過」根本沒在保護舊行為。 判決:否決,branch 直接刪掉。舊的本來就是預設,零損失。 ...
