Codex 装上 Jev 决策快 200 倍，Jev 系第一个出圈的 CLI 是它

Codex 装上 Jev 决策快 200 倍，Jev 系第一个出圈的 CLI 是它

【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep

2026 年 9 月，AI 圈被一个"不说话的模型"刷屏：前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立的 TypeSafe AI 发布 Jev，只输出"选择 + 概率"，不生成一个字。紧接着，开发者社区里流传开一组实测数据——给 Codex 装上 Jev 判断模型后，Agent 决策比 LLM 快 40–200 倍，便宜 40–400 倍，输出 Token 免费。就在这波热潮里，一个叫jevgrep的开源 CLI 悄悄成了 Jev 系第一个出圈的工程化产物：它把 Jev 的"选择 + 概率"能力翻译成一条命令，让编码 Agent 用一句话找到仓库里真正相关的文件与源码上下文。

本文不写"Jev 有多神"的观感文章，而是把两件事对齐：一是社区实测数据背后的模型定价与延迟逻辑，二是 jevgrep 仓库里真实存在的检索架构与成本审计证据。哪些数字可信、哪些数字需要区分口径，看完你心里会有数。

判断模型的数据从哪来：40–200 倍与 40–400 倍背后是定价结构

先说社区流传最广的两组数字。9 月下旬有开发者实测在 Codex 中接入 Jev 判断模型，报告"Agent 决策比 LLM 快 40–200 倍、便宜 40–400 倍"，输出 Token 免费；同一时期，Jev 的定价被多个渠道反复引用：输入 0.042 美元 / 百万 token，输出免费。这个价格结构是理解"快 200 倍、便宜 400 倍"的关键——Jev 不是不生成文本的"哑巴"卖点，而是一个把成本从"生成"换成"判断"的定价模型：它只对喂进去的上下文计费，判断结果本身不产生输出 token。

快，来自它放弃自回归生成、直接输出离散选项概率的推理路径；便宜，来自输出免费 + 极低的输入单价。但这里必须把口径说清楚：40–200 倍 / 40–400 倍是"Jev 判断本身 vs LLM 生成"的单项对比，不是端到端 Agent 任务的总成本对比。仓库里 jevgrep 自己的 SWE-bench 审计数据用的是另一种口径，同样值得看。

evals/results/total-cost-2026-09-28.md 记录了含 Jev 在内的十任务总成本审计：使用发布版@dzhng/jevgrep@0.4.3，保留与无 Jev 基线相同的8/10 官方 SWE-bench 解决数，总成本从$7.6221 降至 $5.6564，下降 25.8%（含两次未解决任务的失败成本）。其中 Sol 侧 $4.1780，Jev 侧 $1.4784。Jev 成本按列表价jev-1.13.0输入 $0.042/M 估算，输出免费——这正是"判断模型便宜"的记账体现。

配图：

更早一轮只计 Sol 成本的审计（evals/results/relevance-threshold-2026-09-27.md）显示 28.63% 的编码 Agent 成本下降，README 里对外宣称的"约 30%"即源于此；而含 Jev 的 25.8% 是后续补上的全口径数字。速度方面，evals/results/speed-2026-09-28.md 记录了一组同查询诊断对比：Jev 原生 TypeSafe 端点中位延迟 140ms，而经 Vercel Gateway 中转为 330ms，整个搜索流程从 43.4 秒降到 34.3 秒，且原生端点无错误、Gateway 则恢复了 64 次内部 503。这就是为什么 jevgrep 在 0.3.0 之后把 Provider 路由做成可选项——见 packages/core/src/providers.ts，内置 Vercel AI Gateway、TypeSafe、OpenRouter、OpenCode Zen 四个预设端点加自定义端点，jg auth交互式选择后保存凭据，搜索全程走同一条 Provider。

jevgrep 如何把"选择 + 概率"变成文件定位

Jev 的 API 一次返回多个布尔问题的概率。jevgrep 的核心工程，就是设计一套"怎么问、问什么、拿概率后做什么"的检索协议，把一次次的判断题串成一条从目录到代码行的定位流水线。

架构文档 docs/architecture.md 把它概括为分层遍历 + 内容采样预算：不先把整棵树上传给模型，而是用目录元数据与内容预览决定探索方向。落地到 packages/core/src/retrieve.ts，是三层渐进式筛选：

