数据说明书

Frontier CodingHarbor 格式的代码任务数据

更新于2026年9月23日

产品定位与核心价值

Frontier Coding 交付面向前沿 Coding Agent 的可执行工程任务:由领域专家基于真实工程问题设计,按 Harbor Format 封装任务说明、固定起始环境、参考实现与可执行测试(UT),并附带指定模型的多次独立运行记录。

高价值 Coding 数据的稀缺性来自三项约束同时成立:任务贴近真实工程工作、难度足以区分前沿模型、验证器能对结果给出可复现的判定。缺任何一项,数据作为训练信号或评测资产的价值都会明显下降。

Terminal-Bench 代表的评测范式把 Agent 放进真实终端与代码库,衡量从需求理解、环境探索、工具调用到结果交付的完整链路;Harbor 提供相应的任务封装与运行框架,使不同模型在一致条件下批量运行、复现与比较。本文所称 UT 是任务完成条件的统一验收入口,按任务需要覆盖单元、集成、回归或端到端行为。

同一份数据可服务三类场景:作为独立评测集衡量 Coding Agent 能力;以筛选后的成功轨迹支持 SFT;在 RLVR / Coding RL 中由验证器提供可复现的结果奖励,并结合失败轨迹定位模型、环境或测试侧的问题。用于训练与用于评测的题目按项目隔离,降低题目泄漏与评测污染风险。

一份数据,三种用法
评测、强化学习与监督微调用到的部分不同,使用方式也不同
一条 Frontier Coding 数据
task.zip任务说明 · 环境 · 验证器 · 参考解
harbor_run_job@nn 次运行:成功 / 失败轨迹
score.jsonPassRate@n · 平均轮数
Agent 评测(Benchmark)衡量端到端能力
用到任务说明环境验证器参考模型基线
固定任务版本与配置每题独立运行 n 次PassRate@n · 平均轮数 · 成本
强化学习(RLVR / Coding RL)训练环境 + 可验证奖励
用到任务说明环境验证器on-policy 采样,同一题反复使用
同题采样 K 条验证器判 0 / 1组内比较得优势更新策略迭代
监督微调(SFT)示范轨迹训练数据
用到任务说明成功轨迹离线使用,不需要起环境
筛选通过验证的轨迹转换为目标训练格式训练样本

因此,交付的最小单元不是一道题或一次回答,而是可复现的“任务—环境—验证器—轨迹”闭环:客户可以复跑结果、核对判分、分析行为路径,并把同一套质量标准贯穿训练与评测。

交付内容与数据结构

每条数据以 Harbor 任务包为核心,配套结构化元数据、指定模型的多次独立运行记录、通过率与平均轮数。

2.1 交付资产

标准交付包含以下四类资产,模型、运行次数与统计口径按项目约定配置。

delivery/
├── manifest.json
│   # 任务 ID、编程语言、任务类型、应用领域与摘要
├── task.zip
│   # Harbor 任务包
├── harbor_run_job@n-[model].zip
│   # 指定模型的 n 次完整运行记录与轨迹
└── score.json
    # PassRate@n([model])、[model]平均轮数
交付资产用途
结构化元数据任务 ID、标题、摘要、编程语言、任务类型与应用领域,用于定位任务并快速理解工程问题,可按需检索和配比。
Harbor 任务包任务说明、固定起始环境、参考实现和可执行测试,用于复现任务并独立验收。
模型运行记录指定模型的 n 次独立 trial,包含配置、完整轨迹、原始日志和验证器输出。
实测统计PassRate@n 与平均轮数,用于衡量任务难度、比较模型表现并估算交互开销。

2.2 分类体系

数据按编程语言、任务类型和应用领域三类维度标注,便于按能力切片选题、配比和评测。具体标签可随客户技术栈与训练目标扩展。

维度定义示例
编程语言任务主要涉及的语言与运行时Python、Java、Go、C / C++、JavaScript / TypeScript 等
任务类型Agent 需要完成的工程动作Bug Fix、新功能开发、CI 修复、安全修复、测试开发等
应用领域任务所属的工程场景客户端、后端基础设施、AI / 机器学习、数据库、网络与安全等

2.3 Harbor 任务包结构

每道任务以 ZIP 形式交付,标准目录如下;可选文件根据任务复杂度配置。

