权限分级与人工断点 | Agent 与 Skill | 做产品

权限分级与人工断点

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

你会遇到的现象

• 演示时它能删库，你下意识觉得「应该不会真删吧」

• 为了让它「自动化」，把权限全开给了它

• 没有人工断点，所有动作都在无人监管下发生

为什么要分级

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

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

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

四级权限

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

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

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

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

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

台阶越高，出错时越挽不回来

① 只读 查文档、读数据、看代码

② 低风险写 草稿、临时文件

③ 高风险写 删除、发送、付款

④ 人工断点 超出授权范围

自动放行 自动 + 留日志 默认禁止 停下来等人批

错了能重来 错了改得回 要明确授权 由人做最终决策

默认从最左边开始，按任务需要逐级开放，任务一结束就收回

台阶的高度就是出错时的挽回成本。「先全给再收紧」之所以是灾难配方，是因为它等于一上来就站在最右边——而你多半没有时间再走回来。

断点设在哪

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

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

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

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

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

默认怎么定

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

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

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

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

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

Agent 跑偏的三种形态 分级权限要拦的，正是这三种失控。

提示注入 为什么全权限 Agent 尤其危险。

什么能交给 AI 从用户视角判断，哪类操作该留给人工。