# 项目执行摘要

> 更新时间：2026-08-30。项目已完成P0并阶段性归档；腾讯云CVM、云硬盘及相关计费资源已经释放，原k3s/BuildKit/sandbox当前不在线。本文中的集群状态、命令和资源规格均为历史验收记录或未来重建参考，不再代表可直接运行的环境。

## 1. 阶段结果

项目已完成从阿里云ACR到腾讯云TCR个人版的主仓切换，并将任务镜像布局优化为80个分片仓库。历史CVM曾使用batch 40、concurrency 10批量执行NOP/Oracle；Oracle选批从简单顺序遍历改为按split缺口和仓库覆盖的确定性轮询。停止条件从“accepted达到500”改为 `freeze_ready=true`，同时要求train/validation/test数量和至少70个仓库覆盖达标。该CVM及其云盘现已释放。

PPO已完成第二轮40K、900秒、并发8的20-step model-only warm-start：160个episode无error、12个timeout、32个成功，actor LoRA为177.5MiB，critic BF16模型为14.11GiB。前10步成功率22.5%，后10步17.5%；Pygments单题贡献一半成功，critic explained variance最终仍约为-1.689，因此只通过工程稳定性门禁，没有通过能力提升门禁。历史40K/32K评测曾显示parent step20点估计高于SFT，但统一64K P0已经消除协议差异：SFT run `p0-klear64k-sft-20260828T145119Z`与parent run `p0-klear64k-parent-20260828T160138Z`在test38均为6/38（15.79%），在Verified27按全部attempt均为9/27（33.33%）。test38配对为3胜32平3负，Verified27 benchmark为2胜23平2负，两个面板delta均为0、exact McNemar p均为1.0。parent在两个面板分别增加约47.7%/46.8%的平均input tokens、19.2%/27.0%的平均agent steps，运行时间约为SFT的2.33/2.24倍，却没有增加成功数。P0结论是没有稳定的总体PPO增益，停止追加训练；Sphinx 8621的单Pod 8Gi OOM仅作为基础设施异常保留，不再为此恢复整套云环境。

## 2. 最终归档状态

- 正式训练数据：`swesmith-curated-grpo-267-v1`，train/validation/test为187/42/38。
- 最终主要候选：原始`Klear-AgentForge-8B-SFT`与父checkpoint `20260820T154406Z/global_step_20`。
- 当前决策：不追加PPO step，不用训练reward、VF loss或critic explained variance替代held-out能力评测。
- 当前基础设施：腾讯云CVM、CBS和相关计费资源已释放；k3s、BuildKit、PVC、sandbox与verifier均不在线。
- 若未来恢复：必须按`PROJECT_LAYERED_ARCHITECTURE.md`和各setup/runbook重新创建运行面，不能沿用旧EIP、KubeConfig、PVC或端口转发。

## 3. ACR→TCR迁移（历史记录）

当前主仓：

```text
ccr.ccs.tencentyun.com/harbor-qwen-grpo-tcr
```

已完成：

- TCR命名空间、infra/基础镜像仓库和80个 `task-00` 到 `task-79` 仓库初始化。
- CVM `skopeo` authfile同时保存ACR源端和TCR目标端登录，权限600。
- `registry-migrate-linux` 迁移BuildKit、curl、uv共3个infra镜像，并逐一校验源/目标digest。
- 84个可用SWE-Smith基础镜像迁入TCR；3个超限项保持skipped；pending为0。
- completed/skipped/rewrites镜像状态已从ACR前缀原子改写为TCR前缀。
- `dataset-images-plan` 重建映射后，coverage为84/84 available、0 missing、0 errors。
- k3s runtime/builder namespace的pull secret已更新为TCR凭证。

`registry-migrate-linux` 不迁移任务镜像。已accepted的历史任务镜像由 `registry-task-migrate` 按旧/新分片映射单独处理；本轮完成166个迁移目标。

## 4. TCR任务仓库布局和预热

当前布局：

```bash
ACK_TASK_IMAGE_LAYOUT=base-sharded-tags
ACK_TASK_IMAGE_SHARDS=80
ACK_TASK_IMAGE_BASE_SHARDS=5
ACK_TASK_IMAGE_REPOSITORY_PREFIX=task
TASK_REPOSITORY_MAX_TAGS=100
TASK_REPOSITORY_PREWARM_CONCURRENCY=5
```

优化点：

1. task ID确定任务tag，基础镜像digest确定主分片，task hash再在5条lane中选择具体仓库。
2. `registry-prewarm-plan` 在复制前同时投影任务tag和 `basecache-*` tag，任一仓库超过100标签即拒绝执行。
3. `registry-prewarm-linux` 把基础镜像层预先复制到后续会使用它的 `task-XX` 仓库，避免每个新任务首次push时重复上传大层。
4. `registry-prewarm-check` 要求每个 `basecache-*` 目标和基础镜像digest一致。

