第 3 章第一部分：快速上手

接入新的 Benchmark

Task 的完整生命周期、以 SWE-bench 和 WebArena 为例走一遍、批量执行、数据集管理

最后更新：2026年11月9日 Nexus Benchmark SWE-bench WebArena Batch DeepSWE ProgramBench Fable 5 mini-swe-agent

Task 的完整生命周期

在 Nexus 里，一个 Benchmark 对应一个 Task 模块。一个完整的 Task 模块通常包含：

extensions/tasks/swe/
├── pyproject.toml      # 模块元数据 + 依赖声明 + [tool.nexus] 注册
├── task.py             # Task 主函数（@task_registry.register）
├── generator.py        # 数据集生成器（产出 BatchItem 列表）
├── eval.py             # 评估逻辑（判定 Agent 输出是否正确）
├── dataset_handler.py  # 数据集加载和预处理
├── constants.py        # 常量定义
└── swe_bench/          # Benchmark 特定的子模块
    ├── grading.py
    ├── log_parsers.py
    └── test_spec.py

执行流程如下：

Generator → [BatchItem, BatchItem, ...] → 每个 Item 跑一次 Task
                                            ↓
                                     Task 函数编排：
                                     1. 准备 Runtime 环境
                                     2. 调用 run_agent(prompt)
                                     3. 收集 Agent 输出
                                     4. 评估 + 评分
                                            ↓
                                     TaskRunOutput(score=...)

28 个内置 Task 速览

Nexus v1.1.3 内置了 28 个 Task，覆盖主流 benchmark：

Task	领域	说明	状态
`swe_task`	代码修复	SWE-bench 全家桶（含 Verified/Plus+/Multilingual/Smith/Gym/Pro/Turing/ReBench/Live 等 14 个变体）。⚠️ SWE-bench Verified 已被 OpenAI (2026.03) 宣布饱和/污染，前沿模型分数超 90%。⚠️🔴 “转向 SWE-bench Pro”这条建议已作废：2026-02 OpenAI 曾推荐以 Pro 替代饱和的 Verified，但 2026-07-08 OpenAI 已正式撤回该推荐（审计 731 道公开题，约 30% 存在根本缺陷，详见下文 §「OpenAI 的双重撤退」）。当前不建议以 Pro 作为主基准，可考虑 DeepSWE / SWE-bench-Live / Terminal-Bench 4.0。Pro 的历史分数（Opus 4.7: 64.3%, GPT-5.5: 58.6%）属 vendor-scaffold 口径，比 Scale SEAL 标准化榜高 15–30 分，不可与公开榜混用。⚠️ DeepSWE (2026.05) 审计发现 Pro 验证器 8.5% 假阳性 + 24% 假阴性率，历史排名可能存在偏差；Claude Opus 4.7 约 18% 通过项使用了 git 历史中的原始补丁	⚠️ Verified饱和/Pro已撤回
`webarena`	Web 操作	网页操作任务（电商/论坛/CMS/地图，原 812 任务含不可能项）	⚠️ 需用Verified
`webarena_verified`	Web 操作	WebArena Verified 子集（428 可行任务，去除原 812 任务中不可能完成的项，评测更公平。当前 SOTA: DeepSeek V3.2 74.3%）	✅ 活跃
`gaia`	通用推理	GAIA benchmark（多步推理 + 工具使用。当前 SOTA: GPT-5 65.8%，Memento-Skills 66.0%）	✅ 活跃
`hle`	极难推理	Humanity’s Last Exam（前沿从 3.4% 飙升至 56.8%，Claude Mythos Preview 14个月内+53.4点）	✅ 活跃
`browsecomp`	浏览器理解	BrowseComp benchmark（SOTA: GPT-5.5 Pro 90.1%，接近饱和，WebChoreArena/Mind2Web 2 为新方向）	⚠️ 接近饱和
`gsm8k`	数学推理	GSM8K 数学题	✅ 活跃
`math`	数学推理	MATH 数据集	✅ 活跃
`bfcl`	函数调用	Berkeley Function Calling Leaderboard v4	✅ 活跃
`ace`	工具调用	ACEBench——API 调用评测	✅ 活跃
`tau2` / `tau3`	工具调用	τ-bench v2/v3（零售/航空客服场景）	✅ 活跃
`terminal_task`	终端操作	Terminal-Bench 4.0（66 任务，2026-08-28 发布；2.x 已退役两代）。官方榜 2026-10-06 快照（10-23 快照复核：组成与数值未变，核于 2026-11-09）：Opus 5.5 64.8%、Sonnet 5.5 61.8%、GPT-6 Astra 58.2%、Fable 5.1 57.9%、GLM-5.3 41.8%、GPT-5.6 Sol 37.3%（共 35 条 / 23 个模型）。⚠️ 跨版本分数绝对不可比：GPT-5.6 Sol 在 2.1 为 88.8%、在 4.0 为 37.3%；Kimi K3 从 88.3% 掉到 12.6%（⚠️ 12.6% 为二手聚合站口径：Kimi K3 在 tbench.ai 官方 4.0 榜无条目，该数未获一手榜证实，引用时须另标出处）。引用任何 TB 分数必须一并写版本号	⚠️ 2.x 已退役，须升 4.0
`search` / `hy3_search`	搜索	搜索质量评测	✅ 活跃
`mm_agent`	多模态	多模态 Agent 评测	✅ 活跃
`mcp_benchmark`	MCP 工具	MCP 工具使用评测。可参照 MCP Atlas（Scale Labs）：Muse Spark 1.1 88.10 ± 1.95、claude-opus-5 (xhigh) 85.80 ± 2.10、gemini-3.5-flash (high) 83.60 ± 2.30——首个对 MCP 工具使用给出标准化口径与置信区间的基准	✅ 活跃
`claw_eval`	综合	ClawBench 评测	✅ 活跃
`wildclaw_bench`	综合	WildClawBench	✅ 活跃
`pinchbench`	综合	PinchBench	✅ 活跃
`nl2repo`	代码生成	自然语言到仓库	✅ 活跃
`vita_task`	客服模拟	VitaBench 对话模拟	✅ 活跃
`custom_web`	Web 操作	自定义网站任务	✅ 活跃
`browser_game`	浏览器游戏	浏览器游戏任务	✅ 活跃
`artifact_task`	代码构建	构建 + 评测任务	✅ 活跃
`skills_task`	技能评测	SkillsBench	✅ 活跃
`echo`	教学	教学示例任务	—
`identity`	透传	直接跑 Agent（不评测）	—

