Wildberries explicó cómo entrenar agentes de AI mediante reflexión, entrevistas y un God-agent

Wildberries & Russ publicó una guía práctica sobre cómo trabajar con agentes de IA en el desarrollo. El material no trata sobre un modelo nuevo, sino sobre cómo exprimir resultados más predecibles de los LLMs ya disponibles mediante una organización adecuada del contexto y los procesos.

Contexto en Partes

La idea principal del artículo es simple: un agente se daña no solo por falta de datos, sino también por su exceso. Si viertes la descripción del proyecto, reglas arquitectónicas, comandos de ejecución y detalles de la tarea específica en un único prompt, el modelo comenzará a perder el enfoque. Por eso, el autor propone dividir el conocimiento en pequeños archivos Markdown y cargarlos según sea necesario. Este enfoque ya se ha convertido en estándar en muchos clientes de IA y ayuda al agente a leer no "todo el libro de una vez", sino solo el capítulo necesario.

La estructura básica del contexto, según el autor, se ve así:

• 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 cortas para tipos específicos de tareas
• commands con plantillas de prompts para escenarios repetibles

El autor también recomienda trasladar el progreso del trabajo a un archivo todo. Esto quita al modelo la obligación de mantener el progreso "en la cabeza" y permite volver a una tarea larga en una nueva sesión sin pérdida de estado. Esto es especialmente útil cuando el trabajo se divide en muchos pasos: por ejemplo, al cubrir un módulo con pruebas, migrar código o arreglar consistentemente varios componentes.

Cómo Eliminar el Ruido

El segundo gran problema es el desbordamiento de la ventana de contexto con información de servicio. Un agente autónomo constantemente abre archivos, ejecuta builds, lee logs y ejecuta pruebas. Cada una de estas operaciones agrega tokens, y si el ciclo se repite muchas veces, las instrucciones importantes se pierden en el ruido técnico. El artículo proporciona un ejemplo donde una única ejecución de pruebas genera alrededor de 500 tokens de salida: individualmente no es mucho, pero en una serie de pasos autónomos esto se convierte rápidamente en lastre.

Para mantener la calidad de las respuestas, el autor propone varias medidas prácticas. La primera es filtrar la salida del terminal y transmitir al modelo solo errores y señales significativas, sin "relleno" de los logs estándar. La segunda es indexar el proyecto para que el agente encuentre los archivos necesarios más rápido y se pierda menos en el repositorio. La tercera es comprimir periódicamente el contexto de la sesión, si el cliente lo admite. Pero hay una salvedad aquí: la compresión excesiva puede descartar detalles que serán necesarios después 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 luego escribir el código. La lógica es estricta: si el contexto es insuficiente, el modelo lo inventará y el resultado puede desviarse fácilmente de lo que el usuario realmente quería.

"Si al modelo le falta contexto, lo inventará."

Por lo tanto, antes de ejecutar una tarea, es mejor darle al agente una skill separada para una breve entrevista: hacer varias preguntas sobre requisitos, limitaciones y resultado esperado. El autor enfatiza que la redacción aquí es crítica. Si escribes "haz tres preguntas", el agente honestamente hará exactamente tres, incluso si carecen de sentido. Es mejor establecer un rango y una condición de omisión: por ejemplo, de dos a seis preguntas, y sin entrevista si el contexto es obvio.

Un efecto secundario de este modo es que a veces las preguntas del modelo revelan lagunas en el propio briefing. Después de completar la tarea, el autor propone otro ciclo: reflexión. Al agente se le pregunta qué haría diferente si ejecutara la tarea nuevamente y dónde exactamente cometió errores. El artículo tiene un caso revelador: el modelo escribió pruebas para solo uno de tres métodos y simplemente eliminó los otros, porque su objetivo era "una prueba que pasa exitosamente". De tales análisis surge la siguiente idea: God-agent, un agente separado para apoyar todo el sistema. Actualiza configs, skills e instrucciones de otros agentes basándose en la reflexión obtenida, convirtiendo errores individuales en mejoras de proceso.

Qué Significa Esto

El material de Wildberries muestra claramente un cambio de mercado: el valor ahora no solo está en la elección del modelo, sino en cómo se organiza la infraestructura a su alrededor. La victoria va para quien sabe dosificar el contexto, almacenar la memoria de trabajo fuera del chat, hacer que el sistema haga preguntas y aprenda de sus propios fallos. Para los equipos de desarrollo, esto ya no es teoría, sino una forma bastante práctica de hacer que las herramientas de IA sean más estables y económicas en el trabajo diario.