jevgrep 架构剖析分层遍历 内容预览Jev 如何不上传整棵树就锁定代码位置【免费下载链接】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/jevgrepjevgrep 是一款面向编程智能体的代码搜索 CLI你用一句自然语言提问它基于 Jev 模型通过分层遍历仓库目录、内容预览文件返回最相关的文件与源码片段帮助 coding agent 快速定位代码。本文剖析它的内部架构看懂它如何在不上传整棵树的前提下锁定代码位置。它解决什么问题 编程智能体接一个陌生任务时最耗 token 的环节往往是找文件反复ls、rg、读文件把半个仓库塞进上下文。jevgrep 的思路是——让 Jev 替 agent 判断哪些目录值得进、哪些文件值得读最后把文件列表 逐字源码摘录 行号一次性打到 stdout。一句话流程来自 docs/architecture.md问题 → 目录 → 文件 → 源码单元 → stdout它先不上传整棵树而是用目录元数据 内容预览决定往哪走。这正是下面三个阶段的核心。第一阶段分层遍历目录级试读 遍历逻辑在 retrieve.ts 的discover()里约 L297–L395是一个逐层广度优先搜索第 0 层目录只看名字根目录的直接子目录直接进队列连预览都省了更深的目录先做目录预览previewDirectory() 只采样最多 64 个条目、约 4KB 的元数据子项名称、文件/目录计数、扩展名分布就够 Jev 判断这个目录值得探索吗Jev 回答布尔问题概率 0.5 才放行每个目录/文件都会收到一个navigationRequest见 requests.ts问题大意是这个目录是否值得为本次查询探索文件名与元数据作为证据。低于阈值的分支直接剪掉没有固定 top-N通过标准的文件全部保留不会因为只取前两名漏掉证据硬性资源上限单次搜索最多看 10 万个条目、单文件 1MB 封顶防止失控。这意味着一个只有目录名就足以排除的vendor/永远不会被打开读取。第二阶段内容预览文件级试读 对通过目录关的分支jevgrep 同样不上传全文而是构造有预算的内容预览文件预览 开头 16KB 文本previewFile()超限文件则切分成 12KB 的采样块逐块送评判断这段源码是否直接实现了目标行为而不是泛泛相关Python / TypeScript / JavaScript 额外附声明索引先用内置解析器source.ts抽出函数/类声明与行号范围让 Jev 一眼看清文件骨架目录的内容级复查有精细预算withDirectoryContent() 给目录内每个文件按16000/文件数字节分配预算最低 80 字节采样开头 中部 结尾三段整体超 28KB 就按比例缩水——每次发给 Jev 的内容都有硬上限。其他语言含无法解析的文本统一退化为有界源码块保证任何仓库都不会卡死在解析上。第三阶段声明级选择精确到行 文件入选后selection.ts 的selectFile()把文件切成语法单元声明级单元超 24KB 的单元按 16 行再切块然后向 Jev 提出三类布尔判断evidenceRequest问题作用q相关性这段代码是否直接实现或测试目标行为包含 bug 的当前实现也算scope范围是否属于查询点名的那个 API/组件而非功能相似的另一个 APIref引用是否被已选证据具体引用用于把相关声明拉回来通过判断的声明连同其局部调用上下文call-context.ts成为最终摘录被标记为测试文件的还会额外挑选相关 test bodytest-body-selection.ts。解析失败时退化为 3000 字节的有界文本块——失败不丢证据只降级粒度。一次反悔机制锚点复查 剪掉的目录并不会彻底出局。若某候选文件里发现了.context类锚点jevgrep 会把之前所有被剪枝的目录重新做内容级评估retrieve.ts问题变成该目录是否声明/继承/使用了锚点类。这相当于给首轮只看名字的判断一次带上下文的重审机会——但只允许一轮代价可控。新鲜度与安全内容哈希守门 每次向 Jev 发请求或取缓存答案前都会用contentHash校验源文件没被改过filesystem.ts 提供快照读取文件变了 → 丢弃对应旧结论标记sourceOmitted而不是硬着头皮返回过期证据部分失败provider 错误、请求超限→ 结果标记incomplete已获得的证据不被一次失败擦掉默认过滤隐藏文件、依赖/构建产物、二进制与明显含凭据的文件尊重.gitignore——但选择搜索根目录依然是你的责任。实测效果同样解题成本更低 在 10 个 SWE-bench Python 任务上的对照含失败任务无 Jev 基线8/10完成Sol 成本$7.62用 jevgrep8/10完成成本$5.44降幅28.6%后续 speed-2026-09-28.md 的优化版本还快29.16%token 少 0.97%。更多细节见 evals/results/relevance-threshold-2026-09-27.md 与 evals/cost-quality-policy.md。总结小数据决策大上下文收益 ✅jevgrep 的架构可以浓缩为三条原则分层决策目录看名字 → 文件看预览 → 声明看源码越贵的判断越晚、范围越小每次交互都有字节预算64 条目目录预览、16KB 文件预览、38KB 请求上限绝不上传整棵树诚实的失败语义剪枝可反悔一次、缓存必校验哈希、部分失败标incomplete让 agent 知道哪些是已证实的哪些只是线索。这套设计让编程智能体拿到的是早期可用的证据而不是一份完整索引——这也是它同样智能、约 30% 更低成本的底气所在。想深入了解设计取舍可阅读 docs/architecture.md 与 specs/done/jevgrep/README.mdagent 侧的使用约定见 skills/jevgrep/SKILL.md。【免费下载链接】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），仅供参考 jevgrep 架构剖析：分层遍历 + 内容预览，Jev 如何不上传整棵树就锁定代码位置
jevgrep 架构剖析分层遍历 内容预览Jev 如何不上传整棵树就锁定代码位置【免费下载链接】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/jevgrepjevgrep 是一款面向编程智能体的代码搜索 CLI你用一句自然语言提问它基于 Jev 模型通过分层遍历仓库目录、内容预览文件返回最相关的文件与源码片段帮助 coding agent 快速定位代码。本文剖析它的内部架构看懂它如何在不上传整棵树的前提下锁定代码位置。它解决什么问题 编程智能体接一个陌生任务时最耗 token 的环节往往是找文件反复ls、rg、读文件把半个仓库塞进上下文。jevgrep 的思路是——让 Jev 替 agent 判断哪些目录值得进、哪些文件值得读最后把文件列表 逐字源码摘录 行号一次性打到 stdout。一句话流程来自 docs/architecture.md问题 → 目录 → 文件 → 源码单元 → stdout它先不上传整棵树而是用目录元数据 内容预览决定往哪走。这正是下面三个阶段的核心。第一阶段分层遍历目录级试读 遍历逻辑在 retrieve.ts 的discover()里约 L297–L395是一个逐层广度优先搜索第 0 层目录只看名字根目录的直接子目录直接进队列连预览都省了更深的目录先做目录预览previewDirectory() 只采样最多 64 个条目、约 4KB 的元数据子项名称、文件/目录计数、扩展名分布就够 Jev 判断这个目录值得探索吗Jev 回答布尔问题概率 0.5 才放行每个目录/文件都会收到一个navigationRequest见 requests.ts问题大意是这个目录是否值得为本次查询探索文件名与元数据作为证据。低于阈值的分支直接剪掉没有固定 top-N通过标准的文件全部保留不会因为只取前两名漏掉证据硬性资源上限单次搜索最多看 10 万个条目、单文件 1MB 封顶防止失控。这意味着一个只有目录名就足以排除的vendor/永远不会被打开读取。第二阶段内容预览文件级试读 对通过目录关的分支jevgrep 同样不上传全文而是构造有预算的内容预览文件预览 开头 16KB 文本previewFile()超限文件则切分成 12KB 的采样块逐块送评判断这段源码是否直接实现了目标行为而不是泛泛相关Python / TypeScript / JavaScript 额外附声明索引先用内置解析器source.ts抽出函数/类声明与行号范围让 Jev 一眼看清文件骨架目录的内容级复查有精细预算withDirectoryContent() 给目录内每个文件按16000/文件数字节分配预算最低 80 字节采样开头 中部 结尾三段整体超 28KB 就按比例缩水——每次发给 Jev 的内容都有硬上限。其他语言含无法解析的文本统一退化为有界源码块保证任何仓库都不会卡死在解析上。第三阶段声明级选择精确到行 文件入选后selection.ts 的selectFile()把文件切成语法单元声明级单元超 24KB 的单元按 16 行再切块然后向 Jev 提出三类布尔判断evidenceRequest问题作用q相关性这段代码是否直接实现或测试目标行为包含 bug 的当前实现也算scope范围是否属于查询点名的那个 API/组件而非功能相似的另一个 APIref引用是否被已选证据具体引用用于把相关声明拉回来通过判断的声明连同其局部调用上下文call-context.ts成为最终摘录被标记为测试文件的还会额外挑选相关 test bodytest-body-selection.ts。解析失败时退化为 3000 字节的有界文本块——失败不丢证据只降级粒度。一次反悔机制锚点复查 剪掉的目录并不会彻底出局。若某候选文件里发现了.context类锚点jevgrep 会把之前所有被剪枝的目录重新做内容级评估retrieve.ts问题变成该目录是否声明/继承/使用了锚点类。这相当于给首轮只看名字的判断一次带上下文的重审机会——但只允许一轮代价可控。新鲜度与安全内容哈希守门 每次向 Jev 发请求或取缓存答案前都会用contentHash校验源文件没被改过filesystem.ts 提供快照读取文件变了 → 丢弃对应旧结论标记sourceOmitted而不是硬着头皮返回过期证据部分失败provider 错误、请求超限→ 结果标记incomplete已获得的证据不被一次失败擦掉默认过滤隐藏文件、依赖/构建产物、二进制与明显含凭据的文件尊重.gitignore——但选择搜索根目录依然是你的责任。实测效果同样解题成本更低 在 10 个 SWE-bench Python 任务上的对照含失败任务无 Jev 基线8/10完成Sol 成本$7.62用 jevgrep8/10完成成本$5.44降幅28.6%后续 speed-2026-09-28.md 的优化版本还快29.16%token 少 0.97%。更多细节见 evals/results/relevance-threshold-2026-09-27.md 与 evals/cost-quality-policy.md。总结小数据决策大上下文收益 ✅jevgrep 的架构可以浓缩为三条原则分层决策目录看名字 → 文件看预览 → 声明看源码越贵的判断越晚、范围越小每次交互都有字节预算64 条目目录预览、16KB 文件预览、38KB 请求上限绝不上传整棵树诚实的失败语义剪枝可反悔一次、缓存必校验哈希、部分失败标incomplete让 agent 知道哪些是已证实的哪些只是线索。这套设计让编程智能体拿到的是早期可用的证据而不是一份完整索引——这也是它同样智能、约 30% 更低成本的底气所在。想深入了解设计取舍可阅读 docs/architecture.md 与 specs/done/jevgrep/README.mdagent 侧的使用约定见 skills/jevgrep/SKILL.md。【免费下载链接】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），仅供参考