Jevgrep 检索实测：psf__requests-1142 安装包集成的质量保持与成本核查

本篇技术指南基于 Jevgrep（jg）项目在 SWE-bench 任务psf__requests-1142上的一次"安装候选检查点"（installed candidate checkpoint）记录展开，说明 Jevgrep 在安装后的真实 CLI 包 + 官方规范技能（canonical skill）+ 强制初始检索指令条件下如何完成一次多文件定位任务，以及在官方评分器下保持通过的同时付出了多少额外成本。读完本文，你将掌握该项目的评估协议（双臂对比、基线复用、Jev 成本单独核算）、一次真实的检索包结构与 Sol 代理行为轨迹，以及如何解读这类单任务核查的统计边界。

检查点的性质：集成质量通过，而非队列验收

仓库中保留的这份记录（specs/done/jevgrep/assets/installed-requests-checkpoint.md）明确限定了自己的定位：这是一个集成/质量（integration/quality）检查点，而不是队列（cohort）验收结果。两者的区别在于结论的适用范围——队列验收要回答"某个候选版本在一组任务上的总体表现"，而本次检查只回答"把 Jevgrep 以 npm 包形式安装、配上仓库自带的规范技能、要求代理必须先用一次检索之后，单个任务还能不能照常通过、成本变化多少"。

这一点与该项目的评估策略一致：evals/cost-quality-policy.md 规定"官方 SWE-bench 任务完成度是首要指标"，同时要求"报告每个尝试任务的完整任务成本（编码代理 + Jev），增加的成本可以是更多完成任务的可接受权衡"。本次检查点正是一次"成本增加换来集成保障"的单点核算。

核心结果：通过保持，成本上升 30.03%

检查点的原始数据表如下：

逐项解读：

• Officially resolved = yes / yes：安装后的jg方案与固定基线都在官方 SWE-bench 评分器下通过该任务。实现补丁与基线完全一致，treatment（安装分支）额外做的事情是"更广泛的测试"——也就是说，检索本身没有改变最终补丁的内容，通过质量未因集成而退化。
• Full Sol cost 从 $0.2685004 升到 $0.3491436：增加$0.0806432（30.03%）。Sol 的生成次数从 11 次升到 13 次。注意这里的成本口径是编码代理（Sol）的完整成本，Jev 成本和 token 均被排除——这是该项目评估策略的一贯口径，详见 evals/cost-quality-policy.md 与 docs/architecture.md 中"Jev cost is separate"的说明。

为什么会更贵？从记录看，treatment 分支承担了额外的检索与阅读开销：24 次命令执行、48,127 字节输出，而基线只有9 次命令、42,168 字节输出。文档同时提示，部分命令是并行执行的，因此这些数字不能直接当作模型调用次数。

实验协议：双臂同底，只有两处显式差异

检查点记录交代了完整的对照设置，保证两只"手臂"可比：

• 双臂均使用openai/gpt-5.6-sol模型、medium effort、相同的900 秒截止时间、Codex 0.153.4，以及保留的运行时（runtime）与源码（source）身份；
• 基线是保存的固定结果，直接复用、不重跑（"The saved baseline was reused without execution"）；
• treatment 分支只有两处显式变更：
  1. 强制初始检索指令（mandatory initial retrieval instruction）：代理必须先用一次 Jevgrep 检索；
  2. 安装的规范技能（installed canonical skill）：即仓库中的 skills/jevgrep/SKILL.md，它指导代理"先读返回的摘录再做进一步发现、已知上下文时跳过冗余搜索、诚实处理不完整结果"。

这两处差异正是"安装包集成"实验的意义所在：验证的不是检索算法本身，而是把 CLI 与技能真实装进代理工作流之后，端到端行为是否成立。候选包的 SHA256 为aebb98108817285b21b0dced87786e4060dd28a1509a2ac3236c3d3689217be7，用于固化产物身份。

实际观察到的检索包：一次真实的 Jevgrep 输出

检查点记录了 Sol 提出的原始查询（verbatim）：

