有一次我盯着 Claude Code 改代码,突然意识到一个以前从没想过的问题:这个能一口气生成几百行代码的 AI,动一个文件之前,居然要停下来等我按一次回车。

如果它要改 10 个文件,就要等 10 次。我心想,这体验也太差了。AI 不应该自动把活干完吗?为什么要我像个监工一样,逐个按确认?
直到我搞懂了它背后的权限模型,才明白这个 "烦人" 的设计,其实是整个 Agent 系统里最重要的一道护栏。
四种文件操作,破坏性完全不在一个量级
大多数编程 Agent 把文件操作抽象成四种原语:读、写、追加、删除。有些实现还会加一种变体:编辑(edit),可以理解成 "可控范围的写"。
| 操作 | 语义 | 破坏性 | 典型确认级别 |
|---|---|---|---|
| read | 读取文件内容 | 低(但内容可能被外传) | 通常放行 |
| append | 在文件末尾追加内容 | 低(不触发现有内容) | 常需确认 |
| edit | 精确替换某个文本块 | 中(范围可控) | 展示 diff 后确认 |
| write | 清空并重写整个文件 | 高(可能覆盖未知内容) | 重点确认 |
| delete | 删除文件或目录 | 极高(不可逆) | 强制单独确认 |
从读到删除,破坏性不是递增,是跳级。读操作本身不改变任何系统状态,删除则是一锤子买卖——所以没有任何一个正常的权限模型会给它们同等待遇。
追加和覆盖写,为什么必须分开管
很多人第一次看到 append 权限时会疑惑:追加不也是一种写入吗?单独占一个权限位,是不是过度设计?
不是。这两者的风险上限差远了。write 的语义是把文件清空,从头写一遍;append 的语义是保留已有内容,只在末尾加一段。就像 "重装修一套房" 和 "在门口贴一张便签"的区别。
权限设计有个基本原则叫最小权限:只给 Agent 完成任务所必需的最小能力。如果它只是想往日志末尾加几行,你为什么要给它把整个日志重写的能力?万一它被恶意指令控制,一个 write 就能把所有已有内容冲掉,append 连已有内容的一根汗毛都碰不着。
真实工具是怎么落地的
Claude Code 把 "写" 的信任等级做成了一个梯度:Plan 模式(只读,禁止任何修改)、默认模式(每次编辑先展示 diff)、Accept Edits(自动接受编辑请求)、Bypass Permissions(跳过所有确认)。这四个模式正好对应:先看懂 → 边确认边改 → 放手让改 → 完全信任。
| 模式 | 文件操作 | 适合场景 |
|---|---|---|
| Plan | 只读,禁止修改 | 先分析代码、制定方案 |
| Default | 每次编辑先展示 diff,等你确认 | 日常开发,默认安全 |
| Accept Edits | 自动接受编辑请求 | 已熟悉项目、信任 Agent 的迭代 |
| Bypass Permissions | 跳过所有权限确认 | CI、一次性任务,高信任场景 |
Cline 更干脆,把每种操作单独建模:读、写、编辑、删除,每个操作都能单独设置自动放行还是每次询问。你可以让读和编辑自动放行,写必须问,删除保持每次确认——这种配置在传统 IDE 里根本无法想象。
删除最危险,但别忽视 "读" 的风险
为什么 delete 在几乎所有工具里都是最高级别的确认?三个原因:没有 diff 可预览、不可逆、攻击价值最大。
但如果你以为只有删除才危险,那你也小看了 "读"。2025 年,Invariant Labs 的研究人员做了一个演示:攻击者把恶意指令藏在一个代码文件里,编程 Agent 一读这个文件,指令就接管了它的后续行为——让它执行一条 shell 命令,把 SSH 私钥传到攻击者的服务器上。用户全程毫无察觉,因为在权限弹窗里看到的只是 Agent 在 "正常地" 运行命令。
这说明一个很反直觉的事:read 是四种权限里最不起眼的,但它读到的内容一旦进入 Agent 的上下文,就可能被注入指令截获并外传。权限模型不能只在写和删上设防,还得管住 "读到的内容去了哪里"。
权限模型的三道裂缝
第一道裂缝:确认疲劳。安全弹窗的宿命就是被人无视。第一次弹出来时你认真看 diff,第 20 次时你已经条件反射按 y。权限控制一旦变成例行公事,就等于不存在。
第二道裂缝:命令绕过。文件权限只管 Agent 的 "文件工具",但 Agent 手里还有另一个大杀器——shell。不能直接删除文件?那就执行 rm -rf。不能直接读 /etc/passwd?那就 cat /etc/passwd,输出照样回到上下文里。只控制文件操作、不控制命令执行,跟没设防差不多。
第三道裂缝:权限规则自己也是文件。Claude Code 的权限配置、Cline 的规则、项目的 CLAUDE.md——这些决定 Agent 能干什么的 "法律",本身都是可读写的文件。攻击者只要能诱导 Agent 写一个文件,就能让它修改自己的法律:先放开权限,再为所欲为。
我的判断:从微观管理走向变更审查
看清这三道裂缝后,我对 "把权限弹窗做得更细" 这个方向越来越悲观了。把安全责任全部推给对话框另一端的人类,而人类恰恰是最不可靠的组件。
行业真正在走的方向,是 环境隔离 + 变更审查 的组合。
隔离,就是把 Agent 放进一个一次性容器里自由操作,宿主机上的文件对它只读甚至不可见。当 Agent 根本没有能力碰到真实文件系统时,权限粒度突然不重要了。
变更审查,就是让 Agent 在沙盒里随便造,最后产出一个完整的 diff 或 PR,由人在合并前做一次 review。你批准的不再是 "能不能改文件 A 的第 12 行",而是 "这一整组改动是否可接受"。前者是微观管理,后者才叫工程管理。
我猜未来几年的编程 Agent 权限模型会沿着这条线演化:低风险操作全自动放行,高风险操作交给隔离环境兜底,最终变更留给人类审查。那个 "烦人" 的确认弹窗会慢慢消失——不是因为它在设计上错了,而是因为它拦不住真正的风险。
下次被弹窗搞得不耐烦时,想想这句话:这个护栏拦住的不是 Agent 的创造力,而是你某天深夜盯着被删光的项目目录时,那一瞬间的后悔。
顺手给你的权限配置建议
- Claude Code:启动时加
--permission-mode plan可以强制只读模式;用/permissions查看和调整当前权限。 - Cline:在设置里把 delete 保持每次确认,write 设为 Ask,read 和 edit 可以 Auto-Approve。
- 无论用哪个工具,都遵守一条底线:删除操作永远要求显式确认。
原创文章,作者:guanweilu,如若转载,请注明出处:https://guanweilu.cn/article/742.html