先花三分钟理解一个现象：在过去两年的大模型训练里，数据几乎都是“人工标注 → 清洗 → 喂给模型”的单向流程。模型学完一批数据，能力提升，但下一次训练又要等新的数据被标注出来。这个过程在数学推理、代码生成、工具调用这类需要“过程反馈”的场景里尤其吃力。因为人工标注不仅贵，而且很难标注出“为什么这条路径错了”的过程性信号。
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-dotenv>=1.0 pydantic>=2.0 typer>=0.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_factory=list) 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_factory=list) 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(f"forbidden node: {type(node).__name__}") if isinstance(node, ast.Call) and _check_forbidden_call(node): violations.append(f"forbidden 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_output=True, text=True, timeout=timeout, env={"PYTHONPATH": "", "PATH": "/usr/bin:/bin"}, cwd="/tmp", ) return ExecutionResult( task_id="", code=code, stdout=proc.stdout, stderr=proc.stderr, return_code=proc.returncode, timed_out=False, duration_ms=int((time.time() - start) * 1000), ) except subprocess.TimeoutExpired: return ExecutionResult( task_id="", code=code, stdout="", stderr="timeout", return_code=-1, timed_out=True, duration_ms=int((time.time() - start) * 1000), ) except Exception as e: # noqa: BLE001 return ExecutionResult( task_id="", code=code, stdout="", stderr=str(e), return_code=-2, timed_out=False, duration_ms=int((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_id=tid, description=description, reference_code=reference_code, timeout=5, difficulty=difficulty, 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 = f"def 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 = [ f"def sum_to_n(n):\n return sum(range(n + 1))", f"def sum_to_n(n):\n return n * (n + 1) // 2", f"def sum_to_n(n):\n total = 0\n for i in range(1, n+1):\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, timeout=task.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(task=task, attempts=results) 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(maxlen=10) self.trajectories = [] def run_epoch(self, n_tasks: int = 4): """运行一个进化周期""" tasks = self.generator.generate(self.difficulty, n=n_tasks) epoch_results = [] for task in tasks: # 合法性校验：参考解必须能跑通 ref_result = run_code(task.reference_code, timeout=task.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(strategy="rule_based") evaluator = Evaluator() controller = EvolutionController(generator, solver, evaluator) for epoch in range(20): pass_rate, difficulty = controller.run_epoch(n_tasks=4) print(f"Epoch {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_rate=1.00 | difficulty=0.40 | history=4 Epoch 01 | pass_rate=1.00 | difficulty=0.50 | history=8 Epoch 02 | pass_rate=1.00 | difficulty=0.60 | history=12 ... Epoch 19 | pass_rate=0.75 | difficulty=0.90 | history=80 训练轨迹数量: 80 通过轨迹数量: 62在这个演示中，因为求解器本身是规则模板，能力固定，所以随着难度上升，通过率会逐步下降。而真实场景中，求解器会在每轮训练后更新参数、变强，从而在更高难度下保持通过率——这正是“共进化”的含义。
5. 从“最小演示”走向“真实框架”：关键差异点
上面的代码能帮你理解 SPADE 的骨架，但离真实可用还有较大距离。这一节列出落地时的主要差异。
5.1 生成器和求解器要换成大模型调用
最小演示里的生成器和求解器都是规则模板。真实场景中两者都需要调用大模型。
生成器的提示词大致长这样：
你是一个训练任务生成器。请根据以下目标能力生成一个编程任务。 目标能力：{capability_description} 当前难度：{difficulty}（0~1，1 为最难） 任务要求： 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 自己变强。
