Jevgrep 检索速度优化实录：SWE-bench 十任务队列 29.16% 提速背后的本地优化与原生路由实验

本篇技术指南基于 Jevgrep 官方基准评测报告 speed-2026-09-28.md 及其配套的机器可读数据 speed-2026-09-28.json，完整还原一次以"在不损失任务解决能力的前提下缩短检索耗时"为目标的受控实验：候选版本如何保留全部 8/10 官方解、将含检索在内的 Agent 墙钟时间缩短 29.16%，并对比分析七项局部优化策略的实测取舍。读完本文，你将掌握 Jevgrep 检索管线中"源校验时机、忽略规则缓存、provider 并发度、原生二进制扫描、原生 TypeSafe 路由"等关键旋钮的实测效果与取舍逻辑，以及如何读懂该评测体系下的证据边界。

一次"不牺牲任务结果"的速度对比实验

Jevgrep 是一个面向编码 Agent 的 CLI：通过 Jev 模型"按功能描述发现相关文件与源码上下文"。速度评测的意义在于——检索快了，Agent 花在等待检索上的时间就少了，但这绝不能以丢失官方测试解为代价。

本次实验（speed-2026-09-28.md）沿用了评测体系 evals/README.md 确立的原则：使用 SWE-bench 官方行为评分器、复用冻结的安装包评测脚手架 installed.md、基线不可重跑。实验在十个调校过的 Python 任务上各执行一次首次尝试，编码 Agent 为openai/gpt-5.6-sol（medium 努力档），Jev 检索走 TypeSafe 原生端点，Sol 仍经 Vercel Gateway，检索技能为冻结的公开版技能（public skill SHA-256 为04d4d7b59d12...，见 speed-2026-09-28.json）。

核心结果：同样的 8/10，更快的墙钟、更省的 Sol 开销

冻结的候选版本保留了上一轮评测中十个任务中的八个官方解，且整体完成时间显著缩短：

换算为相对变化：

• 相对上一轮 Jevgrep 队列：整体快29.16%，Sol tokens 少 0.97%，Sol 成本低 1.87%；
• 相对固定无 Jev 基线：快12.70%，便宜29.97%，Sol tokens 少41.51%。

需要强调的是口径细节（原文明确列出的边界）：

• 所有首次尝试都计入统计，包括未解决的 Matplotlib 与 Pylint 任务；
• 编码 Agent 基线（no-Jev）没有重跑，复用保存的固定基线；
• Jev 的 tokens 与成本不计入得分，检索返回的上下文依然计入 Sol 账单；原生 Jev 响应不提供价格元数据，因此其 API 成本是"未知"，而非"为零"（speed-2026-09-28.json 的jev_api_cost字段明确记录了这一口径）。

逐任务明细可从 speed-2026-09-28.json 的rows中读取，每个任务都附有 archive identity、receipt hashes 与匹配指标。例如 Sphinx 任务墙钟从 545.29 s 降至 172.57 s，Django 从 408.78 s 降至 311.91 s，SymPy 的 Sol tokens 从 621,998 降至 263,652；而 Requests 与 Matplotlib 则比上一轮更贵（详见后文"限制与任务差异"）。

候选版本到底改了什么

报告开篇即说明变更内容，这些改动与 packages/core/src/retrieve.ts 等源码实现一一对应：

1. 源校验改为"每次 HTTP attempt / 缓存命中返回前校验一次"：检索仍然串行化这些校验，重试仍然检查 freshness。移除一次冗余的初始读取，减少本地工作，同时不允许缓存结果绕过"源已变更"或忽略规则的检查。
2. 二进制检测改用原生正则扫描：与原有的字节排除规则保持一致。
3. 忽略规则身份缓存：早期版本已随 v0.4.2 单独发布，本次候选版本包含该能力。
4. Jev 走 TypeSafe 原生端点：候选版本使用 TypeSafe 原生接口调用 Jev，Sol 仍走 Vercel Gateway。现有用户保存的 provider 选择不变，公开检索技能完全不变。

