OpenViking: Memoria + RAG para Agentes de IA

Todo stack de agentes que armo choca con la misma pared: la memoria vive en una librería, el conocimiento RAG en una vector DB, y los skills desparramados entre repos y prompts. OpenViking — la base de datos de contexto open-source de Volcengine con ~33K estrellas en GitHub — elimina esa fragmentación guardando las tres cosas como un solo filesystem virtual que tu agente recorre con ls, tree y find.

En esta guía te muestro qué es, cómo funcionan los tiers L0/L1/L2 y el retrieval recursivo, cómo correrlo en 5 minutos con comandos verificados, y cuándo NO deberías usarlo.

1. Qué Es OpenViking

OpenViking es una base de datos de contexto self-evolving para agentes de IA. En lugar de una vector store caja negra, expone todo — memoria de largo plazo, recursos ingeridos (docs, repos, páginas) y skills — como archivos bajo el protocolo viking://. Tu agente navega el contexto por paths deterministas en vez de rezar que el top-k devuelva el chunk correcto. Cada retrieval deja una trayectoria visible que podés inspeccionar y debuggear en el Web Studio.

Datos del repo (verificados Sep 2026)

Repositorio: github.com/volcengine/OpenViking
Estrellas: ~33K+ (trending semanal desde el lanzamiento)
Licencia: AGPL-3.0 core · Apache-2.0 CLI crates + ejemplos
Creado por: Volcengine (ByteDance)
Lanzamiento: Enero 2026
En una línea: “Memoria, recursos, skills. Todo es un archivo.”

Si leíste mi guía de Mem0, la diferencia en un párrafo: Mem0 es una capa de memoria enfocada — dos llamadas a la API, hechos con scope de usuario. OpenViking es todo el plano de contexto: memoria Y conocimiento RAG Y skills ejecutables, con carga jerárquica para que un repo de 200 archivos cueste tokens L0 hasta que el agente entra al único archivo que necesita.

La nota de licencia que casi nadie menciona

El core del servidor es AGPL-3.0 — perfecto para uso interno y self-hosting, pero si lo ofrecés como servicio hosteado debés devolver el código. Los crates del CLI y los ejemplos son Apache-2.0. Leé los archivos LICENSE antes de montar un wrapper comercial.

2. La Arquitectura en 4 Pasos

Cuatro ideas sostienen todo el diseño. Entendé estas y la documentación se lee sola:

🗂️

