Infraestructura para la investigación sobre RSI: ejecutar y evaluar agentes que se mejoran a sí mismos

Un agente de investigación cambia una herramienta de búsqueda en su propio código. Resuelve una tarea en la que antes fallaba. ¿Puede resolver ahora otras tareas? ¿Puede la versión mejorada encontrar otro cambio útil? Para averiguarlo hay que editar programas, ejecutar experimentos y comparar resultados una y otra vez. Beeuni proporciona un ordenador donde los agentes pueden hacer ese trabajo con tu código, tus herramientas y tus scripts de evaluación.

La automejora recursiva, o RSI, estudia si un sistema puede mejorarse a sí mismo, incluida su forma de producir nuevas mejoras. En experimentos con agentes, puede consistir en cambiar su código, instrucciones o herramientas, probar el cambio y usar una versión que haya funcionado para el siguiente intento. Un experimento con una herramienta de búsqueda nos servirá para explicar cómo ayuda Beeuni durante todo el proceso.

Dale a Beeuni el código y una pregunta concreta

Conecta el repositorio que contiene tu agente y sus pruebas. Indica a Beeuni cómo instalarlo, qué comando ejecuta la evaluación y qué parte puede cambiar. Una buena primera pregunta es concreta: ¿puede la herramienta de búsqueda devolver la función pertinente sin enviar todo el archivo al modelo?

La pregunta de investigación determina qué puede editar el agente. Puedes estudiar si otras instrucciones mejoran la planificación, si una nueva búsqueda reduce las lecturas innecesarias o si otra gestión de la memoria ayuda en tareas posteriores. Mantén separados estos experimentos. Cambiar los pesos del modelo requiere otro planteamiento, con su método de entrenamiento y sus necesidades de cómputo.

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuni puede leer la implementación, ejecutar los comandos de instalación y lanzar las pruebas en el terminal. Si falta una dependencia o una prueba falla, el agente puede revisar el error e investigar su causa. Tú puedes seguir el trabajo en la sesión y abrir los archivos que genera.

Prueba la herramienta original antes de sustituirla

Primero pide a Beeuni que ejecute el agente sin modificarlo. Guarda qué tareas pasaron, cuáles fallaron y los errores. Si tu herramienta de pruebas registra el uso del modelo, las llamadas a herramientas o el tiempo transcurrido, incluye esos datos. Ya tienes resultados concretos con los que comparar la versión modificada.

Después deja que el agente cambie la herramienta de búsqueda y ejecute de nuevo el mismo comando. Mantén el modelo, la lista de tareas y los límites. Pídele que explique cada resultado que haya cambiado y adjunte el registro correspondiente. Conviene investigar tanto una reducción de tokens como una tarea que ahora falla porque el resultado abreviado omite código importante.

Son archivos que le pides al agente que genere con tus scripts. Beeuni no aporta el banco de pruebas de investigación ni decide qué cuenta como mejora. Tú aportas las tareas y el código de puntuación; el agente ayuda a ejecutarlos y a investigar los resultados.

Usa los fallos para elegir el siguiente cambio

Supongamos que la nueva herramienta funciona bien con archivos pequeños, pero falla cuando una función llama a otra auxiliar de un archivo distinto. Pide a Beeuni que examine esa tarea, encuentre el contexto que falta y proponga un cambio más concreto. Podrías añadir nombres de funciones relacionadas al resultado de búsqueda, en vez de volver a devolver todos los archivos completos.

Revisa el cambio y el informe antes de aceptarlos. Después pruébalo con otras tareas. Resolver el ejemplo que motivó el cambio dice menos que resolver tareas a las que el agente no ha estado adaptando su código. Mantén las pruebas de puntuación final fuera de los archivos que el agente puede modificar.

El mismo enfoque sirve para un agente de navegación. Dale a Beeuni una aplicación de prueba y una tarea, como encontrar un pedido y actualizar su nota de entrega. Puede manejar el navegador, comprobar el resultado y guardar pruebas de un fallo. Restablece los datos de la aplicación antes de comparar otra versión, para que ambas empiecen con el mismo pedido.

Organiza experimentos sucesivos con tu propio programa

En los experimentos repetidos, el controlador es el programa que organiza las rondas. Elige una versión del agente, pide un cambio, inicia pruebas y decide qué intentar después. El candidato es la versión modificada que se prueba en esa ronda. Tu controlador puede usar la API o el SDK de TypeScript para iniciar y consultar sesiones de Beeuni. Las reglas de selección permanecen en tu código de investigación.

