如何设计 AI Agent 的工具调用权限

AI Agent 真正危险的地方，不是它会聊天，而是它能调用工具：发邮件、改数据库、创建订单、删除文件、调用内部 API。只要 Agent 能执行动作，就必须设计权限边界。

这篇文章给一个实用的 AI Agent 工具调用权限设计框架，适合正在做内部 Agent、客服 Agent、运维 Agent 或自动化助手的团队。

快速结论

Agent 权限设计的核心原则是：默认只读，逐步授权，高风险动作必须人工确认。

不要一开始给 Agent “管理员权限”。更安全的方式是按动作风险分级：

只读 → 草稿 → 低风险写入 → 高风险写入 → 破坏性操作

工具权限分级

等级动作类型示例是否需要人工确认
L0无工具只回答问题否
L1只读查询订单、读取文档通常否
L2生成草稿写邮件草稿、生成工单草稿建议审核
L3低风险写入添加标签、更新备注视场景
L4高风险写入发送邮件、修改状态、创建订单是
L5破坏性操作删除数据、退款、改权限必须人工确认，甚至禁止

第一版 Agent 最好停留在 L1-L2。

为什么默认只读

只读 Agent 即使回答错了，通常不会直接破坏系统。但一旦 Agent 能写入数据，错误就会变成业务事故。

例如：

  • 错误发送客户邮件
  • 给错客户退款
  • 删除重要记录
  • 把内部信息写到外部渠道
  • 修改了不该修改的订单状态

所以权限设计不能等到上线后再补。

工具调用前的检查

每次工具调用前，建议检查：

用户是谁？
用户是否有权限？
工具要访问什么数据？
动作是否可逆？
失败会造成什么后果？
是否需要人工确认？
是否要记录审计日志？

这些检查最好写在系统逻辑里，而不是只写在 Prompt 里。

Prompt 不是权限系统

系统 Prompt 可以提醒 Agent 不要做危险操作，但不能代替真正的权限控制。

不安全的做法：

请不要删除数据。

更安全的做法：

Agent 根本没有 delete_user、refund_payment、change_role 这类工具。

权限应该由后端控制，Prompt 只是辅助约束。

人工确认机制

高风险动作应该进入确认流程：

Agent 生成操作计划 → 展示给用户 → 用户确认 → 后端再次校验权限 → 执行工具 → 记录日志

确认信息要具体，不能只写“是否继续”。例如：

即将给 customer@example.com 发送邮件，内容如下...
这个动作会通知客户，发送后无法撤回。是否确认？

审计日志

Agent 工具调用至少记录：

user_id
agent_id
tool_name
input_summary
result_status
created_at
approval_user_id
risk_level

出问题后，你需要知道是谁触发、Agent 调了什么工具、输入是什么、结果是什么。

常见错误

错误 1：把所有 API 都暴露给 Agent

Agent 不需要完整内部 API。给它专门设计小工具，每个工具只做一件事。

错误 2：没有 dry-run 模式

高风险动作最好先支持 dry-run，只生成计划，不执行。

错误 3：没有速率限制

如果 Agent 循环调用工具，可能在短时间内造成大量错误操作。要限制频率和最大调用次数。

总结

AI Agent 的权限设计要像设计一个实习员工的系统权限：先只读，再让它写草稿，最后才考虑低风险自动执行。

真正安全的 Agent，不是 Prompt 写得多严，而是工具、权限、确认和审计都设计清楚。

一个实际例子

假设你想做“自动生成产品 FAQ”的 Agent。第一版不要让它直接更新官网 FAQ。更安全的流程是：

Agent 读取客服工单 → 生成 FAQ 草稿 → 产品经理审核 → 人工发布

等这个流程稳定后，再考虑让 Agent 自动把草稿写入 CMS 的“待审核”状态。即使这样，也不要让它直接发布到线上。

顶部