用 NXS 跑 FrontierHarness，30 题通过 22 题
我们用 NXS 跑完 FrontierHarness 的 30 道题。22 道通过，8 道失败，真正值得看的在失败任务的时间和成本。
9 月 1 日，Runta 发布了 Coding Agent Harness 评测 FrontierHarness Eval。
他们让同一个 Kimi K3 完成 30 道题，每轮只更换 Agent Harness。公开结果里，通过率从 50.0% 到 66.7%，每通过一道题的成本从 1.05 美元到 18.34 美元。
我们把发布文章、任务和逐题结果对了一遍。模型相同，Harness 带来的差距比预想中大。
图片来自 Runta 与 FrontierHarness 公开仓库。
先看官方评测
FrontierHarness v1.0 选了 30 道题，其中 21 道来自 Terminal-Bench，9 道来自 DeepSWE。Runta 测了 9 个 Harness、12 组配置，一共运行 360 个 cell。
所有配置都使用 Kimi K3，经由同一个网关连接 Fireworks。任务环境先做成 Golden Checkpoint，每次运行都从新快照恢复，vCPU、内存、磁盘和内存状态保持一致。正式题没有提前调试，每个 cell 只跑一次。
模型、题目与运行环境固定以后，Harness 成为主要变量。
Codex 通过 20 题，通过率为 66.7%。DSH Creator 和 Claude Code 都通过 19 题，通过率为 63.3%。后两者的结果一样，单题通过成本分别为 3.28 美元和 18.34 美元，相差 5.6 倍。
Exo Harness 通过率为 53.3%，每通过一道题花 1.05 美元。它在官方展开的长任务里走到 51 步上限后停止，花了 1.46 美元。失败便宜不代表任务完成。产品如果自动重试，这笔钱还会继续增加。
模型生成下一步，Harness 决定模型能看到什么、能用哪些工具，也负责上下文和失败后的重试。通过率只给出了其中一个结果。
NXS 在本地通过 22 题
NXS 是 Nexus 默认使用的 Agent Runtime。Nexus Host 负责 Room、消息和协作状态，NXS 在独立进程里运行 Agent loop，调用模型与工具，并管理自己的上下文。
以前测试 NXS，我们会检查文件能不能读、命令能不能跑、补丁能不能写回去、session 能不能正常结束。这些测试能发现功能故障，看不出它处理完整任务时能走多远。
FrontierHarness 提供了 30 道带 verifier 的题。我们沿用这批题，在本地用 NXS 跑了一轮。
模型仍是 Kimi K3，接入 Kimi 官方 Coding API。评测由 Harbor 0.20.0 驱动，宿主机是 Apple Silicon，任务容器为 Linux ARM64。NXS 使用 stock-no-memory 配置，关闭 Session Persistence 和 AutoMemory。并发任务组设为 1，每次只推进一道题。
题目与模型和官方评测相同，其他条件不同。Runta 使用 Fireworks、统一网关和 Golden Checkpoint，我们使用 Kimi 官方 API 与本地 Docker Desktop。13 道题在 API 或 verifier 故障处理后重新运行。
NXS 最终通过 22 道题，通过率为 73.3%。
Terminal-Bench 通过 18 / 21，DeepSWE 通过 4 / 9。22 道成功任务的执行时长中位数是 3 分 35 秒，缓存命中中位数是 95.6%。29 道留下 usage 的任务合在一起，Token 加权缓存命中率是 97.8%。
图里的 NXS 带有 LOCAL* 标记。官方公开结果中，最高成绩是 Codex 的 20 / 30。NXS 在本地多通过两题，但 Provider、机器架构、环境恢复和重跑条件都不一样，不能据此排进官方榜单。
官方 12 组配置都通过的 Terminal-Bench 有 12 道，NXS 也全部通过。NXS 还通过了 kv-store-grpc 和 largest-eigenval，两道题在 FrontierHarness 的公开数据里都是 0 / 12。
DeepSWE 的 4 道通过项是 anko-typed-variable-bindings、fastapi-deprecation-response-headers、httpx-multipart-response-parsing 和 python-statemachine-state-data-scoping。其余 5 道失败题在官方 12 组配置中，最多只有 2 组通过。
一道跑了 52 分钟的题
Runta 用 python-statemachine-state-data-scoping 展示不同 Harness 的执行过程。这道题要修改状态机、回调注入、历史恢复、序列化、SCXML 解析和图表生成。官方给出的历史通过率是 38%。
NXS 也通过了这道题。它用了 98 个模型回合，调用工具 146 次，缓存命中率为 98.5%，执行时间为 52 分 16 秒。本地记录成本为 7.37 美元。
| 配置 | 结果 | 成本 | 回合 | 缓存 | 时间 |
|---|---|---|---|---|---|
| NXS 本地 | 通过 | $7.37 | 98 | 98.5% | 52m 16s |
| Pi 官方 | 通过 | $2.50 | 90 | 98.2% | 39m |
| Codex 官方 | 通过 | $5.97 | 187 | 99.1% | 37m |
| Claude Code 官方 | 通过 | $64.36 | 381 | 15.7% | 60m |
两边使用的模型服务不同，时间和价格不能直接比较。能确认的是，这道题跨越多个模块，NXS 在 98 个回合后完成了 verifier 要求。
通过题很快，失败题会拖很久
| 口径 | 通过任务 | 失败任务 | 全部任务 |
|---|---|---|---|
| 回合数中位数 | 10 | 58 | 12 |
| 工具调用中位数 | 10.5 | 56.5 | 17 |
| 工具调用总数 | 575 | 498 | 1073 |
8 道失败题占全部工具调用的 46.4%。通过题通常在十个回合左右结束，失败题会继续工作到五十多个回合。成本和耗时的长尾也出现在这里。
| 工具 | 调用数 | 占比 |
|---|---|---|
| Bash | 553 | 51.5% |
| Edit | 209 | 19.5% |
| Read | 142 | 13.2% |
| TaskCreate、TaskUpdate、TaskOutput | 128 | 11.9% |
| Write | 40 | 3.7% |
| EnterPlanMode | 1 | 0.1% |
任务状态工具占 11.9% 的调用量。它们能不能改善长任务完成率，目前没有对照组。下一轮可以只在 DeepSWE 长任务上做一次开关实验，不必重跑整套 benchmark。
八道失败题花掉一半成本
计入结果的 30 个 cell 至少花了 39.34 美元。22 个成功 cell 合计约 18.35 美元，留下完整 usage 的 7 个失败 cell 合计约 21 美元。gcode-to-text 超时后没有留下 usage，实际费用会更高。
以 39.34 美元除以 22 道通过题，每通过一道题至少花 1.79 美元。这个价格来自 Kimi 官方 API。Runta 会重算首轮缓存成本，本轮没有重算。1.79 美元只代表这次本地运行。
8 道失败题用了 53.4% 的已记录成本。成功任务的时长中位数是 3 分 35 秒，失败任务达到 19 分 52 秒。失败任务还占了 46.4% 的工具调用。
几道 DeepSWE 任务只差少数用例。arktype 的新增用例通过 23 / 25，katex 通过 92 / 94，scc 通过 28 / 31。Agent 改完了大部分代码，最后几个边界问题仍然没有解决。
| 任务 | verifier 结果 | 直接原因 |
|---|---|---|
arktype-json-schema-refs-dependencies | P2P 1679 / 1679，F2P 23 / 25 | 两个递归 $defs 引用场景访问到未定义节点 |
expr-try-catch-errors | 基线全过，新增顶层用例 68 / 74 | 错误变量字符串与 errtype 分类不符合要求 |
katex-multicolumn-array-spans | P2P 599 / 599，F2P 92 / 94 | 跨列后仍保留内部竖线分隔符 |
scc-bounded-memory-spilling | P2P 286 / 286，F2P 28 / 31 | 有界内存下的 csv-stream 输出与普通模式不一致 |
meriyah-explicit-resource-declarations | P2P 51469 / 51469，F2P 0 / 49 | using 与 await using 语法没有进入解析路径 |
dna-insert | 0 / 1 | 两条引物 Tm 相差 8.19°C，要求不超过 5°C |
extract-elf | 1 / 2 | 输出覆盖 0%，要求覆盖至少 75% 的参考地址 |
gcode-to-text | 0 / 2 | 900 秒到期，44 次工具调用后仍未生成 out.txt |
dna-insert 和 extract-elf 都在 2 分 34 秒结束，产物没有满足 verifier 的数值条件。交付前跑一次本地检查就能发现问题。gcode-to-text 走到 900 秒上限，仍未生成 out.txt，需要更明确的时间预算和收尾策略。
这轮结果留下什么
NXS 在这组 Terminal-Bench 题里表现很好，DeepSWE 长任务仍然决定整体上限。缓存没有成为主要问题。失败任务的回合数、工具调用、时间和成本一起拉长，运行时需要更早识别停滞，并在预算快用完时转入定向验证和交付。
短任务更需要理解 verifier 的条件。dna-insert 与 extract-elf 都能在交付前用本地检查发现确定性错误。长任务则要保留测试失败的结构化摘要，只修剩余边界，不再反复探索已经走过的路径。
22 / 30 是这次本地运行的结果。它说明 NXS 已经能完成一批长短不一的真实工程任务，也把接下来该改的地方摆到了台面上。下一轮，我们会先盯住那八道失败题。