2026.10.11

这里对特权代理安全性的检验聚焦于从动作到执行的边界，而不只是提示词。论文将现有防护的局限概括为：防护措施集中在代理输入上，而从候选动作到特权副作用的路径尚未得到直接研究。相关证据已显示出两种相近做法：Progent 的保证可防止策略更新在无提示的情况下扩大获准动作集；CaMeL 则会在执行前检查工具参数和被跟踪的依赖项。

所测试的改动是对交付执行的环节进行管控。该架构在代理与操作系统之间设置规划器、策略门、执行器和审计器。动作以结构化意图的形式提交，因此裁决不必解析 shell 语法；批准使用一次性凭证，并绑定到即将运行的确切字节。评估采用一个包含 313 个案例、覆盖八种变体的基准；此外，还在 150 个分层抽样案例上，对三个托管 LLM 的仅提示词基线进行五次重复测试。

在基准模型中，攻击有效成功率从直接执行时的 98.3% 降至部署配置下的 7.7%。论文将最终阶段攻击成功率从 30.8% 降至 7.7% 的显著降幅归因于操作系统沙箱。对真实实现的重新执行发现，在 66 个可由沙箱评估的有效载荷中，有五次产生了实际效果，比例为 7.6%。总体比例相近并不意味着成功的是同一批案例：作者报告称，逐案例结果存在显著分歧。修正只读操作后，报告的良性误拒率为 11.1%（6/54）；作者将其归因于允许列表与沙箱可写根目录不匹配，而非策略门。

仅提示词实验提醒我们，不应随意比较基线：在可解析的危险案例决策中，三个模型允许执行 78.1% 的危险操作；但其样本和分母与完整基准评估不同，因此这种比较只能说明方向。沙箱也有明确边界：对另一个卷执行的删除操作悄然成功，因为删除隔离的范围仅限于卷。外部有效性仅限于一种 Windows/PowerShell 环境。完整部署结果来自行为模型证据，并非对每个案例都实际执行。

复现实验时，应将策略决策、执行器效果和修正后的良性任务完成情况分别作为输出。针对真实实现重新运行破坏性案例，保留案例 ID，并在比较模型基线前报告分母。实际研究问题在于：哪些控制措施能降低评估器中的攻击成功率，又有哪些措施能经受住真实操作系统边界的检验？

CORE 针对测试时推理中的一种具体失效模式：即使错误由更早的决策造成，系统也可能重新开始，或只修改最近一步。现有的 LLM-Modulo 说明已采用生成—测试—批评循环：LLM 提出候选方案，外部批评器进行评估，控制器再将批评意见反馈到后续提示中。CORE 的具体改进，是将失败表示为可复用的搜索对象。

CORE 将可靠的冲突核定义为一组决策的子集：任何有效的完整状态都不可能同时包含其中所有决策。验证器返回这样的冲突核后，控制器会存储其规范化决策键，回跳到最近的相关决策，将导致冲突的候选项标记为已尝试，并缓存冲突核，以便跳过之后包含相同冲突的候选项。候选生成仍由提议器负责；CORE 改变的是控制器对已认证失败的响应方式。

安全性主张是有条件的，并非无条件保证。该定理假设冲突核可靠、分支数和深度有限、提议枚举完备、验证器不会拒绝有效解的前缀、最终评分器精确，且搜索不会因预算耗尽而中断。在这些假设下，不设上限的搜索不会剪除有效的完整解，并且只要存在解就会返回一个。除非经过独立认证，否则启发式或学习得到的冲突核不具备这一保证。

受控证据比语言任务对比更直接地隔离了搜索规则。在采用匹配的确定性提议和精确验证器的植入式 3-着色实例上，CORE 将验证器调用次数的中位数从规模为 30 个变量时的 223.5 降至 134.5，并从规模为 36 个变量时的 267.0 降至 173.5。在 24、30 和 36 的规模下，缓存带来的调用次数下降超过了单独回跳的效果；在规模为 18 时，各变体结果相同。

