Hemos extraído el sistema de memoria de OpenClaw y lo hemos puesto en código abierto (memsearch)
OpenClaw (antes clawdbot y moltbot) se está volviendo viral: más de 189.000 estrellas de GitHub en menos de dos semanas. Es una locura. La mayor parte de la expectación gira en torno a sus capacidades autónomas y ágiles en los canales de chat cotidianos, como iMessages, WhatsApp, Slack, Telegram y otros.
Pero como ingenieros que trabajamos en un sistema de base de datos vectorial, lo que realmente nos llamó la atención fue el enfoque de OpenClaw sobre la memoria a largo plazo. A diferencia de la mayoría de los sistemas de memoria que existen, OpenClaw hace que su IA escriba automáticamente registros diarios como archivos Markdown. Esos archivos son la fuente de la verdad, y el modelo sólo "recuerda" lo que se escribe en el disco. Los desarrolladores humanos pueden abrir esos archivos Markdown, editarlos directamente, destilar principios a largo plazo y ver exactamente lo que la IA recuerda en cualquier momento. Sin cajas negras. Sinceramente, es una de las arquitecturas de memoria más limpias y fáciles de desarrollar que hemos visto.
Así que, naturalmente, nos hicimos una pregunta: ¿por qué debería funcionar esto sólo dentro de OpenClaw? ¿Y si cualquier agente pudiera tener una memoria como ésta? Tomamos la arquitectura de memoria exacta de OpenClaw y creamos memsearch, una biblioteca de memoria a largo plazo independiente, plug-and-play, que proporciona a cualquier agente una memoria persistente, transparente y editable por humanos. No depende del resto de OpenClaw. Sólo tiene que colocarla y su agente obtendrá una memoria duradera con búsqueda impulsada por Milvus/Zilliz Cloud, además de registros Markdown como fuente canónica de la verdad.
GitHub Repo: github.com/zilliztech/memsearch (código abierto, licencia MIT)
Documentación: https://zilliztech.github.io/memsearch/
Plugin de código Claude: https://zilliztech.github.io/memsearch/claude-plugin/
Qué hace diferente a la memoria de OpenClaw
Antes de sumergirnos en la arquitectura de memoria de OpenClaw, aclaremos dos conceptos: contexto y memoria. Suenan similares pero funcionan de forma muy diferente en la práctica.
Contexto es todo lo que el agente ve en una única petición - avisos del sistema, archivos de guía a nivel de proyecto como
AGENTS.mdySOUL.md, historial de conversaciones (mensajes, llamadas a herramientas, resúmenes comprimidos), y el mensaje actual del usuario. Está limitado a una sesión y es relativamente compacto.La memoria es lo que persiste a lo largo de las sesiones. Vive en el disco local: el historial completo de conversaciones anteriores, los archivos con los que ha trabajado el agente y las preferencias del usuario. No está resumida. Sin comprimir. El material en bruto.
Esta es la decisión de diseño que hace especial el enfoque de OpenClaw: toda la memoria se almacena como archivos Markdown en el sistema de archivos local. Después de cada sesión, la IA escribe automáticamente actualizaciones en esos registros Markdown. Usted -y cualquier desarrollador- puede abrirlos, editarlos, reorganizarlos, borrarlos o perfeccionarlos. Mientras tanto, la base de datos vectorial se asienta junto a este sistema, creando y manteniendo un índice para su recuperación. Cada vez que cambia un archivo Markdown, el sistema detecta el cambio y lo vuelve a indexar automáticamente.
Si has utilizado herramientas como Mem0 o Zep, notarás la diferencia de inmediato. Esos sistemas almacenan las memorias como incrustaciones: ésa es la única copia. No puedes leer lo que tu agente recuerda. No puedes arreglar un mal recuerdo editando una fila. El enfoque de OpenClaw te ofrece ambas cosas: la transparencia de los archivos planos y la capacidad de recuperación de la búsqueda vectorial mediante una base de datos vectorial. Puedes leerlo, git diff, grep it - son sólo archivos.
¿El único inconveniente? Ahora mismo este sistema de memoria Markdown-first está estrechamente entrelazado con todo el ecosistema OpenClaw: el proceso Gateway, los conectores de plataforma, la configuración del espacio de trabajo y la infraestructura de mensajería. Si sólo quieres el modelo de memoria, es un montón de maquinaria que arrastrar.
Precisamente por eso hemos creado memsearch: la misma filosofía -Markdown como fuente de verdad, indexación automática de vectores, totalmente editable por humanos- pero en forma de biblioteca ligera e independiente que puede integrarse en cualquier arquitectura agéntica.
Cómo funciona memsearch
Como se mencionó anteriormente, memsearch es una biblioteca de memoria a largo plazo totalmente independiente que implementa la misma arquitectura de memoria utilizada en OpenClaw, sin llevar consigo el resto de la pila de OpenClaw. Puede conectarla a cualquier estructura de agentes (Claude, GPT, Llama, agentes personalizados, motores de flujo de trabajo) y dotar instantáneamente a su sistema de una memoria persistente, transparente y editable por el ser humano.
Toda la memoria del agente en memsearch se almacena como texto plano Markdown en un directorio local. La estructura es intencionadamente simple para que los desarrolladores puedan entenderla de un vistazo:
~/your-project/
└── memory/
├── MEMORY.md # Hand-written long-term memory
├── 2026-02-09.md # Today's work log
├── 2026-02-08.md
└── 2026-02-07.md
Memsearch utiliza Milvus como base de datos vectorial para indexar estos archivos Markdown para una rápida recuperación semántica. Pero lo más importante es que el índice vectorial no es la fuente de la verdad, sino los archivos. Si se elimina por completo el índice Milvus, no se pierde nada. Memsearch simplemente vuelve a incrustar y a indexar los archivos Markdown, reconstruyendo toda la capa de recuperación en unos minutos. Esto significa que la memoria de su agente es transparente, duradera y totalmente reconstruible.
Estas son las principales capacidades de memsearch:
Markdown legible hace que la depuración sea tan sencilla como editar un archivo
La depuración de la memoria de la IA suele ser dolorosa. Cuando un agente produce una respuesta errónea, la mayoría de los sistemas de memoria no ofrecen una forma clara de ver lo que realmente almacenó. El flujo de trabajo típico consiste en escribir código personalizado para consultar una API de memoria y, a continuación, escudriñar incrustaciones opacas o ampulosos blobs JSON, ninguno de los cuales dice mucho sobre el estado interno real de la IA.
memsearch elimina toda esa clase de problemas. Toda la memoria vive en la carpeta memory/ como Markdown plano:
## Morning
- Fixed N+1 query issue — switched to selectinload()
- Query count dropped from 152 to 3
Si la IA hace algo mal, arreglarlo es tan sencillo como editar el archivo. Actualiza la entrada, guarda, y memsearch automáticamente vuelve a indexar el cambio. Cinco segundos. Sin llamadas a la API. Sin herramientas. Ningún misterio. Puede depurar la memoria de IA del mismo modo que depura la documentación: editando un archivo.
La memoria respaldada por Git permite a los equipos rastrear, revisar y revertir cambios
La memoria de IA que vive en una base de datos es difícil de colaborar. Averiguar quién cambió qué y cuándo significa excavar en los registros de auditoría, y muchas soluciones ni siquiera los proporcionan. Los cambios se producen en silencio, y los desacuerdos sobre lo que la IA debe recordar no tienen una vía de resolución clara. Los equipos acaban confiando en los mensajes de Slack y en suposiciones.
Memsearch soluciona este problema convirtiendo la memoria en archivos Markdown, lo que significa que Git gestiona el versionado automáticamente. Un solo comando muestra todo el historial:
git log memory/MEMORY.md
git diff HEAD~1 memory/2026-02-09.md
Ahora la memoria de IA participa en el mismo flujo de trabajo que el código. Las decisiones de arquitectura, las actualizaciones de configuración y los cambios de preferencias aparecen en diffs que cualquiera puede comentar, aprobar o revertir:
+ ## Architecture Decision
+ - Use Kafka for event bus instead of RabbitMQ
+ - Reason: better horizontal scaling
La memoria Plaintext hace que la migración sea casi sin esfuerzo
La migración es uno de los mayores costes ocultos de los frameworks de memoria. Pasar de una herramienta a otra suele implicar exportar datos, convertir formatos, volver a importar y esperar que los campos sean compatibles. Ese tipo de trabajo puede consumir fácilmente medio día, y el resultado nunca está garantizado.
memsearch evita el problema por completo porque la memoria es Markdown en texto plano. No hay formato propietario, ni esquema que traducir, ni nada que migrar:
Cambia de máquina:
rsyncla carpeta de memoria. Hecho.Cambia de modelo de incrustación: Vuelva a ejecutar el comando de índice. Tardará cinco minutos, y los archivos markdown permanecen intactos.
Cambiar el despliegue de la base de datos vectorial: Cambie un valor de configuración. Por ejemplo, pasar de Milvus Lite en desarrollo a Zilliz Cloud en producción:
# Development
ms = MemSearch(milvus_uri="~/.memsearch/milvus.db")
# Production (change only this line)
ms = MemSearch(milvus_uri=“https://xxx.zillizcloud.com”)
Sus archivos de memoria permanecen exactamente igual. La infraestructura que los rodea puede evolucionar libremente. El resultado es la portabilidad a largo plazo, una propiedad poco común en los sistemas de IA.
Los archivos Markdown compartidos permiten a humanos y agentes ser coautores de la memoria
En la mayoría de las soluciones de memoria, editar lo que la IA recuerda requiere escribir código en una API. Esto significa que sólo los desarrolladores pueden mantener la memoria de la IA, e incluso para ellos resulta engorroso.
Memsearch permite una división de responsabilidades más natural:
La IA se encarga: Registros diarios automáticos (
YYYY-MM-DD.md) con detalles de ejecución como "desplegada v2.3.1, mejora del rendimiento del 12%".Los humanos se encargan: Principios a largo plazo en
MEMORY.md, como "Team stack: Python + FastAPI + PostgreSQL".
Ambas partes editan los mismos archivos Markdown con las herramientas que ya utilizan. Sin llamadas a API, sin herramientas especiales, sin guardián. Cuando la memoria está bloqueada dentro de una base de datos, este tipo de autoría compartida no es posible. memsearch lo hace por defecto.
Bajo el capó: memsearch funciona con cuatro flujos de trabajo que mantienen la memoria rápida, fresca y ágil
memsearch tiene cuatro flujos de trabajo principales: Observar (monitorizar) → Indexar (trocear e incrustar) → Buscar (recuperar) → Compactar (resumir). Esto es lo que hace cada uno de ellos
1. Observar: Vuelve a indexar automáticamente cada vez que se guarda un archivo
El flujo de trabajo Watch monitoriza todos los archivos Markdown en la memoria/directorio y activa un re-indexado cada vez que un archivo es modificado y guardado. Un retardo de 1500 ms garantiza que las actualizaciones se detecten sin malgastar recursos: si se guardan varios archivos en rápida sucesión, el temporizador se reinicia y se activa sólo cuando las ediciones se han estabilizado.
Este retraso se ajusta empíricamente:
100ms → demasiado sensible; se dispara en cada pulsación de tecla, quemando llamadas de incrustación.
10s → demasiado lento; los desarrolladores notan retraso
1500ms → equilibrio ideal entre capacidad de respuesta y eficiencia de recursos.
En la práctica, esto significa que un desarrollador puede escribir código en una ventana y editar MEMORY.md en otra, añadiendo una URL de API docs o corrigiendo una entrada obsoleta. Guarda el archivo y la siguiente consulta de IA recoge la nueva memoria. Sin reinicios ni reindexación manual.
2. Índice: Agrupación, deduplicación e incrustación inteligente en función de la versión
Index es el flujo de trabajo crítico para el rendimiento. Se encarga de tres cosas: la fragmentación, la deduplicación y los identificadores de fragmentos versionados.
La fragmentación divide el texto a lo largo de los límites semánticos -encabezamientos y cuerpos- para que el contenido relacionado permanezca unido. Esto evita casos en los que una frase como "configuración de Redis" se divide en varios chunks.
Por ejemplo, este Markdown:
## Redis Caching
We use Redis for L1 cache with 5min TTL.
The connection pool is configured with max 100 connections.
## Database
PostgreSQL 16 is the primary database.
Se convierte en dos trozos:
Fragmento 1:
## Redis Caching\nWe use Redis for L1 cache...Fragmento 2:
## Database\nPostgreSQL 16 is the primary database.
La deduplicación utiliza un hash SHA-256 de cada chunk para evitar incrustar el mismo texto dos veces. Si varios archivos mencionan "PostgreSQL 16", la API de incrustación se llama una vez, no una vez por archivo. Para ~500KB de texto, esto ahorra alrededor de $0.15/mes. A escala, eso suma cientos de dólares.
El diseño del Chunk ID codifica todo lo necesario para saber si un chunk es antiguo. El formato es hash(source_path:start_line:end_line:content_hash:model_version). El campo model_version es la parte importante: cuando un modelo de incrustación se actualiza de text-embedding-3-small a text-embedding-3-large, las antiguas incrustaciones dejan de ser válidas. Dado que la versión del modelo está integrada en el ID, el sistema identifica automáticamente los fragmentos que deben volver a incrustarse. No es necesaria ninguna limpieza manual.
3. 3. Búsqueda: Recuperación híbrida de vectores + BM25 para obtener la máxima precisión
La recuperación utiliza un enfoque de búsqueda híbrido: búsqueda vectorial ponderada al 70% y búsqueda de palabras clave BM25 ponderada al 30%. De este modo se equilibran dos necesidades diferentes que surgen con frecuencia en la práctica.
Labúsqueda v ectorial se encarga de la correspondencia semántica. Una consulta sobre "Redis cache config" devuelve un chunk que contiene "Redis L1 cache with 5min TTL" aunque la redacción sea diferente. Esto es útil cuando el desarrollador recuerda el concepto pero no la formulación exacta.
BM25 gestiona la correspondencia exacta. Una consulta para "PostgreSQL 16" no devuelve resultados sobre "PostgreSQL 15". Esto es importante para los códigos de error, los nombres de las funciones y el comportamiento específico de la versión, donde lo cercano no es suficiente.
La división por defecto 70/30 funciona bien para la mayoría de los casos de uso. Para los flujos de trabajo que se inclinan en gran medida hacia las coincidencias exactas, aumentar el peso de BM25 al 50% es un cambio de configuración de una sola línea.
Los resultados se devuelven en trozos top-K (por defecto 3), cada uno truncado a 200 caracteres. Cuando se necesita el contenido completo, memsearch expand <chunk_hash> lo carga. Esta revelación progresiva mantiene el uso reducido de la ventana contextual LLM sin sacrificar el acceso a los detalles.
4. Compacta: Resumir la memoria histórica para mantener limpio el contexto
La memoria acumulada acaba convirtiéndose en un problema. Las entradas antiguas llenan la ventana de contexto, aumentan el coste de los tokens y añaden ruido que degrada la calidad de la respuesta. Compact soluciona este problema llamando a un LLM para que resuma la memoria histórica en un formato condensado y, a continuación, borrando o archivando los originales. Puede activarse manualmente o programarse para que se ejecute a intervalos regulares.
Cómo empezar a utilizar memsearch
Memsearch proporciona tanto una API Python como una CLI, por lo que puedes utilizarlo dentro de frameworks de agentes o como una herramienta de depuración independiente. La configuración es mínima, y el sistema está diseñado para que su entorno de desarrollo local y el despliegue de producción parezcan casi idénticos.
Memsearch soporta tres backends compatibles con Milvus, todos expuestos a través de la misma API:
Milvus Lite (por defecto): Archivo local
.db, configuración cero, adecuado para uso individual.Milvus Standalone / Cluster: Autoalojado, soporta múltiples agentes que comparten datos, adecuado para entornos de equipo.
Zilliz Cloud: Totalmente gestionado, con autoescalado, copias de seguridad, alta disponibilidad y aislamiento. Ideal para cargas de trabajo de producción.
El cambio de desarrollo local a producción suele ser un cambio de configuración de una sola línea. Su código sigue siendo el mismo.
Instalar
pip install memsearch
memsearch también soporta múltiples proveedores de incrustación, incluyendo OpenAI, Google, Voyage, Ollama y modelos locales. Esto asegura que su arquitectura de memoria se mantiene portátil y agnóstica.
Opción 1: API Python (integrada en el marco de trabajo del agente)
Aquí tienes un ejemplo mínimo de un bucle de agente completo utilizando memsearch. Puedes copiar/pegar y modificar según necesites:
from openai import OpenAI
from memsearch import MemSearch
llm = OpenAI()
ms = MemSearch(paths=[“./memory/”])
async def agent_chat(user_input: str) -> str:
# 1. Recall — search relevant memories
memories = await ms.search(user_input, top_k=3)
context = “\n”.join(f"- {m[‘content’][:200]}" for m in memories)
<span class="hljs-comment"># 2. Think — call LLM</span>
resp = llm.chat.completions.create(
model=<span class="hljs-string">"gpt-4o-mini"</span>,
messages=[
{<span class="hljs-string">"role"</span>: <span class="hljs-string">"system"</span>, <span class="hljs-string">"content"</span>: <span class="hljs-string">f"Memories:\n<span class="hljs-subst">{context}</span>"</span>},
{<span class="hljs-string">"role"</span>: <span class="hljs-string">"user"</span>, <span class="hljs-string">"content"</span>: user_input},
],
)
<span class="hljs-comment"># 3. Remember — write to markdown, update index</span>
save_memory(<span class="hljs-string">f"## <span class="hljs-subst">{user_input}</span>\n<span class="hljs-subst">{resp.choices[<span class="hljs-number">0</span>].message.content}</span>"</span>)
<span class="hljs-keyword">await</span> ms.index()
<span class="hljs-keyword">return</span> resp.choices[<span class="hljs-number">0</span>].message.content
Muestra el bucle central:
Recuerda: memsearch realiza una recuperación híbrida de vector + BM25
Piensa: tu LLM procesa la entrada del usuario + la memoria recuperada
Recuerda: el agente escribe nueva memoria en Markdown, y memsearch actualiza su índice
Este patrón encaja de forma natural en cualquier sistema de agente: LangChain, AutoGPT, enrutadores semánticos, LangGraph o bucles de agente personalizados. Su diseño es independiente del marco de trabajo.
Opción 2: CLI (operaciones rápidas, bueno para depuración)
La CLI es ideal para flujos de trabajo autónomos, comprobaciones rápidas o inspección de memoria durante el desarrollo:
memsearch index ./docs/ # Index files
memsearch search "Redis caching" # Search
memsearch watch ./docs/ # Watch for file changes
memsearch compact # Compact old memory
La CLI refleja las capacidades de la API de Python, pero funciona sin necesidad de escribir ningún código: ideal para depuración, inspecciones, migraciones o validación de la estructura de carpetas de memoria.
Comparación de memsearch con otras soluciones de memoria
La pregunta más común que se hacen los desarrolladores es por qué utilizar memsearch cuando ya existen opciones establecidas. La respuesta corta: memsearch cambia características avanzadas como los gráficos de conocimiento temporal por transparencia, portabilidad y simplicidad. Para la mayoría de los casos de uso de la memoria de agentes, es el compromiso correcto.
| Solución | Puntos fuertes | Limitaciones | Lo mejor para |
|---|---|---|---|
| memsearch | Memoria de texto plano transparente, co-autoría humano-AI, cero fricciones de migración, depuración sencilla, Git-native | No incorpora grafos temporales ni complejas estructuras de memoria multiagente. | Equipos que valoran el control, la simplicidad y la portabilidad en la memoria a largo plazo |
| Mem0 | Totalmente gestionado, sin infraestructura que ejecutar o mantener | Opaca: no se puede inspeccionar ni editar manualmente la memoria; las incrustaciones son la única representación. | Equipos que desean un servicio gestionado sin intervención y están de acuerdo con una menor visibilidad |
| Zep | Amplio conjunto de funciones: memoria temporal, modelado multipersona, grafos de conocimiento complejos. | Arquitectura pesada; más piezas móviles; más difícil de aprender y manejar | Agentes que realmente necesitan estructuras de memoria avanzadas o razonamiento temporal |
| LangMem / Letta | Integración profunda y sin fisuras en sus propios ecosistemas. | Bloqueo del marco; difícil de portar a otras pilas de agentes. | Equipos ya comprometidos con esos marcos específicos. |
Pruebe memsearch y háganos llegar sus comentarios
Memsearch es completamente de código abierto bajo la licencia MIT, y el repositorio está listo para experimentos de producción hoy mismo.
Documentación: zilliztech.github.io/memsearch
Si estás construyendo un agente que necesita recordar cosas entre sesiones y quieres un control total sobre lo que recuerda, merece la pena echar un vistazo a memsearch. La librería se instala con un simple pip install, funciona con cualquier framework de agente, y almacena todo como Markdown que puedes leer, editar y versionar con Git.
Estamos desarrollando memsearch activamente y nos encantaría recibir aportaciones de la comunidad.
Abre una incidencia si algo se rompe.
Envía un PR si quieres extender la librería.
Haz una estrella en el repositorio si la filosofía de Markdown-como-fuente-de-la-verdad resuena contigo.
El sistema de memoria de OpenClaw ya no está bloqueado dentro de OpenClaw. Ahora, cualquiera puede usarlo.
Seguir leyendo
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word
