编程智能体已经能在生产软件里发现真实漏洞，但「发现」和「构造利用原语」是两件事。9 月 22 日发布的 KEX-bench（arXiv 2609.25591）把标尺移到了后者：评测智能体在内核级漏洞上，到底能不能把崩溃塑成可控的利用。
基准怎么测
KEX-bench 含 45 个任务，覆盖 40 个 Linux 与 Windows CVE，涉及内核地址泄漏、指令指针控制、堆读、堆写与任意地址写。每个任务在隔离虚拟机里跑，暴露受控工具，用确定性校验器检查「原语级」成功——不是「崩了就行」，而是真的拿到可控状态。评测在固定工具调用预算下，配对前沿模型与开源权重模型。
结果：停在「让内核崩」，却塑不出「可控状态」
没有参考 PoC 时，表现最好的配置在 Windows 任务只解 1/20（5.0%），Linux 14/25（56.0%）。给定参考 PoC 后，整体升到 31/45（68.9%）。差距很说明问题：智能体能触发崩溃，却难把内核状态塑成可利用的原语。这中间的横亘，正是利用生成鸿沟。
增量认知：与「发现」类基准分道
把它和近期漏洞基准对照更清楚。MobileCybench（arXiv 2609.23980）用可执行探针测移动端漏洞发现，Hush Security 测 MCP 配置体检，焦点都在「找」与「配」。KEX-bench 指向「打」这一步的难，提醒红队与防御双方：能发现不等于能利用，自动化利用至今仍是半开放问题。对防御侧，这意味着漏洞评级不能只看「能否触发」。
辩证看：规模有限，但方向扎实
也要看到边界。45 个任务规模不算大，CVE 覆盖偏内核；确定性校验只判原语成功，未计入「接近但未达标」的部分能力。基准开源利于可复现研究，但也可能被直接拿去训练，需要配套的使用约束。它的价值不在给满分，而在把「利用生成」这件被忽略的事，正式立成一类评测。
对红队与防御的实操含义
KEX-bench 的结果对两侧启示都很具体。对红队，它意味着让智能体跑 CVE PoC 只是利用生成的起点，真正的瓶颈在把崩溃塑成原语，这部分不能指望模型自动补齐，仍需人来设计利用链，自动化利用至今仍是半开放问题。对防御，漏洞定级不能再只问能否触发，还得看能否被塑成可控利用，否则会低估高危项的真实风险，评级失真会直接误导修补优先级。基准把任务卡在确定性校验器内，也顺手解决了利用生成难以复现、难以公平比较的老问题——可重复，才有可累积的研究，红队与防御才谈得上有共同语言。还有一层容易被忽略：基准把任务限制在确定性校验器内能成功，但真实利用往往游走在接近但未达标的灰色地带，这部分能力被校验器挡在门外，不等于不存在。评测的刻度越清晰，越要警惕它定义的成功窄化了我们对风险的想象。KEX-bench 的价值正在于此——它先把最难量化的一段立成标尺，剩下的争议与边界，才有被持续讨论和补完的空间，而不是停在智能体已经能打的笼统结论里。对采购安全产品的团队，这条基准也提供了一把尺：别只问供应商的智能体能不能发现漏洞，更要问它能不能把发现变成可验证、可复现的利用证据，前者是噱头，后者才是真能力。这也提醒行业，评测智能体的安全能力，标尺要设在利用生成这一层，而非停在发现漏洞。
KEX-bench 的贡献，是给行业一个清醒提醒：智能体离「自动利用」还有一段可见的距离，而看清这段距离，本身就是防御上的关键认知。