El agente no recuperaba memoria porque el gateway inyectado no era alcanzable
La conversación funcionaba y el contexto mostraba memoria, pero la recuperación activa daba timeout: la IP del gateway inyectada salía de la red del contenedor, inalcanzable para el ejecutor de herramientas.
Una conversación que responde y un contexto que contiene memoria no demuestran que el agente recupere nada. En un despliegue en Docker del MemoryProxy de TencentDB-Agent-Memory, las peticiones de recuperación activa daban timeout mientras el chat seguía funcionando con normalidad. El fallo estaba en la dirección de gateway que se inyectaba en el prompt de la herramienta, que apuntaba a la red del contenedor.
Inyección pasiva y recuperación activa no van juntas
El proxy tiene dos caminos que comparten configuración y maquinaria de inyección, pero que pueden fallar por separado. La inyección pasiva lee contenido o índices de memoria en el lado del servidor y los mete en el contexto: memoria núcleo L3, índices de escenario L2, persona y lista de skills. En este despliegue seguía viva.
La recuperación activa, en cambio, entrega endpoints a través de prompts de herramientas, y el cliente pide direcciones como ${base}/memory-bridge/v3 o ${base}/skill-bridge/v3/skill. Ahí está la trampa: que el contexto traiga memoria no implica que el cliente alcance la URL que se le pasa. El servidor leía bien; el ejecutor de herramientas del cliente no llegaba a la dirección generada. Las peticiones morían en timeout o sin respuesta HTTP, registradas como 000, y el asistente seguía tirando de lecturas de fichero y búsquedas locales sin mostrar ningún error al usuario.
El campo de configuración que faltaba
Siguiendo el camino roto se llega a la lógica que genera la URL. En el código de la rama feat/server_team consultado el 19 de septiembre de 2026, injection.externalGatewayUrl tiene prioridad cuando está configurado. Si falta y el host configurado es 0.0.0.0 o 127.0.0.1, el fallback coge la primera IPv4 no interna y construye una base http://<host>:<port>, dejando un aviso por el camino. Ese despliegue había tomado el fallback: la dirección elegida pertenecía a la red del contenedor y el ejecutor de herramientas estaba fuera de ella. La pieza que faltaba era un campo que ya existía; no es una vulnerabilidad nueva del upstream, sino un error de despliegue.
El config.example.yaml documenta el valor, y la generación de direcciones vive en el código de inyección. Para corregirlo basta con fijar externalGatewayUrl a un dominio alcanzable desde el entorno que ejecuta las herramientas, con el proxy inverso reenviando las rutas bridge. Y hay que tocar la fuente de configuración persistente: editar un fichero que un script de arranque regenera no sirve de nada.
Conviene leer bien las sondas antes de tocar nada. Un 401 significa que hay un servicio HTTP que pide autenticación, no que la operación de memoria funcione. Un 000 significa que no hubo respuesta HTTP; no identifica una causa concreta, puede ser timeout, DNS o enrutado.
Las herramientas de conocimiento tienen sus propias URLs
Otro fallo de la misma investigación tenía causa distinta. Las herramientas para wiki o grafo de código usan URLs guardadas en el momento de registrar el recurso, y el inyector las copia tal cual. Cambiar externalGatewayUrl no actualiza esas direcciones. Cada una necesita su propia comprobación. El ejemplo del autor usaba host.docker.internal, una convención de Docker Desktop que en un entorno Linux sin la configuración correspondiente puede no resolver. La pregunta útil es si el nombre resuelve y conecta desde ese entorno concreto.
Ninguno de estos fallos apunta a que el almacenamiento de memoria esté dañado. El autor deja claro que le queda verificación por cerrar: tiene el diagnóstico y la corrección propuesta, pero no ha medido cuánto afectaba el fallback a la calidad de las respuestas.