源码层面的"一次校验"实现

在 packages/core/src/retrieve.ts 中，freshEvaluation通过beforeAttempt钩子把所有 source 的"未变更"校验串行排入一条验证队列：

let validationQueue: Promise<void> = Promise.resolve(); async function freshEvaluation(request, sources, navigation = false) { const validate = async () => { for (const source of new Map(sources.map((source) => [source.path, source])).values()) { if (!(await unchanged(source))) throw new EvaluationFailure("source-invalid"); } }; const beforeAttempt = () => { const pending = validationQueue.then(validate); validationQueue = pending.catch(() => {}); return pending; }; return evaluator.evaluate(request, { navigation, beforeAttempt }); }

关键点：beforeAttempt由 packages/core/src/evaluator.ts 在两条路径上执行——既在每次真实 HTTP attempt 之前（await policy?.beforeAttempt?.()，见 evaluator.ts 第 159 行），也在缓存命中返回之前（第 134 行）。也就是说，源的新鲜度校验被精确地绑定在"每次对外发生副作用"的边界上，而不是在管线入口做一次性的全局预校验。这样既删除了重复的初始读取，又保证了缓存的答案不会在源文件已变更或忽略规则已更新时被错误复用。

unchanged本身（retrieve.ts）通过重读快照并比对contentHash判断源是否仍与进入检索时的版本一致；一旦发现变化，会把该文件的角色、优先级、摘录等状态清空并标记sourceOmitted，确保后续阶段不再基于过期内容给出上下文。

原生 TypeSafe 路由的配置依据

packages/core/src/providers.ts 中注册了四种 provider，本次实验切换的是：

typesafe: { label: "TypeSafe", baseURL: "https://api.typesafe.ai/v1", model: "jev-1.13.0", },

而 Sol 继续走vercel的 Vercel AI Gateway（https://ai-gateway.vercel.sh/typesafe/v1）。评测数据 speed-2026-09-28.json 中jev_provider: "typesafe"记录了这一选择；该 JSON 同时注明候选版本描述为"v0.4.2 plus native binary scan and one source validation per transport attempt/cache return; no lazy-preview change"，即本次候选 = v0.4.2 + 原生二进制扫描 + 每次传输 attempt/缓存返回前的单次源校验，不含"延迟富预览"改动。

七项策略的实验发现与取舍

报告以一张证据表给出了各项局部优化的实测结论，这是整篇文档最富实战价值的部分，逐项解读如下：

从源码理解"并发 32"与"重试"的相互作用

并发度 32 是 packages/core/src/evaluator.ts 中concurrency的默认值（options.concurrency ?? 32），也是 retrieve.ts 中stageWorkers的取值。实验尝试降到 8 之所以失败，从实现上可以解释：score阶段的批处理队列（retrieve.ts）依赖多个 worker 并行泵出待评分组，并发降低会拉长整棵导航树（navigation tree）的评分时间；同时 8 并发下目录发现不完整，说明该任务负载下 32 并发是吞吐与稳定性之间的平衡点。

重试逻辑同样值得注意（evaluator.ts）：导航类且含多个问题的请求 attempt 上限为 1，其余为 2；429 时会依据retry-after头设置冷却窗口（第 83-94 行），并将导航请求的 attempt 上限提升到 2（第 213 行）。实验中"原生路由零错误、Gateway 恢复 64 次内部 503"的对比，正是在这一重试/冷却机制下得到的——原生端点把 503 类故障从源头消除，避免了重试与冷却带来的额外等待。

缓存策略为何能与"单次校验"共存

