产品定位与核心价值
Frontier Coding 交付面向前沿 Coding Agent 的可执行工程任务:由领域专家基于真实工程问题设计,按 Harbor Format 封装任务说明、固定起始环境、参考实现与可执行测试(UT),并附带指定模型的多次独立运行记录。
高价值 Coding 数据的稀缺性来自三项约束同时成立:任务贴近真实工程工作、难度足以区分前沿模型、验证器能对结果给出可复现的判定。缺任何一项,数据作为训练信号或评测资产的价值都会明显下降。
Terminal-Bench 代表的评测范式把 Agent 放进真实终端与代码库,衡量从需求理解、环境探索、工具调用到结果交付的完整链路;Harbor 提供相应的任务封装与运行框架,使不同模型在一致条件下批量运行、复现与比较。本文所称 UT 是任务完成条件的统一验收入口,按任务需要覆盖单元、集成、回归或端到端行为。
同一份数据可服务三类场景:作为独立评测集衡量 Coding Agent 能力;以筛选后的成功轨迹支持 SFT;在 RLVR / Coding RL 中由验证器提供可复现的结果奖励,并结合失败轨迹定位模型、环境或测试侧的问题。用于训练与用于评测的题目按项目隔离,降低题目泄漏与评测污染风险。
因此,交付的最小单元不是一道题或一次回答,而是可复现的“任务—环境—验证器—轨迹”闭环:客户可以复跑结果、核对判分、分析行为路径,并把同一套质量标准贯穿训练与评测。
交付内容与数据结构
每条数据以 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.json | reward、token 用量与费用、环境准备 / Agent 执行 / 验证各阶段起止时间;exception_info 记录超时、环境故障等运行异常,便于区分模型失败与运行故障 |
| Agent 轨迹 | agent/trajectory.json | 逐步记录任务指令、模型响应、推理内容、工具调用与环境返回;用于成功轨迹筛选、RLVR rollout 分析、失败诊断与轮数统计等 |
| 原始日志 | agent/claude-code.txt、agent/sessions/、trial.log | Agent 原始流式输出与会话记录,以及 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 方向。任务按技术栈、系统层级与应用领域匹配专家,确保出题人具备该领域的实际工程经验;小众语言或细分方向可按项目补充专项供给。
学历分布
学历状态
学校类型分布
工作年限分布
技术栈覆盖
候选人可多选,各项相加可以超过 100。
公司类型分布
- 私企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 记录,保证统计结果与交付版本一一对应。
任务说明 · 固定起始环境 · 参考实现 · 可执行测试
Oracle / Nop 校验、相似度与污染检查、题包质量 Checker、失败归因,逐项输出结论与证据
同领域专家复核题包与自动审查证据,校正误报与漏报;通过后冻结题包版本
在冻结版本上按固定配置多次独立运行,产出 PassRate@n、平均轮数与完整 trial 记录
统计结果与交付版本一一对应
限定次数内修订后重新提交
不进入交付批次
4.2 质量控制
4.2.1 自动审查
自动审查先确认题包可运行,再从可解性、污染风险、验证质量与失败归因四个方面生成结论与证据,供人工复核。
- 拦截不可解与初始即通过01Oracle / Nop 校验
在干净环境中分别运行参考实现与空操作,Oracle 须通过,Nop 须失败。
产出:两次运行的日志与 reward,作为任务可解性的证据。
- 拦截公开可得与重复提交02相似度与污染检查
与公开 Benchmark、GitHub Issue / PR 及内部题库比对,识别复用与重复提交。
产出:候选来源与重叠片段,作为任务私有性的证据。
- 拦截不可验、无难度、不合理03题包质量审查
从三个维度逐项检查,每项给出结论、理由与证据。
- 拦截非模型能力原因导致的失败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 次独立运行
- PassRate@5
- 1/5
- 平均轮数
- 63.2
- PassRate@5
- 4/5
- 平均轮数
- 44.6
- PassRate@5
- 1/5
- 平均轮数
- 64.2
- PassRate@5
- 4/5
- 平均轮数
- 57.4
- PassRate@5
- 4/5
- 平均轮数
- 26
通过未通过同一题目在前沿模型间的通过率从 1/5 到 4/5,具备区分度。
PassRate@5 指 5 次独立运行中的通过次数占比;平均轮数取自轨迹步数,可用于估算交互开销。
Failsafe 共享重试预算:自动审查报告
题包质量自动化评审结果
基础校验
通过 reward = 1
通过 reward = 0
低风险
评审方法:GPT-5.6-Sol 逐项打分 1–5 分,单项门禁 ≥ 3;judge 结果存在波动,故独立评审 4 次、每次全新请求,取多次结果交叉参考。
- 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
- difficulty_level3/3/3/3
- no_knowledge_shortcut5/5/5/5
- agentic5/5/5/5
- 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 次独立运行
- PassRate@5
- 0/5
- 平均轮数
- 118.4
- PassRate@5
- 1/5
- 平均轮数
- 63
- PassRate@5
- 0/5
- 平均轮数
- 81.2
- PassRate@5
- 0/5
- 平均轮数
- 72.2
- PassRate@5
- 0/5
- 平均轮数
- 34.6
通过未通过五个模型共 25 次独立运行,仅 Opus-5.5 通过 1 次,属于当前批次的高难度样本。
PassRate@5 指 5 次独立运行中的通过次数占比;平均轮数取自轨迹步数,可用于估算交互开销。
MQTTnet 订阅配额:自动审查报告
题包质量自动化评审结果
基础校验
通过 reward = 1
通过 reward = 0
低风险
评审方法:GPT-5.6-Sol 逐项打分 1–5 分,单项门禁 ≥ 3;judge 结果存在波动,故独立评审 4 次、每次全新请求,取多次结果交叉参考。
- 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
- difficulty_level3/3/3/3
- no_knowledge_shortcut5/5/5/5
- agentic5/5/5/5
- 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 区间与交付字段。
建议从一个明确的能力切片开始做小批量试点,验证三件事:题包能否稳定复现、验证器能否准确判分、目标模型之间能否形成有效区分。试点通过后转入持续生产,按批次交付训练数据或独立评测集。