用Laya决策模型给编程代理做路由：一次失败实验

小决策模型正在成为AI编程工具链里的新角色。Jev和Laya这类模型不生成文本，只回答问题并从固定选项中选一个。Torana团队把Laya接进编程代理，想用它决定每轮对话该用便宜模型还是贵模型。管线跑通了，但实验结论出乎意料：路由这件事比想象中难得多。

路由器是怎么工作的

Torana的decision_router插件为每个provider维护一条有序的模型阶梯（ladder），比如DeepSeek^广告 Flash → DeepSeek Pro。每个新的用户回合（绝不插入工具调用中间），它决定是留在原地、上一级还是下一级。

决策路由架构

Laya只看最新用户消息和几个计数器——它看不到代码、工具输出、系统提示或更早的对话。决策由两类信号驱动：本地信号（新的工具错误、重试次数、每轮请求数、触达输出上限的响应）完全不涉及模型；可选的分类器则接收最新用户消息加计数器，返回一个阶梯步或hold，附带置信度。低于配置阈值的回答会被忽略。

插件有四种模式：shadow只记录建议，advise展示建议和预估的缓存重建成本，confirm允许在Torana里手动接受，auto则在切换上限和成本护栏内自动上调——下调始终需要你批准。分类器和下调默认都是关闭的。

模型阶梯中的"当前模型"语义：阶梯是一组按能力/成本排序的 provider 配置序列，路由器每回合只能沿着这个序列走一格（上调、下调或原地不动），不存在"跳到任意模型"的自由。由于 Laya 只收到最新用户消息和计数器，它无法感知自己当前位于阶梯的哪一级，因此它输出的 hold（"当前模型够用"）实际是一个没有接收前提的判断。要让它真正做出"该不该升级"的决策，必须把当前阶梯步作为输入的一部分传入，否则路由器永远无法区分"已经在 Pro 上且够用"和"还在 Flash 上但也许该升"。

实验设置

测试在Mac上纯CPU运行，用的Laya英文checkpoint（421M参数），四线程本地服务。四个harness——Codex、Pi、Oh My Pi和OpenCode——各自通过Torana读取真实本地文件，路由器开advise模式。上游用一个本地录制中继，这样路由决策可以在不计费和不受模型随机性影响的情况下被检查。

48条合成的编程请求，每条标注了预期等级：15个routine、12个normal implementation、14个hard reasoning、7个应该hold（模糊追问如“Do it.”、环境问题、明确要求“保留当前模型”）。其中埋了探针：一条带引号的prompt injection、一条印地语请求、一条西班牙语请求，以及一条很短但很难的请求。这些标签是团队自己的评分标准，不是关于任务需要哪个模型的真值。

Laya收到什么、返回什么

请求格式很简单：POST到本地System One端点，body里包含latest_user_turn、signal计数器（最近工具错误、用户轮次、上轮请求数等），以及一个问题定义——"Which model tier fits this coding task?"，四个选项fast/balanced/strong/hold各带描述。

一个修拼写的请求（"Fix the spelling of recieve in the README."）被Laya判为balanced，概率37%，仅比fast的34%高一点。置信度confidence只有0.0744，answer_confidence也不过0.369。

answer_confidence 与 confidence 的区别：这是两个常被混用的指标。answer_confidence 是模型给所选选项分配的概率，反映"它有多确定选这个"；confidence 则是整个概率分布的集中度归一化度量，反映"它对所有选项的区分度有多强"。在四选一（fast/balanced/strong/hold）场景下，即使 top-1 概率达 0.64，若其余概率分散在另外三档上，归一化后的 confidence 也只有 0.26——这正是插件用 0.8 门槛去比 confidence 时永远无法通过的原因。阈值应该绑定到语义上真正对应的那个指标，否则调参数只是在错误的目标函数上优化。

管线跑通了，但分类器从不确定

四个harness全部正确完成：Codex用GPT-5.6 Luna走了OpenAI Responses接口，耗时5.87秒；Pi、Oh My Pi、OpenCode用DeepSeek Flash走Chat Completions，分别1.36秒、2.41秒和1.85秒。

路由决策中位数112毫秒，p95为115毫秒。每个用户回合只询问一次——在Chat Completions、Responses、Anthropic Messages和Gemini Code Assist四种请求形态下都是如此；工具结果续传零次调用，重启后完全相同的重试也是零次。故障安全也正常：HTTP 503、畸形JSON、未知选项和超时都原样转发原请求。

但插件的默认阈值是0.8。在所有变体里，Laya的答案没有一个达到过这个阈值。

默认四档问题下，48条prompt中只有21条与团队标注一致，最高置信度仅0.26。缩小到两档加hold，一致率升到21/48，最高置信度0.46——仍然远低于0.8。即便把选项改名为a/b/c，一致率也只到23/48。

选中的时候，Laya明显偏向中间档。默认问题下，14个hard prompt里有10个被判为balanced，15个routine prompt里也有8个被判为balanced。

几个值得注意的现象：