验收结果：357/357预热组合通过digest验证，单仓库最大投影标签数93/100。该优化解决了CVM资源空闲但环境创建长时间停留在大镜像跨仓库push的问题。

## 5. 批量Oracle

当前CVM运行参数：

```bash
CURATION_ORACLE_BATCH_SIZE=40
CURATION_ORACLE_CONCURRENCY=10
CURATION_ORACLE_MAX_RETRIES=2
CURATION_ORACLE_VERIFIER_TIMEOUT_SEC=180
CURATION_ORACLE_ENVIRONMENT_BUILD_TIMEOUT_MULTIPLIER=4
```

已实施的选批优化：

- 过滤已处理和基础镜像不可用任务。
- 先按repo分组，组内用seed + task ID做稳定排序。
- 优先选尚无accepted任务的repo，其次选当前split仍有缺口的repo，再考虑repo已accepted/已处理数。
- 按repo轮询抽取，一轮最多每个repo选一条，避免单一仓库垄断整批。
- NOP失败任务不进入Oracle阶段，其他任务继续执行，单条失败不阻断整批。

批量会话每批先执行 `dataset-freeze-check`；如果未达标则执行一批 `dataset-oracle`，如果已达标则输出 `BULK_ORACLE_FREEZE_READY` 并结束。这避免了固定批数和人工监控导致的过度执行。

## 6. 冻结检查和平衡选择

`make dataset-freeze-check` 使用与真实freeze相同的选择函数，但不写入冻结文件。`freeze_ready=true` 必须同时满足：

- train至少350条。
- validation至少75条。
- test至少75条。
- 整体至少覆盖70个repository。
- 单一repository不超过 `max_per_repo=20`。
- split之间保持repository隔离，且各split按目标数比例分配最小repository数。

因此 `oracle_accepted>=500` 只是必要但不充分条件。本轮在accepted超过500后仍继续Oracle，原因是早期任务按名称集中在少量repo，split容量与repo覆盖尚未同时达标。

## 7. Verifier超时解耦

Oracle和训练的verifier超时使用不同配置：

| 阶段           | 配置                                         | 当前效果                           |
| ------------ | ------------------------------------------ | ------------------------------ |
| NOP/Oracle   | `CURATION_ORACLE_VERIFIER_TIMEOUT_SEC=180` | Harbor job CLI绝对180秒上限         |
| GRPO rollout | `TRAIN_VERIFIER_TIMEOUT_MULTIPLIER=0.06`   | SWE-Smith原始3000秒 × 0.06 = 180秒 |

`scripts/50_train_grpo.sh` 通过Hydra参数 `rllm.remote_runtime.harbor.verifier_timeout_multiplier` 将训练倍率传入runtime。Oracle参数的变化不会隐式改变GRPO，反之亦然。

## 8. BuildKit隧道故障与Oracle状态恢复

CVM重启后，k3s中的BuildKit Deployment、Pod和PVC会恢复，但CVM本机的 `kubectl port-forward` 不会自动重建。本轮故障的决定性错误是：

```text
dial tcp 127.0.0.1:1234: connect: connection refused
```

该错误发生在环境镜像构建阶段，所以尚未创建sandbox Pod。界面中的 `starting environment`、`Failed to download logs`和低资源使用率均是这一失败的表象，不是CPU/内存瓶颈。

恢复操作：

1. 停止 `dataset-oracle-bulk`，防止继续将可用候选记为失败。
2. 重建 `buildkit-tunnel`，并运行 `make buildkit-status` 和 `make buildkit-smoke`。
3. 根据job结果、`exception.txt` 和batch manifest确定受影响的task ID。
4. 备份持久状态，仅恢复已证实由该故障造成的task ID，然后重建Oracle summary。
5. 验证计数，重启bulk，观察首批Pod和异常数。

本轮恢复了batch `a8b550d0beb5` 和 `9b345ea2a202` 共80条错误拒绝记录；`fbaaf8c33f88` 在ingest前已停止。恢复后状态为 `oracle_total=1160`、`oracle_accepted=813`，备份和审计清单位于：

```text
oracle/recovery/20260811-buildkit-tunnel-loss/
```

不能按 `RuntimeError` 类型全局删除：事故前已存在其他真实RuntimeError，恢复必须以精确batch/task ID为边界。

## 9. 2026-08-11历史状态与后续进展

2026-08-11最终Oracle与冻结结果：

```text
static_total=3000
static_accepted=2614
oracle_total=1440
oracle_accepted=981
base_images_pending=0
base_images_completed=84
base_images_skipped=3

train=350/350
validation=75/75
test=75/75
repositories=77/70
freeze_ready=true
```

