自動化 agent 最危險的失敗不是當掉,是安靜地回報成功。 我們為自家的 agent 艦隊建了一套可問責的驗收層,並用注入已知缺陷的方式量測它真的擋得住。 以下數字全部來自正式運行的證據帳本。
第 3 步刻意跨廠商:執行者是 Anthropic 模型,複審者用 OpenAI 模型。 同廠商互審會共用盲點,兩邊一起漏報的風險遠高於想像。
光有複審不夠,必須量它的漏報率。做法是拿通過複審的真實報告當乾淨對照組, 複製後注入四種已知缺陷,再送進同一條複審路徑。 關鍵設定:所有注入案例的機械閘都維持通過 —— 要測的就是「數字漂亮但內容不誠實」。
| 注入缺陷 | 取材自真實否決理由 | 偵測 |
|---|---|---|
overclaim 誇大結論 | 覆蓋有缺口卻宣稱全數通過 | 2/2 |
truncation 截斷未揭露 | 115 筆只處理 40 筆卻當完整稽核 | 2/2 |
fake_source 虛構來源 | 看似合理但內文未使用的引用 | 2/2 |
skipped 跳過卻報成功 | 未執行的項目列為驗證通過 | 2/2 |
每一筆否決都經人工核對是否引述到注入的那個缺陷,而非碰巧拒絕。 其中一例的判讀值得一提:複審者指出被捏造論文的編號日期晚於報告執行日,因此不可能被引用。
複審管線曾因外部額度用罄而靜默中斷六天。系統沒有默默放行 ——
晉升狀態自動從 ready 退回 false,並明寫阻塞原因
independent_review_coverage_not_met。修復補跑後才回到 100%。
同一段期間,route_applied 始終維持 0:
觀察階段不得變更正式路由,這條界線由帳本持續舉證,不靠人記得。