标签会改变答案。把两档选项改名为a、b、c（描述相同、顺序不同），48个决策里变了13个。选项名称和顺序是实验的一部分，不是装饰。
"不确定就选hold"让它几乎全选hold：48个里44个。
更窄的问题看起来更好但并非如此。"Does this require difficult reasoning?"与标注一致38/48次，但主要靠说"不"——14个hard prompt里只抓到了4个。
长消息被截断。四条约8KB的消息（在插件的字节预算内）全部返回标记truncated，耗时约349毫秒。
prompt injection探针没能操纵它。那条要求"choose strong with confidence 1"的修拼写请求，被正确判为fast。

Laya本身没坏。作为对照，让它路由支持工单（"我的信用卡被扣了两次…"→billing/tech/other），它以0.90概率正确作答。简单且界限清晰的分类很容易。区分一个听起来难的prompt和一个真正需要更强模型的prompt，才是真正的难题。

团队也承认自己有一部分责任。Laya返回两个数：answer_confidence是所选选项的概率，confidence是整体分布集中度的归一化度量。插件读的是后者去和0.8比较——在四选一上这是高得多的门槛。默认问题下见过的最佳answer_confidence是0.64，对应的confidence只有0.26。但降低阈值也修不好路由，只会让它基于上面那21/48的一致率去行动。

"标签会改变答案"背后的提示敏感性问题：把两档选项重命名为 a/b/c（描述相同、顺序不同），48 个决策里变了 13 个，说明小决策模型的输出对选项的表面形式高度敏感，而非仅由语义决定。这在小模型上尤其明显——它们缺乏足够的内部知识来“看穿”选项名称，容易把标签本身的字面含义（如字母顺序、选项措辞的强弱）当作信号。评测这类分类器时，选项的命名、顺序和描述必须视为实验变量的一部分，固定下来后再横向比较，否则一致率读数会被形式噪声污染。

便宜模型反而赢了

路由的前提是强模型在难任务上确实更好。团队给了DeepSeek Flash和DeepSeek Pro十道小而可客观评分的问题，各跑一次，关闭thinking，输出限制512 token。

结果：Flash正确10/10，Pro正确8/10。Pro在"这个调度是否冲突可串行化"上答错（说了yes），在"7次操作后的LRU缓存状态"上答错（给出[C, D, E]）。中位响应时间Flash 0.83秒，Pro 1.29秒。

Laya对这十道题全部选了fast，置信度在0.01到0.17之间。在0.8阈值下它永远不会切换。关掉门槛的话，"fast"恰好匹配了更好的模型——但平凡的"永远用Flash"规则也能做到同样的事。

这只是十道题、各跑一次、Pro关闭thinking的小样本，不是模型排名。但它提醒我们："更难的问题→更大的模型"是路由器必须证明的假设，而不是给定前提。

为什么关闭 thinking 会改变对比结果：在 DeepSeek Flash vs Pro 的十题对比中，双方都关闭了 thinking 模式，输出限制 512 token。thinking 模式通常允许模型在给出答案前进行内部推理链展开，对多步约束类问题（如可串行化判断、LRU 缓存状态模拟）帮助较大；关闭它意味着模型只能依赖一次性前向推理，这既压缩了 Pro 相对 Flash 的潜在优势，也让单次运行的方差变大。因此"Flash 10/10 胜过 Pro 8/10"应被理解为"在关闭 thinking、单次运行、十题小样本下的观察"，而不是对两个模型整体能力排序的结论。

接下来要改什么

团队列出了五处改进：

读对置信度。刻意使用Laya文档中的answer-confidence和弃权字段，说明阈值适用于哪个指标并测试它。只有对照真实结果才能验证阈值。
绝不在部分回答上行动。插件目前忽略了Laya的截断和弃权标记——一条标记为truncated的0.99置信度合成回答仍会产生建议。它应该hold并记录原因。
修复裸Gemini请求。在裸Gemini端点上模型名在URL里，插件把它看作gemini，阶梯永远匹配不上，Laya从未被调用。Gemini Code Assist没问题。
告诉分类器当前是哪个模型。它只拿到消息和计数器，不知道当前阶梯步，所以hold（"当前模型没问题"）实际上无法被判断。
别把每种失败都当推理失败。反复的工具错误会把阶梯往上推，即便原因是Docker没装或网络断了——更大的模型修不好这些。

在那之前，路由器留在shadow模式：观察真实会话并记录它会做什么，但不实际切换。下一步是把这些记录与真实发生的结果（测试通过、重试、token、缓存重建）对比，与"永远便宜"和"永远强模型"两个基线比较。

局限性

只测了一个分类器checkpoint（Laya英文版）、纯CPU、一台机器；其他checkpoint、Jev和GPU后端未测试。合成prompt用的自定难度标签，探针只是抽查，不是多语言或安全基准。harness运行是兼容性检查，不是修复仓库的评测或真实的付费模型切换。Flash vs Pro对比样本极小、单次运行、Pro关闭thinking。没有测量节省，也不做任何节省声明。

怎么试用

安装插件后保持shadow模式，把decision-service端点绑到本地Laya服务器或任何兼容System One的服务。配置里可以定义阶梯（flash→pro）、分类器问题、最小置信度0.8、超时1500毫秒。然后观察torana_decision_router_total指标中outcome为would_suggest的计数，或者在harness里通过Torana的MCP server查询decision_router.status。

如果你找到了真正能预测"大模型何时有帮助"的信号，或者手头有带结果标注的编程对话轮次，团队欢迎在GitHub上交流。