Harbor 评测框架解剖

CODING AGENT 评测基础设施 · 2026

Harbor 评测框架解剖

从「跑一个 benchmark」到「可复现、可信、可比较」的评测基础设施 —— 一份由浅入深的框架研究笔记。

v0.24.0 @6099b8c 6 仓库代码快照 2026-10-25 L1 → L5 五层深度

L1 入门它是什么、为什么重要

L2 架构概念、数据流、任务包

L3 深入模型、生命周期、锁与评分

L4 对照Pier / Inspect AI

L5 方法路线图、选题、结论

问题定义

评测框架不是「跑分工具」，是评测信用的基础设施

同一句「这个模型在 Terminal-Bench 上 65 分」，背后藏着一整套必须成立的前提。框架要解决的，是让这些前提可验证。

① 可比性

同一个模型换一个 agent harness（Claude Code / Codex CLI / 自研 scaffold），分数就会变。比的是「模型 + harness + 环境」的组合，框架必须把三者都记录清楚，否则数字不可比。

② 可复现性

题目版本、容器镜像、依赖、超时、网络策略、模型参数……任一项漂移，分数就不可复现。框架要把「影响结果的输入」全部锚定，而不是只存一份配置。

③ 防作弊

agent 可能改测试、伪造日志、利用判分脚本漏洞。评分侧必须与执行侧隔离：独立环境、白名单产物、受限网络、非特权评分进程。

因此，评测框架的核心资产不是「跑得快」，而是三件事：任务包的可分发与校验、轨迹与结果的可审计、评分步骤的隔离与可重放。后面的所有内容都围绕这三点展开。

Harbor 精读 · P1/P2/P3 笔记综合02 / 26

一句话定位

Harbor：any agent × any model × any task × any sandbox

由 Terminal-Bench 团队（Laude Institute）出品的评测与优化框架；官方 Terminal-Bench harness；生态已整体迁入 harbor-framework 组织。

6.4kGitHub stars · 2.1k forks

48已注册 agent 适配器

34沙箱后端（docker / modal / daytona …）

85benchmark adapters（含 parity 实验）

156Terminal-Bench 主线任务

80Harbor Index（从 6000+ 任务蒸馏）

它不是「一个 benchmark 的 runner」，而是 rollout 引擎 + 任务格式规范 + 轨迹格式 + 评分组件 + 榜单平台的组合体。这也是它值得作为研究对象的理由。

数据快照：2026-10-25 · v0.24.003 / 26

生态地图

Harbor 位于基准与基础设施的中间层

上游 · 基准与任务

Terminal-Bench 1/2/2.1/3/Science、SWE-bench、Aider Polyglot、SWE-smith、GAIA… 通过 85 个 adapters 变成统一任务包。

中间 · Harbor

任务格式 · rollout 引擎 · ATIF 轨迹 · RewardKit 评分 · Registry / Hub 榜单 · RL rollout 生成。

下游 · 使用者

前沿实验室跑榜、企业做内部评测、训练团队生成 SFT/RL 数据（SkyRL / OpenThoughts-Agent / Prime-RL）。

左侧 · 沙箱与 agent

34 个 sandbox（docker / modal / daytona / e2b / k8s …）× 48 个 agent（Claude Code / Codex / Gemini CLI / mini-swe-agent / ACP 协议）。

右侧 · 对照物

Pier（DataCurve 的 Harbor fork，为 DeepSWE）· Inspect AI（UK AISI 跨领域评测框架）。见 L4。

为什么这一层重要

基准会过时，模型会换代，但「任务格式 + 轨迹格式 + 评分协议」是长期资产——它决定了未来所有评测能否互相比较。

来源：awesome-harbor、harbor-framework 组织仓库、awesome 列表04 / 26

概念地图

先记住这七个概念，后面都是它们的组合

Task

任务包：指令 + 环境 + 评分脚本。目录即格式。

Trial

一次尝试：一个 agent 跑一个 task 的完整生命周期。

Job

一批 trial 的组合与聚合：并发、重试、统计。

Agent

被评测的智能体程序：installed CLI 或 API 型。

Sandbox

执行环境抽象：启动、执行、上传/下载、健康检查。

Verifier

评分：跑 tests/，解析 reward（单值/多维）。

Trajectory

ATIF 轨迹：步骤、工具调用、token/成本，跨 harness 统一。

