SPADE这个方向核心是把“可执行代码环境”和“自对弈共进化”组合成一套训练框架。它最值得关注的点不是某一个模型突然变强而是让AI自己生成训练环境、自己写代码、自己跑代码、自己出结果再用结果反过来训练自己。简单说就是模型不再只对着固定数据学习而是不断跟自己生成的“任务”和“对手”互相对抗从而持续进化。这篇文章适合正在做智能体AI、大模型后训练、强化学习落地或者研究自对弈训练方案的同学读。如果你只是调用现成接口做业务这个方向可以先了解不需要立刻照搬。标题里提到的SPADE框架我理解的重点是两个一是任务和环境本身可以由模型生成而且必须是可执行代码不是一堆纯文本描述二是求解器和任务生成器之间形成共同进化关系。这种架构在学术和工程里其实有不少类似叫法比如自博弈、反事实课程学习、自主智能体训练。SPADE的特点是把环境也变成可生成的、可执行的而不是人工写死一组固定测试用例。下面我按自己的落地经验拆一遍它到底解决什么问题、最小闭环怎么跑通、哪些地方最容易翻车。1. 先搞清楚SPADE真正解决的是哪个瓶颈1.1 智能体训练为什么卡在“环境”上传统大模型训练尤其是后训练阶段主要依赖静态数据集。静态数据有很明显的问题数据是过去时场景是固定的模型学完之后遇到真实环境里的新情况仍然不知道怎么应对。智能体AI和多步推理模型需要的是可交互环境。模型不仅要输出答案还要能观察反馈、修改策略、执行动作然后根据结果再生成下一步。真实环境往往不可控成本高还有安全边界。人工构造环境又非常费时写几百个测试用例已经很累更别说覆盖数千种复杂场景。这就是环境瓶颈想训练一个会“做事”的智能体但没有足够的可交互环境。1.2 可执行代码环境解决了什么可执行代码环境意思是把任务和任务对应的验证方式都写成代码。模型可以自己提出一个编程任务生成测试用例或者评分脚本然后在隔离的沙箱里真正执行。这个设计有几个直接好处反馈是客观的通过测试就是通过不通过就是不通过不需要人工逐个标注。环境可以自动组合只要模型还能生成新任务环境规模就是动态扩张的。结果是可复现的一次训练样本可以反复回溯方便排查模型是能力不足还是任务定义不清晰。成本相对可控相比搭一套真实机器人环境或复杂游戏环境代码沙箱更容易在本地部署。很多人刚看到SPADE时会以为它只是“让模型写代码”。其实不是。让模型写代码只是最外面一层关键是把代码执行结果转成训练信号再把这个信号送回模型更新参数。1.3 自对弈共进化解决了什么自对弈共进化的思路是让两个角色互相促进。一边是任务生成器负责持续产出越来越有区分度的任务另一边是问题求解器负责在这些任务上不断提升能力。如果只靠固定题库模型练到一定程度就饱和了因为没有新的挑战。如果只让任务生成器随便生成任务会变得过难或者过偏求解器学不到稳定技能。自对弈的价值在于双方会互相逼着前进求解器变强之后生成器就需要生成更难的任务生成器把任务变难之后求解器又被迫去适应新难度。这个机制能让训练数据始终处于“最近发展区”不会一直重复简单样本也不会直接跳到完全解不动的难度。这个特点正是SPADE在智能体AI训练里最有价值的地方。2. SPADE拆开看四个核心组件和闭环逻辑如果要做一套SPADE落地我通常把它分成四个核心组件任务生成器、行为执行器、评估器、优化器。整个框架实际上就是这四个组件组成一个循环。2.1 任务生成器任务生成器的任务是产出“候选训练任务”。它负责定义问题、生成输入、生成预期输出或者测试逻辑。任务不能只保存在自然语言描述层面因为自然语言无法自动判定对错。必须把任务转成可执行代码比如生成一组随机输入、一个校验函数、一个参考实现或者一套完整测试套件。比如说训练目标是“让智能体学会修复代码报错”任务生成器不能只输出一道文字题“请修复排序函数”而应该输出一个包含有 bug 的代码文件、对应的单元测试以及运行方式。求解器修复后再跑测试结果才可信。2.2 行为执行器行为执行器就是真正运行代码的地方。它接收任务和求解器输出的代码在受限环境中执行然后返回退出码、标准输出、标准错误、超时信息。执行器必须考虑几个边界运行超时防止死循环拖垮整个训练流程。内存限制防止单次任务占满资源。依赖白名单防止代码生成不可控行为。输出长度限制防止日志刷爆磁盘。这些听起来像工程细节但实际运行中绝大多数训练中断都不是模型算错而是沙箱资源被某个任务打满。2.3 评估器评估器负责把执行结果转换成训练信号。最基本的评估方式是看测试用例是否通过。更复杂一点的场景比如代码修复质量、代码执行效率、多步决策成功率就需要设计多层次评分规则。注意一点评估器不能完全依赖LLM打分。如果所有判断都交给模型模型可能会偏爱格式好看但功能错误的输出。更稳妥的做法是“可执行结果为硬标准LLM评分为辅助标准”。先是测试用例通过再看效率、可读性、资源消耗等软指标。2.4 优化器优化器就是模型更新模块。它把评估器产出的偏好对或奖励值组织成训练数据通过SFT、DPO、PPO等算法更新模型参数。也就是说SPADE并不是某一种训练算法而是一个数据生成和训练框架。底层用什么算法可以根据任务和算力选择。最小验证阶段用DPO就够了因为它只需要偏好对不需要额外训练奖励模型想要更大规模再考虑PPO。2.5 整个闭环一个完整的SPADE迭代流程可以用伪代码表示for round in range(max_rounds): task task_generator(current_model, previous_tasks) if not is_executable_task(task): continue solutions solver(current_model, task, num_candidates4) results sandbox.execute(task, solutions) data build_preference_pairs(task, solutions, results) if enough_data: current_model trainer.update(current_model, data) validation_score eval_on_fixed_set(current_model) log(round, validation_score, average_pass_rate)这个循环有一个关键点任务生成、求解、执行都必须按日志方式记录。否则出问题时你根本不知道是任务生成不规范还是求解器能力不足还是执行环境有问题。3. 动手之前先做好这些准备3.1 模型和算力条件先用已有的API模型做模拟其实不需要太多算力。你现在可以把任务生成器和求解器都接同一个API先验证闭环能不能转起来。这一步主要看数据流和评估规则是否合理。本地训练才需要考虑GPU。如果你只有一张普通显卡建议先从开源小模型开始比如7B到14B级别任务范围也控制在代码生成、代码修复、测试生成这几个方向。原始材料没有给出明确版本和显存数据落地时先用小模型确认参数再评估要不要增大规模。这里最重要的经验是第一版不要追求大模型要求稳。先把闭环跑通再升级模型容量。3.2 沙箱环境沙箱推荐用容器隔离。每个任务执行时创建一个临时工作目录挂载只读的依赖目录限制CPU时间、内存、网络访问。网络访问默认关闭。自动生成的代码本身不稳定如果它还带外部接口请求问题会更难排查。训练阶段直接禁网只保留本地文件系统读写。3.3 评估规则评估规则必须提前写清楚。这比选模型更重要。比如代码生成任务评估规则可以定义为测试用例全部通过才算成功。部分通过时按通过比例计分。两个候选都通过时看运行效率。运行超时或崩溃视为失败。如果没有明确的胜负规则自对弈就没有稳定的训练信号。3.4 最小迭代目标开始跑之前先定一个最小迭代目标。我一般这样定义至少跑通100个任务。每个任务至少生成4个候选答案。单次运行成功率高于某个阈值。固定验证集效果不能下降。不要一上来就追求“模型打赢所有日常任务”。自对弈训练的第一步是让流程不出错不是让模型变强。4. 跑通一个最小自对弈循环4.1 步骤一生成任务用一个任务生成器让模型产出结构化任务。任务必须包含任务描述、生成方式、校验规则。一个任务示例结构如下{ task_id: sort-001, description: 实现一个函数将整数列表按从小到大排序原地修改。, language: python, execution: { timeout_seconds: 10, memory_mb: 256 }, generator: { type: random_test_generator, test_rules: [ 输入为随机整数数组, 长度在1到100之间, 输出必须为非降序排列, 原地修改则额外加分 ] } }任务生成器可能输出格式错误所以代码里要加一层校验如果任务没有生成器字段、没有可执行脚本、没有超时设置直接丢弃不能进入后续流程。4.2 步骤二生成多个候选解让同一个模型生成多个候选解建议把temperature调高一些比如1.0到1.2同时可以修改top_p让候选解之间差异更大。同一个任务不要只生成一个答案。自对弈训练需要比较“哪个答案更好”如果只有一个答案没有对比后面构造偏好对就很麻烦。这一步最常遇到的问题不是模型写不出代码而是多个候选解完全一样。原因是温度太低或者采样限制太窄。出现这种情况时我会降低最大输出token限制、提高随机性或者要求模型给出不同解法说明。4.3 步骤三在沙箱里执行执行阶段把任务和候选解一起放进沙箱。沙箱要输出三类信息退出码判断是否正常结束。标准输出和标准错误用来定位运行时问题。耗时和内存峰值用来判断质量差异。执行成功的判断不只看退出码。有时候退出码是0但答案根本没按任务要求输出。所以执行器还要带上特定任务的“断言检查”也就是自动验证结果是否符合任务描述。4.4 步骤四构造偏好对和训练信号执行完后根据评估规则给每个候选解打分。然后两两组合成偏好对。比如同一个任务生成了四个答案经过执行和评估答案A通过全部测试耗时0.4秒。答案B通过全部测试耗时0.8秒。答案C通过部分测试。答案D运行超时。那么(A, B)是一个偏好对(A, C)是 (A, D)也是还可以构造(B, C)等。每个偏好对都记录了任务、两个回答、选择结果。这些数据可以直接用于DPO训练。4.5 步骤五更新模型建议先积累至少几千条高质量偏好对再开始微调。中途直接边跑边训容易出现数据分布不均匀还可能在一次模型更新后整体行为变化太大。微调完成后用固定验证集检查效果。固定验证集要保留人工标定的一批任务里面不能包含模型自己生成的任务。否则你很难判断模型是真实能力增长还是只学会了生成器的套路。4.6 步骤六迭代验证每轮更新后要记录三个指标固定验证集正确率。新生成任务的平均通过率。任务生成器产出的平均难度。我一般会设定固定验证集不下降且新任务通过率保持在30%到70%之间才认为这轮训练有效。如果通过率高于90%说明任务太简单需要让任务生成器升级难度如果低于20%说明任务太难求解器难以学习。5. 从最小循环到可用训练系统需要补哪些模块最小循环跑通之后如果只是做实验已经够了。但如果你想让它稳定产生训练数据还要补五个模块。5.1 队列、日志和失败重试任务生成不是批量全部生成再批量全部执行。它更像一个流式队列生成一个任务马上执行执行完评估评估完归档。日志至少要包含任务ID任务生成时的输入候选解代码执行返回码和超时信息评估分数本轮trained模型版本号没有日志后面排查会让你怀疑人生。因为没有版本号的训练数据无法判断是数据问题还是模型更新问题。5.2 安全边界代码生成加自动执行最需要盯紧的是安全边界。不允许生成的任务访问外部网络。不允许读取沙箱之外的文件系统。不允许无限使用内存和CPU。不允许调起子进程做异常操作。这里不鼓励任何绕过系统限制的行为。正常训练框架里安全策略应该写死而不是依赖模型自觉。只要你允许模型在本地生成并执行代码就必须默认它会出错遇到危险指令不应该执行。5.3 任务多样性控制模型很容易陷入生成相似任务的模式。比如一开始生成了大量排序类任务后续几千轮都是排序变体那模型能力只会覆盖排序不会覆盖其他方向。解决办法有两个方向一是任务去重对生成的任务做聚类相似任务合并二是采样约束每个主题下限制生成数量一旦超出就强制切换到其他主题。5.4 评估指标设计评估指标不能只写“任务通过率”。我建议至少分三层统计指标层级统计对象使用场景任务层单任务是否通过测试判断求解器基础能力候选层同一任务多个候选解的差异判断生成多样性系统层整个循环内任务分布、平均难度、训练数据量判断训练资源投入是否合理整套系统稳定后可以再加一个“任务贡献度”概念哪些任务真正促进了模型验证集提分哪些任务只是反复出现但没有带来提升。5.5 收敛控制自对弈系统最大的问题不是不学习而是学着学着突然跑偏。最难发现的是任务生成器悄悄变了分布求解器跟着适应了错误分布。因此每轮都要对比当前任务分布和上一轮任务分布的相似度。如果两个分布差异过大就要回滚上一版任务生成器或者引入人工抽查。6. 踩坑和常见误判6.1 自对弈没有提升先查动态坍塌很多人跑了几十轮发现模型验证集没怎么涨。最常见的原因是动态坍塌任务生成器和求解器联合收敛到了一个简单解空间互相“配合”得非常好但实际能力没有拓展。动态坍塌的信号是新任务通过率很高但这批任务都很简单。候选解之间相似度极高。固定验证集长期不变。应对手段是增加任务多样性控制、降低任务通过率阈值、定期向任务池插入人工编写的高难度任务。6.2 固定验证集很关键没有固定验证集自对弈很难被观察。只有持续在同一个固定验证集上测试才能区分“模型确实变强”和“模型只是更适应自身生成分布”。固定验证集要足够稳定同时也要足够有区分度。我建议有三种难度的任务简单、中等、困难每一层都要有。这样你在查看指标时能知道提升发生在哪一层。6.3 评估器偏差会带偏整个训练评估器一旦有偏差整个自对弈会跟着学偏。如果评估器只奖励“代码风格好看”求解器就会倾向于生成短但可读的代码而不是真正解题。所以评估器硬标准一定要占主导地位。能写成规则判断的不要用LLM判断。只有当规则本身无法覆盖时才引入LLM打分并且要把LLM打分结果和规则结果做交叉验证。6.4 执行环境不稳定执行环境不稳定是另一个高频翻车点。可能是依赖版本不一致也可能是容器资源限制不合理还可能是同一任务在不同机器上执行结果不同。排查顺序是先记录环境哈希和依赖版本再固定容器镜像最后确认磁盘、内存、CPU限制在任务之间是否完全一致。如果任务执行结果波动很大先修执行环境再继续训练。6.5 成本失控自对弈框架的Token消耗比普通数据集生成高很多。因为每个任务要多次尝试求解每个候选解都可能很长执行日志也占存储。建议做三件事给单轮迭代设成本上限给单任务生成候选数设上限给执行日志设置轮转策略。如果不控制一次全量实验可能消耗远超预期。6.6 通用排查链路遇到问题我一般按这个顺序定位先看任务生成结果是否格式完整、是否可执行。再看候选解代码是编译错误、逻辑错误还是超时。接着看执行环境资源限制、依赖版本、临时目录是否正常。再看评估器同一个代码多次评估分数是否一致。最后看模型更新训练数据是否存在任务重复、标签错误、分布偏移。报错不一定是模型问题。很多时候问题出在输入格式、路径权限、依赖版本或者评估规则上。7. 合适的项目起步方式与下一步方向7.1 先用API模型做模拟不要一上来就买显卡跑自对弈。先用一个API模型比如通用的文本生成接口搭建最小闭环跑上几百个任务。主要验证几个问题任务生成器能不能稳定产出可执行任务求解器能不能按预期生成多个候选解评估器能不能自动区分好坏训练数据能不能转化成偏好格式。这一步不需要训练模型只需要记录数据看数据质量。如果连数据质量都不达标后面训练也没意义。7.2 再用开源模型本地验证数据质量达标之后再考虑本地微调。推荐从7B到14B的开源模型开始任务方向限制在代码生成、测试生成、代码修复。本地跑的时候先不要用复杂训练算法。用DPO就够。因为DPO只需要偏好对不需要奖励模型工程复杂度低很多。7.3 和主流后训练方法配合SPADE不是用来替代传统后训练的它更适合作为后训练里的数据生成循环。你可以这样组合先用高质量人工数据做SFT让模型具备基本能力。再启动SPADE生成大量偏好数据做DPO训练。接着用固定验证集评估。如果进入强化学习阶段再把可执行环境作为奖励来源接入PPO。这样做的好处是降低风险。SFT保证下限SPADE扩展场景RL在可执行环境上做进一步优化。7.4 我给你的落地建议第一单条任务先跑通再开批量。不要一上来就设计多智能体协作、复杂队列、分布式训练。先把“生成一个任务、执行一个任务、评估一个任务、更新一次模型”跑通。第二批量任务要重点看失败重试、输出命名、队列堆积。批量跑的时候一个任务失败不应该拖垮整个队列应该标记后跳过并把失败原因写进日志。第三默认参数适合入门但不一定适合长期训练。如果你的目标是稳定的生产环境就必须把安全策略、任务去重、评估一致性、模型版本管理全部想好。最后这个方向真正落地时最该盯住的不是模型又变强了多少而是训练分布是否平稳、评估信号是否可靠、数据是否可以追溯。这三件事做好了SPADE才有可能成为可持续的数据生产和能力进化系统。