Jev 的 8 项目清单：1 个无关，星最多的没进

9 月 19 日夜里，一条 X 上的清单转到我手上：8 个 Jev 项目，配一句「收藏吧」。发帖次日浏览过万，一百多个赞。 Jev 我一直在跟，所以看到清单没想着收藏，第一反应是：这 8 个是不是真的都在用 Jev？于是我把 8 个仓库逐个核了一遍：GitHub API 拉元数据（星数、fork、协议、创建时间、描述、话题标签），读完整 README，再翻顶层文件树和最近的提交。 结论先放这儿：8 个仓库都真实存在，但有一个跟 Jev 没关系；清单漏掉的，恰好是星最多的那几个。 ● ● ●

先把 8 个仓库摆出来

口径写清楚，后面的判断才站得住：星数是 9 月 20 日上午的一次读数。这个生态还在小时级地涨，同一天早上和前一天晚上的数字就能差出一千多，引用星数都得带时间。

仓库	星	建于	核验判
tamaratran/fast-jev-compaction	4337	9-17	名副其实，每次工具调用后用 Jev 判保留/压缩/丢弃
TianyuCodings/NanoJev	1000	9-17	描述属实，成绩不属实（见下）
reticlehq/reticle	742	6-11	误挂：跟 Jev 没关系
superagents-lab/jev-search	238	9-17	名副其实，Search1API 出品
y0usaf/pi-jev	86	9-16	名副其实，给编码 agent 加危险操作前的把关
kerpopule/hermes-jev-skills	57	9-18	名副其实，把 Jev 装进 agent 的五个接缝
Ying-Kai-Liao/jev-browser	17	9-16	名副其实，README 首行就写着「非官方，与 TypeSafe 无关」
ikermoel/open-alternative-jev	12	9-18	名副其实，全清单里方法学最讲究的一份

8 个仓库都能打开，没有一个 404。这话得说完整：存在不等于能用，这 8 个我一个都没跑起来，privacy 和降级行为都是读 README 读来的。 ● ● ●

有一个，从时间上就对不上

reticle 742 星，在清单里按星数排第三。它有三处对不上： 第一，它建于 6 月 11 日，比 Jev 发布（9 月 15 日）早 96 天。第二，它 README 的路线图那一节里写着 Jev，原话是「等我们做出那一层，Jev 会决定一次运行走哪条流程。 目前还没有任何东西跑在它上面。 」第三，它的描述里写「Jev 式」，话题标签里挂着 jev ，但同一份 README 的能力清单——路网、状态库、React commit 流、控制台、进程通信——没有一处依赖 Jev。 它不是假项目。这是个真的验证工具：agent 说自己做完了，它去查是不是真的，返回通过/不通过/说不清，外加文件行号。它只是把这个新概念写进了自己的定位描述里。 风险就在这一格。 jev 出现在描述和话题标签里，和「用了 Jev」是两件事，前者是给自己贴关键词，后者要能在代码里调出来。 ● ● ●

清单漏掉的，是牌面最大的那几个

清单里 8 个仓库的星数中位数是 162。清单外面， browser-use/jev-ultrafast 8935 星、 SemIf 1984 星、 laya 1442 星、 kev 564 星、 jev-review 358 星，一个都没进。

清单里的中位数，和清单外的头部 这份清单是按「接缝形态」挑的：压缩、浏览器、搜索、感知、复现、替代、门控、技能。这个挑法有价值——想知道一个决策模型能插进 agent 的哪些位置，它一页给全了。但它不是热度榜，也不是可用性榜。按形态读它，有用；按「最值得收」读它，会漏掉一半。顺带说，清单里最小的那个 12 星、最大的那个 4337 星，排在一起看不出差别，可前者是两天写出来的插件，后者已经有人拿它做产品。 ● ● ●

顺着清单，摸到三件它没写的事

