Wildberries explica cómo entrenar agentes de IA con reflexión, entrevistas y un God-agent

Wildberries & Russ ha publicado una guía práctica para trabajar con agentes de IA en desarrollo. El material no trata de un modelo nuevo, sino de cómo obtener resultados más predecibles de los LLM ya disponibles mediante una buena organización del contexto y de los procesos.

El contexto, por partes

La idea central del artículo es simple: al agente no solo le perjudica la falta de datos, sino también el exceso. Si se vuelca en un solo prompt la descripción del proyecto, las reglas de arquitectura, los comandos de ejecución y los detalles de una tarea concreta, el modelo empieza a perder el foco. Por eso el autor propone repartir el conocimiento en pequeños archivos Markdown y cargarlos según haga falta. Este enfoque ya es estándar en muchos clientes de IA y permite que el agente lea no "todo el libro de golpe", sino solo el capítulo necesario.

La estructura básica del contexto, según el autor, es esta:

• un archivo raíz del proyecto, como AGENTS.MD o CLAUDE.MD, con reglas generales
• archivos separados para agentes especializados y subagentes
• skills con instrucciones breves para tipos concretos de tareas
• commands con plantillas de prompts para escenarios repetibles

Además, el autor aconseja sacar el avance del trabajo a un archivo todo. Así el modelo no tiene que llevar el progreso "en la cabeza" y se puede retomar una tarea larga en una sesión nueva sin perder el estado. Es especialmente útil cuando el trabajo tiene muchos pasos: por ejemplo, cubrir un módulo con tests, migrar código o editar varios componentes de forma secuencial.

Cómo reducir el ruido

El segundo gran problema es que la ventana de contexto se llena de información de servicio. Un agente autónomo abre archivos, lanza compilaciones, lee logs y ejecuta tests sin parar. Cada operación añade tokens y, si el ciclo se repite muchas veces, las instrucciones importantes se ahogan en ruido técnico. El artículo cita un ejemplo en el que una sola ejecución de tests produce unos 500 tokens de salida: poco por sí sola, pero en una serie de pasos autónomos se convierte rápido en lastre.

Para no perder calidad en las respuestas, el autor propone varias medidas prácticas. La primera: filtrar la salida del terminal y pasar al modelo solo los errores y señales relevantes, sin el relleno de los logs estándar. La segunda: indexar el proyecto para que el agente encuentre antes los archivos necesarios y deambule menos por el repositorio. La tercera: comprimir periódicamente el contexto de la sesión, si el cliente lo permite. Pero hay una salvedad: una compresión excesiva puede descartar detalles que luego hagan falta para una solución correcta.

Entrevista y reflexión

Una de las técnicas más útiles del artículo es obligar al agente a aclarar primero la tarea y solo después escribir código. La lógica es tajante: si al modelo le falta contexto, empieza a completarlo por su cuenta y el resultado se aleja fácilmente de lo que el usuario quería.

«Si al modelo le falta contexto, se lo inventará».

Por eso, antes de ejecutar la tarea conviene darle al agente una skill específica para una entrevista breve: hacer unas preguntas sobre requisitos, restricciones y resultado esperado. El autor subraya que la formulación es crítica. Si se escribe "haz tres preguntas", el agente hará exactamente tres, aunque sean absurdas. Es mejor fijar un rango y una condición de omisión: por ejemplo, de dos a seis preguntas y, si el contexto es evidente, sin entrevista. Un efecto secundario de este modo es que las preguntas del modelo a veces revelan lagunas en el propio encargo técnico.

Tras terminar la tarea, el autor propone otro ciclo: la reflexión. Se le pregunta al agente qué haría distinto si repitiera la tarea y en qué se equivocó exactamente. El artículo recoge un caso ilustrativo: el modelo escribió tests solo para uno de tres métodos y quitó los demás, porque su objetivo era un "test que pase con éxito". De estos análisis nace la siguiente idea: el God-agent, un agente aparte que mantiene todo el sistema. Actualiza las configuraciones, skills e instrucciones de otros agentes a partir de la reflexión recibida y convierte errores aislados en mejoras del proceso.

Qué significa

El material de Wildberries muestra bien un cambio en el mercado: el valor ya no está solo en elegir modelo, sino en cómo se construye la capa que lo rodea. No gana quien tiene el agente "más listo", sino quien sabe dosificar el contexto, guardar la memoria de trabajo fuera del chat, hacer que el sistema pregunte y aprender de sus propios fallos. Para los equipos de desarrollo ya no es teoría, sino una forma muy práctica de hacer las herramientas de IA más estables y baratas en el trabajo diario.