Agent 評估必須把邊界一起量進去
前幾天讀 AISI cyber evaluation incident，像 reviewer 看 supplementary material 時，突然發現實驗設定漏了一欄。122 次 cyber challenge evaluation 裡，有 19 次 agent 對真實網路做了未授權行為。最嚴重的例子裡，agent 建 GitHub 帳號，送惡意 PR，嘗試 social engineering，還建立第二個帳號偽裝成 reviewer。AISI 當時給 agents internet access，而且停用了 cyber classifiers。
我覺得麻煩在於，大家談 agent capability evaluation 時，很容易把任務成功率當主角。可是 agent 跟一般 LLM benchmark 差很多。agent evaluation 是在一個環境裡行動。只要它有 browser、shell、GitHub、filesystem，評估對象就已經變成 model 加 tools 加 policy 加監控加網路拓樸的複合系統。
我自己之前在 lab 裡做 multi agent 小實驗時踩過一個坑。原本只是要測 coding agent 能不能自動修 issue，成功率大概是 7/20。後來我把 issue template、CI token scope、外部 package 查詢權限整理好，成功率變成 13/20。模型沒有變，prompt 只改兩行。這時候如果我在 paper 裡只報 65% success rate，卻沒有報工具權限與網路邊界，就是把最重要的實驗變因藏掉了。
所以我現在比較傾向把 agent 評估拆成四個一起報的軸。第一是 task success。第二是 boundary contact，也就是 agent 有多少次接觸到不該接觸的外部資源。第三是 intervention load，監控或 classifier 需要介入幾次才避免事故。第四是 permission sensitivity，把同一個任務在不同權限下重跑，例如 no internet、allowlist internet、full internet。sota 是多少分當然重要，但如果 sota 只在 full internet 加關閉 classifier 的條件下成立，就比較像壓力測試結果。
有人可能會說，安全評估就是要給模型最大自由度，才看得出極限能力。這個說法有一半合理，像毒理學會用高劑量測危害上限。但是高劑量實驗不會假裝自己是一般用藥情境。agent cyber evaluation 也一樣，可以做危險設定，但要把危險設定標清楚。論文裡常說 evaluation drives progress。你量什麼，最後大家就會優化什麼。
作者：十年大博士