先花三分钟理解一个现象在过去两年的大模型训练里数据几乎都是“人工标注 → 清洗 → 喂给模型”的单向流程。模型学完一批数据能力提升但下一次训练又要等新的数据被标注出来。这个过程在数学推理、代码生成、工具调用这类需要“过程反馈”的场景里尤其吃力。因为人工标注不仅贵而且很难标注出“为什么这条路径错了”的过程性信号。SPADE 这个方向正是冲这个问题来的。它想做的事可以概括成一句话让 AI 自己生成训练环境并在环境里和自己对抗、持续进化。它把可执行代码环境、自对弈机制、共进化框架三者揉在一起形成一套不需要人工不断喂数据也能持续提升能力的训练范式。这篇文章会围绕 SPADE 做一次系统拆解。我们会先讲清楚它试图解决什么问题和三个核心概念再给出一套可运行的最小演示框架最后结合我的实际经验讲清楚如果要在自己的项目里落地这套思路哪些模块是必须的、哪些坑是躲不开的、哪些工程底线不能碰。无论你是做算法训练、Agent 应用开发还是对大模型训练框架感兴趣的同学这篇文章都能给你一套“能看懂、能复现、能扩展”的闭环参考。1. SPADE 是什么让模型在自建环境中持续进化想理解 SPADE先要接受一个和传统训练完全不同的前提训练环境不应该是固定不变的而应该由 AI 自己按需生成。1.1 为什么“静态数据集”撑不起复杂推理能力先看传统方案的问题。假设你要训练一个模型学会“根据自然语言生成 Python 代码并运行结果”。传统做法是准备一批自然语言问题描述请人工或更高阶模型写出参考答案代码拿这些问题和参考答案去微调模型。这套流程最大的痛点在于问题空间是封闭的。模型见过的题型是有限的。一旦遇到训练集里没有的问题分布能力就会明显掉档。更麻烦的是代码类任务非常依赖过程性反馈。错误代码的运行结果、报错信息、中间变量值这些信息在静态数据里很稀缺。模型很难通过“只看答案”学会“如何调试和重试”。SPADE 的思路则完全不同让模型先写代码生成训练问题再让另一个模型或同一个模型的不同策略去解决这些问题然后根据解决过程的反馈反过来优化生成器。问题空间是动态扩张的反馈信号是过程性的能力提升也就有了持续来源。1.2 三个核心概念速览SPADE 不是单一算法而是一个框架组合。它的三个支柱是概念一句话解释在大模型训练中扮演的角色可执行代码环境能真正运行代码、返回结果和报错的安全沙箱提供过程性反馈信号替代人工标注自对弈同一模型的不同策略相互对抗、彼此出题、彼此解题持续提供有难度梯度的训练样本共进化框架生成器出题方和求解器做题方交替提升防止训练数据停滞能力持续螺旋上升我把这三个概念再展开说一下。可执行代码环境是这套框架的地基。模型生成的代码必须被真正执行拿到 stdout、stderr、返回值、超时信息这些信号才构成“过程性奖励”。如果只是在文本层面模拟“这段代码大概能跑”框架就退回了静态数据模式失去了进化动力。自对弈机制借鉴了 AlphaGo 的思想但对象变成了代码问题。一个模型本体负责出题一个负责解题。出题方想方设法生成越来越难的问题解题方想方设法破解这些问题。两者在一轮轮对抗中都变得更强。共进化框架则保证“出题”和“解题”两个能力不会失衡。如果出题太难、解题方永远解不出学习信号就消失了如果题目太简单、解题方轻松满分出题方也得不到有效反馈。共进化的核心是动态难度调节让题目永远保持在“跳一跳够得着”的区间。1.3 SPADE 和普通 Agent 的区别这里容易产生一个混淆SPADE 中的“模型生成代码并执行”看起来很像 Agent 应用但两者目标完全不同。普通 Agent 应用关注的是“完成任务”例如让它查天气、订机票、写报告。它吃的是用户给的输入输出是任务结果。SPADE 关注的是“让模型变强”。它的产物不是业务结果而是高质量的训练数据、可学习的难度阶梯、可复现的推理路径。换句话说Agent 是在用模型能力解决任务SPADE 是在解决任务的过程中顺便训练出更强的模型。这个区别决定了工程实现方式完全不同。SPADE 框架需要额外考虑数据沉淀、轨迹评估、难度调节、策略迭代这些都是传统 Agent 工程不太敏感的问题。2. SPADE 框架的整体架构设计2.1 框架组成的五个核心模块一个完整的 SPADE 框架通常可以拆成五个模块模块职责关键点环境生成器根据目标能力生成训练任务控制任务难度、多样性和合法性代码执行沙箱运行生成的代码并返回反馈安全限制、超时控制、资源隔离自对弈求解器尝试解决生成的任务提供解题轨迹暴露薄弱环节轨迹评估器评估解题质量并生成奖励信号区分“结果对”和“过程好”进化控制器根据反馈更新生成策略和求解策略动态调节难度防止模式坍缩环境生成器是框架的“出题大脑”。它接收一个高层的目标描述例如“训练模型理解递推关系”然后生成一系列从易到难的任务。任务可以是自然语言描述、可执行的断言、单元测试或者半成品代码模板。代码执行沙箱是安全边界。它负责在隔离环境里运行代码捕获标准输出、错误信息、运行耗时。这个模块最大的挑战不是“能跑”而是“安全地跑”。后面我会详细讲沙箱的设计底线。自对弈求解器是解题方。它通常是一个已经具备基础代码能力的模型接收生成器给出的问题输出解题代码并提交到沙箱执行。解题成功与否、路径是否正确这些信息都会被记录下来。轨迹评估器负责把原始运行结果转化为可学习的信号。同一个问题一次 AC通过和一次 TLE超时对应的训练价值完全不同。好的评估器能把这种差异量化。进化控制器是协调者。它会记录最新几轮生成器的出题难度分布、求解器的通过率并据此调整后续生成策略。如果通过率长期低于 20%就降低难度如果连续多轮通过率接近 100%就提升难度。2.2 一次完整的进化循环SPADE 的训练循环可以用下面的流程描述1. 初始化准备一个基础求解器、一套基础任务模板 2. 生成环境生成器根据目标描述生成 N 个新任务 3. 隔离验证在沙箱中运行任务自带的参考解确认任务本身可解 4. 对抗求解器逐个尝试解决这些任务 5. 评估记录通过率、耗时、错误类型、解题轨迹多样性 6. 反馈进化控制器根据评估结果调整生成器参数 7. 沉淀把高质量的(任务, 解题轨迹, 反馈)三元组加入训练集 8. 迭代用更新后的求解器继续下一轮注意第 3 步很多人会忽略。生成器自己生成的任务必须先由“参考解”验证一遍防止生成出本身就有问题的任务。这一步叫做“任务合法性校验”是保证数据质量的生命线。2.3 为什么“可执行环境”是 SPADE 的关键如果不用可执行环境只靠文本生成任务和答案整个框架会退化成“模型自己给自己出选择题”没有任何新增信息量。可执行环境提供了三类关键信号第一类是正确性信号。代码跑通、输出与预期一致这是最直接的信号。没有它模型的“自我感觉正确”没有任何意义。第二类是调试信号。报错信息、堆栈轨迹、部分通过的测试用例这些信号比“正确/错误”更细腻。模型可以从中学习“为什么错、错在哪里、如何修正”。第三类是难度信号。一个任务求解器花了大量 token 才通过说明它超出了当前能力舒适区这正是最有训练价值的样本。静态数据集很难自动标出这种难度信息。3. 环境准备与最小化依赖在动手写代码之前先把运行环境准备好。这一节我以常见环境为例版本号需根据你的实际情况调整重点讲清楚依赖的理由。3.1 基础运行环境推荐使用 Linux 或 macOS 作为开发环境。Windows 也可以但在沙箱子进程管理和信号处理上会遇到更多兼容问题。如果你只有 Windows建议用 WSL2。操作系统Ubuntu 20.04 及以上或 macOS 12编程语言Python 3.9 及以上包管理工具pip 或 poetry代码解释器本机 Python 解释器用于沙箱执行3.2 Python 依赖清单下面是一个最小依赖清单。注意这里没有写死版本号因为 SPADE 相关库迭代较快你可以安装最新稳定版。# requirements.txt # SPADE 最小演示框架依赖 # 版本按当前环境最新稳定版安装即可 python-dotenv1.0 pydantic2.0 typer0.9如果后面需要接入大模型 API 做生成器和求解器还需要根据实际选择的模型服务商安装对应 SDK。这里先不展开。安装命令pip install -r requirements.txt3.3 项目目录结构我建议按模块化方式组织代码方便后续扩展。spade_demo/ ├── requirements.txt ├── config.py # 全局配置超时、最大 token 等 ├── models.py # 数据结构定义 ├── sandbox.py # 代码执行沙箱 ├── generator.py # 环境生成器 ├── solver.py # 自对弈求解器 ├── evaluator.py # 轨迹评估器 ├── evolution.py # 进化控制器 主循环 └── run.py # 启动入口这个结构把“生成、执行、求解、评估、进化”五个模块拆开职责清晰。后面每个模块的核心代码都会对应到具体文件。4. 核心模块代码拆解下面的代码是一个教学级最小实现。它不是为了达到生产级性能而是为了把 SPADE 的关键机制讲清楚。你在复现时需要根据自己的模型接口和环境做调整。4.1 数据结构定义先定义框架中流转的核心数据结构。建议用 Pydantic 做数据校验避免脏数据在模块间传播。# 文件路径spade_demo/models.py from typing import List, Optional from pydantic import BaseModel, Field class Task(BaseModel): 一个由生成器产出的训练任务 task_id: str description: str # 自然语言问题描述 reference_code: str # 参考解代码用于验证任务本身可解 timeout: int 5 # 执行超时时间秒 difficulty: float 0.5 # 生成器预估的难度 0~1 tags: List[str] Field(default_factorylist) class ExecutionResult(BaseModel): 一次代码执行的结果 task_id: str code: str stdout: str stderr: str return_code: int 0 timed_out: bool False duration_ms: int 0 class Trajectory(BaseModel): 一条完整的解题轨迹 task: Task attempts: List[ExecutionResult] Field(default_factorylist) final_status: str pending # passed / failed / timeout / error reward: float 0.0 # 评估器给出的奖励信号Task是生成器和求解器之间的“语言”。ExecutionResult记录每一次执行的真实反馈。Trajectory是最终沉淀到训练集里的数据单元。4.2 安全沙箱代码执行的核心沙箱是最需要谨慎对待的模块。教学演示中我们至少要做到三件事限制危险操作、限制执行时间、限制资源消耗。# 文件路径spade_demo/sandbox.py import ast import subprocess import sys import time from typing import List from models import ExecutionResult # 禁止出现在生成代码中的危险节点类型 _FORBIDDEN_NODES ( ast.Import, ast.ImportFrom, ast.Global, ast.Nonlocal, ast.Call, # 需要二次检查函数名这里先由 _check_forbidden_call 处理 ) def _check_forbidden_call(node: ast.Call) - bool: 检查是否调用了危险函数 if isinstance(node.func, ast.Name): if node.func.id in {exec, eval, compile, __import__, open}: return True if isinstance(node.func, ast.Attribute): if node.func.attr in {system, popen, subprocess}: return True return False def validate_code(code: str) - List[str]: 静态检查代码是否包含高危操作返回违规描述列表 violations [] try: tree ast.parse(code) except SyntaxError: return [syntax error] for node in ast.walk(tree): if isinstance(node, _FORBIDDEN_NODES): violations.append(fforbidden node: {type(node).__name__}) if isinstance(node, ast.Call) and _check_forbidden_call(node): violations.append(fforbidden call: {ast.dump(node)}) return violations def run_code(code: str, timeout: int 5) - ExecutionResult: 在子进程中执行代码并返回结构化结果 start time.time() try: proc subprocess.run( [sys.executable, -c, code], capture_outputTrue, textTrue, timeouttimeout, env{PYTHONPATH: , PATH: /usr/bin:/bin}, cwd/tmp, ) return ExecutionResult( task_id, codecode, stdoutproc.stdout, stderrproc.stderr, return_codeproc.returncode, timed_outFalse, duration_msint((time.time() - start) * 1000), ) except subprocess.TimeoutExpired: return ExecutionResult( task_id, codecode, stdout, stderrtimeout, return_code-1, timed_outTrue, duration_msint((time.time() - start) * 1000), ) except Exception as e: # noqa: BLE001 return ExecutionResult( task_id, codecode, stdout, stderrstr(e), return_code-2, timed_outFalse, duration_msint((time.time() - start) * 1000), )这段代码做了两层防护。第一层通过ast静态分析把import、eval、open这类高风险操作直接拦截。第二层通过subprocess把执行放到独立子进程使用timeout控制最大运行时间。需要说明的是这个沙箱只是教学级的。生产环境必须使用 Docker 容器、gVisor 或 Firecracker 等强隔离方案而不是只靠 AST 检查和子进程。后面常见问题部分会展开。4.3 环境生成器AI 自己出题环境生成器负责把“训练目标描述”转化为具体任务。如果不接大模型 API可以用模板随机化的方式先跑通流程。# 文件路径spade_demo/generator.py import random import uuid from typing import List from models import Task class TaskGenerator: 环境生成器根据难度参数生成代码任务 def __init__(self, template_pool: dict): self.template_pool template_pool def generate(self, difficulty: float, n: int 1) - List[Task]: tasks [] for _ in range(n): tid str(uuid.uuid4())[:8] description, reference_code self._make_task(difficulty) tasks.append(Task( task_idtid, descriptiondescription, reference_codereference_code, timeout5, difficultydifficulty, tags[math, code], )) return tasks def _make_task(self, difficulty: float): 根据难度生成题目与参考解 # 示例模板n 越大难度越高 n max(1, int(difficulty * 10)) description f请编写一个 Python 函数 sum_to_n(n)计算 1 到 n 的和。n {n} reference_code fdef sum_to_n(n):\n return n * (n 1) // 2 return description, reference_code这个实现为了演示故意做得很简单。真实项目中生成器通常会调用大模型根据指令生成更复杂的问题并附带单元测试。这里有一个关键点生成器生成的任务必须经过合法性校验。校验方式是在沙箱里执行参考解确认参考解能通过任务自带的测试。如果参考解本身跑不过这个任务就要丢弃。4.4 自对弈求解器AI 自己解题自对弈求解器负责接收任务并输出解题代码。在最小实现中我们可以用一个基于规则的“伪模型”来模拟解题过程。# 文件路径spade_demo/solver.py import random from typing import List from models import Task, ExecutionResult from sandbox import run_code class Solver: 自对弈求解器尝试解决生成器给出的任务 def __init__(self, strategy: str rule_based): self.strategy strategy def solve(self, task: Task) - List[ExecutionResult]: 返回一系列尝试执行的结果 # 实际项目中这里应该调用大模型生成代码 # 这里用规则模板 随机扰动来模拟不同水平的求解器 n None # 从问题描述中提取参数演示用 try: n int(task.description.split(n)[-1].strip().rstrip(.)) except Exception: n 5 candidates [ fdef sum_to_n(n):\n return sum(range(n 1)), fdef sum_to_n(n):\n return n * (n 1) // 2, fdef sum_to_n(n):\n total 0\n for i in range(1, n1):\n total i\n return total, ] results [] for code in candidates: # 用小规模的验证调用包装一下代码 full_code code f\n\nprint(sum_to_n({n})) result run_code(full_code, timeouttask.timeout) result.task_id task.task_id results.append(result) if result.return_code 0 and str(n * (n 1) // 2) in result.stdout: break return results求解器的实现同样是大模型接口的替身。真实场景中这里会调用代码生成模型根据任务描述产出候选代码并把执行结果作为上下文拼接回提示词让模型尝试修复错误——也就是 Agent 里的“自我调试”循环。4.5 轨迹评估器把执行结果变成学习信号评估器判断一次求解是否成功并计算奖励值。奖励值的计算直接影响进化质量。# 文件路径spade_demo/evaluator.py from typing import List from models import ExecutionResult, Trajectory, Task class Evaluator: 评估解题轨迹并计算奖励 def evaluate(self, task: Task, results: List[ExecutionResult]) - Trajectory: traj Trajectory(tasktask, attemptsresults) if not results: traj.final_status empty traj.reward 0.0 return traj last results[-1] passed last.return_code 0 if last.timed_out: traj.final_status timeout traj.reward -1.0 elif passed: # 奖励 基准 难度加成 - 耗时惩罚 duration_penalty min(last.duration_ms / 1000.0, 2.0) * 0.1 traj.final_status passed traj.reward 1.0 task.difficulty * 0.5 - duration_penalty else: traj.final_status failed traj.reward -0.5 return traj这个奖励公式有三个用意通过任务的奖励会随难度增长鼓励生成器挑战更难的问题超时得到负分约束求解器不要陷入死循环耗时惩罚鼓励更高效的解题方案。4.6 进化控制器动态调节难度进化控制器是整个框架的“大脑”。它观察最近几轮的通过率通过率高了就加大难度通过率低了就降低难度。# 文件路径spade_demo/evolution.py from collections import deque from evaluator import Evaluator from generator import TaskGenerator from solver import Solver class EvolutionController: 共进化控制器根据历史通过率动态调节难度 def __init__(self, generator: TaskGenerator, solver: Solver, evaluator: Evaluator): self.generator generator self.solver solver self.evaluator evaluator self.difficulty 0.3 self.history deque(maxlen10) self.trajectories [] def run_epoch(self, n_tasks: int 4): 运行一个进化周期 tasks self.generator.generate(self.difficulty, nn_tasks) epoch_results [] for task in tasks: # 合法性校验参考解必须能跑通 ref_result run_code(task.reference_code, timeouttask.timeout) if ref_result.return_code ! 0: continue # 自对弈求解器尝试解题 attempts self.solver.solve(task) traj self.evaluator.evaluate(task, attempts) self.trajectories.append(traj) epoch_results.append(traj) # 更新难度 if epoch_results: pass_rate sum(1 for t in epoch_results if t.final_status passed) / len(epoch_results) else: pass_rate 1.0 self.history.append(pass_rate) avg_pass sum(self.history) / len(self.history) if avg_pass 0.7: self.difficulty min(1.0, self.difficulty 0.1) elif avg_pass 0.3: self.difficulty max(0.1, self.difficulty - 0.1) return pass_rate, self.difficultyrun_epoch方法就是一次完整的“生成 → 校验 → 对抗 → 评估 → 进化”循环。通过率是调节难度的核心指标。这里使用的调节幅度和阈值都是可配置超参数。4.7 主启动入口最后把整个流程串起来。# 文件路径spade_demo/run.py from evolution import EvolutionController from evaluator import Evaluator from generator import TaskGenerator from solver import Solver def main(): template_pool {simple_sum: sum_to_n} generator TaskGenerator(template_pool) solver Solver(strategyrule_based) evaluator Evaluator() controller EvolutionController(generator, solver, evaluator) for epoch in range(20): pass_rate, difficulty controller.run_epoch(n_tasks4) print(fEpoch {epoch:02d} | pass_rate{pass_rate:.2f} | difficulty{difficulty:.2f} | history{len(controller.trajectories)}) print(\n训练轨迹数量:, len(controller.trajectories)) passed sum(1 for t in controller.trajectories if t.final_status passed) print(通过轨迹数量:, passed) if __name__ __main__: main()运行命令cd spade_demo python run.py预期输出示例实际输出可能因环境略有差异Epoch 00 | pass_rate1.00 | difficulty0.40 | history4 Epoch 01 | pass_rate1.00 | difficulty0.50 | history8 Epoch 02 | pass_rate1.00 | difficulty0.60 | history12 ... Epoch 19 | pass_rate0.75 | difficulty0.90 | history80 训练轨迹数量: 80 通过轨迹数量: 62在这个演示中因为求解器本身是规则模板能力固定所以随着难度上升通过率会逐步下降。而真实场景中求解器会在每轮训练后更新参数、变强从而在更高难度下保持通过率——这正是“共进化”的含义。5. 从“最小演示”走向“真实框架”关键差异点上面的代码能帮你理解 SPADE 的骨架但离真实可用还有较大距离。这一节列出落地时的主要差异。5.1 生成器和求解器要换成大模型调用最小演示里的生成器和求解器都是规则模板。真实场景中两者都需要调用大模型。生成器的提示词大致长这样你是一个训练任务生成器。请根据以下目标能力生成一个编程任务。 目标能力{capability_description} 当前难度{difficulty}0~11 为最难 任务要求 1. 问题描述清晰不需额外背景知识 2. 提供参考解和至少 3 组测试用例 3. 难度要与目标一致不要过于简单或复杂 请以 JSON 格式输出。求解器的提示词则是你是一个编程解题智能体。请解决下面的编程任务。 任务描述 {task_description} 你可以分步思考 1. 先说明解题思路 2. 再编写代码 3. 提交代码后如果运行失败请阅读报错并修正。 请输出完整的 Python 代码。关键差别在于真实求解器需要把前一次执行得到的 stderr、stdout 拼接回提示词让模型进行多轮自我调试而不是像演示里那样一次性生成固定候选。5.2 沙箱必须升级为容器级隔离教学演示中的subprocess沙箱无法对抗恶意代码。真实框架面对的是模型可能生成的任意代码包括尝试读文件、扫内网、发起网络请求的代码。生产级方案通常采用Docker 容器每个代码执行都启动一个一次性容器用完销毁seccomp AppArmor限制系统调用cgroup 资源限额限制 CPU、内存、网络无网络环境默认禁用网络只有确有必要时才开放白名单域名。安全边界的优先级永远高于功能完备性。代码执行环境一旦被攻破损失是不可控的。5.3 训练数据沉淀与去重要做足每一轮自对弈产生的轨迹最终要沉淀为训练集。这里很容易踩的坑是“数据无限增长模式单一”。实际项目里需要做去重相同任务、相似解法只保留代表性样本难度分层按通过率把轨迹分成 easy / medium / hard保证采样时三个档位都有答案校验只有通过评估器验证的轨迹才能进入训练集防止错误数据污染模型。5.4 自对弈不一定用同一个模型严格意义上的自对弈是同一模型的两个副本互相对抗。但工程上更常见的是生成器用一个模型或一个 prompt 策略求解器用另一个模型或同一个模型的不同温度设置。这样可以避免模型记住自己刚生成的答案保持对抗的有效性。6. 常见问题与排查思路在实现 SPADE 框架过程中下面几个问题出现频率最高我把现象、原因和解决思路整理成一张表。问题现象常见原因解决思路子进程执行永远不结束没有设置 timeout 或 timeout 失效统一用 subprocess.run(timeout) 并订阅超时信号生成代码包含import os被拦截AST 静态检查把 import 全部拦截按需求维护白名单仅允许安全模块自对弈通过率长期 100%难度没有动态提升检查进化控制器的难度更新逻辑通过率超过阈值必须调高难度通过率长期 0%训练信号为零生成器出题过难或任务本身不可解增加参考解校验步骤未通过校验的任务直接丢弃训练轨迹大量重复生成器模式坍缩总是生成同类问题增加多样性奖励对相似度过高的任务降权评估器只认“结果对”不认“过程好”奖励函数只看最后 return_code引入中间步骤正确性、首次尝试通过次数等过程指标生成器学会了“刷分”——出简单题骗奖励进化控制器只看通过率一个指标加入难度方差、新颖度、覆盖度等多维指标沙箱 CPU 被打满影响主进程子进程资源未限制使用 cgroup 或容器限制 CPU 和内存配额在实际排查时我建议遵循一个基本原则先确认任务生成是否合法再排查求解能力最后才怀疑进化策略。因为生成器一旦产出大量非法任务下游所有环节的统计都会失真。具体排查步骤可以用下面的 checklist抽样 20 条生成器产出的任务人工检查参考解是否能通过统计任务描述长度和参考解长度的分布确认没有异常坍缩检查求解器在固定任务集上的通过率确认基线能力是否正常查看单条 trajectory 的完整 attempts 列表确认报错类型是否有规律最后检查进化控制器的难度更新曲线看是否呈现锯齿状上升。如果难度曲线长期不上升问题大概率出在生成器——它没有能力生成更难的任务需要先提升生成器的指令遵循能力或扩充任务模板库。7. 最佳实践与工程建议7.1 安全与稳定性底线做任何和代码执行相关的框架安全边界永远排第一。我在自己的项目里会强制要求这几条默认拒绝所有外部网络请求。模型生成的代码如果需要访问网络必须显式声明并经过审批否则一律拒绝。每个执行任务有独立临时目录。任务执行完目录直接删除防止数据残留。执行环境无持久状态。每次执行都是全新环境避免上一次执行污染下一次。线程池 队列限流。防止多个任务同时执行拖垮主机。超时分级。单次执行超时、单任务总尝试超时、单 epoch 总时间预算三层都要有。7.2 数据质量优先于数据数量SPADE 框架理论上可以无限生成数据但低质量数据会把模型越训越偏。我建议在数据管道里加入三个质量关卡第一个关卡是任务合法性。任务必须通过参考解验证不合法直接丢弃。第二个关卡是任务新颖度。新任务与已有任务集合的相似度过高时降权或丢弃。可以用文本 embedding 相似度或测试用例覆盖率相似度来衡量。第三个关卡是轨迹质量。只有最终通过且路径合理的轨迹才能进入训练集。解题过程中存在明显“碰运气”行为的轨迹价值更低。7.3 进化指标要多维监控不要只盯通过率这一个指标。一个健康的 SPADE 训练过程应该同时监控以下几类指标指标类型具体指标反映的问题难度指标平均通过率、难度分布、P90 通过耗时难度是否在合理区间多样性指标任务文本相似度、测试用例覆盖度生成器是否模式坍缩过程指标首次尝试通过率、平均尝试次数、常见报错类型求解器的解题质量进化指标难度曲线斜率、通过率波动幅度进化是否稳定可持续如果难度曲线一路上升但通过率保持稳定说明进化是健康的。如果难度上去后通过率断崖式下跌说明生成器和求解器之间出现了“断层”需要降低调节步长或增加中间难度任务。7.4 实验追踪与可复现性SPADE 的可复现性比普通训练更难因为数据是动态生成的。我建议每次训练运行都要记录生成器提示词或模板的版本求解器模型的版本和超参数随机种子进化控制器的所有参数每一轮生成的任务 ID 列表。把“任务 ID 列表”单独存一份非常重要。这样即使后面想重新训练也能重建当时的任务集合验证某些结论是否是某个任务分布导致的。8. 总结与学习路线这篇文章把 SPADE 拆成了三个核心概念——可执行代码环境、自对弈、共进化框架并给出了一个完整的最小演示实现。你至少已经掌握了以下内容SPADE 解决的核心问题是“训练环境需要动态生成”而不是“模型在固定数据集上反复学习”可执行代码环境提供过程性反馈是框架的地基自对弈通过生成器和求解器持续对抗自动产生难度递进的训练样本共进化控制器调节难度防止“出题失衡”或“解题失衡”完整跑通了一套包含生成、校验、求解、评估、进化五个环节的最小代码。如果你想继续深入这个方向我建议你按下面的路线推进第一步把最小演示里的求解器替换成真正的大模型调用先不追求效率专注跑通“模型生成代码 → 执行 → 报错回填 → 再次尝试”的闭环。第二步把生成器也换成大模型并引入任务合法性校验让系统开始产生真正的新任务。第三步引入向量数据库或倒排索引做任务去重和多样性控制防止模式坍缩。第四步把沙箱升级为 Docker 容器隔离加入资源限额、无网络、临时目录清理等安全机制。第五步接入强化学习反馈把轨迹评估器输出的奖励信号用于策略优化形成真正的“训练闭环”。最后说一个我自己的经验不要在第一步就去追求“让模型通过自对弈变强”。先把“执行反馈”这个闭环做扎实再谈进化。如果代码执行环境不稳定、反馈信号有噪音后面所有进化策略都是在噪音上跳舞。反之只要执行反馈足够可靠哪怕进化策略简单一些系统也能持续产出有价值的训练数据。先把沙箱建稳再谈让 AI 自己变强。 SPADE框架：让AI在自建代码环境中自对弈进化，提升大模型推理能力
先花三分钟理解一个现象在过去两年的大模型训练里数据几乎都是“人工标注 → 清洗 → 喂给模型”的单向流程。模型学完一批数据能力提升但下一次训练又要等新的数据被标注出来。这个过程在数学推理、代码生成、工具调用这类需要“过程反馈”的场景里尤其吃力。因为人工标注不仅贵而且很难标注出“为什么这条路径错了”的过程性信号。SPADE 这个方向正是冲这个问题来的。它想做的事可以概括成一句话让 AI 自己生成训练环境并在环境里和自己对抗、持续进化。它把可执行代码环境、自对弈机制、共进化框架三者揉在一起形成一套不需要人工不断喂数据也能持续提升能力的训练范式。这篇文章会围绕 SPADE 做一次系统拆解。我们会先讲清楚它试图解决什么问题和三个核心概念再给出一套可运行的最小演示框架最后结合我的实际经验讲清楚如果要在自己的项目里落地这套思路哪些模块是必须的、哪些坑是躲不开的、哪些工程底线不能碰。无论你是做算法训练、Agent 应用开发还是对大模型训练框架感兴趣的同学这篇文章都能给你一套“能看懂、能复现、能扩展”的闭环参考。1. SPADE 是什么让模型在自建环境中持续进化想理解 SPADE先要接受一个和传统训练完全不同的前提训练环境不应该是固定不变的而应该由 AI 自己按需生成。1.1 为什么“静态数据集”撑不起复杂推理能力先看传统方案的问题。假设你要训练一个模型学会“根据自然语言生成 Python 代码并运行结果”。传统做法是准备一批自然语言问题描述请人工或更高阶模型写出参考答案代码拿这些问题和参考答案去微调模型。这套流程最大的痛点在于问题空间是封闭的。模型见过的题型是有限的。一旦遇到训练集里没有的问题分布能力就会明显掉档。更麻烦的是代码类任务非常依赖过程性反馈。错误代码的运行结果、报错信息、中间变量值这些信息在静态数据里很稀缺。模型很难通过“只看答案”学会“如何调试和重试”。SPADE 的思路则完全不同让模型先写代码生成训练问题再让另一个模型或同一个模型的不同策略去解决这些问题然后根据解决过程的反馈反过来优化生成器。问题空间是动态扩张的反馈信号是过程性的能力提升也就有了持续来源。1.2 三个核心概念速览SPADE 不是单一算法而是一个框架组合。它的三个支柱是概念一句话解释在大模型训练中扮演的角色可执行代码环境能真正运行代码、返回结果和报错的安全沙箱提供过程性反馈信号替代人工标注自对弈同一模型的不同策略相互对抗、彼此出题、彼此解题持续提供有难度梯度的训练样本共进化框架生成器出题方和求解器做题方交替提升防止训练数据停滞能力持续螺旋上升我把这三个概念再展开说一下。可执行代码环境是这套框架的地基。模型生成的代码必须被真正执行拿到 stdout、stderr、返回值、超时信息这些信号才构成“过程性奖励”。如果只是在文本层面模拟“这段代码大概能跑”框架就退回了静态数据模式失去了进化动力。自对弈机制借鉴了 AlphaGo 的思想但对象变成了代码问题。一个模型本体负责出题一个负责解题。出题方想方设法生成越来越难的问题解题方想方设法破解这些问题。两者在一轮轮对抗中都变得更强。共进化框架则保证“出题”和“解题”两个能力不会失衡。如果出题太难、解题方永远解不出学习信号就消失了如果题目太简单、解题方轻松满分出题方也得不到有效反馈。共进化的核心是动态难度调节让题目永远保持在“跳一跳够得着”的区间。1.3 SPADE 和普通 Agent 的区别这里容易产生一个混淆SPADE 中的“模型生成代码并执行”看起来很像 Agent 应用但两者目标完全不同。普通 Agent 应用关注的是“完成任务”例如让它查天气、订机票、写报告。它吃的是用户给的输入输出是任务结果。SPADE 关注的是“让模型变强”。它的产物不是业务结果而是高质量的训练数据、可学习的难度阶梯、可复现的推理路径。换句话说Agent 是在用模型能力解决任务SPADE 是在解决任务的过程中顺便训练出更强的模型。这个区别决定了工程实现方式完全不同。SPADE 框架需要额外考虑数据沉淀、轨迹评估、难度调节、策略迭代这些都是传统 Agent 工程不太敏感的问题。2. SPADE 框架的整体架构设计2.1 框架组成的五个核心模块一个完整的 SPADE 框架通常可以拆成五个模块模块职责关键点环境生成器根据目标能力生成训练任务控制任务难度、多样性和合法性代码执行沙箱运行生成的代码并返回反馈安全限制、超时控制、资源隔离自对弈求解器尝试解决生成的任务提供解题轨迹暴露薄弱环节轨迹评估器评估解题质量并生成奖励信号区分“结果对”和“过程好”进化控制器根据反馈更新生成策略和求解策略动态调节难度防止模式坍缩环境生成器是框架的“出题大脑”。它接收一个高层的目标描述例如“训练模型理解递推关系”然后生成一系列从易到难的任务。任务可以是自然语言描述、可执行的断言、单元测试或者半成品代码模板。代码执行沙箱是安全边界。它负责在隔离环境里运行代码捕获标准输出、错误信息、运行耗时。这个模块最大的挑战不是“能跑”而是“安全地跑”。后面我会详细讲沙箱的设计底线。自对弈求解器是解题方。它通常是一个已经具备基础代码能力的模型接收生成器给出的问题输出解题代码并提交到沙箱执行。解题成功与否、路径是否正确这些信息都会被记录下来。轨迹评估器负责把原始运行结果转化为可学习的信号。同一个问题一次 AC通过和一次 TLE超时对应的训练价值完全不同。好的评估器能把这种差异量化。进化控制器是协调者。它会记录最新几轮生成器的出题难度分布、求解器的通过率并据此调整后续生成策略。如果通过率长期低于 20%就降低难度如果连续多轮通过率接近 100%就提升难度。2.2 一次完整的进化循环SPADE 的训练循环可以用下面的流程描述1. 初始化准备一个基础求解器、一套基础任务模板 2. 生成环境生成器根据目标描述生成 N 个新任务 3. 隔离验证在沙箱中运行任务自带的参考解确认任务本身可解 4. 对抗求解器逐个尝试解决这些任务 5. 评估记录通过率、耗时、错误类型、解题轨迹多样性 6. 反馈进化控制器根据评估结果调整生成器参数 7. 沉淀把高质量的(任务, 解题轨迹, 反馈)三元组加入训练集 8. 迭代用更新后的求解器继续下一轮注意第 3 步很多人会忽略。生成器自己生成的任务必须先由“参考解”验证一遍防止生成出本身就有问题的任务。这一步叫做“任务合法性校验”是保证数据质量的生命线。2.3 为什么“可执行环境”是 SPADE 的关键如果不用可执行环境只靠文本生成任务和答案整个框架会退化成“模型自己给自己出选择题”没有任何新增信息量。可执行环境提供了三类关键信号第一类是正确性信号。代码跑通、输出与预期一致这是最直接的信号。没有它模型的“自我感觉正确”没有任何意义。第二类是调试信号。报错信息、堆栈轨迹、部分通过的测试用例这些信号比“正确/错误”更细腻。模型可以从中学习“为什么错、错在哪里、如何修正”。第三类是难度信号。一个任务求解器花了大量 token 才通过说明它超出了当前能力舒适区这正是最有训练价值的样本。静态数据集很难自动标出这种难度信息。3. 环境准备与最小化依赖在动手写代码之前先把运行环境准备好。这一节我以常见环境为例版本号需根据你的实际情况调整重点讲清楚依赖的理由。3.1 基础运行环境推荐使用 Linux 或 macOS 作为开发环境。Windows 也可以但在沙箱子进程管理和信号处理上会遇到更多兼容问题。如果你只有 Windows建议用 WSL2。操作系统Ubuntu 20.04 及以上或 macOS 12编程语言Python 3.9 及以上包管理工具pip 或 poetry代码解释器本机 Python 解释器用于沙箱执行3.2 Python 依赖清单下面是一个最小依赖清单。注意这里没有写死版本号因为 SPADE 相关库迭代较快你可以安装最新稳定版。# requirements.txt # SPADE 最小演示框架依赖 # 版本按当前环境最新稳定版安装即可 python-dotenv1.0 pydantic2.0 typer0.9如果后面需要接入大模型 API 做生成器和求解器还需要根据实际选择的模型服务商安装对应 SDK。这里先不展开。安装命令pip install -r requirements.txt3.3 项目目录结构我建议按模块化方式组织代码方便后续扩展。spade_demo/ ├── requirements.txt ├── config.py # 全局配置超时、最大 token 等 ├── models.py # 数据结构定义 ├── sandbox.py # 代码执行沙箱 ├── generator.py # 环境生成器 ├── solver.py # 自对弈求解器 ├── evaluator.py # 轨迹评估器 ├── evolution.py # 进化控制器 主循环 └── run.py # 启动入口这个结构把“生成、执行、求解、评估、进化”五个模块拆开职责清晰。后面每个模块的核心代码都会对应到具体文件。4. 核心模块代码拆解下面的代码是一个教学级最小实现。它不是为了达到生产级性能而是为了把 SPADE 的关键机制讲清楚。你在复现时需要根据自己的模型接口和环境做调整。4.1 数据结构定义先定义框架中流转的核心数据结构。建议用 Pydantic 做数据校验避免脏数据在模块间传播。# 文件路径spade_demo/models.py from typing import List, Optional from pydantic import BaseModel, Field class Task(BaseModel): 一个由生成器产出的训练任务 task_id: str description: str # 自然语言问题描述 reference_code: str # 参考解代码用于验证任务本身可解 timeout: int 5 # 执行超时时间秒 difficulty: float 0.5 # 生成器预估的难度 0~1 tags: List[str] Field(default_factorylist) class ExecutionResult(BaseModel): 一次代码执行的结果 task_id: str code: str stdout: str stderr: str return_code: int 0 timed_out: bool False duration_ms: int 0 class Trajectory(BaseModel): 一条完整的解题轨迹 task: Task attempts: List[ExecutionResult] Field(default_factorylist) final_status: str pending # passed / failed / timeout / error reward: float 0.0 # 评估器给出的奖励信号Task是生成器和求解器之间的“语言”。ExecutionResult记录每一次执行的真实反馈。Trajectory是最终沉淀到训练集里的数据单元。4.2 安全沙箱代码执行的核心沙箱是最需要谨慎对待的模块。教学演示中我们至少要做到三件事限制危险操作、限制执行时间、限制资源消耗。# 文件路径spade_demo/sandbox.py import ast import subprocess import sys import time from typing import List from models import ExecutionResult # 禁止出现在生成代码中的危险节点类型 _FORBIDDEN_NODES ( ast.Import, ast.ImportFrom, ast.Global, ast.Nonlocal, ast.Call, # 需要二次检查函数名这里先由 _check_forbidden_call 处理 ) def _check_forbidden_call(node: ast.Call) - bool: 检查是否调用了危险函数 if isinstance(node.func, ast.Name): if node.func.id in {exec, eval, compile, __import__, open}: return True if isinstance(node.func, ast.Attribute): if node.func.attr in {system, popen, subprocess}: return True return False def validate_code(code: str) - List[str]: 静态检查代码是否包含高危操作返回违规描述列表 violations [] try: tree ast.parse(code) except SyntaxError: return [syntax error] for node in ast.walk(tree): if isinstance(node, _FORBIDDEN_NODES): violations.append(fforbidden node: {type(node).__name__}) if isinstance(node, ast.Call) and _check_forbidden_call(node): violations.append(fforbidden call: {ast.dump(node)}) return violations def run_code(code: str, timeout: int 5) - ExecutionResult: 在子进程中执行代码并返回结构化结果 start time.time() try: proc subprocess.run( [sys.executable, -c, code], capture_outputTrue, textTrue, timeouttimeout, env{PYTHONPATH: , PATH: /usr/bin:/bin}, cwd/tmp, ) return ExecutionResult( task_id, codecode, stdoutproc.stdout, stderrproc.stderr, return_codeproc.returncode, timed_outFalse, duration_msint((time.time() - start) * 1000), ) except subprocess.TimeoutExpired: return ExecutionResult( task_id, codecode, stdout, stderrtimeout, return_code-1, timed_outTrue, duration_msint((time.time() - start) * 1000), ) except Exception as e: # noqa: BLE001 return ExecutionResult( task_id, codecode, stdout, stderrstr(e), return_code-2, timed_outFalse, duration_msint((time.time() - start) * 1000), )这段代码做了两层防护。第一层通过ast静态分析把import、eval、open这类高风险操作直接拦截。第二层通过subprocess把执行放到独立子进程使用timeout控制最大运行时间。需要说明的是这个沙箱只是教学级的。生产环境必须使用 Docker 容器、gVisor 或 Firecracker 等强隔离方案而不是只靠 AST 检查和子进程。后面常见问题部分会展开。4.3 环境生成器AI 自己出题环境生成器负责把“训练目标描述”转化为具体任务。如果不接大模型 API可以用模板随机化的方式先跑通流程。# 文件路径spade_demo/generator.py import random import uuid from typing import List from models import Task class TaskGenerator: 环境生成器根据难度参数生成代码任务 def __init__(self, template_pool: dict): self.template_pool template_pool def generate(self, difficulty: float, n: int 1) - List[Task]: tasks [] for _ in range(n): tid str(uuid.uuid4())[:8] description, reference_code self._make_task(difficulty) tasks.append(Task( task_idtid, descriptiondescription, reference_codereference_code, timeout5, difficultydifficulty, tags[math, code], )) return tasks def _make_task(self, difficulty: float): 根据难度生成题目与参考解 # 示例模板n 越大难度越高 n max(1, int(difficulty * 10)) description f请编写一个 Python 函数 sum_to_n(n)计算 1 到 n 的和。n {n} reference_code fdef sum_to_n(n):\n return n * (n 1) // 2 return description, reference_code这个实现为了演示故意做得很简单。真实项目中生成器通常会调用大模型根据指令生成更复杂的问题并附带单元测试。这里有一个关键点生成器生成的任务必须经过合法性校验。校验方式是在沙箱里执行参考解确认参考解能通过任务自带的测试。如果参考解本身跑不过这个任务就要丢弃。4.4 自对弈求解器AI 自己解题自对弈求解器负责接收任务并输出解题代码。在最小实现中我们可以用一个基于规则的“伪模型”来模拟解题过程。# 文件路径spade_demo/solver.py import random from typing import List from models import Task, ExecutionResult from sandbox import run_code class Solver: 自对弈求解器尝试解决生成器给出的任务 def __init__(self, strategy: str rule_based): self.strategy strategy def solve(self, task: Task) - List[ExecutionResult]: 返回一系列尝试执行的结果 # 实际项目中这里应该调用大模型生成代码 # 这里用规则模板 随机扰动来模拟不同水平的求解器 n None # 从问题描述中提取参数演示用 try: n int(task.description.split(n)[-1].strip().rstrip(.)) except Exception: n 5 candidates [ fdef sum_to_n(n):\n return sum(range(n 1)), fdef sum_to_n(n):\n return n * (n 1) // 2, fdef sum_to_n(n):\n total 0\n for i in range(1, n1):\n total i\n return total, ] results [] for code in candidates: # 用小规模的验证调用包装一下代码 full_code code f\n\nprint(sum_to_n({n})) result run_code(full_code, timeouttask.timeout) result.task_id task.task_id results.append(result) if result.return_code 0 and str(n * (n 1) // 2) in result.stdout: break return results求解器的实现同样是大模型接口的替身。真实场景中这里会调用代码生成模型根据任务描述产出候选代码并把执行结果作为上下文拼接回提示词让模型尝试修复错误——也就是 Agent 里的“自我调试”循环。4.5 轨迹评估器把执行结果变成学习信号评估器判断一次求解是否成功并计算奖励值。奖励值的计算直接影响进化质量。# 文件路径spade_demo/evaluator.py from typing import List from models import ExecutionResult, Trajectory, Task class Evaluator: 评估解题轨迹并计算奖励 def evaluate(self, task: Task, results: List[ExecutionResult]) - Trajectory: traj Trajectory(tasktask, attemptsresults) if not results: traj.final_status empty traj.reward 0.0 return traj last results[-1] passed last.return_code 0 if last.timed_out: traj.final_status timeout traj.reward -1.0 elif passed: # 奖励 基准 难度加成 - 耗时惩罚 duration_penalty min(last.duration_ms / 1000.0, 2.0) * 0.1 traj.final_status passed traj.reward 1.0 task.difficulty * 0.5 - duration_penalty else: traj.final_status failed traj.reward -0.5 return traj这个奖励公式有三个用意通过任务的奖励会随难度增长鼓励生成器挑战更难的问题超时得到负分约束求解器不要陷入死循环耗时惩罚鼓励更高效的解题方案。4.6 进化控制器动态调节难度进化控制器是整个框架的“大脑”。它观察最近几轮的通过率通过率高了就加大难度通过率低了就降低难度。# 文件路径spade_demo/evolution.py from collections import deque from evaluator import Evaluator from generator import TaskGenerator from solver import Solver class EvolutionController: 共进化控制器根据历史通过率动态调节难度 def __init__(self, generator: TaskGenerator, solver: Solver, evaluator: Evaluator): self.generator generator self.solver solver self.evaluator evaluator self.difficulty 0.3 self.history deque(maxlen10) self.trajectories [] def run_epoch(self, n_tasks: int 4): 运行一个进化周期 tasks self.generator.generate(self.difficulty, nn_tasks) epoch_results [] for task in tasks: # 合法性校验参考解必须能跑通 ref_result run_code(task.reference_code, timeouttask.timeout) if ref_result.return_code ! 0: continue # 自对弈求解器尝试解题 attempts self.solver.solve(task) traj self.evaluator.evaluate(task, attempts) self.trajectories.append(traj) epoch_results.append(traj) # 更新难度 if epoch_results: pass_rate sum(1 for t in epoch_results if t.final_status passed) / len(epoch_results) else: pass_rate 1.0 self.history.append(pass_rate) avg_pass sum(self.history) / len(self.history) if avg_pass 0.7: self.difficulty min(1.0, self.difficulty 0.1) elif avg_pass 0.3: self.difficulty max(0.1, self.difficulty - 0.1) return pass_rate, self.difficultyrun_epoch方法就是一次完整的“生成 → 校验 → 对抗 → 评估 → 进化”循环。通过率是调节难度的核心指标。这里使用的调节幅度和阈值都是可配置超参数。4.7 主启动入口最后把整个流程串起来。# 文件路径spade_demo/run.py from evolution import EvolutionController from evaluator import Evaluator from generator import TaskGenerator from solver import Solver def main(): template_pool {simple_sum: sum_to_n} generator TaskGenerator(template_pool) solver Solver(strategyrule_based) evaluator Evaluator() controller EvolutionController(generator, solver, evaluator) for epoch in range(20): pass_rate, difficulty controller.run_epoch(n_tasks4) print(fEpoch {epoch:02d} | pass_rate{pass_rate:.2f} | difficulty{difficulty:.2f} | history{len(controller.trajectories)}) print(\n训练轨迹数量:, len(controller.trajectories)) passed sum(1 for t in controller.trajectories if t.final_status passed) print(通过轨迹数量:, passed) if __name__ __main__: main()运行命令cd spade_demo python run.py预期输出示例实际输出可能因环境略有差异Epoch 00 | pass_rate1.00 | difficulty0.40 | history4 Epoch 01 | pass_rate1.00 | difficulty0.50 | history8 Epoch 02 | pass_rate1.00 | difficulty0.60 | history12 ... Epoch 19 | pass_rate0.75 | difficulty0.90 | history80 训练轨迹数量: 80 通过轨迹数量: 62在这个演示中因为求解器本身是规则模板能力固定所以随着难度上升通过率会逐步下降。而真实场景中求解器会在每轮训练后更新参数、变强从而在更高难度下保持通过率——这正是“共进化”的含义。5. 从“最小演示”走向“真实框架”关键差异点上面的代码能帮你理解 SPADE 的骨架但离真实可用还有较大距离。这一节列出落地时的主要差异。5.1 生成器和求解器要换成大模型调用最小演示里的生成器和求解器都是规则模板。真实场景中两者都需要调用大模型。生成器的提示词大致长这样你是一个训练任务生成器。请根据以下目标能力生成一个编程任务。 目标能力{capability_description} 当前难度{difficulty}0~11 为最难 任务要求 1. 问题描述清晰不需额外背景知识 2. 提供参考解和至少 3 组测试用例 3. 难度要与目标一致不要过于简单或复杂 请以 JSON 格式输出。求解器的提示词则是你是一个编程解题智能体。请解决下面的编程任务。 任务描述 {task_description} 你可以分步思考 1. 先说明解题思路 2. 再编写代码 3. 提交代码后如果运行失败请阅读报错并修正。 请输出完整的 Python 代码。关键差别在于真实求解器需要把前一次执行得到的 stderr、stdout 拼接回提示词让模型进行多轮自我调试而不是像演示里那样一次性生成固定候选。5.2 沙箱必须升级为容器级隔离教学演示中的subprocess沙箱无法对抗恶意代码。真实框架面对的是模型可能生成的任意代码包括尝试读文件、扫内网、发起网络请求的代码。生产级方案通常采用Docker 容器每个代码执行都启动一个一次性容器用完销毁seccomp AppArmor限制系统调用cgroup 资源限额限制 CPU、内存、网络无网络环境默认禁用网络只有确有必要时才开放白名单域名。安全边界的优先级永远高于功能完备性。代码执行环境一旦被攻破损失是不可控的。5.3 训练数据沉淀与去重要做足每一轮自对弈产生的轨迹最终要沉淀为训练集。这里很容易踩的坑是“数据无限增长模式单一”。实际项目里需要做去重相同任务、相似解法只保留代表性样本难度分层按通过率把轨迹分成 easy / medium / hard保证采样时三个档位都有答案校验只有通过评估器验证的轨迹才能进入训练集防止错误数据污染模型。5.4 自对弈不一定用同一个模型严格意义上的自对弈是同一模型的两个副本互相对抗。但工程上更常见的是生成器用一个模型或一个 prompt 策略求解器用另一个模型或同一个模型的不同温度设置。这样可以避免模型记住自己刚生成的答案保持对抗的有效性。6. 常见问题与排查思路在实现 SPADE 框架过程中下面几个问题出现频率最高我把现象、原因和解决思路整理成一张表。问题现象常见原因解决思路子进程执行永远不结束没有设置 timeout 或 timeout 失效统一用 subprocess.run(timeout) 并订阅超时信号生成代码包含import os被拦截AST 静态检查把 import 全部拦截按需求维护白名单仅允许安全模块自对弈通过率长期 100%难度没有动态提升检查进化控制器的难度更新逻辑通过率超过阈值必须调高难度通过率长期 0%训练信号为零生成器出题过难或任务本身不可解增加参考解校验步骤未通过校验的任务直接丢弃训练轨迹大量重复生成器模式坍缩总是生成同类问题增加多样性奖励对相似度过高的任务降权评估器只认“结果对”不认“过程好”奖励函数只看最后 return_code引入中间步骤正确性、首次尝试通过次数等过程指标生成器学会了“刷分”——出简单题骗奖励进化控制器只看通过率一个指标加入难度方差、新颖度、覆盖度等多维指标沙箱 CPU 被打满影响主进程子进程资源未限制使用 cgroup 或容器限制 CPU 和内存配额在实际排查时我建议遵循一个基本原则先确认任务生成是否合法再排查求解能力最后才怀疑进化策略。因为生成器一旦产出大量非法任务下游所有环节的统计都会失真。具体排查步骤可以用下面的 checklist抽样 20 条生成器产出的任务人工检查参考解是否能通过统计任务描述长度和参考解长度的分布确认没有异常坍缩检查求解器在固定任务集上的通过率确认基线能力是否正常查看单条 trajectory 的完整 attempts 列表确认报错类型是否有规律最后检查进化控制器的难度更新曲线看是否呈现锯齿状上升。如果难度曲线长期不上升问题大概率出在生成器——它没有能力生成更难的任务需要先提升生成器的指令遵循能力或扩充任务模板库。7. 最佳实践与工程建议7.1 安全与稳定性底线做任何和代码执行相关的框架安全边界永远排第一。我在自己的项目里会强制要求这几条默认拒绝所有外部网络请求。模型生成的代码如果需要访问网络必须显式声明并经过审批否则一律拒绝。每个执行任务有独立临时目录。任务执行完目录直接删除防止数据残留。执行环境无持久状态。每次执行都是全新环境避免上一次执行污染下一次。线程池 队列限流。防止多个任务同时执行拖垮主机。超时分级。单次执行超时、单任务总尝试超时、单 epoch 总时间预算三层都要有。7.2 数据质量优先于数据数量SPADE 框架理论上可以无限生成数据但低质量数据会把模型越训越偏。我建议在数据管道里加入三个质量关卡第一个关卡是任务合法性。任务必须通过参考解验证不合法直接丢弃。第二个关卡是任务新颖度。新任务与已有任务集合的相似度过高时降权或丢弃。可以用文本 embedding 相似度或测试用例覆盖率相似度来衡量。第三个关卡是轨迹质量。只有最终通过且路径合理的轨迹才能进入训练集。解题过程中存在明显“碰运气”行为的轨迹价值更低。7.3 进化指标要多维监控不要只盯通过率这一个指标。一个健康的 SPADE 训练过程应该同时监控以下几类指标指标类型具体指标反映的问题难度指标平均通过率、难度分布、P90 通过耗时难度是否在合理区间多样性指标任务文本相似度、测试用例覆盖度生成器是否模式坍缩过程指标首次尝试通过率、平均尝试次数、常见报错类型求解器的解题质量进化指标难度曲线斜率、通过率波动幅度进化是否稳定可持续如果难度曲线一路上升但通过率保持稳定说明进化是健康的。如果难度上去后通过率断崖式下跌说明生成器和求解器之间出现了“断层”需要降低调节步长或增加中间难度任务。7.4 实验追踪与可复现性SPADE 的可复现性比普通训练更难因为数据是动态生成的。我建议每次训练运行都要记录生成器提示词或模板的版本求解器模型的版本和超参数随机种子进化控制器的所有参数每一轮生成的任务 ID 列表。把“任务 ID 列表”单独存一份非常重要。这样即使后面想重新训练也能重建当时的任务集合验证某些结论是否是某个任务分布导致的。8. 总结与学习路线这篇文章把 SPADE 拆成了三个核心概念——可执行代码环境、自对弈、共进化框架并给出了一个完整的最小演示实现。你至少已经掌握了以下内容SPADE 解决的核心问题是“训练环境需要动态生成”而不是“模型在固定数据集上反复学习”可执行代码环境提供过程性反馈是框架的地基自对弈通过生成器和求解器持续对抗自动产生难度递进的训练样本共进化控制器调节难度防止“出题失衡”或“解题失衡”完整跑通了一套包含生成、校验、求解、评估、进化五个环节的最小代码。如果你想继续深入这个方向我建议你按下面的路线推进第一步把最小演示里的求解器替换成真正的大模型调用先不追求效率专注跑通“模型生成代码 → 执行 → 报错回填 → 再次尝试”的闭环。第二步把生成器也换成大模型并引入任务合法性校验让系统开始产生真正的新任务。第三步引入向量数据库或倒排索引做任务去重和多样性控制防止模式坍缩。第四步把沙箱升级为 Docker 容器隔离加入资源限额、无网络、临时目录清理等安全机制。第五步接入强化学习反馈把轨迹评估器输出的奖励信号用于策略优化形成真正的“训练闭环”。最后说一个我自己的经验不要在第一步就去追求“让模型通过自对弈变强”。先把“执行反馈”这个闭环做扎实再谈进化。如果代码执行环境不稳定、反馈信号有噪音后面所有进化策略都是在噪音上跳舞。反之只要执行反馈足够可靠哪怕进化策略简单一些系统也能持续产出有价值的训练数据。先把沙箱建稳再谈让 AI 自己变强。