OpenViking

Az OpenViking a Volcengine nyílt forrású kontextusadatbázisa AI-ügynököknek. Nem önmagában vektoradatbázis, és nem is egyetlen promptba betömött dokumentumhalmaz: a tudás, a memória és a skillek egyetlen virtuális fájlrendszerbe kerülnek viking:// URI alatt, amit az ügynök ugyanúgy bejár, mint a lemezt.

Két tulajdonságát érdemes kiemelni. Minden visszakereshető dolog megnyitható és szerkeszthető, tehát nem fekete doboz. A tartalom pedig rétegenként töltődik: az ügynök előbb a könyvtár összefoglalóját olvassa, és csak relevancia esetén nyitja meg a teljes forrást.

Mi ez pontosan

A kontextusnak három típusa van, mindegyik saját útvonalon:

• Resourcok (viking://resources/): dokumentumok, repók, weboldalak.
• Memóriák (viking://user/{user_id}/memories/): preferenciák, entitások, események és tapasztalat, amit a rendszer a munkamenetekből nyer ki. A peer-specifikus rész a peers/{peer_id}/ alatt van.
• Skillek: újrahasznosítható munkafolyamat-leírások, a megosztottak a viking://agent/skills/ alatt.

Minden fájl és könyvtár viking://{scope}/{path} formájú URI-t kap, a saját terület rövidítése viking://~/....

A tartalom rétegekben érkezik: az L0 a könyvtár absztraktja (.abstract.md), az L1 az áttekintés (.overview.md), az L2 az eredeti tartalom. Az L0 és L1 könyvtár szintű mellékfájl, nem minden fájlhoz tartozó összefoglaló, és a meglétük a feldolgozás állapotától függ.

A tárolás két rétegű: a tartalom a RAGFS fájlrendszerben van, a vektorindex pedig csak URI-kat, vektorokat és metaadatot tart. Az értelmezés (markdown, PDF, HTML, kód, kép, videó) nem hív LLM-et, a szemantikai réteg aszinkron generálódik.

Visszakeresés és memória

Két belépési pont van. A find egyetlen lekérdezést futtat munkamenet-kontextus nélkül, a search viszont az aktuális beszélgetésből indul: szándékelemzést végez, típusos lekérdezéseket gyárt, prioritási sorral járja be a könyvtárfát, végül rerankkel pontosít. A keresés rész-fára szűkíthető, tehát nem a teljes indexet pásztázza. A rerank dokumentáltan Volcengine backendhez kötött; ha nincs ilyen, a rendszer a vektoros pontszámokra esik vissza.

A memória a munkamenetekből épül. Az alkalmazás üzeneteket ír a sessionbe, majd commit()-ot hív: a szinkron rész archiválja a beszélgetést és task azonosítót ad vissza, a háttérben pedig elkészül az összefoglaló (L0/L1), és megtörténik a memóriakinyerés. A típusok között van profil, preferenciák, entitások, események, identitás, esetek és tapasztalatok. Minden commit memory_diff.json-t ír a hozzáadott, módosított és törölt memóriákról, így a változás visszakereshető.

Az API HTTP-alapú, Python, Go és TypeScript SDK-val, és ugyanazon a porton MCP végpont is fut (/mcp), több mint egy tucat eszközzel.

Üzemeltetés a gyakorlatban

• Az openviking-server init megírja a ~/.openviking/ov.conf fájlt, a doctor parancs pedig ellenőrzi a konfigurációt és az elérést. Szolgáltató lehet a Volcengine, az OpenAI, a Codex OAuth, a Kimi, a GLM vagy a helyi Ollama.
• A szerver alapból a 127.0.0.1:1933 címen figyel. Az életjel a GET /health, a készenlét a GET /ready végponton kérdezhető le, utóbbi a fájlrendszert, a vektoradatbázist, a kulcskezelőt és az embeddinget is ellenőrzi.
• A hivatalos konténerkép a ghcr.io/volcengine/openviking. Egyetlen kötet elegendő (~/.openviking:/app/.openviking), a port az API-t és a studio felületet (/studio) is kiszolgálja, és alapból indul a VikingBot átjáró, amit a --without-bot kapcsol ki.
• Ha a konténer a 0.0.0.0 címre köt, a root_api_key kötelező, enélkül a szerver nem indul. A repóban van systemd unit, docker-compose fájl és Helm chart is.
• A fő projekt AGPLv3, a CLI crate és az examples Apache 2.0 alatt van.

Hogyan illeszkedik a rendszerünkbe

Nálunk az OpenViking a visszakereshető kontextus és a hosszú távú memória rétege. Az ügynököt a Hermes Agent adja, az eszközöket MCPHub mögül érjük el, a gráfos, időbeli emlékezetet pedig Graphiti tartja; a kettő nem ugyanaz a feladat.

A dokumentációból tényleges korlátként ezek látszanak:

• Embedding modell kötelező, a memóriakinyeréshez VLM kell, tehát a feldolgozás külső modellszolgáltatóktól függ.
• Python 3.10 vagy újabb kell, a RAGFS kötést pedig Rust eszközlánccal kell fordítani, ha nincs a wheelben.
• Az L0/L1 réteg nem azonnal és nem feltétlenül minden könyvtárra készül el.
• Reverse proxy mögött az OPENVIKING_PUBLIC_BASE_URL változót külön be kell állítani, különben a feltöltési URL a belső címre mutat.
• A dokumentáció maga jelzi, hogy a szülő-összefoglalók frissítése felfelé terjed, ami mély, sűrűn változó fában írási amplifikációt okozhat.
• A rerank és a javasolt modellek erősen a Volcengine ökoszisztémájához kötődnek.

Tovább olvasás

• OpenViking a GitHubon: a README, a gyors indítás és az integrációs lista.
• Introduction: a kontextustípusok, a rétegmodell és a session-alapú memória áttekintése.
• Architecture Overview: a szolgáltatásréteg, a kétlépcsős visszakeresés és a két rétegű tárolás leírása.

Nálunk a CyberElectro a visszatérő projektkontextust és a döntések hátterét tartja OpenVikingben, hogy egy új munkamenet ne a nulláról induljon.