研究提案
HarnessForge v2：6-Agent 代码任务数据工厂（可执行规格书）
从精选 GitHub Repo 的 release 历史中，通过 6 个 Agent 协作流水线，批量生产带完整探索轨迹的中高难度代码开发任务。本文档是可直接交给 Coding Agent 执行的完整规格书。
HarnessForge 数据生产 多Agent 代码任务 RL训练 可执行规格书
HarnessForge v2：6-Agent 代码任务数据工厂
本文档的定位：这不是研究论文，是可执行规格书。给到 OpenClaw / Claude Code / 任何 Coding Agent，它应该能直接按照本文档搭建并运行整个流水线。
与 v1 的关系：v1（HarnessForge 原始 proposal）是从”反向重建 repo 演进历史”出发的研究性设计。v2 是从”数据生产实操”出发的简化版——砍掉 PR 聚类等复杂步骤，直接利用 release tag 作为 ground truth，6 个 Agent 角色分工清晰，流水线可串行执行。
一、目标
批量生产格式为 (环境, 任务描述, test, solution) 的代码开发任务数据，用于 Coding Agent 的 RL / SFT 训练。
每条数据包含：
- Docker 环境（可复现）
- 自然语言任务描述（PM 视角，不暴露实现）
- 测试套件（可自动验证 pass/fail）
- Solution（Dev 的完整开发轨迹，含探索、失败、回退、被提示后调整方向）
- 渐进提示序列（L0-L2，用于构造 DPO 对）
- 难度标签（基于 Dev 是否需要提示才能完成）
目标规模：首批 30 个 repo → 3,000-5,000 个 verified tasks
二、总体架构
阶段 1：任务设计（离线，每个 repo 一次）
┌─────────────┐ ┌──────────────┐
│ Repo │────→│ Task │────→ task_blueprints/
│ Selector │ │ Designer │ {repo}-blueprints.yaml
└─────────────┘ └──────────────┘
阶段 2：任务执行（在线，每个 task 一次）
┌──────┐ ┌──────┐ ┌──────┐
│ PM │────→│ Dev │←───→│ Test │
└──────┘ └──────┘ └──────┘
│ ↑ │
└── hint ──────┘ │
←── 失败反馈 ───────────────┘
阶段 3：质检输出（离线，批量）
┌──────────┐
│ Reviewer │────→ verified_tasks/
└──────────┘ {task-id}.yaml三、Agent 1: Repo Selector
职责
从 GitHub 筛选适合生产任务数据的仓库。
执行步骤
# 1. 从种子列表开始（人工提供，见下方）
# 2. 对每个候选 repo 执行以下检查：筛选条件（全部必须满足）：
| 条件 | 检查方式 | 阈值 |
|---|---|---|
| 有 CI | 检查 .github/workflows/ 或 .circleci/ | 必须存在 |
| 测试覆盖 | 运行 pytest --co -q 或等价命令，统计测试数 | ≥ 50 个测试 |
| 近 6 月活跃 | git log --since="6 months ago" --oneline | wc -l | ≥ 100 commits |
| 代码规模 | cloc --json 统计核心语言行数 | 10K-500K 行 |
| 有 release tag | git tag -l "v*" | wc -l | ≥ 3 个 release |
| 依赖可锁定 | 检查 requirements.txt / package-lock.json / go.sum | 必须存在 |
| 环境可构建 | 尝试构建并运行测试 | 必须通过 |
种子列表（30 个）：
python: # 12 个
- django/django
- pallets/flask
- tiangolo/fastapi
- psf/requests
- pandas-dev/pandas
- scikit-learn/scikit-learn
- pydantic/pydantic
- celery/celery
- encode/httpx
- sqlalchemy/sqlalchemy
- pytest-dev/pytest
- python-poetry/poetry
typescript: # 10 个
- microsoft/TypeScript
- vercel/next.js
- prisma/prisma
- trpc/trpc
- vitejs/vite
- vitest-dev/vitest
- remix-run/react-router
- drizzle-team/drizzle-orm
- colinhacks/zod
- date-fns/date-fns
go: # 5 个
- gin-gonic/gin
- go-chi/chi
- stretchr/testify
- spf13/cobra
- hashicorp/terraform
rust: # 3 个
- tokio-rs/tokio
- serde-rs/serde
- clap-rs/clap输出
# repos/selected-repos.yaml
repos:
- name: "django/django"
language: "python"
releases: ["4.0", "4.1", "4.2", "5.0", "5.1"]
test_cmd: "python -m pytest tests/ -x -q --tb=short"
setup_cmd: "pip install -e ."
loc: 285000
test_count: 16842
status: "selected"
- name: "vitejs/vite"
language: "typescript"
# ...四、Agent 2: Task Designer
职责
分析每个 repo 的 release 历史，设计具体的开发任务。每个任务对应一个”从版本 A 到版本 B 的某个 feature 开发”。
执行步骤
对每个 selected repo：
1. 列出所有 release tag，按时间排序
2. 对相邻的两个 release（v_old → v_new）：
a. 读取 release notes / changelog
b. 读取两个版本之间的所有 commit 和 PR
c. 识别 3-5 个有挑战性的 feature（标准见下）
d. 对每个 feature：
- 确定 base_commit（v_old 对应的 commit）
- 确定 target_commit（feature 完成后的 commit，通常是 v_new 或中间某个 merge commit）
- 从 target_commit 的 diff 中提取涉及的文件和测试
- 设计验证方式：哪些测试在 base 上应该 FAIL，在 target 上应该 PASS
- 确定运行环境
3. 环境验证（关键！）：
a. 在 Docker 中 checkout base_commit
b. 安装依赖，确认能构建
c. 运行测试框架，确认基础环境正常
d. 如果有 target_commit，验证测试在 target 上 PASSFeature 挑选标准：
| 标准 | 说明 | 原因 |
|---|---|---|
| 涉及 ≥3 个文件 | git diff --stat 查看 | 太少的改动没有挑战 |
| 不是纯 refactor | 有新功能或行为变化 | 纯重构难以写测试 |
| 有对应测试 | diff 中包含测试文件变更 | 没测试的 feature 无法验证 |
| 不依赖外部服务 | 不需要数据库/网络等 | 沙箱环境限制 |
| 难度适中 | 预估人类开发者 0.5-3 天 | 太简单没价值，太难 Agent 做不出 |
输出
# task_blueprints/{repo}-blueprints.yaml
repo: "django/django"
language: "python"
blueprints:
- task_id: "django-async-queryset-iter"
base_commit: "abc123" # v4.2.0
base_version: "4.2.0"
target_commit: "def456" # v4.3.0 中的某个 merge commit
target_version: "4.3.0"
feature_summary: |
QuerySet 支持异步迭代器 (async for)，使得在 async view 中
可以直接 `async for obj in MyModel.objects.filter(...)` 而不
需要 sync_to_async 包裹。
files_changed:
- "django/db/models/query.py"
- "django/db/models/sql/compiler.py"
- "django/db/models/manager.py"
- "tests/async/test_queries.py"
verification:
test_files: ["tests/async/test_queries.py"]
test_cmd: "python -m pytest tests/async/test_queries.py -x -q"
base_expected: "FAIL" # 这些测试在 base 上应该失败
target_expected: "PASS" # 在 target 上应该通过
base_verified: true # 已实际验证
target_verified: true # 已实际验证
environment:
dockerfile: |
FROM python:3.11-slim
WORKDIR /workspace
COPY . .
RUN pip install -e ".[dev]"
setup_cmd: "pip install -e ."
test_cmd: "python -m pytest tests/async/test_queries.py -x -q"
ground_truth:
diff_file: "diffs/django-async-queryset-iter.patch"
commit_count: 3 # 跨 3 个 commit
additions: 245
deletions: 12
estimated_difficulty: 4 # 1-5
- task_id: "django-json-field-lookups"
# ...五、Agent 3: PM
职责
- 把 Task Designer 的技术 blueprint 重写为用户/产品经理视角的需求描述
- 准备 3 级渐进提示
- 在 Dev 执行过程中，感知 Dev 状态，在 Dev 多次失败时释放提示
PM 的需求重写规则
输入：Task Designer 的 blueprint（含技术细节）
输出：PM 视角的任务描述（隐藏实现细节）
规则：
1. 描述"做什么"（期望行为），不说"怎么做"（实现方式）
2. 不给文件路径、不给代码片段
3. 包含背景动机（为什么要做这个 feature）
4. 包含明确的验收标准（可观测的行为）
5. 可以包含合理的约束（向后兼容、性能要求等）示例转换：
技术 blueprint:
"QuerySet 支持异步迭代器，修改 query.py 和 compiler.py"
PM 重写后:
"## 背景
我们的异步 Web 视图中大量使用了 sync_to_async 包裹数据库查询，
代码冗长且容易出错。用户多次反馈希望能直接在 async 上下文中
迭代查询结果。
## 需求
让 QuerySet 支持 `async for` 语法，在异步视图中可以直接：
```python
async for article in Article.objects.filter(published=True):
...验收标准
async for obj in queryset正常工作- 支持切片、filter 等链式操作后的异步迭代
- 同步使用方式不受影响（向后兼容）
- 新增测试覆盖上述场景”
### PM 的渐进提示设计
对每个任务准备 3 级提示：
```yaml
hints:
L0: [] # hard 模式，零提示
L1: # 方向级：告诉 Dev 大致在哪个方向
- "这个功能的核心在于让数据库查询支持 Python 的异步迭代协议"
- "你需要关注 ORM 层的查询编译器如何生成和执行 SQL"
L2: # 模块级：告诉 Dev 具体涉及哪些文件和关键点
- "核心改动在 django/db/models/query.py —— QuerySet 需要实现 __aiter__ 和 __anext__"
- "compiler.py 的 execute_sql 需要支持异步数据库连接"
- "参考现有的 sync 版本 __iter__ 实现作为起点"PM 感知 Dev 状态的协议（关键设计）
PM 不是定时释放提示，而是根据 Dev 的实际状态决定是否介入。
pm_intervention_protocol:
# PM 如何感知 Dev 状态
monitoring:
# PM 在 Dev 执行过程中持续接收以下信号：
- test_results: "每次 Dev 运行测试后的 pass/fail 结果"
- edit_count: "Dev 累计修改代码的次数"
- files_touched: "Dev 修改过哪些文件"
- direction_changes: "Dev 是否推翻了之前的方案"
- explicit_help_request: "Dev 是否主动说'我需要帮助'"
# 提示释放规则
hint_release_rules:
rule_1_consecutive_test_failures:
trigger: "Dev 连续 3 次运行测试且均失败，且每次失败的 error 相同或相似"
action: "释放 L1 提示"
rationale: "Dev 卡在同一个问题上，需要方向指引"
rule_2_thrashing:
trigger: "Dev 在 2 个不同方向之间来回切换超过 2 次（修改→回退→修改→回退）"
action: "释放 L1 提示"
rationale: "Dev 迷失方向，需要定位"
rule_3_wrong_direction:
trigger: "Dev 已经修改了 5+ 个文件但测试通过数没有增加"
action: "释放 L1 提示"
rationale: "Dev 在错误方向上越走越远"
rule_4_l1_ineffective:
trigger: "释放 L1 后 5 轮内，Dev 仍然无法让任何新测试通过"
action: "释放 L2 提示"
rationale: "方向提示不够，需要更具体的指引"
rule_5_explicit_request:
trigger: "Dev 的 think 中出现'I'm stuck'、'not sure where to look'等表达"
action: "释放当前未释放的最低级别提示"
rule_6_never_intervene_too_early:
constraint: "Dev 至少执行 8 轮（含至少 2 次测试运行）后，PM 才可以开始介入"
rationale: "给 Dev 足够的自由探索空间"
# PM 释放提示的消息格式
hint_message_format: |
[PM 反馈]
你已经尝试了几种方案但都没有通过。这里有一些额外信息可能对你有帮助：
{hint_content}
请根据这个信息重新考虑你的方案。
# 关键：记录提示释放时刻的完整上下文
recording:
on_each_hint_release:
- turn_number: int # 第几轮释放的
- hint_level: "L1" | "L2"
- trigger_rule: string # 哪条规则触发的
- dev_state_snapshot: # Dev 当时的状态快照
files_modified: [string]
test_results_history: [{ pass: int, fail: int }]
total_edits: int
- dev_response_in_next_3_turns: # Dev 收到提示后的反应
direction_changed: bool
new_files_touched: [string]
test_improvement: boolPM 的实现方式（给 Coding Agent 的指令）
# pm_agent.py — PM Agent 的核心逻辑
class PMAgent:
"""
PM Agent 在 Dev 执行过程中作为观察者存在。
它不主动干预，只在特定条件触发时释放提示。
"""
def __init__(self, task_blueprint, hints):
self.hints = hints # {L0: [], L1: [...], L2: [...]}
self.current_hint_level = 0 # 当前已释放的最高级别
self.dev_turns = 0 # Dev 已执行的轮数
self.test_history = [] # [(pass_count, fail_count), ...]
self.consecutive_same_failures = 0
self.direction_changes = 0
self.hint_log = [] # 记录每次提示释放
def observe_dev_turn(self, turn_info):
"""
每次 Dev 执行一轮后调用此方法。
turn_info 包含: action_type, test_result (if any),
files_touched, think_content
"""
self.dev_turns += 1
# 更新测试历史
if turn_info.get("test_result"):
result = turn_info["test_result"]
self.test_history.append(result)
self._check_consecutive_failures(result)
# 检查是否需要介入（至少 8 轮后）
if self.dev_turns < 8:
return None
hint = self._evaluate_intervention(turn_info)
if hint:
self.hint_log.append({
"turn": self.dev_turns,
"level": f"L{self.current_hint_level}",
"trigger": hint["trigger"],
"dev_state": self._snapshot_dev_state()
})
return hint
def _evaluate_intervention(self, turn_info):
"""评估是否需要释放提示"""
# Rule 1: 连续 3 次相同失败
if self.consecutive_same_failures >= 3 and self.current_hint_level < 1:
self.current_hint_level = 1
return {
"trigger": "consecutive_test_failures",
"content": self._format_hint(1)
}
# Rule 4: L1 释放后 5 轮仍无进展
if (self.current_hint_level == 1 and
self._turns_since_last_hint() >= 5 and
not self._any_test_improvement_since_hint()):
self.current_hint_level = 2
return {
"trigger": "l1_ineffective",
"content": self._format_hint(2)
}
# Rule 5: Dev 明确求助
if self._dev_is_stuck(turn_info.get("think_content", "")):
next_level = self.current_hint_level + 1
if next_level <= 2:
self.current_hint_level = next_level
return {
"trigger": "explicit_request",
"content": self._format_hint(next_level)
}
return None
def _format_hint(self, level):
hints_at_level = self.hints.get(f"L{level}", [])
content = "\n".join(f"- {h}" for h in hints_at_level)
return (
f"[PM 反馈]\n"
f"你已经尝试了几种方案但都没有通过。"
f"这里有一些额外信息可能对你有帮助：\n\n"
f"{content}\n\n"
f"请根据这个信息重新考虑你的方案。"
)六、Agent 4: Dev
职责
在 Docker 沙箱中执行开发任务，记录完整探索过程。
沙箱配置
sandbox:
runtime: "docker"
base_image: "根据语言选择 python:3.11-slim / node:20-slim / golang:1.22 / rust:1.78"
network: "none" # 禁止网络访问
resources:
cpu: 2
memory: "4g"
timeout: "30min" # 单个任务最长 30 分钟
mount:
- "{repo_checkout}:/workspace:rw"
workdir: "/workspace"Dev 可用工具
tools:
- name: "read_file"
description: "读取文件内容"
- name: "write_file"
description: "写入/覆盖文件"
- name: "edit_file"
description: "精确替换文件中的指定内容"
- name: "list_dir"
description: "列出目录内容"
- name: "search"
description: "在代码库中搜索文本（ripgrep）"
- name: "bash"
description: "执行 shell 命令（包括运行测试）"
# 禁止：web_search, web_fetch（纯离线）Dev 执行协议
1. 读取任务描述
2. 浏览项目结构（list_dir, read_file）
3. 阅读相关代码和现有测试
4. 形成初始方案（在 think 中输出）
5. 迭代开发：
a. 修改代码
b. 运行测试（bash: pytest ... / npm test / go test）
c. 检查结果
d. 如果失败 → 分析错误 → 调整 → 重试
e. 如果收到 PM 提示 → 重新评估方向
6. 所有测试通过 → 运行完整测试套件确认无回归 → 完成
约束：
- max_turns: 50
- 每次修改代码后必须运行测试
- 不能修改测试文件（测试是验收标准，不能改）轨迹记录格式
// 每一轮记录一行 JSON
{
"turn": 1,
"action_type": "read_file",
"action": {"path": "django/db/models/query.py"},
"observation": "class QuerySet:\n def __iter__(self):\n ...",
"think": "我需要先理解现有的 QuerySet 迭代机制...",
"test_result": null,
"hint_received": null,
"files_modified": [],
"cumulative_test_results": null
}
{
"turn": 8,
"action_type": "bash",
"action": {"cmd": "python -m pytest tests/async/test_queries.py -x -q"},
"observation": "FAILED tests/async/test_queries.py::test_async_iteration - TypeError: ...",
"think": "我的 __aiter__ 实现有问题，返回类型不对...",
"test_result": {"passed": 2, "failed": 3, "total": 5},
"hint_received": null,
"files_modified": ["django/db/models/query.py"],
"cumulative_test_results": [
{"turn": 5, "passed": 0, "failed": 5},
{"turn": 8, "passed": 2, "failed": 3}
]
}
{
"turn": 15,
"action_type": "think",
"action": {},
"observation": "",
"think": "连续三次修改 compiler.py 都没有解决问题，测试 error 一样...",
"test_result": null,
"hint_received": {
"level": "L1",
"content": "这个功能的核心在于让数据库查询支持 Python 的异步迭代协议...",
"trigger": "consecutive_test_failures"
},
"files_modified": [],
"direction_change": true
}七、Agent 5: Test
职责
- 在 Dev 过程中提供测试反馈
- Dev 完成后做最终验证
Test 的工作流程
阶段 A：Dev 执行前（预验证）
1. 在 base_commit 环境中运行 Task Designer 指定的测试
2. 确认测试在 base 上 FAIL（如果 PASS → 任务无效，跳过）
3. 如果有 ground truth，确认测试在 target 上 PASS
阶段 B：Dev 执行中（实时反馈）
Dev 每次运行测试，Test Agent 解析结果并：
1. 统计 pass/fail 数量
2. 将结果发送给 PM（PM 据此决定是否释放提示）
3. 如果 Dev 试图修改测试文件 → 阻止并警告
阶段 C：Dev 完成后（最终验证）
1. 运行目标测试套件 → 必须全部 PASS
2. 运行 repo 完整测试套件 → 确认无回归
3. 如果有 ground truth diff → 对比 Dev 的改动和 ground truth：
- 不要求完全一致（实现方式可以不同）
- 检查是否修改了相同的核心文件
- 检查功能是否等价（通过测试即可）
4. 输出验证报告验证报告格式
verification_report:
task_id: "django-async-queryset-iter"
target_tests:
total: 5
passed: 5
failed: 0
status: "PASS"
regression_tests:
total: 16842
passed: 16840
failed: 2
new_failures: 0 # 排除 base 上就失败的
status: "PASS"
ground_truth_comparison:
available: true
same_core_files: true # Dev 修改了相同的核心文件
additional_files: 1 # Dev 额外修改了 1 个文件
functional_equivalence: "PASS" # 通过相同测试 = 功能等价八、Agent 6: Reviewer
职责
从 Dev 的轨迹中筛选有训练价值的数据，丢弃噪声，输出最终 task 卡片。
筛选维度
judgment:
1_difficulty:
score: 1-5
criteria:
5: "Dev 需要 L2 提示才完成，过程有多次方向调整"
4: "Dev 需要 L1 提示，或自主探索超过 25 轮才完成"
3: "Dev 无需提示但经历 3+ 次有意义的迭代"
2: "Dev 2 次迭代内完成"
1: "Dev 一次通过"
2_trajectory_quality:
good_signals:
- "探索有逻辑（不是随机瞎试）"
- "失败后分析了错误信息"
- "收到提示后快速调整方向"
- "有增量进展（fail 数逐步减少）"
bad_signals:
- "重复相同修改"
- "忽略测试错误信息"
- "收到提示后没有改变方向"
3_discard_reasons:
- "env_issue": "环境问题（依赖缺失、构建失败）→ 丢弃"
- "too_easy": "difficulty 1，没有训练价值 → 丢弃"
- "agent_loop": "Dev 在简单问题上打转 → 丢弃"
- "flaky_test": "测试结果不稳定 → 丢弃"
4_rl_training_value:
high: "difficulty 4-5，有完整的探索-提示-突破链路"
medium: "difficulty 3，有有意义的迭代"
low: "difficulty 2，可作为 curriculum 起点"
reject: "env_issue / too_easy / agent_loop / flaky_test"最终输出格式
# verified_tasks/{task-id}.yaml
task_id: "django-async-queryset-iter"
repo: "django/django"
language: "python"
difficulty: 4
rl_training_value: "high"
# ── 环境 ──
environment:
base_commit: "abc123"
dockerfile: |
FROM python:3.11-slim
WORKDIR /workspace
COPY . .
RUN pip install -e ".[dev]"
setup_cmd: "pip install -e ."
# ── 任务描述（PM 视角）──
task_description: |
## 背景
我们的异步 Web 视图中大量使用了 sync_to_async 包裹数据库查询...
## 需求
让 QuerySet 支持 async for 语法...
## 验收标准
1. async for obj in queryset 正常工作
2. 支持链式操作后的异步迭代
3. 向后兼容
4. 新增测试覆盖
# ── 测试 ──
test:
cmd: "python -m pytest tests/async/test_queries.py -x -q"
files: ["tests/async/test_queries.py"]
total_tests: 5
# ── Solution（Dev 的完整轨迹）──
solution:
trajectory_file: "trajectories/django-async-queryset-iter.jsonl"
total_turns: 28
edit_attempts: 6
hints_received: ["L1"] # 收到了 L1 提示
key_moments:
- { turn: 5, event: "first_test_run", result: "0/5 pass" }
- { turn: 12, event: "partial_progress", result: "2/5 pass" }
- { turn: 15, event: "stuck", detail: "连续 3 次相同失败" }
- { turn: 15, event: "hint_received", level: "L1" }
- { turn: 17, event: "direction_change", detail: "从 compiler.py 转向 query.py" }
- { turn: 22, event: "near_completion", result: "4/5 pass" }
- { turn: 28, event: "all_pass", result: "5/5 pass" }
final_diff_file: "diffs/django-async-queryset-iter-dev.patch"
# ── 渐进提示（用于 DPO 构造）──
hints:
L0: []
L1:
- "这个功能的核心在于让数据库查询支持 Python 的异步迭代协议"
- "你需要关注 ORM 层的查询编译器如何生成和执行 SQL"
L2:
- "核心改动在 django/db/models/query.py —— QuerySet 需要实现 __aiter__ 和 __anext__"
- "compiler.py 的 execute_sql 需要支持异步数据库连接"
# ── Ground Truth（可选）──
ground_truth:
available: true
target_commit: "def456"
diff_file: "diffs/django-async-queryset-iter-truth.patch"
# ── 元数据 ──
pm_intervention_log:
- { turn: 15, level: "L1", trigger: "consecutive_test_failures" }
tags: ["async", "orm", "cross-file", "feature-development"]九、端到端执行流程（给 Coding Agent 的完整指令）
Step 1: 准备工作
mkdir -p harnessforge/{repos,blueprints,tasks,trajectories,verified,diffs}
Step 2: Repo Selection
对 seeds.yaml 中的每个 repo:
git clone --depth=100 {repo_url} repos/{repo_name}
运行筛选检查（CI 存在、测试数量、release tag 数量等）
输出 repos/selected-repos.yaml
Step 3: Task Design
对 selected-repos.yaml 中的每个 repo:
分析 release 历史
设计 3-5 个 feature 任务
在 Docker 中验证环境和测试
输出 blueprints/{repo}-blueprints.yaml
Step 4: PM + Dev + Test 执行循环
对每个 blueprint 中的每个 task:
4a. PM 重写需求，准备提示
4b. 构建 Docker 环境，checkout base_commit
4c. Test 预验证（测试在 base 上 FAIL）
4d. Dev 在沙箱中执行，PM 实时监控：
loop:
Dev 执行一轮（read/edit/bash/test）
记录轨迹
if Dev 运行了测试:
Test 解析结果
PM.observe_dev_turn(turn_info)
if PM 返回 hint:
将 hint 注入 Dev 的下一轮 context
if Dev 完成 or 超时:
break
4e. Test 最终验证（目标测试 PASS + 无回归）
4f. 输出: tasks/{task-id}/trajectory.jsonl + report.yaml
Step 5: Review
对 tasks/ 中的每个完成的 task:
Reviewer 评估 difficulty + trajectory_quality + rl_value
if rl_value != "reject":
输出 verified/{task-id}.yaml
统计: 总共 X 个 task, 通过 Y 个, 通过率 Z%
Step 6: 打包
将 verified/ 目录打包为 harnessforge-v2-dataset.tar.gz
生成 README.md 包含统计信息十、规模与成本估算
| 阶段 | 输入 | 产出 | 通过率 |
|---|---|---|---|
| Repo Selection | 30 seeds | ~25 repos | ~83% |
| Task Design | 25 repos × 4 features/release × 3 releases | ~300 blueprints | — |
| PM 重写 | 300 blueprints | 300 tasks | 100% |
| Dev 执行 | 300 tasks × 2 models | 600 trajectories | — |
| Test 验证 | 600 trajectories | ~400 passed | ~67% |
| Reviewer 筛选 | 400 passed | 200-300 verified tasks | ~60% |
首批规模：200-300 个 verified tasks。规模不大但每条数据包含完整探索轨迹（平均 25-40 轮交互）。
扩展到 3K-5K：扩展 repo 列表到 150-200 个 + 覆盖更多 release 版本对。
成本（首批 30 repos）
| 环节 | 单价 | 数量 | 小计 |
|---|---|---|---|
| Task Designer (Sonnet) | ~$0.08/task | 300 | $24 |
| PM (Opus) | ~$0.12/task | 300 | $36 |
| Dev (Sonnet, ~30K tokens) | ~$0.50/run | 600 | $300 |
| Test (自动化) | ~$0.02/run | 600 | $12 |
| Reviewer (Opus) | ~$0.15/task | 400 | $60 |
| Docker 运行 | ~$0.02/run | 600 | $12 |
| 总计 | ~$444 |
十一、快速验证（PoC）
在投入全量之前，先用 3 个 repo 验证流水线可行性：
PoC 范围：
- django/django（Python）
- vitejs/vite（TypeScript）
- gin-gonic/gin（Go）
- 每个 repo 2 个 feature → 6 个 task
PoC 成功标准：
1. 6 个 task 中 ≥ 3 个通过 Reviewer 筛选（通过率 ≥ 50%）
2. 至少 1 个 task 的 difficulty ≥ 4（Dev 需要 PM 提示才完成）
3. 所有 verified task 的环境可复现（Docker rebuild 后测试仍通过）
4. 轨迹格式正确，可被 RL 训练框架（verl-agent / ms-swift）读取
PoC 预估成本：~$30
PoC 预估时间：1-2 天