大模型训练推进到今天卡点已经慢慢从“算力不够”转移到了“题从哪来”。大家训练出来的模型往往在公开榜单上分数不错一放到真实业务场景里就露馅代码写不出来、工具调用不会、复杂任务一拆就乱。原因并不复杂——我们的训练数据是静态的评测环境是静态的连强化学习里的人类反馈也是滞后且昂贵的。换句话说模型在“一套固定的卷子”里反复刷题自然很难在开放世界里真正变强。“SPADE”这一类思路就是从根上换了一套玩法让 AI 自己生成训练环境自己出题自己判卷然后在可执行代码环境里进行自对弈和共进化。这句话听起来有点科幻但背后的技术逻辑非常实在——它解决的是大模型训练里最贵的两个环节高质量数据获取和多样化评测环境构建。如果这条路线能走通模型就不再只是被动地吃人类喂的语料而是能主动地、持续地创造自己的训练场。这篇文章我会围绕 SPADE 拆开讲清楚四件事它到底要解决什么痛点核心机制是什么与传统强化学习/RLHF 训练范式有哪些本质区别以及如果你想动手实现一个最小可运行的“自对弈共进化”系统应该怎么写代码、会遇到哪些坑、怎么做好工程化兜底。1. SPADE 到底在解决什么问题先看当前大模型训练里三个非常现实的瓶颈。第一高质量监督数据开始枯竭。过去几年模型能力的提升很大程度靠的是海量人类高质量标注数据。但这条路越来越贵也越走越窄。人工写一条高质量指令样本要数分钟甚至数小时成本高、质量不稳定而且人类数据总有覆盖不到的长尾场景。很多团队已经发现靠堆数据量带来的收益在明显递减。第二RLHF 依赖的人类反馈是“滞后反馈”。RLHF 的训练范式是模型生成多个回答人类标注员对回答排序打分再通过 PPO 等算法把奖励信号压回模型。这个流程有几个问题标注成本高人类对复杂任务很难给出稳定、准确的偏好反馈周期长模型改一轮要等很久。尤其在代码生成、数学推理这类“对就是对、错就是错”的任务上让人类去排序远不如直接跑一下测试用例来得客观。第三评测环境和真实任务脱节。传统评测集是静态的模型练到最后很容易“背题”。哪怕题目没见过静态评测也无法覆盖模型在开放环境里可能遇到的组合性问题。更麻烦的是智能体 AI 要面对的往往不是“给你一道题你写个答案”而是“给你一个环境你自己拆解任务、调用工具、试错、修正”。这样的能力静态数据集根本评测不出来更别说拿来训练。SPADE 的核心价值就是同时瞄准这三个瓶颈。它让模型自己生成可执行的代码环境也就是能真正跑起来、有输入输出、有判定逻辑的环境再在这个环境里让模型自对弈——一个角色出题另一个角色解题然后通过执行代码来客观判定对错最后让环境和模型一起迭代形成共进化。这样一来训练数据的产生、验证、反馈三个环节都能自动化而且反馈信号来自代码执行结果不是来自人类的模糊偏好客观性、覆盖率、实时性都上了一个台阶。所以说SPADE 不是一个小技巧而是一套“数据飞轮 评测飞轮”自动化的训练范式。对于做智能体 AI、大模型后训练、模型评估的同学来说这是绕不开的方向。2. 三个核心概念可执行代码环境、自对弈、共进化要理解 SPADE必须先弄明白三个词可执行代码环境、自对弈、共进化。它们不是并列关系而是层层递进的关系。2.1 可执行代码环境先说什么叫“可执行代码环境”。传统数据集是一堆文本样本比如“问题和答案的配对”。模型读完就完事了它无法验证自己的答案对不对。可执行代码环境则不同它是一段可以被运行、被检查的代码逻辑定义了某个任务领域的规则、输入输出格式、判定标准。举个例子。你想要一个“四则运算出题环境”传统做法是人工写 1000 道算式题。用可执行环境的方式你只需要写一个 Python 函数def generate_expression(level: int): # 根据难度生成一个四则运算表达式 pass def evaluate_expression(expression: str, answer: str) - bool: # 执行表达式并判断答案是否正确 pass环境本身并不包含 1000 道题它只提供“生成题”和“判定答案”的能力。SPADE 里的智能体就是通过生成这样的环境代码把“出题”这件事也自动化了。关键点在于环境必须是可执行的不能只是描述性的文本。如果环境不能执行就没有客观的判定信号自对弈就无从谈起。这也是“可执行代码环境”在 SPADE 里如此重要的原因——它是整个反馈回路的地基。2.2 自对弈自对弈这个词很多人第一次听到是在 AlphaGo 那里。AlphaGo 没有拿人类棋谱对练而是让两个版本的模型互相下棋一局一局地生成更多棋局数据再从中学习。整个过程中棋力提升靠的不是外部老师而是“左右互搏”产生的新挑战。SPADE 的自对弈把这个思想从围棋棋盘搬到了代码环境和智能体任务里。模型的一个角色负责生成任务出题者另一个角色负责在环境里完成任务解题者。出题者会刻意提高难度、增加干扰、构造边界情况解题者则不断尝试突破。两者互相逼迫共同变强。自对弈最妙的地方在于它不依赖外部数据源。数据是在博弈过程中“无中生有”地涌现出来的。这正是解决高质量数据枯竭问题的一种可行路径。2.3 共进化共进化是比自对弈更深一层的概念。自对弈强调的是同一个模型的两个副本在对抗共进化强调的是“模型”和“环境”两个对象一起迭代。想象一下如果只有一个固定环境模型再自对弈也会很快饱和。它把所有可能性都摸透了就没有进步空间了。所以 SPADE 里的环境不是静态的它会根据模型的当前水平不断调整——太难了模型跟不上就降难度太简单了模型轻易答对就出更复杂的题。环境本身像是一个“有生命”的教练而不是一张死卷子。模型在变强环境也在变复杂环境变复杂又反过来逼模型更强。这就是共进化的含义。把三个概念串起来看可执行代码环境是博弈发生的舞台自对弈是博弈的方式共进化是博弈带来的长期结果。三者的关系可以这样理解没有可执行环境就没有客观判定没有自对弈就没有持续的数据生成没有共进化就有会模型瓶颈模型练到某个水平就再也上不去。3. SPADE 与传统训练范式的对比说清楚了概念我们再把它放进整个大模型训练范式演进的时间线里看看 SPADE 到底处在什么位置。训练范式数据来源反馈信号环境是否动态主要瓶颈有监督指令微调SFT人类人工标注人类正确答案否标注成本高长尾覆盖不足RLHF / PPO模型生成 人类排序人类偏好奖励模型否人工反馈滞后复杂任务难以稳定AlphaGo 式自对弈模型自我博弈游戏胜负等客观规则固定规则规则简单明确难以迁移到开放任务SPADE 式共进化环境生成 模型自对弈代码执行结果环境动态调节是环境生成质量、安全性、模式坍塌从这张表能看到一个清晰的趋势数据来源从“人工”走向“自动”反馈从“主观”走向“客观”环境从“静态”走向“动态”。SPADE 基本站在这条演进路线的终端。但这里要强调一个容易误解的地方SPADE 不是要替代 RLHF 或 SFT而是可以作为它们的上游数据引擎。SPADE 持续产出的“任务-过程-结果”三元组经过筛选和质量控制完全可以变成 SFT 的高质量语料SPADE 的可执行环境也可以直接作为强化学习的环境接口变成一个“永不枯竭”的 RL 训练场。更稳妥的判断是SPADE 更适合作为一种数据与评估生成层叠加在传统训练流程之上而不是彻底推翻现有流程。4. SPADE 的工作流程拆解理解了概念我们来拆一个具体的 SPADE 循环。它通常由四类角色组成环境生成器、任务生成器、求解器、验证器。再加上一个难度调节器来控制共进化的节奏。4.1 环境生成器让 AI 写环境代码环境生成器的输入是一个高层领域描述输出是一段可执行的代码环境。例如给模型一个描述“设计一个 Python 函数式题目环境考察循环和条件判断。”环境生成器就会生成对应的题目生成函数和答案判定函数。环境生成器是整个流程的第一个环节它的质量直接决定了后面所有环节的上限。如果环境本身有 bug或者判定逻辑写得有问题那自对弈产生的数据就是垃圾数据。所以环境生成器产生的代码通常还要经过一层静态检查和基础用例冒烟测试。4.2 任务生成器在环境里出题环境有了接下来要出具体题目。任务生成器会把环境代码作为上下文调用大模型生成具体的题目实例。比如环境是“四则运算”任务生成器就会生成“3 5 × 2 ?”这样的具体问题。不同的难度档位会生成不同复杂度的题目。4.3 求解器让模型去解题求解器就是我们要训练的目标模型。它接收任务生成器给出的题目尝试给出答案。如果是代码生成任务求解器要写出能通过测试用例的代码如果是推理任务求解器要给出最终结果。自对弈的机制在这里体现为任务生成器和求解器可以是同一个基座模型的不同角色配置。一个模型既会出题又会被考这不矛盾反而逼着模型从“出题人视角”理解知识的边界和难点。4.4 验证器用执行结果说话验证器负责把求解器的回答放进可执行环境里实际运行返回通过/失败结果。这里强调“执行”而非“人工判定”原因前面说过代码执行结果是客观的不依赖于人类的偏好和标注一致性。验证结果会形成训练样本进入下一轮训练。通过的数据可以作为正样本失败的样本也很有价值——它可以被回灌给任务生成器用来评估这道题出的“质量”是否合理或者被改造为难度等级样本。4.5 难度调节器让进化持续进行难度调节器是共进化的核心。它维护一个“模型当前能力水平”的评估值动态调整任务生成器的难度参数。模型正确率太高就调高难度正确率太低就调低难度。类似游戏里的动态难度系统保证模型始终处在“有点挑战但又不至于崩溃”的学习区间。完整循环如下环境生成器写出一段可执行环境代码任务生成器基于环境出题求解器尝试解题验证器执行代码并给出判定难度调节器根据判定结果调整后续出题难度将产生的有效样本回流到模型训练数据池训练后的新一轮模型再次进入流程环境根据需要更新换代。这个循环一旦跑起来就是一个持续产生数据的自动飞轮。理论上只要沙箱资源足够模型可以 24 小时不停自我进化。5. 最小实现一个可运行的 SPADE 循环这一节我们用代码演示一个最小可运行的 SPADE 雏形。目标是跑通“环境生成 → 出题 → 解题 → 验证 → 难度调节”这条链路。代码以 Python 示例核心思路可以直接迁移到你的实际项目。5.1 环境生成器示例假设我们希望模型生成“函数式编程”类练习环境。下面这段代码是环境生成器输出的结果它定义了一个简单的题目环境生成一个 Python 练习题要求模型实现一个函数并通过单元测试验证。# 文件路径generated_env/function_env.py # 这是环境生成器为“函数实现题”生成的动态环境 import random import ast GENERATED_PROBLEM_COUNT 0 def generate_task(difficulty: int) - dict: 根据难度生成一道函数实现题 global GENERATED_PROBLEM_COUNT GENERATED_PROBLEM_COUNT 1 # 不同难度对应不同的函数要求 if difficulty 1: # 简单求和函数 func_name fsum_list_{GENERATED_PROBLEM_COUNT} body return sum(data) test_cases [ ([1, 2, 3], 6), ([], 0), ([-1, 10, 5], 14), ] description f给定整数列表 data实现函数 {func_name}返回所有元素之和。 elif difficulty 2: # 中等去重再排序 func_name funique_sorted_{GENERATED_PROBLEM_COUNT} body return sorted(set(data)) test_cases [ ([3, 1, 2, 1, 3], [1, 2, 3]), ([], []), ([5, 5, 5], [5]), ] description f给定整数列表 data实现函数 {func_name}返回去重并升序排序后的新列表。 else: # 困难动态规划题由环境生成器随机构造 func_name fdp_max_sub_{GENERATED_PROBLEM_COUNT} body return max_subarray_sum(data) test_cases [ ([-2, 1, -3, 4, -1, 2, 1, -5, 4], 6), ([1], 1), ([-1, -2, -3], -1), ] description f给定整数数组 data实现函数 {func_name}返回和最大的连续子数组的和。 problem_statement ( f{description}\n f请只输出函数代码不要额外解释。\n f函数名{func_name}\n f函数签名def {func_name}(data): ) return { func_name: func_name, problem_statement: problem_statement, expected_body: body, test_cases: test_cases, difficulty: difficulty, } def evaluate_answer(task: dict, answer_code: str) - dict: 通过执行测试用例验证模型生成的函数是否正确 try: func_name task[func_name] namespace {} exec(answer_code, namespace) if func_name not in namespace: return {passed: False, error: 函数未定义} func namespace[func_name] for input_data, expected in task[test_cases]: actual func(input_data) if actual ! expected: return {passed: False, error: f输入 {input_data} 期望 {expected} 实际 {actual}} return {passed: True, error: None} except Exception as e: return {passed: False, error: str(e)}这个文件虽然是手工演示但它已经具备可执行环境的核心特征能生成题目、能验证答案、且验证过程依赖真实代码运行。5.2 任务生成与求解的调度代码接着是调度代码。它负责调用环境、调模型出题解题、收集结果。实际项目中大模型的推理调用通常走 OpenAI 兼容接口或本地部署的推理服务这里用函数封装便于替换。# 文件路径spade_loop.py import random from generated_env.function_env import generate_task, evaluate_answer class LLMClient: 大模型调用封装实际项目请替换为真实推理接口 def generate_task(self, env_desc: str, difficulty: int) - str: # 这里用环境模块直接生成题目实际项目中由大模型基于环境代码补全 task generate_task(difficulty) return task def solve_task(self, problem_statement: str) - str: # 实际项目调用目标模型prompt problem_statement, 返回模型补全的代码 # 这里返回一个可配置的示例实现仅演示调度逻辑 if unique_sorted in problem_statement: return def unique_sorted(data):\n return sorted(set(data)) if sum_list in problem_statement: return def sum_list(data):\n return sum(data) return def dp_max_sub(data):\n if not data: return 0\n cur best data[0]\n for x in data[1:]:\n cur max(x, cur x)\n best max(best, cur)\n return best def run_self_play_episode(llm: LLMClient, difficulty: int): # 1. 生成任务 task llm.generate_task(函数实现题环境, difficulty) # 2. 模型解题 answer_code llm.solve_task(task[problem_statement]) # 3. 代码执行验证 result evaluate_answer(task, answer_code) return { task: task, answer_code: answer_code, result: result, difficulty: difficulty, } def dynamic_difficulty(history): 难度调节器根据最近一轮通过率调整难度 if len(history) 5: return 1 recent history[-5:] pass_rate sum(1 for r in recent if r[result][passed]) / len(recent) if pass_rate 0.8: return min(3, recent[-1][difficulty] 1) if pass_rate 0.3: return max(1, recent[-1][difficulty] - 1) return recent[-1][difficulty] def main(): llm LLMClient() history [] difficulty 1 for episode in range(20): result run_self_play_episode(llm, difficulty) history.append(result) print(fepisode {episode:02d} | difficulty{difficulty} | fpassed{result[result][passed]} | error{result[result][error]}) difficulty dynamic_difficulty(history) if __name__ __main__: main()注意这段代码里 LLMClient 的 solve_task 是硬编码返回这不是“模型自己在解题”而是为了演示调度和验证流程。实际项目中你需要把 solve_task 替换为真实目标模型的推理调用。这一步非常关键否则你跑起来的是一个假自对弈循环。5.3 用提示词代替硬编码的求解客户端上面代码最需要替换的部分就是 solve_task。实际项目里一般会用类似下面的 OpenAI 兼容接口让真正的大模型来解题# 文件路径spade_loop.py真实求解器替换版 import openai client openai.OpenAI( base_urlhttp://localhost:8000/v1, # 本地部署的推理服务 api_keyEMPTY, ) class RealLLMClient: def __init__(self, model_nameqwen2.5-7b-instruct): self.model_name model_name def solve_task(self, problem_statement: str) - str: resp client.chat.completions.create( modelself.model_name, messages[ { role: system, content: 你是一个 Python 编程助手。只输出函数代码不要解释。, }, { role: user, content: problem_statement, }, ], temperature0.2, max_tokens512, ) return resp.choices[0].message.content这样你就把整个循环里最核心的“解题者”换成了真实模型。真正跑 SPADE 循环时第 6 节说的难度调节和数据回流也都需要在这个基础上扩展。6. 让进化真正发生难度自适应与多样性保护如果只是让模型生成任务、再自己解题这个循环很可能跑一段时间就“退化”了。最常见的现象是模型学会了针对自己常见弱点出简单题自对弈产生的数据越来越同质化模型能力停滞。这需要从两个维度来兜底。第一个维度是难度自适应。前面代码里的 dynamic_difficulty 是一个最简单的实现但实际项目里更推荐用 ELO 评分或基于能力模型的动态难度曲线。每个任务实例都对应一个难度分模型解题正确率会更新这个分数。任务生成器在采样题目时优先选取难度分在“最近发展区”的题目——也就是模型目前正确率在 30% 到 70% 之间的区间。这个区间是最能促进学习的。第二个维度是多样性保护。自对弈系统特别容易陷入“模式坍塌”出题器只出某一类题解题器也只会做某一类题两边达成一个虚假的低维平衡。解决办法通常是在任务生成时引入多样性目标函数比如对生成任务做聚类同一簇的任务在一个批次里只允许出现一定比例或者直接用 embedding 计算新任务与已有任务的相似度过滤掉过于相似的任务。还有一个在工程上很有效的做法把失败样本也收集起来。模型解错题目不代表这题没用。恰恰相反模型反复出错的题目就是最宝贵的训练信号。可以把这类样本标记为“hard negative”用于后续的困难样本增强训练。7. 适用场景与使用边界SPADE 并不是万能的。它依赖一个前提任务可以在可执行代码环境里被自动验证。符合这个前提的领域SPADE 会非常强不符合的领域强行套用只会产生一堆自嗨的假指标。适用场景特点原因代码生成与程序修复有编译器、单测、静态检查判定标准客观环境易构建数学与逻辑推理有标准答案可公式验证自对弈可以产生大量推理样本策略类游戏 AI有胜率、得分等明确指标AlphaGo 已经验证过这条路自动化测试用例生成代码覆盖率、断言结果可量化生成器和验证器天然匹配数据清洗与 ETL 任务输入输出可通过脚本验证环境代码实现成本低不适用场景原因主观审美类任务无法用代码执行客观判定需要人类打分内容安全与价值观对齐依赖人类价值判断全自动自对弈存在失控风险高风险决策场景模型生成环境的错误可能被放大必须有人审查一个常见的误区是看到 SPADE 能自动生成环境就觉得它可以替代人工对齐。这个判断是危险的。SPADE 擅长的是提升“客观能力”而安全对齐、价值观对齐这类任务依赖人类的规范和判断不能被全自动循环替代。在实际工程中SPADE 产生的数据仍然需要经过规则过滤和人工抽检再进入训练管线。8. 常见问题与排查思路下面是我从这类自对弈框架的工程实践中总结出的常见问题按出现频率排序。问题现象可能原因排查方式解决方案自对弈跑了很多轮模型能力不增长难度调节失效题目一直在舒适区打印各难度档位的通过率曲线实现基于 ELO 的动态难度评分生成的任务高度重复缺少多样性约束对任务文本做 embedding 聚类统计增加相似度过滤和多样性奖励环境代码有 bug导致大量错误判定环境生成器输出质量低对每个生成环境先跑一组冒烟用例增加环境质量校验层失败环境直接重生成求解器严重依赖格式才能得分验证器判定过于宽松检查测试用例覆盖度增加边界测试和隐藏测试用例训练数据里混入大量错误样本验证器没能拦截失败结果抽样人工审查增加规则过滤和人工抽检模型只做简单题逃避挑战难度调节收敛到低难度统计难度分布设置最低难度基线排查这类系统有一个原则先验证环境再验证模型。如果环境本身不可靠那后面所有“模型进化”的结论都是空谈。因此在跑大规模循环之前应该先抽检环境生成器的输出确保它生成的环境代码在语法、逻辑、边界条件上都是可用的。9. 工程化落地的核心建议如果要在真实项目中落地一个 SPADE 式的自对弈共进化系统下面几条工程经验值得提前想清楚。第一沙箱安全是第零优先级。模型生成的代码要在你的机器上执行这就意味着你正在运行不可信代码。必须在隔离容器、受限用户、资源限额、网络断开的沙箱里执行。执行超时要主动杀掉内存要限制文件系统要只读或临时。任何让你“先跑通再补安全”的想法都要警惕——模型生成的代码能做的事超出你最初的预期。第二环境生成需要独立的质量关卡。不能信任环境生成器输出的第一版代码。比较稳妥的做法是每个生成环境先跑一组由人类预置的最小冒烟测试语法错误直接丢弃重生成同时设置“环境通过率”指标低于阈值时让环境生成器参考失败日志迭代修复。第三数据回流之前必须做过滤。自对弈产生的数据量可能非常大但绝不是所有数据都能进训练池。建议统一的过滤管线验证器通过的部分检查答案多样性、去重、过滤低质量格式验证器失败的部分单独打标签为 hard negative不直接丢弃但也别直接作为正样本。整条管线要有数据血缘记录方便追溯每个样本是由哪个环境、哪个出题器、哪个求解器生成的。第四混合反馈比纯自动反馈更稳。SPADE 的自动执行反馈能覆盖客观正确性但模型在生成过程中的代码风格、注释质量、模块化程度这类软性指标自动验证覆盖不到。建议在 SPADE 全自动循环之外保留一个小批量的人类反馈通道周期性地对生成样本进行抽审和质量标注再把抽审结果作为奖励模型的辅助信号。这样既保持了自动化的效率又不至于完全丢掉人类偏好。第五算力和存储要提前规划。自对弈循环是 7×24 小时运行的模型推理、沙箱执行、日志存储都会消耗大量资源。经验上的建议是动态控制每个时间片的对弈局数失败样本和任务日志要定期归档避免无限制堆积。第六把 SPADE 当“训练数据工厂”而不是端到端训练系统。不要指望跑一个 SPADE 脚本就能得到一个完整可用的强模型。更现实的组合方式是SPADE 持续产出高质量训练样本 → 这些样本经过过滤和混入人类数据 → 用于 SFT 或 RLHF 训练 → 训练后的模型回到 SPADE 中继续自对弈。这也是它被放在“大模型后训练”和“智能体 AI 训练”两个热词下讨论的原因——它解决的是持续进化环节而不是从头训练环节。10. 总结与下一步建议SPADE 所代表的“可执行代码环境 自对弈共进化”本质上是给大模型训练装上一个“数据与评测自动飞轮”。它把传统训练里最贵的人工出题、人工标注、人工评测三个环节替换成基于代码执行结果的自动化闭环。对做智能体 AI、代码模型、大模型后训练的团队来说这个方向是真正能落地、也值得投入的。如果你想自己动手探索可以从一个最小闭环开始用一个大模型接口生成题目环境再调用同一个模型解题用代码执行结果做判定然后用动态难度控制进化节奏。先跑通这条链路再逐步加入多样性保护、质量过滤、沙箱安全、数据回流。不要一开始就追求大规模先用小循环验证“数据可以自动产生、质量可以自动判定”这两个核心假设是否成立。SPADE 当然不是终点。它自身的模式坍塌问题、环境评估偏差问题、安全对齐缺口都还没有完美的答案。但对于所有正在被“数据不够、标注太贵、评估不准”困扰的团队来说它提供了一条极有潜力的出路让 AI 在它自己创造的世界里不断和自己交锋变得越来越强。这正是智能体 AI 演进过程中最值得跟踪的方向之一。建议收藏这篇文章后续可以沿着“环境生成质量评估”“自对弈数据多样性”“可执行环境安全沙箱”这几个方向继续深入。