Oracle bulk已输出 `BULK_ORACLE_FREEZE_READY` 并停止。旧217条短缺冻结集已移动到版本目录外的可恢复归档；正式500条冻结集已在AutoDL导入并注册。split manifest内嵌语义摘要为 `8e29a24910b727e72b63fed539cb834fda47994b8d963c2e002ffa8deb23e654`，JSON文件SHA-256为 `0e23cbcf8c7a1d0eba498a867898514344f2a1e8826130cf0937691dc36077e5`，导出包SHA-256为 `8ce630ad5850c1b0456802cb26230257bb7a0b4ca76be50b643534c3248ced05`。后续进展与顺序：

1. Klear-AgentForge-8B-SFT + mini-swe-agent-plus validation Canary已10/10无异常，平均reward为0.1。
2. 单卡GRPO smoke已完成4/4 rollout、backward、optimizer step、权重同步和global step 1；`TRAIN_GPU_MEMORY_UTILIZATION=0.35`解决了backward OOM。
3. 该批reward、advantage和grad norm均为0，因此只完成链路验收，没有有效学习信号。
4. 原始双卡collective确认当前AutoDL的NCCL Direct P2P/CUMEM路径死锁；`NCCL_P2P_DISABLE=1` 后，两卡FSDP2与两卡FSDP1完整GRPO均通过。
5. 严格A/B确认rank 32在默认 `dummy_dtensor` 路径首轮即生成2048-token乱码并超时；改用 `safetensors` 后恢复合法Bash动作、无timeout且rollout/actor相关性0.999536。
6. runtime schema v3已完成空轨迹守卫、官方公开profile兼容、`working_dir`注入和64K live gate；固定Verified 27题的恢复口径为10/27 = 37.04%，详见第9节。
7. SWE-Smith RL重叠集固定30题仅27题正常评分，reward 1/0为2/25，scoreable-only `pass@1=7.41%`；其余2题OOM、1题ACK label 422。该结果未达到进入8题train smoke筛选的前提，按当前决策不重跑。
8. Klear公开66K SWE-Smith数据是SFT消息轨迹集，固定revision共65,994行且仅有`instance_id`、`messages`字段。论文未披露这些SWE轨迹的生成模型；“强教师模型至少成功一次”是另行描述的RL任务筛选条件。公开轨迹中的提交标记、自测结果和本项目的`klear_trajectory_count`都不能作为官方verifier成功数或reward 1标签。
9. 固定公开强模型证据与当前数据取交集后得到487题`filter-pro`；再与正式冻结500题和completed镜像取交集得到125题`freeze-pro`，其中train/validation/test为90/18/17。跨官方Claude/GPT与SWE-Master两个数据源成功的任务为8题，Claude 3.5成功任务为7题，GPT-4o成功任务交集为0。当前只完成数据派生，尚未从中选择下一轮Canary或训练任务。

## 10. SWE-bench Verified 27题能力Canary

2026-08-14固定27题诊断子集已完成首轮能力验证。该集合来自
SWE-bench Verified，由30题分层/仓库限额清单中镜像已完成的27题派生；3个超限镜像未纳入。

原offline-v2作业：

```text
job=state/harbor-jobs/2026-08-14__14-03-48
requested=27
normally_scored=25
exceptions=2
reward_1=10
reward_0=15
reported_mean=0.370
```

两个异常均为verifier基础设施问题，而非已判定的模型成功：

- `pallets__flask-5014`：原作业 `VerifierTimeoutError` 3000秒；offline-v3复测作业
  `2026-08-14__15-38-50` 为 `Exceptions=0, reward=0`，总耗时11分55秒。
- `sphinx-doc__sphinx-8621`：原作业 `DownloadVerifierDirError`；offline-v3复测作业
  `2026-08-14__15-40-10` 为 `Exceptions=0, reward=0`，总耗时2分40秒。

恢复口径下的校正结果为10成功、17失败，即 `10/27 = 37.04%`，与论文对同名SFT
checkpoint报告的38.2%相差1.16个百分点。这证明当前模型、64K服务、Plus Agent、sandbox和
SWE-bench verifier链路具有与论文数值一致的小样本能力表现。但该数字是“原批次 +
两个异常恢复作业”的合并口径，不得写成单一 `27 Trials / 0 Exceptions`作业；27题也不是
Verified 500的无偏抽样，不得写成完整榜单复现。

offline-v3通过预构建Python/SWE-bench评分环境、移除 `make_test_spec(datum)`引发的
GitHub访问，并为parser设置60秒硬超时。项目内存转换已对27/27个脚本完成编译校验，
全部103项本地测试通过。若需单一可归档证据，下一步在offline-v3下重跑完整27题，验收
`27 Trials / 0 Exceptions`。

