编码智能体横评 frontier-harness-eval/eval

FrontierHarness Eval

查看实时结果 → · 阅读博客 → · 评测你自己的 harness →

通过率相近，成本相差 17.5 倍。

同一个 Kimi K3 模型，我们跑了九个编码智能体 harness——一共 12 种配置——完成同一批 30 个软件工程任务。模型、任务、运行时都不变，只换 harness，通过率、成本、缓存行为和速度就全变了。

完整结果

| Harness（配置） | 通过率 | 每次通过的中位成本 | 缓存，中位单元格 | 中位耗时 |
| Codex | 66.7% | $3.47 | 88.0% | 6m 43s |
| DSH Creator | 63.3% | $3.28 | 84.3% | 6m 44s |
| Claude Code | 63.3% | $18.34 | 67.8% | 9m 38s |
| Pi | 60.0% | $2.43 | 79.4% | 7m 33s |
| DSH PTC | 60.0% | $4.58 | 87.2% | 7m 44s |
| DSH Standard | 60.0% | $3.46 | 86.5% | 6m 17s |
| Oh My Pi | 56.7% | $4.75 | 82.2% | 6m 46s |
| Kimi Code | 56.7% | $3.65 | 88.0% | 7m 56s |
| DSH Minimal | 56.7% | $4.72 | 84.6% | 5m 41s |
| Exo Harness | 53.3% | $1.05 | 70.3% | 6m 17s |
| OpenCode | 50.0% | $3.24 | 78.4% | 6m 27s |
| Hermes | 50.0% | $2.90 | 85.9% | 6m 58s |
交互式报告包含失败的运行、每个任务的成本、缓存行为、速度，以及任务级结果。评估设计与分析请阅读发布文章。

仓库里有什么

.
├── benchmark.json # Public benchmark definition
├── cli/index.mjs # npx @frontierharness/eval: workspace + skill installer
├── metadata/
│ ├── difficulty.json # Difficulty assignments and source methodology
│ └── harness-versions.json # Harness versions used for the run
├── results/
│ └── eval-data.json # Normalized aggregate and task-level results
├── tasks/<task>/
│ ├── instruction.md # Prompt shown to every harness
│ └── task.toml # Public task metadata and environment definition
└── skills/frontierharness-eval/ # Agent-neutral skill, usable by hand
├── SKILL.md # Evaluation workflow for a third-party harness
├── PROMPT.md # Copy-paste prompt that points an agent at the skill
├── reference.md # Command reference, runner templates, troubleshooting
└── scripts/ # Provisioning, trial runner, scoring, chart, report

仓库有意只包含结果、任务定义和评估工作流。内部基础设施、凭据、运行时标识、私有证据、解答和部署配置都不在其中。

评估你自己的 harness

仓库附带一套复现工作流，用来在已发布的任务集上评估另一个 harness。它会记录与原始基线运行之间的环境差异；要确立可比性，需要一次匹配的对照运行。

试运行网络访问。 智能体可以访问验证器所需的包注册表和源主机，包括 Ubuntu/Debian apt 镜像、PyPI、npm、PyTorch、GitHub 下载主机，以及 Harbor 的任务注册表。Runta 把允许列表应用到整个运行时，包括智能体容器；Harbor/Pier 的任何额外隔离仍然生效。验证器会在试运行期间安装依赖，所以只允许模型服务商和 uv 下载会阻断有效的验证。任务镜像在试运行策略生效之前就已拉取。具体主机定义在 providers.sh。

每个 run.json 都会记录 egress_policy，包含它的模式、作用范围和确切的 allowed_hosts；两个套件使用同一策略，候选数据和报告里也会带上它。已发布的基线没有记录它们实际应用的允许列表，所以新的运行默认 methodology_comparable: false，不会获得排行榜名次。在声称可比之前，请在同一策略和环境下评估一个对照 harness。策略变更或未记录时拒绝恢复运行；新策略请使用新的 run id，并保留早先的证据。
skills/frontierharness-eval/ 是一个与智能体无关的技能：只要让任何能读 SKILL.md 的编程智能体指向它，它就能驱动整个运行流程——冻结黄金检查点，从同一份全新恢复环境跑完每个任务，给试验打分，再生成报告。

如何使用这个技能

让智能体来驱动

