用 Jev 折腾一个周末,我的编程智能体快了 31%

tyrpien.com 2026-10-26T21:53:57.518716

Jev 是一个 AI 模型,它不写文字,只做打分。我把它接到编程智能体的代码搜索上,看能不能让它们跑得更快。

太长不看

我在 Jev 之上做了一个叫 Oko 的开源代码搜索工具,专门给编程智能体用(Oko 在波兰语里是「眼睛」的意思)。一次 Oko 搜索,能顶好几次 grep 加读文件。在 162 轮基准测试里,Codex 完成任务快了 18%,OpenCode 快了 15%,Claude Code 快了 31%,token 用量还少了 20% 到 42%。不过这个提速有个前提:我得先告诉智能体什么时候该停止搜索。

跳到结果表

Jev 来自 TypeSafe AI,它不生成文本。你给它一段上下文和一个问题,它返回一个判断:一个标签或一个分数,附带概率。TypeSafe 管它叫「系统一模型」(System One,意思是像人的直觉那样快速反应)。他们给的示例大约 0.1 秒就能出结果,价格是每 10 亿输入 token 收 42 美元,便宜到每次搜索都能调它一次。

我周末拿它玩了一阵,想找点正经事用上。重排序(rerank)看着挺合适:扔给它一个问题加 30 段代码,问它哪几段能回答问题。编程智能体整天都在搜代码,于是我给它做了个小小的开源搜索工具 Oko,再测一测它到底能不能让智能体更快、更省 token——毕竟 Jev 的 token 比前沿模型便宜得多。

Oko 是怎么工作的

  1. 用 ripgrep 列出项目里的文件,再切成块,大致一个函数一块。
  2. 用 BM25(一种标准的关键词排序方法)给这些块按问题相关度打分。打分做两次:一次看纯文本,一次给函数名和类名加权重,然后把两份结果合并,保留前 30 名。测试代码和被测代码用词一样,很容易挤满榜单,所以 Oko 给非测试文件留了一半位置。
  3. 把这 30 个候选和问题一起交给 Jev,由它给每个候选打分,评估它多大程度上回答了问题。30 个候选一次调用搞定,大约耗时半秒。
  4. 最终返回最多三段摘录。每段是完整的函数,从注释和装饰器开始,再加上它调用的短小辅助函数。每行都带真实行号——模型需要自己数行的时候总会数错。其他可能相关的位置按路径列出。

第 1、2 步在你的本地机器上跑。第 3 步把问题和候选片段发给 TypeSafe。索引在服务启动时建好并缓存,所以第一次搜索不用再等建索引。它通过 MCP 和agent连接。

我怎么测的

基准测试用了三个开源项目,都锁定在固定提交:Astro(TypeScript)、HTTPX(Python)和 ripgrep(Rust)。一共九个任务,没有一个点明涉及哪个文件或函数。

其中六个是搜索任务。举一个 HTTPX 的:

追踪响应中的 Content-Encoding 值如何选择解码器、多个解码器如何组合,以及为什么解码要按应用的逆序执行。

另有三个是小改动。举一个 ripgrep 的:

扩展替换捕获名的解析,让命名引用支持 ASCII 连字符,$first-name 和 ${first-name} 两种写法都要支持。

每个 agent 对每个任务都跑了三遍不带 Oko 的(只用它自己的 grep 和读文件),再跑三遍带 Oko 的。计时覆盖整个会话,包括模型的思考和 Oko 的搜索。搜索类答案对照已知位置核对,改动类答案则对修改后的文件跑测试来验证。

每次会话都从零开始。智能体会拿到一份全新的仓库副本和一段新对话,记忆功能也已关闭,所以它记不住十分钟前刚见过的任务。基准测试会在每次运行前验证这一点:先告诉智能体一串秘密代码,再开启新对话并问它这串代码。如果智能体答得出来,就说明记忆发生了泄漏,这次运行会立即停止。

第一个版本省了 token,却没省时间

