给 Agent 划权限：三道边界比提示词重要得多

客户第一次提 Agent 需求时，往往会说「希望它能自动处理客户的问题」。这句话里藏着一个危险：什么叫「处理」？回复邮件是处理，退款也是处理，两者需要的权限差了几个数量级。

我们在每个 Agent 项目里都会先定三道边界，然后才写第一行提示词。

第一道：能读什么，能写什么

读和写必须分开授权。一个客服 Agent 需要读订单历史才能回答问题，但不需要写订单状态。把这两件事绑在一起，是绝大多数事故的来源。

具体做法是最小权限：先只给读权限跑两周，观察它实际需要什么，再逐项加。不要一开始就给全套权限然后指望提示词约束——提示词是建议，权限是事实。

第二道：什么动作必须人确认

我们把动作分成三档：

• 自动执行：只读查询、生成草稿、内部标注。做错了改回来成本很低。
• 执行后通知：发内部通知、创建任务、更新内部状态。做错了有人能看到并能撤销。
• 必须人确认：对外发送、涉及金额、修改客户可见的信息、删除数据。

第三档的清单要写死，不能由模型判断「这个动作重不重要」。我们已经见过模型把「给客户发一封说明邮件」判定为低风险内部操作。

第三道：出错之后怎么回退

每个 Agent 都必须能回答一个问题：如果它刚才做错了，我们怎么撤销？

如果答案是「没法撤销」，那这个动作就不该被自动化。我们要求所有写操作都可追溯——记录什么时间、基于什么输入、做了什么修改、原始值是什么。这样最坏情况下还能人工复原。

提示词仍然重要，但位置不同

提示词解决的是「怎么把事做对」，权限解决的是「做错了能有多糟」。这两件事不能互相替代。

一个提示词写得很好但权限过大的 Agent，和一个提示词一般但权限收得很紧的 Agent，后者在生产环境里一定更安全。前者的风险是尾部事件，平时看不出来，出事就是大事。

一个实践中的判断

如果客户说不清「这个 Agent 做错了会怎样」，那说明这个流程还不该自动化。先把它做成「AI 建议 + 人执行」，跑一两个月，等流程本身的边界清楚了，再考虑让 Agent 直接动手。

这个顺序不能反。先自动化再补权限，通常是在事故之后。