Wiki Notes

Appearance

风险分层路由专题 ​

版本：v1.1

最后更新：2026-07-08

适用对象：需要让不同风险请求走不同模型、工具、审批和执行链路的产品、研发、平台与治理同学

很多 AI 系统一开始只有一种处理路径：

  • 所有请求走同样的模型
  • 所有动作走同样的审批
  • 所有风险走同样的防线

但一旦业务变复杂，这种“一刀切”很快就会遇到瓶颈。

根据 2026-07-08 可访问的 OpenAI Building agents、Guardrails and human review、Anthropic Ticket routing、NIST AI RMF Playbook 等资料，可以先建立一个关键共识：

  • 风险分层路由的价值不在“给请求打标签”，而在于让不同风险自动走到不同的模型、工具、审批和兜底路径。

1. 什么是风险分层路由 ​

更实用的理解通常是：

  • 先判断请求或任务的风险等级
  • 再把它路由到不同的模型、工具、审批或执行链路

重点不是“分类本身”，而是：

  • 不同风险走不同处理路径

1.1 分层路由的目标不是把所有请求都变安全 ​

而是：

  • 让低风险路径尽量高效
  • 让高风险路径尽量可控

1.2 分层之后才可能谈“既快又稳” ​

否则团队通常只能在两个极端里选一个：

  • 全部请求都走重型高成本链路
  • 或全部请求都走轻量高效率链路

两者都不可持续。

2. 为什么不能所有请求都走同一条链路 ​

因为不同任务的风险和成本完全不同：

  • 有些只是低风险问答
  • 有些涉及敏感知识访问
  • 有些会触发真实外部动作

如果全走同一条链路，通常会出现两种结果：

  • 要么过度保守，效率太低
  • 要么过度放开，风险太高

2.1 单一路径会把高风险问题藏在普通流量里 ​

结果就是：

  • 平均指标还不错
  • 高风险误放却越来越难发现

2.2 单一路径也会让低风险请求被高风险规则拖慢 ​

例如：

  • 普通 FAQ 也要走强审
  • 低风险查询也要高价模型

这会明显降低系统性价比。

3. 哪些对象最适合先做风险分层 ​

更适合优先分层的通常包括：

  • 用户请求类型
  • 工具调用动作
  • 知识访问范围
  • 输出是否对外发送
  • 是否涉及金钱、合同、审批或权限

3.1 请求语义本身 ​

例如：

  • 普通知识问答
  • 风险建议
  • 操作性请求
  • 需要外发的内容

3.2 动作对象 ​

例如：

  • 查询
  • 导出
  • 修改
  • 删除
  • 外发

3.3 数据与知识范围 ​

例如：

  • 公共知识
  • 内部知识
  • 敏感知识
  • 多租户隔离知识

3.4 组织与审批边界 ​

例如：

  • 是否需要 manager approval
  • 是否需要法务 / 财务 / 安全确认

4. 一个更实用的分层方式 ​

可以先按三层来做：

4.1 低风险路由 ​

典型对象：

  • 普通问答
  • 只读检索
  • 低影响任务

典型策略：

  • 低成本模型
  • 开放只读工具
  • 自动执行

4.2 中风险路由 ​

典型对象：

  • 需要更稳结构化输出的任务
  • 需要额外校验的任务
  • 涉及内部数据但不直接触发高风险动作的任务

典型策略：

  • 更稳模型
  • 更严 guardrails
  • 更少工具
  • 更多结构校验

4.3 高风险路由 ​

典型对象：

  • 涉及审批、权限、合同、金钱、外发、敏感数据导出的任务

典型策略：

  • 更稳模型
  • 收缩工具面
  • 只读降级
  • 人工审批或人工复核

这样做的核心不是标签数量，而是：

  • 每一层对应的处理策略是否明确

5. 风险分层为什么必须和模型、工具、审批一起设计 ​

很多团队只做了“风险打标”，却没有真正改变执行路径。

更稳妥的设计通常会把风险等级映射到：

  • 可用模型
  • 可用工具
  • 是否允许自动执行
  • 是否要求人工审批
  • 是否收缩上下文范围

否则分层只会停留在看板层。

5.1 模型层的映射 ​

例如：

  • 低风险走低成本模型
  • 高风险走更稳、更保守的模型

5.2 工具层的映射 ​

例如：

  • 低风险开放只读工具
  • 高风险关闭写工具或必须先审批

5.3 审批层的映射 ​

例如：

  • 低风险无需人审
  • 中风险二次确认
  • 高风险人工批准

6. 风险识别最好结合规则、模型和历史事故 ​

只靠一种方式识别风险，通常都不够稳。

更常见的三类信号来源通常是：

6.1 规则信号 ​

例如：

  • 是否涉及支付、合同、权限、外发消息
  • 是否命中敏感知识域
  • 是否包含导出、删除、修改等动作词

6.2 模型判断 ​

例如：

  • 当前请求是否包含模糊高风险意图
  • 是否存在角色扮演、规避审批或越权迹象

6.3 历史事故与失败样例 ​

例如：

  • 哪些场景过去经常误放
  • 哪些 query 经常投诉
  • 哪些工具经常被误调

OpenAI 当前 Building agents 和 Guardrails and human review 的资料都在强调：

  • 自动校验适合做前置筛查
  • 真正敏感动作仍应进入人工确认

这和风险分层的结构高度一致。

