跳到主要内容

Router-Agent架构

核对日期：2026-05-09。

1. 定义与边界​

Router-Agent 架构在入口处增加路由器，根据用户意图、风险、成本、权限和上下文，把请求分发给不同 Agent、workflow、模型或工具链。

Router 可以是规则、分类模型、LLM、向量检索或混合策略。它不是 Supervisor：Router 主要做一次或少数几次分流，Supervisor 会持续管理子任务执行。

2. 为什么重要​

现实应用通常不是一个任务：客服系统有退款、物流、发票、投诉；企业助手有 HR、财务、研发、法务；代码助手有搜索、修改、测试、审查。把所有逻辑塞进一个 Agent 会扩大提示词、工具和权限面。

Router 的价值：

  • 降低上下文和工具选择复杂度。
  • 将简单请求路由到低成本模型或确定性 workflow。
  • 将高风险请求路由到审批链。
  • 将不同业务域的权限、日志和评测隔离。

3. 核心机制​

路由决策至少包含：

{
  "route": "refund_workflow",
  "confidence": 0.87,
  "reason": "用户要求退款且提供订单号",
  "risk_level": "medium",
  "required_scopes": ["order.read", "refund.preview"],
  "fallback": "ask_clarifying_question"
}

4. 架构模式​

模式机制适用
Rule router正则、枚举、业务字段判断高确定性、合规流程
Classifier router小模型/传统分类器输出类别大量历史标签、低成本分流
LLM routerLLM 读取上下文并输出结构化 route意图复杂、长文本入口
Embedding router与 route 描述做相似度匹配知识库/技能匹配
Hybrid router规则先挡高风险，模型处理模糊区生产环境常用

5. 工程实现​

def route_request(req, user):
    features = extract_features(req, user)

    if matches_high_risk(features):
        return Route("approval_queue", confidence=1.0)

    deterministic = rule_router(features)
    if deterministic:
        return deterministic

    candidate_routes = retrieve_route_descriptions(req.text)
    decision = llm_router(req.text, candidate_routes, schema=RouteDecision)

    if decision.confidence < 0.65:
        return Route("clarify", reason="low confidence")

    return policy_check(decision, user)

路由表示例：

routes:
  refund_workflow:
    owner: commerce
    allowed_tools: [get_order, preview_refund, create_refund_case]
    requires_approval_above_amount: 100
  faq_agent:
    owner: support
    allowed_tools: [kb_search]
    max_steps: 3
  coding_agent:
    owner: engineering
    allowed_tools: [repo_search, patch_preview, test_runner]
    sandbox_required: true

6. 生产实践​

  • 路由器输出结构化 JSON，并保存 reason、confidence、候选 route。
  • 使用 shadow routing：新路由器先旁路评估，不直接影响生产。
  • 对高风险意图使用规则优先，不依赖 LLM 自觉识别。
  • route 级别配置模型、工具、预算和日志保留周期。
  • 对低置信度请求优先追问，不要强行路由。

7. 常见反模式​

  • 只靠一个 LLM router，缺少规则和权限兜底。
  • route 描述彼此重叠，导致分类边界不稳定。
  • 路由错误后没有纠错或转人工入口。
  • 子 Agent 仍暴露所有工具，路由隔离形同虚设。
  • 只评测最终回答，不评测 route accuracy。

8. 评测方法​

  • Route Accuracy：意图分类是否正确。
  • False Safe / False Risky：高风险请求是否漏判，普通请求是否过度拦截。
  • Escalation Precision：转人工是否必要。
  • Cost Routing Gain：简单请求是否确实使用低成本路径。
  • Recovery：用户纠正后能否重新路由。

9. 安全与治理​

  • route 是权限边界，不只是代码分支。
  • 子 Agent 只能看到本 route 需要的上下文，避免跨域数据泄漏。
  • 外部内容不得影响 route 权限，只能影响业务 facts。
  • 对 route 配置做版本控制和审批，避免私自新增高危工具。

10. 工程手册补充​

10.1 控制流、状态流、工具流​

Router-Agent 的核心不是“分类”，而是把请求送入正确的执行边界。

流生产要求观测点
控制流规则先挡高风险，模型处理模糊意图，低置信度追问route_decision、candidate_routes、confidence
状态流路由只传递目标 route 需要的上下文，不共享全局记忆context_keys、redaction_policy
工具流route 绑定工具白名单和预算，不允许子 Agent 自行扩权route_toolset、denied_tool_call
反馈流用户纠正、转人工、子 Agent 拒绝都要回写路由训练样本correction_label、handoff_reason

10.2 适用与不适用边界​

场景是否适用原因
企业助手按 HR/财务/研发/法务分域适用权限、知识库、审计边界天然不同
客服入口按退款/物流/发票分流适用高确定性业务路由可以节省成本
只有 3 个工具的个人助手通常不适用单 Agent 工具选择已足够
需要跨域连续推理的大任务谨慎过早路由可能切断必要上下文

失败恢复：

  • 路由错误但未产生副作用：允许用户纠正后重新路由，并把原 route 标为负样本。
  • 路由错误且已产生副作用：进入人工复核，不让目标 Agent 自行补救。
  • route 置信度长期下降：回退到规则集或旧版本 router，开启 shadow routing。
  • 新 route 上线：先只读、再 preview、最后开放 commit 类工具。

上线清单：

  • route 描述互斥，至少有 50 条以上真实样本做混淆矩阵。
  • 每个 route 有 owner、SLO、工具白名单、预算上限和降级路径。
  • 高风险 route 有规则兜底，不依赖 LLM 自行识别。
  • 监控 route accuracy、low-confidence rate、错误转人工率、越权工具尝试。

11. 权威资料​