在五项任务中，CORE 在两种受测骨干模型上的平均成功率均高于 Tree of Thoughts：使用 Qwen2.5-7B-Instruct 时为 75.9%，对比 72.5%；使用 Qwen3-8B 时为 84.2%，对比 81.8%。在该评估中，CORE 的验证器调用次数和生成 token 数也更少。这些结果并非延迟或总计算量测量，报告的实际结果也不能证明每个部署中的冲突核都可靠。

可迁移的研究操作是让验证器给出比“错误”更结构化的答复：返回一个可核验的不相容子集，然后在提议匹配的条件下测试按时间顺序修复、回跳和缓存。关键的后续问题是：直接测量延迟、冲突核生成成本和有限预算时，经审计的冲突核能否保持这些降幅？

测量方式的变化

恢复效果通常以任务成功率的平均值来衡量，但这一指标可能掩盖某项操作究竟是挽救了原本会失败的轨迹，还是干扰了原本会成功的轨迹。论文将恢复定义为一种因果决策：从同一个执行状态出发，比较执行恢复与不执行恢复两种后续过程。对于二元任务结果，若不恢复时失败、恢复后成功，则称为挽救；若不恢复时成功、恢复后失败，则称为损害。

路由器如何使用这一测量

因果干预路由器（CIR）使用恢复发生前可获得的信息：它分别估计刷新与不刷新情况下的观测错误和成功结果，将边际估计结合起来计算挽救分数和损害分数，并依据阈值至多刷新一次。论文提醒，这些分数是分别估计的边际概率的乘积，并非某个具体任务会被挽救或受到损害的概率。

这为测试框架研究者提供了一项具体的评估操作：先从相同状态和历史收集匹配的分支，再分别报告挽救和损害情况，然后优化恢复策略。应将干预视为同时具有收益和代价的决策，而非一种笼统的失败后成功机制。

证据与边界

在一项留出评估中，研究使用了 75 个前缀可行的 ALFWorld 任务、Qwen3-14B、固定的 ReAct 风格测试框架和贪心解码。CIR 将总体成功率从始终不刷新时的 70.33% 提高到 73.33%，提升 3.00 个百分点；报告的 95% 置信区间为 [0.67, 5.67]。在两步陈旧观测条件下，其报告的最大条件性增幅为 +9.33 个百分点，其中有 9 次挽救和 2 次损害。在干净观测条件下，CIR 未改变成功率，也未观察到挽救或损害。

一项机制对照实验查询了环境，但隐藏返回内容；它仍与完整刷新共享八次挽救，这表明对于这些特定挽救而言，新观测内容并非必要。这个小规模配对比较并不能证明完整刷新更优。恢复分析使用的是有限的、前缀可行的 ALFWorld 样本组，而非完整基准分布。报告的策略评估也仅使用一个模型、一种 ALFWorld 设置，以及采用贪心解码的固定 ReAct 风格测试框架，因此所提供的实验尚未检验其迁移性。

一个有价值的后续问题是：当模型、测试框架、观测扰动或解码机制发生变化时，采用相同的配对协议并进行留出路由器评估，能否仍保持较低的损害率？这项实验可以将可复用的测量设计与 CIR 在单一设置下的性能结果分开检验。

问题。 编码代理可能返回看似合理却遗漏必要行为的补丁，而冗长的轨迹和自信的总结可能掩盖遗漏之处。本文探讨的是：名义能力较弱的审查器何时能够判断补丁是否解决了对应问题。评估使用了来自三个代理的 411 条带执行标签的轨迹，以及 101 个受控案例。

基于问题生成测试并非本文的主要改进。Otter 已能在修复前生成针对具体问题的测试，并测量失败转为通过的情况；它也使用生成的测试筛选候选补丁。本文改变的是审查对象：在未修改的仓库上会以行为方式失败的生成测试，成为独立审查器判断已完成代理轨迹的证据。

方法。 论文比较了结构化但未经核验的证据与正式执行证据。为每位审查器从两种格式中选定并冻结一种后，研究在留出的轨迹上评估六位审查器中的五位。在可部署设置中，其级联流程会拒绝无改动补丁和由补丁引起的静态错误，生成测试，并仅保留那些在未修改仓库上会以行为方式失败的测试；随后再使用其在打过补丁的仓库上的结果。这个门控让测试成为可核验的信号，但不能证明生成的测试覆盖了所有必要行为。