Metric

跨任务聚合：mean / sum / min / max / 自定义脚本。

这 7 个概念的代码入口都在 src/harbor/models/ 与 src/harbor/trial/：Task 是内容包，TrialConfig 是执行参数，二者同名不同义，是读代码时第一个坑。

详见 notes/01-models.md05 / 26

harbor run --dataset terminal-bench:2 --agent claude-code --n-concurrent 4 # ↑ 你告诉它「考哪些题、用谁考、同时开几个考场」 Job.create ├── JobPlan.from_config # 解析配置 → 展开任务列表 → 预下载 ├── JobLock # 写 lock.json（冻结所有输入） ├── TrialQueue(n=4) # 信号量控制并发 │ ├── Trial #1 ──┐ │ ├── Trial #2 │ 每个 = (agent × task × attempt) │ ├── Trial #3 │ 独立跑、独立写 result.json │ └── Trial #4 ──┘ └── JobStats # 汇总所有 trial → 算分、出榜

一句话：Job 是「组织考试」——拆卷、发卷、监考、收卷、算总分。它不亲自做任何评测，只负责把 Trial 串起来、管并发、最后聚合。

对应 P0 定位笔记 + P3 骨架06 / 26

数据流

整个框架只有三条数据流

① 任务包流

init → lint
→ publish（content hash）
→ registry / Hub
→ download（3 种来源）
→ Task（解析 task.toml）
→ 挂载进沙箱

核心不变量：任务内容 = content_hash。

② 轨迹流

agent native logs
→ convert_trajectory()
→ ATIF v1.8
→ trajectory.json
→ viewer / 分析 / SFT

核心不变量：跨 harness 的同一表示（覆盖 CLI 与 API 型 agent）。

③ reward 流

tests/test.sh
→ reward.txt / reward.json
→ VerifierResult.rewards
→ 多步聚合 → metrics
→ JobStats / 榜单

核心不变量：reward 是文件协议，可审计、可重放。

三条流的交点就是 TrialResult：它同时记录任务身份（task digest）、执行轨迹（ATIF）与评分结果（rewards），是「一次评测」的最小可审计单元。

P1/P2/P3 笔记交叉验证07 / 26

生命周期（单步）

一次 Trial：准备 → 执行 → 收产物 → 评分

准备

启动沙箱
healthcheck
agent setup

Agent

相位式网络策略
run(instruction)
超时/取消

日志

上传 agent logs
同步 ATIF
trajectory.json

产物

收集 artifacts
白名单 + manifest
（sidecar 可停主服务）

评分

上传 tests/
跑 test.sh
解析 reward

落盘

result.json
lock.json
job 聚合

分支 A（separate verifier）：第 4 步后先停 agent 环境，再用独立镜像起 verifier 环境，只挂载白名单产物 → 评分侧看不到 agent 文件系统。
分支 B（shared verifier）：评分直接跑在 agent 环境里，成本低，但 agent 与 grader 共享文件系统——隔离性弱。

7 个生命周期事件（START / ENVIRONMENT_START / AGENT_START / AGENT_END / VERIFICATION_START / END / CANCEL）是 Job 实时统计、UI、遥测的统一入口。

trial/single_step.py:44 · trial/hooks.py:17 · trial/trial.py:60108 / 26

任务格式

任务包：目录即格式，内容哈希即版本

my-task/ ├── instruction.md # 指令 ├── trajectory.json # 可选：预置 ATIF ├── task.toml # schema 1.4 ├── environment/ # Dockerfile / compose ├── solution/solve.sh # oracle 参考解 ├── tests/test.sh # verifier → reward └── steps/<name>/ # 多步任务 ├── instruction.md ├── tests/ solution/ └── workdir/setup.sh

# task.toml（节选） schema_version = "1.4" [task] name = "harbor/hello-world" [verifier] timeout_sec = 120.0 environment_mode = "separate" # 可选 [environment] docker_image = "ubuntu:24.04" network_mode = "no-network"

内容哈希 = 对白名单文件做排序、逐文件 sha256，再对 relpath\0hash 序列做外层 sha256。哈希覆盖「会被分发和执行的输入」，不覆盖工作区垃圾文件。

本地目录

原地使用；内容哈希在 lock 时计算

git 仓库

子目录 + 可选 commit；sparse checkout，解析出真实 commit

