AI Agent 一旦开始调用工具，权限问题就不能只靠一句“请谨慎操作”解决。它可能读知识库、查客户资料、写邮件草稿、改表格、发消息、提交代码，动作越接近真实业务，越需要把权限分层。
前面讲 工具调用机制 时，我们把 Function Calling、MCP 和 Skills 的边界拆开过；讲 OpenClaw 权限与凭证管理 时，也强调过凭证不能混用。今天换一个更通用的视角：一个 AI Agent 到底应该拥有哪些工具权限。
第一层：只读权限
只读权限适合查询型任务，比如读知识库、搜索文档、拉取订单状态、查看工单记录。它的风险相对低，但仍然要有边界：能读哪些库，能读多少字段，返回结果是否需要脱敏，都要写清楚。
只读工具的关键不是“让 Agent 随便查”，而是让它知道资料来源。否则它会把过期资料、用户输入和工具返回混在一起，这也是 上下文工程 里最常见的污染来源。
第二层：草稿权限
草稿权限适合邮件、报告、客服回复、会议纪要和表格建议。Agent 可以生成内容，但不直接发送、不直接覆盖正式记录。对很多团队来说，这是最容易落地的一层，因为它明显节省时间，同时保留人工判断。
比如 销售线索整理 里，Agent 可以先生成跟进邮件和客户标签；销售人员确认以后再发出去。这样既提高响应速度，也不会把客户沟通完全交给自动化。
第三层：执行权限
执行权限要更谨慎。发邮件、改 CRM、创建任务、发布内容、部署代码，都属于会改变外部状态的动作。这里应该按风险分级：低风险动作可以自动执行，高风险动作必须人工确认，敏感动作要有审批和日志。
判断风险时不要只看工具名称，也要看对象和范围。给自己创建一个待办是低风险，给全公司群发消息就是高风险；改一条草稿记录和删除一批客户数据也不是一回事。
第四层：回滚和审计
真正能上线的 Agent，不只是能执行，还要能解释自己做过什么。工具调用日志至少要记录任务目标、输入摘要、工具名称、关键参数、返回结果、人工确认人和最终状态。出了问题，团队要能知道该撤回哪一步。
这和 AI Agent 评估指标 里的可复盘性有关。一个 Agent 即使成功率不低，如果失败时完全查不清原因，也很难进入长期生产流程。
总结
AI Agent 工具权限模型可以先按四层设计：只读、草稿、执行、回滚。越往后越接近真实业务，越需要人工确认、最小权限和审计记录。把权限拆清楚，Agent 才不是一个不可控的黑盒，而是一个能逐步放权的协作系统。
