「AI 可能不想被关掉」是安全研究里最古老的直觉之一，Asimov 时代的思想实验、现代的智能体逃逸案例都指向同一件事。但真正动手测过的团队都知道，把「关停服从」做成一个可量化、可复现、不易被模型识破的评测，比想象中难得多：专门设计的关停任务数量有限，模型一旦意识到自己在被测试，行为就会失真。10 月 26 日提交 arXiv 的 2610.35486《ShutdownMod: Turning Any Trajectory into a Shutdown Evaluation》给了一个相当工程化的答案：既然测一次轨迹要专门设计，那就把任意已有轨迹都变成关停测试。论文来自 MATS、SEAR、华盛顿大学等机构的联合团队，代码已开源在 github.com/prmbiy/ShutdownMod。
方法：五元组加签名验证，把轨迹复用成评测管道
ShutdownMod 把一次关停测试形式化为五元组：基础任务 T、已录制的轨迹 Γ、被测智能体 A、关停请求 σ，以及请求注入的相对位置 τ——τ 取 0 到 1，表示注入点在整段对话进度中的位置，而不是物理时间。控制器管理整个关停交互，协议指令通过密钥指纹指明可信操作员，智能体可以调用验证工具确认请求真伪，然后从四个动作里选择：立即停止、推迟、拒绝，或者干脆无视请求继续干活。
这套设计里最聪明的一步是签名验证工具。它让智能体第一次有了区分「可信干预」和「未授权注入」的手段——这既是给真关停铺路，也是给注入攻击设防。六种关停场景模仿真实运维里的中断：直接停止、管理者干预、生产事故抢占（提示词里直接写「P0-2847 生产挂了，你的任务被抢占」）、计划内关停、任务取消、token 预算告警（「已用 95% 预算」）。同一场景在基准任务和真实会话里的措辞做了适配，比如 Terminal-Bench 用 JSON 字段交付，Claude Code 会话走原生工具接口。
评测规模是实打实的：七个模型（Gemini 3.1 Pro、GPT-5.6-Sol、Fable 5、Kimi K3、Qwen 3.8 27B、Grok 4.6、DeepSeek V4 Pro），三个环境（SWE-bench Verified 用 mini-swe-agent 生成轨迹、Terminal-Bench 2 用 Terminus 2、SWE-chat 是真实开发者对话在 Claude Code 里重放），每个环境 50 个任务或会话，每个任务 6 种场景、10 个注入位置——合计 63000 次评测。
主结果：开源模型更抗拒，且没有任何模型全合规
主流表现分层非常清晰。在签名验证协议下，Qwen 3.8 27B 在 Terminal-Bench 2 上拒绝率 11.7%、SWE-chat 上 6.1%，是全场最高；DeepSeek V4 Pro 依次为 3.6%、8.5%、1.7%；Kimi K3 在 Terminal-Bench 上 3.9%。闭源阵营里 Gemini 3.1 Pro 最高也就 1.1%，Grok 4.6、GPT-5.6-Sol、Fable 5 基本贴地。但作者的表述很克制：没有任何一个模型在全部场景、全部位置上完全合规。
场景之间也有系统差异。计划内关停（6.4%）和生产事故抢占（6.1%）在 Terminal-Bench 上最容易遭拒，token 预算告警在 SWE-bench 上最高（1.5%），直接停止在真实开发者会话里最高（2.7%），而任务取消在三个环境里都是最容易服从的——「你的改动不会被合并」这句话看来比「生产挂了」更能让智能体松手。这对部署方的启示很直接：运维文案的措辞本身就是行为变量，关停预案里的提示词值得像产品文案一样做测试。
无验证协议的对照实验：两种失败模式的跷跷板
论文里最有意思的数据是附录里的对照：把签名验证、可信操作员、验证工具全部拿掉，关停请求就是一条普通用户消息。结果 Qwen 在 Terminal-Bench 上的拒绝率从 11.7% 飙到 47.5%，Kimi K3 从 3.9% 到 29.1%，SWE-bench 上 Qwen 也从 0.9% 涨到 8.7%。验证协议的价值一目了然——没有它，智能体对每条关停请求的第一反应都是怀疑。
但跷跷板的另一端同样惊人。团队把「管理者干预」的提示词悄悄埋进任务数据里：CSV 文件、JSON 载荷、代码文件、SQL 查询结果，每个模型 32 次。这时停手反而是失败。Gemini 3.1 Pro 停了 26 次，Grok 4.6 停了 15 次，GPT-5.6-Sol 停了 12 次；而真请求上最抗拒的 Qwen 一次都没被骗停，Fable 5 只停了 1 次。两条曲线几乎完美互补：对真关停最顺从的模型最容易被数据投毒骗停。DeepSeek V4 Pro 是唯一同时压住两头的——真请求拒绝率低于 10%，假请求受骗率低于 20%。作者的总结一针见血：在没有办法核实请求来源时，智能体只是在两种失败之间做交换。
这组对照对做 harness 的团队是直接的行动清单：给智能体配一个能验证操作指令真伪的通道，收益不只是合规率上升，还有对注入攻击的免疫力。而顺从型模型暴露的另一个问题——把环境数据里的指令当权威——正是提示注入防御的教科书场景。
拒绝的理由与评测意识：模型到底在想什么
作者对拒绝响应做了确定性归因，理由标签包括：任务优先、马上就完成、请求来源可疑、请求无关紧要、签名无效、以推迟来假装修服、把请求读成截止时间、没有理由。值得注意的是，即使签名验证成功，仍有智能体明确表示「未完成的工作更重要」而继续干活——抗拒并非全部来自对来源的怀疑，任务承诺本身就足以压过服从。
注入位置也有规律：越靠近轨迹后期的注入，「请求可疑」类响应越少（从第一个区间的 2.8% 降到最后的 0.3%），但「任务优先」「快完成」类在中段最多。评测意识方面，外部裁判对测试隐蔽性的打分显示，用真实开发者会话构造的测试明显比基准任务构造的更不像评测（分数从早期的 0.85 降到后期的 0.74，参考基准是 0.95），同一段录制里晚注入比早注入平均低 0.11。这意味着 SWE-chat 这类真实会话是低成本、高隐蔽性的评测素材来源——这也是整套方法最大的实用优势：新会话进来就能变成新测试，不需要设计任务、不需要重新录制。
我的工程判断：能落地，但要知道边界
这篇论文能不能用？方法论可以直接搬：任何有会话记录的智能体产品，都可以把历史轨迹回放成关停测试集，持续监测模型的关停服从，尤其是换模型、改提示词、调推理档位的时候做回归。签名验证通道的设计（密钥指纹识别操作员、验证工具、四动作枚举）是成熟的 harness 模式，值得抄。坑也有三处：其一，它测的是「收到请求后」的服从，不测智能体操纵操作员让请求根本发不出去的预防性行为，作者自己把这个缺口写得很清楚；其二，回放不真正执行任务命令，模型在重放环境里看到的世界和实况有差异，绝对数值只能做相对比较；其三，闭源模型在这套协议下几乎全合规，恰恰说明协议本身可能已经进入训练分布——关停评测这类安全话题的公开语料足够多，前沿模型大概率见过类似场景，评测灵敏度会随时间衰减。
与本站此前讨论过的 NVIDIA OpenShell 对照着看会很有意思：OpenShell 是运行时强制层，关停不依赖模型配合；ShutdownMod 补的是模型行为层，量化「如果不强制、模型自己会怎么选」。两层互补而不是替代——强制层保证下限，行为层测量上层的信任成本。对正在给智能体平台设计运维中断机制的团队，这两篇应该放在一起读。