做开源项目评测这些年，我发现一个规律：README 里最响的那个数字，往往是最没人回头核的那个。
所以这回我换了个做法。hermes-jev-skills 这个仓库，我不看它说自己多好，我把它自带的基准脚本全部重新跑了一遍——真金白银买了 Jev 的 API，6 个能复现的实验里 5 个逐格对上了。它是 9 月 18 日建仓、8 天 823 Star 的小项目，MIT，作者一个人维护。
但也是它自己承认了一件事，我先摆在这：README 里那张主图，今天仍然取自一台真实机器。 这一点它自己在 commit message 和脚本注释里写得很清楚，只是图一直没换。
它想做的事：让一个便宜模型替 agent 做小决定
你的 agent 每轮都在烧前沿模型的 token 做那些根本不是「思考」的事：这一轮该哪个模型答、377 个 skill 里该加载哪个、检索回来的哪几段值得读、转录要压缩时哪些轮次该留下、下一步该点哪个按钮。
这些是决定，不是文章。hermes-jev-skills 的做法是把它们交给 Jev——TypeSafe 的决策模型，它从不写文本，你给它一个状态和几道类型化问题，它回你一个带校准置信度的答案。十项技能分别是：模型路由、搜索、记忆过滤、handoff 压缩、轮次取舍、skill 选择、消息分诊、邮箱分拣、computer use、browser use。
这十项都以 SKILL.md 形式发布，所以不止能在 Hermes 上跑——Claude Code、Codex，或任何读 skill 文件的宿主都行。
架构上最值得记的一点：它把请求数当成一等成本。路由的三个问题和 skill 选择的 stage 1 问题被合并进同一次请求——Jev 按请求计费而不是按问题计费。这一点后面有实测数字。
实测一：6 个基准实验，5 个逐格复现
先说方法，因为这是这篇的核心。仓库里每个 scorecard 都附了能「reproduce every number here」的脚本，我就照着跑。做法是：在沙箱里 clone、装一个只有 PyYAML 的 venv，然后用真实的 Jev API key 跑它自带的标定脚本。不是读文档，是重算。
先说不动用网络就能验的：
| 项 | 结果 |
|---|---|
主测试套件 tests/ |
1020 个测试通过（skipped=1），28.6 秒，全离线 |
| dashboard 测试 | 71 个测试通过，2.25 秒 |
jevkit 第三方依赖 |
零（AST 扫描：纯标准库） |
那 1020 个测试用的是内置 fake transport——这一点它自己在测试文件里点明了：如果 fake 发出的分布形状是 API 根本产生不了的，那套件就会变成「绿着测校验器的拒绝路径」。这句话说明作者知道「测试全绿」本身可以骗人。
然后是花钱的那部分。下面每个数字都是我这次实跑的输出，和仓库 scorecard 对照：
| 实验 | 我测到的 | 仓库 scorecard | 判定 |
|---|---|---|---|
calibrate_choose.py |
31 cases · 0 wrong actions | 同 | 逐格命中 |
calibrate_choose_match.py --runs 3 |
floor 0.65：right 23 / stalled 1 / wrong 0 | right 22-23 / stalled 1 / wrong 0 | 逐格命中 |
calibrate_choose_stakes.py --runs 3 |
18 个 gate family 全为 69/1-1/21/0 |
同表 | 全表命中 |
calibrate_choose_permutations.py |
solo Brier 0.032 | 对照值 0.032 | 命中 |
calibrate_skill_stage2.py --runs 2 |
单轮折算：stage1 only right 10 / spurious 4；stage1+2 right 14 / spurious 0 | 同口径 | 命中 |
calibrate_skillpick_permutations.py |
结构一致（10/0/4/0） | 11/0/3/0 一行不同 | 部分 |
几条值得单独讲的。
那个 trap case 每次都出现在同一位置。31 个用例里有一个是 Cancel this dialog without losing my work，而错误答案是 Save。原文写它的置信度在五轮里是 0.45-0.60，每一轮都落在 0.65 地板之下，所以从没被放过。我这次测到 0.40 和 0.44——机制完全一致。这种「错答案稳定地出现在地板以下」不是运气，是校准。
分离性数字也对上了。「这个屏幕上没有正确答案」这一类，我用第二个问题测出的上界是 0.45（原文 0.43-0.45）；而正常可答类的下界是 0.78（原文 0.75-0.80）。
permutation averaging 那条结论被复现了，而且是以它失败的方式。有一种做法是把选项顺序打乱多次、把概率向量平均。我实跑的结果是：在 0.65 地板上，averaging 把那个本该被拒的 trap case 变成了 1 个 wrong action——而单次调用是 0 个。仓库据此没有采纳这个做法。它甚至补了一句更狠的：那个错答案在三次重复里有两次是全体一致答错的，所以「一致性检查」这种安全阀根本拦不住。
唯一没逐格对上的是第 6 个，因为口径不同：那个脚本优先读机器上的 fleet catalog（原文是 459 个 skill 的目录），沙箱里没有，于是回落到仓库自带的 10 个 skill。结构对上了，数字不能逐格比。我把这条明确标出来，不混进「5 个命中」。
实测二：数字能验，但有一处它自己承认的缺口
既然数字这么硬，那篇宣传的缺口在哪？
缺口不在基准，在主图。README 介绍 dashboard 那张截图，caption 写着「profiles, paths and decisions here are a demo home」。但图本身来自一台真实机器。
这是我这次用 git 历史而不是看图确认的：
| 证据 | 内容 |
|---|---|
| 图的引入 | commit 0a15c12（2026-09-19 23:32），此后从未被替换 |
| 自陈的那次 commit | c5875aa（2026-09-20），标题是 Make the README screenshot reproducible from invented data |
| 该 commit 改了什么 | 只新增 scripts/demo_home.py、改 caption、改 CHANGELOG——没有动那张图 |
c5875aa 的 commit message 原话是：「The image was taken from a real machine under a caption calling it demo data, which is how a working fleet’s model strategy got published.」它同期新增的 demo_home.py 注释里写着「that is how the current image ended up showing a real working pool set」。
也就是说：作者发现了这个问题、写了工具来生成假数据、在文档里解释了这件事——然后忘了换图。caption 里那句「the pools are a real working set」直到今天还在。
顺带说，demo_home.py 本身有个小 bug 我顺手复现了：它把 --help 当成输出目录路径（main() 直接取 argv[0]，不解析参数），所以 python3 scripts/demo_home.py --help 会在当前目录建出一个名叫 --help/ 的目录树。这不是安全问题，但是这类「脚本没走参数解析」的痕迹。
还有个细节：README 那张表，一半数字买得到一半买不到
这是我觉得最值得记的一条，因为它解释了这个仓库的诚实边界在哪。
README 顶部有一张十项能力的表，每项配一个「Measured」数字。我按「外部人能怎么验」把它们分了三类：
| 类别 | 能力 | 情况 |
|---|---|---|
| 能重跑出数字 | choose（两问门、stakes/margin、permutation）、skill 选择 stage 2 | evals/choose-match/、evals/skill-pick/、evals/permutation-averaging/ 有 scorecard，我这轮全跑了并对照 |
| 有脚本、但要你自己的数据 | 记忆过滤（evals/context-filter/regret.py）、computer use 的质量（evals/plan-quality/、evals/representative/） |
脚本要求「locally held labelled observations」——人类裁决过的真实任务标注，仓库不含语料，也不许用 mock 推断 |
| 有 scorecard、但数据明确不公开 | handoff 头条那个「58.7% recall alone, 75.0% with one search」 | 出自 evals/compaction/results/SCORECARD-2026-09-20.md |
也就是说：十项能力里，外部人能独立重算出数字的只有三类模型侧决策；涉及真实会话和人工标注的那几项，谁都验不了。这和我上一篇评 laya 是同一件事，只是程度不同——laya 的头条数字连产物文件都没有，这里的第二类至少把脚本和验收口径都写清了（representative/compare.py 甚至会「reject missing arms、duplicates、unknown completion」而不是替你猜测成功），只是语料在你手上。
第三类最值得单说。那个 handoff 数字出自一套实验，输入是 7 个真实工作会话（243 到 614 行、含大量工具调用）加每份 15 道题的考卷。仓库的 README 里写着「Transcripts, exams and capsules stay off this repo」——数据不公开，所以任何人都复现不了，包括买了 key 的我。而这恰好是它全站最响的那个数字。
我特意核对了这段的表意，因为它容易被误读。这张表里 Jev 的表现是分裂的：
| 对照 | 结果 | 说明 |
|---|---|---|
| Jev 的取舍标记 vs 按 recency 标记 | 11 胜 4 负 | Jev 的判断确实更好 |
| 但 Jev 摘出来的 capsule vs plain tail | 37.5% vs 48.1% | 靠 Jev 写出来的胶囊反而更差 |
作者自己解释了原因：一个被标为「summarize」的轮次只保留前 400 字符，而七个会话里有五个平均每轮 1,400 到 7,400 字符，任何取舍策略都救不回被裁掉的部分。所以它没有采用 Jev 版 handoff，而是改成整段对话（上限 300,000 字符）+ 1,200 词预算。
这是整个仓库最诚实的一处：它测出自家核心功能没有更好的方案，就没上。表里那些「looked obviously right、measured、not shipped」的两行实验也一样。
还有一处：它把「不省事」也写进文档了
三条我觉得值得抄的工程习惯。
一、fail-open 不是口号，是实测。我在沙箱里故意不给 key 跑：jev doctor 仍然退出码 0；jev mail 把消息标成 unsorted、not_sent_to_jev: 1，而不是崩掉。README 的说法是「No key, timeout, rate limit, malformed reply, low confidence: routing keeps your current model, memory returns the original list, compaction drops nothing」——每一条都有对应的测试。
二、有安全护栏不依赖 Jev 答对。比如「风险词（production / delete / migration / security / payment / legal）永不被路由到最便宜的档」、「大上下文不在会话中途切更便宜的模型」、「转录轮次只在有把握时才丢」。这类护栏的意义是：决策模型错了，损失有上界。
三、隐私边界写得很具体，包括它做不到的部分。README 里有一整节「What leaves your machine」，逐项列出每个功能发出去什么：路由发的是被脱敏的用户这一轮（邮箱、手机、token 遮蔽，上限 2,500 字符），绝不含历史、工具结果、文件、记忆；而且它明说了一个不完美处——默认模式下路由发的是这一轮本身，「the agent has no say in that, because routing happens before it acts」，要彻底不出机器得配 private_profiles。邮箱那条更细：邮件是先解码再筛查（quoted-printable、percent-encoding、HTML entity、base64），因为「a newsletter footer carries your own address percent-encoded in the unsubscribe link」——纯文本脱敏器两个都看不见。
放到同类里看
这一篇要横着比，最自然的坐标是我昨天刚评完的 laya——同样是「决策不用生成」这条路线，同样有 Jev 作为对比对象，同样把「自家模型接近随机」这种难看的数字写在主文档里。
但两者的证据链是镜像的。laya 的 6 张基准表我离线复算逐格命中，而它全站主打的 0.766 准确率在仓库 14 个结果 JSON 里找不到任何支撑文件——那个数字出自一个保存输出数为 0 的 notebook。hermes-jev-skills 反过来：它最响的那批数字（路由、skill 选择、choose 校准）我买了 key 就重跑出来了；它的缺口在一张图，而那张图是它自己公开承认过的。
第二个坐标是评测方法论本身，和我写过的 addyosmani/agent-skills 复测 是同一个问题：自带评测的项目，它的分数该不该信。那次是 25 个技能自评 100% 全绿、我只对上 24%；这次是 6 个基准我复现 5 个，缺口在配图。一个稳定的规律正在形成——看它的评测脚本能不能被你重跑，比看它的分数高低有用得多。
如果你要一句话判断这个项目值不值得看：它的方法论比它的代码更值钱。 把「looked obviously right、measured、not shipped」写进 CHANGELOG、把自己输掉的对照表留在文档里、把「测试全绿可以骗人」写在测试文件顶部——这些习惯，比它那 823 个星更能说明这东西靠不靠得住。
适合谁：跑多 profile agent fleet、模型账单肉疼的团队（路由 + 合并请求直接省钱）；要自托管、不想把工具结果发给第三方做决策的场景（它的隐私边界写得很细）；任何想学「怎么诚实地做自评基准」的开发者。
不适合谁：只想开箱即用的人——它要 Jev 的 key，而 TypeSafe 目前不接受新注册（README 明写），得走 OpenCode Zen 免费层或 OpenRouter 才能起步。不用 Hermes 的人也能用那十个 SKILL.md，但 dashboard 和插件接缝是给 Hermes 做的。以及：它的 README 主图目前还不可信于「demo」二字——这事作者知道，只是还没换。
结论
工程纪律一流，数字经得起重算，缺口是它自己认下的那张图。
我买的 Jev key 花的钱不到一毛（几个 scorecard 自陈总额 under $0.05），换回来的是 5 个基准的逐格复现。在这个「自评数字满天飞」的赛道里，能做到这一点的项目是少数。
但它提醒了我一件更重要的事：连一个连自己输掉的实验都写进文档的作者，也会忘了换掉一张图。所以我的做法还是那句——别信 README 里最响的数字，去把它的脚本跑一遍。跑得出来，那个数字就是你的；跑不出来，它只是个声明。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：