扒开 jevgrep不上传整棵代码树三层筛选怎么省下近三成 token【免费下载链接】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/jevgrep2026 年 9 月一个不生成文本、只输出选择与概率的判断模型 Jev 刷屏开发者社区TypeSafe AI 把它定位为 System One 模型输入定价 0.042 美元/百万 token、输出免费。很快GitHub 上冒出一个以它为引擎的开源 CLI——jevgrepjg宣称能在 SWE-bench 任务里让编码代理的总成本下降约 30%。这类省 token的叙事并不新鲜真正值得拆的是机制它怎么做到不上传整棵代码树就把相关文件找出来三层渐进式筛选、内容采样预算、锚点反悔机制这些名词背后代码里到底是怎样实现的本文直接进入 packages/core/src/retrieve.ts 与 packages/core/src/selection.ts结合仓库公开的 SWE-bench 评测记录逐层还原这条省钱路径。一、分层遍历的设计动机为什么不能把整棵树喂给模型编码代理面对陌生仓库时最大的开销不在写代码而在找代码你告诉它去调查遥测事件是怎么记录和发送的它不知道该读哪个文件于是要么暴力 grep、要么把大片目录塞进上下文——后者在 Sol 这类生成模型上按 token 计费前者在跨文件语义场景下经常扑空。社区里对 jevgrep 的讨论也集中在这一点它解决的正是知行为、不知位置的检索问题。而 Jev 本身是个判断模型给它一段内容加一道有固定选项的题它返回每个选项的概率不生成 token。这意味着它可以被用来做分类器但每一次调用都要把待判断的内容作为输入上传。如果天真地把整个仓库作为一次输入一个中等规模仓库几 MB 到几十 MB 的源码按 Jev 的输入计价并不便宜而且上下文窗口也吃不消。jevgrep 的答案是把相关性的判断拆成一个三层漏斗每一层只上传足够做判断的采样目录级试读只上传目录条目清单文件名、类型、扩展名统计问 Jev这个目录值得往下探索吗文件级预览只上传文件开头最多 16384 字节与声明索引问 Jev这个文件对查询有用吗声明级精确定位用 Tree-sitter/TS 编译器把通过筛选的文件切成声明单元函数、类、方法按块上传逐个问这段源码是否直接实现/控制/测试了目标行为。看 packages/core/src/retrieve.ts 的previewDirectory目录预览被硬性压到很小的体量最多收集 64 个条目、序列化后不超过 4096 字节超出即标记truncated并停止。previewFile则只取文件开头 16384 字节作为预览文本超长文件再叠加 Tree-sitter 解析出的声明名与行号索引且声明索引本身也被限制在约 32KB 序列化上限内。换句话说分层遍历的每一层都在用足够决策的最小字节数换取一次 Jev 判断而不是把候选内容整个搬上去。还有一个容易被忽略的设计筛选结果没有固定 top-N 上限。所有通过阈值的路径都被保留在candidatesMap 中分数高于 0.5 即准入并按分数排序输出。这是对社区常踩的坑的反向设计——很多检索工具硬性返回Top 2/3恰恰会把真正有用的第 5 个文件丢掉迫使代理再花一轮 token 去补查。二、内容采样预算与锚点反悔机制试错成本怎么控分层遍历解决了该看哪里但 Jev 判断本身也有成本而且存在一个现实风险弱相关的正分数会让检索无限扩散。设想一个 6300 文件、全部得分 0.51 的仓库——如果每个弱正目录都继续展开请求会指数级放大。jevgrep 用两个机制把试错成本焊死其一导航字节预算 弱正分数洪泛抑制。retrieve.ts顶部定义了navigationByteBudget 8_000_0008MB 序列化请求字节以及relevanceBoundary 0.5、weakScoreCeiling 0.6、minimumPositiveScores 32三个阈值。navigationAdmissions的逻辑是如果还没有出现任何强证据score ≥ 0.6而 0.5–0.6 之间的弱正条目已经攒了 32 个以上就整体抑制这批弱正条目不让它们继续入队展开单个孤立的弱正线索则照常保留避免误杀。预算侧只要尚未确认到有信心的源码confidentSourceSeen导航阶段的累计请求字节一旦超过 8MB 就暂停入队如果最终仍未确认源码直接上报low_confidence_budget并建议收窄搜索根。仓库里的确定性回归测试显示一个合成的大规模弱正仓库会在 252 次假评估、约 7.97MB 序列化字节处停下返回空结果加一段显式incomplete报文——而如果不设这个预算同场景要打到 1000 次请求上限、上传 31.6MB。其二锚点反悔机制anchor retraction。检索是渐进式的早期判断可能错必须允许翻案。代码里有两处明显的反悔通道类关系锚点relationship anchor主遍历会优先筛出一个包含.context类单位的文件作为锚点anchor然后对被剪枝的目录做一次带内容采样的重新评估——withDirectoryContent对目录内每个文件按perFile max(80, floor(16000/文件数))字节采样三个片段开头、中间、结尾并以锚点类的名义询问这里是否有声明/继承/覆写/直接使用该类关系的源码。这能找回跨平台、跨目录的同类实现即使它们与查询语言不同。评测记录里有个关键教训最初把关系问题写成未绑定具体条目的通用指令时同类子类分数从 0.23 涨到 0.91但无关文件也一起涨到 0.90——证据串扰。修复方式是每个问题显式绑定state.items[i]及其路径同类回升到 0.97 而无关控制组保持 0.02–0.07。声明级证据反悔selection.ts中声明单元的判定包含 relevance、scope、reference 三个维度。一旦后续拿到具体引用证据prepared.evidence某段代码分数 ≤ 0.5就会把之前选中的 span按区间收缩selected数组被拆掉重叠部分只有有效的上下文反驳才能撤销先前的选择失败的判断绝不抹掉已获得的证据。这背后还有一层字节级校验兜底每次调用 Jev 前都会做contentHash新鲜度校验freshEvaluation里的unchanged源文件在遍历期间被改动、替换或删除相关缓存与证据立即失效防止用旧快照做判断。所有 Jev 回答还会按namespacemodel、provider、policyVersion、parserVersion、promptVersion做 SHA-256 缓存TTL 7 天、容量上限 256MB重复查询直接命中缓存这在 packages/core/src/cache.ts 里实现。三、28.6% 成本下降在 SWE-bench 上是如何兑现的现在回到核心数字。仓库评测记录 evals/results/relevance-threshold-2026-09-27.md 给出的最终冻结队列结果是10 个 SWE-bench 任务中jevgrep 与无 Jev 基线各解出 8/10编码代理Sol成本从 $7.6220690 降到 $5.4396530——28.63% 下降且基线原有的 8 个 solve 全部保留失败尝试的费用也全额计入分母任务jevgrep基线Sol 成本对比django__django-15629passpass$1.2286 / $1.5055pytest-dev__pytest-6197passpass$0.8281 / $2.3445scikit-learn__scikit-learn-13124passpass$0.2641 / $0.2944psf__requests-1142passpass$0.2915 / $0.2685astropy__astropy-13579passpass$0.4586 / $0.4286pydata__xarray-3305passpass$0.3529 / $0.4937sympy__sympy-16792passpass$0.5613 / $0.5480sphinx-doc__sphinx-8638passpass$0.7049 / $1.0595matplotlib__matplotlib-26466unresolvedunresolved$0.2637 / $0.3957pylint-dev__pylint-4604unresolvedunresolved$0.4860 / $0.2836最戏剧性的是 pytest 任务代理成本从 $2.3445 直降到 $0.8281——在没有 jevgrep 时代理会反复 grep、反复读错文件每次都是真金白银的 token有了精确的文件与声明级证据探索轮次大幅收敛。注意这只是编码代理端的成本Jev 的费用单列。把 Jev 计入总成本的复测evals/results/total-cost-2026-09-28.md依然维持 8/10 解出总成本 $5.6564 对基线 $7.6221即25.8% 下降。另一个佐证是 token 本身速度研究 evals/results/speed-2026-09-28.md 显示与无 Jev 基线相比全队 Sol 输入输出 token 从 9,933,430 降到 5,810,284减少 41.51%墙钟时间也快了 12.7%。三层筛选省下的正是这些本会被盲目读进上下文的 token——目录预览避免了展开无关子树文件预览避免了整读无关文件声明级选择避免了把整个文件包括无关部分塞给代理。当然口径必须讲清楚这是10 个经过调优的 Python 任务、单次首尝试、冻结的安装包与公开 skill 下的观测值仓库文档反复强调它不是 holdout、不构成跨语言跨仓库的统计等价性。逐任务看Requests、Astropy、SymPy、Pylint 单看反而比基线略贵——聚合省钱不承诺每任务省钱。这一点在 evals/cost-quality-policy.md 里被写成硬规则官方 solve 是主指标全任务成本必须如实报告失败的尝试也计入分母不允许挑成绩最好的重跑来凑数。小结jevgrep 的~30%不是营销话术而是三层渐进式筛选的工程结果目录级试读把判断成本压到每次 4KB 级文件级预览用 16KB 采样与声明索引做二次淘汰声明级定位只上传被切碎的、有明确行号边界的源码块8MB 导航预算、弱正洪泛抑制与内容哈希校验把失控扩散和脏快照挡在门外锚点反悔则给早期误判留了纠错通道。最终在 SWE-bench 上以 41.51% 的 Sol token 减量换来了 28.63% 的成本下降且不牺牲解出率。对于所有被上下文越塞越贵困扰的编码代理开发者这套最小决策字节 可反悔的渐进判断的组合比任何把仓库灌进提示词的方案都更值得抄作业。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考