7. 风险分层真正有价值，在于把标签映射成执行动作 ​

很多团队做了风险分级，但最后只停留在看板里：

  • 这条请求被标成高风险
  • 然后系统实际还是走原来那条路径

这就失去了分层路由最核心的价值。

更实用的做法通常是把风险等级直接映射成执行动作，例如：

风险层级典型执行动作
低风险用低成本模型、开放只读工具、自动执行
中风险提升 guardrails、收缩工具面、增加结构校验
高风险改用更稳模型、限制工具、要求审批或人工复核

7.1 标签系统不等于路由系统 ​

必须明确：

  • 标签是谁算的
  • 算完怎么影响路径
  • 路径改变后是否被审计

7.2 最小闭环应该是“识别 -> 路由 -> 观察 -> 调整” ​

而不是只有“识别”。

8. 风险分层不只看安全，还要看成本、品牌和业务流程风险 ​

风险不只是安全和合规，还可能包括：

  • 成本风险
  • 品牌风险
  • 业务流程风险
  • 用户体验风险

8.1 成本风险 ​

例如：

  • 某些任务不值得走高价高推理模型

8.2 品牌风险 ​

例如：

  • 对外消息生成
  • 对客户承诺话术

8.3 流程风险 ​

例如：

  • 自动改工单状态
  • 自动改权限
  • 自动发审批结论

如果只从单一安全视角设计，很多真实业务问题会被漏掉。

9. 风险分层和模型路由最好联动，而不是各自独立 ​

模型路由决定：

  • 哪个模型处理哪类任务

风险分层决定：

  • 哪类任务需要更保守的处理链

这两者如果分开做，就容易出现：

  • 成本最优的模型路线
  • 和风险最优的治理路线

互相打架。

9.1 低风险任务更适合轻路由 ​

例如：

  • 小模型
  • 短上下文
  • 自动完成

9.2 高风险任务更适合稳路由 ​

例如：

  • 更保守模型
  • 更少工具
  • 更强 schema
  • 更高人工参与度

9.3 这也是为什么路由策略必须带风险上下文 ​

否则模型路由只能看：

  • 成本
  • 延迟

看不到：

  • 放错的代价

10. 工具权限和审批边界也要跟着风险层级变化 ​

风险分层之后，最应该同步变化的通常就是：

  • 工具权限
  • 审批门禁

10.1 低风险层 ​

可开放：

  • 只读工具
  • 低副作用结构化提取

10.2 中风险层 ​

更适合：

  • 更少工具
  • 参数严格校验
  • 明确二次确认

10.3 高风险层 ​

更适合：

  • 人工批准
  • 只读降级
  • 默认阻断写动作

如果这一步不做，风险分层很容易变成：

  • 只换了模型
  • 没收紧动作

11. 高风险误放和低风险误拦，要分开观测 ​

风险路由上线后，最值得关注的两类错误不是同一类问题。

11.1 高风险误放 ​

后果通常更重：

  • 越权
  • 漏审
  • 错发
  • 错写

11.2 低风险误拦 ​

后果通常是：

  • 体验差
  • 成本高
  • 效率低

这两类问题不该混在一个“路由准确率”里看。

11.3 更好的观测方式 ​

至少拆开看：

  • 高风险误放率
  • 高风险漏审率
  • 中风险过度升级率
  • 低风险误拦率

12. 风险路由的兜底路径，最好默认保守而不是默认继续 ​

当风险识别不确定、上下文不足或策略冲突时，默认行为非常重要。

更稳妥的做法通常是：

  • 默认保守

例如：

  • 收缩工具
  • 转人工
  • 只读回答
  • 要求补充信息

而不是：

  • 继续自动执行

12.1 什么时候最该默认保守 ​

例如：

  • 高敏工具
  • 多租户边界不清
  • 审批条件模糊
  • 用户意图不明确

12.2 默认保守并不代表系统“太笨” ​

它只是把：

  • 高代价错误

优先级放在了：

  • 低摩擦体验

之前。

13. 风险分层需要持续从事故、投诉和评测中校准 ​

风险分层不是一次定好的静态规则。

更好的做法通常是：

  • 用历史失败样例和事故样例定义风险边界
  • 观察不同分层的误放与误拦表现
  • 持续调整分层规则与路由策略

13.1 哪些输入最值得回流 ​

例如：

  • 红队失败样例
  • 线上投诉
  • 审批绕过事件
  • 越权召回事件

13.2 路由规则也应该有版本与回滚 ​

否则分层一旦改坏，很难知道是哪条策略导致的。

14. 常见反模式 ​

14.1 只做风险打标，不改执行路径 ​

这几乎等于没做。

14.2 只从安全角度分层 ​

却忽略成本、品牌和流程风险。

14.3 分层规则完全写死，不做回流 ​

这样系统会越来越脱离真实业务风险。

14.4 高风险和低风险共用同一工具面 ​

这样风险标签就失去了意义。

14.5 默认继续执行，而不是默认保守 ​

这是很多事故的根因之一。

15. 推荐搭配阅读 ​

16. 重点官方资源 ​

17. 落地检查清单 ​

  • 是否定义了低/中/高风险层级
  • 风险标签是否真正映射到模型、工具和审批路径
  • 是否区分高风险误放与低风险误拦
  • 是否定义默认保守兜底路径
  • 是否把红队、事故和投诉样例回流到路由规则
  • 路由策略是否有版本与回滚能力