很多企业做 Agent 时，会在两个极端之间摇摆：要么只给只读权限，最后还是人工复制粘贴；要么为了追求“全自动”，直接把 CRM、工单、消息和审批接口全部开放。

更稳妥的做法不是回答“开或不开”，而是把写权限拆成可逐级放开的能力，并让每一级都有明确的额度、验收和回滚方式。

一、先把写权限拆成四级

L0：只读与建议

Agent 可以查询数据、生成草稿和推荐下一步，但不能改变外部系统。适合需求尚未稳定、验收标准还在建立的阶段。

L1：可撤销写入

允许创建草稿、添加内部备注、写入临时表或发起待审批任务。所有结果都能在业务生效前被人工检查和取消。

L2：低风险受限写入

允许自动更新低风险字段、关闭满足固定条件的工单、发送内部通知，但必须限制对象范围、单次额度、频率和执行时段。

L3：高风险写入

涉及付款、删除、对外发送、合同状态和敏感数据修改时，Agent 只能准备动作，最终提交必须经过指定角色确认。即使模型平均准确率很高，也不能跳过最坏情况测试。

权限不应该授给“某个 Agent 名称”，而应该授给具体能力，例如：

crm.contact.update.low_risk_fields
ticket.close.refund_below_100
message.send.internal_only
payment.prepare.max_5000

二、开放写权限前检查 7 件事

1. 任务身份是否稳定

task_id 表示业务任务，run_id 表示某次执行。重试时必须能判断这是同一任务的新一次尝试，而不是一笔全新的业务。

2. 权限是否在服务端过滤

模型不能只靠 Prompt 自觉遵守权限。它能看到的数据、能调用的工具和参数范围，都应由服务端根据当前用户与任务上下文过滤。

3. 工具契约是否明确

每个写工具都要有输入输出 schema、错误码、超时、版本和副作用说明。自然语言描述只能补充意图，不能代替接口契约。

4. 写操作是否幂等

发消息、建工单、改库存等动作必须带 idempotency_key。网络超时后先查询动作是否已发生，再决定是否重试。

5. 是否有限额与速率控制

至少限制单次金额、每日总额、对象数量、调用频率和执行时间窗。异常放量时自动降级为只读或等待审批。

6. 是否有确定性验收

不要让模型自己宣布“任务完成”。用字段、金额、引用、状态和外部系统回执判断是否成功，关键断言未通过就不能进入完成状态。

7. 是否能回放、补偿和转人工

系统应记录输入快照、策略版本、工具请求与响应、副作用状态和验收结果。失败后要能从断点继续、执行补偿，或把完整上下文交给人工。

三、出现这三种情况，先别开写权限

1. 任务结果无法被规则或人工样本复核；
2. 写操作既不幂等，也没有查询是否成功的接口；
3. 错误发生后没有回滚、补偿或人工接管路径。

上线试点可以先跑 14 天，只观察四个数：无需重做的成功率、写入错误率、人工审批通过率和平均恢复时间。只有结果可验证、净节省工时为正、失败可恢复，才继续扩大权限范围。

写权限不是一次性开关，而是一组可以逐级授予、随时收回的能力。真正可用的 Agent，不是“什么都敢做”，而是在边界内稳定完成任务，并且每一步都可追踪、可验证、可恢复。

利益相关说明：我们正在开发 TotalClaw，方向是多角色 Agent 的任务分解、最小权限执行、确定性验收与失败回放。产品能力与在线体验：

https://taituai.com/?utm_source=csdn&utm_medium=article&utm_campaign=agent_write_permission_guardrails&utm_content=article_04