每次提到“让AI自己生成训练环境”，大部分人的第一反应都是科幻感。SPADE 这个名字听起来也很像那种“一夜之间模型就会自己进化”的项目，但实际上，它强调的并不是单一模型变得更强，而是另一件事：用可执行代码环境加上自对弈共进化，把过去完全靠人工整理和标注的训练数据，变成模型自己生成、自己验证、自己迭代的闭环。这个方向的野心很大，但真正落地时，难点不在“AI自动生成环境”这八个字，而在环境是否可执行、任务难度是否可控、整个闭环能不能稳定跑下去。
如果只看表面，SPADE 解决的像是“让AI自己给自己出题”。但把它拆开看，它真正想改变的，是训练环境中成本最高、最不可缩放的那部分：人类对任务的设计、筛选和排序。可是这里容易出现一个误解：以为只要把“出题”交给大模型，就万事大吉。实际不是。生成一个看起来合理的环境代码，和生成一个可执行、可评分、难度适中的训练环境，完全是两码事。这篇文章我想围绕SPADE这类框架，讲清楚它背后的机制、真正值得做的地方，以及把它落到工程里时最容易翻车的几个环节。
1. 先想清楚一个问题：训练环境的瓶颈，为什么比模型结构更早出现
1.1 静态数据和人工任务，撑不起持续进化
过去几年大模型训练的主流路径，是“先收集一批高质量数据，再让模型拟合这些数据”。这种思路在特定任务上非常有效，但它有一个天然上限：数据是静态快照。你不可能靠一份固定数据集，让智能体学会应对它从来没有见过的边界情况。
尤其是做智能体AI时，问题会更明显。智能体需要在一个环境里持续决策：观察状态、选择动作、获得反馈、修正策略。如果训练时只是一堆静态的指令问答，模型学会的是“如何回答”，而不是“如何在环境中通过行动达成目标”。这也是为什么越来越多的项目会把可执行代码环境引入训练：只有在一个能真正运行、能返回状态、能给出奖励的环境里，智能体才能获得真实的交互信号。
但引入环境又带来了新问题：环境是谁写的？如果是人来写，那瓶颈又回到了原点。一个复杂任务环境，往往包含状态定义、动作空间、终止条件、奖励函数、异常处理，写起来比写几万条训练样本还要费劲。SPADE这类框架的出发点，就是把这个“人工写环境”的环节自动化。
这里需要先分清一个概念：可执行代码环境不只是一个Python脚本，它应该具备三个基本特征：
- 能够被运行，并能返回明确的当前状态。
- 能够根据智能体的动作改变状态。
- 能够输出一个可量化的结果，用来判断任务是否完成、完成质量如何。
只有满足这三条，环境才能被当作训练信号源。否则，就算生成了一堆代码，也只是悬空文本。
1.2 从“给定数据训练”到“生成环境训练”
SPADE 的核心不是某一个模型，而是一套循环。这个循环里至少有两个角色：一个是负责做任务的智能体，一个是负责生成任务环境的生成器。两者交替更新，互相给对方提出更难、更有区分度的挑战。
这种思路并不新。自对弈在棋类AI里早就被验证过：AlphaGo和AlphaZero就是让模型不断和自己对弈，棋谱和策略同时进化，最终超越人类棋谱的覆盖范围。SPADE的特别之处在于，它把“棋盘”也变成了可以生成的对象。也就是说，不只是策略在进化，游戏规则本身也在进化。
这就是“共进化”三个字的含义。它不是简单的数据增广，也不只是让智能体自己和自己打，而是让环境生成器和策略模型形成一个彼此牵引的竞争关系：
- 智能体太强，环境生成器就要生成更难的任务。
- 环境生成器生成的题目太难，智能体一直失败，训练就失去梯度，这时又得退回难度更低的题目。
这个动态平衡，是整个框架里最难把握的地方。很多人把 SPADE 理解为“让AI自己写很多训练题”，但只写题不够，还要保证题的难度和当前模型能力匹配。否则训练信号无效，模型要么记住捷径，要么完全学不会。
注意：判断一个训练环境有没有价值，不能只看“能不能运行”，要看它是否落在模型当前能力区的边缘。太简单的任务只会让模型退化，太难的任务会让模型从头到尾拿不到正反馈。
2. SPADE 这类框架的工作机制：三个子系统怎么咬合
2.1 子系统A：可执行代码环境生成器
环境生成器是整个框架的起点。它接收一个任务目标，输出一份环境代码。这份代码不是人类直接使用的，而是给智能体跑交互用的。
举一个最简单的例子，假设我们要训练一个能完成“字符串处理”的智能体。环境生成器可能先定义一个任务：
- 环境初始状态：一段乱序的字符串。
- 智能体动作：调用若干字符串处理函数。
- 终止条件：输出满足排序规则。
- 奖励：输出与目标完全一致得1分，部分匹配得0.5分。
看起来很简单，但真正实现时，生成器输出的代码必须能被执行。也就是说，它需要有一整套检查流程：先静态检查代码，再放进沙箱运行，最后用自带测试用例验证环境本身是否合理。
这里最容易出现的问题是：生成的代码能跑，但测试太弱。比如环境生成了一个排序任务，测试函数却只检查了输出长度，没有检查元素顺序。智能体很快就会发现这个漏洞，然后学会用一段错误但能拿满分的策略。这种情况在真实项目里非常常见，而且越是灵活的生成器，越容易产生这类“看起来合理、实际不可用”的环境。
所以，环境生成器通常需要配备一个“验证器”。验证器要完成四件事：
- 代码能否在指定环境里正常执行。
- 环境是否存在可解路径。
- 难度是否和当前智能体能力匹配。
- 奖励信号是否足够稠密，不会让智能体完全拿不到反馈。
从工程经验看，验证器才是这个子系统的核心。生成器的随机性决定环境多样性，验证器决定这些环境能不能进入训练流水线。
2.2 子系统B：智能体和策略模型
智能体就是那个在环境里“做任务”的模型。它接收环境状态，输出动作，循环往复，最后根据奖励更新策略。
在 SPADE 这类框架里，智能体的训练信号不只有“是否完成任务”，还包括更细的维度：
- 任务完成率，也就是在整个任务池里能解出多少环境。
- 轨迹效率，也就是完成一个任务需要多少步。
- 稳定性，也就是同一个任务多次运行，结果是否一致。
- 泛化性，也就是没见过的环境是否也能有还算不错的表现。
如果只看任务完成率，智能体很容易走捷径。比如它可能只记住环境生成器的代码习惯，而不是真正理解任务本质。所以训练时，通常会把轨迹长度和探索多样性也纳入奖励。
不过，我对智能体训练部分的建议是：不要一开始就想着设计复杂的奖励函数，先尽量把环境做好。环境质量决定了信号质量，信号质量决定了模型能学到什么。一个糟糕的奖励设计，往往是在给错误的环境打分，打再多次也不会变对。
2.3 子系统C：自对弈和共进化调度
共进化调度器是串起所有组件的胶水。它要做的事情包括：
- 决定每一轮生成多少新环境。
- 判断哪些环境应该保留、哪些应该淘汰。
- 控制任务难度，让智能体始终停留在“跳一跳够得着”的状态。
- 记录每一次生成、训练、评估的结果，方便回溯。
一个通用的 SPADE 主循环，用伪代码看长这样：
# 简化后的共进化主循环，用于说明结构，不是 SPADE 官方实现 task_pool = [] agent = load_checkpoint("agent_v1") gen = load_checkpoint("env_gen_v1") for round in range(100): # 1. 环境生成器采样新任务 specs = gen.sample(n=20, target_difficulty="auto") # 2. 对每个新环境做可执行性验证 valid_envs = [] for spec in specs: env = build_env(spec) if env.is_executable() and env.has_viable_solution(): valid_envs.append(env) # 3. 让智能体在有效环境里试跑 results = [] for env in valid_envs: reward, trace = agent.rollout(env) results.append({"env": env, "reward": reward, "trace": trace}) # 4. 只保留对训练有帮助的任务 selected = select_curriculum(results, target_success=0.6) # 5. 用被选中的任务更新智能体 agent = train(agent, selected) # 6. 每隔几轮，根据智能体现有水平更新环境生成器 if round % 10 == 0: gen = update_env_gen(gen, agent.get_stats())这段伪代码省略了很多细节，但它体现了 SPADE 真正重要的一个特征：生成环境、验证环境、智能体训练、环境生成器更新，每一步都在同一个闭环里做版本管理。没有这个闭环，它就是一个普通的“AI写代码工具”，而不是共进化框架。
这里有个容易被忽略的点：环境生成器和智能体是交替更新的，不是同时更新。如果两边同时变化，训练过程会非常不稳定，最后你很难判断模型的提升到底来自策略进步，还是单纯因为任务变简单了。
3. 真要落地 SPADE，需要哪几步？
3.1 先跑通最小闭环，而不是一上来部署大集群
很多人在看到一个类似 SPADE 的框架后，第一反应是“赶紧部署一套，让它自己跑几天”。这个冲动可以理解，但实际落地时，我更建议从一个非常窄的领域开始。
什么叫窄领域？比如：
- 只做文本编辑类任务，不让它做网页操作。
- 只做命令行指令生成，不让它做多步骤规划。
- 只做 JSON 数据转换，不让它处理非结构化文档。
选择窄领域有两个原因。第一，环境验证规则更容易定义；第二，智能体失败时更容易定位是环境问题还是策略问题。
最小闭环可以按以下顺序跑：
- 手工写好 3 到 5 个示例任务环境。
- 让环境生成器模仿这些示例，再生成 10 个变体。
- 用验证器检查这 10 个变体，看看可执行率和有效完成率。
- 让智能体在 10 个变体上试跑，记录奖励和日志。
- 把日志喂回训练流程，更新一次策略。
- 检查智能体在“人工保留的测试环境”上的表现，确认它没有过拟合到生成器的输出风格。
第 6 步非常关键。如果你只在新生成的环境上评估，很多时候看到的结果是假的，因为环境生成器和智能体可能一起走偏了。保留一小批人工验证过的测试环境，相当于给整个共进化过程装了一块“稳定参照物”。
3.2 关键参数和环境隔离
SPADE 类框架涉及的参数很多，但刚开始你不需要调整所有参数，先把下面这几个理解透：
| 参数 | 作用 | 落地建议 |
|---|---|---|
| 环境生成数量 | 每一轮向任务池注入多少新任务 | 先设 10 到 20，不要一上来就几百个 |
| 任务难度阈值 | 决定哪些任务进入训练集 | 先看智能体当前成功率，选 40% 到 80% 区间的任务 |
| 环境重试次数 | 生成器生成无效环境后允许重试几次 | 建议 2 到 3 次，超过就放弃，避免死循环 |
| 智能体训练步数 | 每一轮更新策略时用多少步 | 先跑小步数，确认整个链路稳定后再扩大 |
| 环境生成器更新频率 | 每隔多少轮更新一次生成器 | 一般比智能体更新频率低，比如智能体每轮更新，生成器每 10 轮更新 |
| 沙箱超时时间 | 智能体在单个环境里最多运行多久 | 从 10 秒到 60 秒起步，防止代码卡死 |
环境隔离是另一个绝对不能跳过的事。可执行代码环境意味着智能体真的会执行代码，而代码一旦有随机性或不可控操作，就可能影响到训练进程。常见做法是把每个环境放进独立容器或独立进程，限制 CPU、内存、磁盘和时间。
如果之前没有容器化经验，也可以先从最轻量的方案做起：用子进程加超时终止，同时限制输出大小。只要代码不能访问宿主文件系统和网络，就能挡住大部分风险。
3.3 数据、日志和版本管理
训练类项目最怕的不是跑不起来，而是跑起来之后看不懂结果。SPADE 这类框架因为涉及两条进化线，数据管理变得尤其重要。
我建议每个训练环境都记录一份结构化元数据：
- 环境唯一ID。
- 生成时使用的任务描述和生成参数。
- 环境代码的完整内容。
- 是否通过可执行性验证。
- 智能体在该环境上的奖励、轨迹长度、完成状态。
- 该环境被选中进入训练集的时间点和原因。
有了这些记录，你才能回答三个问题：
- 智能体能力提升，是环境变简单了还是策略真变强了？
- 某一次训练突然发散，是不是因为环境生成器产生了一批异常任务？
- 如果环境生成器退化，能不能快速回滚到上一版生成器？
版本管理不只是给模型存 checkpoint，更要给“环境生成器”和“任务池”单独做版本。一个环境从生成、验证、训练到淘汰，最好有完整生命周期记录。这件事一开始做会显得繁琐，但如果不做，等整个任务池膨胀到几万条时，排查问题的成本会高到失控。
4. 最容易翻车的四个地方，和一套排查顺序
4.1 环境生成了，但不可执行或无法判定
这是整个框架里出现概率最高的坑。表面现象是：智能体训练时 reward 一直很低，或者 loss 不降。很多人第一反应是调模型参数，但实际上问题可能出在环境本身。
我见过的常见现象包括：
- 环境代码能运行，但测试用例没覆盖关键条件，导致智能体使用漏洞轻松拿分。
- 环境代码本身有随机性，同一个动作在不同时刻返回不同结果，导致奖励信号不稳定。
- 任务难度太高，智能体永远失败，训练梯度长时间不变。
- 环境生成器生成大量高度相似的任务，任务池虽然很大，但多样性极低。
这些现象都会让整个训练看起来“没问题但没进展”。定位方法也很简单：先看环境日志，而不是先看模型指标。
这里给你一套适合 SPADE 类框架的排查链路：
- 先看环境生成日志：最近100次生成里，有多少环境能通过编译/执行？如果可执行率低于 80%，优先优化生成器或验证器。
- 再看环境质量分布：生成出来的任务，难度分数是一条均匀曲线，还是集中在“过于简单”或“过于困难”两个极端？
- 再看智能体试跑结果：在有效环境里，智能体的平均奖励是在逐步上升，还是一直贴在地板上？
- 再看调度日志：当前被选中的任务主要来自哪个时间段？如果大多来自前几轮，说明环境生成器已经停止产出有价值的新任务。
- 最后看数据版本：把最近一次训练前后的人工测试集结果对比，如果人工测试集没有提升，即使任务池指标在涨，也要怀疑过拟合。
按这个顺序排查，90% 的问题都能定位到某一个子系统，而不是盲目调参。
4.2 这个框架不适合谁，适合谁
SPADE 听起来很强大，但它不是所有场景的银弹。你必须先确认自己想要解决的问题能不能被形式化验证。
适合用这类框架的场景，通常有几个共同点：
- 任务结果可以被程序判定，比如代码是否通过测试、JSON 格式是否合法、策略返回值是否符合规则。
- 环境状态转换是确定的，至少是可以模拟的。
- 你愿意投入工程成本去维护沙箱、日志、验证器和任务池。
不适合的场景也很明显：
- 如果你的任务依赖大量主观判断，比如“这篇文章写得是否流畅”，SPADE 就没有用武之地。这类任务无法用可执行环境给出客观奖励。
- 如果你只是想让 AI 在单个任务上表现更好，直接用人工数据训练更划算。
- 如果你的团队没有运维或基础架构支持，一上来就做容器化、并发训练，会消耗大量时间。
这个框架真正的长期价值，在于它把“训练数据生产”变成了一条可持续运行的流水线。但代价是，你需要同时维护两条进化线的质量。这比维护一个固定数据集，复杂度至少要高一个量级。
4.3 先跑通，再优化，最后才谈“自动化进化”
最后再说一点我的真实感受。SPADE 这类“自对弈共进化”框架，听起来很像那种“模型自己关在机房里跑几个月，出来一个超人智能体”的东西。但从工程实践看，它更像一条需要不断人工监控的生产线。
你仍然需要：
- 定期人工检查新生成的环境，确认没有语义偏差。
- 保留固定测试集，监控智能体是否发生能力退化。
- 给任务池设置清理和淘汰策略，防止无效环境越积越多。
- 对生成器、智能体、任务池分别做版本存档。
所以，如果问我推不推荐尝试这种方向，我会说：推荐，但请从一个小闭环开始。先选择一类非常窄的任务，比如“把自然语言需求转成可执行的 SQL 查询”，然后跑通环境生成、验证、训练、回测四个环节。等这条路稳定了，再逐步扩大任务范围、提高环境复杂度。
进化的前提不是环境无限生成，而是每一步都能被观察、被验证、被回滚。这才是 SPADE 这类框架真正值得长期投入的地方。
如果你正在做智能体训练，并且不断被“人工写任务、人工调难度、人工筛数据”拖住，那我建议你认真把“可执行代码环境”和“自对弈共进化”放在一起考虑。它们不会一次性解决所有问题，但会把你从“不停造数据”的循环里拉出来，让你把精力放在更值得做的事情上：设计验证规则、监控训练质量、判断模型什么时候该升级、什么时候该重置。
这件事可能不像“AI一夜之间自己进化”那么炫目，但它才是让框架稳定跑下去的底座。