1. 目录级试读：对每个目录，先发送最多 64 个条目的文件名与扩展名分布（previewDirectory），让 Jev 判断"这个目录值不值得探索"——对应 packages/core/src/requests.ts 中navigationRequest的目录问题。
2. 文件级预览：对候选文件发送开头 16KB 的采样内容（previewFile），让 Jev 判断"这个文件是否提供实现、调用方、测试或配置证据"。
3. 声明级精确定位：对通过的文件，用 Tree-sitter（Python/Go/Rust）或 TypeScript 编译器解析出函数/类声明（packages/core/src/source.ts 的inspect），按批次把"这段声明是否直接实现或控制目标行为"以及"这段声明是否在目标 API 的作用域内"作为独立布尔题提交。

每次提问返回的都是一组概率：q0..qn对应每个条目的相关性。jevgrep 用三层阈值消化这些概率——packages/core/src/retrieve.ts 中relevanceBoundary = 0.5（准入门槛）、weakScoreCeiling = 0.6（强信号）、packages/core/src/selection.ts 中sourceConfidenceBoundary = 0.7（可展示摘录门槛）。值得注意的是，同一请求里 Jev 一次回答多条判断题，所以目录批次 128 条、字节上限 38KB 的批量策略（见score函数）能把"每次决策"的往返成本摊薄。

这套协议里有几个细节值得单独说：

• 反悔机制：上下文跟进阶段（selectFile里的 contextual rejection），只有"有效证据明确否定"时才收回先前选中区间；失败或未处理的组保留原有证据（packages/core/src/selection.ts）。这保证一次失败判断不会抹掉已获得的证据。
• 内容哈希校验：每次请求发出前，freshEvaluation会重新校验源文件的 contentHash，防止"文件刚被编辑过，模型判断的却是旧内容"（packages/core/src/retrieve.ts 的unchanged）。
• 导航字节预算：navigationByteBudget = 8_000_000，在确认到高置信度源码之前，探索阶段的序列化字节数超过预算就停止并如实上报"发现不完整"（apps/cli/src/render.ts 中对应low_confidence_budget提示），而不是假装搜全了。
• 本地答案缓存：判断结果按请求+命名空间做 SHA-256 键缓存七天（packages/core/src/cache.ts），重复提问不重复付费。

最终 stdout 输出格式见 specs/done/jevgrep/assets/stdout-example.txt：先是文件清单与角色标注，接着是带行号的逐字源码摘录，最后是声明与调用位置表。README 的定位很克制："输出是给 Agent 的证据，不是生成好的答案，也不保证找到每个相关文件。"

Codex 生态里还有多少 Jev 系工具在路上

jevgrep 是 Jev 出圈的受益者，也是最早的工程化样本之一。它的集成方式很能说明 Jev 系工具的分工思路：CLI 只负责"发现证据"，实现与测试全交给调用它的 Agent。jg skill命令通过 skills CLI 把 skills/jevgrep/SKILL.md 装进 Claude Code、Codex、OpenCode 等 Agent 的工作目录，skill 内容严格限定在"何时调用 jg、如何读输出、不完全结果如何处理"，不掺入调试或实现建议——apps/cli/src/skill.ts 里甚至会在安装时自动检测当前环境里的 Agent 类型。

为什么"文件发现"成了 Jev 系第一个出圈的应用场景？因为编码 Agent 的痛点恰好是 Jev 的强项：Agent 面对陌生仓库时最常犯的错是"关键词搜不到、盲猜文件位置、把叙事性文档当实现"。这正是一个高置信度的选择题——"这个文件夹/文件/声明是否直接承载查询描述的行为"——而非需要生成能力的开放题。Jev 系的其他方向也在同步铺开：基于 Jev 的浏览器 Agent 插件已在 GitHub 狂揽 21k star，把"决策快、延迟低"用到页面操作路由上；本地可部署的 Laya 等判断模型也在做 Agent 路由与 RAG 排序。Jev 生态的路径已经清晰——判断模型负责把"要做什么"翻译成"选哪个"，而 jevgrep 证明了这条路径在代码仓库检索上能先跑通、能量化、能省钱。

回到开头的问题：Jev 系第一个出圈的 CLI 为什么是它？因为 jevgrep 没有去蹭"判断模型很聪明"的叙事，而是把 Jev 的概率输出、定价结构与工程预算管理组装成一个可复现的检索协议，并用 SWE-bench 十任务审计给出了同解决率下约 26%–30% 的成本下降。数据口径不同（40–400 倍是单点决策对比，30% 是端到端任务对比），但两者指向同一个结论：当决策从"生成"变成"选择"，Agent 的工作流确实变快、变便宜了——而 jevgrep 是这个转变里第一个能拿出手的代码侧落地案例。

【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep