Todo sistema de RL con recompensa verificable para agentes de lenguaje choca con la misma pared: el conjunto de entornos deja de crecer. Las tareas curadas manualmente se agotan; las sintetizadas estáticamente congelan la distribución de objetivos en el momento de la creación; los pipelines con verificadores congelados no pueden adaptarse una vez que el modelo supera la tarea preestablecida más difícil. SPADE, publicado en arXiv el 19 de agosto por un equipo de 18 autores de UW, CMU y colaboradores, ataca ese cuello de botella al fusionar el diseñador de entorno y el agente razonador en una política compartida.

Un único LLM desempeña dos roles. Como Environment Designer, escribe programas Python completos—MDPs ejecutables con interfaces reset()/step(), transiciones de estado, funciones de recompensa y código de verificación—fundamentados en pasajes de un corpus de preentrenamiento y una memoria acumulada de entornos generados previamente. Como Reasoning Agent, recorre esos programas. Ambos roles actualizan una política compartida vía GRPO; no hay modelo separado de diseñador ni de agente.

La señal de recompensa previene el colapso a través del arrepentimiento basado en pistas: la brecha entre el rendimiento del episodio del agente con una pista privilegiada y sin ella. El arrepentimiento alto marca la frontera de aprendizaje—tareas que el agente resuelve con ayuda pero no solo. El arrepentimiento bajo más rendimientos altos marcan dominio; el arrepentimiento bajo más rendimientos bajos marcan un entorno intratable por el que el diseñador es penalizado. Esta distinción de tres vías evita que SPADE degenere en un adversario puro que genera tareas irresolubles.

Las ablaciones muestran las dependencias críticas. Elimina el anclaje del corpus y el diseñador no puede anclar nuevos entornos a conceptos reales. Elimina la memoria del entorno y regenera tareas redundantes. Desactiva completamente el entrenamiento del diseñador y la línea de base se satura. En juegos, SPADE mejora a través de los 400 pasos de entrenamiento mientras las líneas de base de entorno fijo se estabilizan. La progresión del currículo es visible en los registros publicados: en el paso 4, un entorno ejecuta 173 líneas con 11 variables de estado y el agente de 30B resuelve 31 de 32 intentos en un promedio de 3.7 turnos; en el paso 304, un entorno ejecuta 1.012 líneas con 13 variables de estado y el mismo agente usa los 12 turnos permitidos en cada uno de los 32 intentos.

A escala de 30B (Qwen3-30B-A3B-Instruct), SPADE entrega una ganancia promedio de +5.3 sobre la línea de base de entorno fijo más fuerte en ocho benchmarks retenidos cubriendo matemáticas, ciencia, código y razonamiento procedural—ninguno apareciendo en ningún entorno de entrenamiento generado. El uso de herramientas muestra ganancias mayores: +5.7 en BFCL-v4 multi-turno y +13.9 en ACEBench-Agent. Una ejecución de juegos produjo 4.976 entornos distintos; la ejecución de uso de herramientas de 30B generó 4.023 entornos en 105 pasos, cada uno simulando un backend con un esquema de llamada de función OpenAI. El margen sobre las líneas de base de entorno fijo crece con la escala del modelo—probado a 4B, 8B y 30B—sugiriendo que el enfoque se fortalece conforme el modelo subyacente mejora.

La pila de entrenamiento es de peso de producción: RL distribuido vía Slime, inferencia a través de SGLang, actualizaciones de políticas vía Megatron-LM y normalización de ventaja por rol en GRPO. La evaluación utiliza RLVE, el Berkeley Function Calling Leaderboard y utilidades PRIME. El código es de código abierto en github.com/spade-rl/spade (Python 3.10–3.12, instalable por pip); los lanzadores requieren checkpoints convertidos de Megatron, un corpus de anclaje JSONL y una clave W&B.

Para equipos construyendo sistemas de agentes de largo horizonte en el techo de su grupo actual de tareas, el diseño de doble rol con política compartida de SPADE es el camino publicado más concreto hacia un currículo auto-expandible. El número +13.9 ACEBench-Agent es la señal a observar—los benchmarks de uso de herramientas son donde ocurren la mayoría de fallos de agentes en producción, y esa brecha es lo suficientemente grande para justificar la inversión en infraestructura en Slime más Megatron incluso antes de que el enfoque madure.