MWS redujo el arranque de un agente de IA de 37,6 a 16,8 segundos: análisis del harness

Mientras unos desarrolladores configuran un harness local en su portátil, otros ya lo llevan a producción para miles de usuarios. Un autor de Habr asistió al meetup de MWS «Russkoe tekhno 2» y anotó qué ocurre cuando hay que escalar el andamiaje que rodea al modelo. A continuación, lo esencial, con una salvedad: las cifras proceden de los ponentes y no se pueden verificar de forma independiente.

El harness es casi todo, menos el modelo

Un LLM a secas es una caja negra: recibe texto y devuelve texto. No tiene memoria, ni cálculo exacto, ni capacidad de autoverificación. Según la definición de los ponentes, un agente equivale a un modelo más un harness. El harness incluye el prompt, el contexto y la memoria, las herramientas, el ciclo de acciones, las verificaciones, las restricciones y la orquestación.

¿Cómo se ve esa diferencia en la práctica? Un arquitecto de MWS encargó a Opus la revisión de código ajeno y obtuvo tres observaciones menores. La misma tarea con DeepSeek y un harness arrojó unas 50 observaciones, de las cuales 25 requerían atención. Es decir, un modelo «medio» con un buen harness superó a uno potente sin él.

Algunas lecciones de la ponencia:

• El contexto es lo principal. El modelo relee toda la conversación desde el principio y, cuanto más larga es, peores son las respuestas. La salida: comprimir el historial, cargar lo necesario mediante subagentes o trasladar los datos a archivos.
• Más herramientas no es mejor. En Vercel, un agente con 17 herramientas fallaba en una de cada cinco tareas. Tras reducirlas a las cuatro necesarias, las tareas se completaban al 100%.
• Los errores se acumulan. Con una precisión del 99% por paso, una cadena de 10 pasos termina sin fallos en el 90% de los casos; una de 50 pasos, solo en el 60%. Por eso hacen falta pruebas tras cada cambio y una especificación adaptada a la tarea, por ejemplo en OpenSpec.

La tendencia de 2026 es un harness que se corrige a sí mismo. Un configurador lee los logs de las sesiones, detecta fallos recurrentes y añade reglas. En el ejemplo de MWS, el agente entregaba el trabajo sin pruebas en tres de seis sesiones. El configurador añadió un hook «no entregar sin pruebas» y al día siguiente las seis sesiones pasaron con pruebas.

En qué se van los 37,6 segundos

El proyecto «Empleado digital» es un agente conserje personal en Telegram y Max con más de 30 habilidades. Por dentro, cada usuario tiene su propio pod en Kubernetes con OpenClaw o Hermes. La primera respuesta tardaba de media 37,6 segundos, aunque la respuesta del modelo en sí duraba entre 2,3 y 4,5 segundos.

El tiempo se iba en infraestructura:

• 4 s: el operador despliega el manifiesto del agente en Kubernetes;
• 10 s: conexión del disco al nodo;
• 5 s: montaje del disco en el pod;
• 5 s: inicialización de los contenedores;
• 9,5 s: carga del Gateway del agente;
• 3,1 s: comprobación de disponibilidad;
• 1 s: entrega de archivos.

El equipo eligió una arquitectura de slots precalentados: la preparación pesada se hace de antemano y el usuario solo espera al arranque. MWS descartó las alternativas: un pod por usuario tarda demasiado en arrancar, una MicroVM por sesión es compleja de operar y un despachador común, si falla, tumba a todos.

La cadena de optimizaciones fue la siguiente:

1. Trasladaron a los slots el levantamiento del pod y la entrega de claves: menos 4 s, quedan 33,6.
2. Pasaron de discos de bloque al almacenamiento compartido CephFS: menos 15 s, quedan 18,6.
3. Precalentaron los contenedores y los módulos del agente: la mejora fue de solo 1,8 s, porque se añadieron la fijación del slot y el despertar del agente.

Resultado: 16,8 segundos. El objetivo es de 6–8, pero para lograrlo habrá que meterse en el código del agente y, posiblemente, hacer un fork.

El precio de la velocidad

Cada paso complicó el sistema. Hace falta un registro de slots en PostgreSQL, eventos de Kafka y la garantía de que el slot de un usuario A que se ha ido no acabe asignado a un usuario B. El principal problema es el disco compartido: en la variante actual, los slots ven una raíz común y, por los permisos, un usuario podría ver en teoría los datos de otros. La solución es montar un subvolume por clave, pero eso exigirá un servicio aparte.

Los archivos del workspace del agente se dividieron en cinco áreas: managed (según el registro), protected (perfiles, no tocar), runtime, user-owned y seed (se entregan una sola vez). La regla es sencilla: solo se puede actualizar y borrar lo propio.

Otro quebradero de cabeza es cuándo dormir al agente. Ahora se hace por tiempo: 30–35 minutos después de la última actividad del usuario o 5 minutos si el slot lo levantó Cron. Sin acceso al runtime no se puede distinguir entre «se ha ido» y «está pensando la respuesta». El equipo prueba una hipótesis con un modelo rápido que decide en 0,5 segundos.

Qué conviene llevarse

Si construye agentes para muchos usuarios, mida el tiempo hasta la primera respuesta por separado del tiempo de trabajo del modelo. Lo más probable es que el problema esté en la infraestructura, no en el LLM. No infle el conjunto de herramientas y coloque las verificaciones dentro del ciclo. Piense con antelación en el aislamiento de datos: el almacenamiento compartido acelera el arranque, pero convierte los permisos de acceso en el principal riesgo.

Limitación del material: el texto se interrumpe en la ponencia sobre la adopción de IA en las organizaciones y la evaluación del efecto empresarial, así que aquí no hay nada que decir sobre la medición del retorno de la inversión. Una parte de las tesis (por ejemplo, sobre Google Research Harness 2) se presenta sin fuentes y conviene tomarlas como declaraciones de los ponentes.