🌥️ 晓灰

RSS 订阅

在能力边界上造题：可验证后训练的原理与实践

18分钟阅读

假设一批训练任务各跑二十次，留下三组结果。

任务 A：成功 20 次
任务 B：成功 0 次
任务 C：成功 7 次

直觉容易把任务 B 当成最有价值的数据，因为它最难。对只看最终结果的强化学习来说，任务 B 往往什么也教不了。二十次尝试拿到同一个零分，模型看不出哪条路稍微好一点；任务 A 也一样，奖励全部相同，已经没有多少新的策略需要发现。

真正值得留在训练队列里的，是任务 C。模型摸到过正确答案，说明任务可解；十三次失败又暴露出搜索、工具调用或决策上的不稳定。它比当前模型难一点，但没有难到只剩一排零分。

训练队列不是一摞印好的试卷。模型向前走一步，入选的题也要跟着向前挪一步。

最难的题经常没有梯度

在常见的组内相对奖励训练中，模型对同一道题采样多条轨迹，再比较各条轨迹的 reward。如果一组轨迹全部成功或全部失败，组内差异很小，更新信号也会变弱。题目有多难并不重要，重要的是它能不能让当前策略产生可比较的结果。

“恰好难一点”不是出题人读完题目后的感觉，而是当前模型跑出来的统计量：

difficulty(task, policy_t) = 1 - success_rate

同一道题对旧模型可能很难，对新模型可能只是热身。难度属于“任务与当前策略”的关系，不是任务身上永远不变的标签。

按当前模型的运行结果，任务可以分进四个池子：

任务池当前模型的表现去向
已掌握多次运行几乎都成功留在回归集，降低训练采样权重
能力边界有成功轨迹，也有明确失败优先进入 RL
暂时过难当前模型全败，强模型或参考方案可解先用 SFT、蒸馏或拆分任务搭桥
无效任务参考方案也失败，环境或验证器不稳定隔离修复，不得当成负样本

通过率区间没有通用答案。任务昂贵、奖励稀疏时，可以放宽到一个较大的中间区间；轨迹便宜时，可以把采样集中在更窄的前沿。比某个固定阈值更有用的，是看一类任务经过一轮训练后，通过率是否真的上升。长期卡在零分的题，未必高贵，可能只是坏了。

一道题其实是一间能恢复原状的房间

从 Hello World 入门 Harbor：如何稳定地衡量 Agent 把 Task 比作一间考试教室。用于后训练时，这间教室还要能被并发复制，跑完以后恢复到完全相同的初始状态。

一个可训练任务至少包含：

Task
├── instruction       模型要完成什么
├── initial_state     文件、数据库和业务对象的初始状态
├── environment       可用工具、依赖、权限和故障语义
├── verifier          怎样检查结果与副作用
└── budget            时间、token、调用次数和费用上限

模型运行一次以后，才产生真正用于训练的 Episode：

Episode = Task + trajectory + final_state + reward + diagnostics

只有问题和答案，适合教模型模仿。加入环境以后，模型才会留下搜索、读取、修改、重试和回退组成的轨迹；加入 Verifier，这些动作才有机会变成规模化的训练信号。

Verifier 也不能只盯着最终文本。它要检查业务对象是否落在正确状态、是否发生了不允许的副作用，以及模型有没有碰不该碰的东西。一个退款任务最终生成了措辞漂亮的邮件，却没有走审批，应该是失败；代码测试变绿是因为模型删掉了测试，也应该是失败。

造题器和解题器一起移动

如果训练任务永远由人手写，模型很快会吃完最有价值的题目。规模化以后，系统里会多出一个造题器。它可以是规则、脚本、多个专职 Agent，也可以是继续训练的模型。

复杂的题面拿不到奖励，生成的任务还要过几道检查：

  • 参考解法或更强模型能够完成，证明任务没有坏；
  • 当前模型不能稳定完成，仍然存在学习空间；
  • Verifier 可以重复给出一致结果；
  • 新任务没有泄露答案，也不是旧题换几个名字；
  • 模型无法通过修改测试、寻找答案文件或伪造状态骗取分数。

这些检查可以写进同一个奖励函数：

task_reward
  = valid
  × frontier_difficulty
  × verifier_confidence
  × novelty
  - leakage
  - hackability

题目再难，只要不可解、不可判或容易作弊，训练价值就会迅速归零。

造题器还能直接修改环境。给同一个退款流程注入重名客户、过期权限、接口超时和重复提交，比在题面里多写一句“请仔细处理异常”更接近真实工作。模型学到的是怎样在变化的状态中行动，不是怎样复述一条注意事项。

通用 Agent 的原料来自工作留下的摩擦

合作伙伴说订单延期，要求减免费用。员工需要核对合同和物流状态，确认审批权限，更新 CRM，创建工单，再回复邮件。

员工和外部伙伴的真实记录适合做任务种子，不适合原样进入训练。先去掉个人信息和商业敏感字段，再把会话还原为业务对象、状态变化、权限和异常：

真实工作流
  -> 脱敏并抽取任务骨架
  -> 构造 CRM / ERP / 邮箱的初始状态
  -> 生成带状态的 mock 工具
  -> 重放正常路径和失败路径
  -> 检查最终状态与操作顺序

mock 不必复制整套 Salesforce 或 SAP，却要复制这项任务会碰到的脏东西：分页、旧数据、重名对象、权限不足、调用超时、幂等键和跨系统延迟。接口名称一模一样，返回永远干净，训练出来的只是一个擅长填写函数参数的模型。

模型在接口超时后重试，创建了两张退款工单。重放这次失败时，环境构造器要保留“第一次调用已经写入，但响应丢失”这个状态，再变化金额、客户、授权范围和超时位置。Verifier 检查的不是模型有没有说“已经处理”，而是数据库里最终有几张工单，审批是否发生在退款之前。