requests.get always adds Content-Length header; expected GET requests with no body to omit automatically generated Content-Length, while preserving body/header behavior. Find request preparation, header calculation helpers, callers, and tests.

这是一个典型的"按行为找代码"问题：requests.get总会自动添加Content-Length头，而期望是无 body 的 GET 请求省略自动生成的 Content-Length，同时保留 body/header 行为——并要求定位请求准备、头部计算辅助函数、调用方与测试。

对应返回的检索包（packet）包含：

• 源码摘录：requests/models.py:231–256, 385–414；
• 测试摘录：test_requests.py:18–26；
• 外加六个文件线索（file leads）。

这个包立即暴露了两件事：无条件 header 赋值（unconditional header assignment）与认证重算（authentication recalculation）都直接可见。同时值得注意的是它的边界：

• prepare_body只作为线索出现，而非源码摘录——说明它未通过摘录阈值，但文件位置仍被保留，这正是 docs/architecture.md 描述的"Paths without excerpts remain optional reading leads, not a compulsory checklist"；
• 测试摘录test_requests.py:18–26只有 HTTPBIN/helper/class 脚手架，不含行为断言——这成为后文"薄弱的周边/测试上下文"假设的依据。

从实现侧看，这种"摘要先行、详细声明/调用位置殿后"的输出顺序是 CLI 的固定渲染规则：apps/cli/src/render.ts 定义了DEFAULT_MAX_SOURCE_BYTES = 0（默认包含全部选中的源），而 apps/cli/src/args.ts 解析--max-source-bytes等参数；输出全部走 stdout，不生成报告文件。

Sol 的行为轨迹：识别缺陷、失败恢复、双重验证

检查点记录了编码代理（Sol）在拿到检索包之后的完整行为链，这是本文最有参考价值的部分：

1. 识别缺陷：Sol 直接认出了Content-Length的无条件赋值问题；
2. 扩展阅读：随后读取更广泛的 models/test 源码，并检查 adapters、utilities、structures 与 setup——即检索包之外的普通工具阅读；
3. 一次失败与恢复：它的第一次捆绑检查（bundled inspection）在产生输出前失败，随后用分离的命令恢复。这说明即便在安装好的 Jevgrep 流程里，代理自身的工具调用也可能失败，而"恢复"是正常行为；
4. 双重验证：验证运行了两次，两次成功运行之间有一次测试编辑（test edit）。记录特别强调"这不是未改动测试的重复运行"（not unchanged-test repetition）。

观察到的代理行为还包括：额外的指导性搜索（guidance searches）、失败命令后的恢复、源码阅读与测试细化（test elaboration）。这些都在为后续"呈现（presentation）研究"积累假设：薄弱的周边/测试上下文 + 宽泛的可选线索，是文档给出的两个最可能影响成本与效果的呈现因素。

Jev 成本单独核算：$0.011889360 与"0 ≠ 免费"

由于该项目把 Jev 成本从评分口径中剥离，检查点专门花了一节澄清 Jev 侧的真实账目：

• 全部85 次 Jev HTTP 请求都返回 200；这 85 次响应全部保留了 Gateway 成本元数据；
• 汇总报告成本为$0.011889360，对应283,080 个输入 token、8,963 个输出 token；
• 若把 Jev 计入总成本：$0.3491436 + $0.011889360 =$0.361032960；
• 这个数字是"响应报告的 API 成本"，不是发票对账（not an invoice reconciliation），原始总和保留在尝试目录的jev-accounting.json中；
• 之前会计字段中的jev_cost_usd: 0表示的是评分口径下的排除，而不是"实测零费用"——文档特别强调这一点，避免被误读为 Jev 免费。

还有一个容易被忽略的细节：85 个客户端调用内部实际发生了100 次 Gateway provider 尝试。因此"全部返回 HTTP 200"不能解读为"没有内部 provider 失败或回退"——两者是不同层级的事实。这与 apps/cli/src/index.ts 中doctor命令的设计一脉相承：诊断只报告一个经过消毒的 provider 错误，并区分 HTTP 失败、超时与连接失败。