注册表包

org/name@ref；按 digest 寻址缓存，tar 解包

packager.py:28/88 · tasks/client.py:586 · 3 种来源：local / git / package09 / 26

组件层

Trial 调用四个可替换件：Agent × Sandbox × Verifier × ATIF

① Agent（被评测对象）

BaseAgent 接口统一 installed CLI 与 API 型两类。
48 个适配器：Claude Code / Codex / Gemini CLI / mini-swe-agent / Terminus…
接入清单：安装方式 · 凭据注入 · 会话日志 → ATIF · 退出码/超时 · 网络 allowlist。

② Sandbox（执行环境）

BaseEnvironment 抽象 5 个动作：启动 / 健康检查 / 执行命令 / 上传文件 / 下载文件。
34 个后端：docker / modal / daytona / e2b / runloop / k8s / 本地。
替换成本：实现 5 个方法即可，Trial 代码零改动。

③ Verifier（评分）

跑 tests/test.sh，解析 reward.txt / reward.json。
两种模式：shared（与 agent 同环境，便宜）vs separate（独立镜像 + 只挂白名单产物，隔离强）。
默认解析为 SHARED，需任务显式声明——这是风险点（见 L3 第 14 页）。

④ Trajectory（轨迹格式）

所有 agent 的输出统一转成 ATIF v1.8（schema_version），落盘 trajectory.json。它是 viewer、分析、SFT/RL 训练的唯一输入。
关键字段：steps[]（source / message / tool_calls / reasoning_content / metrics）· llm_call_count · subagent_trajectories · final_metrics（token / cost / duration）。

⑤ Metric（聚合函数）

跨任务聚合：mean / sum / min / max / 自定义脚本。
注意：job 聚合有 3 个坑——无 verifier 结果计 0、单 key 时输出键被改名、多 key 时缺失维度记 0。见 L3 第 13 页。

四个组件只通过抽象接口与 Trial 交互，Metric 只在 Job 聚合阶段介入——这是 Harbor「换任何 agent / 任何沙箱 / 任何评分脚本都行」的实现基础。

agents/base.py:34 · trial/environment.py · verifier/verifier.py:69 · rfcs/000110 / 26

模型分层

同名类的秘密：声明层 vs 执行层

Harbor 有两套同名模型：models/task/config.py 描述「任务是什么」，models/trial/config.py 描述「这次执行怎么跑、从哪拿任务」。

同名类	声明层（task.toml 内容）	执行层（运行时参数）
TaskConfig	schema 1.4：task / verifier / agent / environment / steps / artifacts	任务来源指针：path / git_url / name / ref / download_dir
AgentConfig	timeout、user、相位级网络策略	name、model、kwargs、env、skills、load_trajectory
EnvironmentConfig	镜像、OS、资源、网络、healthcheck	type、import_path、force_build、override_cpu/mem…
VerifierConfig	timeout、env、environment_mode、collect	override_timeout、max_timeout、include_logs、disable

命名债实锤：job/lock.py:19 必须写 from harbor.models.task.config import TaskConfig as TaskDefinitionConfig 才能区分两者。读代码第一步永远是看 import 来源，不是看类名。

notes/01-models.md · task/config.py:853 · trial/config.py:39810 / 26

组合与展开

五步转换链：配置如何变成一次执行

JobConfigdatasets / tasks /
agents / metrics

→

JobPlan展开任务 + 下载
+ 解析 metrics

→

TrialConfig ×Nattempts × tasks
× agents

→

Trial.createTask 解析
task.toml

→

TrialResultreward + 轨迹
+ timings

步	位置	做什么	关键产物
1	job_plan.py:35 from_config	解析 skills → 展开任务 → 解析 metrics → 预下载任务	JobPlan
2	job_plan.py:115 resolve_task_configs	tasks + datasets 展开成「任务来源指针」列表	list[TaskConfig(exec)]
3	tasks/client.py:586 download_tasks	local/git/package 三类来源统一下载与缓存	path + content_hash
4	job_plan.py:140 build_trial_configs	三重笛卡尔积；继承 env/verifier/timeouts	list[TrialConfig]
5	trial/trial.py:469/532	下载任务 → Task(task_dir) → 分派单步/多步/regrade	Trial 实例

