企业官网建设流程全解析

给 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/jevgrep

2026 年 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 的概率打分决定是否深入——这本质上是一次次"值得继续探索吗"的判断决策。

第一层：目录级导航。对每个子目录，只发送目录内的文件名列表和抽样元数据（childPreview），Jev 回答"这个目录值得为当前查询探索吗"。如果目录通过，才展开下一层；不通过则剪枝（pruned集合）。值得注意的是 packages/core/src/requests.ts 中navigationRequest的提问词强调："截断的预览不能证明有用的后代不存在"——即"未知"不等于"无关"，判断器不知道的内容绝不能当作否证。

第二层：文件级预览。对候选文件，只发送开头 16KB 字节的预览与声明索引（filePreview），Jev 判断"这个文件是否包含对查询有帮助的具体实现、调用者、元数据或测试证据"。预览不是整文件，避免了把大文件全部上传。

第三层：声明级精确定位。文件通过后，用 Tree-sitter（Python/Go/Rust）或 TypeScript 编译器解析出声明单元，对每个声明同时问三个布尔问题（evidenceRequest）：q（相关性——这段源码是否直接实现或控制目标行为）、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得分不足，可撤销此前的选择，但失败或未处理的组保留原有证据——一次失败的判断绝不能抹掉已获得的证据。检索预算（navigationByteBudget，800 万序列化字节）耗尽时，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.md）；
• 0.4.3 重跑含 Jev 费用在内的总成本为5.6564 美元，比基线低 25.8%，其中 Jev 部分仅 1.48 美元（evals/results/total-cost-2026-09-28.md）；
• 0.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