Jev 三项候选接入评估：搜索路由 / 高影响动作前粗筛 / 工具调用选择
2026-09-21｜评估人：小墨 判据沿用上一轮结论：动作可逆 + 判据可核对 + 问法是判别式（三条同时满足才接）
结论
| 候选 | 判定 | 一句话理由 |
|---|---|---|
| ① 搜索路由 | GO（有条件） | 把「主模型读 42KB 矩阵做首跳路由」换成一次 Jev choice；但升级链留给主模型 |
| ② 高影响动作前可逆粗筛 | GO（优先做） | 是已证模式（重要度影子 / retain 预筛）的扩展，动作可逆、批量、成本极低 |
| ③ 工具调用选择（热路径） | NO-GO | 加一跳却不省主模型调用；且换 toolset 会破坏 prompt 缓存不变量 |
③ 与 ① 本质是同一件事的不同粒度（选引擎 vs 选工具）。正确做法是合并成一层「能力路由层」，而不是在两处各接一次。
⚠️ 先更正一个事实（影响 ① 的前提）
上一份评估里我写「search_router.py 当前 137 行纯规则分发」——这是错的，来自未经核对的记忆。
实际读取 ~/.hermes/scripts/search_router.py（137 行）后确认：它里面没有任何路由规则。
它是一个 search-worker 调用器：task_goal → prompt_builder → search_worker_wrapper → 归一化 packet → 中文摘要。
真正的路由决策落在两处：
~/.hermes/skills/productivity/search-routing-matrix/SKILL.md（41,877 字节，≈12k tokens）- 调用它的 agent 自己的判断（
--coverage默认值里那句「轻量查找和已知 URL 抽取应由主 agent 直搜/直抽」就是策略文本，不是代码逻辑）
这个更正让 ① 的收益点变得更清楚也更可量化：不是「把规则换成模型」，而是 「省掉每次路由都要加载 42KB 矩阵 + 主模型推理」。
① 搜索路由
现状成本
search-routing-matrix/SKILL.md= 41,877 字节（≈12k tokens）， 且常与search-fullbundle（15 个 skill）一起加载。- 每次复杂检索都要「读矩阵 → 分层判断 → 选引擎」。
Jev 适配点（首跳路由）
把「给定查询 + 引擎清单 → 选哪一层/哪个引擎」做成一次 choice 判定：
- 选项集是闭集且稳定（cycle: 当前会话 LCM / 跨会话 session_search / 本地 wiki / 本地文件 / 轻公网 web_search / 中文公网 baidu / 平台专项 / 动态反爬 scrapling+browser / 证据包 search_router），
完全落在 choice 原语的适用形态内。
- 动作可逆：选错了可以重搜（这正是可逆判定的要求）。
- 判据可核对：历史查询里「agent 实际选了哪条路、结果好不好」就是现成 ground truth。
明确的边界（否则会重犯剪枝那个错）
- Jev 只做首跳，不做升级链。 「首搜没结果 → 升级到 scrapling」这类多跳/条件升级，Jev 官方自己标注多跳推理退化，必须留给主模型或规则。
- 不能让它成为「唯一门控」：路由错会浪费一次检索，但不是不可逆，所以风险可控 —— 这也正是它比剪枝适合的原因。
- 需要离线对照（见验证计划），不能直接上线。
验证计划（先离线，零生产影响）
用历史会话里的真实检索请求当样本，让 Jev 判首跳，与 agent 实际选择 + 结果质量对照： 1. 抽 50–100 条历史检索请求（跨公网/平台/本地/wiki 各类）； 2. Jev choice 判首跳 → 与「实际走了哪条 + 是否成功」对照； 3. 通过门槛：首跳一致率 ≥80%，且不存在「本该走证据包路线却被判成轻量直搜」这类高危漏判； 4. 达标才影子，再谈替换矩阵加载。
② 高影响动作前的可逆粗筛（建议优先做）
为什么优先
这一条不是新能力，而是已证模式的扩展： - 晨报重要度影子评分、retain 预筛、wiki 告警分诊 —— 三处都是「对候选池排序/分档，只标记不拦截」，已稳定运行。 - 动作可逆（过滤输入 / 排序，不裁剪产物）、批量（成本极低）、判据可事后核对。 - 三条判据全满足，且不引入新架构。
具体候选落点
| 落点 | 用法 | 动作性质 |
|---|---|---|
| 深度调研启动前 | 一批候选主题先排优先级，决定哪几个进全量调研 | 过滤输入，可逆 |
| 大批量处理前 | 全量 wiki 治理 / 全会话扫描 的条目先分档 | 排序，可逆 |
| 记忆治理前 | L0 治理候选先分档，减少人工过目量 | 排序，可逆 |
| 升级/迁移前 | 变更清单先判「哪些是必须保留的能力」 | 标记，可逆 |
| delegate 前 | 子任务先判「值不值得委派 / 该不该拆」 | 过滤，可逆 |
边界
- 分档由我们定（quantile），Jev 只提供排序 —— 这是本轮实测的核心纪律：模型量表是任意的，绝对阈值必然退化。
- 绝不用它决定「删不删」，只决定「先看哪个 / 要不要进下一步」。
- 每个落点上线前都要有 ground truth 对照（否则就是换个地方拍脑袋）。
③ 工具调用选择（热路径）—— NO-GO
先把被混为一谈的四件事拆开：
| 决策 | Jev 适配 | 理由 |
|---|---|---|
| (a) 要不要用工具 | ❌ | 主模型本来就要跑，加一跳不省调用 |
| (b) 选哪个工具 | ⚠️ 仅限非热路径 | 与 ① 同构；放热路径纯亏 |
| (c) 选哪个 toolset | ❌ 默认不做 | 换 toolset 会破坏 prompt 缓存 |
| (d) 这次调用该不该放行 | ❌ | 热路径门控 + 误判代价高 |
三条硬理由
- 加一跳，却不省调用。 就算 Jev 选对了工具，主模型仍必须运行来产出参数与回答。 Jev 只增加 0.4–0.8s（跨洋实测）与一次请求，净亏。
- 换 toolset 违反缓存不变量。 Hermes 明确把「对话内 prompt 缓存」当作不可变约束 （压缩是唯一豁免）。而 Hermes 的工具 schema 每次调用都全量发送， 所以在轮次之间动态换 toolset 会让缓存失效、成本上升——省下的 schema token 抵不上缓存丢失。
- 误判代价不对称。 工具选错的纠正成本是一整次模型调用；若当门控用，一次误拦会直接打断正常流程。
唯一有意义的形态（归并到 ①）
不在热路径选工具，而在路由层选「能力族」： 把「这类请求该动哪一层能力」提前判一次（choice），主模型只在这层能力里选具体工具。 这既省掉「读矩阵」的成本，又不碰缓存不变量，也不用 Jev 承担门控责任。
换句话说：用户问的第三个问题，答案是把 ③(b) 并进 ① 去做，而不是在工具调用点上接 Jev。
汇总：建议执行顺序
- 先做 ②（可逆粗筛的某个具体落点，如深度调研前置排序）—— 已证模式、风险最低、当天可出对照数据。
- 再做 ①（搜索路由离线对照）—— 需要 50–100 条历史样本，1–2 天出结论。
- ③ 不单独做，其有效部分并入 ①。
三条必须沿用的工程纪律（本轮实测得来）
- 问法必须判别式（绝对式「还需要吗」会退化）
- records 绑定 ≫ 整段 state 多问
- 量表任意 → 分位排序，不用绝对阈值；且降级链必须内建（429/503 实测存在）
诚实边界
- ①②均为评估结论 + 验证计划，尚未执行任何接入，无生产改动。
- ①的首跳一致率门槛（≥80%）是预注册判据，不是实测数字。
- ③的结论基于架构约束（缓存不变量 + 调用次数），不依赖新实验；若将来 Hermes 允许会话始冻结 toolset，可重新评估。