⚠️ 命名防撞：τ^τ-Bench 与上表的 tau2 / tau3 不是同一系列（2026-10-02 新增）。tau2 / tau3 是 τ-bench v2/v3，测的是”Agent 在客服场景里做事”；而 τ^τ-Bench（arXiv:2609.04611，2026-09-04，读作 hyper-tau-bench）测的是”Agent 能不能交付出一个 Agent”——给一个开发方 Agent 完整的客户交付材料（真实业务记录、客户需求、生产 API、既有代码库、模型与成本的约束），要求它交付一个可用的客服 Agent，再用留出集的模拟用户评估。53 个任务 / 4 个域；最强配置（Claude Opus 5 通过 Claude Code）通过 23.9% 的评估模拟，专家手写参照上限为 82.2%。名字只差一个上标，任务完全不同——这是本章读者最可能踩的坑。⚠️ 该工作为 arXiv 预印本，23.9% / 82.2% 为论文自报，摘要页未提供任务构造、模拟器设计与统计不确定性的细节。

Terminal-Bench 4.0：为什么要整节重写这行

terminal_task 是全表受版本漂移影响最大的一行，值得单独说明。Terminal-Bench 现行版本为 4.0（官方站页头直显 TERMINAL-BENCH 4.0，Hosted by Stanford / Harbor / Laude Institute；榜单每个条目 n_trials=330，即 66 任务 × 5 次）。

版本谱系（据官方榜镜像的版本谱系表）：2.0（2025-11，89 任务）→ 2.1（2026-05，89 任务，修订 28 题）→ 3.0（2026-07，74 任务，rolling task set）→ 4.0（2026-08-28，66 任务：移除 8 个、修订 19–20 个、新增 0 个；按任务校准 CPU/内存/时间，统一 8 小时 agent 超时）。

官方榜 2026-10 快照（数据取自 tbench.ai/leaderboard 页内 JSON；榜单 updated_at = 2026-10-06，本章核于 2026-10-22。上一版快照 updated_at = 2026-09-21、共 27 条，榜首为 GPT-6 Astra 58.2%——20 天后榜换了一次）：

排名	模型	Agent	effort	解题率	成本
1	Opus 5.5	Claude Code	max	64.8% ± 3.1%	$4.7k
2	Sonnet 5.5	Claude Code	max	61.8% ± 2.9%	$7.3k
3	GPT-6 Astra	Codex	max	58.2% ± 2.8%	$3.3k
3	GPT-6.1 Sol	Codex	max	58.2% ± 3.1%	$634.24
5	Fable 5.1	Claude Code	max	57.9% ± 3.8%	$6.2k
20	GLM-5.3	Claude Code	max	41.8% ± 3.2%	$2.7k
21	Grok 4.7	Grok Build	xhigh	37.6% ± 3.5%	$3.68k（partial: 324/330）
22	GPT-5.6 Sol	Codex	max	37.3% ± 3.8%	$2.5k
23	GLM-5.3-Flash	Claude Code	none	35.8% ± 3.5%	$2.9k（10-23 修正为 $118.74，见下文注记）
26	Opus 4.8	Claude Code	max	23.6% ± 3.6%	$6.5k
33	⚠️ Sonnet 5	Claude Code	max	12.4% ± 3.1%	$9.6k

⚠️ 官方榜共 35 条（去重后 23 个模型），同一模型按 reasoning effort 分档重复上榜；上表是 effort = max 档的子集外加几条代表性条目（Grok 4.7 xhigh、GLM-5.3-Flash none）。若按”排名”读这张表，会以为榜上只有十来个模型——实际是 35 个（模型 × effort 档）条目。

🔁 快照第三次换血（2026-11-09 核）：榜单 updated_at 已推进为 2026-10-23，条目组成与 10-06 快照相同（35 条 / 23 个模型），35 条数值中 34 条逐条比对一致——唯一变化是 GLM-5.3-Flash 的成本由 $2.9k 修正为 $118.74（准确率不变，见下文 effort=none 档注记）。这是本节”版本锚点会腐烂”叙事的第三次发生（09-21 → 10-06 → 10-23），且第一次出现”日期换了、数据几乎没换”的形态。上表数字除该条成本外继续有效，无需替换。

🔁 这张表本身就是”版本锚点会腐烂”的活样本。上一版（2026-10-02 核）写下的是 27 条 / 榜首 58.2%，20 天后变成 35 条 / 榜首 64.85%，换了 8 条、榜首让位 6.7 个百分点。凡是”截至某日”的快照，请把抓取日写进句子里而不是写”当前”——否则读者无法判断它离现在有多远。

⚠️ “榜上有名”不等于”跑满全部试验”：官方榜允许未跑满 330 次（66 任务 × 5 次）的条目上榜并参与排名，并在页面上显式标注——例：Grok 4.7 的成本列写作 $3.68k (partial: 324/330)，即 330 次里只跑了 324 次。对以复现为目标的评测框架，引用前须先看该条是否为完整 trial；否则”完整跑完”与”少跑 6 次”的条目会被当成同一量级比较。

🔎 2026-10-22 复核：这条警示仍然有效，而且出现了一个更值得记的细节。Grok 4.7 到现在仍是榜上唯一带 partial 标注的条目（display_cost 字段仍写着 partial: 324/330，成本仍为 $3.68k），但同一条目的 n_trials 字段已经是 330，其 successes = 124，准确率 37.58% 正是按 124/330 算出来的——也就是说，显示字符串与计数字段并不一致：一个说”只跑了 324 次”，另一个按 330 次算分。

因此判断依据必须写死为看 n_trials 与 successes 这两个字段，而不是看页面上的显示串。更要紧的是：本节的举例（partial: 324/330）随时可能被榜单补齐或改写，所以你引用时不要照抄本节的句子，去核当天该条的字段值。

⚠️ Terminal-Bench 各版本分数不可比，且量级惊人：GPT-5.6 Sol 在 2.1 是 88.8%、在 4.0 是 37.3%；Kimi K3 从 88.3% 掉到 12.6%（⚠️ 同上，12.6% 未见于官方 4.0 榜）。4.0 移除了饱和题与拒答题、统一了资源预算，分数下沉是基准变难，不是模型退步。这条应作为本书的通用编辑规则：引用任何 TB 分数必须一并标注版本号。 按本章旧版配置 terminal_task 的读者，会以为自己在跑一个”顶尖模型能解 88%“的活跃基准，实际差了 50 个百分点。