Paso 1 — Todo es un archivo (viking://)

Recursos, memorias de usuario y skills de agente viven en un solo árbol: viking://resources/…, viking://user/{id}/memories/…, viking://agent/skills/…. Los agentes usan paths deterministas y comandos estándar de filesystem en vez de queries vectoriales opacas.

🪜

Paso 2 — Tiers L0 / L1 / L2

Al ingerir, cada directorio genera un abstract L0 (~256 caracteres, para búsqueda vectorial) y un overview L1 (~4K caracteres, para rerank y navegación). L2 es el contenido completo, que se carga solo bajo demanda. Los repos grandes dejan de explotar tu context window.

🔍

Paso 3 — Retrieval recursivo, con comprobantes

La búsqueda vectorial encuentra directorios prometedores, después el motor baja con propagación de scores y devuelve resultados en su contexto estructural. find() es rápido; search() suma análisis de intención. Cada corrida guarda su trayectoria, así que las malas respuestas se pueden debuggear.

🧠

Paso 4 — Las sesiones se vuelven memoria; los skills se ejecutan

Commitear una sesión la archiva y destila perfil, preferencias, entidades y experiencia a memoria de largo plazo de forma asíncrona. Un skill es solo un directorio con SKILL.md — las herramientas MCP se convierten automáticamente y los skills compartidos viven en viking://agent/skills/.

El paradigma en una frase

Capa de almacenamiento pura, sin lógica de agente escondida: las escrituras se parsean e indexan de forma asíncrona, las lecturas pasan por análisis de intención más retrieval jerárquico, y el índice vectorial solo refleja el store de contenido AGFS.

3. Quickstart: Correrlo en 5 Minutos

Prerrequisitos: Python 3.10+ y Docker (para modo servidor). Instalá el paquete primero — uv es el default documentado:

uv tool install openviking --upgrade
# o: pip install openviking --upgrade --force-reinstall
# o: pipx install openviking

Inicializá la config, validala, y levantá el servidor (API en :1933, Web Studio en /studio):

openviking-server init
openviking-server doctor
openviking-server

# nueva terminal — debería devolver {"status": "ok"}
curl http://localhost:1933/health

¿Preferís Docker? Este es el servicio compose documentado (incluye el gateway vikingbot):

services:
  openviking:
    image: ghcr.io/volcengine/openviking:latest
    container_name: openviking
    ports:
      - "1933:1933"
    volumes:
      - ~/.openviking:/app/.openviking
    restart: unless-stopped

# después:
docker-compose up -d

Apuntá el CLI a tu servidor y cargá tu primer recurso — estos tres comandos son todo el modelo mental (agregar, explorar, preguntar):

openviking add-resource https://raw.githubusercontent.com/volcengine/OpenViking/refs/heads/main/README.md
openviking ls viking://resources
openviking find "what is openviking"

Y para clonar el repo — las integraciones con agentes (memory plugin de Claude Code, compile skills) viven en examples/:

git clone https://github.com/volcengine/OpenViking.git
cd OpenViking
ls examples  # claude-code-memory-plugin, dsh-memory-plugin, compile skills…

Tip: doctor antes de debuggear

Si el recall vuelve vacío, corré openviking-server doctor y pegale al endpoint /health antes de tocar la config — nueve de cada diez veces el servidor simplemente no está corriendo o el ovcli.conf apunta a la URL equivocada.

4. Dónde Brilla: Casos de Uso

OpenViking se paga solo donde uno — o muchos — agentes necesitan contexto compartido que crece:

💻

Memoria para coding agents

El memory plugin de Claude Code / Codex recuerda memorias relevantes antes de cada prompt y commitea las nuevas después — cross-proyecto, cross-sesión, sin tool calls del modelo.

📚

RAG de docs sin caja negra

Ingerí repos y docs como recursos; los sidecars L0/L1 más el retrieval recursivo le ganan al top-k plano en codebases grandes, y cada respuesta trae una trayectoria navegable.

🛠️

Una librería de skills de verdad

Distribuí capacidades como directorios SKILL.md — versionados, compartibles, con auto-conversión a MCP — en vez de copiar prompts entre proyectos.

👥

Contexto compartido multi-agente

Namespaces de usuario, peer y agente más snapshots y OVPack hacen el contexto portable entre agentes y restaurable después de una compactación.

🔌

Integraciones drop-in

Hermes trae provider de memoria OpenViking built-in; LangChain/LangGraph, clientes MCP, OpenClaw, Cursor y opencode son setups documentados.

🧪

Conocimiento compilable

ov compile convierte recursos crudos en artefactos derivados (ej. knowledge graphs) con reason + tracking de tareas — RAG que produce assets, no solo respuestas.

El patrón en los seis: contexto que arranca desordenado y se vuelve más útil cuanto más corre el agente — el loop self-evolving que promete el README.

5. Cuándo NO Usarlo

El proyecto me gusta, pero no es la respuesta a todo problema de memoria. Límites honestos:

❌ Evitalo cuando

• Solo necesitás “recordar preferencias del usuario” — las dos llamadas de Mem0 le ganan a correr todo un servidor con índice vectorial y AGFS.
• Lo vas a wrapear como SaaS hosteado — el core AGPL-3.0 obliga a compartir código; que legal lea LICENSE primero.
• Querés local cero-config — igual configurás providers de embedding + VLM en ov.conf (keys, dimensiones); es self-hosted, no libre de dependencias.
• Con RAG plano sobre unos PDFs alcanza — pgvector o Qdrant más buen chunking es más liviano (ver mi guía de chunking).
• Necesitás garantías de estabilidad de API — salió en enero 2026 y se mueve rápido (el endpoint /recall ya está deprecated).

✅ Usalo cuando

• Memoria + RAG + skills tienen que vivir en un solo lugar con un solo patrón de acceso.
• Los agentes navegan repos grandes donde el top-k plano pierde el contexto estructural.
• Debuggeás calidad de retrieval y querés trayectorias visibles, no caja negra.
• Múltiples agentes o sesiones comparten contexto que evoluciona (namespaces, snapshots, OVPack).
• Hacés self-hosting en tu infra o VPC y el AGPL es aceptable.

Regla de oro

Mem0 recuerda por vos; OpenViking es el filesystem donde viven tus agentes. Si tu contexto entra en llamadas a una API, quedate liviano. Si tus agentes necesitan un lugar donde vivir, dales Viking.

Conclusión

OpenViking es la apuesta open-source más ambiciosa sobre contexto de agentes hoy: un solo filesystem para memoria, conocimiento y skills, carga por tiers que respeta la context window, y retrieval que se puede debuggear de verdad. ~33K estrellas en ocho meses dicen que el dolor que ataca — la fragmentación del contexto — es real.

Empezá con el quickstart de arriba, cargá un repo real como recurso, y mirá una trayectoria en el Studio. Si el drill-down L0 → L1 → L2 te hace click, encontraste tu capa de contexto; si lo sentís pesado, Mem0 más buen chunking cubre el 80% de los casos.