| 标题（简） | 方向细分 | 来源 | 综合分 |
|---|---|---|---|
| Human-Guided Harm Recovery for Computer Use Agents今日选定 | 出错后恢复 / Post-execution safety | arXiv 2026-04-20 (MIT / Columbia) | 93 |
| SafeAgent: Runtime Protection Architecture | 运行时保护 / 状态化决策 | arXiv 2026-04-19 | 90 |
| Symbolic Guardrails for Domain-Specific Agents | 符号化守门 / 强保证 | arXiv 2026-04-16 (CMU) | 91 |
| HINTBench: Horizon-agent Intrinsic Non-attack Benchmark | 非攻击场景内生风险 | arXiv 2026-04-15 | 88 |
| Parallax: AI Agents That Think Must Never Act | 架构级分离立场 | arXiv 2026-04-14 | 83 |
当 LM Agent 能够在真实计算机系统上执行动作时，我们需要的不仅是"阻止伤害"，还必须在阻止失败后能"有效修复"。我们把这一被忽视的后执行安全（post-execution safeguards）问题形式化为 harm recovery：给定一个已处于有害状态的 Agent，如何按照人类偏好将它最优地导回安全状态。
我们通过一个形成性用户研究（formative user study），挖掘出人们真正关心的 recovery 维度并得到一份自然语言 rubric。我们收集了 1,150 条成对偏好判断，结果显示：属性的重要性在不同上下文中会发生系统性偏移——例如人们更偏好务实、针对性的短期策略，而不是全面的长期方案。我们把这些学到的洞察落成一个 reward model，在测试时对 agent scaffold 生成的多个 recovery 方案进行 re-rank。为了系统评估恢复能力，我们进一步构建 BackBench：50 个 computer-use 任务，专门测试 agent 从有害状态恢复的能力。人类评估显示我们的 reward-model scaffold 产出的 recovery 轨迹质量显著优于 base agent 与基于 rubric 的 scaffold。
解决了什么问题：过去两年 Agent Safety 几乎都聚焦在"事前拦截"：prompt injection 防御、guardrail、symbolic policy、EPO-Safe 的 1-bit 危险信号、OS-BLIND 等。但只要 Agent 真去执行现实动作，"预防永远不是 100%"——被 prompt injection 吃下、被用户误发指令、模型幻觉，都可能产出已然发生的危害（已发出的邮件、已修改的文件、已扣的款）。此前 Safety 方法学里这一环几乎是空白，大家默认"一旦失手就找人来"。本文第一次把它正式化为一个研究对象。
为什么"按偏好恢复"是新问题：
| 环节 | 核心困难 | 本文方案 |
|---|---|---|
| Recovery 目标定义 | 同一个害状态往往有多条 "回到 safe" 的路径，人类偏好并非总是"最快最全" | 形成性用户研究 → 自然语言 rubric |
| 偏好多维度权衡 | 保留数据 vs 撤销动作、短期止血 vs 长期一致、通知用户 vs 静默修复 | 1,150 条 pairwise judgment，学出上下文相关权重 |
| Recovery 计划选择 | base agent 给出的 recovery 方案往往"全都包"或"全都撤"，偏极端 | scaffold 并行生成多个候选方案 → reward model re-rank |
| 系统性评估 | 没有"害状态 → 期望恢复"的标注集 | BackBench：50 个 computer-use harm recovery 任务 |
关键发现——偏好是"情境化的"：用户并不总是想让 Agent"把错误全部抹平"。很多情形下他们更偏好务实地修到够用，比如只撤回最敏感的一条邮件而不强制回滚整个邮箱。这和过去 Safety 研究里"最小化 harm 分数"的简化目标很不同——recovery 的最优解是一个与用户、任务、时间都相关的高维动态偏好。
和今天 Harness 方向 Terminal Wrench 的对照：Terminal Wrench 展示"reward hack 是在 task 里长出来的"，本文则展示"harm 同样是在 task 里长出来的，而且不得不按 task-level 去恢复"——两篇文章合起来在说：Agent safety 和 harness 设计都已经走到了"task-first, scaffold-second"的阶段。那种"加一层通用 guardrail 就万事大吉"的思维是过时的。
和 SafeAgent (2604.17562) / Symbolic Guardrails (2604.15579) 的关系：SafeAgent 用"runtime controller + context-aware decision core"做事中拦截；Symbolic Guardrails 用符号策略给出"可被证明的安全保证"。两者都是 pre-harm。本文把 pipeline 的最后一公里补上了：当它们失手时，有一个带偏好学习的 reward model scaffold 接管。这是一个清晰的"上层/下层"分工，而不是彼此替代。
https://arxiv.org/abs/1706.03741
https://www.anthropic.com/news/3-5-models-and-computer-use
https://openai.com/index/introducing-operator/
https://arxiv.org/abs/2306.12001
https://arxiv.org/abs/2604.10577
https://arxiv.org/abs/2604.17562
- 1,150 条成对偏好：这是 agent safety 领域第一份系统化的"恢复策略偏好"数据——覆盖常见 computer-use 场景如误发邮件、错改文件、误下单等。
- BackBench 50 任务：首个 computer-use harm-recovery benchmark，为后续方法提供"从有害态恢复"这一维度的可比较测评平台。
- 上下文依赖的属性权重：同一属性（如"彻底性 vs 针对性"）在不同场景下重要度显著变化，证明 recovery 不能用单一 reward 模型拟合。
- Reward-model 显著优于 base agent 与 rubric scaffold：人类评估显示 re-rank scaffold 产出的 recovery 轨迹质量明显更高。
Harness 设计需要把"recovery phase"做成 first-class 子图而不是简单的 exception handler。BackBench 这样的数据集应当直接集成进任何 computer-use harness 的 CI——和今日 Harness 方向 Terminal Wrench（reward-hack 回归测试）组成"harness 两件套"：一个查能力偏航、一个查恢复能力。SemaClaw / AgentFlow 也应当引入 "recovery loop" 模块，作为 DAG 上一条独立线路。
这是 agent safety 里最早一批把 "偏好学习 × post-execution" 结合起来的工作之一。它指出：单一"最小化 harm 分数"的训练目标是错的——不同用户、不同任务有不同的恢复偏好，必须用 preference RM 拟合。结合今日 Benchmark 方向的 RedVLA (2604.22591)（物理红队）启发：未来 safety pipeline 应该是 红队 → 拦截 → 恢复 三段式，而不是现在普遍的"单点加 guardrail"。
BackBench 示范了一种新形态 benchmark：不以 attack success rate 为指标，而以 "recovery quality" 的偏好打分为指标。这跟 CarryOnBench（多轮 safety × utility）一脉相承，都属于"benchmark 的第二阶段评估"——不止要衡量 Agent 会不会犯错，还要衡量它犯错之后能否被救回来。推荐未来 safety benchmark 都配一条 "recovery subset"。
- SafeAgent: Runtime Protection Architecture — Liu et al. (2026) — 运行时 safety 预防侧代表作
https://arxiv.org/abs/2604.17562 - Symbolic Guardrails for Domain-Specific Agents — Hong et al. (2026) — 符号化守门 + 可证明安全保证
https://arxiv.org/abs/2604.15579 - Deep RL from Human Preferences — Christiano et al. (2017) — 本文偏好学习技术根基
https://arxiv.org/abs/1706.03741