Arnés de agentes para Pi y Orca

El problema

Trabajo con varios agentes a la vez, y el arnés que los lanza acababa consumiendo más recursos que los propios agentes. Dos síntomas: el equipo se calentaba y la respuesta se sentía lenta.

Lo que hice

En lugar de optimizar a ojo, medí. Un perfil de V8 de 10 628 muestras mostró que el bucle de render acaparaba más del 80 % del tiempo y que el proceso estaba ocioso el 0,6 %. Eso no era “lento”: era un camino mal construido que se recorría continuamente.

El segundo hallazgo fue más interesante. Cada sesión levantaba su propio árbol de servidores de lenguaje de TypeScript, y cada uno consumía alrededor de 1,1 GiB en residente. La memoria que veía no venía de los agentes, venía de la infraestructura de las herramientas.

Después del arreglo, el tiempo ocioso pasó al 74 % y un banco sintético de componentes bajó de 284 milisegundos a 9. La parte importante es lo que el documento no afirma: que eso no es una mejora de 31× de la aplicación, que la memoria residente no es compartida y por tanto exagera el consumo, y que la bajada de temperatura no la atribuyo a este cambio.

Por qué lo enseño

Porque es el único proyecto donde el entregable es un diagnóstico. No construí una herramienta nueva: entendí por qué una que usaba iba mal, lo arreglé y dejé escrito qué no prueba mi propia medición.

Esa última parte es la que casi nunca se escribe y la que distingue un informe técnico de un informe de ventas.

Aparte, el proyecto documenta una pelea real con la arquitectura de otro: quería unificar dos entornos de agente y no se podía, porque ambos registran la misma familia de herramientas y el host rechaza proveedores duplicados. La conclusión fue aceptar dos entornos y documentar por qué, que es menos elegante y más útil que forzar la unificación.