模式矩阵/R2 复杂度路由/蓝皮书

场景约束

企业 HR 与薪酬入口会收到不同类型的请求：领域外闲聊、薪资表分析、薪资组配置、算薪或代发。若所有请求都进入链式推理和行动编排，简单请求会占用不必要的模型和工具成本，高风险事务也缺少独立治理入口。

复杂度路由在主循环入口完成分类，并把请求分配到深度不同的执行链。

控制信号

早期系统使用四个枚举：

随着场景增加，枚举演化为 task、information、produce、chat 等类型，并增加第二层业务场景绑定，用于推荐相关 Skill 和工具候选。枚举由下游流程倒推，不直接复用其他产品的分类。

路由流程

用户输入
  -> 受 Schema 约束的意图分类
  -> 输出校验
  -> 意图网关
  -> chat / analyze / resolve / unknown 执行链

分类器固定在一到两次模型调用内完成。输出必须符合 Schema，无法解析或置信度不足时转入 unknown。意图结论的自然语言摘要写入叙事状态，离散枚举进入控制平面。

会话仍保持 pre / middle / post 三段边界：

• pre 接收输入并完成意图分类；
• middle 执行所选能力链；
• post 合成结果并返回。

Orchestrator 管理三段流程，意图网关只负责从信号映射到执行链。

案例运行

“你叫什么名字”可以在 chat 链路结束；上传薪资表并请求说明进入 analyze，按需检索领域知识；搭建薪资组进入 resolve，继续使用 R1 链式推理和行动模块。代发等敏感事务在后续控制信号中进入审批门。

第二层场景绑定可以提前缩小 Skill 和工具候选，但不能跳过工具准入、参数校验和审批。

失效信号

• 分类结果是一段描述，没有离散枚举；
• 未知输出直接进入默认重链路；
• 所有请求都被路由到最高成本路径；
• 枚举过细，入口分类承担了完整业务规划；
• 业务分类和工具准入混为同一步；
• 路由结果没有进入事件时间线，无法分析误分流。

验证指标

• Schema 解析成功率和 unknown 比例；
• 各路由档位的流量分布；
• chat、analyze 被误送入 resolve 的比例；
• 事务请求被误送到轻链路的比例；
• 各档平均 Token、延迟和工具调用次数；
• 二层场景绑定后的候选工具缩减率与正确率。

与白皮书的对应

R2 白皮书以信号提取、分类和分档执行描述复杂度路由。东方屹腾按动作类型和执行链深度分类，而非只按模型档位分类；unknown 承担解析失败和低置信度的回退。

迁移条件

自然语言入口对应多条成本、能力或风险差异明显的下游流程时，应使用复杂度路由。入口已经结构化，或所有请求使用同一流程时，可以直接进入主链。信号枚举、兜底和路由指标必须在上线前定义。