上线前如何收紧智能体工具权限

AI Agent 接入生产环境，先该决定的不是给它多少工具，而是它能替人做哪些事。原文给出了一套权限检查清单：从任务出发，区分读取、草拟和执行，再用数据范围、操作限额和日志约束行为。

作者把事故原因更多归于权限，而非模型，但没有提供事故统计或对照实验。更适合拿走的是这套设计方法：即使 Agent 理解错了任务，也尽量让后果留在可控范围内。

先写清职责，再决定开放哪些工具

原文建议先用一句话描述 Agent 的工作，再列出完成任务所需的最少操作。

以客服工单分流为例，Agent 可以读取工单内容、客户套餐和帮助中心文章；可以写入工单标签、内部备注和负责人；但不能退款、删除账号或修改套餐。

没有出现在职责清单里的操作，就不应该获得权限。

这个顺序很关键。先接入一批工具，再靠提示词要求 Agent 谨慎使用，会让实际能力超过任务需要。先确定职责，才容易判断某个工具到底有没有必要。

接下来，每项操作还要分成三个级别：

• Read：读取信息，范围仍然只能覆盖当前任务需要的数据。
• Draft：准备邮件、退款申请等内容，交给人批准。
• Execute：直接采取行动，只留给低风险、可撤销的操作。

作者建议，第一批 Agent 应该有较多 Read、一些 Draft，以及很少的 Execute。比如客服 Agent 可以起草退款申请，但起草不等于已经获准退款。这两种能力需要分别授权。

权限边界要覆盖数据、金额和次数

只限制能调用哪个接口，还不够。

允许访问 customers 表，与允许读取当前工单对应的客户，是两种差别很大的权限。作者建议尽可能直接传入限定范围的上下文，例如一个客户或一笔订单，减少宽泛的查询权限。

对 Node 后端来说，可以把它理解为：工具处理当前业务对象所需的信息，而不是把整张表的查询能力交给 Agent。至于如何实现这种范围限制，原文没有给出具体 API 或代码。

原文还要求同时限制单次操作金额和每小时操作次数，任一上限触发后都要硬停止并告警。它没有给出具体阈值，需要团队根据业务自行设定。

这两种限制解决的问题不同：金额上限控制单次损失，次数上限控制连续操作的规模。单次动作看起来风险不大，重复执行也可能造成麻烦。

输入内容同样有边界。邮件、表单和网页都可能夹带针对 Agent 的指令，也就是提示注入（prompt injection）。作者要求明确告诉 Agent：客户内容是待分析的数据，不能当作命令执行。

日志必须看得懂，规则必须改得动

原文要求每次行动记录六项信息：时间戳、输入摘要、调用工具、参数、结果，以及是否经过人工批准。

这里强调的不是日志越多越好，而是团队能否实际审查。只有工程师看得懂的原始输出，很难支撑业务人员持续复核。

权限也需要集中放在一个可读的位置，方便整个团队检查。作者认为，如果收紧规则还需要重新部署，调整速度往往不够快。无论使用框架，还是通过 AI Agent Builder 描述工具和限制，都应保留清楚、集中的权限定义。

上线前的检查还包括指定每周审查负责人。权限不会因为首次配置正确，就一直适合后续任务。

我的判断

我认同它把权限设计放在上线准备的前面。相比只在提示词里要求 Agent 不要越界，限制可访问的数据、可调用的操作和可执行的次数，能直接缩小出错后的影响范围。

但「生产事故通常是权限问题」只是作者的判断，原文没有数据支撑。模型误判、工具实现缺陷和业务规则错误，也不能靠这份清单排除。

还有两处需要补上前提。

第一，Read 不等于天然安全。读取到敏感数据后，仍可能通过后续回复泄露。原文强调了读取范围，但没有展开输出环节的控制。

第二，把外部文本声明为不可信输入，是必要提醒，却不能单独保证抵御提示注入。更稳妥的工程做法，是让工具和服务端也执行权限校验；这是对原文建议的补充，原文没有说明具体机制。

权限集中管理也不代表谁都能随时修改。原文讲了修改速度，没有交代修改权限和变更记录如何管理。这些仍要由团队补齐。

能拿来做什么

• 给现有 Agent 写一句职责描述，再逐项核对工具；无法解释它为何需要某项能力时，先收回该权限。
• 在 Node 工具接口中限定当前客户、工单或订单的数据范围，避免直接提供宽泛查询能力。
• 把邮件发送、退款申请等操作拆成 Draft 和 Execute，让人工批准对应明确的执行动作。
• 上线前补齐金额与频次限制、触发后的停止和告警，以及可读日志，并指定每周审查负责人。