用 Skills CLI 安装评测技能和它的 Runta 配套技能（需要 Node.js 和 Git）。在你使用编程智能体的项目里运行：

npx skills add https://runta.com/docs --skill runta-installer runta-cli
npx skills add frontier-harness-eval/eval --skill frontierharness-eval

runta-installer 负责 Runta 工具链的安装与验证；runta-cli 提供运行时操作指引。frontierharness-eval 驱动基准测试、打分和报告。如果 Runta 技能已经装好，只需运行第二条命令。

提示选择时，两条命令选同一个智能体，也可以直接指定：

npx skills add https://runta.com/docs --skill runta-installer runta-cli --agent codex -y
npx skills add frontier-harness-eval/eval --skill frontierharness-eval --agent codex -y

两条命令都加上 --global，技能就能跨项目使用。在项目里开一个新的智能体会话，然后问：

Use the frontierharness-eval skill to evaluate https://github.com/acme/my-harness.
Start with one Terminal-Bench task and one DeepSWE task.

技能会为任务定义和基线结果拉取一份基准测试检出，用 Runta 技能完成工具链安装，然后检查前置条件并引导评测。只装技能不会运行评测。如果你想要一份写明 harness、commit、服务商和构建设置的提示词，见 PROMPT.md。

已经克隆了这个仓库？在仓库根目录安装本地副本：

npx skills add . --skill frontierharness-eval

改为手动运行

技能里的脚本和智能体调用的是同一批，所以完全不用智能体也能跑。所有路径都相对于工作区根目录，而这个仓库有自己的 scripts/ 目录，所以要用变量来指向技能里的脚本：

FH=skills/frontierharness-eval/scripts

1. 前置条件。 runta 命令行（brew install runta-dev/tap/runta 或 npm i -g @runta/runta-cli）已用 runta login 完成认证，另外还需要 jq、node >= 18，以及 Python >= 3.9 用于 token 成本核算。
2. 安装脚本。 写一个脚本，在干净的 Linux 机器上构建你的 harness。如果它不是 Harbor 或 Pier 的内置智能体，就在那边的两个 runner 注册表里把它注册为自定义智能体，并用注册后的名字作为 --harness。如果服务跑在运行时主机或外部主机上，配置时把 --harness-topology 设为 runtime-service 或 external-service，并记录它的资源限制和状态重置方式。

3. 服务商密钥。 把它存成一条 Runta secret，只存一次，名字用你服务商对应的环境变量（FIREWORKS_API_KEY、MOONSHOT_API_KEY、OPENROUTER_API_KEY 或 TOGETHER_API_KEY）。交互式提示不会把值写进 shell 历史：

runta secret set FIREWORKS_API_KEY --prompt

API 永远不会把值交回来，所以配置时会复用已存的 secret，而不是再问你要一次明文。如果你已经把密钥放在环境里，用 --value-env 或 --value-stdin 也行。

4. 黄金检查点。 一条命令就能创建干净的运行时、在固定 commit 上克隆 harness、安装 Harbor 和 Pier 栈，并冻结一个小检查点。trial runner 会在每次恢复之后拉取各个任务镜像：

$FH/provision-golden-checkpoint.sh \
--runtime fh-build --checkpoint fh-golden-myharness-v1 \
--harness my-harness --provider fireworks \
--repo https://github.com/acme/my-harness --commit 9f2c1ab \
--cpus 4 --memory 8192 --disk-size-gib 50 --keep-runtime \
--install-script ./install-my-harness.sh

真正的密钥留在 egress proxy 里，所以要确认运行时看到的始终只是 stub：

runta exec fh-build -- sh -lc 'test "$FIREWORKS_API_KEY" = runta-secret-stub'

这个例子保留了构建运行时，方便检查。确认检查点就绪后，用 runta rm fh-build 删掉那个构建运行时。

5. Trials。 每个任务都会拿到自己全新的恢复环境，等完整证据归档在本地校验通过后删除。不加 --tasks 时，会运行从 tasks/ 读取的已发布 30 任务集：

$FH/run-trials.sh \
--checkpoint fh-golden-myharness-v1 --harness my-harness \
--provider fireworks --run-id 2026-09-02-myharness --out runs

