项目：白泽 Baize —— 面向团队的 AI 助手运行时（Go 1.25+，MIT） 仓库： github.com/rebornace/b… ｜ 国内镜像： gitee.com/RebornAce/b… 这篇文章不是 “接入 Jev” 的教程，而是分享一个判断：Jev 值得学习的不止是模型，还有 “高频判断不该让生成式模型写作文” 这个工程思想—— 而且这个思想不依赖 Jev 服务本身也能落地。
一、决策层设计：三个原则 + 一条红线
白泽是一个旁挂式 AI Agent 运行时：单进程部署在业务系统旁边，把 OpenAPI / MCP / HTTP 插件自动变成可调用工具，写操作要人工审批。它通过 OpenAI 兼容 API 调模型，拿不到 logits，也就拿不到校准概率 —— 所以决策层从一开始就不设计任何依赖概率的逻辑。
设计时定了三条硬原则：
可插拔：抽象一个决策接口，本地规则、本地小模型、远端决策服务都是它的实现，缺省用最便宜的那个。不依赖任何外部服务。
可降级：每个决策点失败都 fail-open 回现有规则路径，决策层永远不是 run 的单点故障。
可观测：每个判断都留下出处和降级记录（decide.degraded、decide.tool_narrow 等事件）。
一条红线：判断结果里不存在任何置信度数字。因为拿不到校准概率 ——“能拿到一个数字，但那不是我们想要的那个数字”，一个看起来像概率、实际未校准的数字，比没有数字更危险，它会诱使人写出 “概率超过 0.9 就自动执行” 这种分支逻辑。
接口形状：判断只回枚举
决策层的返回形状刻意保持最小：判定只有 yes /no 两个枚举值；多选场景返回被选中的项；每次判定附带出处（来自规则、远程模型还是兜底）和是否降级的标记。接口里没有任何 float 类型的置信度字段 —— 这条是从类型层面杜绝 “把未校准数字当置信度用”。
Chain 的降级语义
所有实现被串成一个链，按序尝试，首个成功的返回；全部失败时返回调用点预先写死的兜底判定，并标记 “已降级”。链本身永不返回错误 —— 错误必须在链内部被降级消化，不允许穿透到主流程。这样调用方永远拿得到一个合法的枚举值，决策层故障的表现是 “退回老行为”，而不是 “报错中断”。
一个容易忽略的细节：兜底判定是调用点在代码里写死的，不是配置项。因为各判断点的失败方向各不相同且不一致 —— 记忆抽取失败应当照常抽取（宁可多花钱不可丢记忆），工具收敛失败应当发全量（宁可多花 prefill 不可漏工具）。如果做成配置项，迟早会有人在成本压力下把它翻成反方向，然后静默丢数据。失败方向是安全性属性，不是运营参数。
决策链的实现
链上目前有两档实现：远程实现优先 —— 配置了独立决策模型档位时，用提示词强制模型只输出 yes /no，再用正则 / JSON 解析校验，解析不了就当弃权让链继续降级；没有配置或远程不可用时，落到零延迟规则兜底（目前只负责记忆抽取这一个判断点，其他判断点直接弃权）：短闲聊且无事实线索判 No，带 “记住、密码、电话” 等事实线索、出现连续数字或内容较长时判 Yes。多选版本只接受候选集合里的名字，出界的一律丢弃。因为 OpenAI 兼容端点的结构化输出支持不一致，契约靠提示词 + 解析强制，而不是依赖各家接口差异。
将来如果想接能读 logits 的自部署推理端，只需在链上再加一档实现，调用方不用改。
二、四个判断点：从 “让大模型写作文” 下沉出来
白泽里有四处典型的浪费：为了拿一个 “是 / 否、选哪个” 的决定，让生成式模型写一大段话。决策层把这四处逐一下沉。
2.1 DP-1：记忆抽取前置判断（性价比最高的一处）
白泽原本在每次成功对话之后都发一次 LLM 调用做记忆抽取，绝大多数对话根本没值得记的事实，返回空数组，但每次都要付一次完整调用 + 一次 JSON 解析风险。
现在在支付那次调用之前，先问决策层 “这轮值不值得抽记忆”：判定为 No 时直接跳过抽取，记录一条跳过事件（标明是决策层判的），并把预估省下的输入 token 数一起记下，方便核算收益；判定为 Yes 或决策层不可用时，照常抽取，行为与改动前完全一致。
判断本身的成本也要控制：探针上下文截断到 1500 字符以内 ——探针不该比它要省的那次调用更贵。
2.2 DP-2：工具候选两级收敛（结构性成本）
这是白泽身上最值得做的一件事。白泽的定位是 “有 OpenAPI 就自动变工具”，连接器越接越多，全量工具 schema 每轮都发给主模型 ——prefill 成本随连接器数量线性增长，这是随用户规模放大的结构问题。
收敛分两级：
第一级：系统路由（System Targets）。先让决策模型从 “几个连接器 id” 里选这轮要用的后台系统（拿不准时选多个）。从几百个工具里选一个很难，从三五个系统里选就简单得多。系统的描述不是写死的，而是根据每个系统内工具的领域词自动生成（词频 × 跨系统 IDF），所以接新连接器时不需要人维护路由语料。
第二级：系统内关键词预筛。在被选中的系统内，用确定性 IDF 关键词打分（工具名权重 2 倍、描述 1 倍，停用词剔除，中文用二元组切词），按系统轮询分配名额，收敛到默认 16 个以内。
收敛不是 “一刀切”，还带三个地板防止误杀：
类别工具地板：用户说 “列出用户” 时，通用的分页工具在 IDF 里排不上去，但列表请求恰恰需要它 —— 命中列表 / 详情意图时强制保留对应管理工具；
登录地板：系统被选中后，它的登录、当前会话原语永远保留 —— 后端返回 401 时模型要能当场恢复会话，而用户永远不会在请求里说 “登录”；
混合路由：查询里确定性命中的领域词（如 “宠物”" 订单 "）会强制锁住对应系统，模型只能往上加、不能去掉 —— 防止小模型把唯一正确的系统选没。
另外，主模型调用支持枚举约束（要求模型必须从给定工具里选），通过可选接口扩展，不破坏现有 Provider 签名；提供方不支持时自动退回普通调用 —— 约束是优化，不是硬门禁。
2.3 DP-3：工具结果剪枝
长会话里，之前某轮工具返回的大体积 JSON 会一直躺在上下文里膨胀。压缩触发时，决策层对 “最大的几条工具返回” 逐条判断 “值不值得原样保留”，不值得的替换成占位符（保留消息与工具调用的配对，模型需要时还能重新调用工具，原始结果仍在运行日志里）。
三条边界保证判断本身不贵：只审工具返回（普通对话不审）、只审估算超 500 token 的、每轮最多审 8 条。全部失败就全部保留。
2.4 DP-4：路由档位仲裁
白泽原来用纯启发式（有无图片、有无代码围栏）把每轮路由到 light /standard/power 三档。启发式的问题是 “帮我重构这个函数” 不含代码围栏，会被判成轻档，强模型该上没上。
DP-4 的做法：不替换启发式，只在 “启发式落在模糊的 standard 档 + 回合足够长（≥400 字符）+ 是自动路由” 时才咨询决策层二选一（light /power）。短回合不值得问 ——“你好” 路由到哪档差别很小，而每次查询本身有延迟成本。
DP-4 的判断也走同一条决策链：有独立决策档位时由便宜档位来二选一；判断不可用（降级）时保留启发式判出的 standard 档 —— 决策层永远只给建议，不改写路由结果。
三、效果与验证
可复现基准：37 条真实只读业务请求，横跨 3 个已接入后台（共 390 个工具），模型 DeepSeek-Flash；稳定性连跑 5 轮（185 次请求）。收口 16（默认）时运行成功率99.5%（184/185），turn-0 prompt 平均约3,090 tokens，相比收口 32 降低约34%；直接全量下发 390 个工具时，turn-0 实测约 8.5 万 tokens。数据与脚本都在 scripts/tool-routing-eval，可复现；
默认收口：超过阈值（默认 12 个工具）才启用收敛，收口后默认最多保留16 个候选工具，这是成本 / 成功率实测的折中点；
回归基准：仓库里有一套 tool-routing-eval 回归脚本（扫宽度、测稳定性、离线分析），跑完自动恢复原配置 ——收敛这种会改行为的优化，必须先有 shadow 数据，再谈关 shadow 生效。
整个过程都保持 “决策层默认关闭、逐点灰度”：总闸 decide_enabled 默认关，所有判断点都有独立开关，通过现有的热重载配置面控制，不动任何装配代码。
四、边界与诚实声明
没有校准概率：我们通过 OpenAI 兼容 API 调模型，拿不到 logits。所以决策层永远只回枚举，任何 “按概率阈值自动执行” 的功能都没有。写操作审批仍然是确定性规则 + 人工审批，这条红线不因 Jev 而松动。
这不是 “接入 Jev”：白泽决策层不依赖任何外部决策服务。将来用户把自己的推理端指向本地 vLLM（装了决策插件）时，远程实现天然可用 —— 但那是白捡的能力，不是架构的前提。
五、结尾
Jev 让我重新想清楚了一件事：模型当然重要，但很多高频小判断，本不该每次都让生成式模型写作文。把 “判断” 从 “生成” 里下沉出来，用一个可插拔、可降级、可观测的决策层承接，是任何 agent 项目都值得做的工程 —— 它不依赖某一家公司的窗口期。
白泽的决策层已经落地在主线代码里（internal/decide + 四个判断点），欢迎来看看、跑跑，或者直接提 Issue：
GitHub：github.com/rebornace/b…
Gitee：gitee.com/RebornAce/b…
更多资料：README 的「架构理念：决策层」一节，以及开发者文档 docs/developers/（中英双语）