元智能体生成的终端任务让9B模型在20步内达到81.3%平均pass@2，加入困难任务后降至20.6%
相关研究与后续进展
核心概要
该工作提出一个由前沿模型（如Claude Opus）作为元智能体生成终端任务与验证器的流水线，诊断出基准无效、执行框架脆弱和奖励错配三类失败，并通过提示重设计与上下文扩展将基线可解性提升5.6倍；一个9B模型在Claude Opus生成的任务上20步内平均pass@2饱和于81.3%，而在不改变训练配置的情况下加入困难任务后降至20.6%，表明可解性区间是模型特定的。
Figure 2: Left: task categories in all three datasets; no single category dominates. Right: instruction length distributions for all datasets.
arXiv深度剖析
该工作提出一个元智能体流水线，用于生成终端任务与验证器，并据此诊断出三类失败：基准无效、执行框架脆弱和奖励错配。 此前常见做法是依赖可运行的Docker镜像与可执行测试套件来判断流水线是否可用；该工作指出这两者并不保证端到端流水线对终端智能体训练是忠实的，并把失败类别明确命名。 证据来自该流水线自身的诊断过程，摘要以三类失败的命名与描述呈现，未给出各类失败的独立量化统计。
提示重设计与上下文扩展将基线可解性提升5.6倍。 这一提升幅度把数据生成环节的提示与上下文设计识别为影响可解性的关键变量，而不仅是任务本身难度。 摘要报告了5.6倍这一倍数关系，未说明基线绝对值、任务数量或评测协议细节。
一个9B模型在Claude Opus生成的任务上，20步内平均pass@2饱和于81.3%；在不改变训练配置的情况下加入困难任务后，平均pass@2降至20.6%。 同一训练配置下仅改变任务难度分布就带来如此幅度的变化，摘要将其作为可解性区间是模型特定的强证据。 证据为同一模型、同一训练配置下的对照式观察，摘要给出81.3%与20.6%两个数值及20步这一训练步数范围。
该工作主张元智能体可靠性需要把可解性区间校准、验证器审计和基础设施错误核算作为一等评估标准，而非事后诊断。 把这三项从训练后的排查手段提升为评估流程中的前置要求，改变了元智能体生成训练数据的评估设计方式。 该主张由前述三类失败诊断与可解性区间观察支撑，属于基于该流水线经验的方法论建议。
启示与展望
该工作面向使用前沿模型作为元智能体、为终端智能体RL训练生成任务与验证器的研究者与工程团队，适用于需要判断生成任务是否落在目标模型可解区间内的训练数据构建场景。其诊断框架与可解性区间校准思路可直接用于设计任务难度分布、审计验证器以及核算基础设施错误；摘要中9B模型在20步内饱和于81.3%、加入困难任务后降至20.6%的观察，为在训练前先标定模型特定可解区间提供了可操作的参照。
摘要未说明任务数量、任务来源分布、验证器的具体审计方式，也未给出三类失败各自的量化占比，因此难以判断各失败类别在整体流水线中的相对权重。5.6倍提升的基线绝对值与评测条件未列出，81.3%与20.6%所对应的任务集合规模与困难任务定义也未展开。可解性区间是模型特定的这一结论目前基于一个9B模型的观察，是否适用于其他规模或架构的模型仍是开放问题。此外，本次读取范围为摘要，图表与正文细节未纳入，上述数值的统计不确定性与实验重复性有待原文确认。