给 --tasks 传一个带 suite 前缀的 id 文件，就能只跑一个子集——值得先用一个 Terminal-Bench 任务和一个 DeepSWE 任务跑一遍，在花掉全部预算之前先验证链路通不通。重跑同一个 --run-id 会接着收集未完成的证据、重试基础设施搭建失败，并保留每一次有效尝试。执行断连和拷贝不完整都会保留运行时，方便恢复。要做一次有意为之的新实验，就用新的 run id。如果某个 trial 两次都死在基础设施上，把它标记出来，而不是当成失败计分：

trial=runs/2026-09-02-myharness/trials/terminal-bench-<task>/trial.json
jq '.status = "infra_invalid" | .success = false' "$trial" > "$trial.tmp" && mv "$trial.tmp" "$trial"
6. 评分、生成图表、输出报告。

node $FH/normalize-results.mjs --run runs/2026-09-02-myharness --label "My Harness"
node $FH/generate-chart.mjs --run runs/2026-09-02-myharness
node $FH/build-report.mjs --run runs/2026-09-02-myharness

每一步的推理过程、运行器模板和故障排查，见 SKILL.md 和 reference.md。

让结果保持可比

只有一次运行满足下面这些不变量，它的分数才有资格和已公布的数字并列。报告会说明哪些不变量被放宽了。

- Kimi K3，每个已公布的配置都用的同一个模型，否则 harness 效应和模型效应就分不开。跑通过率，任何服务商提供它都行；算成本，要确认它的 token 价格和 reference.md 里的一致。
- 一个 golden checkpoint，每个任务一次全新恢复，每次恢复的 vCPU、内存、磁盘都完全相同。
- checkpoint 冻结之前不执行任何正式任务。 预拉镜像属于环境准备；提前跑任务就是热缓存偏差。provisioning 脚本只会在 terminal-bench-sample 上预热。
- 基础设施故障标记为 infra_invalid，不算作任务失败。

成本用 effective_cost_per_pass 比较，它是所有任务的总成本除以通过数，可以从每个任务的原始成本复现。results/eval-data.json 里的 *_normalized 字段会用非公开数据重新计算首轮缓存读取，所以评分脚本把它们留空，而不是编造数值。

指标定义和 trial 记录约定见 SKILL.md。运行器模板、另一种 Harbor-with-Runta-provider 拓扑，以及故障排查，见 reference.md。

方法

测试的 harness 配置

| 配置 | 版本 | 配置 | 版本 |
| Codex | 0.148.0 | DSH Creator | 0.1.0-rc.8 |
| Claude Code | 2.1.237 | DSH Minimal | 0.1.0-rc.8 |
| Pi | 0.84.2 | DSH PTC | 0.1.0-rc.8 |
| DSH Standard | 0.1.0-rc.8 | Oh My Pi | 17.4.0 |
| Kimi Code | 0.37.2 | Exo Harness | 0.1.0 |
| OpenCode | 1.18.19 | Hermes | 0.20.4 |

- FrontierHarness v1.0 聚焦软件工程场景和终端任务，未必能推广到其他知识工作领域。
- 在 Runta 智能体运行时上评测。每个任务，所有 harness 和 task.toml 里定义的环境都预先准备成一个 golden checkpoint。每次运行都是一次全新恢复，vCPU、内存、磁盘大小、磁盘内容和内存状态完全一致。
- Kimi K3 由 Fireworks 提供。

基准范围

- 30 个任务： 21 个 Terminal-Bench 任务和 9 个 DeepSWE 任务
- 9 个 harness： Claude Code、Codex、DeepSeek Harness、Exo Harness、Hermes、Kimi Code、Oh My Pi、OpenCode 和 Pi
- 12 种配置： 每个任务与 harness 配置组合都有一份规范结果
- 360 次评估： 任务与 harness 全覆盖
- 确定性评分： 由 verifier 判定通过或失败
- 成本可比较： 首轮 cache 读取在所有 harness 之间按统一口径重新计价

公开的 benchmark 定义见 benchmark.json，完整的归一化结果集见 results/eval-data.json。

使用数据

jq '.harnesses[] | {name, successful, effective_cost_per_pass}' results/eval-data.json

每个任务目录都包含 benchmark 使用的公开指令原文和任务元数据。

赞助商

Runta 提供了隔离运行时和 Golden Checkpoint 恢复能力，全部 360 次评估都用到。