很多自动化事故不是 Agent 完全不知道答案，而是它只有六七成把握，却被流程设计推着继续执行。用户说得含糊，资料互相冲突，工具返回异常，权限边界不清，最后 Agent 还是往下写入系统，问题就会被放大。
低置信度请求分流的目的，是把“拿不准”变成明确去向，而不是让 Agent 装作确定。它可以和 意图识别置信度、质量门禁、人工接管台 连在一起。
先定义什么叫低置信度
低置信度不只来自模型分数。用户目标不完整、关键字段缺失、知识库出现两种口径、工具调用失败、权限不足、高风险动作没有审批，都应该被视为低置信度信号。
如果只看模型自己说“我有把握”，分流会很脆。生产系统里更可靠的是多信号判断：输入是否清楚，证据是否一致，工具是否成功，动作是否越权。
不同原因要分到不同队列
低置信度不能全部扔给人工。意图不清的请求应该追问用户，资料冲突的请求应该进入知识库修订，权限不足的请求应该走授权流程，工具失败的请求应该进入技术排查，高风险动作应该进入审批队列。
这样做的好处，是人工不再面对一堆“请确认”的模糊任务，而是知道自己要补资料、补权限、修工具，还是做风险判断。
回复用户时要说清状态
低置信度分流不代表用户体验一定变差。真正糟糕的是 Agent 给出一个看似确定但其实不可靠的答案。更好的做法是告诉用户：当前缺少哪些信息，已经转到哪个队列，预计下一步是什么。
这和 SLA 分层 有关。不同低置信度类型，可以有不同响应时限和升级路径。
分流结果要反哺知识库和流程
如果某类低置信度请求反复出现，就说明上游有问题。可能是知识库缺口，可能是表单字段设计不清，也可能是工具返回格式不适合模型理解。
前面写过 知识库问答抽检。低置信度样本正适合进入抽检池，因为它们比成功样本更能暴露真实边界。
总结
用 AI Agent 做低置信度请求分流，关键不是让模型更敢答，而是让它在拿不准时有明确去向。追问、补资料、补权限、修工具、人工审批分清楚，执行流才不会被不确定性拖垮。