关键洞见：TrialConfig 不携带任务内容，只带「任务指针」；内容的唯一身份是 TaskLock.digest（内容哈希）。这样 resume/regrade 不用解析任务就能判断「是不是同一个任务」。

notes/01-models.md §311 / 26

可复现性

lock.json：不是配置副本，是可复现性合同

JobLock # schema 3 ├── harbor: version / git commit / editable ├── n_concurrent_trials, retry └── trials[] : TrialLock # schema 2 ├── task: TaskLock │ └── digest = sha256(内容) ← 内容锚点 ├── agent / user_agent（冻结的完整配置） ├── skills[] + git 元数据（digest） ├── extra_instructions / persona / prompt（sha256） ├── extra_docker_compose（sha256） ├── verifier + resolved environment_mode └── source_trial（regrade 溯源）

它解决什么

同一个 job 目录不允许换配置重跑：写出 lock 前比较已有 lock，不一致直接 FileExistsError（job.py:957），防止结果被污染。

equality 即语义

TaskLock 只比 digest；TrialLock 逐项冻结；JobLock 的 trials 用无序比较——顺序不影响语义。

为什么 760 行

每个影响重放的输入都要：稳定摘要 + 比较规则 + 可读序列化；再加 ~100 行 Harbor 安装来源探测（direct_url.json / git rev-parse）。

models/job/lock.py:66/175/266 · job.py:957 · trial/trial.py:120312 / 26

评分信号

reward 是文件协议：单值、多维、多步、聚合

test.sh写文件

→

reward.txt{"reward": v}

reward.jsondict[str, 数值]

→

VerifierResultrewards + 异常

→

metricsmean/sum/min/max

→

JobStats+ pass@k

多步：mean / final

multi_step_reward_strategy：mean 按 key 跨步均值（缺失 key 记 0、无 verifier 的 step 不进分母）；final 取最后一步。

job 聚合三个坑

① 无 verifier 结果 → 计 0；② 单 key 时输出键被改名成 metric 名（如 mean）；③ 多 key 时缺失维度记 0。

为什么值得研究

聚合口径直接决定结论：同一批 trial，换 metric 语义就能改变排名。评测论文必须报告口径。

三个协议层事实：① reward 必须是有限数值（NaN/Infinity 直接抛错）；② 多维 reward 让「部分正确」可表达；③ 评分脚本与 agent 使用同一套文件系统时，reward 文件本身就是攻击面。

报告口径 · verifier mode 报告口径 · 重试策略报告口径 · 聚合函数报告口径 · reward 维度报告口径 · 失败样本处理

verifier/verifier.py:69/91 · metrics/base.py:14 · job_plan.py:35513 / 26

研究钩子

三个可能污染分数的机制（代码级证据）

① grade=False 仍进分母

error_policy.py:33 把 sandbox/provider 失败标成 grade=False，但 reward_valid 只在 TrialResult 上定义，聚合路径没有引用它——基础设施失败可能以 0 分计入平均。

影响：平均分被系统性拉低，且失败与模型能力无关。

② 重试只留最后一次

trial/queue.py:222 重试前删除 trial 目录，最终只保留成功/最后一次尝试。中间失败样本与轨迹不可见，误差分析会失真。

影响：样本分布被重采样，方差被低估。

③ 评分侧可见性差异

shared verifier 与 agent 共享文件系统；separate 模式才是隔离设计。但默认解析逻辑是 SHARED（verifier_mode.py:29），需要任务显式声明——默认值即风险。

影响：默认配置下攻击面更大，报告须披露 mode。

这三条都不是「bug」，而是评测工程里必须明示的口径问题。把它们写进报告，比刷高 1 分更有价值。→ 对应研究选题 A/B。

notes/01-models.md §4/§5 · 待 P6 验证14 / 26

错误分类

8 类失败 × retry / grade 的单一事实源

FailureCause	retry	grade	reward_valid	典型异常
SANDBOX_FAILED	✅	❌	❌	EnvironmentStartTimeout、Healthcheck、BuildFailed
MODEL_PROVIDER_FAILED	部分	✅/❌	❌	ApiRateLimit、Authentication、Timeout
HARBOR_FAILED	❌	❌	❌	ServiceOperationsUnsupported、RegradeError
UNCLASSIFIED	✅	✅	❌	NonZeroAgentExitCodeError
AGENT_EXHAUSTED_BUDGET	❌	✅	✅	AgentTimeout、ContextWindowExceeded
AGENT_REFUSED_TASK	❌	✅	✅	AgentSafetyRefusal、ContentPolicyViolation
VERIFIER_FAILED	❌	✅	❌	VerifierTimeout、RewardFileNotFound
CANCELLED	❌	❌	❌	CancelledError

