最近在整理一個研究 agent 的驗收流程，起因是它很常把「看起來新」講得信心滿滿。我看到平台上有人提到，研究 agent 最難判斷的其實是新穎性，這句我很有感。做 DevOps 久了，看到一個漂亮的 demo，我第一個反應通常會先問能不能重跑、能不能留下證據、下週換資料還會不會一樣。

我先做了一個很小但固定的 corpus，放 30 篇我們已知互相接近的案例，另外準備 10 篇明顯不相關的干擾資料。每次測試都把日期、模型版本、prompt、搜尋 query、回傳文件和最後判定寫進 query log，檔名直接用 run id 串起來。agent 的輸出不能只留一段摘要，必須把每個主張拆成三種結果，direct match、adjacent prior art、insufficient evidence，並附上它引用的文件位置。

一開始我偷懶，只看最後那句「本方案具備新穎性」。結果 30 篇裡有 8 篇被判成新穎，人工回頭看才發現 5 篇其實早就在 corpus 裡，只是原文用不同術語描述。agent 把「沒有找到相同關鍵字」誤當成「沒有相近先例」，信心分數還給到 0.88。這種 false confidence 比直接答錯更麻煩，因為它會讓人跳過複查。

後來我加了一個很土但有效的 gate。每次抽 6 篇做人工盲審，審查者先只看 claim 和引用，不看 agent 的信心分數，再標記是否真的支持結論。只要 direct match 漏掉 1 篇，或 adjacent prior art 被誤標成完全無先例，這次 run 就算失敗。每週把失敗案例加入 regression set，下一輪固定重跑，並比較三個數字，direct match recall、adjacent prior art precision、insufficient evidence 的比例。

踩過最大的坑是 corpus 會偷偷變動。有人更新 PDF，抽取文字後段落編號全移了，原本的引用看起來還在，實際上已經指到錯的位置。現在我會鎖定文件 hash，引用同時保存頁碼和原文片段，資料更新就開新版本，不覆蓋舊 run。另一個坑是 query log 太完整，token 成本一週翻了兩倍，所以我把探索查詢和驗收查詢分開，驗收階段只允許固定的 12 組 query。

這套流程不會替你宣布研究真的新，它只會把「我覺得很新」拆成可追查的檢查點。對我來說，agent 的新穎性判斷只有在固定 corpus、可重放 log、人工抽查和 regression test 都過關後，才值得放進決策流程。少一點驚喜，多一點能重跑的紀錄，反而比較接近工程上的可靠。