跳到主要内容

Router 与 Triage 设计

多 Agent 系统里，第一步经常不是推理，也不是工具调用，而是分流。

系统先要回答的是：

  • 这件事该交给谁
  • 要不要继续追问
  • 能不能直接在入口层解决
  • 什么时候该 handoff
  • 什么时候只需要调用一个 specialist tool

这一层如果没设计好，后面的 specialist、evals 和 guardrails 都会被拖着一起出问题。

这篇文档专门讨论 router 和 triage 设计。

参考资料主要来自：

1. 先把两个词分开​

1.1 Router​

router 关注的是：

当前输入应该被送到哪个能力单元。

它是分发层。

1.2 Triage​

triage 关注的是：

在正式进入执行前，先把问题分类、补全、判断优先级和边界。

它不只是分发，还包括前置判断。

很多系统里这两个角色会放在同一个入口 Agent 上，但关注点并不一样。

2. 为什么这一层单独值得设计​

原因很直接。

入口一旦做得含糊，后面会连带出现这些问题：

  • specialist 收到不该由自己处理的任务
  • handoff 变多，但没有变准
  • 同一个问题在多个 Agent 之间来回传
  • 工具被错误调用
  • trace 看起来很长，但真正有用的步骤很少

所以 router / triage 往往不是“前台接待”，而是系统稳定性的第一道结构层。

3. triage 主要在判断什么​

一个入口层通常至少要先判断这几件事：

3.1 任务类型​

例如：

  • 问答
  • 检索
  • 写操作
  • 审批
  • 浏览器操作
  • 需要 specialist 的复杂任务

3.2 风险级别​

例如：

  • 只读
  • 可逆写操作
  • 不可逆写操作
  • 对外发送
  • 财务 / 权限 / 合规相关

3.3 信息是否足够​

很多任务还没到执行阶段，先卡在：

  • 缺参数
  • 缺上下文
  • 缺目标对象
  • 缺权限边界

这时更好的动作通常不是 route，而是先补信息。

3.4 是否需要 specialist​

有些任务入口层就能解决。

有些任务虽然复杂，但只需要一个 tool。

只有当任务真的进入另一个职责边界时，specialist 才有必要出场。

4. 一个最小 triage 流程​

这张图里的关键点有两个：

  • triage 不只是“选人”
  • route 之前先判断信息和风险

5. router 的常见实现方式​

5.1 规则优先​

最简单，也最稳。

例如：

  • 命中退款关键词 -> billing
  • 命中合同 / 条款 -> legal
  • 命中删除 / 修改 / 发送 -> 高风险路径

优点是：

  • 容易解释
  • 容易审计
  • 容易回归

缺点是：

  • 灵活性有限
  • 复杂语义边界会变难维护

5.2 模型路由​

也就是让模型判断：

  • 该去哪个 specialist
  • 是否需要 handoff
  • 是否先追问

优点是：

  • 适合语义边界复杂的任务
  • 扩 specialist 更方便

缺点是：

  • 更难解释
  • 更需要 evals
  • 更容易产生不必要 route

5.3 规则 + 模型混合​

这是实际系统里很常见的一种做法。

例如：

  • 规则先拦高风险和明显类型
  • 模型再做细分路由
  • 实在不确定时回到补信息

这种方式通常更稳，也更容易迭代。

6. 入口层最常见的 4 个错误​

6.1 一上来就 handoff​

入口层如果一上来就把任务交出去，很容易变成：

  • 谁都能接
  • 谁都接不准
  • specialist 被迫处理脏输入

6.2 不追问信息缺口​

例如：

  • 用户说“帮我发邮件”
  • 但没有收件人、主题、内容范围

这时直接 route 或直接 tool call 都不稳。

6.3 specialist 边界重叠​

如果：

  • support 能答一点 billing
  • billing 也能答一点 order
  • order 又能处理一点 support

入口层的路由准确率会迅速下降。

6.4 入口层承担了过多业务逻辑​

入口层适合做：

  • 分类
  • 追问
  • 风险判断
  • route

但如果它同时负责：

  • 深度推理
  • 大量工具调用
  • 长链路执行

那它就不再是 triage，而是在偷做 specialist 的事。

7. 什么时候该 route，什么时候该 tool call​

这是入口层最容易犹豫的地方。

可以用这组判断：

更接近 tool call​

  • 主控 Agent 仍然很清楚
  • 下游只是局部能力
  • 当前任务不需要换一套职责边界

更接近 handoff / route​

  • 下游需要成为新的主导者
  • 后续会使用另一套系统提示和工具集
  • 责任边界已经切换

更接近先追问​

  • 信息还不够
  • 风险还不清楚
  • 当前不该急着执行

8. triage prompt 最少要覆盖什么​

入口 prompt 至少要讲清：

  • 哪些 specialist 存在
  • 每个 specialist 负责什么，不负责什么
  • 哪些情况先追问
  • 哪些情况属于高风险
  • 哪些情况不要 handoff
  • route 时要保留哪些上下文

如果这些边界没写清，路由很容易漂。

9. triage evals 应该怎么做​

这一层最好单独评，不要混到总结果里。

可以单独测：

  • route 是否正确
  • 是否多余 handoff
  • 是否少问了关键追问
  • 是否把高风险任务送进了错误路径

这一层和 Multi-Agent-Evaluations.md 正好能接起来。

10. 和现有专题里的关系​

最适合一起看的文档有：

11. 小结​

router / triage 这一层做得好，后面的 specialist 才有机会跑稳。

它主要处理的不是深度推理，而是前置分流：

  • 先补信息
  • 先看风险
  • 再决定 route、tool call 还是 handoff

这一层越清楚，后面的链路越干净。