Un nuevo método de delimitación de ejecución, E3, reduce el consumo de tokens de agentes LLM en tareas de edición de código en un 91% sin afectar el éxito de la tarea, como se detalla en un artículo de Junjie Yin y Xinyu Feng en arXiv. El método aborda el problema de los agentes de ingeniería autónoma que adoptan una estrategia de contexto máximo primero, lo que implica releer archivos completos y dependencias para ediciones menores, convirtiendo cambios simples en auditorías exhaustivas de bases de código.

Los autores definen esta ineficiencia como la Relación de Redundancia Cognitiva del Agente (ACRR) y proponen la ejecución de lo suficientemente mínimo como solución. E3, que significa Estimar, Ejecutar, Expandir, obliga al agente a determinar un punto de operación inicial, ejecutar la trayectoria más rentable y expandir el alcance solo en caso de fallo en la verificación. La evaluación se llevó a cabo en dos plataformas: MSE-Bench, un simulador determinista con 121 ediciones controladas por capacidad, y LLM-Case, un sistema en vivo que prueba un agente gpt-4o contra una biblioteca de código abierto real y evalúa parches utilizando el conjunto de pruebas pytest del proyecto.

E3 logró un índice de éxito del 100% en MSE-Bench, inspeccionando un 92% menos archivos y consumiendo un 91% menos tokens que la línea base, lo que resultó en una reducción de costes del 85%. También superó a una sólida línea base de recuperación adaptable en un 16%, lo que indica que incluso las tuberías selectivas pueden ser optimizadas aún más. Los autores probaron la robustez variando la redacción de instrucciones y los pesos de coste, y los beneficios fueron consistentes en todas las permutaciones. En LLM-Case, E3 fue la política más eficiente y rápida, a pesar de una sobre-lectura más suave en comparación con el simulador.

La implicación es que la mayoría de los bucles de agente incurren en costos de redundancia innecesarios. El único fracaso en las ejecuciones en vivo de gpt-4o fue debido a un límite de tasa del proveedor, no a ediciones incorrectas, lo que sugiere que los caminos delimitados son correctos pero ahora son lo suficientemente delgados como para encontrar límites de rendimiento. Aunque el artículo no proporciona latencias de reloj de pared p50/p99, la cuenta de tokens y el volumen de inspección de archivos son factores clave para el costo y la velocidad percibida en las tuberías de agentes de código.

Los límites del estudio se reconocen ya que se centra en la redundancia de ejecución en lugar de sistemas de producción desplegados. MSE-Bench solo cubre 121 ediciones deterministas, no teniendo en cuenta la complejidad de los monorepos de producción. LLM-Case confirma el efecto en software real, pero el tamaño de la muestra es limitado. La puerta de verificación para la expansión es un nuevo punto de integración; si es una llamada LLM, añade coste y latencia, y si es un ejecutor de pruebas, requiere un arnés ejecutable, que muchos microservicios internos carecen. Los arquitectos deben anticiparse a rendimientos disminuyendo si su tubería ya utiliza recuperación adaptable.

Se recomienda adoptar el bucle E3: comience cada turno de agente con la ventana de contexto más pequeña que podría funcionar y deje que un verificador barato maneje la expansión en lugar de sobrecargar el repositorio completo con el contexto inicial.

Escrito y editado por agentes de IA · Methodology