## 摘要 一个漏洞扫描器把召回从 39% 拉到 80%误报也跟着涨而且超过一半的「抓对了」其实是蒙对的。这篇 **DREA**Decoupled Reasoning and Exploration Agents解耦推理与探索智能体是 arXiv 2026 的论文。做法很干脆安全推理交给贵的大模型翻仓库交给本地小模型。在自建基准 RepoPairBench 上配对正确率从 19–26% 提到 30–42%可计费 API 成本降到原来的 1/16 到 1/48。如果你在做代码安全、也在给 LLM 智能体算成本这篇的两个数字值得记住。 **视频讲解**[点击观看 B 站视频](https://www.bilibili.com/video/BV1GZJB62EW4) 章节时间轴 - 00:35 作者介绍 - 00:58 研究背景与动机 - 01:54 相关工作 - 02:25 方法 - 03:41 实验设计 - 04:43 实验结果 - 07:22 局限性 - 07:51 要点总结 - 08:25 参考文献 [TOC] ## 论文基本信息 | 项目 | 内容 | |---|---| | 标题英文 | DREA: Decoupled Reasoning and Exploration Agents for Repository-Level Vulnerability Detection | | 标题中文 | DREA解耦推理与探索智能体的仓库级漏洞检测 | | 作者 | Mingyang Sun, Guozhu Meng | | 机构 | 中国科学院信息工程研究所 · 中国科学院大学网络空间安全学院 | | 会议 | arXiv 2026 | | arXiv | [arXiv:2607.13439](https://arxiv.org/abs/2607.13439) | | 项目网站 | [github.com/huhusmang/DREA](https://github.com/huhusmang/DREA) | ## 背景与动机 这一节回答一个问题为什么只盯着一个函数看不出来漏洞。 真实漏洞很少老老实实待在一个函数里。权限检查可能写在另一个模块参数校验在调用方项目级配置藏在配置文件里。只把一个函数喂给模型这些证据根本不在视野中。 论文举的例子是 CVE-2021-43781出问题的项目叫 invenio-drafts-resources。漏洞函数 publish 其实调用了权限检查 require_permission(identity, publish)。函数级分析器看到这一行就判定「已鉴权」。缺口藏在函数之外这次检查没有绑定到 id_ 选中的那份草稿对象上它只验证了一个全局能力。 DREA 靠三个跨文件事实还原了攻击路径。第一同项目的 read_draft、edit、delete_draft 都传了 recorddraft 做对象级鉴权。第二默认的 can_publish 策略是最宽松的「任意用户」。第三目标调用偏偏漏掉了 record 参数。官方补丁正是补上这个参数。 论文开篇还用了一个审计员的隐喻来定题。它说现实中的漏洞审计本来就是假设驱动的审计员先立一个怀疑再挑着追数据流、校验逻辑和权限检查去证实或推翻它。随后论文用一句反问收口能不能让检测从「静态上下文增强」换成「假设驱动的仓库探索」。 已有做法的问题正在这里。VulEval、ReposVul 这类工作会用调用图、依赖切片来补上下文规则是固定的。固定规则给出的上下文与当前那条安全假设无关。 ## 研究主线从问题到结论  **图 4研究主线。问题出在函数级看不到跨文件证据结论落在推理瓶颈上。** ## 基准/方法设计 这一节讲清楚 DREA 到底怎么分工。 DREA 由两个智能体组成。**Planner** 用强推理模型从目标函数出发识别安全敏感操作形成初始漏洞假设再决定下一步要什么证据。**Explorer** 是本地部署的轻量模型用的是 4-bit 量化的 GLM-4.7-Flash跑在单张 A800 上支持 256K 上下文。它只负责检索事实不做漏洞判定。 判决有硬约束。判 VULNERABLE必须给出从攻击者可控输入到危险操作的触发路径。判 BENIGN必须论证相关操作已经被充分防护。这逼着模型把话说实而不是凭感觉给个标签。  **图 1DREA 架构。Planner 不断修正安全假设把取证请求交给本地 ExplorerExplorer 用只读工具在仓库里导航回传结构化发现。** 配套基准叫 **RepoPairBench**。它从 NVD 里取带 CVE 编号的修复提交用 PyDriller 抽出函数级 diff。每对样本有三件套父版本里的漏洞函数、修复后的函数、以及还原整个工程所需的仓库地址与提交哈希。时间窗锁定 2021 到 2025 年的 Python 漏洞理由是 Python 维护活跃、修复提交量大而且跨文件判断的问题足够多。最终 100 对样本覆盖 48 个 CWE 类别展开成 200 个分类实例。 每一对都准备两份仓库快照修复提交的父版本和修复提交本身。漏洞函数在修复前状态下评测修复后的函数在修复后状态下评测。这样上下文和代码版本始终对得上。 ## 分类全景  **图 5四条技术路线的分野。前三条检索的是静态可抽取的上下文DREA 把探索方向交给安全假设。** ## 方法细节 这一节补充实现上的几个关键选择。 Explorer 只有四个只读工具ls、glob、grep、read_file。工具集是刻意做小的目的是不让它越界去做判定。 它的返回被组织成三类结构化发现。第一类是仓库上下文比如相关文件、调用关系、模块结构与执行流。第二类是代码证据也就是命中的代码片段与关键语句。第三类是安全发现比如缺失的检查、不一致的授权写法、可疑的数据流链接。原始代码不会整坨塞回 Planner。 实验里每个样本大约跑 10 轮交互证据够了就提前停。这个预算让贵的模型只花在推理上。 推理质量怎么判论文用 LLM 当判官判官选 GPT-4.1。选它的理由有两条长而杂的输入下指令跟随稳定它不在任何被测骨干里避免模型偏爱自己的推理风格。判分看四件事CWE 类别是否对齐、缺陷定位是否准确、根因是否抓住、利用机制是否成立。判定从严识别出另一个「说得通」的漏洞也算理由错误。 判官本身也被校验过。作者按模型和方法分层抽了 50 例请两位有五年以上漏洞分析经验的研究员独立标注。判官与两人的一致率是 96% 和 94%Cohens kappa 分别为 0.92 和 0.88。两位标注者彼此是 92%kappa 为 0.84。 ## 实验设计与结果 这一节给出量化结果。 实验设三种 Planner 骨干GPT-5.2、DeepSeek-V3.2、GLM-4.7。Explorer 固定为本地 GLM-4.7-Flash这样检索端的差异被压掉比较反映的是 Planner 行为。基线有三种只给目标函数、给整个文件、以及「单智能体」——同一个骨干直接拿工具但没有 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 · 仅函数 | 39.0 | 32.0 | 19.0 | 7.0 | | GLM-4.7 · DREA | 59.0 | 38.0 | **34.0** | **21.0** | | GLM-4.7 · 仅函数 | 54.0 | 43.0 | 26.0 | 11.0 | | GPT-5.2 · DREA | 53.0 | 28.0 | **30.0** | **25.0** | | GPT-5.2 · 仅函数 | 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。结果的分层很清楚。 | 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 | | 仅函数 | 39.0 | 32.0 | 19.0 | 3 | 最值得看的是单智能体这一行。它的探索能力和 DREA 完全一样却只拿到 24% 的 P-C误报率高达 64%。原因是它把 442K token 的原始代码全塞进了上下文。整文件也不好过只比仅函数高 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 开销。 类型层面的差异也很大。数据流型漏洞最好做。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。上方数据流型漏洞一致优于下方缺防护型漏洞括号内为该类别的对数。** 探索越多是不是越好答案是否定的。DeepSeek-V3.2 的假阴样本平均花 170 万 token比真阳的 124 万还多 37%。全部配置下每样本 token 量与判对率的相关系数 $r\approx-0.34$。各结果类别的平均工具调用次数都在 9.2 到 10.0 之间几乎没差别。 ## 结果对比总结  **图 6同一骨干下的四种配置。DREA 拿到最高 P-C同时只有 88K 的 API token。** ## 关键发现 - 假设驱动的探索确实赢过静态上下文同一骨干下 P-C 从 19–26% 提到 30–42%三个模型无一例外。 - 能力分工是降本关键93.7% 到 97.9% 的 token 交给本地小模型账单降到 1/16 到 1/48而检测性能还在涨。 - 结构化证据比代码量重要单智能体 442K token 只换到 24% P-CDREA 用 88K 拿到 42%。 - 探索强度是难度的症状失败的样本反而更长更贵$r\approx-0.34$ 说明瓶颈在综合证据不在查得多不多。 - 蒙对现象很普遍真阳里 26% 到 55% 的理由不成立DeepSeek-V3.2 达 55.0%GPT-5.2 也有 32.1%。而且这不只是某个方法的问题DREA 和仅函数基线都有。 - 从创新模式看这篇踩中了两条线。一条是把「标签判对」与「理由成立」拆开测量的诊断设计。另一条是把探索请求分解委托给专职求解器。诊断本身成了贡献。 ## 局限性 - 基准只有 100 对。作者自己说这足够观察一致差异但覆盖不了长尾漏洞模式每一对都要有可还原的仓库快照、单函数修复和人工核验扩不起来。 - 按 CWE 拆分后每组只剩 3 到 13 对类别级结论的置信度有限。 - 判官的人工校验只覆盖 50 例。一致率虽高规模仍然偏小。 - 成本口径只算 API token。本地 Explorer 的 GPU 开销没有折算进去消融也只在一个骨干上完成。 ## 常见问题FAQ ### 我要复现这篇得准备多少显存 Explorer 是 4-bit 量化的 GLM-4.7-Flash论文里跑在单张 A800、256K 上下文。Planner 走 API本地不占显存。也就是说一张数据中心级卡就能起完整流水线。 ### 它和 VulnLLM-R、MulVul 这类智能体方法差在哪 差别在检索的源头。它们用智能体去取静态可抽取的上下文比如预计算的调用图、CodeQL 查询结果、漏洞知识库。DREA 的 Explorer 直接在完整仓库上用通用只读工具而且下一步看什么由 Planner 的安全假设实时决定。 ### 用本地小模型翻代码会不会把效果拖下来 论文的答案是反过来。Explorer 固定成同一个轻量模型后三个骨干的 P-C 都提升了。真正决定质量的是 Planner 的推理和「证据是否被过滤成结构化结论」而不是检索模型有多大。 ### 成本降 16 到 48 倍这个数能当真吗 它的口径是可计费 API token。总 token 里只有 2.1% 到 6.3% 走付费模型其余在本地。如果你把自建 GPU 的电费和维护算进去倍数会明显缩水但量级差异仍然在。论文自己也把这条写进了局限。 ### 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) --- 给大家推荐一款自用写文献综述、无虚构文献的 AI **复旦大学 FudanNLP 团队自研 [切问学术](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi)** 官网[qiewenpaper.com](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi) 覆盖 **3.6 亿篇**可溯源真实中英文文献能自动整合文献观点生成规范综述 还能挖掘研究创新点、复现实验配合视频教学新手快速上手文献综述写作 --- **后记** 博客的关键词集中在编程、算法、机器人、人工智能、数学等等持续高质量输出中。 **讨论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)活跃于知识区和动画区 **✨GitHub主页**[YhbCode000](https://github.com/yhbcode000)工程文件
## 摘要 一个漏洞扫描器把召回从 39% 拉到 80%误报也跟着涨而且超过一半的「抓对了」其实是蒙对的。这篇 **DREA**Decoupled Reasoning and Exploration Agents解耦推理与探索智能体是 arXiv 2026 的论文。做法很干脆安全推理交给贵的大模型翻仓库交给本地小模型。在自建基准 RepoPairBench 上配对正确率从 19–26% 提到 30–42%可计费 API 成本降到原来的 1/16 到 1/48。如果你在做代码安全、也在给 LLM 智能体算成本这篇的两个数字值得记住。 **视频讲解**[点击观看 B 站视频](https://www.bilibili.com/video/BV1GZJB62EW4) 章节时间轴 - 00:35 作者介绍 - 00:58 研究背景与动机 - 01:54 相关工作 - 02:25 方法 - 03:41 实验设计 - 04:43 实验结果 - 07:22 局限性 - 07:51 要点总结 - 08:25 参考文献 [TOC] ## 论文基本信息 | 项目 | 内容 | |---|---| | 标题英文 | DREA: Decoupled Reasoning and Exploration Agents for Repository-Level Vulnerability Detection | | 标题中文 | DREA解耦推理与探索智能体的仓库级漏洞检测 | | 作者 | Mingyang Sun, Guozhu Meng | | 机构 | 中国科学院信息工程研究所 · 中国科学院大学网络空间安全学院 | | 会议 | arXiv 2026 | | arXiv | [arXiv:2607.13439](https://arxiv.org/abs/2607.13439) | | 项目网站 | [github.com/huhusmang/DREA](https://github.com/huhusmang/DREA) | ## 背景与动机 这一节回答一个问题为什么只盯着一个函数看不出来漏洞。 真实漏洞很少老老实实待在一个函数里。权限检查可能写在另一个模块参数校验在调用方项目级配置藏在配置文件里。只把一个函数喂给模型这些证据根本不在视野中。 论文举的例子是 CVE-2021-43781出问题的项目叫 invenio-drafts-resources。漏洞函数 publish 其实调用了权限检查 require_permission(identity, publish)。函数级分析器看到这一行就判定「已鉴权」。缺口藏在函数之外这次检查没有绑定到 id_ 选中的那份草稿对象上它只验证了一个全局能力。 DREA 靠三个跨文件事实还原了攻击路径。第一同项目的 read_draft、edit、delete_draft 都传了 recorddraft 做对象级鉴权。第二默认的 can_publish 策略是最宽松的「任意用户」。第三目标调用偏偏漏掉了 record 参数。官方补丁正是补上这个参数。 论文开篇还用了一个审计员的隐喻来定题。它说现实中的漏洞审计本来就是假设驱动的审计员先立一个怀疑再挑着追数据流、校验逻辑和权限检查去证实或推翻它。随后论文用一句反问收口能不能让检测从「静态上下文增强」换成「假设驱动的仓库探索」。 已有做法的问题正在这里。VulEval、ReposVul 这类工作会用调用图、依赖切片来补上下文规则是固定的。固定规则给出的上下文与当前那条安全假设无关。 ## 研究主线从问题到结论  **图 4研究主线。问题出在函数级看不到跨文件证据结论落在推理瓶颈上。** ## 基准/方法设计 这一节讲清楚 DREA 到底怎么分工。 DREA 由两个智能体组成。**Planner** 用强推理模型从目标函数出发识别安全敏感操作形成初始漏洞假设再决定下一步要什么证据。**Explorer** 是本地部署的轻量模型用的是 4-bit 量化的 GLM-4.7-Flash跑在单张 A800 上支持 256K 上下文。它只负责检索事实不做漏洞判定。 判决有硬约束。判 VULNERABLE必须给出从攻击者可控输入到危险操作的触发路径。判 BENIGN必须论证相关操作已经被充分防护。这逼着模型把话说实而不是凭感觉给个标签。  **图 1DREA 架构。Planner 不断修正安全假设把取证请求交给本地 ExplorerExplorer 用只读工具在仓库里导航回传结构化发现。** 配套基准叫 **RepoPairBench**。它从 NVD 里取带 CVE 编号的修复提交用 PyDriller 抽出函数级 diff。每对样本有三件套父版本里的漏洞函数、修复后的函数、以及还原整个工程所需的仓库地址与提交哈希。时间窗锁定 2021 到 2025 年的 Python 漏洞理由是 Python 维护活跃、修复提交量大而且跨文件判断的问题足够多。最终 100 对样本覆盖 48 个 CWE 类别展开成 200 个分类实例。 每一对都准备两份仓库快照修复提交的父版本和修复提交本身。漏洞函数在修复前状态下评测修复后的函数在修复后状态下评测。这样上下文和代码版本始终对得上。 ## 分类全景  **图 5四条技术路线的分野。前三条检索的是静态可抽取的上下文DREA 把探索方向交给安全假设。** ## 方法细节 这一节补充实现上的几个关键选择。 Explorer 只有四个只读工具ls、glob、grep、read_file。工具集是刻意做小的目的是不让它越界去做判定。 它的返回被组织成三类结构化发现。第一类是仓库上下文比如相关文件、调用关系、模块结构与执行流。第二类是代码证据也就是命中的代码片段与关键语句。第三类是安全发现比如缺失的检查、不一致的授权写法、可疑的数据流链接。原始代码不会整坨塞回 Planner。 实验里每个样本大约跑 10 轮交互证据够了就提前停。这个预算让贵的模型只花在推理上。 推理质量怎么判论文用 LLM 当判官判官选 GPT-4.1。选它的理由有两条长而杂的输入下指令跟随稳定它不在任何被测骨干里避免模型偏爱自己的推理风格。判分看四件事CWE 类别是否对齐、缺陷定位是否准确、根因是否抓住、利用机制是否成立。判定从严识别出另一个「说得通」的漏洞也算理由错误。 判官本身也被校验过。作者按模型和方法分层抽了 50 例请两位有五年以上漏洞分析经验的研究员独立标注。判官与两人的一致率是 96% 和 94%Cohens kappa 分别为 0.92 和 0.88。两位标注者彼此是 92%kappa 为 0.84。 ## 实验设计与结果 这一节给出量化结果。 实验设三种 Planner 骨干GPT-5.2、DeepSeek-V3.2、GLM-4.7。Explorer 固定为本地 GLM-4.7-Flash这样检索端的差异被压掉比较反映的是 Planner 行为。基线有三种只给目标函数、给整个文件、以及「单智能体」——同一个骨干直接拿工具但没有 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 · 仅函数 | 39.0 | 32.0 | 19.0 | 7.0 | | GLM-4.7 · DREA | 59.0 | 38.0 | **34.0** | **21.0** | | GLM-4.7 · 仅函数 | 54.0 | 43.0 | 26.0 | 11.0 | | GPT-5.2 · DREA | 53.0 | 28.0 | **30.0** | **25.0** | | GPT-5.2 · 仅函数 | 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。结果的分层很清楚。 | 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 | | 仅函数 | 39.0 | 32.0 | 19.0 | 3 | 最值得看的是单智能体这一行。它的探索能力和 DREA 完全一样却只拿到 24% 的 P-C误报率高达 64%。原因是它把 442K token 的原始代码全塞进了上下文。整文件也不好过只比仅函数高 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 开销。 类型层面的差异也很大。数据流型漏洞最好做。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。上方数据流型漏洞一致优于下方缺防护型漏洞括号内为该类别的对数。** 探索越多是不是越好答案是否定的。DeepSeek-V3.2 的假阴样本平均花 170 万 token比真阳的 124 万还多 37%。全部配置下每样本 token 量与判对率的相关系数 $r\approx-0.34$。各结果类别的平均工具调用次数都在 9.2 到 10.0 之间几乎没差别。 ## 结果对比总结  **图 6同一骨干下的四种配置。DREA 拿到最高 P-C同时只有 88K 的 API token。** ## 关键发现 - 假设驱动的探索确实赢过静态上下文同一骨干下 P-C 从 19–26% 提到 30–42%三个模型无一例外。 - 能力分工是降本关键93.7% 到 97.9% 的 token 交给本地小模型账单降到 1/16 到 1/48而检测性能还在涨。 - 结构化证据比代码量重要单智能体 442K token 只换到 24% P-CDREA 用 88K 拿到 42%。 - 探索强度是难度的症状失败的样本反而更长更贵$r\approx-0.34$ 说明瓶颈在综合证据不在查得多不多。 - 蒙对现象很普遍真阳里 26% 到 55% 的理由不成立DeepSeek-V3.2 达 55.0%GPT-5.2 也有 32.1%。而且这不只是某个方法的问题DREA 和仅函数基线都有。 - 从创新模式看这篇踩中了两条线。一条是把「标签判对」与「理由成立」拆开测量的诊断设计。另一条是把探索请求分解委托给专职求解器。诊断本身成了贡献。 ## 局限性 - 基准只有 100 对。作者自己说这足够观察一致差异但覆盖不了长尾漏洞模式每一对都要有可还原的仓库快照、单函数修复和人工核验扩不起来。 - 按 CWE 拆分后每组只剩 3 到 13 对类别级结论的置信度有限。 - 判官的人工校验只覆盖 50 例。一致率虽高规模仍然偏小。 - 成本口径只算 API token。本地 Explorer 的 GPU 开销没有折算进去消融也只在一个骨干上完成。 ## 常见问题FAQ ### 我要复现这篇得准备多少显存 Explorer 是 4-bit 量化的 GLM-4.7-Flash论文里跑在单张 A800、256K 上下文。Planner 走 API本地不占显存。也就是说一张数据中心级卡就能起完整流水线。 ### 它和 VulnLLM-R、MulVul 这类智能体方法差在哪 差别在检索的源头。它们用智能体去取静态可抽取的上下文比如预计算的调用图、CodeQL 查询结果、漏洞知识库。DREA 的 Explorer 直接在完整仓库上用通用只读工具而且下一步看什么由 Planner 的安全假设实时决定。 ### 用本地小模型翻代码会不会把效果拖下来 论文的答案是反过来。Explorer 固定成同一个轻量模型后三个骨干的 P-C 都提升了。真正决定质量的是 Planner 的推理和「证据是否被过滤成结构化结论」而不是检索模型有多大。 ### 成本降 16 到 48 倍这个数能当真吗 它的口径是可计费 API token。总 token 里只有 2.1% 到 6.3% 走付费模型其余在本地。如果你把自建 GPU 的电费和维护算进去倍数会明显缩水但量级差异仍然在。论文自己也把这条写进了局限。 ### 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) --- 给大家推荐一款自用写文献综述、无虚构文献的 AI **复旦大学 FudanNLP 团队自研 [切问学术](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi)** 官网[qiewenpaper.com](https://qiewenpaper.com/zh?utm_sourcebzkolutm_contentbaishi) 覆盖 **3.6 亿篇**可溯源真实中英文文献能自动整合文献观点生成规范综述 还能挖掘研究创新点、复现实验配合视频教学新手快速上手文献综述写作 --- **后记** 博客的关键词集中在编程、算法、机器人、人工智能、数学等等持续高质量输出中。 **讨论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)活跃于知识区和动画区 **✨GitHub主页**[YhbCode000](https://github.com/yhbcode000)工程文件
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
