El coste oculto de dejar que los agentes funcionen solos

La economía de los agentes de programación con IA cambia una vez que dejan de responder a preguntas aisladas y empiezan a trabajar por su cuenta. Una predicción puntual es barata. Una ejecución larga y sin supervisión no lo es: los pasos de razonamiento se acumulan sobre las llamadas a herramientas, que a su vez se acumulan sobre los bucles de retroalimentación, y la factura de tokens crece con cada ciclo. Los investigadores de Nvidia han publicado un artículo que describe un sistema que ataca esa factura desde un ángulo inesperado: no haciendo que el modelo subyacente sea más barato de ejecutar, sino reescribiendo el andamiaje que lo rodea.

Según los investigadores, su método, llamado SoL-Pi, reduce el consumo de tokens casi a la mitad mientras deja el rendimiento prácticamente intacto. El trabajo fue reportado por The Decoder, que señala que el sistema se dirige a la capa de control conocida como harness en lugar de al propio modelo.

Qué hace realmente el harness

El harness es la capa de software que se sitúa entre un modelo y el entorno en el que opera. Muestra al agente en qué estado se encuentra, decide cómo se ejecutan las acciones y determina qué retroalimentación vuelve al modelo después. Productos conocidos como Codex, Claude Code y OpenClaw dependen de harnesses de este tipo para convertir un modelo de lenguaje en algo capaz de editar archivos, ejecutar pruebas e iterar.

Debido a que esa capa gobierna gran parte del bucle, tiene un efecto desproporcionado sobre el coste. Cada llamada a herramienta redundante, cada ventana de contexto sobredimensionada, cada paso de verificación que se activa demasiado tarde añade tokens que no eran estrictamente necesarios. Hasta ahora, la mayor parte del trabajo de eficiencia se ha concentrado en otros lugares: en reducir el precio de un solo token mediante kernels de atención más rápidos e infraestructura de servicio, en comprimir modelos mediante cuantización, o en enrutar el trabajo hacia modelos más pequeños y baratos.

Por qué es difícil optimizar el harness

Ajustar el harness a mano es difícil porque sus responsabilidades están estrechamente entrelazadas. El uso de herramientas, la gestión del contexto, las rutinas de verificación y la lógica de aborto interactúan entre sí. Un cambio que recorta tokens en una etapa puede introducir fallos en otro lugar, o simplemente trasladar el coste a una fase posterior de la ejecución donde es más difícil de ver.

Diagrama del bucle de autoinvestigación de SoL-Pi que muestra entornos de investigación, una IA de investigación, un grupo de ideas y cuatro mecanismos retenidos, junto a gráficos de barras que comparan la puntuación y los costes de API de Codex, Claude Code, Pi y SoL-Pi en EdgeBench.
Una IA de investigación analiza las trazas de los agentes, propone cambios en el harness y conserva solo aquellos que mantienen el rendimiento mientras reducen los costes. SoL-Pi ahorra un 50 por ciento en comparación con Codex y un 54,3 por ciento en comparación con Claude Code en EdgeBench. | Imagen: Nvidia

En la práctica, los ingenieros leen largas trazas de ejecución, detectan patrones de fallo recurrentes y traducen esas observaciones en cambios de código. Es un trabajo lento y manual que depende de que alguien note el mismo error por décima vez.

Cómo automatiza SoL-Pi la búsqueda

SoL-Pi toma ese bucle humano y lo automatiza. Un agente de investigación observa las trazas producidas por otro agente, propone modificaciones al harness y luego prueba esas propuestas dentro de entornos preparados. Los cambios candidatos se filtran mediante comprobaciones tanto de capacidad como de eficiencia, y solo se conservan las variantes que mantienen el rendimiento estable mientras reducen el coste.

Los autores describen el enfoque como basado en la automejora recursiva: un sistema de IA está mejorando efectivamente las condiciones operativas de otro. Un detalle clave es que la evaluación utilizada para juzgar el resultado final ocurre solo después de que el harness se haya congelado, y esa evaluación reservada no retroalimenta el proceso de búsqueda. Esa separación importa, porque limita cuánto puede ajustarse el proceso de optimización a las pruebas que finalmente enfrentará.