接入 Oko 后,每个智能体使用的 token 数少了大约五分之一到四分之一。Claude Code 变快了。Codex 从 25.7 秒降到 23.2 秒,OpenCode 基本没动:不用 Oko 是 22.8 秒,用了是 23.0 秒。

于是我去看了会话里的时间到底花在哪。一次 grep 几毫秒就返回。真正慢的通常是模型决定下一步做什么,而且每次工具调用后它都要再决定一次,每次要花 2 到 6 秒。OpenCode 不用 Oko 时,每个任务平均有 5.8 次工具调用。智能体只有在更少的调用里找到正确的代码才会变快,而 Oko 当时没能把调用次数降下来。

在大多数会话里,Oko 的第一次响应就已经包含了任务需要的代码,可智能体还是继续发起调用。它会用更大的范围打开同一个文件,去 grep 一个已经在结果里打印出来的函数名,或者用 sed 打印上下文。这些额外调用花掉的时间,比搜索省下来的还多。

我一开始在工具描述里加了一句话,说明这些摘录就是文件的精确内容。结果没有任何可测量的变化。真正有效的是把这条信息放进智能体每次会话开始时都会读取的项目说明里(Codex 和 OpenCode 用 AGENTS.md,Claude Code 用 CLAUDE.md),并写清楚什么时候该停下来,再配上正例和反例:

Oko returns exact, current file contents with real line numbers: the same text a file read would print. Treat each excerpt as a file read you have already done.

After an Oko search, if you can name the exact code to cite or change, act: answer or edit. Usually that is one Oko call and at most one follow-up read.

- Good: Oko search, then edit the returned lines.
- Bad: Oko search, then sed, nl, cat, or a read of the same range to verify it.
- Bad: Oko search, then grep for a name the excerpts already show.

第一轮回答也更完整了,这样“该停就停”的判断更常成立。回放此前运行中的 169 个问题后,回答中包含任务所需全部信息的比例从 67% 提升到 84%。

结果

指标 未使用 Oko 使用 Oko 平均 最佳任务
Codex
耗时 25.7 秒 21.0 秒 快 18% 快 54%
Token 71,923 48,823 少 32% 少 69%
工具调用 3.4 2.0 少 40% 少 79%
OpenCode
耗时 22.8 秒 19.3 秒 快 15% 快 53%
Token 29,413 17,017 少 42% 少 80%
工具调用 5.8 2.6 少 56% 少 87%
Claude Code
耗时 10.6 秒 7.3 秒 快 31% 快 52%
Token 23,960 19,133 少 20% 少 46%
工具调用 3.7 1.6 少 57% 少 77%

“平均”指 9 个任务、每个跑 3 次、共 162 次会话的均值;“最佳任务”指 Oko 对该代理帮助最大的那个任务。“快”指会话时间减少的幅度。Token 只统计代理自己消耗的,不含重排序模型。

每个任务、每个代理的工具调用次数都下降了。在一个 ripgrep 任务上,OpenCode 从 9 次调用降到 2 次。

每次会话还按正确性打了分。装好 Oko 后,81 次会话全部通过;没装时 81 次里通过 75 次,6 次失败中有 4 次是搜索类任务。6 次失败样本太少,不足以说明 Oko 更准,但至少能说明提速没有牺牲正确率。

这只是一个规模不大的基准测试,而且并非每个任务都变快了。在一个 HTTPX 问题上,用了 Oko 的 OpenCode 反而慢了 33%、消耗更多 Token,原因目前还没查清。

试一试

Oko 支持 macOS 和 Linux。你需要先从 TypeSafe AI 拿一个 Jev API key,首次安装时会提示填入。安装好 Oko 后,在项目目录里运行 setup:

curl -fsSL https://raw.githubusercontent.com/bartlomein/oko/main/install.sh | sh
oko setup --client claude     # 或 codex、opencode、all

运行 setup 会把 agent 连接起来,并写入上面那些指令。如果没有密钥,执行 oko setup --no-jev 就只能得到关键词搜索,不做重排序(reranking)。基准测试及其任务、答案校验都放在仓库里,完整结果逐项列出了每个任务,包括那些变慢的。

查看原文