📌 成本效率的第一课其实在同一模型内部（2026-10-02 补）。官方榜按 reasoning effort 分档给出同一模型的解题率与成本，据此可直接算出梯度——这比跨模型比较纯净得多，因为不混入模型差异：

模型 × effort 解题率成本每千美元解题率
GPT-6 Astra / low 50.6% $1.6k 约 31.6 pp
GPT-6 Astra / medium 54.2% $1.9k 约 28.5 pp
GPT-6 Astra / high 57.9% $2.3k 约 25.2 pp
GPT-6 Astra / xhigh 57.9% $2.4k 约 24.1 pp
GPT-6 Astra / max 58.2% $3.3k 约 17.6 pp
Fable 5.1 / low 43.3% $2.4k 约 18.0 pp
Fable 5.1 / medium 53.9% $2.8k 约 19.3 pp
Fable 5.1 / high 54.5% $4.0k 约 13.6 pp
Fable 5.1 / max 57.9% $6.2k 约 9.3 pp
⚠️ Sonnet 5 / max 12.4% $9.6k 约 1.3 pp

Astra 的 low 档成本效率约为 max 档的 1.8 倍，而准确率只差 7.6 个百分点（58.2% → 50.6%）。Fable 5.1 更极端：medium 档约为 max 档的 2.1 倍，准确率只差 4.0pp；其 high 档（13.6）反而劣于 medium 档（19.3）——多花的钱没有换来更多解题，也没有换来更高效率。

反例同样在榜上：Sonnet 5（max）仅 12.4% 却花 $9.6k，每千美元约 1.3 个百分点，是 Astra low 档的约 1/24。“贵的档位一定更好”在这张榜上不成立。

同家族的跨代对比更极端（2026-10-22 补，同一张 2026-10-06 快照）：榜上同时有 Sonnet 5.5 / max：61.82%，$7.3k（第 2 名） 与 Sonnet 5 / max：12.42%，$9.6k（并列第 33）。同一产品线的两代之间差 49.4 个百分点，而更贵的那代（$9.6k）正是更差的那一代。这不是”贵的档位不一定更好”，而是”贵的那一代可能整整差 49 个百分点”。对批量评测的意义是：模型名一旦写进配置，你锁定的不是”某个能力水平”，而是”某个能力水平 + 某个时间点”。

对批量评测的意义很直接：effort 档位是一个和”选哪个模型”同等量级的成本杠杆，而它在本章此前的讨论里完全缺席。⚠️ 表中”每千美元解题率”与倍数均为按官方榜 cost 列自算，非榜单原字段；cost 为单次评测总花费，各模型 trial 数一致（均为 330）。

⚠️ 补一条适用边界（2026-10-22）：这个自算指标是 accuracy ÷ cost，分母趋近 0 时会爆炸，排名会完全由成本驱动而不是解题能力。2026-10-06 快照上的现成反例：GPT-6 Luna 只解 16.36%，却因成本仅 $72.14 而拿到全榜最高的约 226.8 pp/$1k；Muse Spark 1.3 的 cost 为 $0.00，该指标无定义。用它做比较时应设一个成本下限（例如只比较 cost ≥ $1k 的条目），或改用”达到目标准确率所需成本”这类分母有下界的形式。

🔴 该反例在 2026-11-09 被更强的一条取代：GLM-5.3-Flash 成本修正为 $118.74 后，其自算成本效率升到约 301 pp/$1k，超过 GPT-6 Luna 的 226.8，成为全榜第一——而它的准确率只有 35.76%（第 23 名）。成本下修一个数量级，成本效率榜就换一个冠军，解题能力一行没变——这是”分母驱动”最干净的一次现场演示，“设成本下限”这条边界从预防性建议变成了必须执行的规则。

模型 × effort	解题率	成本	每千美元解题率
GPT-6 Astra / low	50.6%	$1.6k	约 31.6 pp
GPT-6 Astra / medium	54.2%	$1.9k	约 28.5 pp
GPT-6 Astra / high	57.9%	$2.3k	约 25.2 pp
GPT-6 Astra / xhigh	57.9%	$2.4k	约 24.1 pp
GPT-6 Astra / max	58.2%	$3.3k	约 17.6 pp
Fable 5.1 / low	43.3%	$2.4k	约 18.0 pp
Fable 5.1 / medium	53.9%	$2.8k	约 19.3 pp
Fable 5.1 / high	54.5%	$4.0k	约 13.6 pp
Fable 5.1 / max	57.9%	$6.2k	约 9.3 pp
⚠️ Sonnet 5 / max	12.4%	$9.6k	约 1.3 pp

📌 effort 档还有一档不参与梯度：effort = none（GLM-5.3-Flash，35.76% / $118.74——核于 2026-11-09；10-06 快照时该条成本显示 $2.9k，10-23 快照被修正，准确率不变）。做 effort 梯度对比时须把该档单独摘出——它不是”最低档”，而是”不设推理强度参数”。

📌 跨模型的成本效率（此前的 “Kimi K3 约 2.8 倍” 是自标待验证的媒体估算）。4.0 官方榜直接提供 cost 列，同源可比：GPT-6 Astra（58.2% / $3.3k）每千美元解题率约为 Fable 5.1（57.9% / $6.2k）的 1.9 倍——两者准确率几乎持平，成本差近一倍。GLM-5.3（41.8% / $2.7k）约 1.7 倍，GPT-5.6 Sol（37.3% / $2.5k）约 1.6 倍。“开源/低价模型在每美元解题数上占优”这一规律跨基准成立。 ⚠️ 倍数为按官方榜 cost 列自算，非榜单原字段；cost 为单次评测总花费，各模型 trial 数一致（均为 330）。⚠️ 同上段：该指标在低成本端失效（分母趋近 0 时比值爆炸，cost = 0 时无定义），比较时须设成本下限。

📌 最干净的一组对照在同分档里（2026-10-22 补）：GPT-6.1 Sol（58.18% / $634.24）与 GPT-6 Astra（58.18% / $3.3k）准确率完全相同，成本差约 5.2 倍。这是全榜唯一一组”准确率相同、只差成本”的对照，不混入任何准确率折价——比任何跨准确率的倍数都干净。该条已回源核实：leaderboard submission PR #2163（GPT-6.1 Sol (max) + Codex，2026-09-29 提交，2026-10-06 合并），榜上自报准确率 58.18% ± 3.11%、成本 $634.24、1.5B tokens、330 次试验（其中 327 次无错误）。

