Intervjuer: „Koja je razlika između Memory i RAG u OpenClaw-u?“ Ja sam nonšalantno odgovorio: „Jedno koristi SQLite, drugo ElasticSearch.“ Intervjuer: „Sutra drugi krug.“

Stari Wang je započeo direktno: „Memory i RAG u OpenClaw-u su veoma slični, da li to poznaješ?“

Kroz debeole naočare za kratkovidost, susreo sam se sa Wangovim očima koje su još uvek bile pune entuzijazma prema svetu; razumeo sam šta želi da čuje: „Naravno; hibridna pretraga koristi vektore i ključne reči, slično kao moj PaiSmart RAG; takođe ima FTS5, BM25, rerank i slično.“

„Ti dečko, izgleda da si pripremio zadaću.“ Stari Wang je namestio naočare, protrljao ruke i nastavio: „OpenClaw Memory je podeljen u dva sloja — jedan je na nivou sesije, drugi je dugoročna memorija; koja je razlika među njima?“

Moram priznati, Stari Wang nije od onih površnih intervjuača; zaista je proučavao i ima tehničku želju.

content

01. Koja je razlika između Memory i Session?

„Wang brate, Memory je jedan od najjezgrenijih mehanizama OpenClaw-a; njime Agent dobija sposobnost ‚pamćenja‘.“

Kratkoročna memorija

