操作分级

一句话理解：不是所有动作都一样危险——查询可以放手，发送要先看，动钱和删除必须有人批准；操作分级就是把“Agent 能做什么”变成一张可以评审的表。

当 Agent 只会回答问题时，最坏的结果是答错；当它能调接口、发消息、改状态、退款时，最坏的结果是 做错。而做错的代价差异极大：查错一个订单号，重查一次就好；给错客户退了五万块，可能再也追不回来。

很多团队在这里走两个极端：要么什么都要确认，用户被弹窗烦死，最后闭眼全点“同意”；要么为了体验流畅全部自动执行，直到出第一次事故。操作分级是介于两者之间的方法：先给每个动作定级，再按级别决定自动执行、事后可见、事前确认还是审批。

七级动作

从风险最低到最高，Agent 的动作大致可以分成七类：

级别	类型	例子	可逆性	默认策略
R1	查询	查订单、查库存、读文档、搜索	无副作用	自动执行
R2	分析	汇总数据、生成诊断结论、在沙箱里算指标	无副作用	自动执行，结论附证据
R3	草稿	起草邮件、生成工单草稿、准备退款申请	未生效，随时丢弃	自动执行，交给人查看
R4	发送	发邮件给客户、在群里通知、回复评论	发出即不可撤回	事前确认（或在白名单内自动）
R5	写入	改订单状态、更新 CRM、合并代码、改配置	通常可以改回，但可能已触发下游	按范围分级：低影响自动，高影响确认
R6	资金	退款、付款、结算、调整价格与额度	很难或无法撤回	审批，叠加金额上限
R7	删除与破坏性操作	删除数据、注销账号、生产环境迁移、强制推送	往往不可逆	审批 + 预演 + 备份，或直接禁止

这张表的直觉很简单：前三级只影响 Agent 自己的“草稿纸”，从第四级开始影响真实世界。 很多 Agent 产品的第一版，完全可以只开放 R1–R3，让 Agent 先证明判断力，再逐步开放执行权。这与 自主性等级 是同一个思路。

把七级画成一道阶梯，分界线就很清楚：

定级看的不只是动作类型

同一个“退款”动作，50 元和 50000 元显然不是一个级别。定级时至少要看五个因素：

因素	问题	升级信号
可逆性	做错了能撤回吗？撤回成本多大？	无法撤回、撤回需要对方配合
影响范围	影响一条记录还是一批？一个用户还是所有用户？	批量操作、全局配置
对外可见性	只有内部看到，还是客户、合作方、公众会看到？	对外发送、公开发布
金额与合规	是否涉及资金、合同、个人信息？	超过金额阈值、涉及敏感数据
上下文可信度	这个决定依据的信息来自哪里？	依据来自外部邮件、网页等不可信来源

最后一条经常被忽略：如果 Agent 决定退款的理由来自客户邮件里的一句话，那么这次退款的风险比依据系统记录做出的退款更高，因为邮件内容可能是被操纵的。详见 Prompt 注入。

所以更实用的定级方式是 “动作类型定基准级，参数和上下文负责升级”：

注意“降级”条件是由程序根据系统数据判断的，而不是模型自己宣称“这笔金额很小”。具体怎么落地，见 程序校验优先。

实战：给订单售后 Agent 定级

以实战项目「可执行的售后处理 Agent」为例，把它的全部动作列出来：

动作	级别	策略	说明
查询订单、支付记录、历史工单	R1	自动	只读工具
判断问题原因	R2	自动	必须引用查询到的数据作为证据
起草给客户的回复	R3	自动	草稿进入待发送列表
创建内部工单	R5（低影响）	自动，事后可见	工单可关闭，影响小
在工单里给同事留言	R4	模板内自动，自由文本需确认	对内沟通，但会留痕并触达他人
发邮件给客户	R4	确认	对外、不可撤回
修改订单状态	R5	确认	会触发发货、开票等下游流程
发起退款	R6	按金额分级审批	见上面的规则
补发商品或发放优惠券	R6	审批	实质等同于资金支出
批量关闭工单	R5（批量）	预演 + 确认	先展示将被关闭的清单
删除订单或客户数据	R7	禁止	Agent 不提供该工具

这张表本身就是一份很好的需求评审材料：业务、法务、财务都能看懂，也都能提意见。

几个设计经验：

• “禁止”最好的实现方式是不给工具。与其在提示词里写“不要删除订单”，不如根本不提供删除工具，见 安全的工具设计。
• 批量操作要单独定级。单条可以自动的动作，一次改一千条就是另一回事。
• 分级会随信任积累而调整。上线初期保守，通过线上数据证明准确率后，再把部分动作从“确认”调整为“自动 + 抽查”。

常见误区

• “按工具定级就够了。” 同一个工具因参数不同风险可以相差千倍，必须结合参数和上下文。
• “所有写操作都要确认才安全。” 确认过多会导致审批疲劳，用户不再认真看，安全反而下降。
• “让模型自己判断风险高不高。” 模型的判断可以作为参考信号，但分级规则必须由程序执行，否则一次注入就能让它“觉得”风险很低。

产品经理检查清单

• Agent 的全部动作是否都列出来了，包括通过通用工具（如执行 SQL、调用任意 API）间接获得的能力？
• 每个动作的基准级别是什么？哪些参数会让它升级？
• 哪些动作应该直接不提供，而不是“提供但要求确认”？
• 批量操作是否单独定级，并设置了数量上限？
• 分级规则由谁维护？调整分级需要经过谁同意？
• 每一级的动作是否都有日志，出事时能追溯是谁、依据什么、批准了什么？

练习

为「销售分析 Agent」或你自己负责的 Agent 做一次完整的操作分级，用 45–60 分钟：

1. 列出 Agent 所有可能的动作，至少 10 个。
2. 为每个动作定基准级别，并写出至少一个会让它升级的条件。
3. 标出哪些动作应该直接删除工具。
4. 找一位业务同事评审这张表，记录他不同意的地方。

延伸阅读

• OWASP：LLM06:2025 Excessive Agency——把“过度代理”拆成功能过多、权限过大、自主性过高三个根因。

下一步

定好了哪些动作需要人参与，下一课「Human-in-the-loop」讨论人具体怎么参与：审批、确认、中断与接管分别适合什么场景。