团队一旦开始让 Agent 自主执行真实动作，就会很快发现一个尴尬事实：问题不在于“要不要自动化”，而在于“哪些动作可以自动化到什么程度”。同样是一次模型输出，草拟一封内部回复和直接给客户退款，风险完全不是一个量级；同样是一次工具调用，查询工单状态和修改客户权限，业务后果也完全不同。NIST 的 AI 风险管理框架，以及 Anthropic 关于 prompt leak 与 jailbreak 缓解的文档，都在提醒同一件事：自治边界应该由动作风险决定，而不是由模型能力、团队热情或产品上线节奏决定。
对 TaskPilots 这类需要连接真实业务系统、真实权限和真实责任的 Agent Studio 来说，风险分级不是一张挂在墙上的矩阵，而是系统运行时的控制规则。它应该明确回答四个问题：当前动作属于哪一档风险、这一档能否自动执行、是否必须触发审批或人工接管、以及即使被越狱或提示注入命中，损害上限会被限制在哪里。只有先把这些边界写清楚，团队才能让 Agent 安全地获得更多自治，而不是每次出事后再回头补流程。
为什么这个问题重要
自治风险真正来自动作，不来自回答长度
很多团队最初会按任务类型讨论风险，比如“客服场景风险高”“内部知识问答风险低”，但真正决定后果的通常不是场景名，而是动作本身。一个看似普通的客服流程里，可能同时包含低风险的状态查询、中风险的模板建议、高风险的补偿承诺和极高风险的退款执行。如果不按动作分级，系统就容易在同一条链路里把所有步骤用同一套权限和同一套拦截规则处理，结果不是过度阻断，就是误放行。
- 能读到什么，决定了信息泄露风险。
- 能改动什么，决定了业务副作用风险。
- 能代表谁承诺什么，决定了法律与合规风险。
没有分级，护栏会变成一刀切
Anthropic 对减少 prompt leak 和缓解 jailbreak 的建议，都强调要把敏感上下文、工具权限和执行边界分层处理。如果团队没有先定义风险层级，最常见的结果就是把所有请求都压在同一种护栏上。护栏过重时，低风险动作也要排队审批，系统几乎失去自治价值；护栏过轻时，高风险动作又会被混进自动化通道。真正可持续的做法，是先按风险给动作分类，再为每一档定义不同的权限、校验和人工介入要求。
适用场景
哪些团队最需要动作级风险分档
最需要做这件事的，是那些 Agent 已经不只是“给建议”，而是在操作真实系统的团队。典型场景包括客服补偿与退款、对外邮件回复、CRM 更新、工单升级、内部权限开通、财务异常处理，以及会调用第三方系统写入数据的运营链路。这些流程共同的问题，不是模型能不能答对，而是系统有没有能力在每一步判断“现在允许自动做多少”。
哪些阶段可以先用简化版
如果当前系统仍停留在草稿生成、知识检索、人工逐条终审、没有直接副作用的阶段，当然也可以做风险分级，但不必一开始就设计复杂的五层或七层模型。更合理的起点，是先区分三类动作：只读、可逆写入、不可逆或高责任写入。只要这三类先分清，后续再逐步补足更细的审批、证据和限权规则，团队就不会在原型期背上过重流程。
推荐系统结构
先定义一套围绕动作的风险分级
比起按业务线、按团队或按模型来分级，更稳妥的做法是直接围绕动作设计风险层。一个实用的四档模型可以这样定义：第一档是建议级，只允许生成草稿、摘要或分类结果，不产生任何外部副作用；第二档是受限执行级，允许只读查询、可撤销更新或在严格模板内执行低影响动作；第三档是审批执行级，涉及客户承诺、敏感数据、跨系统写入或财务影响，必须先过策略评估与人工确认；第四档是禁止自治级，涉及高金额支付、权限授予、合同变更、法律承诺等动作，Agent 只能收集上下文和建议，最终必须由人主导处理。
这套分级的关键，不在档位名称，而在判断标准是否清楚。建议至少同时看五个维度：影响范围、可逆性、敏感性、身份代表性和攻击面。影响范围看动作会波及多少用户或系统，可逆性看错误后能否低成本回滚，敏感性看是否触及个人数据、财务或权限，身份代表性看是否在代表公司对外承诺，攻击面则看该动作是否容易被提示注入、越狱或上下文污染误触发。
把风险分级直接绑定到权限和审批
风险档位不应该只停留在文档里，而要直接驱动运行时行为。每一档至少要绑定四类控制：可用工具范围、可访问数据范围、是否允许自动执行、是否要求人工审批。比如建议级可以拿到有限上下文但没有写权限；受限执行级可以访问少量业务工具，但只能在参数白名单内操作；审批执行级必须在策略服务判定通过后进入人工确认；禁止自治级则连短时执行令牌都不应该发放。这样做能确保即使模型判断出错，损害上限也被控制在当前风险档位内。
把 TaskPilots 的治理面做成风险控制面
映射到 TaskPilots，可以把 Agent Studio 里的角色、工具集、知识源、审批节点和人工接管节点全部按风险档位组织起来。路由 Agent 先判断动作意图与风险等级，执行 Agent 再根据档位拿到最小必要工具，审批节点保留策略版本和放行理由，人工接管则继承完整上下文而不是从零开始。像 审计友好的人工接管，需要留下哪些证据 和 企业 Agent 的 Jailbreak 缓解应该落在哪一层 讨论的证据链与整栈护栏，也都应该按风险档位配置，而不是对所有动作一视同仁。
风险与失效点
最常见的失误是按场景分级，不按动作分级
生产环境里最常见的偏差，是团队用“客服流程”“销售流程”“内部助手”这样的标签来做分级，结果把同一条链路里高低风险差异巨大的动作混在一起。这样一来，系统要么把低风险动作也锁死，要么让高风险动作顺着低风险流程滑过去。另一类常见问题，是风险等级在文档里定义了，但没有同步到工具权限、审批策略和日志字段中，最后变成一套人人看过、运行时谁也没用的制度。
- 只按团队分级，会掩盖同一团队内部动作的巨大差异。
- 只按输入分级，会忽略执行阶段的真实副作用。
- 只按模型输出分级，会漏掉工具调用和外部写入风险。
高风险动作最怕被“顺手自动化”
另一种失控方式，是团队先让系统在低风险动作上跑通，然后为了体验顺滑，把高风险动作也一点点塞进同一条自动化路径里。例如先允许 Agent 草拟补偿方案，后来又允许它直接提交补偿申请，再后来甚至允许它在阈值内自动发放。每一步单看都像合理优化，但如果没有重新评估风险等级、攻击面和证据要求，系统就会在“本来只是建议”的外壳下悄悄获得高风险执行能力。
验证指标
上线前先验证分级是否真能改变运行路径
上线前不要只检查风险矩阵写得漂不漂亮，而要验证同一条链路在不同档位下是否真的会走出不同路径。建议至少准备三类测试：第一类是边界样本，确认低风险和高风险动作不会被判到同一档；第二类是越权样本，确认高风险动作即使被诱导也拿不到超范围工具；第三类是回放样本，确认审批和人工接管只在应触发的档位出现。只有运行路径真的随风险变化，分级才不是纸面制度。
上线后持续看拦截质量与业务摩擦
生产阶段至少要长期跟踪五类指标：风险分类准确率、审批命中率、误放行率、误伤率和高风险动作审计完备度。前两项衡量分级是否把动作送进了正确通道，中间两项判断护栏是否过松或过紧，最后一项确保高风险动作即使进入人工路径也留下完整证据。除此之外，最好再补一项“高风险动作自动化占比变化”，因为这能帮助团队识别自治边界是否在没有重新评估的情况下被慢慢扩张。
- 分类准确率低，说明分级标准或样本定义仍然模糊。
- 审批命中率异常高，说明过多中低风险动作被推给人工。
- 误放行率上升，说明高风险动作正在绕开本应存在的控制点。
下一步 / FAQ
下一步先做一张动作清单，而不是先写制度
最实际的第一步，不是先开会讨论“我们要不要做风险治理”，而是先把当前 Agent 真正会做的动作列出来，再逐条标注影响范围、可逆性、敏感性、身份代表性和攻击面。只要这份动作清单出来，很多团队就会立刻发现，自己原本以为的“一个功能”其实包含了四五种风险完全不同的动作。先把动作拆开，再谈分档、审批和最小权限，推进会顺得多。
FAQ：风险档位需要做得很细吗
不一定。比起一开始设计八档十档，通常更重要的是先让每一档都能映射到清晰的运行规则。档位太多但规则不清，效果往往不如三到四档、每档都有明确权限和审批条件的模型。
FAQ：同一个请求能跨多个风险档位吗
可以，而且在生产环境里很常见。关键是不要按请求整体取平均风险，而要按动作拆分。例如同一条客服请求里，查询状态可以自动做，草拟回复可以自动做，但退款执行必须升级审批。
FAQ：风险分级会不会拖慢交付
前期会增加一些建模和治理成本，但通常会换来更少的事故和更快的放权决策。没有风险分级时，团队往往只能在“全自动”与“全人工”之间来回摇摆，长期反而更慢。