把「从 N 个候选里选一个」这件事，从大模型的推理路径上拿下来，交给一个只做选择的决策模型。
企业级 Agent 平台一般都会有一个「入口智能体」：所有对话先到它这里，它判断用户想干什么，再决定是「自己答」还是「委派给某个领域专家」。
BizBuddy 就是这样做的（RuoYi-Vue-Plus 6.0.0 + Spring Boot 4.1 + JDK 21 + AgentScope Java 2.0.4，纯 Java 一条链路）。我们把这个入口智能体叫「小Z」------它不绑业务工具、不绑知识库，只做两件事：读懂意图，挑一个专家。
本篇讲的是第二件事：我们怎么用**结构化决策模型（JEV）**替掉「让大模型猜」，以及为什么要这么换。
一、问题不在模型，而在「判断被放在了推理路径上」
小Z 原本的路由判断，是它 ReAct 循环里的一个内部工具 route_decision（function calling）完成的：模型带着完整上下文（还有候选专家清单）推理一轮，返回一段受 prompt 约束的结构化出参，服务端再校验合法性。
这套机制没有缺陷，但有一个结构性代价：
判断必须等一次推理。
用户提问之后，要先等小Z 把「选谁」这一步推理出来，专家才开始干活。一次询问里，「选谁」白白压着一整轮秒级 的 ReAct------这段空白，就是用户感知到的「首字延迟」 。而且这个判断藏在模型出参里------不可校准、不可回放、不可分支（它自己给的 confidence 从来没参与过任何决策）。
所以我们想换的不是「更聪明的模型」，而是这一步的计算方式。
二、JEV 是什么：一个只回答「选哪个」的模型
JEV 是 AgentScope Java 2.0.4 里的 agentscope-extensions-jev（核心是 JevClient）。它对接的是 TypeSafe System One 协议：POST /compatible-mode/v1/systemone，请求里是一个闭集 的候选与判据，返回的是概率分布 + 置信度。
有意思的是：阿里云百炼上的决策模型 decision-model-preview 说的就是同一套协议。我们实测下来，零适配代码 ------只换 base-url / model / api-key，JevClient 直接解析成功（type 取值 choice / noul / score 与框架逐字一致）。这也意味着换厂商、换模型不需要写适配层。
它的边界也很清楚：回答「是/否」「N 选一」「打分」，不生成文本、不做长链推理与长文理解。
所以真正的价值不是「更准」，而是：判断从推理路径中前置移出，高置信时不必再等一次小Z 的推理。
三、落地形态：闭集 + 概率 + 两段式采信
给决策模型的输入只有判断必需的事实，不喂完整对话历史（这也是数据出境面的控制）：
- 选项闭集 =
self（小Z 自答）+ 自动候选专家 +other（兜底出口，语义是「无法判断归属」，不是错误）； - 判据 就是每个专家的「描述」------沿用「描述即路由『擅长』」的口径，所以运营侧改描述就能改善路由质量，零代码；
- 输出是概率分布，天然可设阈值、可留痕、可回放。
采信条件是两段式，顺序不能颠倒：
- 先按候选数取分档基础阈值比较
top1（候选 ≤5 用 0.75、6~10 用 0.65、>10 用 0.55）------闭集打分器的概率在 N 个选项上归一化，候选越多单选置信度天然越低，一把尺子量所有规模必然失真； - 再要求
top1 / top2 ≥ 2.0（margin）。0.76/0.15和0.76/0.70的确定程度天差地别，裸 confidence 分不出来，后者正是「勉强第一」型误接管。
两段都过、且选项在候选内 → 采信 ：短路整段入口轮 ReAct，直接编排，专家直答 。任一段不过（含 margin 不足、选项越界）→ 回落小Z 原本的工具决策。
四、放量纪律：先影子，再闸门，默认关闭
这套能力默认是关的，而且关得彻底：
| enabled | mode | 是否外呼 | 谁决定路由 |
|---|---|---|---|
| false（默认） | 忽略 | 否，零外呼 | 小Z（原有工具决策） |
| true | shadow | 是（并行） | 小Z，判定只落审计 |
| true | gate | 是（前置） | 高置信 → 决策模型；其余 → 小Z |
硬约定是：enabled=false 时不得有任何副作用 ------不构造 state、不发起外呼、不新增耗时、不改动原有工具决策链路一行代码。不配置即完全等价现状。
shadow 档是这套方案的真正入口：判定照跑、结果只落审计，用来采集「决策模型选了谁 vs 小Z 实际路由给谁」的对照语料。判断质量必须先用真实数据证明，再谈接管。
五、本篇只到「设计层」
设计层的三个决定说完了：闭集 + 概率 、两段式采信 、默认关闭 + 影子先行。它们解决的是「这件事该怎么算」，还没碰「这件事怎么写、怎么上」。
落地之后的问题都在后两篇：
- （二）跟真实模型对接 ：判断端口怎么切、
state与闭集怎么拼、审计留什么，以及我们在对接决策模型时踩到的 4 个坑------概率和不保证为 1（框架会因此直接抛异常，且异常不带响应体）、是非题不返回置信度、outputTokens恒为 0、同一输入两次判定会波动； - （三）放量与兜底：影子数据怎么变成阈值（三个指标 + reliability 校准）、超时与熔断怎么收口、追问场景怎么做到根本不外呼，以及外呼前的强制脱敏与「判断不授予权限」这条边界；
- （四）体验向单篇 ：不讲机制，只讲用户侧那三条可感知收益------该路由的轮次少等一整轮推理、故障期不再被超时拖住、追问零额外等待。
六、小结
把「选谁」从推理里拿出来，用户侧 其实只感受得到三件事：该路由的轮次少等一整轮推理 （秒级，不是毫秒级）、故障时不再被超时拖住 （每轮 5 秒多 → 1 秒以内，故障期间直接归零）、追问不再重复付一次判断（粘性复用、零外呼）。
系统侧 换来的是另外三件事：判断可校准可留痕 、失败可回退且零新增失败面 、以及一次判断终于变成可审计、可回放的动作。
它不是什么颠覆式创新------恰恰相反，它的价值在于工程上的克制 ：默认关闭、关闭态逐项等价、先影子后放量、任何失败都回落原路径。企业里能上线的 AI 能力，往往不是最亮眼的那一个，而是最不会把系统拖下水的那一个。
项目已在 Gitee 开源：gitee.com/zl3624/biz-...（文档见 gitee.com/zl3624/biz-...）。欢迎来 Issue 聊聊------尤其是你对「判断与推理分离」这条路的看法。