Ejecutamos enjambres de agentes de IA en Minecraft y Mindustry
Los experimentos de Y Combinator Labs que liberaron enjambres de agentes basados en LLM en Minecraft y Mindustry ponen de relieve tanto la promesa como los límites actuales de la IA en entornos de juego complejos y en tiempo real. Los comentaristas señalan que, aunque los modelos pueden razonar, tienen dificultades con la latencia, la coordinación y la ejecución básica, y a menudo degeneran en una burocracia cómica más que en un juego eficaz. El hilo usa estos resultados para plantear preguntas más amplias sobre si los grandes modelos de razonamiento, los enjambres de agentes y los arneses que escriben código son la arquitectura adecuada para mundos interactivos, y qué diseños híbridos (LLM para macro + control determinista para micro) podrían funcionar mejor.
Reacción general a los experimentos
- Muchos encontraron las demostraciones divertidas, encantadoras e impresionantes desde el punto de vista técnico, pero también señalaron limitaciones serias.
- Varios comentaristas sintieron que los agentes “jugaban” Minecraft de una manera por turnos y lenta, haciendo que la construcción de civilizaciones se sintiera burocrática e ineficaz.
- Algunos quedaron más impresionados por el visor incrustado de Minecraft que por la propia IA.
Latencia, control y arquitectura
- Un tema recurrente: los LLM grandes son una mala opción para juegos de acción en tiempo real debido a la alta latencia y al cálculo token por token.
- Los comentaristas sostienen que estas tareas se parecen más a la robótica: necesitan bucles de retroalimentación continuos y ajustados para el movimiento y el combate.
- Patrón sugerido: usar scripts deterministas o modelos pequeños y rápidos para microacciones (movimiento, pelea, “click spam loops”), y LLM solo para la planificación de nivel superior.
- Se citaron como más prácticos los sistemas existentes que tienen un mod/bot para acciones por debajo de un segundo, un servidor separado de decisiones macro y LLM solo para política/diseño.
Comportamiento, burocracia y vibra de “middle manager”
- Las ejecuciones multiagente a menudo derivaban en coordinación elaborada, comités y procesos para asuntos triviales (por ejemplo, roles para un solo bone meal, postmortems detallados por incidentes menores).
- Los comentaristas vincularon esto con el género (contenido de Minecraft de “construir una civilización”), los datos de entrenamiento humanos y la tendencia general de los sistemas multiagente hacia el bike shedding y la burocracia.
- Los logs fueron ampliamente leídos como oro cómico: agentes actuando como ingenieros senior ansiosos o middle managers en pánico.
Diferencias entre modelos y límites del razonamiento
- Algunos sintieron que la necesidad de escribir scripts de acción en JavaScript/Python expone la dificultad de los LLM para mantener un control lógico continuo sobre el entorno.
- Otros respondieron que hacer que el modelo genere código auxiliar determinista en realidad es una fortaleza y una forma natural de reducir errores y costos.
- Observaciones de los experimentos:
- Los agentes basados en GPT parecían más agresivos, exploratorios y mejores para diagnosticar errores de herramientas y compartir soluciones alternativas.
- Los agentes basados en Claude tendían a ser más cautelosos, defensivos y “tipo Slack” en la comunicación, a veces concluyendo que las tareas eran imposibles cuando las herramientas tenían fallos.
Enjambres frente a sistemas más simples
- Varios cuestionaron el valor de los “enjambres” de 50 agentes cuando todos comparten el mismo modelo subyacente.
- Críticas: roles redundantes, desperdicio de tokens, política de oficina emergente, ganancia mínima frente a un solo agente bien instruido.
- Los defensores de los sistemas multiagente argumentaron que pueden ayudar cuando los agentes tienen herramientas, conocimientos y ámbitos genuinamente diferentes, o cuando los problemas son altamente paralelizables.