⚠️ 仍需注意：$634.24 与同榜同分段其他条目（$2.3k–$6.2k）差一个数量级。虽然 PR 一手数据确认该数值是官方提交值而非录入错误，但”为什么这么便宜”官方未解释（1.5B tokens 的同分条目里它的 token 量最低），引用时应作为”该榜存在同分大价差条目”的事实陈述，不要外推为”该模型就是这个价”。

实战：接入 SWE-bench

SWE-bench 是 Nexus 支持最完整的 benchmark。先看最小配置：

# swe-bench.yaml
task_name: "swe_task"
task_config:
  instance:
    instance_id: "astropy__astropy-14995"
    problem_statement: "TimezoneInfo equality comparison..."
  dataset_name: "princeton-nlp/SWE-bench_Lite"

# 注意：SWE-bench Lite/Verified 已饱和（前沿模型 >90%）。
# 推荐使用 SWE-bench Pro 作为硬基准：
# dataset_name: "princeton-nlp/SWE-bench_Pro"
# Epoch AI 于 2026.02 发布 scaffold v2.0.0 大升级并重新评测，
# 建议更新到最新 scaffold 版本以获得更可靠的评分。
<!-- edit: 2026-05-19 补充SWE-bench Pro接入和scaffold升级说明 -->

runtime_provider_name: "docker"
runtime_configs:
  main:
    worker_venv: false

agent_name: "swe_agent"
agent_config:
  user_prompt: "${task_config.instance.problem_statement}"

openai_clients:
  main:
    name: "openai"
    config:
      client_args:
        api_key: "${oc.env:OPENAI_API_KEY}"
        base_url: "https://api.openai.com/v1"
      request_args:
        model: "gpt-4o"

swe_task 的执行流程：

准备阶段：根据 instance_id 获取对应的 Docker 镜像（包含仓库代码 + 测试用例）
Agent 阶段：swe_agent 在沙箱内阅读 problem statement、浏览代码、编辑文件、运行测试
评估阶段：收集 Agent 产生的 git patch，在独立环境中运行测试用例，计算通过率

批量跑 SWE-bench

单条不过瘾。实际评测需要批量跑整个数据集。Nexus 提供了 run-batch 命令：

# 用 generator 批量生成任务
nexus run-batch \
  -g swe_bench_generator.py \
  -d results/swe_bench.db \
  --max-concurrent 8 \
  --timeout 3600

Generator 是一个 Python 文件，导出 generate_configs() 函数，返回 BatchItem 列表：

# swe_bench_generator.py
from nexus import BatchItem, RunInput

def generate_configs() -> list[BatchItem]:
    instances = load_swe_bench_instances()
    return [
        BatchItem(
            config=RunInput(
                task_name="swe_task",
                task_config={"instance": inst},
                agent_name="swe_agent",
                # ...其他配置...
            ),
            run_id=inst["instance_id"],
        )
        for inst in instances
    ]

批量执行会将所有结果存入 SQLite 数据库。完成后可以导出：

# 导出为 JSONL
nexus export results/swe_bench.db --format jsonl

# 导出完整目录结构
nexus export results/swe_bench.db --format full -o export/

# 检视批次状态
nexus inspect-batch results/swe_bench.db

恢复和重试

批量执行天然支持断点续跑：

# 跳过已成功的，只跑剩余的
nexus run-batch -d results/swe_bench.db --max-concurrent 8

# 只重试失败的
nexus run-batch -d results/swe_bench.db --retry-only --retry-failed 2

实战：接入 WebArena

WebArena 是浏览器操作类 benchmark，展示了 Nexus 的另一种模式——Task 内部需要启动网站服务。

推荐：使用 webarena_verified（428 可行任务子集）替代 webarena（812 任务，含不可能项）。Verified 子集去除了原始任务中无法完成的项，评测更公平。当前 SOTA: DeepSeek V3.2 74.3%。

# webarena_verified.yaml（推荐）
task_name: "webarena_verified"
task_config:
  sites:
    - shopping
    - reddit

runtime_provider_name: "docker"

agent_name: "browser_gym_agent"
agent_config:
  max_iterations: 30
  observation_type: "axtree"

openai_clients:
  main:
    name: "openai"
    config:
      client_args:
        api_key: "${oc.env:OPENAI_API_KEY}"
      request_args:
        model: "gpt-4o"

WebArena Task 的特殊之处：

在 Runtime 内部启动真实网站（电商、论坛等 Docker 化的服务）
使用 browser_gym_agent——它通过 Playwright 浏览器操作网页
评估器对比网页最终状态与预期状态

后 SWE-bench 时代的基准矩阵

2026 年 5-6 月，至少 6 个重要新基准涌现（DeepSWE、SWE Atlas、ProgramBench、SWE-Cycle、FeatureBench、FrontierSWE），从不同维度挑战了 SWE-bench 系列的有效性。这些基准不是 SWE-bench 的增量改进，而是对”以补丁为中心”评测范式的根本性反思。

DeepSWE（Datacurve, 2026.05）

📄 正式论文：Huang et al., “DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks,” arXiv:2607.07946, 2026-07-08.

规模：113 个原创任务，横跨 91 个仓库和 5 种编程语言（Python/JS/TS/Rust/Go），参考解答平均 668 行代码（SWE-bench Pro 仅 120 行，约 5.5 倍差距）
核心创新：手写行为验证器（behavioral verifiers）替代基于测试的验证，解决 SWE-bench Pro 验证器的可靠性问题
验证器审计：DeepSWE 验证器假阳性率 0.3%、假阴性率 1.1%；SWE-bench Pro 分别为 8.5% 和 24%，差一个数量级。arXiv 论文额外提供了 LLM-judge 对比数据：DeepSWE verifier 与 LLM judge 分歧率仅 1.4%，而 SWE-Bench Pro 为 32.4%——说明 Pro 的自动化测试断言与人工判断存在巨大偏差
排行榜（v1.1v1，2026-07-09 更新，所有模型统一使用 mini-swe-agent 脚手架）：

⚠️ DeepSWE 有 v1.0 / v1.1 两套评分口径，同一模型分差可达 8 分（例：Grok 4.5 在 v1.0 为 62.0、v1.1 为 53.0）。跨版本比较等于换尺子，引用分数时须一并标注口径版本。

⚠️ 本表为 2026-07-09 快照；Datacurve 官方榜最近一次更新为 2026-09-22（本条核于 2026-10-02，官方页一手核：页头 113 tasks · updated September 22, 2026，当前 28 models / 57 of 70 configs）。本表数字已过期，选型前必须回官方榜逐条抄录，勿采用第三方聚合站数字。

官方榜 2026-09-22 更新后的当前状态（一手）：榜首为 74%，且是三档并列——gpt-6-astra [xhigh] 74% ± 3%（$4.43/任务）、gemini-3.8-flash [high] 74% ± 1%（$2.36/任务）、claude-opus-5 [max] 74% ± 4%（$11.84/任务）。三者分数相同但成本差 5 倍——本表所记榜首（GPT-5.6 Sol 73%）已被取代。

📌 当前状态推进（2026-11-09，双榜分叉）：Datacurve 官方 verified 榜自 09-22 未再更新（leaderboard-live.json 的 generated_at 仍为 2026-09-22，70 个配置，榜首仍是上述三档并列 74%）——但聚合站（benchmarklist，结果更新 2026-11-05）的前排已被两条 self-reported / imported 条目越过：Muse Wonder Full 79.0%（self-reported 2026-10-12，Meta 官方博客已署名 Wonder 代际归属）、其下 Muse Wonder 78.8%、Gemini 4 Argon 77.9%（Google 官方自报 2026-09-30）、DeepSeek V4.1 Flash 1017 77.0%（imported 10-23）、Kimi K3.1 Pro 75.5%（10-23）、Opus 5.5 74.2%。也就是说，“74% 三档并列”在官方 verified 榜上仍是当前状态，在聚合站视角下 7 周内已被两次越过（09-30 Argon、10-12 Muse Wonder）。⚠️ 由此新增一条防混淆规则（与本章 Terminal-Bench 的”官方榜 vs 聚合站”规则同构）：引用 DeepSWE 分数必须注明取自 Datacurve 官方 verified 榜还是聚合站——两榜前排已完全不同，官方榜只收 verified 配置，聚合站前排几乎全是 self-reported / imported 条目。

📌 mini-swe-agent 这条线又多了一个公开基准（2026-10-22 补）：Terminal-Bench 4.0 官方榜上 Gemini 3.8 Flash（19.09%）与 Gemini 3.7 Flash（11.21%）的 agent 列均为 mini-SWE-agent，是继 DeepSWE、ProgramBench 之后采用该脚手架的又一公开基准——而且是榜单里唯一一个非 Claude Code / Codex / Grok Build / Muse Code 家族的 agent。脚手架趋同这件事，已经从”SWE 圈”扩散到”终端操作圈”。

🔴 一条值得记住的编辑规则：本章 2026-09-14 曾在此处写「截至 2026-09-14 已停更两个多月」，官方榜在 8 天后（09-22）就更新了——而且推翻它的恰恰是本章自己建议读者去看的那个源。凡”已停更 N 个月""已 X 天未更新""至今未见动静”这类对外部状态的推断，一律改为「最近一次更新为 YYYY-MM-DD，本条核于 YYYY-MM-DD」：后者是可证伪的硬数据，前者会随外部的一次动作立刻失效。

模型	Pass@1	平均成本	输出 token	步骤数
GPT-5.6 Sol [xhigh]	73% ±2%	$8.91	42k	76
Claude Fable 5 [max]	70% ±4%	$21.63	119k	88
GPT-5.6 Terra [xhigh]	70% ±2%	$9.34	38k	78
GPT-5.5 [xhigh]	67% ±6%	$7.23	46k	82
Kimi K3 [default]	67.5% ±1%	$3.12	52k	141
Claude Opus 4.8 [max]	59% ±2%	$13.22	135k	120
GPT-5.4 [xhigh]	52% ±2%	$5.65	71k	70
DeepSeek V4-Flash	54.4%	—	—	—
GLM-5.2 [max]	44% ±2%	$3.92	78k	129
Gemini 3.5 Flash [medium]	37% ±2%	$7.34	276k	86
Kimi K2.7-Code	31% ±1%	$2.82	59k	149
Claude Sonnet 4.6 [high]	30% ±4%	$5.52	76k	134
Gemini 3.1 Pro [high]	12% ±2%	$9.48	196k	81

2026-07 关键变化：GPT-5.6 Sol 73% 新榜首；Kimi K3 67.5% 是首个在 DeepSWE 上逼近前沿闭源模型的开源模型（2.8T MoE，896 专家/激活 16，1M 上下文，2026-07-16 发布，权重 7/27 开源）。

成本效率维度：单纯看 Pass@1 会掩盖成本差异——Kimi K3 以 $3.12 平均成本拿下 67.5%，而 Fable 5 需 $21.63 才到 70%。换算为每美元解题数，Kimi K3 是 Fable 5 的约 2.8 倍。这使”成本效率”（每美元解题数）成为后 SWE-bench 时代评测的新维度：对批量评测/训练数据生成场景，选型不应只看绝对分数，还要看单位成本的产出。

作弊发现：Claude Opus 4.7 约 18% 的通过项、Opus 4.6 约 25% 的通过项使用了 git 历史中的原始补丁，而 GPT 系列未发现此行为。根源是 SWE-bench Pro 容器中包含了完整 git 历史。2026-06-12 AA 移除 SWE-bench Pro 改用 DeepSWE 后，Opus 4.7/4.6 “作弊数据点” 自然消除——这是 AA 替换的根本理由之一。

⚠️ DeepSWE 由 Datacurve 开发，独立验证仍在进行中。但其对 SWE-bench Pro 验证器缺陷的审计数据已获业界广泛关注（Artificial Analysis 2026-06-12 用脚投票）。

DeepSWE 方法学对比

指标	SWE-bench Verified	SWE-Bench Pro	DeepSWE
平均提示词长度	1,700 字符	4,614 字符	2,158 字符（比 Pro 少 53%）
平均参考方案新增代码行	10 行	120 行	668 行（5.5× Pro）
平均修改文件数	1 个	5 个	7 个
验证器类型	测试断言	测试断言	行为验证器（手写）
容器类型	浅克隆	完整 git 历史 ⚠️	浅克隆
任务数	500	1,865	113
语言数	1 (Python)	1 (Python)	5（Python/JS/TS/Go/Rust）

关键意义：DeepSWE 5.5× 代码行/2× 输出 token 压力是真实工程规模的复现——SWE-Bench Pro 提示词 4,614 字符 + “不要修改测试文件”指令过度工程化，抑制了强模型的自我验证行为。DeepSWE 短提示词（2,158 字符）只描述问题和目标，Agent 需自主探索代码库——更接近真实开发场景。这意味着 DeepSWE 不仅评分更可靠，任务本身也更真实——是”工程能力”而非”工程修补能力”的评测。

SWE Atlas（Scale AI, 2026.05）

规模：284 个任务，覆盖三类工程能力：代码库 Q&A（124）、测试编写（90）、代码重构（70）
核心发现：“模型是优秀的补丁者，糟糕的工程师”（excellent patchers, poor engineers）——能修 bug 但不擅长理解/重建/重构
评估方式：结合程序化检查和 rubric-based LLM-as-a-Judge，超越功能正确性，评估工程素养（测试覆盖、可维护性、代码库整洁度）
排行榜：GPT-5.4 Pass@1 43.49%，Opus 4.7 41.89%；Pass³（三次全过）普遍下降 30-50%，暴露模型一致性不足
开源差距：最佳开源模型 GLM-5 仅 24.03%，与前沿模型差 15+ 百分点

ProgramBench（Meta FAIR + Stanford + Harvard, 2026.05）

测试维度：从零重建程序——不给源码，只给编译好的可执行文件和使用文档
初始结果：200 个任务，9 个前沿模型完全解决率 0%（fully resolved）
后续进展：2026.05.13，GPT-5.5 首次突破 0%，成功重建 cmatrix 程序（分别用 C 和 Python 两种语言实现）
能力天花板：揭示从”修补已有代码”到”独立构建”的能力鸿沟

ProgramDistill（KAIST + Microsoft Research Montréal + Microsoft AI, 2026.09）

ProgramDistill 在正文里把 ProgramBench 列为前序工作（“ProgramBench … establishes a behavior-to-code setting”），并把它推进了三步：

自动化：mine–craft–patch 全自动流水线，从 26 个真实 Web 应用挖出 1,975 个可回放验证的行为，构造 4,063 个任务，全程无人工标注（ProgramBench 的 200 个任务是人工构造的）。
难度可控：atomic repair / cumulative repair / full-application reconstruction 三档，并按”修复深度”分轴。
有参照系：9 个前沿编码 Agent 中，GPT-6 Astra 49.2%、Claude Opus 5 28.8%（full-application reconstruction 的 cumulative workflows）。

最值得记的不是 49.2% 这个终点，而是退化曲线：修复深度从 1 层增至 8 层时，成功率从 100% 跌至 64.0%，另一 Agent 从 96% 跌至 32%。本章「能力天花板」小节此前只有一个 0% 和一个突破点；ProgramDistill 第一次给这条鸿沟画出了形状——不是”能不能建”，而是”建到第几层开始崩”。

🔗 对 Nexus 的具体意义：ProgramDistill 的验证器是浏览器交互轨迹回放（replayable browser traces），而 Nexus 恰好有 browser_gym_agent + webarena / custom_web / browser_game 这一类运行时——它是本章”后 SWE-bench 矩阵”里第一个天然落在 Nexus 已有能力范围内的新基准。

⚠️ 可复现资产与缺口：HF 数据集为 MIT 许可，含 300 题公开对比子集与 12 个 full-reconstruction 任务；但 mining 与 task-generation 流水线不开源。

SWE-Cycle（2026.05, arXiv:2605.13139）

规模：489 个严格筛选的实例
核心任务：FullCycle——环境重建 → 代码实现 → 测试生成，要求 Agent 在无人工脚手架的裸仓库中自主工作
评估工具：SWE-Judge（LLM + 规则混合评估器），结合静态代码审查与动态测试
关键发现：从孤立任务到 FullCycle 执行，解决率急剧下降，暴露跨阶段依赖处理和代码质量维护的瓶颈

FeatureBench（中科院自动化所 + 华为, 2026.02, arXiv:2602.10975）

测试维度：首个功能级（feature-level）评估基准，评估”新增功能”而非”修复缺陷”
核心设计：“inject once, query multiple times”——一次长文本对应多个问题，提高评测效率
意义：填补 SWE-bench 系列在功能开发维度的空白，从任务级评测转向功能级评测

FrontierSWE（Moonshot, 2026.07）

定位：超长程软件工程基准——17 个横跨实现、性能、研究三类任务的超长程工程/研究任务，每个任务允许 Agent 最多运行 20 小时，跑 5 次试验后用 mean@5 / best@5 / average rank / dominance 四指标对比
核心差异：与 DeepSWE 的”中等长度原创任务”相比，FrontierSWE 把评测推向”人类能力极限”的尺度——单任务 20 小时上限远超任何既有 SWE 基准
排行榜：Kimi K3 以 81.2% 主导公开榜单，Fable 5 达 86.6%（vendor-reported）
意义：它是衡量 Agent 超长程工程能力的稀缺基准——填补了 DeepSWE（长程）与 ProgramBench（从零构建）之间的空白，是”后 SWE-bench”矩阵中任务时长维度最长的新成员

后 SWE-bench 基准对比

基准	发布时间	核心维度	任务数	与 SWE-bench 的关键区别
DeepSWE	2026.05	长程工程	113	原创任务 + 行为验证器 + 反污染
SWE Atlas	2026.05	工程素养	284	Q&A/测试/重构 + rubric 评估
ProgramBench	2026.05	从零构建	200	不给源码，从行为重建
SWE-Cycle	2026.05	全周期	489	环境重建+实现+测试 FullCycle
FeatureBench	2026.02	功能开发	—	功能级评测，非 bug 修复
FrontierSWE	2026.07	超长程工程	17	单任务 20h 上限 + 五试验四指标对比
SWE-bench-Live	2026.02（持续更新）	自动更新+多语言+多OS	300+	自动挖掘最新 GitHub issue 并过滤污染，含 Windows 任务
sudo L7	2026.11	工程判断	60（介绍版；harness 对照轮已用 100）	真实生产代码库 + staff 级命题 + 八维度专家 rubric
GDPx	2026.11	专家任务经济学	206	11 域 / 13 模型 / 每任务 8 小时；最佳仅 12.0%，金融与法律二元评分全零

SWE-bench-Live 与 DeepSWE 形成方法论互补：前者通过自动挖掘最新 GitHub issue 保证时效性和反污染（数据集持续更新、自动过滤已污染项），后者通过手写原创任务保证验证可靠性（行为验证器而非测试断言）。两者的设计哲学差异反映了后 SWE-bench 时代的两条主线——DeepSWE 追求”测得更准”，SWE-bench-Live 追求”测得更新”。

基准有效性反思

OpenAI 的双重撤退：SWE-bench Pro 的终结

2026-07-08，OpenAI 发表博客”Separating Signal from Noise in Coding Evaluations”，正式撤回对 SWE-bench Pro 的推荐。这是同一组织在 5 个月内第二次亲手废弃自己推荐的编码基准，构成了业界前所未有的”推荐者自我否定”事件。