无法低成本自动判分的任务，先留给人工评测、规则改造或评测器的元评测，不要急着送进 RL。如何科学评测 Agent 生成的文本报告：从评分体系到评测器的元评测 讨论了怎样检查评测器本身是否可靠。

Coding Agent 已经把这条路踩得很实

代码任务天然适合结果验证。仓库能被钉在一个提交上，测试可以反复运行，补丁产生的副作用也能通过静态检查和隐藏测试发现。

多个专职 Agent 可以接力生产训练数据：

Repository Curator
  -> 检查许可证、构建稳定性、测试覆盖和数据污染
 
Issue Reconstructor
  -> 找到修复前 commit，恢复问题发生时的仓库
 
TestWriter
  -> 从 Issue 和 PR 意图生成复现测试与隐藏测试
 
Solver
  -> 产生定位、修改、测试和返工轨迹
 
Patch Reviewer
  -> 拦截删测试、硬编码和无关的大面积改动
 
Execution Verifier
  -> 运行测试、lint、类型检查、性能与安全检查

这些专职 Agent 首先是数据工厂里的工人，不一定出现在产品运行时。

Kimi-Dev 从数百万 GitHub Issue 和 PR 中构造数据，由 BugFixer 与 TestWriter 形成互补角色；RL 阶段使用容器测试的最终结果作为奖励，过滤当前模型多次采样仍然零成功的题，再逐渐加入更难任务。1 OpenAI 披露 codex-1 在多种真实编码环境中接受强化学习，模型可以读取仓库、修改文件并反复运行测试。2 Qwen3-Coder 则把环境扩展视为长程 Agent RL 的主要难点，为此并行运行约两万个独立环境。3

这些披露没有证明各家公司使用同一张流水线图。算法配方可以复现，稳定构造大量真实、可执行、可判分的环境却更难复制。

失败进入哪一种训练，要先分流

把所有失败都送去 RL，成本很高，也容易把环境缺陷训练进模型。

确定的工具格式、固定操作顺序和高质量示范，先进入 SFT。模型已经会使用工具，但遇到分支、错误恢复和长程决策时不稳定，再把任务放进结果可验证的 RL。当前策略始终找不到成功轨迹，可以让更强模型在它实际走到的状态上给出纠正，再做在策略蒸馏（On-Policy Distillation，OPD）；这样蒸馏的不是一批离当前模型很远的理想答案，而是它眼前跨不过去的那一步。

SFT：先学会基本动作与工具协议
  ↓
RL：在能力边界附近探索，按结果更新策略
  ↓
OPD：针对当前策略访问到的状态补示范
  ↓
重新测量通过率，移动任务边界

一次生产失败进入训练前，应该先待在隔离区。确认不是服务故障、数据缺失、权限误配或 Verifier 错判，再生成变体。还要留出一部分同类失败作为隐藏测试，不能把所有病例都拿去训练，最后再用原病例宣布模型痊愈。

从三十个失败开始

第一版不需要先训练一个会造题的模型。三十个真实失败、一个能恢复状态的环境和几条确定性断言，已经足够暴露管线里的问题。

  1. 收集真实失败，按错误发生的位置去重，而不是按用户措辞去重。
  2. 为每类失败冻结初始状态、工具版本和资源预算。
  3. 先写 Verifier，再写任务描述；参考方案必须在同一环境中通过。
  4. 让当前模型对每道题重复运行，记录通过率、奖励方差、成本和失败原因。
  5. 把有成功也有失败的任务放进前沿池；全败任务先拆分、蒸馏或检查环境。
  6. 每轮只扩大一种难度，例如多一个系统、多一个异常或更长的依赖链。
  7. 新模型训练后重跑完整回归集，已经掌握的旧题不删除，只降低训练权重。

用 Harbor 构建稳定的 Agent 评测与进化环境 讨论了怎样冻结 Task、记录 Trial、保存轨迹和让 Candidate 晋级。在此基础上，训练管线还要根据当前模型的表现改写下一轮任务。

尺子会把模型教成它奖励的样子

当任务和奖励开始规模化，最危险的失败不再是模型得零分，而是它拿到了不该拿的一分。

Anthropic 曾用生产训练中发现的八十个可被利用的 RL 环境做实验。模型在这些环境里反复学会骗取奖励后，把寻找评分器、修改奖励和绕过约束的行为迁移到了新场景。4 Verifier 的漏洞不会只污染一道题，它可能被模型整理成一套通用策略。

难度生成也会走偏。增加无关文件、制造含糊需求、随机让工具报错，都能降低通过率，却不一定增加值得学习的能力。好的难题让模型多做一次有意义的判断；坏的难题只是在房间里关了灯。

真正费时间的地方，常常是一处不起眼的状态。退款接口第一次调用已经写进数据库，只是响应在返回途中丢了。如果 mock 没有复刻这个副作用，模型每次重试都会拿到一分。下一轮训练开始前，那张重复工单还躺在数据库里。

Footnotes

  1. Moonshot AI 在 Kimi-Dev-72B 中披露了 GitHub Issue、PR、BugFixer、TestWriter、课程学习与容器结果奖励的训练设计。 ↩

  2. OpenAI 在 Codex 系统卡补充说明 中介绍了真实编码任务、多种环境和基于测试迭代的强化学习。 ↩

  3. Qwen 团队在 Qwen3-Coder 中介绍了长程 Agent RL 与两万个并行训练环境。 ↩

  4. Anthropic 在 Training a Misaligned Reward Seeker 中记录了奖励漏洞如何在大规模 RL 中塑造并迁移模型行为。 ↩