Cada sesión tiene su propio entorno de ejecución. Puedes probar dos implementaciones de una herramienta sin que sobrescriban los mismos archivos o dependencias. El programa dentro del ordenador debe arrancar con la revisión de código prevista. Si un script carga el código solo al iniciarse, reinícialo tras editarlo para que la prueba use realmente la nueva implementación.

Empieza con una cola pequeña de experimentos. Fija en el controlador límites de intentos, sesiones simultáneas, duración y uso del modelo. Cuando alcance un límite, haz que detenga el trabajo correspondiente y compruebe que los procesos terminaron. Estas reglas determinan cuánto puede buscar el experimento antes de elegir una versión.

Prueba cada versión en condiciones comparables

Un agente que pudiera consultar las respuestas correctas o cambiar las pruebas podría subir su puntuación sin hacer mejor la tarea. Calcula la puntuación final por separado, mantén las respuestas ocultas fuera de los archivos a los que puede acceder el agente e impide que modifique el código de puntuación. Beeuni puede ejecutar las pruebas de desarrollo y recoger resultados; tu programa de evaluación puede puntuarlos aparte. En pruebas de navegador, restablece los datos compartidos de la aplicación entre versiones: un ordenador nuevo sigue viendo los registros que dejó el anterior en la misma aplicación externa.

Compara tareas resueltas, errores, tiempo transcurrido, llamadas a herramientas y uso del modelo cuando tu sistema de pruebas los registre. Mantén comparables las tareas, los ajustes del modelo y los límites de ejecución. Repite los resultados dudosos. Un cambio puede leer menos tokens pero perder una función auxiliar, o resolver más tareas a costa de muchas más llamadas al modelo. El informe debe dejar visible esa diferencia.

Cuenta también el coste de encontrar el cambio. Registra por separado los intentos dedicados a proponer y probar versiones y el coste de ejecutar la versión elegida. Un agente puede costar menos por tarea y haber requerido una búsqueda cara para descubrirlo. Ambas medidas importan al valorar el experimento.

Conserva lo necesario para explicar una ronda fallida

Una tarea que falla y una API de modelo no disponible necesitan seguimientos distintos. Pide a Beeuni que conserve los errores y registros completos antes de resumirlos. Tus resultados pueden distinguir respuestas incorrectas, dependencias ausentes, fallos de peticiones al modelo y límites de tiempo agotados. Decide qué fallos merecen otro intento, en lugar de repetirlos todos en silencio hasta que pasen.

Guarda las revisiones de código original y modificada, las instrucciones, los comandos de inicio, las dependencias, la versión del conjunto de pruebas, la versión del código de puntuación y los resultados por tarea. Anota de qué versión anterior procede cada cambio. Beeuni puede redactar este registro junto con el cambio de código y los logs, para que puedas revisar por qué se eligió o descartó una versión.

Guarda los cambios y los informes útiles en tu repositorio o almacenamiento antes de eliminar el ordenador del experimento. Así podrás relacionar cada resultado con el código y el comando que lo produjeron, incluidos los intentos descartados.

Comprueba si mejora la capacidad de encontrar la siguiente mejora

Después de elegir una versión, evalúala con tareas que no hayan guiado los cambios. Úsala luego para buscar más mejoras y compara esos intentos con los del agente original. ¿Encuentra cambios útiles más a menudo, necesita menos intentos o provoca menos regresiones con el mismo presupuesto? Resolver más tareas es un resultado. Mejorar el proceso que produce las mejoras posteriores es la pregunta adicional que debe investigar RSI.

Como ejemplo, el artículo de Darwin Gödel Machine estudia agentes que modifican su propio código y prueban los cambios. Self-Refine estudia cómo revisar una respuesta a partir de comentarios sin entrenamiento adicional. La diferencia ayuda a definir el experimento: ¿mejoras una respuesta, la forma de trabajar del agente o su capacidad para encontrar la siguiente mejora? Beeuni ayuda a editar código, ejecutar comandos y revisar resultados. Tú diseñas el método de investigación. Si necesitas entrenar un modelo, consulta cómo realizar un ajuste fino con Beeuni.

Para probar el cambio en la herramienta de búsqueda, empieza con un repositorio y un comando de prueba que funcione. La guía de Computer explica cómo consultar el entorno y la salida de los procesos mientras trabaja Beeuni.