风险路由
在 Agent 产品中，根据请求内容、用户身份、操作类型、可撤回性和历史异常动态决定护栏强度、是否审核、是否转人工的产品机制。
简介
风险路由是 Agent 产品从“统一对话体验”走向“生产级行动系统”的关键机制。传统软件路径固定，按钮、权限和流程大多在设计时已经确定；Agent 产品不同，用户一句自然语言可能只是闲聊，也可能触发查询、生成、审批、下单、发邮件、导出数据或修改业务状态。系统如果把所有请求都当成低风险聊天，就会在真实业务里越权；如果把所有请求都当成高风险审批，又会让简单问题变慢、成本变高、体验变笨。
2026-07-07-woshipm-agent-safety-guardrails 提出的解法是：产品经理需要设计一个风险路由机制，让系统先判断这次请求的风险分数，再决定走哪条路径。低风险请求可以快一点，中风险请求要检查，高风险请求要停下来确认。它背后的产品原则是：不要让所有用户为少数高风险场景买单，也不要让高风险场景套用低风险体验。
风险路由不是单纯的技术分类器，而是产品策略、权限体系、护栏强度和用户体验的交汇点。它把“这次 Agent 应该多自主”变成可执行的路由决策：是直接回答、边输出边异步校验、输出前基础校验、完整语义校验、二次确认，还是直接转人工。
关键信息
| 维度 | 内容 |
|---|---|
| 类型 | Agent 产品治理与动态决策机制 |
| 核心问题 | 如何让不同风险等级的请求进入不同护栏和体验路径 |
| 输入维度 | 用户问题、用户身份、操作对象、结果可撤回性、历史异常行为 |
| 输出动作 | 快速响应、异步检查、输出前校验、完整审核、二次确认、转人工 |
| 相关页面 | Agent安全护栏、可撤回性原则、AI产品PRD、AI评估计分板、人机协同 |
核心特性
一、从“统一流程”变成“按风险分流”
风险路由的第一价值是避免两个极端：一是所有请求都低风险处理，导致 Agent 在钱、健康、法律、隐私、权限和外部承诺上越界；二是所有请求都高风险处理，导致 FAQ、内部知识查询、普通总结也要等待重审核，最终用户不愿使用。
合理的做法是让低风险任务走快速路径，让中风险任务走校验路径，让高风险任务走确认或人工路径。比如内部知识库问“年假怎么申请”，回答不完整也可后续纠正，可以流式输出并后台异步检查；金融顾问 Agent 面对“我该不该买这只基金”，则涉及真实交易和监管红线，必须把建议边界、风险提示和人工确认前置。
这使得 Agent 体验不再是一个全局配置，而是一张风险路径图。产品经理要定义不同路径的触发条件、用户提示、等待体验、失败回退和复盘指标。
二、风险分数来自多个维度，而不是关键词命中
原文给出五类判断维度：
- 用户在问什么：是否涉及钱、健康、法律、隐私、权限、外部承诺。
- 用户是谁：普通用户、内部员工、管理员、未授权访客。
- Agent 要操作什么：只是回答，还是要调用工具、修改数据、触发交易。
- 结果能否撤回：聊天回答可以纠正，邮件、支付、合同、审批往往不能撤回。
- 历史上是否异常：用户是否多次尝试绕过规则，或输入明显诱导模型越权的内容。
这五类维度说明风险路由不能只靠关键词。比如“退款”本身可能是普通政策咨询，也可能是实际发起退款操作；“合同”可能只是解释条款，也可能生成对外法律意见；同样是“导出数据”，管理员在内部系统和未授权访客在公开入口的风险完全不同。风险路由必须综合意图、身份、操作和可撤回性。
三、路由结果决定护栏强度和产品体验
风险路由的输出不是一个抽象分数，而是一条具体处理路径。典型路径包括：
| 路由结果 | 适用场景 | 产品体验 |
|---|---|---|
| 快速响应 | 低风险知识查询、普通总结 | 可流式输出，必要时后台异步检查 |
| 基础校验 | 客服、售后、商品信息、品牌话术 | 输出前检查敏感信息、格式、口径和语气 |
| 完整语义校验 | 高风险专业建议、强上下文判断 | 用大模型或专家规则检查依据、一致性和风险边界 |
| 二次确认 | 发邮件、退款、下单、审批、修改资料 | Agent 准备草稿或建议，人确认后执行 |
| 转人工 | 高合规风险、低置信度、知识库无答案、连续校验失败、用户情绪激烈 | 保留上下文并交给人类处理 |
这种路由与 Agent安全护栏 的三层护栏天然配套：规则型护栏适合高频确定性检查，模型分类护栏适合意图和内容风险分流，大模型语义校验适合少数高风险节点。
四、风险路由必须写进 PRD 和指标体系
风险路由不是研发自己写一个分类器就结束。PM 需要在 AI产品PRD 中写清风险等级、触发条件、路由路径、用户提示、失败回退和复盘指标。尤其要定义哪些操作需要二次确认、哪些场景必须转人工、哪些输出必须带依据。
同时，风险路由需要进入 AI评估计分板 或运营看板：护栏命中率是否过高、误拦是否影响体验、漏拦是否造成真实风险、人工接管比例是否异常、响应延迟是否导致用户放弃。没有指标，风险路由就会变成黑盒；有指标，团队才能在“安全”和“体验”之间持续调优。
不同素材中的观点
来自 2026-07-07-woshipm-agent-safety-guardrails：
- Agent 产品真正难的地方在于路径不像传统软件那样固定。用户一句话可能只是闲聊，也可能触发查询、生成、审批、下单、发邮件、改数据。
- 风险路由应先判断这次请求的风险分数，再决定走哪条路径。低风险请求可以快一点，中风险请求要检查，高风险请求要停下来确认。
- 判断维度包括用户在问什么、用户是谁、Agent 要操作什么、结果能否撤回、历史上是否异常。
- 产品原则是：不要让所有用户为少数高风险场景买单，但也不要让高风险场景套用低风险体验。
实用信息
最小风险路由表
| 风险等级 | 判断条件 | 路由动作 | 用户体验 |
|---------|----------|----------|----------|
| L1 低风险 | 普通知识查询、内部 FAQ、低敏感总结；不调用高权限工具；结果可撤回 | 快速响应 + 异步检查 | 流式输出，必要时提示“已根据内部资料回答” |
| L2 中风险 | 客服/售后/商品/政策；可能影响用户权益但通常可纠正 | 输出前基础校验 | 稍慢，但检查口径、格式、敏感信息和品牌语气 |
| L3 高风险 | 医疗、金融、法律、人事、支付、审批、外部发信、数据修改；不可撤回或高代价 | 完整校验 + 二次确认/转人工 | Agent 给建议或草稿，人类确认后执行 |设计检查清单
- 是否区分“回答问题”和“执行操作”？
- 是否区分普通用户、内部员工、管理员和未授权访客？
- 是否识别结果可撤回与不可撤回？
- 是否定义了低置信度、无答案、连续失败时的转人工路径？
- 是否记录每次路由原因，便于复盘误拦和漏拦？
- 是否把路由指标纳入产品运营看板？