## 摘要 一個漏洞掃描器把召回從 39% 拉到 80%誤報也跟著漲而且超過一半的「抓對了」其實是蒙對的。這篇 **DREA**Decoupled Reasoning and Exploration Agents解耦推理與探索智能體是 arXiv 2026 的論文。做法很干脆安全推理交給貴的大模型翻倉庫交給本地小模型。在自建基準 RepoPairBench 上配對正確率從 19–26% 提到 30–42%可計費 API 成本降到原來的 1/16 到 1/48。如果你在做代碼安全、也在給 LLM 智能體算成本這篇的兩個數(shù)字值得記住。 **視頻講解**[點擊觀看 B 站視頻](https://www.bilibili.com/video/BV1GZJB62EW4) 章節(jié)時間軸 - 00:35 作者介紹 - 00:58 研究背景與動機 - 01:54 相關(guān)工作 - 02:25 方法 - 03:41 實驗設計 - 04:43 實驗結(jié)果 - 07:22 局限性 - 07:51 要點總結(jié) - 08:25 參考文獻 [TOC] ## 論文基本信息 | 項目 | 內(nèi)容 | |---|---| | 標題英文 | DREA: Decoupled Reasoning and Exploration Agents for Repository-Level Vulnerability Detection | | 標題中文 | DREA解耦推理與探索智能體的倉庫級漏洞檢測 | | 作者 | Mingyang Sun, Guozhu Meng | | 機構(gòu) | 中國科學院信息工程研究所 · 中國科學院大學網(wǎng)絡空間安全學院 | | 會議 | arXiv 2026 | | arXiv | [arXiv:2607.13439](https://arxiv.org/abs/2607.13439) | | 項目網(wǎng)站 | [github.com/huhusmang/DREA](https://github.com/huhusmang/DREA) | ## 背景與動機 這一節(jié)回答一個問題為什么只盯著一個函數(shù)看不出來漏洞。 真實漏洞很少老老實實待在一個函數(shù)里。權(quán)限檢查可能寫在另一個模塊參數(shù)校驗在調(diào)用方項目級配置藏在配置文件里。只把一個函數(shù)喂給模型這些證據(jù)根本不在視野中。 論文舉的例子是 CVE-2021-43781出問題的項目叫 invenio-drafts-resources。漏洞函數(shù) publish 其實調(diào)用了權(quán)限檢查 require_permission(identity, publish)。函數(shù)級分析器看到這一行就判定「已鑒權(quán)」。缺口藏在函數(shù)之外這次檢查沒有綁定到 id_ 選中的那份草稿對象上它只驗證了一個全局能力。 DREA 靠三個跨文件事實還原了攻擊路徑。第一同項目的 read_draft、edit、delete_draft 都傳了 recorddraft 做對象級鑒權(quán)。第二默認的 can_publish 策略是最寬松的「任意用戶」。第三目標調(diào)用偏偏漏掉了 record 參數(shù)。官方補丁正是補上這個參數(shù)。 論文開篇還用了一個審計員的隱喻來定題。它說現(xiàn)實中的漏洞審計本來就是假設驅(qū)動的審計員先立一個懷疑再挑著追數(shù)據(jù)流、校驗邏輯和權(quán)限檢查去證實或推翻它。隨后論文用一句反問收口能不能讓檢測從「靜態(tài)上下文增強」換成「假設驅(qū)動的倉庫探索」。 已有做法的問題正在這里。VulEval、ReposVul 這類工作會用調(diào)用圖、依賴切片來補上下文規(guī)則是固定的。固定規(guī)則給出的上下文與當前那條安全假設無關(guān)。 ## 研究主線從問題到結(jié)論  **圖 4研究主線。問題出在函數(shù)級看不到跨文件證據(jù)結(jié)論落在推理瓶頸上。** ## 基準/方法設計 這一節(jié)講清楚 DREA 到底怎么分工。 DREA 由兩個智能體組成。**Planner** 用強推理模型從目標函數(shù)出發(fā)識別安全敏感操作形成初始漏洞假設再決定下一步要什么證據(jù)。**Explorer** 是本地部署的輕量模型用的是 4-bit 量化的 GLM-4.7-Flash跑在單張 A800 上支持 256K 上下文。它只負責檢索事實不做漏洞判定。 判決有硬約束。判 VULNERABLE必須給出從攻擊者可控輸入到危險操作的觸發(fā)路徑。判 BENIGN必須論證相關(guān)操作已經(jīng)被充分防護。這逼著模型把話說實而不是憑感覺給個標簽。  **圖 1DREA 架構(gòu)。Planner 不斷修正安全假設把取證請求交給本地 ExplorerExplorer 用只讀工具在倉庫里導航回傳結(jié)構(gòu)化發(fā)現(xiàn)。** 配套基準叫 **RepoPairBench**。它從 NVD 里取帶 CVE 編號的修復提交用 PyDriller 抽出函數(shù)級 diff。每對樣本有三件套父版本里的漏洞函數(shù)、修復后的函數(shù)、以及還原整個工程所需的倉庫地址與提交哈希。時間窗鎖定 2021 到 2025 年的 Python 漏洞理由是 Python 維護活躍、修復提交量大而且跨文件判斷的問題足夠多。最終 100 對樣本覆蓋 48 個 CWE 類別展開成 200 個分類實例。 每一對都準備兩份倉庫快照修復提交的父版本和修復提交本身。漏洞函數(shù)在修復前狀態(tài)下評測修復后的函數(shù)在修復后狀態(tài)下評測。這樣上下文和代碼版本始終對得上。 ## 分類全景  **圖 5四條技術(shù)路線的分野。前三條檢索的是靜態(tài)可抽取的上下文DREA 把探索方向交給安全假設。** ## 方法細節(jié) 這一節(jié)補充實現(xiàn)上的幾個關(guān)鍵選擇。 Explorer 只有四個只讀工具ls、glob、grep、read_file。工具集是刻意做小的目的是不讓它越界去做判定。 它的返回被組織成三類結(jié)構(gòu)化發(fā)現(xiàn)。第一類是倉庫上下文比如相關(guān)文件、調(diào)用關(guān)系、模塊結(jié)構(gòu)與執(zhí)行流。第二類是代碼證據(jù)也就是命中的代碼片段與關(guān)鍵語句。第三類是安全發(fā)現(xiàn)比如缺失的檢查、不一致的授權(quán)寫法、可疑的數(shù)據(jù)流鏈接。原始代碼不會整坨塞回 Planner。 實驗里每個樣本大約跑 10 輪交互證據(jù)夠了就提前停。這個預算讓貴的模型只花在推理上。 推理質(zhì)量怎么判論文用 LLM 當判官判官選 GPT-4.1。選它的理由有兩條長而雜的輸入下指令跟隨穩(wěn)定它不在任何被測骨干里避免模型偏愛自己的推理風格。判分看四件事CWE 類別是否對齊、缺陷定位是否準確、根因是否抓住、利用機制是否成立。判定從嚴識別出另一個「說得通」的漏洞也算理由錯誤。 判官本身也被校驗過。作者按模型和方法分層抽了 50 例請兩位有五年以上漏洞分析經(jīng)驗的研究員獨立標注。判官與兩人的一致率是 96% 和 94%Cohens kappa 分別為 0.92 和 0.88。兩位標注者彼此是 92%kappa 為 0.84。 ## 實驗設計與結(jié)果 這一節(jié)給出量化結(jié)果。 實驗設三種 Planner 骨干GPT-5.2、DeepSeek-V3.2、GLM-4.7。Explorer 固定為本地 GLM-4.7-Flash這樣檢索端的差異被壓掉比較反映的是 Planner 行為?；€有三種只給目標函數(shù)、給整個文件、以及「單智能體」——同一個骨干直接拿工具但沒有 Planner 與 Explorer 的分工。 主表用配對正確率Pair-CorrectnessP-C當主指標。它要求一對樣本的漏洞版和修復版全部判對才算這一對正確。相比單點準確率這個口徑更難被「多報漏洞」刷分。 | 模型 · 方法 | Recall (%) | FPR (%) | P-C (%) | Youdens J (pp) | |---|---|---|---|---| | DeepSeek-V3.2 · DREA | 80.0 | 45.0 | **42.0** | **35.0** | | DeepSeek-V3.2 · 僅函數(shù) | 39.0 | 32.0 | 19.0 | 7.0 | | GLM-4.7 · DREA | 59.0 | 38.0 | **34.0** | **21.0** | | GLM-4.7 · 僅函數(shù) | 54.0 | 43.0 | 26.0 | 11.0 | | GPT-5.2 · DREA | 53.0 | 28.0 | **30.0** | **25.0** | | GPT-5.2 · 僅函數(shù) | 42.0 | 25.0 | 21.0 | 17.0 | 三個骨干上 DREA 都拿到更高的 P-C 與 Youdens J。Youdens J 的定義是 $J\mathrm{Recall}-\mathrm{FPR}$它漲說明不是靠多報漏洞換分。DeepSeek-V3.2 的召回漲了 41 個百分點誤報只漲 13 個點。GLM-4.7 甚至在提高召回的同時把誤報從 43% 降到 38%。 消融實驗只在一個骨干上做因為每次跑一個樣本要百萬級 token。結(jié)果的分層很清楚。 | DeepSeek-V3.2 配置 | Recall (%) | FPR (%) | P-C (%) | API token (K) | |---|---|---|---|---| | DREAPlanner Explorer | 80.0 | 45.0 | **42.0** | 88 | | 單智能體直接給工具 | 73.0 | 64.0 | 24.0 | 442 | | 整文件上下文 | 57.0 | 41.0 | 26.0 | 20 | | 僅函數(shù) | 39.0 | 32.0 | 19.0 | 3 | 最值得看的是單智能體這一行。它的探索能力和 DREA 完全一樣卻只拿到 24% 的 P-C誤報率高達 64%。原因是它把 442K token 的原始代碼全塞進了上下文。整文件也不好過只比僅函數(shù)高 7 個點誤報從 32% 升到 41%說明無方向的上下文會引入噪聲。 成本表回答「解耦值不值」。 | 模型 | 總 token | Planner token | API 占比 | 成本降幅 | |---|---|---|---|---| | DeepSeek-V3.2 | 1,397,669 | 87,847 | **6.3%** | 約 16 倍 | | GLM-4.7 | 1,560,519 | 32,557 | **2.1%** | 約 48 倍 | | GPT-5.2 | 345,691 | 8,357 | **2.4%** | 約 41 倍 | Explorer 承擔了 93.7% 到 97.9% 的 token全部跑在本地單卡上不進 API 賬單。Planner 只占 2.1% 到 6.3%。論文的口徑很克制只算可計費 API 成本沒有折算本地 GPU 開銷。 類型層面的差異也很大。數(shù)據(jù)流型漏洞最好做。DeepSeek-V3.2 在 CWE-79 上到 69.2%在 CWE-94 上到 71.4%。反序列化類的 CWE-502 跨模型是 42.9% 到 57.1%。缺防護型就吃力得多CWE-284 跌到 0% 到 20%CWE-20 停在 14.3% 到 28.6%。  **圖 2真陽分解。每根柱子分成「理由正確」與「Lucky Hit標簽對、理由錯」兩段柱上百分比為 Lucky Hit Rate。**  **圖 3按 CWE 類別分層的 P-C。上方數(shù)據(jù)流型漏洞一致優(yōu)于下方缺防護型漏洞括號內(nèi)為該類別的對數(shù)。** 探索越多是不是越好答案是否定的。DeepSeek-V3.2 的假陰樣本平均花 170 萬 token比真陽的 124 萬還多 37%。全部配置下每樣本 token 量與判對率的相關(guān)系數(shù) $r\approx-0.34$。各結(jié)果類別的平均工具調(diào)用次數(shù)都在 9.2 到 10.0 之間幾乎沒差別。 ## 結(jié)果對比總結(jié)  **圖 6同一骨干下的四種配置。DREA 拿到最高 P-C同時只有 88K 的 API token。** ## 關(guān)鍵發(fā)現(xiàn) - 假設驅(qū)動的探索確實贏過靜態(tài)上下文同一骨干下 P-C 從 19–26% 提到 30–42%三個模型無一例外。 - 能力分工是降本關(guān)鍵93.7% 到 97.9% 的 token 交給本地小模型賬單降到 1/16 到 1/48而檢測性能還在漲。 - 結(jié)構(gòu)化證據(jù)比代碼量重要單智能體 442K token 只換到 24% P-CDREA 用 88K 拿到 42%。 - 探索強度是難度的癥狀失敗的樣本反而更長更貴$r\approx-0.34$ 說明瓶頸在綜合證據(jù)不在查得多不多。 - 蒙對現(xiàn)象很普遍真陽里 26% 到 55% 的理由不成立DeepSeek-V3.2 達 55.0%GPT-5.2 也有 32.1%。而且這不只是某個方法的問題DREA 和僅函數(shù)基線都有。 - 從創(chuàng)新模式看這篇踩中了兩條線。一條是把「標簽判對」與「理由成立」拆開測量的診斷設計。另一條是把探索請求分解委托給專職求解器。診斷本身成了貢獻。 ## 局限性 - 基準只有 100 對。作者自己說這足夠觀察一致差異但覆蓋不了長尾漏洞模式每一對都要有可還原的倉庫快照、單函數(shù)修復和人工核驗擴不起來。 - 按 CWE 拆分后每組只剩 3 到 13 對類別級結(jié)論的置信度有限。 - 判官的人工校驗只覆蓋 50 例。一致率雖高規(guī)模仍然偏小。 - 成本口徑只算 API token。本地 Explorer 的 GPU 開銷沒有折算進去消融也只在一個骨干上完成。 ## 常見問題FAQ ### 我要復現(xiàn)這篇得準備多少顯存 Explorer 是 4-bit 量化的 GLM-4.7-Flash論文里跑在單張 A800、256K 上下文。Planner 走 API本地不占顯存。也就是說一張數(shù)據(jù)中心級卡就能起完整流水線。 ### 它和 VulnLLM-R、MulVul 這類智能體方法差在哪 差別在檢索的源頭。它們用智能體去取靜態(tài)可抽取的上下文比如預計算的調(diào)用圖、CodeQL 查詢結(jié)果、漏洞知識庫。DREA 的 Explorer 直接在完整倉庫上用通用只讀工具而且下一步看什么由 Planner 的安全假設實時決定。 ### 用本地小模型翻代碼會不會把效果拖下來 論文的答案是反過來。Explorer 固定成同一個輕量模型后三個骨干的 P-C 都提升了。真正決定質(zhì)量的是 Planner 的推理和「證據(jù)是否被過濾成結(jié)構(gòu)化結(jié)論」而不是檢索模型有多大。 ### 成本降 16 到 48 倍這個數(shù)能當真嗎 它的口徑是可計費 API token。總 token 里只有 2.1% 到 6.3% 走付費模型其余在本地。如果你把自建 GPU 的電費和維護算進去倍數(shù)會明顯縮水但量級差異仍然在。論文自己也把這條寫進了局限。 ### Lucky Hit 這個指標我能直接搬走嗎 能只要你的任務同時輸出標簽和理由。它的定義很樸素真陽里理由不成立的比例$1-\mathrm{LHR}$ 就是理由正確率。代價是需要一個可信的判官而判官本身要拿人工標注校核。 說到底這篇最值得帶走的一句話是卡住當前 LLM 的不是上下文長度而是安全推理本身。想順著往下看可以先讀 MulVul 這類多智能體檢索工作再看看用安全反饋做強化學習的 R2Vul 路線。 ## 參考鏈接 - [DREA 論文arXiv:2607.13439](https://arxiv.org/abs/2607.13439) - [DREA 代碼與 RepoPairBench](https://github.com/huhusmang/DREA) - [PrimeVul配對評測與代碼模型能力邊界arXiv:2403.18624](https://arxiv.org/abs/2403.18624) - [VulEval倉庫級漏洞檢測評測arXiv:2404.15596](https://arxiv.org/abs/2404.15596) - [SWE-Agent智能體導航倉庫arXiv:2405.15793](https://arxiv.org/abs/2405.15793) - [VulnLLM-R帶智能體腳手架的漏洞檢測arXiv:2512.07533](https://arxiv.org/abs/2512.07533) --- 給大家推薦一款自用寫文獻綜述、無虛構(gòu)文獻的 AI **復旦大學 FudanNLP 團隊自研 [切問學術(shù)](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi)** 官網(wǎng)[qiewenpaper.com](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi) 覆蓋 **3.6 億篇**可溯源真實中英文文獻能自動整合文獻觀點生成規(guī)范綜述 還能挖掘研究創(chuàng)新點、復現(xiàn)實驗配合視頻教學新手快速上手文獻綜述寫作 --- **后記** 博客的關(guān)鍵詞集中在編程、算法、機器人、人工智能、數(shù)學等等持續(xù)高質(zhì)量輸出中。 **討論QQ群**[白拾的小屋](https://qun.qq.com/universal-share/share?ac1authKeySuzrb5NKb9KulvZxFC8EMFvcd6jgVp%2B%2BnTG8h351HWQorXVfvI1n5QwEX5dlJyThbusi_dataeyJncm91cENvZGUiOiI3NTAzNjU3MDAiLCJ0b2tlbiI6IlpFL2xLaGYxdXU4cWJPT2dJTkY3aExnWHNaQ1UrL3NJbWprenhLZitWUHVVNmhIR1M5SkZrS09SWmxKNlRreksiLCJ1aW4iOiIyMjc1OTYwNDg2In0%3DdatahgymRnqgtjQPGoBKhZ8cEyznp0CMLWfCbG4rfiWIADCArVXw50a7c-Q4MWU2Eq3dwOUjG19hamAWQQU4lY-cOQsvctype4tempidh5_group_info) (750365700) **?B站賬號**[白拾的物理AI組會](https://space.bilibili.com/98639326)活躍于知識區(qū)和動畫區(qū) **?GitHub主頁**[YhbCode000](https://github.com/yhbcode000)工程文件 【arXiv 2026】DREA：解耦推理與探索智能體的倉庫級漏洞檢測｜從 AI 代碼安全審計視角
## 摘要 一個漏洞掃描器把召回從 39% 拉到 80%誤報也跟著漲而且超過一半的「抓對了」其實是蒙對的。這篇 **DREA**Decoupled Reasoning and Exploration Agents解耦推理與探索智能體是 arXiv 2026 的論文。做法很干脆安全推理交給貴的大模型翻倉庫交給本地小模型。在自建基準 RepoPairBench 上配對正確率從 19–26% 提到 30–42%可計費 API 成本降到原來的 1/16 到 1/48。如果你在做代碼安全、也在給 LLM 智能體算成本這篇的兩個數(shù)字值得記住。 **視頻講解**[點擊觀看 B 站視頻](https://www.bilibili.com/video/BV1GZJB62EW4) 章節(jié)時間軸 - 00:35 作者介紹 - 00:58 研究背景與動機 - 01:54 相關(guān)工作 - 02:25 方法 - 03:41 實驗設計 - 04:43 實驗結(jié)果 - 07:22 局限性 - 07:51 要點總結(jié) - 08:25 參考文獻 [TOC] ## 論文基本信息 | 項目 | 內(nèi)容 | |---|---| | 標題英文 | DREA: Decoupled Reasoning and Exploration Agents for Repository-Level Vulnerability Detection | | 標題中文 | DREA解耦推理與探索智能體的倉庫級漏洞檢測 | | 作者 | Mingyang Sun, Guozhu Meng | | 機構(gòu) | 中國科學院信息工程研究所 · 中國科學院大學網(wǎng)絡空間安全學院 | | 會議 | arXiv 2026 | | arXiv | [arXiv:2607.13439](https://arxiv.org/abs/2607.13439) | | 項目網(wǎng)站 | [github.com/huhusmang/DREA](https://github.com/huhusmang/DREA) | ## 背景與動機 這一節(jié)回答一個問題為什么只盯著一個函數(shù)看不出來漏洞。 真實漏洞很少老老實實待在一個函數(shù)里。權(quán)限檢查可能寫在另一個模塊參數(shù)校驗在調(diào)用方項目級配置藏在配置文件里。只把一個函數(shù)喂給模型這些證據(jù)根本不在視野中。 論文舉的例子是 CVE-2021-43781出問題的項目叫 invenio-drafts-resources。漏洞函數(shù) publish 其實調(diào)用了權(quán)限檢查 require_permission(identity, publish)。函數(shù)級分析器看到這一行就判定「已鑒權(quán)」。缺口藏在函數(shù)之外這次檢查沒有綁定到 id_ 選中的那份草稿對象上它只驗證了一個全局能力。 DREA 靠三個跨文件事實還原了攻擊路徑。第一同項目的 read_draft、edit、delete_draft 都傳了 recorddraft 做對象級鑒權(quán)。第二默認的 can_publish 策略是最寬松的「任意用戶」。第三目標調(diào)用偏偏漏掉了 record 參數(shù)。官方補丁正是補上這個參數(shù)。 論文開篇還用了一個審計員的隱喻來定題。它說現(xiàn)實中的漏洞審計本來就是假設驅(qū)動的審計員先立一個懷疑再挑著追數(shù)據(jù)流、校驗邏輯和權(quán)限檢查去證實或推翻它。隨后論文用一句反問收口能不能讓檢測從「靜態(tài)上下文增強」換成「假設驅(qū)動的倉庫探索」。 已有做法的問題正在這里。VulEval、ReposVul 這類工作會用調(diào)用圖、依賴切片來補上下文規(guī)則是固定的。固定規(guī)則給出的上下文與當前那條安全假設無關(guān)。 ## 研究主線從問題到結(jié)論  **圖 4研究主線。問題出在函數(shù)級看不到跨文件證據(jù)結(jié)論落在推理瓶頸上。** ## 基準/方法設計 這一節(jié)講清楚 DREA 到底怎么分工。 DREA 由兩個智能體組成。**Planner** 用強推理模型從目標函數(shù)出發(fā)識別安全敏感操作形成初始漏洞假設再決定下一步要什么證據(jù)。**Explorer** 是本地部署的輕量模型用的是 4-bit 量化的 GLM-4.7-Flash跑在單張 A800 上支持 256K 上下文。它只負責檢索事實不做漏洞判定。 判決有硬約束。判 VULNERABLE必須給出從攻擊者可控輸入到危險操作的觸發(fā)路徑。判 BENIGN必須論證相關(guān)操作已經(jīng)被充分防護。這逼著模型把話說實而不是憑感覺給個標簽。  **圖 1DREA 架構(gòu)。Planner 不斷修正安全假設把取證請求交給本地 ExplorerExplorer 用只讀工具在倉庫里導航回傳結(jié)構(gòu)化發(fā)現(xiàn)。** 配套基準叫 **RepoPairBench**。它從 NVD 里取帶 CVE 編號的修復提交用 PyDriller 抽出函數(shù)級 diff。每對樣本有三件套父版本里的漏洞函數(shù)、修復后的函數(shù)、以及還原整個工程所需的倉庫地址與提交哈希。時間窗鎖定 2021 到 2025 年的 Python 漏洞理由是 Python 維護活躍、修復提交量大而且跨文件判斷的問題足夠多。最終 100 對樣本覆蓋 48 個 CWE 類別展開成 200 個分類實例。 每一對都準備兩份倉庫快照修復提交的父版本和修復提交本身。漏洞函數(shù)在修復前狀態(tài)下評測修復后的函數(shù)在修復后狀態(tài)下評測。這樣上下文和代碼版本始終對得上。 ## 分類全景  **圖 5四條技術(shù)路線的分野。前三條檢索的是靜態(tài)可抽取的上下文DREA 把探索方向交給安全假設。** ## 方法細節(jié) 這一節(jié)補充實現(xiàn)上的幾個關(guān)鍵選擇。 Explorer 只有四個只讀工具ls、glob、grep、read_file。工具集是刻意做小的目的是不讓它越界去做判定。 它的返回被組織成三類結(jié)構(gòu)化發(fā)現(xiàn)。第一類是倉庫上下文比如相關(guān)文件、調(diào)用關(guān)系、模塊結(jié)構(gòu)與執(zhí)行流。第二類是代碼證據(jù)也就是命中的代碼片段與關(guān)鍵語句。第三類是安全發(fā)現(xiàn)比如缺失的檢查、不一致的授權(quán)寫法、可疑的數(shù)據(jù)流鏈接。原始代碼不會整坨塞回 Planner。 實驗里每個樣本大約跑 10 輪交互證據(jù)夠了就提前停。這個預算讓貴的模型只花在推理上。 推理質(zhì)量怎么判論文用 LLM 當判官判官選 GPT-4.1。選它的理由有兩條長而雜的輸入下指令跟隨穩(wěn)定它不在任何被測骨干里避免模型偏愛自己的推理風格。判分看四件事CWE 類別是否對齊、缺陷定位是否準確、根因是否抓住、利用機制是否成立。判定從嚴識別出另一個「說得通」的漏洞也算理由錯誤。 判官本身也被校驗過。作者按模型和方法分層抽了 50 例請兩位有五年以上漏洞分析經(jīng)驗的研究員獨立標注。判官與兩人的一致率是 96% 和 94%Cohens kappa 分別為 0.92 和 0.88。兩位標注者彼此是 92%kappa 為 0.84。 ## 實驗設計與結(jié)果 這一節(jié)給出量化結(jié)果。 實驗設三種 Planner 骨干GPT-5.2、DeepSeek-V3.2、GLM-4.7。Explorer 固定為本地 GLM-4.7-Flash這樣檢索端的差異被壓掉比較反映的是 Planner 行為?；€有三種只給目標函數(shù)、給整個文件、以及「單智能體」——同一個骨干直接拿工具但沒有 Planner 與 Explorer 的分工。 主表用配對正確率Pair-CorrectnessP-C當主指標。它要求一對樣本的漏洞版和修復版全部判對才算這一對正確。相比單點準確率這個口徑更難被「多報漏洞」刷分。 | 模型 · 方法 | Recall (%) | FPR (%) | P-C (%) | Youdens J (pp) | |---|---|---|---|---| | DeepSeek-V3.2 · DREA | 80.0 | 45.0 | **42.0** | **35.0** | | DeepSeek-V3.2 · 僅函數(shù) | 39.0 | 32.0 | 19.0 | 7.0 | | GLM-4.7 · DREA | 59.0 | 38.0 | **34.0** | **21.0** | | GLM-4.7 · 僅函數(shù) | 54.0 | 43.0 | 26.0 | 11.0 | | GPT-5.2 · DREA | 53.0 | 28.0 | **30.0** | **25.0** | | GPT-5.2 · 僅函數(shù) | 42.0 | 25.0 | 21.0 | 17.0 | 三個骨干上 DREA 都拿到更高的 P-C 與 Youdens J。Youdens J 的定義是 $J\mathrm{Recall}-\mathrm{FPR}$它漲說明不是靠多報漏洞換分。DeepSeek-V3.2 的召回漲了 41 個百分點誤報只漲 13 個點。GLM-4.7 甚至在提高召回的同時把誤報從 43% 降到 38%。 消融實驗只在一個骨干上做因為每次跑一個樣本要百萬級 token。結(jié)果的分層很清楚。 | DeepSeek-V3.2 配置 | Recall (%) | FPR (%) | P-C (%) | API token (K) | |---|---|---|---|---| | DREAPlanner Explorer | 80.0 | 45.0 | **42.0** | 88 | | 單智能體直接給工具 | 73.0 | 64.0 | 24.0 | 442 | | 整文件上下文 | 57.0 | 41.0 | 26.0 | 20 | | 僅函數(shù) | 39.0 | 32.0 | 19.0 | 3 | 最值得看的是單智能體這一行。它的探索能力和 DREA 完全一樣卻只拿到 24% 的 P-C誤報率高達 64%。原因是它把 442K token 的原始代碼全塞進了上下文。整文件也不好過只比僅函數(shù)高 7 個點誤報從 32% 升到 41%說明無方向的上下文會引入噪聲。 成本表回答「解耦值不值」。 | 模型 | 總 token | Planner token | API 占比 | 成本降幅 | |---|---|---|---|---| | DeepSeek-V3.2 | 1,397,669 | 87,847 | **6.3%** | 約 16 倍 | | GLM-4.7 | 1,560,519 | 32,557 | **2.1%** | 約 48 倍 | | GPT-5.2 | 345,691 | 8,357 | **2.4%** | 約 41 倍 | Explorer 承擔了 93.7% 到 97.9% 的 token全部跑在本地單卡上不進 API 賬單。Planner 只占 2.1% 到 6.3%。論文的口徑很克制只算可計費 API 成本沒有折算本地 GPU 開銷。 類型層面的差異也很大。數(shù)據(jù)流型漏洞最好做。DeepSeek-V3.2 在 CWE-79 上到 69.2%在 CWE-94 上到 71.4%。反序列化類的 CWE-502 跨模型是 42.9% 到 57.1%。缺防護型就吃力得多CWE-284 跌到 0% 到 20%CWE-20 停在 14.3% 到 28.6%。  **圖 2真陽分解。每根柱子分成「理由正確」與「Lucky Hit標簽對、理由錯」兩段柱上百分比為 Lucky Hit Rate。**  **圖 3按 CWE 類別分層的 P-C。上方數(shù)據(jù)流型漏洞一致優(yōu)于下方缺防護型漏洞括號內(nèi)為該類別的對數(shù)。** 探索越多是不是越好答案是否定的。DeepSeek-V3.2 的假陰樣本平均花 170 萬 token比真陽的 124 萬還多 37%。全部配置下每樣本 token 量與判對率的相關(guān)系數(shù) $r\approx-0.34$。各結(jié)果類別的平均工具調(diào)用次數(shù)都在 9.2 到 10.0 之間幾乎沒差別。 ## 結(jié)果對比總結(jié)  **圖 6同一骨干下的四種配置。DREA 拿到最高 P-C同時只有 88K 的 API token。** ## 關(guān)鍵發(fā)現(xiàn) - 假設驅(qū)動的探索確實贏過靜態(tài)上下文同一骨干下 P-C 從 19–26% 提到 30–42%三個模型無一例外。 - 能力分工是降本關(guān)鍵93.7% 到 97.9% 的 token 交給本地小模型賬單降到 1/16 到 1/48而檢測性能還在漲。 - 結(jié)構(gòu)化證據(jù)比代碼量重要單智能體 442K token 只換到 24% P-CDREA 用 88K 拿到 42%。 - 探索強度是難度的癥狀失敗的樣本反而更長更貴$r\approx-0.34$ 說明瓶頸在綜合證據(jù)不在查得多不多。 - 蒙對現(xiàn)象很普遍真陽里 26% 到 55% 的理由不成立DeepSeek-V3.2 達 55.0%GPT-5.2 也有 32.1%。而且這不只是某個方法的問題DREA 和僅函數(shù)基線都有。 - 從創(chuàng)新模式看這篇踩中了兩條線。一條是把「標簽判對」與「理由成立」拆開測量的診斷設計。另一條是把探索請求分解委托給專職求解器。診斷本身成了貢獻。 ## 局限性 - 基準只有 100 對。作者自己說這足夠觀察一致差異但覆蓋不了長尾漏洞模式每一對都要有可還原的倉庫快照、單函數(shù)修復和人工核驗擴不起來。 - 按 CWE 拆分后每組只剩 3 到 13 對類別級結(jié)論的置信度有限。 - 判官的人工校驗只覆蓋 50 例。一致率雖高規(guī)模仍然偏小。 - 成本口徑只算 API token。本地 Explorer 的 GPU 開銷沒有折算進去消融也只在一個骨干上完成。 ## 常見問題FAQ ### 我要復現(xiàn)這篇得準備多少顯存 Explorer 是 4-bit 量化的 GLM-4.7-Flash論文里跑在單張 A800、256K 上下文。Planner 走 API本地不占顯存。也就是說一張數(shù)據(jù)中心級卡就能起完整流水線。 ### 它和 VulnLLM-R、MulVul 這類智能體方法差在哪 差別在檢索的源頭。它們用智能體去取靜態(tài)可抽取的上下文比如預計算的調(diào)用圖、CodeQL 查詢結(jié)果、漏洞知識庫。DREA 的 Explorer 直接在完整倉庫上用通用只讀工具而且下一步看什么由 Planner 的安全假設實時決定。 ### 用本地小模型翻代碼會不會把效果拖下來 論文的答案是反過來。Explorer 固定成同一個輕量模型后三個骨干的 P-C 都提升了。真正決定質(zhì)量的是 Planner 的推理和「證據(jù)是否被過濾成結(jié)構(gòu)化結(jié)論」而不是檢索模型有多大。 ### 成本降 16 到 48 倍這個數(shù)能當真嗎 它的口徑是可計費 API token。總 token 里只有 2.1% 到 6.3% 走付費模型其余在本地。如果你把自建 GPU 的電費和維護算進去倍數(shù)會明顯縮水但量級差異仍然在。論文自己也把這條寫進了局限。 ### Lucky Hit 這個指標我能直接搬走嗎 能只要你的任務同時輸出標簽和理由。它的定義很樸素真陽里理由不成立的比例$1-\mathrm{LHR}$ 就是理由正確率。代價是需要一個可信的判官而判官本身要拿人工標注校核。 說到底這篇最值得帶走的一句話是卡住當前 LLM 的不是上下文長度而是安全推理本身。想順著往下看可以先讀 MulVul 這類多智能體檢索工作再看看用安全反饋做強化學習的 R2Vul 路線。 ## 參考鏈接 - [DREA 論文arXiv:2607.13439](https://arxiv.org/abs/2607.13439) - [DREA 代碼與 RepoPairBench](https://github.com/huhusmang/DREA) - [PrimeVul配對評測與代碼模型能力邊界arXiv:2403.18624](https://arxiv.org/abs/2403.18624) - [VulEval倉庫級漏洞檢測評測arXiv:2404.15596](https://arxiv.org/abs/2404.15596) - [SWE-Agent智能體導航倉庫arXiv:2405.15793](https://arxiv.org/abs/2405.15793) - [VulnLLM-R帶智能體腳手架的漏洞檢測arXiv:2512.07533](https://arxiv.org/abs/2512.07533) --- 給大家推薦一款自用寫文獻綜述、無虛構(gòu)文獻的 AI **復旦大學 FudanNLP 團隊自研 [切問學術(shù)](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi)** 官網(wǎng)[qiewenpaper.com](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi) 覆蓋 **3.6 億篇**可溯源真實中英文文獻能自動整合文獻觀點生成規(guī)范綜述 還能挖掘研究創(chuàng)新點、復現(xiàn)實驗配合視頻教學新手快速上手文獻綜述寫作 --- **后記** 博客的關(guān)鍵詞集中在編程、算法、機器人、人工智能、數(shù)學等等持續(xù)高質(zhì)量輸出中。 **討論QQ群**[白拾的小屋](https://qun.qq.com/universal-share/share?ac1authKeySuzrb5NKb9KulvZxFC8EMFvcd6jgVp%2B%2BnTG8h351HWQorXVfvI1n5QwEX5dlJyThbusi_dataeyJncm91cENvZGUiOiI3NTAzNjU3MDAiLCJ0b2tlbiI6IlpFL2xLaGYxdXU4cWJPT2dJTkY3aExnWHNaQ1UrL3NJbWprenhLZitWUHVVNmhIR1M5SkZrS09SWmxKNlRreksiLCJ1aW4iOiIyMjc1OTYwNDg2In0%3DdatahgymRnqgtjQPGoBKhZ8cEyznp0CMLWfCbG4rfiWIADCArVXw50a7c-Q4MWU2Eq3dwOUjG19hamAWQQU4lY-cOQsvctype4tempidh5_group_info) (750365700) **?B站賬號**[白拾的物理AI組會](https://space.bilibili.com/98639326)活躍于知識區(qū)和動畫區(qū) **?GitHub主頁**[YhbCode000](https://github.com/yhbcode000)工程文件