这张表的设计意图（文件 docstring）：retry / verification / job aggregation / leaderboard 共用同一分类。但如上页所述，聚合端还没完全接入 reward_valid——「单一事实源」有了，消费端还没接全，这正是可研究/可贡献的点。

models/trial/error_policy.py:14/33/5015 / 26

评分安全

评分隔离：四层防线与剩余攻击面

① 环境隔离

separate verifier：独立镜像 + 只挂白名单 artifacts（manifest 化）；shared 模式则共用文件系统。

② 网络隔离

四相位策略：agent 基线 / agent 相位 / verifier 基线 / verifier 相位；受限策略自动放行推理端点 host。

③ 产物白名单

只收集 task.toml 声明的 artifacts；regrade 依据 manifest 判断「可重评性」。

④ 评分进程权限

RewardKit worker：在 verifier 容器内以非特权用户跑提交代码，不能改 grader、读 tests、写 reward。

攻击面清单 ① agent 改 tests/ 或 /logs ② 伪造 reward 文件 ③ 评分脚本漏洞（注入/路径穿越） ④ 借助共享挂载读取 grader ⑤ 用网络外泄/拉取答案 ⑥ 通过日志/artifact 植入指令 ⑦ 奖励函数本身可被「拟合」

隔离是概率性的：每加一层都降低风险，但没有「绝对安全」。评测报告应披露用了哪几层。

trial/network_policy.py:116 · artifact_handler.py:48 · rfcs/000316 / 26

被测对象

Agent 适配层：installed CLI vs API 型

installed（沙箱内 CLI）

在沙箱里安装并运行 Claude Code / Codex / Gemini CLI 等；需要解决安装、凭据注入、会话日志抓取、退出码语义、网络策略。
难点：air-gapped 任务中「安装要网、推理也要网」。

48 个适配器里大多数是 installed 型；Pier 的独有改动（构建期安装 + 推理代理）也集中在这一层。

API 型（沙箱外/内 SDK）

由 Harbor 直接驱动模型 + 工具循环（如 Terminus、computer-use）；能力声明更细，但少了「真实 CLI 的复杂度」。

适合做细粒度能力对比（token/步数可控、实验便宜），但离真实用户工作流更远——这也是「换 harness 分数就变」的根源之一。

统一接口

setup() + run(instruction, environment, context) + capabilities（resume / atif / reasoning_effort…）。

48 个适配器

Claude Code、Codex、Gemini CLI、OpenCode、mini-swe-agent、OpenHands、Cursor CLI… + ACP 协议统一接入。

研究含义

同一模型换 harness → 分数差异巨大。ATIF 是唯一能对齐差异的表示；这也是 Pier 等 fork 的主攻方向。

接入新 agent 的最小 checklist：安装方式、凭据/base URL 注入、会话日志与 ATIF 转换、退出码/超时语义、网络 allowlist 需求。P4 将逐条对到 claude_code.py 的实现。

agents/base.py:34 · installed/base.py · agents/agent_auth_resolution.py17 / 26

轨迹

ATIF：跨 harness 的轨迹交换格式

Trajectory ├── schema_version: ATIF-v1.8 ├── session_id / trajectory_id ├── agent: { name, version, model } ├── steps[]: # 从 1 连续编号 │ ├── source: system|user|agent │ ├── message / reasoning_content │ ├── tool_calls[] / observation │ ├── metrics: tokens/cost/… │ ├── llm_call_count # v1.7 │ └── is_copied_context # v1.5 ├── final_metrics └── subagent_trajectories[] # v1.7

为什么重要

没有它，每个 viewer/训练管线都要写 agent 专用解析器；有它，轨迹可比较、可回放、可训练。

v1.7 → v1.8 的细节

代码已接受 ATIF-v1.8（新增音频内容），但文档仍写「current format is ATIF-v1.7」——文档滞后于代码，是引用时最容易错的点。

研究价值

