Agent 权限边界怎么设计

Agent 越强，越需要边界。

一个只能聊天的系统，最多给错建议。一个能调用工具的 Agent，可能会删文件、改数据、发消息、访问生产系统。能力越接近真实执行，权限设计越不能含糊。

权限不是体验阻力

很多产品会担心权限确认影响流畅度。

但对 Agent 来说，权限边界不是阻力，而是信任基础。用户愿不愿意把任务交给 Agent，取决于它是否可控、可观察、可恢复。

一个没有权限边界的 Agent，很难进入严肃工作流。

我会把权限分成五级

第一层是只读。

Agent 只能读取、搜索、分析，不能写入任何东西。这适合调研、代码审查、资料整理。

第二层是建议。

Agent 可以生成方案、补丁、命令，但不能直接执行。用户确认后再进入下一步。

第三层是沙箱写入。

Agent 可以在临时目录、测试环境、草稿文档里写入。失败了可以直接丢弃。

第四层是受控写入。

Agent 可以修改真实项目或协作系统，但必须限定范围，必要时需要确认。

第五层是自动执行。

只适合低风险、可回滚、重复性强的任务，比如格式化、生成摘要、同步无害状态。

权限要绑定工具和上下文

权限不应该只绑定用户身份，还应该绑定任务场景。

同一个用户，在不同任务里允许的操作不同：

• 做代码审查时，只读就够
• 修复 lint 时，可以允许局部写入
• 部署生产时，必须确认
• 操作数据库时，默认只读
• 发外部消息时，要能预览内容

这意味着权限系统要理解任务类型，而不是只有一个全局开关。

高风险操作必须可审计

凡是会改变外部状态的操作，都应该记录：

• 谁触发了任务
• Agent 调用了哪个工具
• 输入参数是什么
• 输出结果是什么
• 是否经过用户确认
• 能否回滚

没有审计日志，多 Agent 系统出问题时很难定位责任。

Claude Code 的启发

Claude Code 值得学习的一点，是它不会默认把用户工作区当成自己的沙盘。

它需要理解项目指令，尊重已有 git 改动，高风险动作要谨慎，交付时说明验证结果。

这类设计体现了一个原则：Agent 的执行权必须服务用户目标，而不是覆盖用户控制权。

应用到自己的项目

在 OpenClaw 里，我会把权限设计成任务级策略：

Task type -> Tool scope -> Approval rule -> Audit log -> Rollback strategy

比如：

• 搜索资料：允许联网搜索，记录来源
• 生成飞书文档：先写草稿，用户确认后发布
• 修改代码：限定仓库路径，保留 diff
• 运行命令：允许白名单命令，高风险命令确认
• 操作生产数据：默认禁止写入

这样 Agent 不是“能不能用工具”，而是在明确边界里使用工具。

一个判断标准

如果一个 Agent 的错误操作无法被发现、无法被追踪、无法被回滚，它就不应该拥有自动执行权限。

权限设计不是为了限制 Agent，而是为了让强 Agent 可以被放心使用。