packages/core/src/cache.ts 的评估缓存以"请求内容 + 命名空间（model / provider / endpoint / protocol / policyVersion / parserVersion / promptVersion）"的 SHA-256 摘要为键，默认 TTL 7 天、容量上限 256 MB、单条目上限 1 MB。缓存命中本身不重发 HTTP 请求，但如前所述，命中路径同样会先经过beforeAttempt的源校验——这正是"移除冗余初始读取但不允许缓存绕过变更检测"的实现保证：缓存减少的是模型往返，不是本地的新鲜度检查。

原生二进制扫描的上下文

二进制检测的"原生正则扫描"对应 packages/core/src/source.ts 中inspect/splitSource等基于字节偏移的切片逻辑（sourceText用Buffer.byteLength计算行偏移，textUnits在 UTF-8 字节边界上切分单元，见 source.ts）。这类逐字节的判定从 Python 辅助（python-worker.mjs）迁移到原生正则后，省去了进程往返，从而在扫描微基准中带来约 6.3 倍的提升；但报告谨慎地声明：这一微基准收益不被当作整体任务加速的证明——本地扫描只是整条检索链路的一环。

原始 trace、回放输入与保留的实验补丁存于被 git 忽略的evals/runs/swebench/speed-research/目录，作为研究证据而非替代性的产品实现。

限制与任务差异：这份报告证明了什么、没证明什么

报告对自己的证据边界有非常清晰的自述，引用时务必一并说明：

1. 任务集与抽样：这是十个调校过的 Python 任务、每任务一次首次尝试。聚合层面很小的 token 与成本差异（0.97%、1.87%）可能只是抽样波动。结论支持"本次测量的这个队列"，不承诺对任意任务、语言、provider 或机器都必然改善。
2. 运行时重建：重建的 Docker 运行环境固定了官方源镜像与经校验的归档工具链；主机模拟也会影响绝对耗时。
3. 因果不隔离：provider 选择、本地优化与采样共同作用于测量结果，本次队列不隔离它们的单独贡献。
4. 任务间的非均匀表现：
   • Requests 与 Matplotlib 比上一轮更贵：Requests 虽然先检索到了实现与测试，Sol 仍做了大范围搜索与额外验证；Matplotlib 的全部 815 次原生请求成功（中位 267 ms、p95 500 ms）但耗时几乎不变——其官方"input-copying"测试仍未解决，且无官方 pass-to-pass 失败。报告由此总结：健康的上游延迟本身并不能消除本地工作或依赖发现轮次。
   • SymPy 与 Pylint 大幅减少时间与 tokens：Pylint 虽快（143.47 s 对比 326.41 s）但依旧未解出任务。

结论：速度比较就此收官

报告明确给出停止决策：本次速度对比已完成，采纳的候选版本在该次运行中保留了此前全部解与聚合 token 节省，无需再为汇报这一结果追加付费试验。与上一轮"以成本为核心"的评测 relevance-threshold-2026-09-27.md（同样 8/10、Sol 成本 $5.4396530 对比基线 $7.6220690）配合阅读，可以完整看到 Jevgrep 从"成本优化"到"速度优化"两阶段的证据链：前者确立 source-first 检索与准入阈值（>0.5）等参数，后者在不动任务结果的前提下把检索等待压了下来。

对想要复现或继续优化检索管线的读者，建议按以下顺序深入源码：

• retrieve.ts：整条检索管线，freshEvaluation的验证队列、score批处理与 32 并发泵、目录发现与锚点重评；
• evaluator.ts：attempt/重试/冷却/缓存命中路径，beforeAttempt的执行时机；
• cache.ts：缓存键、TTL、容量上限与篡改防护；
• providers.ts：四种 provider 的 baseURL 与模型名；
• installed.md：评测脚手架的运行与记账口径（工作时钟、Jev 与 Sol 分开记账、总成本未知则不算成本胜利）。

最后再次强调报告的自我约束：速度优化是"测量出的队列结果"，不是"对每类任务的保证"；引用本文数据时，请连同上述限制与任务差异一并说明，避免把聚合收益误读为通用结论。