[task_id]/
├── instruction.md              # 面向 Agent 的任务说明
├── task.toml                   # Harbor 元数据和运行限制
├── environment/
│   ├── Dockerfile 或 docker-compose.yaml
│   ├── setup.sh / resources/   # 可选的初始化脚本和素材
│   └── ...                     # 代码、依赖和环境配置
├── solution/
│   ├── solve.sh                # 参考解法,必需
│   └── solution.py             # 可选的辅助脚本
└── tests/
    ├── test.sh                 # 验收入口,必需
    └── test_outputs.py         # 可选的结果校验
内容主要内容用途与交付范围
任务说明instruction.md;问题、输入、目标、输出与必要约束给 Agent 的任务输入
配置与环境task.toml、environment/、代码基线、依赖与初始化资源复现任务起点及运行条件
参考解(Oracle)solution/solve.sh 及必要辅助文件验证任务可解,与解题输入隔离
UT 与验证入口tests/test.sh、测试代码及测试数据执行断言与行为检查,输出 0/1 结果

2.4 Trial 与轨迹记录

每个模型的运行结果打包为 harbor_run_job@n-[model].zip。Harbor 将一次独立运行称为一个 trial;n 次运行分别保留完整配置、Agent 轨迹、原始日志、验证器输出和最终结果,可逐次复查并区分模型失败、环境异常与验证器问题。

harbor_run_job@n-[model]/
├── attempt-1/
│   └── [trial_name]/               # 任务名前缀 + 随机后缀,如 emaj_reincarnated_relation_rollb__pjrTxhm
│       ├── config.json             # 运行配置:任务路径、Agent、模型、max_turns、环境与验证器设置
│       ├── lock.json               # 锁定的任务版本摘要(sha256)与 Agent / 环境配置,用于复现
│       ├── result.json             # 结果汇总:reward、token 用量与费用、各阶段起止时间、异常信息
│       ├── trial.log               # Harbor 执行日志:Agent 安装与启动命令(含完整任务指令)
│       ├── agent/
│       │   ├── trajectory.json     # 结构化轨迹(ATIF 格式)
│       │   ├── claude-code.txt     # Agent 原始流式输出(stream-json)
│       │   └── sessions/           # Agent 会话原始记录(jsonl)及运行中生成的文件
│       ├── artifacts/
│       │   └── manifest.json       # 运行结束后收集的产物清单
│       └── verifier/
│           ├── reward.txt          # 最终判分:1.0 通过,0.0 未通过
│           └── test-stdout.txt     # UT 完整输出,含失败用例与断言信息
├── attempt-2/
│   └── ...
└── attempt-n/
    └── ...
内容文件主要内容与用途
运行配置config.json、lock.json任务路径与版本摘要、Agent 及版本、模型、max_turns、超时与环境设置;用于复现同一次运行
运行结果result.jsonreward、token 用量与费用、环境准备 / Agent 执行 / 验证各阶段起止时间;exception_info 记录超时、环境故障等运行异常,便于区分模型失败与运行故障
Agent 轨迹agent/trajectory.json逐步记录任务指令、模型响应、推理内容、工具调用与环境返回;用于成功轨迹筛选、RLVR rollout 分析、失败诊断与轮数统计等
原始日志agent/claude-code.txt、agent/sessions/、trial.logAgent 原始流式输出与会话记录,以及 Harbor 执行日志;用于逐条核对轨迹
验证结果verifier/reward.txt、verifier/test-stdout.txt最终 0/1 判分与 UT 完整输出,未通过时包含失败用例和断言信息
运行产物artifacts/manifest.json运行结束后从环境中收集的产物清单

trajectory.json 是轨迹主体,采用 ATIF(Agent Trajectory Interchange Format)逐步记录任务指令、模型响应、推理内容、工具调用、环境返回与 token 消耗。成功轨迹经筛选后可用于 SFT,失败轨迹用于失败归因与能力诊断;用于 RLVR 时,训练所需的轨迹由待训练模型在同一环境中在线采样,交付的轨迹作为基线与对照。

