Saltar al contenido
← lab
logholds-upagentsmcpdebugging

Mis agentes tenían 157 herramientas y no llamaban a ninguna

Los agentes juraban que las herramientas no existían. El log decía otra cosa: una race en el cold spawn, no las herramientas. Modelar la latencia donde estaba acabó en un MCP pooler open-source.

El objetivo era simple: que los agentes citaran datos reales de forma nativa, en vez de tirar de shell o adivinar. Todos los backends estaban conectados. Los agentes tenían 157 herramientas a mano. Usaron cero, y me dijeron por qué: “la herramienta no existe”, “el upstream no conectó”. Seguros, detallados y completamente equivocados.

Pasé una hora depurando una ficción

  1. Le creí al agente. Durante una hora depuré el mundo que el agente describía. El agente es un narrador poco confiable. Cuenta una historia, no un stack trace. La verdad estuvo en el log de ejecución todo el tiempo.
  2. Culpé a la cantidad de herramientas. Supuse que 157 eran demasiadas y que la capa de búsqueda se confundía. Las dos hipótesis parecían correctas hasta que el log mató a ambas. Cada “la herramienta no existe” tenía una causa real debajo: una race en el descubrimiento, una sesión que todavía no estaba lista, un schema que no coincidía.
  3. Sospeché del overhead de agregación. También falso. Un backend en caliente responde un tools/list en unos diez milisegundos. La medición mató la teoría.

El cold spawn reventó la ventana de descubrimiento

La latencia era el cold spawn. Cada sesión levantaba siete backends en frío, y eso costaba entre cuatro y veintisiete segundos. El descubrimiento tenía una ventana corta, menos de un segundo, y el cold spawn la atravesaba de lleno. El agente pedía sus herramientas antes de que los backends pudieran responder, no recibía nada y narraba una ficción sobre herramientas faltantes.

El arreglo salió de un cambio de enfoque: lo que se mantiene caliente es la capa de datos, no el cliente efímero. El cliente CLI es one-shot, no puedes hacer pool del proceso. Así que puse un proxy persistente con caché delante de los datos: una sesión upstream caliente, el listado de herramientas en caché, el descubrimiento de vuelta a unos cincuenta milisegundos, bien dentro de la ventana. El catálogo de admin sigue como control plane, pero el tráfico caliente dejó de pasar por él. Control plane y data plane piden velocidades distintas, así que sepáralos en vez de sacrificar uno por el otro. Ese proxy salió como open-source: mcp-pooler, MIT.

Un hábito dejó limpia toda la noche: revertir pronto y medir. Cada patch de prueba entraba con backup y checksum, y salía antes del siguiente, así producción se mantuvo íntegra mientras yo probaba y descartaba hipótesis.

Lección

Cuando un agente reporta una falla, no depures al agente: lee el log de ejecución. El agente es el narrador; el log es la verdad. Y la latencia suele esconderse una capa por debajo de donde aparece: el síntoma era “no hay herramientas”, la causa era un cold start.