编码智能体横评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              # 公开基准定义
├── cli/index.mjs               # npx @frontierharness/eval：工作区 + 技能安装器
├── metadata/
│   ├── difficulty.json         # 难度分配及来源方法论
│   └── harness-versions.json   # 本次运行使用的 Harness 版本
├── results/
│   └── eval-data.json          # 规范化聚合结果和任务级结果
├── tasks//
│   ├── instruction.md          # 向每个 harness 展示的提示词
│   └── task.toml               # 公开任务元数据和环境定义
└── skills/frontierharness-eval/  # 与 agent 无关的技能，可手动使用
├── SKILL.md                # 针对第三方 harness 的评估工作流
├── PROMPT.md               # 可复制粘贴的提示词，引导 agent 使用该技能
├── reference.md            # 命令参考、运行器模板、故障排查
└── scripts/                # 配置、试验运行器、评分、图表、报告

本仓库有意包含结果、任务定义和评估工作流。内部基础设施、凭据、运行时标识符、私有证据、解决方案和部署配置均不包含在内。

评估你自己的 harness

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

试验网络访问。 Agent 可以访问验证器所需的包注册表和源主机，包括 Ubuntu/Debian apt 镜像、PyPI、npm、PyTorch、GitHub 下载主机以及 Harbor 的任务注册表。Runta 将允许列表应用于整个运行时，包括 agent 容器；任何额外的 Harbor/Pier 隔离仍然适用。验证器在试验期间安装依赖，因此仅允许模型提供商和 uv 下载会阻止有效的验证。任务镜像在应用试验策略之前拉取。确切的主机定义在 providers.sh 中。

每个 run.json 都会记录 egress_policy，包括其模式、范围和确切的 allowed_hosts；两个套件使用相同的策略，并包含在候选数据和报告中。已发布的基线未记录其应用的允许列表，因此新运行默认 methodology_comparable: false，且不会获得排行榜排名。在声称可比性之前，请在相同的策略和环境下评估一个对照 harness。若策略发生更改或未记录，则拒绝恢复；请为新策略使用新的运行 ID，并保留先前的证据。
skills/frontierharness-eval/ 是一个与 agent 无关的技能：将任何能读取 SKILL.md 的编码 agent 指向它，它就会驱动整个运行过程——冻结黄金检查点，从完全相同的全新恢复状态运行每个任务，为试验评分，并生成报告。

如何使用该技能

让 agent 来驱动它

使用 Skills CLI（需要 Node.js 和 Git）安装评估技能及其 Runta 配套技能。
在你使用编码 agent 的项目中运行以下命令：

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 技能已经安装，则只需运行第二条命令。

在提示时，为两条命令选择同一个 agent，或者直接指定一个：

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，即可让这些技能在所有项目中可用。在项目中启动一个新的 agent 会话并询问：

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、provider 和 build 设置的提示词，请参阅 PROMPT.md。

已经克隆了此仓库？从其根目录安装本地副本：

npx skills add . --skill frontierharness-eval

改为手动运行

该技能的脚本与 agent 调用的脚本相同，因此即使没有 agent，运行也能正常工作。每个路径都相对于工作区根目录，并且此仓库有自己的 scripts/ 目录，因此请通过变量来引用该技能的脚本：

FH=skills/frontierharness-eval/scripts

1. 先决条件。 runta CLI（brew install runta-dev/tap/runta 或 npm i -g @runta/runta-cli）需使用 runta login 进行身份验证，另外还需要 jq、node >= 18，以及用于 token 成本核算的 Python >= 3.9。
2. 安装脚本。 编写一个脚本，在干净的 Linux 机器上构建你的 harness。如果它不是 Harbor 或 Pier 的内置 agent，就在那里的两个 runner registry 中将其注册为自定义 agent，并使用注册的名称作为 --harness。对于运行时主机或外部主机上的服务，在 provisioning 时设置 --harness-topology runtime-service 或 external-service，并记录其资源限制和状态重置。

3. Provider key。 将其作为 Runta secret 存储一次，以你的 provider 对应的环境变量命名（FIREWORKS_API_KEY、MOONSHOT_API_KEY、OPENROUTER_API_KEY 或 TOGETHER_API_KEY）。交互式提示会让该值不出现在你的 shell 历史记录中：

runta secret set FIREWORKS_API_KEY --prompt

API 永远不会把该值返回，因此 provisioning 会复用已存储的 secret，而不是再次要求明文。如果你已经在环境中拥有该 key，--value-env 或 --value-stdin 方式也可以。

4. Golden checkpoint。 一条命令即可创建干净的 runtime、在固定 commit 处克隆 harness、安装 Harbor 和 Pier 栈，并冻结一个小型 checkpoint。trial runner 会在每次 restore 后拉取每个任务镜像：

$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

真正的 key 留在 egress proxy 中，因此确认 runtime 只能看到 stub：

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

该示例保留 build runtime 以供检查。确认 checkpoint 就绪后，用 runta rm fh-build 删除该 build runtime。

5. Trials。 每个任务都会获得自己的全新 restore，并在完整证据归档在本地验证后被删除。在没有 --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

将一个包含 suite 前缀 id 的文件传给 --tasks 以运行子集——值得先用一个 Terminal-Bench 和一个 DeepSWE 任务来做，以在花费全部预算之前验证管道是否通畅。重新运行相同的 --run-id 会恢复待处理的证据收集、重试基础设施设置失败，并保留每一次有效尝试。断开连接的执行和不完整的副本会保留 runtime 以便恢复。对于有意进行的新实验，请使用新的 run id。如果某个 trial 两次因基础设施而失败，请将其标记，而不是将其评分为失败：

trial=runs/2026-09-02-myharness/trials/terminal-bench-/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 中的价格一致。
- 一个黄金检查点，每个任务一次全新恢复，每次恢复都使用相同的 vCPU、内存和磁盘。
- 在检查点冻结之前不执行任何正式任务。 预拉取镜像属于环境准备；提前运行任务属于热缓存偏差。配置脚本仅在 terminal-bench-sample 上进行预热。
- 基础设施故障标记为 infra_invalid，不计为任务失败。

成本通过 effective_cost_per_pass 进行比较，该指标为所有任务的总成本除以通过数，并且可从原始每任务成本复现。results/eval-data.json 中的 *_normalized 字段使用非公开数据对首轮缓存读取重新定价，因此评分脚本将其留空，而不是编造数值。

指标定义和试验记录契约见 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 agent 运行时上进行评估。对于每个任务，所有 harness 以及 task.toml 中定义的环境都会一次性准备为黄金检查点。每次运行都是一次全新恢复，具有相同的 vCPU、内存、磁盘大小、磁盘内容和内存状态。
- Kimi K3 由 Fireworks 提供服务。

基准范围

- 30 个任务： 21 个 Terminal-Bench 任务和 9 个 DeepSWE 任务
- 9 个测试框架： Claude Code、Codex、DeepSeek Harness、Exo Harness、Hermes、Kimi Code、Oh My Pi、OpenCode 和 Pi
- 12 种配置： 每个任务与框架-配置组合对应一个规范结果
- 360 次评估： 完整的任务与框架覆盖
- 确定性评分： 基于验证器的通过/失败结果
- 可比较成本： 首轮缓存读取在各框架间采用一致的重新定价

有关公开基准定义，请参见 benchmark.json；有关完整的规范化结果集，请参见 results/eval-data.json。

使用数据

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

每个任务目录都包含基准所使用的确切公开指令和任务元数据。

赞助商

Runta 提供了全部 360 次评估所使用的隔离运行时和 Golden Checkpoint 恢复。