{
  "schema_version": "ATIF-v1.7",
  "session_id": "...",
  "agent": { "name": "claude-code", "version": "2.1.266", "model_name": "anthropic/claude-opus-5" },
  "steps": [
    { "step_id": 1, "source": "user", "message": "任务指令" },
    { "step_id": 2, "source": "agent",
      "message": "模型回复", "reasoning_content": "推理内容",
      "tool_calls": [ { "function_name": "Bash", "arguments": { "command": "..." } } ],
      "observation": { "results": [ { "content": "工具返回结果" } ] },
      "metrics": { "prompt_tokens": 0, "completion_tokens": 0, "cached_tokens": 0 } },
    ...
  ],
  "final_metrics": { "total_prompt_tokens": 0, "total_completion_tokens": 0, "total_cost_usd": 0, "total_steps": 0 }
}

专家供给与储备

3.1 专业覆盖

专家池覆盖前端、后端、全栈、测试、数据库、云原生与 SRE / DevOps,并延伸至 RAG、Agent、多模态、模型微调与推理优化等 AI 方向。任务按技术栈、系统层级与应用领域匹配专家,确保出题人具备该领域的实际工程经验;小众语言或细分方向可按项目补充专项供给。

学历分布

本科,57.14%硕士,40.00%博士,2.86%

学历状态

毕业,85.71%在读,14.29%

学校类型分布

其他院校,37.14%985 院校,37.14%211 院校,17.14%C9 院校,8.57%

工作年限分布

0–1 年,17.14%3–5 年,40.00%5–10 年,22.86%10 年以上,14.29%有实习,5.71%

技术栈覆盖

候选人可多选,各项相加可以超过 100。

公司类型分布

私企,31.58%教育 / 科研机构,18.42%头部互联网企业,15.79%央企 / 国企,15.79%高校 / 研究所,7.89%中部互联网企业,2.63%独立开发者,2.63%大型科技企业,2.63%工作室 / 独立团队,2.63%
  • 私企31.58%
  • 教育 / 科研机构18.42%
  • 头部互联网企业15.79%
  • 央企 / 国企15.79%
  • 高校 / 研究所7.89%
  • 中部互联网企业2.63%
  • 独立开发者2.63%
  • 大型科技企业2.63%
  • 工作室 / 独立团队2.63%

3.2 按需招募

针对不同项目,我们通常先将目标能力拆解为语言与运行时、框架与工具链、工程领域、任务类型和难度要求等,再据此建立专家画像并定向招募。对稀缺技术栈或新增领域,先通过小批量校准验证专家能力和生产标准,达到要求后再扩大供给,降低新方向冷启动带来的质量波动。

3.3 持续管理

专家准入依次经过背景匹配、技术面试和模拟任务测评,重点判断其能否把真实工程问题转化为可运行、可验证且具有有效难度的 Harbor 任务包,而非仅凭履历判断。模拟任务按项目定制,覆盖题面设计、环境封装、参考实现和可执行测试,专家在完成过程中同步掌握交付标准。

进入生产后,每个题包都经过自动审查与人工复核,题目生产与质量审核由不同角色承担,作者不参与自己题目的验收。审核结论与典型问题持续回流到生产规范和示例中,减少专家之间的理解偏差。

我们按提交通过率、返修次数、审核问题分布和交付稳定性维护专家表现指标,并据此调整任务分配与专家等级。生产过程保持人工在环,出现质量波动或标准变化时可即时反馈、重新校准并调整供给。

数据生产与质量控制

4.1 生产流程

生产流程从专家提交 Harbor 任务包开始,依次经过自动审查、人工复核和多模型实测。未通过的任务在限定次数内返修;达到返修上限仍不满足标准则拒收。人工复核通过后冻结题包版本,再运行目标模型并生成 PassRate@n、平均轮数和完整 trial 记录,保证统计结果与交付版本一一对应。

生产流程:从专家提交到交付
每一关都可回退返修,达到返修上限则拒收;通过复核后冻结版本再跑分
01专家提交题包

任务说明 · 固定起始环境 · 参考实现 · 可执行测试

02自动审查

Oracle / Nop 校验、相似度与污染检查、题包质量 Checker、失败归因,逐项输出结论与证据

03人工复核

同领域专家复核题包与自动审查证据,校正误报与漏报;通过后冻结题包版本

04多模型 PassRate 实测

在冻结版本上按固定配置多次独立运行,产出 PassRate@n、平均轮数与完整 trial 记录

入库与交付

统计结果与交付版本一一对应

未通过 → 返修

限定次数内修订后重新提交

达到返修上限 → 拒收

不进入交付批次

4.2 质量控制

4.2.1 自动审查

自动审查先确认题包可运行,再从可解性、污染风险、验证质量与失败归因四个方面生成结论与证据,供人工复核。