La escala del experimento

La búsqueda fue amplia. A lo largo de 535 entornos ejecutables, SoL-Pi exploró 152 direcciones distintas. La mezcla de tareas incluyó:

  • 495 tareas construidas a partir de pares de issues y pull requests de GitHub
  • 40 casos de prueba sintéticos diseñados para la evaluación
  • Más de 3000 ejecuciones en total
  • Más de 60 000 interacciones entre agente y entorno

Los investigadores presentan ese volumen como evidencia de lo ampliamente que buscó el sistema, pero también advierten que buscar más no produce automáticamente mejores resultados. La amplitud aumenta la probabilidad de encontrar una configuración de harness útil, pero no la garantiza.

Los ahorros medidos

Las cifras principales son sustanciales. En EdgeBench, SoL-Pi ahorró un 50 por ciento de tokens en comparación con Codex y un 54,3 por ciento en comparación con Claude Code, según los investigadores, mientras que el rendimiento se mantuvo aproximadamente al mismo nivel. El artículo enmarca la reducción general de tokens como de hasta un 49 por ciento con pocos cambios en la capacidad de las tareas.

Diagrama de flujo del pipeline de búsqueda, desde los despliegues de trayectorias pasando por el análisis map-reduce, la propuesta de mecanismos, la implementación de candidatos, la revisión independiente y la validación de desarrollo hasta una evaluación reservada separada.
La evaluación reservada ocurre solo después de que el harness se congela y no retroalimenta el proceso de búsqueda. | Imagen: Nvidia

Ese encuadre es importante. Recortar el uso de tokens es fácil si se permite que un agente falle con más frecuencia, se salte la verificación o aborte antes de tiempo en tareas legítimas. La afirmación aquí es diferente: los ahorros provienen de una lógica de control más austera en lugar de un comportamiento degradado, y por eso las comprobaciones de capacidad se sitúan junto a las de eficiencia en el proceso de selección.

La cuestión del sobreajuste

Existe un peligro conocido en esta línea de investigación. Trabajos anteriores han demostrado que los harnesses optimizados automáticamente tienden a sobreajustarse, volviéndose muy eficientes en las trazas con las que fueron ajustados mientras generalizan mal a situaciones nuevas. Los autores de Nvidia parecen ser conscientes de esto, y por eso la evaluación final se realiza sobre un harness congelado y aislado del bucle de búsqueda.

Aun así, la advertencia merece tenerse en cuenta. Los entornos utilizados aquí, aunque numerosos, siguen siendo una muestra finita de la realidad desordenada que encuentran los agentes de programación. Si un harness refinado a lo largo de 535 entornos resiste ante un repositorio genuinamente desconocido, una suite de pruebas inestable o un informe de error ambiguo sigue siendo una pregunta abierta que solo responderá un despliegue más amplio.

Qué significa para la economía de los agentes

Si los resultados se mantienen fuera del laboratorio, las implicaciones son prácticas más que filosóficas. Los equipos que ejecutan agentes de programación autónomos pagan por token, y las largas sesiones sin supervisión que hacen útiles a los agentes son precisamente las que los vuelven caros. Extraer casi la mitad de los tokens de un flujo de trabajo sin perder capacidad cambia cuántas de esas sesiones puede sostener un presupuesto.

El trabajo también sugiere un cambio en dónde merece la pena gastar el esfuerzo de optimización. La eficiencia a nivel de modelo ha sido el objetivo por defecto durante años, y ciertamente sigue importando. Pero el harness es donde se toman las decisiones sobre contexto, verificación y reintentos, y como ilustra este artículo, esas decisiones son donde se acumula una gran parte del desperdicio. La brecha entre el modelo y el entorno puede ser el lugar más productivo que queda por explorar.

Este artículo se basa en la cobertura de The Decoder. Lee el artículo original.

Originally published on the-decoder.com