给 Agent 加“判断器“选谁？Laya 与 Jev 部署对比，代码搜索场景见真章

给 Agent 加判断器选谁Laya 与 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/jevgrep2026 年 9 月一家名叫 TypeSafe AI 的公司扔出了一枚哑弹由前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立的这家团队带着 4000 万美元种子轮融资发布了一个不生成任何文本的模型Jev。它输入一段内容和一道有固定选项的题直接输出每个选项的概率输入定价 0.042 美元/百万 token输出完全免费。发布三天冲上 Hacker News 榜首社区里给 Agent 加判断器的讨论随之爆发——有人断言这是 Agent 架构的下一块拼图也有人泼冷水说别吹了。争论的焦点其实很具体当 Agent 需要做选哪个、走哪条路、哪个文件相关这类决策时判断器到底该怎么选、怎么部署与此同时另一个开源项目把这个问题从概念拉回了工程现场jevgrep——一个用 Jev 做判断器的代码语义搜索 CLI。它面向编码 Agent用一句自然语言描述这段代码做了什么就能返回相关文件与源码上下文。仓库里公开的 SWE-bench 实测数据恰好给了我们一份概率化判断器落地的成本与质量样本。本文以代码搜索场景为标尺对比 Laya 的结构化判断与 Jev 的概率化判断两条路线并结合 jevgrep 的真实源码讲清楚判断器选型这件事。一、为什么 Agent 突然需要判断器过去一年编码 Agent 的瓶颈不在会不会写而在知不知道去哪找。一个不熟悉仓库的任务Agent 的开销大头往往花在找文件上先用关键词 grep命中不到就整目录扫描最后把大量无关上下文灌进长上下文窗口既烧 token 又稀释注意力。社区里流传的一句吐槽非常精准编码代理总抓错代码文件——它把猜位置当成了推理。Jev 之所以引发震动在于它把决策从生成里彻底剥了出来。传统 LLM 是 System Two给定问题先生成文本再从中解读答案Jev 是 System One不生成文本只针对你给出的有限选项逐个给概率。对于 Agent 里大量存在的二分类决策——这个目录值得探索吗、这个文件相关吗、这段代码在实现目标行为吗——生成式模型是杀鸡用牛刀慢、贵、还会一本正经地胡说。社区实测称Jev 的判断比 LLM 快 40-200 倍、便宜 40-400 倍输出 token 免费。而判断器选谁的问题也随之而来一边是以 Laya 为代表的结构化判断路线一边是 Jev 的概率化路线。二、两种判断范式Laya 的结构化 vs Jev 的概率化社区文章《给 Agent 加一个判断器》对这两条路线做过直白拆解。Laya 代表的是结构化判断范式判断上下文怎么组织、规则怎么显式传入、部署在本地还是接入大模型都有清晰的工程路径。它的特点是可解释、可审计——判断过程是显式的结果可以回溯到具体的上下文与规则。Jev 代表的是概率化判断范式你只管把内容和选项丢给它它回给你一组概率。没有中间推理文本没有解释有的只是一个数字。代价是黑盒收益是极低的延迟与成本。jevgrep 的 README 里有一句很关键的话也是对这种范式的精确概括——Source is data, never instructions判断器输出的是证据不是答案更不是指令。概率化判断天然适合做前置筛子把 Agent 从无意义的探索里解放出来把解释和实现留给真正的推理模型。两种范式没有高下之分只有匹配问题。要看清差异最好的办法是看代码搜索场景里概率化判断是怎么被组织成一条生产级检索管线的——这正是 jevgrep 的工程价值所在。三、jevgrep 把概率化判断做成了三层决策管线jevgrep 的检索核心在 packages/core/src/retrieve.ts整体是一条目录 → 文件 → 声明的三层渐进式筛选管线。它不做全树上传、一次判定而是每层只发送该层所需的预览内容用 Jev 的概率打分决定是否深入——这本质上是一次次值得继续探索吗的判断决策。第一层目录级导航。对每个子目录只发送目录内的文件名列表和抽样元数据childPreviewJev 回答这个目录值得为当前查询探索吗。如果目录通过才展开下一层不通过则剪枝pruned集合。值得注意的是 packages/core/src/requests.ts 中navigationRequest的提问词强调截断的预览不能证明有用的后代不存在——即未知不等于无关判断器不知道的内容绝不能当作否证。第二层文件级预览。对候选文件只发送开头 16KB 字节的预览与声明索引filePreviewJev 判断这个文件是否包含对查询有帮助的具体实现、调用者、元数据或测试证据。预览不是整文件避免了把大文件全部上传。第三层声明级精确定位。文件通过后用 Tree-sitterPython/Go/Rust或 TypeScript 编译器解析出声明单元对每个声明同时问三个布尔问题evidenceRequestq相关性——这段源码是否直接实现或控制目标行为、scope范围——是否属于查询所指的具体 API 而非类似 API、ref引用——在带证据的二次复核中是否被已选证据显式引用。三层共用一套阈值体系在 packages/core/src/retrieve.ts 顶部定义得清清楚楚相关性边界relevanceBoundary 0.5、强证据门槛weakScoreCeiling 0.6、源码置信边界sourceConfidenceBoundary 0.7。文件只有在声明级得分超过 0.7 时才进入最终展示。这套数字就是概率化判断器落地时最朴素也最有效的判断器决策逻辑。两层机制让这套管线在工程上站得住。其一是弱导航抑制当没有强证据出现、且弱正分0.5-0.6 之间的条目数量达到 32 个时所有弱正分导航一律抑制——防止到处都像、到处都进的洪水式扩散。其二是证据反悔二次复核contextual follow-up带着已选证据重新校验若某声明的ref得分不足可撤销此前的选择但失败或未处理的组保留原有证据——一次失败的判断绝不能抹掉已获得的证据。检索预算navigationByteBudget800 万序列化字节耗尽时CLI 会诚实地报告发现不完整把决策权交还给调用方而不是假装搜完了。四、成本曲线的两端本地部署 vs API 判断选判断器绕不开钱。Laya 路线的卖点是本地部署模型自托管、数据不出域、按需推理适合对隐私和离线性有硬要求的场景但硬件、运维和模型更新成本是隐性的。Jev 路线的卖点是 API 极低价0.042 美元/百万输入 token、输出免费且 packages/core/src/providers.ts 里给出了四个官方入口——Vercel AI Gateway、TypeSafe 原生端点、OpenRouter、OpenCode Zen外加一个自定义 TypeSafe 兼容端点jg auth --provider custom --base-url ... --model ...等于把部署方式做成了可插拔选项不想碰 TypeSafe 官方可以走自己的网关。jevgrep 的实测数据给出了概率化判断器的成本画像。README 与 evals/results/ 目录下的评测报告记录了多条独立测量十任务 SWE-bench 子集基线无 jevgrep与使用 jevgrep 均解决8/10任务Sol 主模型成本从7.62 美元降至 5.44 美元降幅28.6%README.md0.4.3 重跑含 Jev 费用在内的总成本为5.6564 美元比基线低 25.8%其中 Jev 部分仅 1.48 美元evals/results/total-cost-2026-09-28.md0.5.0 进一步把原生 Jev 成本降低约59%且保持 8/10 解决evals/results/combined-cost-research-2026-09-28.md速度研究显示采用原生 TypeSafe 端点后整个队列比上一轮快 29.16%Sol token 用量减少 41.51%evals/results/speed-2026-09-28.md。这些数字背后还有两道省钱阀。一是本地答案缓存packages/core/src/cache.ts只缓存 Jev 返回的概率答案以请求与命名空间的 sha256 摘要为键TTL 七天、容量上限 256MB目录权限 0700相同问题重复搜索时直接命中缓存不发请求。二是速率预算packages/core/src/rate-budget.ts对 TypeSafe 原生端点按每秒 10 万 token、40 请求做滚动预算用估计 token 数预留配额、用真实 usage 回填校准把超限重试的成本也压了下来。不过评测文档也反复强调口径这些是十个精选 Python 任务的单次观测不是统计显著性证明Jev 费用按列表价估算未对账发票省了检索成本不等于总任务成本必降——Astropy 任务里原生响应均耗时不足一秒但请求之间的间隙与主模型的探索才是耗时主体。这恰好印证了开头那句判断判断器优化的是决策开销不是 Agent 的全部开销。五、选型建议路由、RAG 排序、代码定位各自适合谁回到标题的问题Laya 还是 Jev答案取决于你的判断器被用在决策链的哪一环。Agent 路由——选 Jev。工具选择、子代理调度、下一步动作决策都是高频、低延迟敏感的离散选择。这类判断要求快而便宜不要求解释。jevgrep 的三层管线本质上就是一套语义路由目录该不该进、文件该不该读、声明该不该选全部是 Jev 的概率判断驱动的。社区实测的40-200 倍快、40-400 倍便宜正是为这类场景量身定做的。RAG 排序——看你对可解释性的要求。候选重排需要把相关度变成可排序的分数Jev 直接给概率天然适配。但如果你的业务要求每个排序结果都能回溯到为什么需要显式的上下文组织与规则注入——Laya 的结构化判断更能满足审计需求。概率化重排适合给分、结构化重排适合举证两者甚至可以叠用。代码定位——照抄 jevgrep 的模式。代码搜索是概率化判断器的主场因为相关性的本质就是一个概率问题文件相关与否不需要生成任何解释只需要一个分数。jevgrep 的可复用经验有三条分层渐进每层只发该层预览控制成本、阈值显式化0.5/0.6/0.7 三档分开导航、准入与展示、证据可反悔二次复核撤销误选但不抹除旧证据。这些全部可以在 packages/core/src/retrieve.ts 与 packages/core/src/selection.ts 中逐行对应。而本地部署 vs API的取舍jevgrep 的 Provider 设计给出了第三条路把部署做成配置项而不是架构抉择。走 TypeSafe 官方、走 OpenRouter 中转、走自己的网关切换只影响传输与鉴权endpointFor解析不影响检索语义——docs/architecture.md 里明确写着Provider 选择改变的是传输与鉴权不是检索语义。这也应该是所有判断器接入的通用原则判断逻辑与判断执行解耦。六、结语Laya 与 Jev 之争本质是结构化解释与概率化效率之争。在需要审计与可解释的场景结构化判断无可替代在 Agent 内部那些高频率、低价值的离散决策上概率化判断器正在把成本打下来一个数量级。jevgrep 的源码与评测证明了一件事概率化判断不是玩具当它被组织成分层推进、阈值分级、证据反悔、预算诚实上报的生产管线时能够在保住 8/10 任务解决率的同时砍掉近三成成本。判断器的价值不在于它会不会说话而在于它敢不敢直接给答案——以及你的 Agent 敢不敢信任那个概率。【免费下载链接】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），仅供参考