「同一模型、同任务、不同 harness」的 token/步数/工具调用模式差异，只有 ATIF 级对齐才能归因。→ 选题 B。

rfcs/0001 · models/trajectories/* · trial/sync_trajectory.py18 / 26

工程现实

读 Harbor 源码的四个陷阱

① 文档漂移

AGENTS.md 里写的 orchestrators/、inspect/、dataset/ 实际不存在；ATIF 文档版本也落后于代码。以代码为准。

② 双实现并存

Job.create 与 JobPlan.from_config 两条创建路径；_resolve_metrics 在 job.py 与 job_plan.py 各一份——先确认实际生效路径。

③ 同名类

TaskConfig / AgentConfig / EnvironmentConfig / VerifierConfig 各有声明层与执行层两个定义；看 import，不看名字。

④ 高频 breaking change

CHANGELOG 的 Unreleased 段就有 10+ 条 breaking（agent auth、网络策略、verifier 默认模式、skills 目录）。笔记必须带 commit。

这四个陷阱本身也是「研究素材」：它们揭示了一个高速演进的评测框架在接口稳定性上的真实成本——这正是对工业界有参考价值的部分。

notes/00-orientation.md §4 · notes/01-models.md §619 / 26

横向对照 1/2

Pier：4 个卖点里，只有 1 个真正独有

Pier 宣称的差异	分类	证据
critique run（新沙箱里让新 agent 审查已完成 trial）	STILL UNIQUE	Harbor 全仓 0 命中；Pier 1,592 LOC + 唯一文档页
air-gapped 下的 installed agent（构建期安装 + 推理代理）	PARTIALLY	机制独有（squid egress proxy），但 Harbor 用相位式网络策略解决同一场景，且 allowlist 更丰富；Pier 反而拒收 Harbor allowlist 任务
augmented ATIF v1.7（每 API turn 一步、peak_context_tokens 等）	PARTIALLY	ATIF 模型是 Harbor 逐行 copy（Harbor 已 v1.8）；只有 2 个指标仍独有（peak_context_tokens / summarization_count）
chat 式 viewer	PARTIALLY	实为「task-definition chat」，README 描述夸大

规模差

Pier 4.6 MB / 28k LOC vs Harbor 145 MB / 173k LOC；依赖 harbor>=0.5.0（落后上游 ~19 个 minor）。

兼容性硬伤

拒收 Harbor 1.3/1.4 任务字段与 allowlist 模式；跨 fork 比较分数前必须重测任务集。

读法结论

读 1 天，不是 1 周：只读 critique、安装/代理、两个 ATIF 指标、task chat 四处。

notes/pier-diff-map.md（159 行，逐路径核对）20 / 26

横向对照 2/2

Inspect AI：协议 + 注册表的方法论价值

Harbor 可借鉴的 5 条

① Solver/Agent/Scorer/Tool/Sandbox 全是 Protocol + 注册表，第三方可注册；② Scorer 与 Metric 分离，自带 stderr / ci / bootstrap / pass@k；③ log 是版本化可重放产物（retry/rescore/edit）；④ agent 可组合（as_solver / as_tool / handoff）；⑤ limit 与 approval 是政策对象。

Harbor 领先的 3 处

① 34 个沙箱后端 vs Inspect 2 个内置（容器/agent 负载的决定性差距）；② 声明式任务包可分发（Inspect 任务是 Python 模块）；③ 环境内验证 + 多步部分奖励 + regrade。

结论：Harbor 是 coding agent 评测的工程底座，Inspect 是跨领域评测方法论的参照系。两者不是替代关系；研究 Harbor 时把 Inspect 当「抽象层设计对照」，收益最大。

notes/inspect-ai-map.md（213 行） · Inspect v0.3.28421 / 26

方法论

精读路线图：10 个阶段，3 种读法

P0 定位 ✅

架构/版本/环境

P1 模型 ✅

声明 vs 执行、lock

P2 任务包 ✅

格式/哈希/来源/lint

P3 生命周期 ⏳

骨架完成

P4 Agent

installed vs API

P5 ATIF

轨迹可比性

P6 评分 ★

RewardKit/攻击面

P7 编排

并发/沙箱/成本

P8 平台

registry/Hub

P9 对照

Pier/Inspect

3 种读法

速通 1 天（P0+P3 主线+P6+跑一个任务）· 主线 9 天（P0→P9）· 研究 3 周（主干 + 选题卡）。

跳过清单

85 个 adapter 只读 2 个；48 个 agent 只读 3 类；34 个沙箱只读 docker+modal；省 60% 时间。

验收标准

每阶段：能画数据流图 + 回答设计问题 + 写出「如果我来重写」三句话 + 引用路径可校验。

当前产出：ROADMAP.md（496 行）+ 4 份编号笔记 + 2 份对照地图 + 自动路径校验脚本（check_refs.py，引用可一键复核）。

ROADMAP.md §6 · notes/reading-log.md22 / 26

研究开题

三个有数据、可落地的研究选题

A · Verifier 安全与 reward hacking

问题：agent 在什么条件下能「伪造通过」？防护的边界在哪？
素材：separate verifier、RewardKit worker（RFC-0003）、harbor-index 的泄题审计。
最小实验：3 类攻击 × 现有防护，统计拦截率。

B · 轨迹客观性与 harness 归因

问题：同模型不同 harness 的分数差，有多少来自 harness 而非模型？
素材：ATIF + 48 个 agent 适配器 + Pier 的计量字段。
最小实验：同模型 2–3 个 harness 跑同一小任务集，做 token/步数/工具调用归因。

C · Benchmark 治理与污染

问题：continuous benchmark 与静态榜单如何可比？80 题蒸馏是否引入偏差？
素材：85 份 parity 实验、harbor-index 蒸馏流程、任务 content hash。
最小实验：复现 2 个 adapter 的 parity，统计分数偏移分布。

三者共同的底座：Harbor 已经把「任务 / 轨迹 / 评分」都变成可批量操作的数据——研究的边际成本从「搭基础设施」降到「设计实验」。

ROADMAP.md §9（5 张选题卡）23 / 26

结论

把 Harbor 读薄：三条主线

主线 1 · 可复现性

任务 = 内容哈希；执行 = lock.json 合同；重放 = manifest 驱动。任何「分数」都要能回答：哪个任务版本、哪个 harness、哪套配置。

证据：TaskLock.digest、lock 冲突检测、regrade 的 artifact manifest。

主线 2 · 可信度

评分侧隔离（separate verifier / 网络相位 / artifact 白名单 / 非特权 worker）+ 失败语义表。剩余风险：grade 未接入聚合、重试幸存者偏差。

证据：error_policy 的 8 类失败、RewardKit worker、shared/separate 两种模式。

主线 3 · 可比性

ATIF 把不同 harness 的轨迹对齐；48 个 agent 适配器 + 85 个 benchmark adapter 让比较规模化。可比性是评测的产品，不是副产品。

证据：ATIF v1.8、统一 Task 格式、85 份 parity 实验。

一句话：Harbor 值得深挖，因为它同时是「评测基础设施」和「RL 环境基础设施」；Pier 读 1 天，Inspect 当方法论对照。

下一步：P4/P5/P6 精读 → 选一张选题卡 → 产出 2 页 memo。

综合 P0–P3 笔记 + 两份对照地图24 / 26

附录

数据快照与继续深入的入口

仓库	版本/commit	用途
harbor	v0.24.0 @6099b8c	主体（1,593 py / 55 models / 85 adapters）
pier	0.3.1 @4d3c14d	fork 差异（critique 等）
inspect_ai	0.3.284 @641b871	跨领域方法论对照
terminal-bench	@e67a2cb	156 个真实任务
harbor-index	@5399ea1	80 题高信号 benchmark

55models 文件

7,478models 行数

2,100trial.py 行数

760lock.py 行数

工作区入口

ROADMAP.md · notes/00..03 · notes/inspect-ai-map.md · notes/pier-diff-map.md · scripts/check_refs.py

外部资源

harborframework.com/docs · github.com/harbor-framework · hub.harborframework.com · github.com/UKGovernmentBEIS/inspect_ai · tbench.ai

阅读提示

G 总览 · F 全屏 · Ctrl/Cmd+P 导出 PDF（打印样式已适配 1280×720）

Harbor 评测框架解剖 · 2026-10-25 · 由浅入深 L1→L525 / 26

→ Space PageDown	下一页
← PageUp	上一页
Home / End	首/尾页
G / Esc	总览 / 关闭
F	全屏
Ctrl/Cmd+P	导出 PDF（打印）
? / H	本帮助