自动审查:四道关卡分别拦截什么
题包提交后逐关检查,每关输出结论、理由与证据,交人工复核
  1. 01Oracle / Nop 校验

    在干净环境中分别运行参考实现与空操作,Oracle 须通过,Nop 须失败。

    产出:两次运行的日志与 reward,作为任务可解性的证据。

    拦截不可解与初始即通过
  2. 02相似度与污染检查

    与公开 Benchmark、GitHub Issue / PR 及内部题库比对,识别复用与重复提交。

    产出:候选来源与重叠片段,作为任务私有性的证据。

    拦截公开可得与重复提交
  3. 03题包质量审查

    从三个维度逐项检查,每项给出结论、理由与证据。

    可验证性 5 项难度 3 项合理性 3 项具体检查项见下表

    拦截不可验、无难度、不合理
  4. 04失败归因

    结合模型轨迹、最终产物与失败断言,判断失败来自模型能力、环境异常还是测试过严 / 过松。

    产出:每次失败的归因结论与对应证据。

    拦截非模型能力原因导致的失败

四关的结论、理由与证据一并提交人工复核(4.2.2)。自动审查不单独决定收录,误报与漏报由审核员校正。

相似度与污染检查是任务私有性的证据环节。公开可得的题目可能已被模型提前接触,无论用于训练还是评测,价值都有限。通过专家自建任务,并同时比对内部题库与公开仓库的重叠,可支撑对任务原创性、模板化与污染风险的判断。

题包质量审查覆盖以下核心维度:

质量维度具体Checker核心判断
可验证性binary_reward最终 UT reward 严格为 0 或 1,不允许主观评分。
可验证性outcome_verified判断最终产物或行为是否达标,允许不同的正确工具与实现路径。
可验证性functional_verification实际执行代码、调用接口来检查产物,避免仅靠关键词命中判分。
可验证性no_hardcoded_answer只写死样例或最终答案的不能绕过测试,验收依赖真实计算与行为。
可验证性test_instruction_alignment题面要求有测试覆盖,测试断言有明确依据,不引入未声明且无法合理推断的条件。
难度difficulty_level评估内在技术难点与所需判断,区分有价值的挑战和机械工作量。
难度no_knowledge_shortcut不能仅凭一个记忆事实、现成答案或简单搜索绕过任务核心推理。
难度agentic需要探索环境、使用工具、观察反馈并进行多步修正。
合理性task_sound场景、要求、解法与评分逻辑自洽,关键路径和标识无歧义。
合理性anti_cheat检查参考解泄漏、测试篡改、伪造 reward 等捷径。
合理性task_security检查题包、依赖和脚本中的恶意行为,如密钥外泄、无关网络外传、恶意代码与逃逸宿主机等风险。

4.2.2 人工复核

人工复核逐项复查题包、自动审查证据与专家的修订说明,重点校正误报、漏报与边界判断,并检查题面、环境、参考实现与测试是否一致。审核员通常为同领域专家。

4.2.3 多模型 PassRate 实测

正式跑分用于确认任务是否仍位于目标能力区间。高难度批次通常以评测时具有代表性的前沿模型 PassRate@n 不高于 50% 作为难度目标;具体模型、运行次数和验收阈值按项目约定,并随模型能力演进更新。

PassRate@n 统一按“通过的有效独立运行次数 / 有效独立运行总数”计算。例如,同一模型运行 5 次并通过 2 次,记为 2/5(40%)。环境故障、基础设施异常等无效运行不计入分母。

样例数据

以下样例披露任务概述、审核结论与模型实测摘要。题包质量 Checker 由 GPT-5.6-Sol 独立评审 4 次,逐项打分 1–5 分,单项得分 ≥ 3 为达标;完整题包、验证器与运行轨迹可在保密前提下提供复核。

5.1 样例 1:Failsafe 共享重试预算

任务概述:为 Java 容错库实现跨策略共享的重试预算,并保持并发与异步场景下的状态一致性。

Failsafe 共享重试预算:模型实测概览

同一题目,五个前沿模型各 5 次独立运行

Java新功能开发后端基础设施

Opus-5
PassRate@5
1/5
平均轮数
63.2
Opus-5.5
PassRate@5
4/5
平均轮数
44.6
Fable-5.1
PassRate@5
1/5
平均轮数
64.2
GPT-5.6-Sol
PassRate@5
4/5
平均轮数
57.4
GPT-6-Astra
PassRate@5
4/5
平均轮数
26

