请求选路

智能路由页回答一个问题：哪些请求属于哪一组渠道。它决定一条请求落到哪个逻辑模型，从而决定它最终连到哪个上游。

两种模式

页头可以在两种模式间切换。它们各自是一份独立定义，同一时刻只有一种生效，切换不会删掉另一份。

两种模式的版本能力是同一套：都是「保存后生效」，也都能回滚到任意一版。

页头按当前模式写名字

模式开关上是「工作流编排」，页头就写「工作流编排」；规则模式同理。

在画布上把节点串成链路：输入 → 协议发现 → 条件 → 逻辑模型选择 → 输出。每个节点只做一件事。

内置策略可直接套用（选择即替换当前画布）：

策略	做什么
逻辑模型命中	请求模型命中逻辑模型列表就直连它，否则落到默认逻辑模型。
UA 区分来源	识别 Cursor / Claude CLI，分流到不同逻辑模型，认不出的回落默认。
LLM 分析请求复杂度	让逻辑模型读一遍请求判断复杂度，复杂走高性能落点，其余走快而便宜的落点。
JS 脚本处理请求	用沙箱脚本按请求规模打分分档，再按分档分流。

可用节点包括：输入请求、控制输入、协议发现、条件、逻辑模型选择、遍历迭代、JS 脚本、LLM 节点、备注、路由结果出口。

规则表从上往下依次匹配：第一条命中且给出落点的规则胜出，都不命中就走兜底。

内置规则预设：逻辑模型命中、UA 区分来源、模型名前缀分流、按协议分流。

两种模式都有试运行，用一条示例请求把判定过程摊开：

试运行不会转发上游

试运行只走路由判定，不会向任何上游发请求。改路由前先跑一遍，比直接上生产便宜得多。

每次保存都会把当前定义发布成一个新版本，代理立即按它路由。历史版本列表里可以回滚到任意一版。如果当前内容与最新版本一致，则不会产生新版本。

路由定好落点后，落点内部的尝试顺序交给故障转移。