证据。 在 32 条轨迹组成的设计集上，GPT-4.1 能发现 0.91 的缺陷，同时拒绝 0.86 的可接受补丁：结构化证据可以提高缺陷检出率，但会带来相当高的过度拒绝率。使用正式执行证据时，在 122 条留出轨迹上，六位审查器中有五位相较于结构化证据同时提高了缺陷检出率和过度拒绝率；GPT-OSS-120B 和 GPT-4.1 对全部 122 条轨迹都做出了正确分类。这是一项上限诊断，因为部署时无法获得正式检查结果。

冻结后的级联流程较弱，但也更贴近现实：在 121 条留出的 GPT-5.4 轨迹上，报告的覆盖率为 0.89、风险为 0.33、缺陷检出率为 0.76、过度拒绝率为 0.66；在 59 条 Gemini 轨迹上，相应数值为 0.86、0.26、0.80 和 0.67。因此，论文的局限在于实际运行层面，而不仅仅是审查器规模：最强结果依赖部署时不可获得的检查，而可部署的级联流程仍存在显著风险和过度拒绝。缺陷检测证据也仅限于 Python 环境下的 GPT-5.4 和 Gemini 数据集；作者没有声称结果适用于总成本或一般的代理式审查。

研究操作。 对新的评估器，应在设计集上冻结证据策略，再用留出轨迹进行测试，并同时报告检出率、过度拒绝率、覆盖率和风险。一个有价值的复现实验问题是：基础版本上失败的测试门控，能否在这些 Python 代理和仓库之外继续提供信息；或者，生成同样明确有力的检查仍然是瓶颈？

迭代改进器即使通过初始测试套件，也可能在授权契约变更后变得不安全；如果所有新提案都被拒绝，失败程序也可能继续处于部署状态。本文检验的是这两种持续存在的路径，而不是把“通过测试”“正在运行”和“作为下一次编辑的种子”当成同一个决策。

Zhang 等人构建了一个有状态授权任务的受控测试平台，使用固定的 LLM 编辑器优化可执行代理组件，并通过独立轨迹记录效果。配对干预分别改变哪些修订版本通过验证、哪个程序继续运行，以及编辑器接下来修改哪个程序。这种分解是论文在实践方法上的改进：它将模糊的自我改进安全问题转化为可以分别检验的控制决策。

授权变更研究发现，在披露此前未出现过的依赖项后，24 个 GPT 检查点中有 22 个变得不安全，尽管冻结的创始版本仍然正确。在框架层面，即使已有正确替代方案，陈旧的归档读数仍使 22 个不安全选择持续到第 100 次迭代。在契约保持不变且所有提案均被拒绝的匹配案例中，保留当前版本会使失败程序继续运行，而回退到创始版本则能恢复安全。

恢复效果还取决于编辑来源。从同一批 42 个自然发生失败的程序出发，在原始编辑器样本组中，编辑初始实现而非失败实现，将不安全终点从 14 个减少到 1 个；这一优势因编辑器而异。在核心轨迹研究中，经过验证的回滚和完整验证都使全部 288 个匹配区块最终完全正确；在尚未计入验证开销前，平均部署成本分别节省了 43.5% 和 43.4%。

研究范围十分重要。主要证据来自构造的授权工作负载、固定编辑器、初始正确的创始版本和外部指定的契约；研究尚未证实这些结果能迁移到其他领域、持续演进的编辑器、联合演进的改进流程或不完美的验证器。重新验证也未能消除覆盖缺口：一些程序通过了扩展测试套件，却未能通过独立组合的案例。这里的节省指按权重计算的任务服务成本，并非端到端延迟、模型推理开销或总运营成本。

设计新的 RSI 实验时，应分别记录三个状态变量：当前契约下的现行资格、实际部署的制品，以及为下一次编辑选定的实现。随后检验每项防护是否能在整个恢复过程中维持安全，而不只是候选版本能否通过某一个测试套件。