另外，整个任务中jg只被调用了一次，其 CLI 数据包为2,852 个 UTF-8 字节——单次检索的体积很小，成本主要消耗在 Sol 后续的阅读与验证上。

保留证据与可复现性

检查点记录声明"没有从结果中丢弃任何任务、基线或失败"，并给出了证据留存位置（这些目录按设计位于 Git 忽略的本地evals/runs/之下，不随仓库提交）：

• 本地忽略研究目录：evals/runs/swebench/installed-jg-requests-checkpoint-v3/，内含冻结计划、npm 包、安装前缀（installed prefix）与安全输入导出；其attempt/子目录保留原始原生 rollout/events、jg-stdout.txt、原始 Jev bodies、补丁、官方评分控制台/收据，以及生成查询与会计记录；
• 基线：evals/runs/swebench/lookahead-native-v88/psf__requests-1142/codex-baseline/；
• 官方报告运行：jg-installed-psf__requests-1142-8cd1b55070bf；
• 独立的实时安装查询：evals/runs/swebench/installed-jg-live-query-v1/先于本任务完成，其 Docker 启动 stderr 只有初始 Node 镜像拉取，应用输出即为保存的 stdout。

这种"冻结候选、保留一切、机器可读与人工可读报告并存"的做法，与 evals/results/total-cost-2026-09-28.md 中"每次尝试都有完整的传输与用量覆盖"的披露口径一致。

结论边界：单对样本不能做因果归因

检查点文档在末尾给出了严谨的统计声明：一对样本（one pair）既不能把成本上升归因于某个变更，也不能排除普通的模型方差。换句话说：

• 30.03% 的成本增加是观察事实，但"强制初始检索 + 安装技能导致成本上升"只是待验证假设；
• 24 次命令 vs 9 次命令、13 次 vs 11 次生成，这些差异同样可能来自 Sol 的随机轨迹差异；
• 因此文档把"薄弱的周边/测试上下文"与"宽泛的可选线索"称为未来呈现工作的假设（hypotheses for future presentation work），而不是已经证实的结论。

这一边界同样体现在项目整体评估里：evals/results/relevance-threshold-2026-09-27.md 与 evals/results/total-cost-2026-09-28.md 都强调"十任务是有针对性的小型样本，不是 holdout，不构成跨语言/跨仓库的一般性结论"；其中psf__requests-1142在最新总成本重跑中的数据为 Sol $0.3368 + Jev 估计 $0.0128，官方结果 pass——与本次检查点的通过结论相互印证，但两者是独立测量。

从检查点看 Jevgrep 的定位

把这份检查点放回项目语境，可以看到 Jevgrep 的设计哲学在端到端实验中的体现：README.md 概括为"编码代理花在陌生任务上的每一部分时间都在找文件；Jevgrep 给出起点，实现与验证仍归代理所有"。本次任务的真实流程——一次jg调用（2,852 字节包）→ Sol 拿到精准的源码位置与线索 → 自己补读、修复、双重验证、官方通过——正是这一分工的完整演示。

安装侧的操作也由此可复现：先npm install --global @dzhng/jevgrep安装 CLI，再jg auth选择 provider 保存密钥、jg doctor验证连通性，最后在代理工作的项目里执行jg skill安装规范技能（详见 apps/cli/README.md 与 skills/jevgrep/SKILL.md）。检查点验证的正是"这条安装链路 + 强制首用"在官方评分器下依然能完成任务，只是要付出约三成的 Sol 成本增量——这个代价换来的，是对真实安装产物（而非开发期内部构建）的端到端信心。

核心结论一句话：psf__requests-1142检查点证明，安装后的 Jevgrep（含规范技能与强制初始检索）能保持官方通过，代价是 Sol 成本 +30.03% 与更宽的命令/字节足迹；它是一次诚实的单点集成核查，其成本差异与行为假设都有完整证据留存，但单对样本不足以做因果归因。