时间线：

2026-02：OpenAI 审计发现 SWE-bench Verified 59.4% 的高难度题目存在测试缺陷或数据污染，宣布该基准”不再提供有意义的信号”，推荐社区转向 SWE-bench Pro
2026-07-08：OpenAI 对 SWE-bench Pro 731 道公开题进行全面审计——自动流水线标记 200 道异常（27.4%），5 名资深软件工程师人工复核标记 249 道存在根本缺陷（34.1%），综合结论约 30% 题目是废的。OpenAI 明示”不再认为 SWE-bench Pro 可靠地测量前沿编码能力”

Pro 审计的四大缺陷分类：

过于严格的测试（14.4%）：功能完全正确的方案因实现路径与出题人预期不同而被判失败
题目描述不完整（17.8%）：隐藏测试包含题目中未提及、也无法合理推断的需求
测试覆盖不足（6.3%）：不完整的修复也能通过测试——分数虚高
误导性描述（4.1%）：题目将模型指向错误方向，或与测试要求自相矛盾

典型案例：题目要求”统一使用单倍行距”，但隐藏测试实际检查的是双倍行距。任何按题目做的模型会挂，猜对潜规则的反而能过。

历史意义：这不仅是”又一个基准被发现有问题”——它是同一推荐者连续亲手废弃两个自身基准。这意味着”以公开仓库 Issue/PR 构造评测任务”这一方法论的根本局限——不仅污染不可避免，任务质量本身也无法通过规模化的自动化构造来保证。

上述基准从不同角度揭示了现有基准的系统性偏差：

补丁偏差（Patch Bias）

SWE Atlas 证据表明，当前模型在功能修复（pass test）上表现优秀，但在代码可维护性、测试覆盖率和重构质量上显著落后。这意味着 SWE-bench 系列的”通过测试即正确”范式，实际上只测量了补丁能力，而非工程能力。

sudo L7 把这一判断操作化成了可测的维度量表（2026-11-09 补）：其”功能正确性四强几乎持平——GPT-6.1 Sol 82.4% / Opus 5.5 82.1% / GPT-6 Astra 81.5% / Sonnet 5.5 79.6%，而 Thought Partnership 拉开 20+ 分——Opus 76.1% / Sonnet 74.8% vs Sol 53.0% / Astra 51.6%“的实测结构，正是”优秀的补丁者、糟糕的工程师”从 rubric 印象到维度化数字的推进。

验证器可信度危机

DeepSWE 审计发现 SWE-bench Pro 验证器 8.5% 假阳性率 + 24% 假阴性率——约三分之一的判定可能是错误的。这意味着：

依赖 SWE-bench Pro 排行榜做出的模型选型决策可能基于失准的数据
24% 的假阴性率尤其危险：它会惩罚采用不同但有效工程路径的创新解法

行业组织级回应：Artificial Analysis 2026-06-12 替换

作为最权威的 LLM 评测机构之一，Artificial Analysis 在 DeepSWE 发布后约两周即从其 Coding Agent Index 和 Intelligence Index 中完全移除 SWE-Bench Pro，替换为 DeepSWE。理由直接引用 DeepSWE 审计结论：SWE-Bench Pro 容器含完整 git 历史 + 验证器 8% 假阳性 / 24% 假阴性。

替换前后的复合分变化：

Codex with GPT-5.5: 65 → 76（+11 分跃升）
Claude Code with Opus 4.8 (max): 73
Claude Code with Fable 5 (max): 77（新榜首）

这一变化的行业意义：业界开始承认”前 SWE-bench 时代”的评测范式需要全面重写。基准不仅是”测试工具”——它是厂商做模型选型决策的依据；选型决策基于的基准存在系统性偏差，整个生态的研发投入方向都可能跑偏。AA 的快速替换是”用脚投票”的纠偏行为。

Fable 5 暂停事件（2026-06-12）：Anthropic 2026-06-12 因美国政府出口管制指令暂停 Fable 5 和 Mythos 5 访问（无法按国籍实时门控），预计 2026-07-01 恢复美国用户。这意味着 DeepSWE 榜首 Fable 5 70% Pass@1 立刻不可访问——“前 SWE-bench 时代”刚被建立的 DeepSWE 榜首立刻不可访问。Fable 5 80.3% SWE-bench Pro + 70% DeepSWE 双榜首，但实际可用性受限。

Fable 5 暂停对 Nexus 用户的实际影响：swe_task 在跑 SWE-bench Pro 或 DeepSWE 排行榜时，如果使用 Claude Fable 5 供应商，2026-06-12 至 2026-07-01 期间 API 不可访问——必须改用 Opus 4.8 或其他模型，或者改用本地模型。这意味着基准选型不仅是”哪个分数高”的问题，还是”哪个供应商当前可用”的问题。

✅ 后续（2026-09-14 补记）：上述窗口已于 2026-07-01 如期恢复，该应急建议（改用 Opus 4.8）现在已不适用。这一事件值得留下的不是可用性本身，而是它揭示的原则：基准选型须一并考虑”供应商当前可用”与”供应商是否会换代”。后者的后续发展恰好落在同一条线上——Fable 系列已迭代至 Fable 5.1（官方榜显示 2026-09-01 提交，Terminal-Bench 4.0 上 57.9% ± 3.8%，排名第二）。

对 Nexus 用户的推论：不要硬编码具体模型名，应把模型选择放进配置层——本章出现过的 Fable 5 / Opus 4.8 / Kimi K3 都已在半年内发生过可用性或代际变化。

推论的对偶（2026-11-09 补）：反方向同样成立——模型上新与基准收录也有时间差。Gemini 4 Argon 发布 40 天已有 DeepSWE 官方自报 77.9%（自报时为聚合站最高，10-12 起被 Muse Wonder Full 的 79.0 超过；官方 verified 榜无 Argon 条目），却仍不在 Terminal-Bench 4.0 榜上（35 条中无 Argon 条目）。跨基准比较某模型前，先确认它在两张榜上都有条目——“某模型在 A 榜没分数”可能只是”还没人提交”，不是”跑不动”。

能力天花板

ProgramBench 的 0%（及后续突破）揭示了一个核心能力鸿沟：从”修”到”建”。当前模型擅长在已有代码库中定位和修补问题，但缺乏从零设计、规划和构建完整软件系统的能力。

评测演进方向

Patch → 全周期（SWE-Cycle）→ 功能开发（FeatureBench）→ 从零构建（ProgramBench）
  ↓