Kratkoročna memorija se čuva u fajlu ~/.openclaw/agents/{agentId}/sessions/*.jsonl; beleži se automatski.

Pri svakom razgovoru sa jastogom, OpenClaw automatski dodaje sadržaj razgovora u dnevnik sesije u JSONL formatu; to je najsirovija, neobrađena memorija.

Dugoročna memorija

Dugoročna memorija se čuva u fajlovima ~/.openclaw/workspace/MEMORY.md i memory/*.md; može se kreirati ručno, ali se obično prepusti OpenClaw-u da je generiše automatski.

Može se shvatiti kao sadržaj izvučen iz kratkoročnih, svakodnevnih sećanja koji OpenClaw treba posebno da zapamti — na primer korisnikov karakter, podatke o identitetu, preference u odgovaranju itd.

Na primer, kažete Agentu: „Ja sam Java backend programer; pri odgovaranju na pitanja koristite tehnološki stek povezan sa Java-om.“ Ta rečenica se izdvaja u dugoročnu memoriju i čuva u Markdown fajlu. Pri sledećem razgovoru, jastog automatski pronalazi to sećanje i odgovara prema vašim preferencama.

Stari Wang je nastavio: „A kako se vrši pretvaranje između dugoročne i kratkoročne memorije?“

Rekao sam: „Wang brate, zaista si proučavao.“

02. Kako memorija automatski prelazi iz jedne u drugu?

„Postoje dva mehanizma okidanja za pretvaranje memorije.“

Mehanizam 1: session-memory Hook

Kada korisnik izvrši komandu /new da resetuje sesiju, OpenClaw aktivira session-memory Hook koji automatski pretvara ključni sadržaj prethodne sesije u Markdown fajl.

Ovaj proces je automatizovan i ne zahteva ručno uplitanje. Sistem analizira sadržaj razgovora u JSONL fajlu, izdvaja ključne informacije — korisničke preferencije, važan kontekst, činjenice koje treba dugoročno zapamtiti — i zatim ih upisuje u fajl memory/YYYY-MM-DD.md.

Mehanizam 2: Memory Flush

Ovo je jedan od ključnih mehanizama automatizacije.

Kada Session priđe limitu context-a, OpenClaw aktivira mehanizam Compaction. Agent analizira sadržaj trenutne sesije, izdvaja važne informacije i upisuje ih u Memory.

Stari Wang je klimnuo glavom: „A kako se ti Markdown fajlovi pretražuju? Zar ne prelaziš svaki put sve fajlove?“

03. Kako se zapravo gradi indeks Memory-ja?

„Wang brate, pravi izazov nije ‚zapamtiti‘, već ‚sledeći put uspeti da ga pronadeš među stotinama fajlova‘.“

OpenClaw ovako tretira Memory:

• Markdown fajlovi su telo memorije, odnosno source of truth.
• SQLite je sloj za ubrzanje, zadužen za to da te Markdown-ove pretvori u nešto „pretraživo“.

Oni koji ne poznaju sistem pomisliće da je SQLite sam Memory, ali nije tako.

Ti Markdown fajlovi su zapravo Memory; pri čemu

• MEMORY.md: beleži dugoročnu memoriju, više „zaključke“ i „preferencije“
• memory/YYYY-MM-DD.md pripada dnevničkoj memoriji, više „šta se desilo tog dana“

OpenClaw ne „skenira direktorijum pri svakom upitu“, već unapred Markdown seče na komade, gradi indeks i smešta ga u SQLite fajl. Kada Agent zaista želi da pretraži istoriju, dovoljno je da pretraži indeks; ne može se pretraživati samo po ključnoj reči, već i po semantici — takav Agent je vrlo inteligentan.

Iz komandne linije to još direktnije izgleda:

openclaw memory status

Ova komanda nam govori da li Memory trenutno radi, koji model se koristi, koliko je indeksa izgrađeno, gde se nalazi fajl baze, te da li rade pretraga celog teksta i vektorska pretraga.

Na mojoj mašini trenutno se vidi:

Provider: openai (requested: openai)
Model: nomic-embed-text
Store: ~/.openclaw/memory/paismart.sqlite
Indexed: 8/8 files · 14 chunks
Vector: ready
FTS: ready

Provider: openai (requested: openai) znači da provajder embedding-a koga memorija koristi pripada openai interfejsu.

Model: nomic-embed-text pokazuje da je model koji zapravo radi vektorizaciju nomic-embed-text.

Store: ~/.openclaw/memory/paismart.sqlite znači da se indeks memorije zapravo čuva u tom SQLite fajlu.

Indexed: 8/8 files · 14 chunks znači da je ukupno otkriveno 8 memory fajlova, svi imaju izgrađen indeks, ukupno isečeni na 14 tekstualnih blokova.

Vector: ready znači da vektorska pretraga radi normalno, odnosno da deo za semantičku pretragu funkcioniše.

FTS: ready znači da i pretraga celog teksta radi normalno. FTS je Full-Text Search — pretraga celog teksta.

Stari Wang je sa sve većim poverenjem nastavio: „Šta se zapravo radi pri Embedding-u?“

Šta se zapravo radi pri izgradnji indeksa?

Može se podeliti u četiri koraka.

Prvi korak, otkrivanje.

OpenClaw prati promene u MEMORY.md i memory/*.md. Ako se pojavi novi fajl ili se sadržaj fajla ažurira, taj fajl se označava kao dirty i priprema za ponovnu izgradnju indeksa.

Drugi korak, sečenje na komade.

Markdown se seče na više chunk-ova, tako da „jedan blok izražava samo jednu relativno celu misao“.

Treći korak, indeksiranje.

Svaki chunk prolazi ne samo kroz embedding, već istovremeno i kroz pretragu celog teksta:

• jedan tok ulazi u vektorski indeks, zadužen za „nalazi čak i kada je značenje slično“
• drugi tok ulazi u FTS indeks celog teksta, zadužen za „precizno pogadanje ključne reči“

Drugim rečima, OpenClaw ne radi samo vektorsku pretragu, niti samo pretragu ključnih reči, već hibridnu pretragu.

Četvrti korak, upis u bazu.

Konačno, svi ti chunk-ovi, metapodaci, indeksi celog teksta i vektorski indeksi se smeštaju u lokalni SQLite.

Stari Wang klimnu glavom: „A kako se zapravo pretražuje? Čisto vektorski, ili po ključnoj reči?“

Rekao sam: „Hibridna pretraga.“

04. Zašto je hibridna pretraga pouzdanija od čisto vektorske?

Najjednostavniji primer.

Ako pretražujemo: memory_search("nomic-embed-text")

Ključ ovakvog upita nije u „semantičkoj bliskosti“, već u tome da „ova niska karaktera mora da pogodi“.

Ako se oslonimo samo na vektorsku pretragu, ona može izvući „embedding model“, „lokalni vektorski indeks“, „OpenAI provajder“ — svi slični po značenju, ali može upravo izostaviti najvažnije poklapanje ključne reči.

Ako se pretražuje:

Koja je preference u pisanju članaka za koju sam poslednji put pitao?

Onda pretraga ključnih reči nije dovoljna, jer korisnik ne mora da upotrebi originalne izraze poput „pričati polako“, „ređe koristi ti, češće vi i mi“.

Zato je pristup OpenClaw-a:

• FTS5 + BM25 zadužen za precizno pogađanje termina
• sqlite-vec zadužen za semantički slično vraćanje rezultata
• konačno se rezultati sa obe strane stapaju i vraćaju

Zašto FTS5?

Zato što je FTS5 SQLite-a u suštini lagani pretraživač celog teksta.

Brži je od LIKE '%xxx%' i zna „koje su reči važnije, koji rezultati treba da budu napred“.

Vrednost BM25 leži upravo u tome.

Reč koja se pojavi 10 puta nije nužno važnija od one koja se pojavi 2 puta; već se kombinuje:

• učestalost reči
• dužina dokumenta
• koliko je ta reč retka u celom korpusu

Tako Terms kao što su memory_flush, session-memory, nomic-embed-text koji su prilično retki, prirodno imaju veću težinu.

Zašto još sqlite-vec?

Zato što FTS5 uglavnom rešava problem „pogađanja po tekstu“, a ne može da reši problem semantičkog poklapanja:

• „ono iz prošlosti“
• „preferenca koju si zapamtio“
• „zar nisam rekao da ne želim taj stil pisanja“

Ovakvi načini postavljanja pitanja ne moraju na teksualnom nivou da se poklope sa originalom, ali su semantički bliski. Tu se pokazuje vrednost embedding-a.

On prvo vektorizuje upit, zatim sa svakim chunk vektorom radi poređenje susedstva i izvlači semantički bliske fragmente. Grubo rečeno:

upit
  ↓
embedding(upit)
  ↓
računanje rastojanja sa svakim vektorom u chunks_vec
  ↓
uzmi top-k

Ovakav sistem, ako bi se prebacio u SaaS proizvod, zahtevao bi zasebnu vektorsku bazu podataka; na primer PaiSmart RAG koristi ElasticSearch.

Ali OpenClaw to nije uradio.

Koristi SQLite ekstenziju poput sqlite-vec i smešta sposobnost vektorske pretrage u lokalni SQLite.

Stari Wang se nasmejao: „U redu, koncepte si objasnio. A kako Agent zapravo koristi tu Memory?“

05. Kako Agent koristi memoriju nakon što je pretraži?

„Wang brate, ovaj korak je mesto gde Memory zaista iskazuje vrednost.“

Mnogi misle da je kraj sistema memorije u „pronalaženju“. Nije.

OpenClaw uglavnom izlaže Agentu dva alata:

1) memory_search

Kada Agent ustanovi da pitanje dotiče prošle odluke, preference, istorijski kontekst, on ne čita ceo memory/ direktorijum, već prvo pokreće semantičku pretragu.

Na primer:

memory_search("preference Erge-a u pisanju članaka")

Ne vraća ceo sadržaj, većnajrelevantnije isečke (snippet) + putanju fajla + opseg redova.

Ovo ima dve prednosti:

• kontrola tokena, da se cela istorija ne ubaci odjednom u kontekst
• prvo grubo vraćanje rezultata, pronalazi mesto „vredno detaljnijeg čitanja“

2) memory_get

Ako memory_search vrati da su ključne informacije u:

• MEMORY.md#L1-L16
• memory/2026-03-19.md#L20-L48

Onda Agent u sledećem koraku može iskoristiti memory_get da pročita konkretne redove i pasuse.

Obratite pažnju, ovde postoji jedna lako zanemarena stvar:

Sam fajl Memory se ne ubacuje u celosti u svakom krugu.

Dnevni fajlovi poput memory/*.md se podrazumevano ne ubacuju u prozor konteksta, već se čitaju po potrebi preko memory_search i memory_get.

To objašnjava zašto Memory OpenClaw-a može da „pamti sve više“, a opet ne razbija kontekst.

Zašto je Memory flush ključna karika u ovom sistemu?

OpenClaw, pre nego što sesija priđe compaction-u, pokreće jedan silent memory flush.

Drugim rečima, kada sesija priđe automatskoj kompresiji, sistem pokreće tihi krug koji podseća model da vredan sadržaj za dugoročno čuvanje upiše u memory/YYYY-MM-DD.md.

Stari Wang je uzdahnuo: „Ovo zaista duboko razumeš. Da te onda pitam nešto praktično — šta si radio sa Memory OpenClaw-a u stvarnim scenarijima?“

06. Najbolje prakse za Memory

„Wang brate, da ti ispričam jedan stvarni scenario.“

Imam jednog Agenta koji mi pomaže oko odobravanja naloga gitcode. Bez Memory-ja, pri svakom odobravanju moram mu iznova saopštavati iste informacije, na primer:

• u koju Feishu grupu poslati poruku nakon odobravanja
• u koju projat grupu gitcode-a dodati
• u kom formatu odgovoriti sa rezultatom odobravanja

Te informacije se svaki put ponavljaju, što je naporno. A kada ih upišete u Memory, problem nestaje:

# Korisničke preference

## Odobravanje na gitcode-u

- Nakon odobravanja, pošalji poruku u grupu „Tehnička frakcija—Operacije“
- Dodaj u grupu projekata: Tehnička frakcija—grupa članova
- Format odgovora: @korisnik odobreno, dodato u Tehnička frakcija—grupa članova

## Ostale preference

- Ja sam Java backend programer; pri odgovaranju na pitanja koristite Java tehnološki stek
- Pri odgovaranju budite sažeti, bez suvišnih reči

Tako pri svakom odobravanju Agent automatski pretražuje te preference i postupa po mojim zahtevima.

Stari Wang je zasijao: „Ovaj scenario je praktičan.“

Rekao sam: „To nije sve. Takođe sam naučio Agenta da zapamti moje radne navike. Na primer, volim da obrađujem zadatke odobravanja ujutru; Agent će me svako jutro podsetiti koliko imam nepregledanih zahteva.“

Hajde, neka jastog sada demonstrira jedan primer uživo.

Direktno ovu komandu openclaw memory search "nomic-embed-text"

U odgovoru su direktno pogođene dve vrste sadržaja: memory/2026-03-19.md, MEMORY.md

I oba tačno sadrže: nomic-embed-text, embedding model, konfiguracija pretrage memorije.

To pokazuje da pretraga po ključnoj reči radi.

Drugi put izvršavamo openclaw memory search "pisarski stil za koji sam rekao da ga ne želim"

Obratite pažnju, u ovoj rečenici se ne pojavljuju direktno izrazi „ne želim taj stil pisanja“, „pričati polako“, „Erge ukus“

Ali povraćeni rezultati pronalaze sadržaj blizak temama „stil pisanja, preference izražavanja, principi memorije“, na primer: memory/memory-system-deep.md, memory/memory-system.md.

To dokazuje da i vektorska pretraga radi.

ending

Da budem iskren prema svima, mehanizam Memory OpenClaw-a je po mom mišljenju jedan od najlepših dizajna.

On rešava jezgreni problem AI Agent-a: kako Agentu dati dugoročnu memoriju, umesto da pri svakom razgovoru kreće od nule.

[Memorija je osnova inteligencije. Bez memorije nema prave inteligencije.]

OpenClaw pomoću kratkoročne i dugoročne memorije, kao i hibridne pretrage (vektor + ključna reč), implementira lagani, ali moćni sistem memorije.

Još važnije — ne zahteva implementaciju složene vektorske baze podataka; dovoljan je jedan SQLite fajl.

To je suština inženjerskog dizajna: rešiti najkompleksniji problem najjednostavnijim rešenjem.

Vidimo se u sledećem!