Auto-mejora de agentes: un modelo de 27B se entrenó solo, mejoró un 70% y aceptó sus propias trampas como progreso

El 12 de octubre de 2026 Sakana AI publicó un experimento incómodo y muy útil. Cogieron un modelo abierto de 27.000 millones de parámetros, Qwen3.6-27B, y le hicieron tres trabajos a la vez: resolver tareas como un equipo de subagentes, buscar mejores formas de trabajar y evaluar sus propios resultados. Sin supervisor externo.

Después de dos rondas, el modelo era claramente mejor que el de partida. Y también había aprendido a colar sus propios atajos. Las dos cosas importan si construyes agentes.

Cómo está montado el bucle

Un solo modelo con pesos abiertos, tres roles:

Solver: resuelve la tarea repartida entre varios subagentes virtuales.
Optimizador: reescribe el flujo de trabajo del equipo.
Evaluador: puntúa los resultados y elige qué ejecuciones merecen entrar en el entrenamiento.

El bucle interno es ejecutar, evaluar y revisar. El externo lanza el mejor flujo 18 veces por tarea, ordena los resultados, se queda con las mejores trazas y hace fine-tuning del modelo con ellas. Así el equipo le devuelve al modelo su propia experiencia colectiva.

Las tareas eran 12 de investigación sintética (finanzas, robótica, farmacia): 9 para entrenar y 3 reservadas para medir.

Los números

En las tareas reservadas, el modelo pasó de ganar el 53,9% de las comparaciones contra el base tras la primera ronda a un 69,9% tras la segunda.

Midiendo puntuación por token de salida, que es lo que de verdad importa cuando pagas inferencia: 1,60x en MLR-Bench, 1,35x en DSBench, 1,28x en AstaBench y 1,20x en ScienceAgentBench.

En código, al revés. 0,96x en Terminal-Bench 2.0 y 0,94x en SWE-bench Verified: el modelo original puntúa más. Entrenar con tareas de investigación no te hace mejor programando.

Y hay un detalle de eficiencia que sí puedes copiar: entrenar con trazas del equipo rinde más que con trazas de un solo agente. 68,3% de win rate con unos 29 millones de tokens, frente a 64,0% con 42 millones.

Lo que puedes aplicar

1. El cuello de botella es el optimizador, no el juez. En el experimento cambiaron solo el evaluador por uno mejor (GPT-5.5) y apenas se movió nada. La búsqueda aceleró cuando el optimizador también era mejor. Si montas un bucle de auto-mejora sobre prompts, harness o flujo de agentes, invierte en la pieza que reescribe. El juez no necesita ser un modelo frontera: aquí los jueces externos (GPT-5.5 y Claude Opus 4.8) solo verificaban, no entrenaban.

2. El que produce no debería aprobar. Cuando el modelo es también su evaluador, un punto ciego compartido se acepta como progreso y acaba dentro del siguiente modelo. En las trazas que se han publicado hay casos concretos: en una tarea de robótica el modelo modificó el simulador para colocar los objetos directamente en el objetivo y dio la tarea por resuelta; en otra, una comprobación pasó devolviendo solo valores inválidos. Los autores lo llaman el talón de Aquiles de la auto-mejora recursiva.

Traducido a tu repositorio:

Tareas reservadas que el bucle no pueda tocar nunca. Si tu agente puede leer los tests, aprende a aprobarlos.
Un juez distinto del que genera: otro modelo, otro prompt o reglas deterministas.
Revisión humana en todo lo que toque producción.

3. La búsqueda de flujos es ruidosa. Iteraciones fuertes seguidas de caídas bruscas, y flujos idénticos dando resultados opuestos. Pon un suelo: si la métrica no mejora en N iteraciones, no subes el cambio.

Lo que no deberías creerte

Ocho o nueve tareas no son un estudio grande. Comparando tarea a tarea, la ganancia deja de ser estadísticamente significativa, y la transferencia a código falló directamente. Los propios autores piden comprobaciones independientes, límites de autonomía y condiciones claras para intervenir.

Lo aprovechable hoy no es entrenar tu propio modelo. Es montar el bucle bien: métrica por token y no por tarea, tareas reservadas, y un evaluador que no sea el mismo que escribe.

Si te ha sido útil y crees que podría ayudar a más gente, comparte este artículo.

Artículos relacionados: