该论文研究一个面向 LLM 驱动攻击性安全代理（offensive-security agent）的工程问题：在代理流水线中加入"验证器—接受阶段"（verifier-and-acceptance stage），即由一个模型充当验证器给出判定、再由确定性代码强制执行该判定，是否会改变代理最终报告的漏洞发现。作者采用预注册（pre-registered）的实验范式，分三步开展：第一步是 15 次运行的探索性试点；第二步是预注册的 20 次运行确认性消融实验（confirmatory ablation）；第三步是预注册的 2×2 因子研究，在两个刻意配置为易受攻击的实验室靶标上共进行 40 次运行。 确认性实验的核心结果是：将验证器—接受阶段移除后，"报告前抑制"（pre-report suppression）现象消失，每次运行的中位发现数从 2 降至 0，单侧精确检验 p = 0.00003；同时，在模型盲审（model-blinded）条件下最终"发货"的精度从 0.471 降至 0.353，p = 0.0087。但对一份冻结但不完整的 ground-truth 列表的召回率没有显著差异（双侧 p = 0.158），且研究未建立等效性，作者也强调该召回端点证据不充分。 因子研究进一步做归因分解：抑制作用主要来自模型验证器本身（Holm 校正后 p = 0.004）；仅靠确定性接受规则并未抑制任何误报；两者之间未检测到交互作用（p = 0.72）。完整设计保留了 93.8% 的经模型裁定的真实候选，但未达到预先注册的非劣效性标准——单侧 95% 置信下界为 0.875，低于 0.90 的门槛，因此不能宣称"不劣于"无验证器配置。 在安全与审计方面，作者在两个研究中部署了带埋点的金丝雀（instrumented canary），在 60/60 次运行中记录到零次接触，偶发的外部接触单独披露。对保留的盲审数据包的人工独立裁定仍在进行中，因此精度与灵敏度端点目前只是支持性证据而非最终结论。作者还主动披露了六处审计追踪失败，其中一处发生在评估工具自身。论文的结论刻意收窄：验证器改变的是"系统最终交付什么"，确定性代码提供的是强制执行与可审计性；该结果并未证明其优于其他代理，也未证明可推广到实验室靶标之外。 论文适合关注 LLM 代理安全评估方法学、代理流水线治理与可审计性设计的研究者与安全工程师阅读，尤其适合负责设计"模型输出—代码执行"门控与审计链路的团队。