通过未通过同一题目在前沿模型间的通过率从 1/5 到 4/5,具备区分度。

PassRate@5 指 5 次独立运行中的通过次数占比;平均轮数取自轨迹步数,可用于估算交互开销。

Failsafe 共享重试预算:自动审查报告

题包质量自动化评审结果

门禁结论:通过

基础校验

Oracle 校验

通过 reward = 1

Nop 校验

通过 reward = 0

相似度与污染检查

低风险

题包质量审查11 项 Checker

评审方法:GPT-5.6-Sol 逐项打分 1–5 分,单项门禁 ≥ 3;judge 结果存在波动,故独立评审 4 次、每次全新请求,取多次结果交叉参考。

可验证性 5 项
  • binary_reward5/5/5/5
  • outcome_verified5/5/5/5
  • functional_verification5/5/5/5
  • no_hardcoded_answer5/5/5/5
  • test_instruction_alignment3/3/3/5
难度 3 项
  • difficulty_level3/3/3/3
  • no_knowledge_shortcut5/5/5/5
  • agentic5/5/5/5
合理性 3 项
  • task_sound5/5/5/5
  • anti_cheat5/5/4/5
  • task_security5/5/5/5

归因结论 轨迹显示 Agent 真实修改生产代码并运行 core 测试,未见 verifier 篡改、reward 伪造或跳过测试。环境、Agent 与 verifier 链路正常,非 infra 故障;未发现测试过松、过严、可绕过、隐藏要求或题面泄露。

5.2 样例 2:MQTTnet 订阅配额

任务概述:为 .NET MQTT Broker 新增 Session 级与全局双层订阅配额,在持久会话、实时调整和并发场景下保持计数与容量回收的一致性。

MQTTnet 订阅配额:模型实测概览

同一题目,五个前沿模型各 5 次独立运行

C#新功能开发后端基础设施

Opus-5
PassRate@5
0/5
平均轮数
118.4
Opus-5.5
PassRate@5
1/5
平均轮数
63
Fable-5.1
PassRate@5
0/5
平均轮数
81.2
GPT-5.6-Sol
PassRate@5
0/5
平均轮数
72.2
GPT-6-Astra
PassRate@5
0/5
平均轮数
34.6

通过未通过五个模型共 25 次独立运行,仅 Opus-5.5 通过 1 次,属于当前批次的高难度样本。

PassRate@5 指 5 次独立运行中的通过次数占比;平均轮数取自轨迹步数,可用于估算交互开销。

MQTTnet 订阅配额:自动审查报告

题包质量自动化评审结果

门禁结论:通过

基础校验

Oracle 校验

通过 reward = 1

Nop 校验

通过 reward = 0

相似度与污染检查

低风险

题包质量审查11 项 Checker

评审方法:GPT-5.6-Sol 逐项打分 1–5 分,单项门禁 ≥ 3;judge 结果存在波动,故独立评审 4 次、每次全新请求,取多次结果交叉参考。

可验证性 5 项
  • binary_reward5/5/5/5
  • outcome_verified5/5/5/5
  • functional_verification5/5/5/5
  • no_hardcoded_answer5/5/5/5
  • test_instruction_alignment5/5/5/5
难度 3 项
  • difficulty_level3/3/3/3
  • no_knowledge_shortcut5/5/5/5
  • agentic5/5/5/5
合理性 3 项
  • task_sound5/5/5/5
  • anti_cheat5/5/5/5
  • task_security5/5/5/5

归因结论 归因类型:模型能力失败 Agent 真实进入解题,verifier 正常构建并执行;前序检查全部通过,最终在「过期与 Server 释放需归还全局配额」一项等待计数归零超时,reward = 0。失败来自实现未满足该语义,非 infra 故障;未发现测试过松、过严或隐藏要求。

合作与定制

Frontier Coding 按客户的目标技术栈、任务类型、应用领域与难度区间定制批次,并共同约定基准模型、独立运行次数、PassRate@n 区间与交付字段。

建议从一个明确的能力切片开始做小批量试点,验证三件事:题包能否稳定复现、验证器能否准确判分、目标模型之间能否形成有效区分。试点通过后转入持续生产,按批次交付训练数据或独立评测集。

返回

更多说明书