一、Jev 已经有三家供应商。 jev-search 的 README 把三家并列写了出来，我另外去两家官方页核过：TypeSafe 自家 API 的 jev-latest ；Vercel AI Gateway 里的 typesafe-ai/jev ，页面上明写 Price: Free；Cloudflare Workers AI 的 typesafe/jev ，官方模型页有完整的 curl 示例，返回里 model 字段是 jev-1.13.0 。 那份 Cloudflare 示例值得一看：一段客服工单进去，三个问题一起回来——是否紧急 0.95，该哪个部门处理选中 billing 0.87，客户多大怨气落在「1.04」。最后一格的分档是 0、1、2，模型给了个 1.04。 Jev 到现在也没有开放权重，但从 Cloudflare 或 Vercel 的账号就能直接调它——两家官方模型页都给了调用示例，Cloudflare 那条返回里 model 字段是 jev-1.13.0 。不必等它的 waitlist。 二、有人把 Jev 装进了 agent 的五个接缝。 hermes-jev-skills 做的事：模型路由的升降级判定、记忆与技能列表的筛选、上下文压缩的选择、技能选择、以及 computer use 里「这一页该点哪」的判定。暴露给 agent 的工具名是 jev_memory_filter 、 jev_compact_select 、 jev_choose_action 。 它 README 里最像工程文件的一段，是把降级行为逐条写死了：没有 key、超时、限流、回复格式不对、置信度低——路由保持当前模型，记忆返回原始列表，压缩不丢任何东西，技能选择不推荐任何东西。默认不动作，是接这类模型时唯一安全的默认值。 三、我上一轮把它当成了「同名蹭热度」，判错了。 fast-jev-compaction 我早前扫生态时归进了「蹭名字」那一类。这轮读它的配置：默认 baseUrl 指向 api.typesafe.ai/v1/systemone ，模型是 jev-latest ，要配 TypeSafe 的 key。它是真在调 Jev，而且是这个生态里星数第二高的真集成。蹭热度的名单里该把它删掉。 ● ● ●

那个做压缩的插件，已经被人接进 agent 的循环里了

fast-jev-compaction 是个 Claude Code 插件，每次工具调用和返回结果都用 Jev 打一次分，判断哪些内容该压掉。往下追它，能追到两个 fork，分别用 TypeScript 和 Python 写的，9 月 18 日、19 日建，都把自己注册成 agent 的上下文引擎——也就是说，Jev 的判定不再只是「一个插件在判断」，而是接管了 agent 每一轮要保留哪些历史。 两个 fork 的作者还去上游提了 issue。第二个 issue 里有条更细的：他们说按源码，压缩器会先记下消息条数，再去调引擎的裁剪接口，如果接口返回的列表比原来短，后面的索引就越界，整个压缩挂掉，而用户看到的只是一句泛泛的「意外错误」。

每一轮要留哪些历史，交给一个判断模型 我按上游 main 分支的源码核了一遍这条：没核出来。压缩器全文用到那个条数变量的地方有六处，没有一处拿它当索引，而且它在第一轮裁剪之后重新数了一遍长度。另一个 issue 报的是某个名字未定义，会让所有引擎的实时配置加载崩掉——那个名字在入口模块里是显式 import 进来的，而报错的那个模块靠运行时从入口的名字空间里绑定，我核到它确实在绑定名单里。 两条都只做到静态读码，现场没跑。所以我的说法只到「照它给的位置没核出来」，不敢替上游宣布 bug 不存在——它指的可能是另一条新接口的路径，那条我没追到底。 ● ● ●

真实调用里，Jev 的分数长什么样

这是这轮最有信息量的一段，因为前面所有关于校准的讨论都停在文档口径，这里第一次有了别人在真实调用里的数字。 一处稳定性观察：同一条明显是临时性的内容，同一个输入，连续两次调用，第一次给 0.10（判为可以丢），第二次通过了。 另一处是分布。四个数学模型跑在线上 jev-1.13.0 上，五个样例各跑五次，外加一次 250 次工具调用的会话模拟：

打分对象	均值	标准差	离 0.5 有多远
结果类问题	0.25–0.40	≤ 0.022	稳定低于 0.5
「这个调用该不该留」	0.516	0.015	只差 1.05 个标准差
带收据的结果	0.25	—	全场最低

阈值往哪挪，结果差得很远：卡在 0.50 时削减 100%，0.40 时 78%，0.35 时只剩 13%。

同一个阈值挪一挪，结果差三倍以上 最后一行最反常识。带收据的结果——消息 id、已发送、已提交这类内容——Jev 打的是 0.25，全场最低。真正保住它们不被压掉的，是作者自己写的一条正则，不是模型的分数。 在这个真实用例里，模型做得最好的是排序，最不靠谱的恰好是最关键的那类内容。 ● ● ●

