小模型 + 自验证:DeepSeek V4 Flash 在 Terminal-Bench 反超旗舰,低成本 Agent 的新路线
摘要:一个 2100+ star 的开源项目 llm-as-a-verifier 给出本周 Agent 成本路线上最硬的数据点:让 DeepSeek V4 Flash 生成终端任务轨迹、再用同一个模型当验证器做 Best-of-5 选择,能把 Terminal-Bench 2.1 的 Pass@1 从 78.7% 抬到 88.0%,项目方称已超越 Anthropic 旗舰 Claude Fable 5。本文拆解"LLM 当验证器"的原理、小模型为什么能赢,以及如何在你的 Agent 管道里落地这套低成本验证层。
一、数据点拆解:自己生成、自己验证、自己选优
8 月 18 日,开源项目 llm-as-a-verifier 以 “Self-Verification with DeepSeek V4 Flash Beats Claude Fable 5 on Terminal-Bench” 为题提交 Hacker News。仓库(2134 star,MIT 协议,2026-04 创建,8-14 更新至 0.2.0)的核心主张很直接:任何 Agent 都不需要额外训练,只要加一层"验证器",就能显著提升成绩。
做法是典型的"生成→验证→选择"循环:对 Terminal-Bench 2.1 的每个任务,先用 mini-swe-agent 搭载 deepseek-v4-flash 生成 5 条候选轨迹,再用同一个 deepseek-v4-flash 给轨迹打分,选出最优:
| 配置 | Pass@1(单次生成) | LLM-as-a-Verifier 选择 | Oracle(理论上限) |
|---|---|---|---|
| Best-of-3 | 79.4% | 86.5% ± 1.1% | 92.1% |
| Best-of-5 | 78.7% | 88.0% ± 0.6% | 96.6% |
注意两个细节:验证器评判的是"自己模型"的输出,即自我验证;而 Oracle 行代表"每次都挑中最优轨迹"的天花板,86.5%/88.0% 离它还有距离,说明选择器本身仍在损失信息,数据有改进空间,不是刷榜注水。
方法上,它和传统 LLM-as-a-Judge 的关键区别在于:不让模型输出离散分数,而是取"打分 token 的 logprob 分布的期望"得到连续分数。配合三个可扩展维度——分数粒度(打分 token 数)、重复评估次数、criteria 分解(正确性/根因/验证分别打分),以及一个把两两比较从 O(N²) 降到 O(Nk) 的 Probabilistic Pivot Tournament 排序算法。实现细节也值得注意:打分用 1-20 的字母刻度(A-T)而非数字,是为了能从 logprob 里提取粒度信号;criteria 分解则把"这次修复对不对"拆成"是否定位根因"“是否真正修复”"是否做了验证"等多个子问题,每个子问题单独打分再聚合,比让模型一次给个总分的噪声小得多。论文(arXiv 2607.05391,作者含 Chelsea Finn、Ion Stoica、Azalia Mirhoseini 等)声称在 Terminal-Bench V2(86.5%)、SWE-Bench Verified(78.2%)、RoboRewardBench(87.4%)、MedAgentBench(73.3%)四个基准上取得 SOTA。
先补一句评测口径的背景:Terminal-Bench 是评测 Agent 在真实终端环境里完成端到端任务的基准——编译代码、改配置、起服务、训练小模型都算。每个任务由三部分组成:一段英文指令、一个验证是否完成的 test script、一份参考(oracle)解法;评测 harness 把模型接进 Docker 沙箱跑。旧版 beta 约 100 个任务,2.0 起由 Harbor 框架托管。它考察的不是"会不会写代码",而是"能不能在命令行里把事办成",这正是编码 Agent 最贵、也最容易出错的场景。
需要说明:"超越 Claude Fable 5"是项目方提交 HN 时的表述;仓库自带的对照表只列了 Pass@1 / 验证器 / Oracle 三列,Fable 5 在 Terminal-Bench 2.1 榜单上的具体分数需查官方 leaderboard 核实 [待验证]。但即使只按仓库数据看,"同模型自我验证 +8~9 个点"已经足够有说服力。而且可复现性做得不错:每条任务的 5 条轨迹都打包在 data/terminal_bench_2.1_trajs/ 里,只要配一个 DEEPSEEK_API_KEY,跑 scripts/run_bo3.py / run_bo5.py 就能本地复现结果,不用自己重新跑一遍 agent 生成。
二、为什么小模型 + 自验证能赢
第一,验证比生成简单。 写对一段 bash 脚本很难,判断一段轨迹有没有完成任务相对容易——验证任务对模型的推理深度要求更低,小模型也能给出可靠判断。llm-as-a-verifier 用 logprob 期望 + 重复评估把"单次判断的噪声"摊薄,相当于用算力换精度。这也是"验证"能被当作一条独立 scaling 轴的原因:生成能力靠预训练堆,验证能力可以靠采样次数、打分粒度和 criteria 数量在推理时堆,成本曲线完全不同。
第二,成本账完全成立。 DeepSeek V4 Flash 官方 API 定价(api-docs.deepseek.com):1M 上下文窗口、最大输出 384K,缓存命中输入低至 $0.007/百万 token(非高峰),缓存未命中 $0.22/百万,输出 $0.66/百万——大约是同系 V4 Pro 的三分之一。而旗舰档模型(Claude Opus 4.6 档)在 Terminal-Bench 2.0 的公开成绩约 76.4%(stanford-iris-lab meta-harness 实测),deepseek-v4-flash + 自验证在 2.1 上做到 88%。严格说这不是同版本同 harness 的公平对比,但量级差距摆在那里:旗舰几十分之一的价格,跑出同一区间的 Agent 成绩。
再算一笔具体的账:仓库自报的 Terminal-Bench 2.1 自验证跑分用了 4,320 次验证调用、2.72 亿输入 token,其中 78.8% 命中缓存——按 Flash 缓存命中价 $0.007/百万算,这部分输入成本不到 $15;即使全按缓存未命中 $0.22/百万算,也就 $60 量级。对比旗舰模型一次完整评测动辄上千美元的成本,验证层的边际开销几乎可以忽略。
第三,生态在往同一个方向使劲。 Fuxi(1159 star)主打终端内自包含编码 Agent + 跨 LLM 成本感知路由;“便宜模型 + 聪明的调度 + 一层验证"正在成为开源 Agent 的标准配方,而不是靠单一旗舰模型硬顶。智谱 GLM-5.3 也于本周公开了 Artificial Analysis 基准成绩,开源模型的评测参照越来越多,选型不再是"只看旗舰榜”。
三、落地:在 Agent 管道里加一层验证器
仓库把接入成本压得很低,pip install llm-verifier 之后三行 Python 就能跑 Best-of-N 选择:
import llm_verifier
problem = "Write a function that reverses a string."
candidates = [
"def rev(s): return s[::-1]", "def rev(s): return s", "def rev(s): return ''.join(sorted(s))",
]
result = llm_verifier.select(
problem=problem,
candidates=candidates,
criteria={"Correctness": "Does the code actually reverse the string?"},
)
print(result.index) # index of the best candidate: 0
print(result.scores) # candidate scores: [0.73104, 0.38446, 0.38449]
pip install llm-verifier
# 复现 Terminal-Bench 2.1 自验证结果(需 DEEPSEEK_API_KEY)
python scripts/run_bo3.py # best-of-3
python scripts/run_bo5.py # best-of-5
几个实用集成点:
- 双模型路由:旗舰模型负责生成(质量优先),deepseek-v4-flash 负责验证(成本优先)。验证器用低单价模型,验证 5 条轨迹的开销远小于多生成一次旗舰输出。
- 在线止损:
ProgressTracker逐步骤打分,分数持续低于阈值就提前中止这条 rollout,省掉无谓的 token 消耗——仓库示例中一条失败轨迹的分数从 0.00002 一路趴底,而成功轨迹逐步爬到 0.986。 - 工具调用纠错:把验证器接到 agent 的每步动作上,命令执行后对"当前状态 + 目标"打分,分数异常就回滚或重试,避免错误状态滚雪球——和在线止损是同一种思路的两种用法。
- Claude Code 插件 TurboAgent:以 LLM API 代理形式挂在 Claude Code 前面,并行生成多个候选、自动选优,
ANTHROPIC_BASE_URL=http://localhost:8888 claude即可接入。 - 前缀缓存优化:0.2.0 把提示词里"任务+两条轨迹"设为共享前缀,缓存命中率从 5.2% 提到 78.4%,输入 token 成本降约 3.4 倍——对轨迹动辄 8 万 token 的验证场景,这比模型降价更狠。
- 接入自家任务:仓库提供
criteria/TEMPLATE.md模板和add_new_benchmark.md向导,把轨迹拷进data/、替换任务名,再让 Claude Code 帮你生成 criteria 和 runner,就能把验证器用在自家 Agent 上,而不是只跑官方基准。
四、局限与选型建议
这套方案不是银弹,选型前想清楚三点:
- 同源偏差:让模型验证自己的输出,会共享模型的盲区。两个候选都错在同一种理解上时,验证器可能给高分。缓解办法是换验证器模型(论文的跨模型表格里,Gemini 2.5 Flash 验证 GPT-5.5 的轨迹同样有效),或者引入 test script 这类"客观验证"兜底。
- 不适合的任务:创意写作、长文润色、开放域问答这类"没有唯一正确答案"的任务,验证器分数没有意义;它擅长的是有明确验收标准的结构化任务(终端操作、修 bug、配置服务)。
- 评测口径要自己把关:Terminal-Bench 2.1 的榜单页面是前端渲染,不同 harness(旧 terminal-bench vs 新 Harbor)的分数不能直接比;换 benchmark 版本、换 agent、换采样数,成绩都会变。选型时以"同任务集、同 harness 的 A/B"为准,别被跨表数字误导。
落到行动上,把"评测驱动"变成日常习惯:固定一组代表性任务,每次换模型、换验证器、换采样数都跑同一套 A/B,记录成本与得分。第三方基准(如 GLM-5.3 近日公开的 Artificial Analysis 成绩)适合做初筛,最终以自家任务集为准——毕竟验证器选型本身就是个可以优化的超参,值得为它单独跑一轮实验。
总结
“小模型 + 自验证"的本质,是把原来花在旗舰模型上的钱,拆成"便宜生成 + 便宜验证"两笔账,再用 logprob 期望、重复评估、锦标赛排序这些工程手段把选择质量提上去。Terminal-Bench 2.1 上 88% 的成绩是否真的压过 Claude Fable 5,值得等独立复现;但"验证是一条独立于预训练和后训练的可扩展轴”(论文原话)这个判断,已经拿到了一个非常硬的工程证据。对预算敏感的 Agent 团队,现在就可以在自己的管道里加这层验证器,成本几乎可以忽略。
参考链接
- llm-as-a-verifier 仓库:https://github.com/llm-as-a-verifier/llm-as-a-verifier
- 论文:https://arxiv.org/abs/2607.05391
- HN 提交:https://news.ycombinator.com/item?id=49348195
- DeepSeek API 定价与模型规格:https://api-docs.deepseek.com/quick_start/pricing
- Terminal-Bench:https://www.tbench.ai
- Harbor(Terminal-Bench 2.0 官方 harness):https://github.com/laude-institute/harbor
- meta-harness(TB 2.0 Claude Opus 4.6 76.4%):https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact
- TurboAgent(Claude Code 插件):https://github.com/llm-as-a-verifier/TurboAgent
- Fuxi(终端编码 Agent,成本感知路由):https://github.com/fuxicodex/Fuxi
更多推荐

所有评论(0)