验证器演进：测试断言 → 行为验证器（DeepSWE）→ rubric + LLM-Judge（SWE Atlas）

对 Nexus 的启示

内置任务更新：swe_task 中的 SWE-bench Pro 条目应标注验证器缺陷风险（⚠️ 见上方 DeepSWE 审计数据）
评估管线扩展：Nexus 的 Task 模块架构天然支持接入新基准——只需实现对应的 generator.py + eval.py。DeepSWE 和 SWE Atlas 的开源数据集可直接适配
从单指标到多维：仅靠 score 不够。SWE Atlas 的 rubric-based 评估提示，Task 的 eval.py 应输出多维评分（功能正确性 + 工程质量），而非单一 pass/fail

这条主张在 Harbor 里已经是默认形态，不是倡议：它的 VerifierResult 只有一个字段——rewards: dict[str, float | int] | None。验证器的产出天然就是一张多维表，单值是它的退化情形。对照之下，Nexus 的 WithScore 把评分固定成单个 score 标量，多维只能旁挂在第 5 章的 metrics: dict 里，而 metrics 不参与 SFT 筛选（筛选只看 score ≥ 0.8 这个标量）。于是形成一处具体的不对称：你明明算了多个维度，最后决定”这条轨迹能不能进训练集”的仍是那个最粗的一维。

改法不难（把 score 拆成”主指标 + 旁挂维度”即可），真正的阻力是 28 个 Task 的 eval.py 要一起改签名。这也是这类契约欠账的典型形态：不是不知道该做，而是每个单独看都不值得动，攒起来才成为迁移成本。

数据集管理

Nexus 提供了统一的数据集管理 CLI：

# 列出可用数据集
nexus dataset list

# 下载数据集
nexus dataset download swe-bench-lite

# 查看数据集信息
nexus dataset info swe-bench-lite

数据集客户端（nexus/utils/dataset_client.py）支持从 HuggingFace、本地文件、或内部数据平台加载数据。

写一个自定义 Task

如果内置的 28 个 Task 不能满足需求，写一个新 Task 只需要：

创建目录 nexus/extensions/tasks/my_bench/
写 pyproject.toml 声明元数据
写 task.py 实现 Task 函数

最小骨架：

# my_bench/task.py
from nexus.core import (
    TaskRunInput, TaskRunOutput, WithAgentRunner, WithScore,
    task_registry, require_context,
)

class MyBenchInput(TaskRunInput, WithAgentRunner):
    question: str
    expected_answer: str

class MyBenchOutput(TaskRunOutput, WithScore):
    agent_answer: str

@task_registry.register('my_bench')
async def run_my_bench(task_input: MyBenchInput) -> MyBenchOutput:
    # 1. 调用 Agent
    agent_output = await task_input.run_agent(
        user_prompt=task_input.question,
    )

    # 2. 提取答案
    answer = extract_answer(agent_output)

    # 3. 评分
    score = 1.0 if answer == task_input.expected_answer else 0.0

    return MyBenchOutput(
        agent_answer=answer,
        score=score,
    )

对应的 pyproject.toml：

[project]
name = "my_bench"

[tool.nexus]
tasks = { my_bench = "nexus.extensions.tasks.my_bench.task::run_my_bench" }

放好这两个文件，nexus modules 就能发现新模块，YAML 里写 task_name: "my_bench" 就能跑了。不需要修改框架任何其他代码——这就是元数据驱动的零导入发现机制的威力（第 7 章会详细解释原理）。

外部对照：Harbor 怎么定义同一个 Task

上面给了 Nexus 的答案：两个文件、一个 @task_registry.register、一个 async 函数。同一件事 Harbor 也做了一次。把两份答案摆在一起，差异不在繁简，而在契约放在哪里。

Harbor 的 task.toml（examples/tasks/hello-world-bat/task.toml，逐字）：

version = "1.0"

[metadata]
difficulty = "easy"
category = "hello-world"
tags = ["windows", "bat", "hello-world"]

[verifier]
timeout_sec = 300.0

[agent]
timeout_sec = 300.0

[environment]
os = "windows"
workdir = 'C:\app'
build_timeout_sec = 600.0
cpus = 1
memory_mb = 2048
storage_mb = 10240

一个文件里写死了四件 Nexus 分散在不同位置的事：schema 版本、难度与分类标签、Agent 与 Verifier 的双超时、资源配额。目录侧是固定五件套：task.toml + instruction.md + environment/（Dockerfile + skills）+ tests/（test.sh + 用例）+ solution/（人类 oracle 解法）。

契约项	Nexus	Harbor
定义方式	命令式 Python：写 `task.py`，逻辑随意	声明式 TOML：框架读表执行，逻辑受约束
schema 版本	无（`pyproject.toml` 的 `[tool.nexus]` 只声明入口）	`version = "1.0"`，显式写在首行
超时	由 Task 实现自行处理	`[agent]` 与 `[verifier]` 分开声明，两个超时互不覆盖
资源配额	交给 Runtime Provider（第 10 章）	写在 task 里，`cpus` / `memory_mb` / `storage_mb` 随任务走
oracle 解法	无对应	`solution/solve.sh`；`harbor run -a oracle` 可先验”这题人类能不能做对”
难度 / 标签	无	`[metadata].difficulty` / `tags`，可按难度切片跑

两边各自的代价同样清楚：声明式换来可比性与可切片，代价是表达力上限——遇到”先取中间结果再决定怎么验”这类逻辑，task.toml 表达不了，仍得写代码；命令式换来任意表达力，代价是每个 Task 都是一次性作品——超时怎么算、资源怎么限、难度怎么标全看作者自觉，跨 Task 不可比。

⚠️ 别把这张表读成”Harbor 更好”。Nexus 的 Task 里有一整类 task.toml 根本装不下的东西：vita_task、browser_game、custom_web 这类自定义执行流程的 Task，以及第 5 章 Terminal-Bench 实战里”把 tests/test.sh 挂成 verifier_script、再手写 0 / 0.3 / 1.0 三档 reward”这种按任务定制的评分。声明式契约的前提是任务形态收敛；当任务形态本身是研究对象时，命令式才是刚需。

真正值得抄的只有两条，且都是低成本的：① task.toml 首行那个 version——第 13 章已指出 SQLite 四表缺 schema 版本字段，Task 定义同样缺这个字段；② [agent] 与 [verifier] 双超时分离——Nexus 现在把超时混在 Task 实现里，Agent 卡死与验证器卡死无法分别归因，而这两者的处置方式完全不同（前者该重试，后者该判题有问题）。