知识层做起来之后，很多团队会很自然地走向一个默认策略：先搜知识库，再看看要不要调工具。这个顺序在演示里很顺，因为检索便宜、可解释、出结果也快。可一旦系统面对的是实时库存、当前审批状态、尚未明确的用户目标，或者需要高 freshness 证明的高风险回答，这种“先搜再说”的顺序就会开始持续制造错觉。系统不是完全不会回答，而是会给出一种看起来足够像答案、实际上却不该在这一刻被当成最终依据的东西。
所以真正成熟的 agent 不应该只有 retrieval，它还需要 retrieval policy router。这个 router 负责回答的不是“去哪搜”，而是“这次问题到底应该先用哪类证据、花多少证据预算、在哪个点停下来追问、以及什么时候干脆不该答”。只要这一层不存在，Knowledge Plane 的效果越强，系统越容易把不适合用知识库解决的问题也往知识库方向硬拽。
换句话说，router 的价值不在于复杂，而在于节制。它让 agent 不再把“我可以从历史材料里推一个像样的解释”误当成“我已经有资格做当前这次判断”。这在高风险流程里，是非常关键的差别。
建议配合 AI agent Corpus Freshness SLA、AI agent Access-Controlled Retrieval、AI agent Tool Capability Negotiation 和 AI agent Retrieval Gap Heatmap 一起看。
先给结论：Router 不是在“知识库和工具之间二选一”，而是在决定当前 run 的证据策略
| 问题类型 | 默认应该优先什么 | 为什么 |
|---|---|---|
| 稳定解释类问题 | 知识库 / canonical source | 主要目标是解释既有规则和定义 |
| 实时状态类问题 | 工具 / live system | 旧知识即使语言上对，也可能事实已过期 |
| 目标不明确的问题 | 追问 / clarify | 先补约束比盲搜更稳 |
| 高风险决策问题 | 组合证据或人工确认 | 单一路径很容易在 freshness 或权限上失足 |
也就是说，router 管的不是搜索引擎入口，而是一次 run 的证据预算和风险姿态。很多 agent 看起来像“检索能力不够”，真正缺的其实是这一步：系统没有判断当前问题究竟适不适合先去检索。
Router 至少要同时看五个输入，而不是只看问题文本
一个可运营的 retrieval router，至少应该把下面五类信号并列看待：
| 信号 | 它会改变什么 |
|---|---|
| task intent | 是解释、查询、决策、写入前校验还是异常排查 |
| freshness requirement | 允许使用历史知识，还是必须要 live state |
| risk level | 如果答错，代价是轻微误导还是直接业务损失 |
| authority scope | 当前会话能合法消费哪些 evidence 类别 |
| latency / token budget | 这次 run 是否承受得起深检索、多路证据或工具调用 |
只要 router 还在按“输入像不像知识问答”来决定路径，它迟早会把那些本该去查实时状态或先追问用户的问题，错误地塞回知识库里。这样系统得到的不是一个完全错误的结果，而是一个极其容易让人放松警惕的次优结果。
真正的 evidence budget，不只是 top-k，而是“愿意为这次判断付出多少证据成本”
很多团队把 evidence budget 理解成检索参数，比如 top-k 是 4 还是 8。更实用的理解是：这次 run 到底允许为了判断去消费多少证据类型、多大时延、多少 token 和多少复杂度。
| 预算策略 | 适合什么 | 风险 |
|---|---|---|
| 轻预算 | FAQ、低风险解释、短时延场景 | 复杂问题容易因为证据不足而过早回答 |
| 中预算 | 一般业务说明、需要两三类来源印证 | 如果没有 router，常被滥用到所有问题 |
| 重预算 | 高风险决策、争议仲裁、外发前校验 | 延迟和成本高，必须和风险等级绑定 |
这层预算如果不存在，系统就会出现另一种常见失控：要么什么问题都深检索，成本越来越高；要么为了控成本把所有问题都压到轻预算，最终又开始用“看起来够了”的证据做不该做的判断。
知识库、工具、追问和人工，不该是补丁式 fallback，而该是路由树上的正式节点
一个更稳的 router 通常不是“先检索，失败再想别的”，而是从一开始就承认四种不同的下一步：
- retrieve：当前问题主要依赖稳定知识说明
- tool：当前问题必须以实时系统状态为主证据
- ask-user：当前问题缺关键约束，任何检索都会在错误问题上努力
- human-gate：当前风险太高，证据即使齐也需要显式接管
这四种动作都应该被结构化记录，而不是靠模型在 prompt 里自由发挥。因为一旦它们只是软约定，系统很容易在真实压力下滑回最省力的那条路，也就是“总之先搜点东西回答一下”。
失败案例：本该查 live 库存的请求，被知识库里一段旧 SOP 回答得头头是道
某团队的售后 agent 同时接了产品手册、仓库操作 SOP 和库存系统工具。某次客户问的是“这批 SKU 现在还能不能承诺今天发出”，系统却优先走了知识检索，从 SOP 里找出一段标准处理说明，又结合历史发货时效给出一个看似合理的判断。客服一开始都没发现问题，因为回答语言非常顺。但事实是，这个问题根本不该先走知识库，它需要的是当前库存与仓储状态。
根因在于 router 完全缺位。系统只看到了“这像一个发货问题”，却没判断这是实时状态问题而不是规则解释问题。于是 Knowledge Plane 的优势反过来成了风险放大器：因为 SOP 文档写得太完整，agent 反而更容易相信自己已经有资格答。
修复后，团队把这类问题改成了显式路由：凡是涉及当前库存、审批状态、额度、排班、价格和 live case state 的问题，默认先走 tool；若 tool 返回不完整，再允许补知识说明；只要 freshness 或 authority 不满足，就直接追问或转人工。这之后系统并没有“更会说”，但大幅减少了那种最危险的“说得很像真知道”的错答。
Router 真正该优化的，不是命中率，而是错误的路径选择率
很多平台会先看 retrieval hit rate、tool success rate、answer success rate。对 router 来说，更有区分力的反而是这些指标：
| 指标 | 用途 |
|---|---|
| wrong-route rate | 判断系统是否经常把实时问题当知识问题，或把缺约束问题强行检索 |
| ask-first conversion rate | 判断追问是否真的减少后续错误路径 |
| knowledge-to-tool fallback ratio | 看知识路径是否被滥用成实时问题入口 |
| heavy-budget justification rate | 看重证据预算是否确实用在高风险任务上 |
如果系统的检索命中率很高，但 wrong-route rate 也高，说明你优化的是“搜到了很多不该先搜的东西”。这是知识层最容易被平均数掩盖的坏味道。
如果你现在只能先补一层，先把“哪些问题默认不该先走知识库”写成路由规则
很多团队会先去调更聪明的 query rewrite、更复杂的 rerank。更值得先做的，是写一张非常朴素但非常值钱的路由规则表：哪些问题必须优先走 live tool，哪些必须先追问，哪些在 freshness 或 authority 不满足时直接停下。只要这张表还不存在，Knowledge Plane 就会持续被用来回答本来不该由知识来回答的问题。
AI agent 不是因为“什么都能检索”而成熟，而是因为它已经知道：什么时候检索是最合适的第一步，什么时候不是。Router 把这件事做对了，后面的检索效果才真正有意义。
Checklist
- router 是否同时读取 task intent、freshness、risk、authority 和 budget 五类信号
- 是否为 retrieve、tool、ask-user 和 human-gate 定义了显式路由动作
- 是否按问题类型定义了轻、中、重三类 evidence budget
- 涉及 live state 的问题是否默认优先走工具而不是知识库
- 缺关键约束的问题是否优先追问而不是盲目检索
- 是否监控 wrong-route rate，而不只看 hit rate 或成功率
延伸阅读：