## 11. SWE-Smith RL重叠集30题Canary

2026-08-14从Klear相关的166题候选中固定筛选30个train任务进行诊断。计划并发为4，但运行前临时导出的`CANARY_CONCURRENCY=10`覆盖了计划值。结果如下：

```text
job=state/harbor-jobs/2026-08-14__18-29-51
requested=30
normally_scored=27
reward_1=2
reward_0=25
scoreable_only_pass_at_1=2/27=7.41%
agent_oomkilled=2
kubernetes_label_422=1
job_finished_at=null
```

两题agent主容器在8GiB Pod内存上限内因OOMKilled以137退出，Harbor随后进入artifact/verifier阶段，造成界面长时间停留在“running verifier”；另1题因自动生成的label为66字节，超过Kubernetes的63字节上限而无法创建Pod。终端显示30/30后人工中断了未正常结束的job收尾，因此不能把该批写成`2/30`的完整无异常结果。

决策是使用27题正常评分口径判断模型在该候选集上的pass@1明显偏低，不再为3个基础设施异常重跑Canary，也不从这30题继续选8题进入train smoke。保留的代码修复是：ACK的session/environment自动label统一经过确定性63字符净化；`make canary`默认拒绝超过4的并发，只有Verified专用Make目标显式把硬上限提高到10。并发保护用于避免再次误设并发，不等价于两个单Pod OOM已经修复；由于本轮停止且缺少节点容量证据，不提高默认Pod内存。

数据调研同时确认：公开的
`Kwai-Klear/SWE-smith-mini_swe_agent_plus-trajectories-66k`是SFT数据而非公开RL数据；固定
revision含65,994行，schema只有`instance_id`和`messages`。SWE轨迹生成模型未公开，论文中的
“强教师模型”只用于RL任务筛选且身份、任务ID和保留数量均未披露。当前166题清单里的
`klear_trajectory_count`只表示同一任务在公开集中的轨迹行数，不表示成功轨迹数；提交命令、
模型自测或shell返回码也不能替代独立官方verifier结果。

## 12. 强模型验证交集数据

固定revision和逐任务证据边界详见`output/docs/SWESMITH_STRONG_MODEL_FILTER.md`。派生定义如下：

```text
filter-pro = 2614题静态通过集 ∩ verified_any = 487题
freeze-pro = filter-pro ∩ 正式冻结500题 ∩ completed镜像 = 125题
freeze-pro split = train 90 / validation 18 / test 17
```

`verified_any`允许官方Claude/GPT轨迹或SWE-Master教师池任一来源成功；`verified_cross_source`要求两个来源都成功。SWE-Master没有逐任务披露MiniMax-M2与GLM-4.6的单独归属，因此跨源任务不能写成五个指定模型全部成功。两个JSON清单位于`state/swesmith-pro/`；执行`make swesmith-pro-derive`可从固定上游revision重建，不会运行Canary。

## 13. 最小运维命令（历史）

```bash
tmux ls
tmux capture-pane -pt buildkit-tunnel:0.0 -S -30
tmux capture-pane -pt dataset-oracle-bulk:0.0 -S -100

make buildkit-status
make dataset-status
make dataset-freeze-check

KUBECONFIG="$HOME/.kube/harbor-curation.yaml" \
  kubectl get pods -n harbor-qwen-grpo -o wide
```

Oracle已结束，不应继续追加批次。后续只需保留BuildKit tunnel用于Canary/GRPO，并以manifest内嵌语义摘要、manifest JSON文件SHA-256和导出包SHA-256作为数据交接依据。

## 14. 2026-08-17历史freeze、Canary与PPO计划

```text
dataset=swesmith-curated-grpo-267-v1
train=187
validation=42
test=38
repositories=89
task_images_verified=267/267
base_images_available=103
base_images_skipped=2
split_manifest_semantic_sha256=ae5df9a3f4a3fc8af44fac420b36529e283839e1bd3de9daba65d5bcda51447d
```

`Klear-AgentForge-8B-SFT`已在该数据集validation按seed `20260817`抽取30题完成64K Canary：reward 1/0为12/18、Mean 0.400、Exceptions 0、耗时32m46s，作业目录为`state/harbor-jobs/2026-08-17__16-14-11`。该结果与旧32K固定57题不是同一题集，不合并排名。

本节以下内容保留当时的实施顺序，不代表当前状态。其后的PPO已改为4卡trainer加1卡单vLLM分离拓扑，完成两轮各20步及三模型能力评测；最终结论与归档状态以本文第1、2节及[`PPO_TRAINING_RUNBOOK.md`](PPO_TRAINING_RUNBOOK.md)为准。