权限分级与人工断点

「给 Agent 权限」不是二选一——要么全给，要么不给。真正的做法是分级：读的放开，低风险写的放行，高风险写的拦下来，边界动作交给人。

为什么要分级

因为 Agent 的一切行为都可能有错，而且错误是分布式的：目标会漂移、工具会误用、外部内容会诱骗它。一条网页里的恶意指令，就能让一个全权限 Agent 执行它根本不该执行的动作。

分级的意义在于：让风险的评估从「模型每次都要做对」转移到「系统只让它在安全范围内做对」。读错了可以重读，删错了无法挽回。前者的容错成本远低于后者。

这和给人开权限是同一套逻辑：你不会因为信任某个实习生，就给他生产数据库的删除权限。Agent 也一样。

四级权限

① 只读。查文档、读数据、看代码。放开给 Agent，这类操作错了也能重来，无需干预。

② 低风险写。写草稿、存临时文件、改自己的草稿箱。可以自动放行，但要留日志——记录它写了什么、改了什么。

③ 高风险写。删除、覆盖、发送、修改配置、涉及钱的操作。默认禁止，只有明确授权时才可执行。这里的「明确授权」通常是人工批准，见下一节。

④ 人工断点。超出已授权范围、或命中高风险清单的动作，停下来等待人来确认。这是最高的一级——由人来做最终决策。

四级的边界可以根据你的场景调整，但骨架不变：影响越不可逆，越要靠人。

断点设在哪

人工断点不是越多越好——每一步都问人，Agent 就失去了意义。判断该在哪设断点，用三个问题：

一、这个动作可逆吗？可逆（改草稿、存临时文件）→ 放行。不可逆（删除、发送、付款）→ 断点。

二、出错的影响面多大？影响单个用户的一封邮件 → 或许可自动。影响全体用户的群发、影响生产数据的批量操作 → 必须断点。

三、它执行时信息完整吗？Agent 往往只看到局部上下文，不知道全局约束。凡是「需要全局判断才能确认正确」的动作，都该留一道人的关卡。

一个务实的断点设计：把断点设在「动作前」而不是「动作后」。让 Agent 在触发高风险动作前先「提出申请」，人批准后才执行。而不是先执行了再汇报——那样断点只是记录，不是保护。

默认怎么定

给 Agent 配权限，默认值比清单更重要。两条原则：

一、最小权限。默认什么都不能做，按任务需要逐个开放。任务结束后回收。「先全给再收紧」是灾难配方——你多半没时间收紧。

二、权限和身份绑定。Agent 用的权限，应该和「它代谁执行」绑定。用户 A 的 Agent 不该有用户 B 的数据权限。这既是安全，也是合规。

最后，把权限当成评测的一部分：定期检查它实际调用过哪些高风险动作、有没有越权、断点拦截率是多少。权限系统好不好，不是看设计得漂亮，是看运行记录。

记住那句话：人工断点不是流程慢，是唯一不需要信任模型的防线。模型会出错、会漂移、会被骗——但一道人工关卡不会。