Memoria persistente para agentes IA con Qwen y MCP

La mayoría de los asistentes IA reinician cada sesión. Sirve para preguntas puntuales. Falla cuando quieres un compañero que recuerde cómo trabajas, qué decidiste la semana pasada y qué sigue pendiente.

En John CEO la memoria no es un extra. Cada cliente tiene un espacio de trabajo privado donde el contexto debería sobrevivir a reinicios, no evaporarse al cerrar el chat. Esa visión de producto nos llevó al hackathon Qwen Cloud (Track 1: MemoryAgent): una oportunidad de probar cómo podría funcionar la memoria semántica expuesta como herramientas estándar de agente.

Lo que sigue es un experimento de aprendizaje independiente, no un anuncio de producto. El código vive en un repo aparte con licencia MIT (qwen-memory-mcp). John CEO no lo usa hoy. En producción, la memoria permanece en el espacio de trabajo individualmente aislado de cada cliente, no en un servicio externo compartido. Construimos esto para aprender, tensionar ideas y compartir lo que encontramos.

Qué queríamos aprender

Buscábamos memoria que fuera:

  • Duradera - sobrevive reinicios y redeploys
  • Semántica - encuentra hechos relacionados, no solo palabras clave
  • Aislada - por usuario, sin mezclar datos
  • Fácil de integrar - herramientas MCP estándar, sin SDK propio

Las reglas del hackathon exigían infraestructura de Alibaba Cloud e inteligencia Qwen. Nuestra respuesta fue un servidor MCP pequeño: guardar recuerdos en una base de datos SQL gestionada, embederlos con Qwen y exponer cuatro herramientas invocables por HTTP.

Arquitectura

Arquitectura Qwen Memory MCP

Un cliente agente llama a un endpoint HTTPS público en Alibaba Function Compute. El servicio de memoria escribe filas en una base SQL gestionada y llama a Qwen Cloud (DashScope) para embeddings y ranking. El diseño es deliberadamente simple: MCP estándar por HTTP, almacén SQL detrás y Qwen en la capa semántica.

El experimento corre en ap-southeast-1 (Singapur), la región internacional de Alibaba Cloud. Mantuvimos el endpoint Qwen API, el compute y la base de datos en la misma región, fuera de China continental. Para un equipo europeo que construye para usuarios globales, esa elección regional fue deliberada: encaja con el endpoint internacional de DashScope y con cómo pensamos el manejo transfronterizo de datos. No es una certificación de cumplimiento - es un ajuste práctico para un experimento orientado al uso internacional.

Cuatro herramientas MCP

Herramienta Propósito
memory_write Guardar un recuerdo nuevo
memory_search Búsqueda semántica en la memoria
memory_recall_context Empaquetar los mejores recuerdos en un presupuesto de tokens
memory_forget Borrar toda la memoria de un usuario (privacidad / reset)

Cuatro herramientas ganan a una API enorme. Los agentes necesitan escribir, buscar, empaquetar contexto y olvidar - no veinte variantes CRUD con semántica solapada.

Memoria centralizada vs memoria en el espacio de trabajo

Comparamos este experimento MCP centralizado con la memoria local en el espacio de trabajo que ofrecemos a clientes de John CEO. Ambos apuntan al mismo objetivo - un compañero que recuerda - pero la forma del sistema cambia los tradeoffs.

  1. Modelo de aislamiento. Un servicio de memoria compartido con ids por usuario es rápido de demostrar y fácil de cablear vía MCP. Mantener la memoria en el espacio individualmente aislado de cada cliente refuerza los límites de datos.

  2. Dónde corren los embeddings. Embeddings vía API en la nube simplifican el arranque pero añaden latencia, coste y preguntas transfronterizas. La recuperación en el espacio de trabajo evita enviar texto crudo a un tercero.

  3. Recall consciente de la audiencia. Los compañeros reales operan en canales e hilos, no solo bajo un id de usuario. Memoria namespaced solo por usuario es más simple pero pierde contexto relevante en equipos.

  4. El ranking viaja bien. Combinar similitud, salience, recency y reinforcement mejoró el recall en ambas formas. El algoritmo importó más que la marca del almacén.

  5. El mantenimiento no es opcional. Pasadas de forget y decay evitan que la memoria crezca sin límite. Ambos diseños necesitan un ciclo de vida explícito.

  6. Superficie de herramientas. Cuatro herramientas MCP explícitas hicieron predecible la integración con agentes. Memoria implícita en archivos es flexible pero más difícil de usar de forma fiable.

Lo que nos sorprendió

  1. Los cold starts son reales. La primera llamada MCP tras inactividad en compute serverless puede tardar 10-20 segundos. Esa latencia es parte de la UX, no una nota al pie.

  2. MCP por HTTP no es JSON plano. Las respuestas pueden llegar como Server-Sent Events. Nuestros primeros scripts smoke asumían que curl | jq bastaría. No bastó. Añadimos un parser Node pequeño para manejar ambos formatos.

  3. La búsqueda semántica cambia la sensación del producto. La búsqueda por palabras clave falla en "¿cómo me gustan los borradores para clientes?" cuando el recuerdo guardado dice "mantener correos externos en tres párrafos cortos." Los embeddings cierran esa brecha.

  4. El presupuesto de tokens importa tanto como la recuperación. memory_recall_context no fue un apéndice. Los agentes reales chocan pronto con límites de contexto. Empaquetar los mejores recuerdos en un presupuesto gana a volcar diez hits de búsqueda en el prompt.

  5. Superficie pequeña gana. Una lista corta de herramientas ayuda tanto a la integración con agentes como a quien opera el sistema. Cuatro herramientas caben en memoria de trabajo.

Cómo John podría usar esto (hipotéticamente)

Por dentro esbozamos un patrón similar a las conexiones de apps: al arrancar el espacio de trabajo, entregar al agente una URL MCP acotada y un token bearer. La clave Qwen API y las credenciales SQL quedarían solo en Alibaba Cloud - nunca en el espacio privado del cliente. Los recuerdos de cada usuario se namespaciarían por id de cliente en el servidor compartido.

Ese blueprint está documentado pero no implementado y no está en la hoja de ruta. La memoria de John en producción sigue en el espacio individualmente aislado de cada cliente. Este experimento informó lo que queremos algorítmicamente (ranking, empaquetado de tokens, recall acotado) sin comprometer Qwen ni MCP en el producto en vivo.

Código abierto

El proyecto tiene licencia MIT en GitHub: qwen-memory-mcp

Clona el repo y sigue el README para ejecución local, pruebas de integración y notas de despliegue.

Verifícalo tú mismo

git clone https://github.com/John-CEO-HQ/qwen-memory-mcp
cd qwen-memory-mcp
npm install
cp .env.integration.example .env.integration
# Configura env según .env.integration.example
npm run verify:deployed

Deberías ver All checks passed. al final. Ese flujo prueba health, listado de tools, write, search, recall y forget contra el endpoint que configures en la documentación del repo.