← 返回决策档案列表
AUDIT TRAIL // RECORDED
Jev 用法扩充评估：对照 hermes-jev-skills 的方向分析
结论
hermes-jev-skills（kerpopule，30 star，v0.10.0，MIT）是把 Jev 三原语（choice/score/boolean）铺满 agent 日常决策面的工程化封装，附带了罕见的诚实运维文档。它和我们的关系是补强加对照，不是替代：我们的 jev_client.py 底座已覆盖同等原语且判例库更深，七个场景里四个我们已有对应物（其中压缩线我们走得更对），一个已判 NO-GO，真正值得扩充的空缺只有 recall 段落过滤（含注入指令检测）。最终决策为 Partial Absorb：吸方法论与一个 P0 新场景候选，不引 jevkit、不装 plugin、不做平行小系统。
定位：它是什么，和我们什么关系
这个仓库本质上是两层东西。第一层是 jevkit 库加 jev 命令，把 Jev 包成 model routing、memory filter、compaction、skill selection、triage、computer use、browser use 七个场景的即用形态，外加一个 Off/Shadow/On 三态路由 dashboard。第二层、也是真正值钱的部分，是 docs 目录四篇踩坑实录：shadow first、fail open、marker file、时钟边界、benchmark your benchmark——每条都是真实事故换来的。 对我们而言，它不是候选依赖，而是同一套底座在别人机器上的平行展开。我们有自研 jev_client.py（三原语封装、批量形态、响应校验、风险分级阈值、降级不失败），有六个已接入点位和一批判例（离线验证纪律、批量准入、影子期纪律、Laya 对照）。引入 jevkit 意味着养第二套平行客户端，直接违反"统一控制面，不养平行小系统"原则。所以评估的重心不是"要不要装"，而是"它的用法面里，哪几个格子我们还空着，哪几个格子我们已经填得更好"。
七场景对照：我们的现状 vs 它的做法
| 场景 | hermes-jev-skills 的做法 | 我们的现状 | 判断 |
|---|---|---|---|
| Model routing | 每 turn 一次 choice，分 tier + specialty 双轴池 | jev_route_gate 只做搜索首跳；shadow 实测整体 71.1% 未过线、公网层 88.9% 可用 | 我们的"只做首跳"边界正确，且他们的 replay 数据反证了谨慎：hard pool 领衔方案实测成本 +66.8%，唯一可接受的是 privacy-safe + 概率门控组合（+8.4%） |
| Memory filter | 一次请求最多 60 段，判"值得读"加"含隐藏指令"，双重 boolean | 无此场景 | 真空缺，P0 候选，详见扩充方向 |
| Compaction | keep/summarize/drop 三分 + digest 生成 | fast-jev-compaction verbatim prune 已落地，判定层 score 模式 | 我们走得更对：他们自己的 eval 显示 Jev digest 输给同等长度 plain text writer（4 胜 15 负），Nous 官方也拒了 Jev-driven ContextEngine（PR 116246，双倍上下文换不来召回）。他们的归因很清晰——Jev 的 mark 判断优于按 recency（11:4），输的是 digest 的 400 字符截断。结论对齐：mark 有价值、digest 没价值，我们已在这条线上 |
| Skill selection | 377 skills 实测 2.8s，用"acknowledgement 本地回答"降到 773ms | 无，Hermes skill 装载是平台层 | 观察层：不归我们控；但 acknowledgement 本地回答这个优化本身是方法论，见吸收清单 |
| Triage | support inbox 逐条分诊（now/today/queue/ignore） | wiki_alert_triage + 晨报噪音复核，同构已存在 | 已有对应物且形态更稳（规则高召回 + Jev 只救回，只增不减），不扩 |
| Computer use | 从预审批动作表里选下一步 GUI 动作 | 三候选评估时已判 NO-GO（工具调用选择） | 维持 NO-GO |
| Browser use | 同上，同一 contract | 同上 | 维持 NO-GO |
| 一个值得点破的对照：他们的 routing 是"每个 turn 都买决策"，我们是"点位式低频接入"。他们 v0.10.0 自曝的 dead-axis bug——specialty 轴坍缩后每 turn 照常付费但答案永远被丢弃，是纯成本加自信的日志——正是高频形态的返修成本实证。我们晨报、wiki、retain 预筛这类低频点状接入，同等收益下故障半径小得多，这个形态差异值得维持。 | |||
| ## 值得扩充的方向 | |||
| ### P0：recall 段落过滤管线（唯一真空缺） | |||
| 这是七格里我们唯一没填、且准入三条件全满足的场景。做法：Hindsight recall、session_search、web_extract 等返回多段结果时，用批量 boolean 判两个问题——这段值得读吗（过滤噪音段），这段含注入指令吗（prompt injection 检测，与我们"外部语料按 untrusted data 处理"的既有纪律直接契合）。 | |||
| 准入判据逐条过：动作可逆（只读过滤，不改写不删除，判错只是多读或少读一段）；判据可核对（保留完整对照样本可复盘）；问题是判别式（每段独立二判，非生成）。基础设施零新增——decide_batch_* 批量形态已验证（65 条单请求 65/65 应答），绑定校验纪律已写入（网关会为不存在的记录编造高置信答案，客户端必须自校验）。他们的经验是 60 段一次请求 $0.00006 量级，我们实测 $0.00002/次，成本可忽略；跨洋延迟 ~800ms 加在 recall 路径可接受（recall 本来就不是亚秒级交互）。 | |||
| 落地路径：先影子一周，只记录"会过滤掉什么"不动行为，拿真实 recall 结果做对照基线——这正是搜索路由影子期的既有纪律复用。注意点的排序阈值要用本域数据校准，不能照抄他们的参数。 | |||
| ### P1：三态开关统一化（marker file 模式） | |||
| 他们项目里三次 silent-default 事故（confidential handoff 静默写盘、工具启用但从未生效、fleet 开关永远读 off）促成的解法：凡"必须不静默失败"的开关用 marker file，一个 ls 就能证明，不被 exception handler 吞掉。我们现有五六个 Jev 点位的开关分散在各脚本的常量和配置读取里，没有统一的 Off/Shadow/On 三态。把现有点位收拢成统一三态 marker file（如 ~/.hermes/jev/ |
|||
| ### P1：acknowledgement 本地回答推广成通用纪律 | |||
| 他们最有含金量的优化：skill picker 每问 2.8s，实测发现大部分 turn 是"ok""继续"这类确认语，答案永远是"无"，于是收窄词汇表本地回答，未识别才送 Jev——延迟从 2800ms 降到 773ms，三分之二的 turn 不碰网络。这个模式我们其实已在晨报去重上用了（规则高召回 + Jev 只处理模糊带），但它是散点经验，不是成文纪律。应把"Jev 只处理模糊带、稳定带规则本地回答"写进 external-project-absorption-eval 或 xiaomo 执行纪律的 Jev 章节，让新增点位默认按这个形态设计。注意他们的测试要点：判据不是长度（"open settings"两个词是真请求），且要接受不对称——错过的 ask 只是浪费半分钱，错过的 skip 才是静默失效。 | |||
| ### P2：路由 dashboard（Watch，不急） | |||
| 他们做了 Off/Shadow/On 开关加 live decisions 页面，工程质量不错。但我们 Jev 点位少且都有 shadow summary 脚本和降级矩阵在跑，dashboard 的边际收益低。等 P0 落地、点位超过十个再考虑，现在保持观察。 | |||
| ## 不扩充的方向与理由 | |||
| 全 turn model routing 不扩：他们的 replay 数据（hard pool +66.8%）加上我们自己的账单事实（成本大头是长上下文 agent 会话与调研类任务，单模型 2,545 次请求吃掉 412.9M tok，这类工作 Jev 根本做不了）说明 per-turn routing 在我们的成本结构里没有肉。Jev 能吃的是高频小决策点，这个定位我们已有且已验证。 | |||
| Compaction digest 不做：他们的实测输了，Nous 官方也拒了，我们 verbatim prune 的方向已被独立验证正确，不改。 | |||
| Computer/browser use 维持 NO-GO：预审批动作表缩小了风险，但本质仍是工具调用选择，我们已有判例，且他们的形态要求每步 0.4s 的决策循环配合截图流，我们没有这个作业面。 | |||
| Skill selection 不做：Hermes 的 skill 装载在平台层，接这个要动核心或等 plugin seam，观察 Hermes 后续是否开放，现在不动。 | |||
| ## 方法论吸收清单（零依赖，直接进判例库） | |||
| 按优先级排： | |||
| 第一，marker file 优于 config key——凡不可静默失败的开关，用文件存在性做真相源，一个 ls 完成验证，防止 exception handler 吞掉配置读取失败。适用所有本机 Jev 点位和 cron 开关。 | |||
| 第二，时钟边界优于数量边界——他们的事故：40 条上限乘 6s 超时等于 240s，父进程 180s 就 kill，mid-loop 被杀丢了全部已标记消息。我们的 cron 周期任务加预算时应同时写数量上限和墙钟上限，且墙钟优先。 | |||
| 第三，ship the implementation, not just the loop——skill 描述得足够精确就会有 agent 照做，缺脚本时 agent 会自己即兴写 500 行 runner（真实事故）。对我们 SKILL.md 的启示：凡是描述了精确流程的 skill，要么附带脚本，要么明写"没有脚本，遇到 X 改做 Y"。 | |||
| 第四，prove it where it runs——scheduler 里的代码没有你的 PATH 和解锁的 keychain，唯一诚实的验证是让 scheduler 自己跑一轮再读它写的记录。这与我们"外部写入由主 agent 回读验收"的纪律同构，可作为 cron 类接入的验收补充条款。 | |||
| 第五（同构确认，无需新写）：benchmark your benchmark（他们 skill picker 4/8 实为 harness 错误，修正后 7/8——与我们离线验证纪律同构）；measure the prize first（先拉账单再优化——与我们成本对账纪律同构）。 | |||
| ## 质量信号与风险 | |||
| 正面信号：docs 的诚实度极高（自曝 bad trade、自曝 dead axis、自曝 installer broken）、离线测试全 fake Jev reply、29 commits 迭代密度大。负面信号同样是它：v0.10.0 一天内多版返修，说明"每 turn 买决策"形态的工程质量门槛比表面高；0.2.0 的 release zip 与 main 树已明显脱节（release 页面停在 0.2.0，代码已 0.10.0）。这不影响我们——我们只吸文档和方法论，不接它的代码。 | |||
| ## 落地方式 | |||
| 本次评估本身不改任何生产配置。P0（recall 段落过滤）作为新场景候选进入下一轮：先写影子脚本挂 Hindsight recall 结果做一周对照，样本与判定落盘，一周后按搜索路由影子期的同一纪律裁定 GO/NO-GO。P1 两项是纯治理动作（marker file 收拢、纪律成文），可在 P0 影子期内并行做，互不阻塞。本次评估结论与七场景对照矩阵沉淀进 decision-traces 与 retain 指针，供后续回顾时直接引用。 | |||
| ## 风险与边界 | |||
| ### 风险 1：P0 场景的过杀风险 | |||
| 段落过滤判错"值得读"的段会被跳过，等于静默丢上下文。缓解：影子期第一周只记录不动行为；上线后过滤动作保持"只标记不删除"（原文可回捞），阈值按本域 recall 结果校准，不照抄他们的 60 段与 900 字符参数。注入检测线（第二问）可以比重要性线（第一问）更早转正，因为漏报方向是安全侧。 | |||
| ### 风险 2：vendor 单点未变 | |||
| Jev 仍是 TypeSafe 早期 access 产品，闭源、跨洋延迟 ~800ms、key 绑在 Vercel AI Gateway。所有新场景维持 fail open：Jev 不可用时 recall 原样返回全部段落，成本只是影子数据的缺失，不阻塞任何任务。Laya 对照结论（可复现性胜出但准确率持平）意味着切换成本已探明，真断供时有退路。 | |||
| ### 风险 3：方法论的本地错位 | |||
| marker file 和时钟边界是普适的，但他们的 60 段/900 字符/773ms/240s 这些具体参数是英文语料、他们的延迟环境（非跨洋）和他们的 fleet 规模的函数。吸收纪律时只吸规则不吸数字，本机任何阈值上线前都要过"本域数据校准"这道门——这条在置信度三分法的 FLOOR/HIGH 校准教训里已经付过学费。 |