| 标题（简） | 方向细分 | 来源 | 综合分 |
|---|---|---|---|
| Don't Let AI Agents YOLO Your Files…今日选定 | Filesystem-level Agent Safety | arXiv 2026-04-15 / v2 2026-04-16 | 91 |
| Owner-Harm: Missing Threat Model for AI Agent Safety | Threat Modeling | arXiv 2026-04-20 | 88 |
| Blind Spot of Agent Safety (OS-BLIND) | Computer-Use Agent Safety | arXiv 2026-04-12 / v2 2026-04-17 | 87 |
| Discovering Agentic Safety Specifications from 1-Bit Signals | Safe Spec Discovery | arXiv 2026-04-25 | 85 |
| AIR: Improving Agent Safety through Incident Response | Incident Response | arXiv 2026-02-12 | 80 |
| AgentDoG: Diagnostic Guardrail Framework | Guardrail | arXiv 2026-01-26 | 76 |
AI 编码 Agent 直接在用户文件系统上工作，它们经常损坏数据、删除文件、甚至泄露密钥。当前各种防御方案都被困在一个 tradeoff 里：不限制访问则风险高，频繁弹出权限提示则阻碍使用。
为理解该问题，本文进行了首个对 Agent 文件系统滥用的系统性研究——分析了 13 个主流 Agent 框架下公开报告的 290 起事故。分析表明：今天的 Agent 对"自己的文件影响"只有很有限的信息，对这些影响的控制也不足。因此作者主张把信息与控制权下沉到文件系统自身。
基于这一原则，作者设计了 YoloFS——一个 Agent 原生的文件系统，包含三项技术：（1）Staging：所有写入在提交前被隔离，给用户一种"事后可纠正"的控制；（2）Snapshots：将这种控制力也给 Agent 自己，让它能检测并纠正自己的错误；（3）Progressive Permission：以最小的交互门控访问权限，为用户提供"事前预防"的控制。在 11 项带有隐藏副作用的任务上，YoloFS 在 8 项里让 Agent 成功自我纠错，并保持所有副作用处于可审查的暂存状态；在 112 项常规任务上，YoloFS 让用户所需的交互次数更少，且成功率与基线持平。
解决了什么问题：coding agent 的一个根本 tension——"让 Agent 自由操作 = 能力"，"限制 Agent 操作 = 安全"。前者导致真实事故（13 框架 290 案例），后者变成频繁权限弹窗，让 Agent 失去自治能力。作者的洞察来自 OS 社区的长期经验：这类问题的正确抽象层不是应用，而是文件系统本身。
核心设计——YoloFS 三件套：
| 机制 | 服务对象 | 类比 |
|---|---|---|
| Staging（暂存提交） | 用户（事后纠正） | Git 的 staging area 式事务隔离 |
| Snapshots（快照回滚） | Agent（自我纠错） | ZFS/Btrfs 快照，Agent 可感知并回滚自身错误 |
| Progressive Permission（渐进式权限） | 用户（事前预防） | Android 运行时权限 + 最小交互门控 |
为什么是"文件系统"这一层：之前的防御分为两类——（a）在 Agent 侧加 prompt 约束或 policy，（b）用 sandbox 完全隔离。两者都有硬伤：前者不可靠（LLM 被 jailbreak 或自己产生混乱），后者不可用（完全隔离的 Agent 不能访问真实文件）。YoloFS 选择"和文件系统一起设计"：Agent 的每一次文件写入都先落到 staging layer，commit 阶段可被人工或 Agent 自己审查后再生效——从而在不牺牲能力的情况下消除"不可逆破坏"。
与现有工作的关键区别：同期相关工作 Owner-Harm（arXiv 2604.18658）提出威胁模型，OS-BLIND（arXiv 2604.10577）提出评测基准，但它们都停留在"发现问题"层面；YoloFS 给出的是"OS 原生的结构性缓解方案"——这类跨层 co-design 是 Agent Safety 研究里仍然稀缺的范式。
https://arxiv.org/abs/2210.03629
docs.anthropic.com — Computer Use
https://arxiv.org/abs/2407.16741
usenix.org — ZFS
git-scm.com — Pro Git
https://arxiv.org/abs/2404.07972
https://arxiv.org/abs/2211.09527
- 事故量化：13 个主流 Agent 框架下 290 起公开的文件系统误操作事故——这是当前 Agent Skills Safety 方向最大规模的真实事故语料。
- 自我纠错能力：在 11 项带隐藏副作用的任务上，YoloFS 使 Agent 在 8 项里实现自我检测并回滚，所有副作用均保持在可审查的 staging 状态。
- 用户体验不降反升：在 112 项常规任务上，YoloFS 需要的用户交互次数比基线 permission prompt 方案更少，且任务成功率保持一致。
- "OS 抽象层即安全边界"：论文提出一个值得 agent-safety 社区认真对待的结构论点——Agent 的安全 tradeoff 应该在系统调用这层解决，而不是在提示词层面解决。
这是 2026 年少数真正把 Agent 文件安全问题"沉到 OS 层"的工作。对你研究技能安全的意义：skill 的权限边界不必由 skill 自己承诺，可以由底层 runtime 强制。把 YoloFS 的 staging/snapshot/progressive permission 三件套抽象成 skill-level 概念——每个技能调用都在 staging 层执行、可回滚、权限最小化——就是可落地的研究方向。
论文强调 harness 需要把"动作效果"暴露给 Agent 自己——这正是 harness 中"可观测性"的核心。YoloFS 为 harness 提供了一种独特的可观测手段：通过文件系统层的事务记录，Agent 能看到自己的副作用、并能以"撤销 + 重做"为语义在 harness 中循环——这是传统 "edit-execute-evaluate" 循环的强化版。
作者用"带隐藏副作用的任务集"定义了一种评估方法：衡量 Agent 能否检测并纠正自己的错误，而非仅看终态是否正确。这是一种"过程安全"维度，可以直接被吸收到 agent safety benchmark 中，补齐现在 HarmBench / AgentHarm 只看 refusal/attack success 的结果导向评估。
- Owner-Harm — Zhang & Jiang (2026) — 提出"Agent 伤害其 deployer"这一被主流 benchmark 遗漏的威胁模型，8 大类别、3 种实验体系
https://arxiv.org/abs/2604.18658 - OS-BLIND — Ding et al. (2026) — Computer-Use Agent 在"良性指令 + 恶意环境"下的安全盲点，Claude 4.5 Sonnet 多代理场景 ASR 从 73% 升到 92.7%
https://arxiv.org/abs/2604.10577 - EPO-Safe — Gallego (2026, AAMAS ALA Workshop) — Agent 从 1-bit 危险信号中自发学习安全 spec
https://arxiv.org/abs/2604.23210