官方和框架在教同一件事：阈值归你

这轮顺手核了框架侧的集成，发现三家说的话是同一句。 pydantic-ai 里有个 TypeSafeModel ：把 output_type 的每个字段变成一个独立问题，一次请求抽多个值，换掉模型名就能让同一个 agent 改跑普通语言模型，直接对照。布尔字段按 typesafe_boolean_threshold 归一，默认 0.5。官方给的兜底是 FallbackModel ，把「拿不准」当成一种可以回退的失败态，和接口报错并列写进 fallback_on。 它文档里那句警告值得抄下来：一个问题如果同时权衡好几件事，它不会失败——它会返回一个看起来合理的数，配上很低的置信度，你事后才知道。 LangChain 那边是 TypeSafeClassifier ，用法是传状态和问题，拿回分类结果。两家加上官方自己的文档，都在说：阈值属于调用方，按自己的标注集校准，校准完把版本钉住——因为 jev-latest 会跟着官方发版往前跑，你调好的阈值会被悄悄挪走。 ● ● ●

以后再看到「N 个必收」，我会先查这四件事

一、看创建时间。早于产品发布日的仓库，要么跟它无关，要么是发布前就在做的，两种都不是「生态成员」。 二、读 README 里怎么自称。搜「非官方」「路线图」「还没开始」这类字样，自称独立的要标出来。 三、找能复现的调用。描述和话题标签里的关键词是贴上去的，只有代码里能调出来的接口才算数。 四、算星数中位数，再去看看清单外的头部。差得越多，说明它在按形态挑而不是按分量挑。 这四条不需要什么工具，一次 API 查询加十分钟读 README 就够。 清单本身没什么错，它挑的八个位置确实都是 Jev 能插进去的地方——压缩、搜索、浏览器、把关、复现。问题出在「收藏」这个动作上，它让人以为收下的就是全部。 我把这八个核完之后改的是一件别的事：以后这类清单我会当索引用，不当结论用。真正有信息量的东西多半藏在清单成员自己的 README、issue 和提交记录里，那些地方没人替你挑，也正因为这样，谁去翻谁先看到。 ● ● ●

参考来源

1. 01 清单原文（X，2026-09-19）：https://x.com/zhouluobo/status/2101452286270792061
2. 02 fast-jev-compaction：https://github.com/tamaratran/fast-jev-compaction
3. 03 NanoJev：https://github.com/TianyuCodings/NanoJev
4. 04 reticle（误挂案例）：https://github.com/reticlehq/reticle
5. 05 jev-search：https://github.com/superagents-lab/jev-search
6. 06 pi-jev：https://github.com/y0usaf/pi-jev
7. 07 hermes-jev-skills：https://github.com/kerpopule/hermes-jev-skills
8. 08 jev-browser：https://github.com/Ying-Kai-Liao/jev-browser
9. 09 open-alternative-jev：https://github.com/ikermoel/open-alternative-jev
10. 10 jev-ultrafast：https://github.com/browser-use/jev-ultrafast
11. 11 SemIf：https://github.com/TheoLeeCJ/SemIf
12. 12 laya：https://github.com/NandhaKishorM/laya
13. 13 kev：https://github.com/jaredpalmer/kev
14. 14 hermes-jev-compaction（TypeScript fork）：https://github.com/deadczarvc/hermes-jev-compaction
15. 15 hermes-jev-plugins（Python fork）：https://github.com/litshing/hermes-jev-plugins
16. 16 上游 issue（bug 报告）：https://github.com/NousResearch/hermes-agent/issues/115572
17. 17 Cloudflare Workers AI 的 Jev 模型页：https://developers.cloudflare.com/ai/models/typesafe/jev/
18. 18 Vercel AI Gateway 的 Jev 模型页：https://vercel.com/ai-gateway/models/jev
19. 19 pydantic-ai 的 TypeSafe 集成文档：https://ai.pydantic.dev/models/typesafe/
20. 20 LangChain 的 langchain-typesafe：https://pypi.org/project/langchain-typesafe/
21. 21 Hacker News 主帖（1915 分 / 501 评论，2026-09-20 读数）：https://news.ycombinator.com/item?id=49717558