OpenClaw intervju, 54 pitanja o jigulama (12.000 reči, 57 ručno crtanih crteža), protivnapad na intervjuu 👍

Chenmo Wang Er8788 reči29 minuta

01,Koja je komanda za deinstalaciju jigule?

„Braćo Wang, ovo pitanje dobro postaviše. Mnogi misle da je deinstalacija samo pokrenuti npm uninstall -g openclaw, pogrešno.“

Na ovaj način se ne deinstalira do kraja, ostaci fajlova će se sakriti u raznim kutkovima sistema, sledeći put prilikom reinstalla ćeće biti razne greške — port je zauzet, konflikti podešavanja, učitavanje pluginova ne uspeva, gomila nejasnih problema.

Pravi način deinstalacije ima tri koraka.

Prvi korak: Zaustaviti Gateway servis

openclaw gateway stop

Ako Gateway trenutno izvršava zadatke, prisilno zaustavljanje može izgubiti podatke. Preporučujem da prvo proveriš status:

openclaw gateway status

Potvrdi da prikazuje stopped pa nastavi.

Drugi korak: Izvršiti zvaničnu komandu za deinstalaciju

openclaw uninstall

Ova komanda će prikazati interaktivni interfejs, da izabereš šta želiš da obrišeš. Koristi space tipku da sve označiš, zatim pritisni enter za potvrdu. Pomoći će ti:

Zaustaviti i deinstalirati Gateway servis
Obrisati ~/.openclaw/ direktorijum sa stanjem
Očistiti konfiguraciju radnog prostora
Ukloniti plugine i keš

Treći korak: Ukloniti globalni CLI paket

npm rm -g openclaw

Ako koristiš pnpm ili bun, odgovarajuće zameni:

pnpm rm -g openclaw
bun rm -g openclaw

Ako naiđeš na greške dozvola, dodaj sudo.

Stari Wang namigne: „Nakon deinstalacije kako da potvrdim da je sve očišćeno?“

Rekoh: „Izvrši sledeće komande, potvrdi da nema ostataka:

# Proveri globalne pakete
npm list -g openclaw

# Proveri direktorijume
ls ~/.openclaw/

# Proveri zauzeće porta
lsof -i:18789

Sve vraća prazno ili „not found", tek se smatra da je deinstalacija kompletna.

Stari Wang posluša i namigne: „Dobro, deinstalaciju zaista dobro poznaješ. Tada još postavljam pitanje, šta ima u ~/.openclaw/ direktorijumu? Zašto je tako važno ukloniti ovaj direktorijum?“

02,Znate li arhitekturu jigule?

„Braćo Wang, sada me ispituješ arhitekturu.“

~/.openclaw/ je „nervni centar“ OpenClawa, unutra se čuvaju sve konfiguracije i stanje.

~/.openclaw/
├── openclaw.json        # Globalna konfiguracija
├── gateway/             # Gateway vezeno
│   ├── config.json      # Gateway konfiguracija
│   ├── logs/            # Direktorijum logova
│   └── pid              # Fajl sa ID-om procesa
├── plugins/             # Direktorijum plugina
│   ├── @openclaw/       # Zvanični plugini
│   └── @wecom/          # Plugini treće strane
├── workspaces/          # Agent radni prostori
│   ├── default/         # Podrazumevani Agent
│   └── paigit/          # Prilagođeni Agent
├── skills/              # Paketi veština
├── cache/               # Direktorijum keša
└── .env                 # Promenljive okruženja

Stari Wang nastavlja da ispituje: „Šta svaki direktorijum radi? Kaži najvažnije.“

2-1 Za šta služi openclaw.json?

Ovo je „centar za konfiguraciju mozga“ OpenClawa.

{
  "version": "2026.3.2",
  "gateway": {
    "port": 18789,
    "auth": "token",
    "host": "0.0.0.0"
  },
  "channels": {
    "feishu": {
      "appId": "cli_xxx",
      "appSecret": "xxx"
    },
    "wecom": {
      "botId": "xxx",
      "secret": "xxx"
    }
  },
  "model": {
    "provider": "glm",
    "profile": "coding-plan",
    "defaultModel": "glm-5"
  },
  "plugins": [
    "@openclaw/feishu-plugin",
    "@wecom/wecom-openclaw-plugin"
  ]
}

Unutra se bilježi:

Gateway konfiguracija: Port za osluškivanje, način autentikacije, vezana adresa
IM kanalna konfiguracija: Akreditivi za aplikacije kao Feishu, Wecom
Konfiguracija velikog modela: Provajder, paket, podrazumevani model
Lista plugina: Instalirani plugini i njihov redosled učitavanja

Braćo Wang ispituje: „Šta znači auth: \"token\" u Gateway konfiguraciji? Šta Gateway zapravo radi?“

2-2 Za šta služi Gateway?

„Braćo Wang, Gateway je najključniji dizajn u OpenClaw arhitekturi.“

Mnogi koriste OpenClaw, samo znaju nakon instalacije pokrenuti openclaw gateway start, ali ne znaju šta Gateway zapravo radi.

Jednostavno rečeno, Gateway je servis za rutiranje poruka koji stalno radi u pozadini.

Njegove odgovornosti su na tri sloja:

Prvi sloj: Primanje poruka

Kada u Feishu grupi @bot-a, Feishu će poslati poruku na Gateway. Gateway nakon primanja, analizira sadržaj poruke, prepoznaje koji Agent, koja sesija.

Drugi sloj: Distribucija zadataka

Gateway rutira poruku odgovarajućem Agentu za obradu. Ako konfigurišeš više Agent (npr. jedan zadužen za reviziju koda, jedan za odobrenje članova), Gateway će na osnovu izvora poruke suditi kome treba da je prosledi.

**Treći sloj: Povratak rezultata

Nakon što Agent završi zadatak, rezultat predaje Gateway-u, Gateway zatim preko IM kanala šalje natrag Feishu.

Feishu poruka → Gateway → Agent → Veliki model → Agent → Gateway → Feishu odgovor

Stari Wang posluša i oči mu se svetle: „Moma ima nivoa. Zašto ovako slojevito? Zašto Gateway i Agent nisu povezani?“

Rekoh: „Dekoupling. Gateway je zadužen za IM komunikaciju, Agent za izvršavanje zadataka. Tako možeš jedan Gateway kačiti više Agent-a, svaki Agent koristi različite modele, izvršava različite zadatke, ne smetaju jedni drugima.“

Stari Wang namigne: „A ako Gateway padne? Da li ima rešenje visoke dostupnosti?“

Rekoh: „Braćo Wang, ovo pitanje je sve dublje. Trenutno OpenClaw zvanično nudi rešenje visoke dostupnosti, Gateway je single point of failure. Ako želiš da ideš u proizvodnju, moja preporuka je:

Gateway klaster deployment, koristi load balancer za distribuciju zahteva
Stanje sesije spusti u Redis, Gateway bez stanja
Između instanci koristi distribuotirano zaključavanje za koordinaciju izvršavanja zadataka

Stari Wang razmišlja: „A plugini? Kako radi mehanizam OpenClaw plugin-a?“

2-3 Znate li sistem plugin-a?

Rekoh: „OpenClaw koristi arhitekturu mikrokernela.“

Jezgro obezbeđuje samo najosnovnije mogućnosti — slanje i primanje poruka, planiranje zadataka, pozivanje alata. Ostale funkcije se sve proširuju kroz plugine.

Feishu podrška? Plugin.
Wecom podrška? Plugin.
Obrada dokumenata? Plugin.

Plugin-i se instaliraju u ~/.openclaw/plugins/ direktorijum, svaki plugin je nezavisan npm paket.

# Instaliraj Feishu plugin
openclaw plugins install @openclaw/feishu-plugin

# Instaliraj Wecom plugin
openclaw plugins install @wecom/wecom-openclaw-plugin

# Pogledaj instalirane plugin-e
openclaw plugins list

Stari Wang ispituje: „Kada se plugin-i učitavaju? Prilikom startovanja Gateway-a? Ako dva plugin-a žele da obrade istu poruku, kako rešavate konflikt?“

Rekoh: „Da, prilikom startovanja Gateway-a će skenirati plugins direktorijum, učitati sve plugin-e redosledom iz openclaw.json. Svaki plugin će registrovati svoje procesore poruka i funkcije alata.“

„Rešavanje konflikta se oslanja na mehanizam prioriteta — u openclaw.json možeš podesiti prioritete plugin-a, viši prioritet se prvo obrađuje. Pored toga, svaki plugin ima svoj imenski prostor, ne smetaju jedni drugima.“

Stari Wang zadovoljno namigne: „Arhitektura si jasno objasnio. Tada još postavljam pitanje — Kako se menja životni ciklus Gateway-a? Start, stop, restart procesi? U čemu su zamke?“

2-4 Znate li životni ciklus Gateway-a?

Rekoh: „Braćo Wang, ovo pitanje je veoma praktično, mnogi su se naneti na zamke.“

Startovanje Gateway-a

openclaw gateway start

Prilikom startovanja će uraditi nekoliko stvari:

Učitati openclaw.json konfiguraciju
Skenirati i učitati plugin-e
Inicijalizovati IM kanale (povezati se sa Feishu, Wecom i sl.)
Pokrenuti HTTP servis i osluškivati port
Upisati pid fajl

Provera stanja Gateway-a

openclaw gateway status

Prikazaće:

Stanje pokretanja (running / stopped)
ID procesa
Osluškivani port
Broj učitanih plugin-a

Zaustavljanje Gateway-a

openclaw gateway stop

Ako se Gateway zablokira, možeš prisilno zaustaviti:

openclaw gateway stop --force

Ili direktno ubiti proces:

kill $(cat ~/.openclaw/gateway/pid)

Restartovanje Gateway-a

Nakon izmene konfiguracije treba restartovati:

openclaw gateway restart

2-5 Kako otkriti greške prilikom startovanja?

Stari Wang ispituje: „Kakve su česte greške prilikom startovanja? Kako otkriti?“

Rekoh: „Najčešće su tri problema.“

Problem prvi: Port je zauzet

Error: Port 18789 is already in use

Način rešavanja:

# Vidi ko zauzima port
lsof -i:18789

# Ubij proces koji zauzima
kill -9 <PID>

Problem drugi: Učitavanje plugin-a nije uspelo

Error: Failed to load plugin @openclaw/feishu-plugin

Način rešavanja:

# Ponovo instaliraj plugin
openclaw plugins uninstall @openclaw/feishu-plugin
openclaw plugins install @openclaw/feishu-plugin

Problem treći: Oštećen fajl konfiguracije

Error: Invalid JSON in openclaw.json

Način rešavanja: Proveri JSON format, ili direktno obriši i ponovo konfiguriši.

Stari Wang namigne: „A tok poruka? Kada u Feishu grupi @bot-a, kako poruka teče do Agent-a i vraća rezultat? Koje komponente su uključene u ceo lanac?“

2-6 Kako poruka od Feishu do jigule pa se vraća?

Rekoh: „Braćo Wang, ovako funkcioniše.“

Prvi korak: Pretplata na događaje

Feishu šalje poruku Gateway-u. Ovo zahteva konfigurisanje pretplate na događaje na Feishu otvorenoj platformi, uključiti im.message.receive_v1 događaj.

Drugi korak: Analiza poruke

Gateway nakon primanja poruke, analizira sadržaj, prepoznaje izvor (koja grupa, koji korisnik) i nameru (šta raditi).

Treći korak: Rutiranje i distribucija

Na osnovu bindings konfiguracije, poruku šalje odgovarajućem Agent-u. Ako konfigurišeš više Agent-a, Gateway će na osnovu izvora poruke suditi kome treba da je prosledi.

**Četvrti korak: Izvršavanje zadatka

Agent poziva veliki model za obradu zadatka. Ako je složen zadatak, Agent će ga raspakovati na više koraka, korak po korak izvršavati.

**Peti korak: Povratak rezultata

Gateway rezultat vraća Feishu preko IM kanala.

2-7 Da li jigula ima memoriju?

Stari Wang ispituje: „Kako se održava stanje? Gde se čuva kontekst višeg razgovora?“

Rekoh: „Kontekst razgovora se čuva u ~/.openclaw/workspaces/<agent>/memory/ direktorijumu. Svaki razgovor se serijalizuje i čuva, nakon restartovanja Gateway-a se može vratiti. Višeg razgovori se označavaju session_id-om, da se ne mešaju.“

2-8 Kaka je mogućnost istovremenog procesiranja?

Stari Wang nastavlja da pita: „Ako istovremeno 100 korisnika @bot-a, kako Gateway procesira istovremeno?“

Rekoh: „Gateway koristi asinhrono neblokirajuće IO za obradu zahteva. Svaka poruka generiše jedinstveni request_id, da se ne mešaju. Agent izvršavanje je u redu, izbjegava se takmičenje resursa.“

Stari Wang namigne: „Ako Agent sporo reaguje? Da li ima rešenje za optimizaciju?“

Rekoh: „Ima nekoliko ideja za optimizaciju:

Zameni brži model (npr. GPT-5.4)
Pojednostavi instrukcije u BOOT.md
Koristi striming izlaz, generiši i vraćaj istovremeno
Složeni zadaci se asinhrono izvršavaju u pozadini, prvo vrati ACK

Stari Wang posluša i prokomentariše: „Ovo razumeš dovoljno duboko. Tada još postavljam jedno praktično pitanje, šta si radio sa OpenClaw u stvarnom poslovnom scenariju? Nemoj mi pričati o demima.“

03,Šta si radio sa OpenClaw?

Rekoh: „Braćo Wang, ovo pitanje me pogodilo u srce.“

Pričam jedan stvarni scenario — pregled gitcode naloga tehničke stranke (paicoding.com).

Članovi tehničke stranke treba da otvore pristup gitcode kodnom repozitorijumu. Ranije ovaj proces je bio takav:

Član se prijavljuje za učešće
Ja dobijam obaveštenje
Ručno otvaram gitcode pozadinu
Tražim nadimak korisnika
Dodajem u odgovarajuću grupu projekta
Šaljem poruku da je pregled odobren

Jedan nalog je fine, ali ako odjednom dođe 20? Sam ovaj proces će trajati pola sata.

Sada? Ovaj zadatak sam prepustio OpenClaw.

Prvi korak: Kreiraj ekskluzivanog Agent-a

openclaw agents add PaiGit --workspace ~/openclaw-workspaces/paigit

Drugi korak: Konfiguriši BOOT.md i reci Agent-u šta je njegova dužnost

# Dužnost PaiGit-a

Ti si pomoćnik za pregled gitcode naloga tehničke stranke.

Kada primiš Feishu poruku koja sadrži nadimak korisnika:

1. Prijavi se u gitcode pozadinu
2. Traži korisnika
3. Dodaj u grupu tehnička stranka-članovi
4. Odgovori rezultat pregleda

Treći korak: Veži Feishu kanal

U Feishu grupi, direktno šaljem poruku:

Pomozi mi da pregledam sledeće korisnike: Zhang San, Li Si, Wang Wu

OpenClaw nakon primanja poruke, automatski izvršava ceo proces pregleda. 20 naloga, 1 minuta završi.

Stari Wang posluša i oči mu se proširuju: „Ovo povećanje efikasnosti je jako.“

Rekoh: „Ne još. Takođe sam mu podesio zakazani zadatak, svako jutra u 9 sati automatski proverava da li ima novih zahteva za pregled, ako ima, direktno obrađuje, nakon završetka šalje u Feishu grupu.“

Stari Wang se zainteresovao: „Da li ima još scenarija?“

3-1 Da li si radio sinhronizaciju Feishu grupnih poruka?

Opet mu pričam jedan — sinhronizacija Feishu grupnih poruka.

Tehnička stranka ima nekoliko Feishu grup: razvojna grupa, operativna grupa, grupa članova. Ponekad poruka poslata u jednoj grupi treba da se sinhronizuje u druge grupe, npr. obaveštenje o novoj funkciji.

Ranije je to bilo: ručno kopirati i nalepiti, ili koristiti Feishu funkciju prosljeđivanja. Ali format prosljeđivanja nije lep, i lako se propusti.

Sada sam ovaj proces rešio sa OpenClaw.

Konfigurisanje Webhook-a

Svaka Feishu grupa ima Webhook adresu, može se naći u podešavanjima grupe.

Ove Webhook adrese reci OpenClaw:

Upamti sledeće Webhook adrese grupa:
Razvojna grupa: https://open.feishu.cn/open-apis/bot/v2/hook/xxx
Operativna grupa: https://open.feishu.cn/open-apis/bot/v2/hook/yyy
Grupa članova: https://open.feishu.cn/open-apis/bot/v2/hook/zzz

Slanje komande za sinhronizaciju

U razvojnoj grupi, operativnoj grupi, grupi članova istovremeno pošalji: PaiCon v2.0 danas je lansiran, dodata je AI funkcija za pomoć na intervjuu, isprobajte brzo!

OpenClaw će automatski pozvati Webhook, poslati poruku u tri grupe.

Stari Wang namigne: „Ovaj scenario je praktičan, ne treba grupa po grupa prosljeđivati.“

3-2 Da li si radio push zakazanih zadataka?

„Zakazani zadaci? Si ranije rekao da svako jutra u 9 sati šalješ najnovije hacknews poruke, kako se to realizuje?“

OpenClaw podržava kreiranje zakazanih zadataka prirodnim jezikom.

Direktno reci mu:

Svako juto u 9 sati, proveri da li hacknews ima zanimljive AI vesti, sredi i pošalji mi.

OpenClaw će kreirati zakazani zadatak, u vreme će automatski izvršiti.

Donja implementacija zakazanog zadatka je cron. OpenClaw će prirodni jezik prevesti u cron izraz, zatim u pozadini planira i izvršava.

Stari Wang ispituje: „Ako zakazani zadatak ne uspe da se izvrši? Da li ima mehanizam ponavljanja?“

Rekoh: „Trenutno OpenClaw nema ugrađen mehanizam ponavljanja, ali se može realizovati dodavanjem logike za obradu grešaka u BOOT.md. Npr. reci Agent-u: 'Ako se izvršavanje zadatka ne uspe, sačekaj 5 minuta pa ponovi, najviše 3 puta.'“

„Pored toga, rezultati izvršavanja zakazanog zadatka se bilježe u logovima, može se videti u ~/.openclaw/gateway/logs/ direktorijumu.“

Stari Wang posluša i prokomentariše: „Ova tri scenarija su sva praktična, nije tipično koristiti alat zbog alata.“

04,Koje probleme ste naišli tokom korišćenja jigule?

Stari Wang promeni temu: „Tada još postavljam pitanje jednog smera — OpenClaw treba da poziva API velikog modela, u stvarnoj upotrebi, na koje probleme ste naišli? Npr. ograničenje token-a, kašnjenje odgovora, kontrola troškova. Kako ste rešili?“

Rekoh: „Braćo Wang, ovo pitanje je suviše praktično, na mnoge sam se naletelo.“

04-1 Kako optimizovati token?

OpenClaw zaista sporo sagoreva token-e. Jedan malo složen zadatak, Agent u pozadini može pozvati i desetak i desetak krugova velikog modela.

Moji načini optimizacije:

Kompresija prompt-a: Uklanjanje suvišnih informacija, samo neophodan kontekst
Rezanje konteksta: Samo zadrži poslednjih N razgovora
Keširanje rezultata: Istom pitanju direktno vrati keširani rezultat

04-2 Šta ako je odgovor spor?

Spor odgovor velikog modela je opšta bolest. Moja rešenja:

Striming izlaz: Generiši i vraćaj istovremeno, smanji čekanje korisnika
Asinhrona obrada: Složeni zadaci se izvršavaju u pozadini, prvo vrati ACK
Izbor modela: Jednostavni zadaci koriste Lite model, složeni zadaci koriste Pro model

04-3 Kako kontrolisati troškove?

Ovo je najteže. Moji postupci:

Upravljanje kvotama: Svaki dan/mesec postavi gornju granicu token-a
Praćenje troškova: Bilženje potrošnje token-a svakog zadatka
Automatska degradacija: Kada se quota potroši, prebaci na jeftiniji model

Stari Wang ispituje: „Ako API velikog modela padne? Da li ima rešenje degradacije?“

Rekoh: „Ima. Veliki model pao, prebaci na lokalni model (npr. Qwen). Mreža ne prolazi, koristi keš kao osiguranje. Timeout obrada, vrati prijateljsku poruku umesto greške.“

04-4 Ako treba da deploy-uješ OpenClaw u produkciono okruženje, na šta bi mislio?

Stari Wang konačno postavlja veoma praktično pitanje: „Ako treba da deploy-uješ OpenClaw u produkciono okruženje, na šta bi mislio?“

Rekoh: „Braćo Wang, ovo pitanje mogu da pričam pola sata. Kažem najvažnije.“

Visoka dostupnost

Gateway klaster deployment, koristi load balancer za distribuciju zahteva
Stanje sesije spusti u Redis, Gateway bez stanja
Između instanci koristi distribuotirano zaključavanje za koordinaciju izvršavanja zadataka

Monitoring

Gateway sloj: Osluškivanje porta, broj veza, QPS
Agent sloj: Stopa uspešnosti izvršavanja zadataka, prosečno vreme odgovora
Model sloj: Potrošnja token-a, statistika troškova, stopa uspešnosti pozivanja modela

Logovi

Deljenje logova po modulima (gateway.log, agent.log, plugin.log)
Ključne operacije se bilže u audit logu
Rotacija i arhiviranje logova (čuvaj 30 dana)

Bezbednost

API kriptografski čuvaj, podrži dinamičnu rotaciju
Mehanizam white liste za plugin-e, dozvoli samo zvanične plugin-e
Mrežna izolacija, Gateway samo spolja izlaže neophodne portove

Stari Wang namigne: „Poslednje pitanje — prilikom korišćenja OpenClaw na koje ste se zapeli? Kako ste otkrili?“

04-5 Koje ste se zapeli tokom korišćenja?

Rekoh: „Kažem nekoliko najtipičnijih.“

Šta ako Gateway nakon startovanja ne prima poruke?

Stari Wang pita: „Kako ovo otkriti?“

Rekoh: „Idi korak po korak.“

Prvi korak: Proveri logove

cat ~/.openclaw/gateway/logs/error.log

Vidi da li ima poruku o grešci. Česte greške: Feishu App ID pogrešno upisan, dozvola nije otvorena, pretplata na događaje nije konfigurisana.

Drugi korak: Proveri stanje kanala

openclaw channels status

Vidi da li su Feishu/Wecom kanali normalno povezani.

**Treći korak: Proveri Feishu konfiguraciju

Idi na Feishu otvorenu platformu, potvrdi:

Pretplata na događaje je uključena
im.message.receive_v1 događaj je dodat
Dugi režim povezivanja je omogućen

Šta ako poziv modela ne uspe?

Stari Wang pita: „A ovo?“

Rekoh: „Neuspelo pozivanje modela je obično tri razloga:

Razlog prvi: API Key je nevažeći ili istekao

Idi na platformu velikog modela, proveri stanje API Key-a, po potrebi ponovo generiši.

Razlog drugi: Kvota je potrošena

Ako je Coding Plan paket, proveri da li je ovog meseca quota potrošena. Ako jest, ili sačekaj sledeći mesec, ili nadogradi paket.

Razlog treći: Mrežni problem

# Testiraj mrežnu konektivnost
curl -I https://open.bigmodel.cn

Ako se ne može povezati, proveri konfiguraciju proxy-a ili firewall postavke.

Šta ako Agent sporo reaguje?

Stari Wang pita: „Kako optimizovati sporo reagovanje?“

Rekoh: „Obradi situacijom.“

Ako je zakasnjenevo modela:

Zameni brži model (Doubao-Seed-2.0-Lite je 30% brži od Pro-a)
Pojednostavi prompt, smanji količinu token-a
Uključi striming izlaz, generiši i vraćaj istovremeno

Ako je sporo izvršavanje zadatka:

Rasparčaj veliki zadatak, izvršavaj u grupama
Koristi keš da smanjiš ponovljene proračune
Izvršavaj u pozadini asinhrono, prvo vrati ACK

Ako je mrežno kašnjenje:

Koristi najbliži servis čvor modela
Proveri mrežni lanac, optimiši konfiguraciju proxy-a

Šta ako se više Agent-a mešaju u razgovor?

Stari Wang pita: „Ovo sam naišao, kako rešiti?“

Rekoh: „Mešanje više Agent-a je zbog nejasne bindings konfiguracije.“

U openclaw.json koristi bindings polje da jasno specificiraš kanal za svakog Agent-a:

{
  "bindings": [
    {
      "agentId": "PaiGit",
      "match": {
        "channel": "feishu",
        "appId": "cli_xxx"
      }
    },
    {
      "agentId": "PaiReview",
      "match": {
        "channel": "feishu",
        "appId": "cli_yyy"
      }
    }
  ]
}

Tako Gateway kada primi poruku, na osnovu App ID tačno rutira do odgovarajućeg Agent-a, neće se mešati.

Stari Wang posluša i prokomentariše: „Tvoj način rešavanja je prilično jasan, nije tip kad naiđeš na problem i zaboraviš.“

2-6 Znate li uključivanje više Feishu aplikacija?

Stari Wang me nije dugo prepustio, direktno ispituje: „Zašto jedna Feishu aplikacija treba da radi jednog Agent-a?“

Rekoh: „Zbog izolacije. U poslovnom scenariju najveći strah nije što se ne može konfigurisati, nego što su dozvole, rutiranje, audit i domeni kvarova sve pomešani. Jedan Agent odgovara jednoj Feishu aplikaciji, granice su jasne.“

Znate li osnovnu logiku konfiguracije više aplikacija?

Feishu plugin OpenClaw-a podržava konfiguraciju više aplikacija, ključ je u defaultAccount polju. Kada u openclaw.json konfigurišeš više Feishu aplikacija, moraš specificirati jednu podrazumevanu aplikaciju:

{
  "channels": {
    "feishu": {
      "defaultAccount": "app1",
      "accounts": [
        {
          "appId": "cli_xxx1",
          "appSecret": "xxx",
          "encryptKey": "xxx",
          "verificationToken": "xxx"
        },
        {
          "appId": "cli_xxx2",
          "appSecret": "xxx",
          "encryptKey": "xxx",
          "verificationToken": "xxx"
        }
      ]
    }
  }
}

Stari Wang me prekida: „Čekaj, šta zapravo radi defaultAccount?“

Rekoh: „Kada Gateway primi poruku, ako ne može kroz bindings pravila da se slaže sa određenim Agent-om, koristići aplikaciju specificiranu u defaultAccount odgovori. To je strategija poslednjeg sredstva.“

Znate li strategiju uparivanja?

Stari Wang nastavlja da ispituje: „Uparivanje znam. Ne želim da čuvam definiciju imena, već šta problem zapravo rešava u poslovnom scenariju?“

Rekoh: „Uparivanje je sigurosni mehanizam OpenClaw-a. Podrazumevano, robot neće odgovoriti na bilo koju poruku, osim ako aktivno završiš uparivanje.“

Načini uparivanja su dva:

Prvi, privatni razgovor za uparivanje. U Feishu tražiš robota, šalješ privatnu poruku, robot će vratiti kôd za uparivanje. Ovaj kôd kažeš OpenClaw, tako uspostavljate jedan-na-jedan odnos.

openclaw pairing approve feishu xxx

Drugi, grupno uparivanje. Povuci robota u grupu, @ga šalješ naredbu za uparivanje. Robot će prepoznati ID grupe, dodati ovu grupu u white listu.

Stari Wang pita: „Zašto tako mnogo truda? Direktno neka robot odgovori na sve poruke?“

Rekoh: „Bezbednost prva. Razmisli, ako je robot otvoren za sve, ako neko zlonamerano bombaše interfejs, tvoji token-i će se minutum iskoristiti. Mehanizam uparivanja je ekvivalent dodavanju sloja kontrole pristupa.“

Ako te u produkcionom okruženju deploy-uješ jigule kako bi razmišljao o više Agent-a?

Ako ja radim enterprise deployment, ovako bih planirao:

Razvojno okruženje: Jedna Feishu aplikacija, veži test grupu
Produkciono okruženje: Jedna Feishu aplikacija, veži zvaničnu grupu
Ekskluzivni Agent: Svaki poslovni scenario ima posebnu aplikaciju, npr. Agent za reviziju koda, Agent za DevOps, Agent za korisničku podršku

Stari Wang namigne: „Ovo zaista jasno. Ako dve aplikacije dodaju istu grupu, kome će se poruka slati?“

Rekoh: „Ovo se tiče prioriteta rutiranja. OpenClaw koristi princip 'najviši prioritet' — ako se u bindings jasno specificira da je ID grupe vezan za određenog Agent-a, prati bindings; ako nije specificirano, koristi defaultAccount kao poslednje sredstvo. Ali dve aplikacije istovremeno odgovaraju na istu grupu, ovu situaciju treba izbegavati, lako je napraviti Haos.“

05,Znate li mehanizam rutiranja više Agent-a?

Stari Wang stavi šolju čaja: „Ranije si spomenuo bindings, kako zapravo radi rutiranje više Agent-a?“

Rekoh: „Ovde ključno nije ime, već kombinovani odnos. Prave odluke o rutiranju više Agent-a donose dmPolicy i bindings ove dve tačke.“

05-1 Znate li dmPolicy?

dmPolicy je puno ime Direct Message Policy, kontroliše kako robot obrađuje privatne poruke. Ima tri strategije za izbor:

{
  "dmPolicy": {
    "app1": "allow",      // Dozvoli sve privatne poruke
    "app2": "deny",       // Odbij sve privatne poruke
    "app3": "pairing"     // Dozvoli samo korisnike koji su se uparili
  }
}

Stari Wang pita: „Kako se izbor u pravom scenariju?“

Rekoh: „Gledaj scenario. Ako je interni alat, allow je najpogodnije; ako je robot za korisničku podršku orijentisan ka spoljnim korisnicima, mora koristiti pairing, sprečiti zloupotrebu; deny se obično koristi za Agent-e koji su čisto grupni.“

05-2 Znate li pravila preciznog rutiranja bindings?

bindings je ključni mehanizam rutiranja više Agent-a OpenClaw-a. Definiše kako treba rasporediti poruke različitim Agent-ima.

{
  "bindings": [
    {
      "agentId": "CodeReview",
      "match": {
        "channel": "feishu",
        "accountId": "cli_xxx1",
        "peer": {
          "type": "group",
          "id": "oc_xxx"
        }
      }
    },
    {
      "agentId": "DevOps",
      "match": {
        "channel": "feishu",
        "accountId": "cli_xxx2"
      }
    }
  ]
}

Stari Wang pokazuje na konfiguraciju i pita: „Imena polja poznajem. Kaži direktno, kako ova polja učestvuju u rutiranju i odlučivanju o prioritete?“

Rekoh: „channel je izvor poruke, npr. feishu, wecom; accountId je App ID Feishu aplikacije; peer je informacija pošiljaoca, type može biti user ili group, id je odgovarajući ID.“

„Braćo Wang, obrati pažnju na prioritete pravila rutiranja — bindings koristi princip najvišeg prioriteta. Ako poruka istovremeno odgovara dva bindings-a, koji match uslov je više specifičan, taj se koristi.“

Na primer:

Binding A: Samo specificiran channel=feishu
Binding B: Specificiran channel=feishu + accountId=cli_xxx
Binding C: Specificiran channel=feishu + accountId=cli_xxx + peer.id=oc_xxx

Ako poruka dolazi iz feishu cli_xxx aplikacije oc_xxx grupe, prvo će odgovarati Binding C, jer je najviše specifičan.

05-3 groupPolicy: Strategija grupa?

Osim dmPolicy, postoji i groupPolicy koji kontroliše ponašanje grupa:

{
  "groupPolicy": {
    "requireMention": true,    // Da li u grupi treba @robot
    "allowAnonymous": false    // Da li se dozvoljavaju anonimne poruke
  }
}

Stari Wang pita: „requireMention sam naišao. Ponekad u grupi @robot me ne sluša, iz tog razloga?“

Rekoh: „Da. Podrazumevano, robot u grupi samo odgovara na @poruke. Ako želiš da sluša sve poruke, postavi requireMention na false. Ali obrati pažnju, time će povećati potrošnju token-a, i može doneti probleme privatnosti.“

06,Kaži arhitekturu Gateway mrežnog prolaza?

Stari Wang stavi šolju čaja na sto: „Konfiguraciju prvo ostavi po strani. Gateway je srce, od dna mi ga raščlani.“

Rekoh: „Gateway je 'nervni centar' OpenClaw-a, zadužen je za tri stvari:

Ceo lanac je takav:

Feishu poruka → Gateway → Agent → Veliki model → Agent → Gateway → Feishu odgovor

06-1 Kako Gateway i Feishu zapravo komuniciraju?

Stari Wang nastavlja da ispituje: „Kako Gateway i Feishu zapravo komuniciraju? Ne pričaj samo o dugoj vezi, jasno mi objasni ključni lanac.“

Rekoh: „WebSocket duga veza. Feishu otvorena platforma nudi mehanizam pretplate na događaje, prilikom startovanja Gateway-a će se registrovati WebSocket veza na Feishu. Nakon toga Feishu ima poruke će aktivno slati.“

Način autentikacije koristi Token mehanizam. U openclaw.json konfigurisani verificationToken i encryptKey, služi za verifikaciju izvora poruke i dešifrovanje sadržaja poruke.

{
  "gateway": {
    "port": 18789,
    "auth": "token",
    "host": "0.0.0.0"
  }
}

Stari Wang pita: „Šta još može da popuni auth polje pored token?“

Rekoh: „Trenutno je uglavnom token autentikacija. Ako je enterprise intranet deployment, može se kombinovati sa IP white listom, TLS certifikatom i drugim načinima jačanja bezbednosti.“

06-2 Znate li dizajn arhitekture visoke dostupnosti?

Stari Wang nastavlja da pritiska: „Ako zaista ideš u produkciju, kako da handlaš Gateway single point? Nemoj mi pričati 'zvanično će kasnije podržati'."“

Rekoh: „OpenClaw zvanično trenutno ne nudi nativno rešenje visoke dostupnosti, Gateway je single point of failure. Ali možemo kroz dizajn arhitekture realizovati visoku dostupnost:

Rešenje prvo: Gateway klaster + load balancer

Deploy-uj više Gateway instanci, ispred stavi load balancer (npr. Nginx). WebSocket veze Feishu se mogu distribuirati na različite instance.

Feishu → Load balancer → Gateway klaster (više instanci)

Rešenje drugo: Spuštanje stanja sesije

Prebaci stanje sesije sa lokalnog diska na Redis, time Gateway instance postaju bez stanja. Bilo koja instance padne, druge instance mogu preuzeti sesiju.

{
  "memory": {
    "storage": "redis",
    "redis": {
      "host": "localhost",
      "port": 6379,
      "db": 0
    }
  }
}

Rešenje treće: Task queue-ing

Za skupe zadatke, koristi message queue (npr. RabbitMQ) kao bafer, izbegavaj da Gateway se blokira.

Stari Wang namigne: „Da li je implementacija ovih rešenja složena?“

Rekoh: „Gledaj kapacitet tima. Ako je mali tim, predlažem prvo single instance + monitoring alarm; kada poslovni volumen raste, razmisliti o klaster rešenju. Ne optimisuj prerano.“

06-3 Znate li mehanizam upravljanja i kompresije sesije?

Stari Wang nije propustio ovaj detalj: „Gde se zapravo nalazi kontekst višeg razgovora? Zašto nakon restartovanja Gateway-a može da se nastavi?“

Rekoh: „Podaci sesije se podrazumevano čuvaju u ~/.openclaw/workspaces/<agent>/memory/ direktorijumu. Svaki razgovor se serijalizuje i čuva, označava se session_id-om. Nakon restartovanja Gateway-a može vratiti stanje sesije.“

Ali ovde ima zamka — podaci sesije će se nakupljati, posebno u scenariju dugog razgovora. OpenClaw nudi mehanizam kompresije:

{
  "memory": {
    "compression": true,
    "maxHistory": 20,      // Zadrži poslednjih 20 razgovora
    "summarizeThreshold": 10   // Nakon 10 krugova automatski napravi sažetak
  }
}

Stari Wang pita: „Šta znači automatski sažetak?“

Rekoh: „Kada broj razgovora pređe threshold, Agent će sadržaj ranije kompresovati u jedan sažetak, samo zadržati ključne informacije. Tako može kontrolisati potrošnju token-a, takođe izbeći prekoračenje kontekstnog prozora.“

06-4 Šta ako se prozor konteksta prekorači?

Stari Wang nastavlja da ispituje: „Ne pričaj samo o kompresijskoj konfiguraciji. Ako se kontekstni prozor zaista prekorači, kako ga rešavaš na liniji?“

Iskustvo prvo: Dizajn slojevite memorije

Podeli memoriju na tri sloja:

Kratkoročna memorija: Poslednjih 5 razgovora, kompletno zadrži
Srednjoročna memorija: 6-20 razgovora, kompresovano čuvanje
Dugoročna memorija: Više od 20 razgovora, samo zadrži ključne sažetke

{
  "memory": {
    "layers": [
      {"type": "short", "rounds": 5, "compression": "none"},
      {"type": "medium", "rounds": 15, "compression": "light"},
      {"type": "long", "compression": "heavy"}
    ]
  }
}

Iskustvo drugo: Ekstrakcija ključnih informacija

U BOOT.md reci Agent-u, koje informacije mora da pamti, koje može da odbaci:

## Strategija memorije

Informacije koje mora da pamti:

- Identitet i preferencije korisnika
- Kontekst trenutnog zadatka
- Ključni poslovni parametri

Informacije koje mogu da se odbace:

- Ljubazne fraze
- Ponavljajuće potvrde
- Privremeni međurezultati

Iskustvo treće: Mekanizam redovnog čišćenja

Podesi zakazani zadatak, automatski očisti istekle sesijske podatke:

openclaw memory cleanup --before 7d

# Očisti sesiju specifičnog Agent-a
openclaw memory cleanup --agent CodeReview --before 3d

Stari Wang posluša i prokomentariše: „Ove detalje zvanična dokumentacija neće pisati, sve su iz istraživanja.“

06-5 Znate li životni ciklus Gateway-a?

Stari Wang nastavlja da pritiska: „Ne pričaj samo o komandama. Startup, stop, restart Gateway-a, donji životni ciklus mi raščlani.“

Stari Wang pita: „Ako Gateway padne, da li se sesija gubi?“

Rekoh: „Gledaj konfiguraciju. Ako je omogućeno perzistiranje, podaci sesije će se periodično upisivati na disk, nakon pada se mogu vratiti. Ali zadaci koji se trenutno izvršavaju mogu se prekinuti.

Zaustavi prijem novih konekcija
Čekaj da se trenutne konekcije završe (podrazumevano 30 sekundi timeout)
Sačuvaj stanje sesije
Oslobodi resurse i izađi

# Kustosno zatvaranje
kill -TERM <pid>

# Prinudno zatvaranje (ne preporučuje se)
kill -9 <pid>

Stari Wang pita: „Ako za 30 sekundi zadatak nije završen?“

Rekoh: „Nakon timeout-a će se prinudno izaći, nezavršeni zadaci će se izgubiti. Zato složeni zadaci treba dizajnirati da budu reentrant, podržavaju nastavak prekidene tačke.“

07,Koji su ključni komponente OpenClaw-a?

Stari Wang namakne naočare, nastavlja da pita: „Kaži ključne komponente OpenClaw-a.“

Odgovorim.

LLM: Ovo je mozak Agent-a, zadužen za razumevanje instrukcija, planiranje zadataka, generisanje odgovora. OpenClaw podržava više modela, Claude, GPT, GLM sve mogu da se povežu.

Planiranje zadataka: Prirodne jezičke zahteve korisnika raspakuje na izvršive korake. Npr. „Pomozi mi da proverim vreme“, će se raspakovati na: pozovi vremenski API → analiziraj vraćene podatke → generiši odgovor.

Izvršilac alata: Zadužen za pozivanje eksternih alata, npr. pretragu, operacije nad fajlovima, upit baze podataka itd. Svaki alat ima jasnu definiciju ulaza i izlaza.

Menadžer memorije: Upravlja kratkoročnom memorijom (Session) i dugoročnom memorijom (Memory) Agent-a. Ovo je ključ što Agent može kontinuirano da razgovara.

Učitavač veština: Dinamički učitava Skills, proširuje mogućnosti Agent-a. Skills su u suštini pakovani Prompt i kombinacije alata.

Stari Wang namigne: „Kako ove komponente komuniciraju?“

07-1 Kako komponente komuniciraju?

Rekoh: „OpenClaw koristi mehanizam lake komunikacije na osnovu message bus-a.“

„Svaka komponenta je nezavisna, razmenjuje podatke kroz message bus. Ovaj dizajn ima prednosti:

Dekoupling: Komponente ne zavise direktno, pogodno za zamenjivanje i proširenje
Asinhrono: Poruke se mogu asinhrono obraditi, ne blokiraju glavni tok
Opservabilnost: Sve poruke prolaze kroz bus, pogodno za debugovanje i monitoring

Intervjueski nastavlja da ispituje: „Kako se konkretno implementira message bus?“

Kako se konkretan implementira message bus?

Rekoh: „Message bus je u suštini red događaja.“

„Kada komponenta A treba da pozove komponentu B, ne poziva direktno, već šalje poruku na bus. Poruka uključuje:

ID ciljne komponente: Kome se šalje poruka
Tip poruke: Koji tip poruke (zahtev, odgovor, događaj)
Sadržaj poruke: Konkretni podaci
Adresa povratnog poziva: Gde treba poslati odgovor

„Komponenta B čita poruku sa bus-a, nakon završetka obrade, šalje odgovornu poruku na bus. Komponenta A čita odgovor sa bus-a, nastavlja izvršavanje.“

„Prednosti ovog dizajna su:

Prvo, komponente su potpuno dekovpisane. Komponenta A ne mora da zna za postojanje komponente B, samo treba da zna format poruke. Možeš u bilo kom trenutku zameniti komponentu B, dokle god format poruke ostaje nepromenjen, komponenta A neće osetiti promene.

Drugo, podržava asinhronu obradu. Komponenta A nakon slanja poruke ne čeka odgovor, može nastaviti da radi druge stvari. Kad odgovor stigne, tada obradi.

Treće, olakšava proširenje. Dodaj novu komponentu C, samo treba da sluša poruke na bus-u, ne treba menjati druge komponente.

Stari Wang ispituje: „A kako sam Agent radi? Je li stalni proces?“

07-2 Da li je Agent stalni proces?

Rekoh: „Ne, Agent je prelazna instanca po sesiji.“

Stari Wang podigne obrvu: „Šta znači?“

Objasnio: „Svaki razgovor je kompletnan ciklus učitavanja-izvršavanja-uništavanja.“

„Kada korisnik pokrene razgovor:

Faza učitavanja: Čita AGENTS.md, SOUL.md i druge konfiguracione fajlove, inicijalizira ličnost i mogućnosti Agent-a
Faza izvršavanja: Prima ulaz korisnika, poziva LLM da generiše odgovor, izvršava alate, vraća rezultat
Faza uništavanja: Kraj razgovora, čuva Session na disk, oslobađa resurse

„Ovaj dizajn ima dve prednosti:

Prvo, ušteda resursa. Agent ne mora stalno zauzeti memoriju, samo se učitava prilikom razgovora.

Drugo, konfiguracija se primenjuje u realnom vremenu. Svaki run ponovo čita fajlove radnog prostora, izmena konfiguracije ne zahteva restart servisa.

Stari Wang pita: „Kako se menadžira Session?“

07-3 Kako Session realizuje učitavanje po zahtevu?

Rekoh: „Učitavanje Session-a je mehanizam lenjog učitavanja.“

„Kada poruka stigne, rutira se do SessionKey-a, OpenClaw će potražiti sessions.json da dobije trenutni SessionId, zatim SessionId odgovarajuću .jsonl fajl učita u Agent-a.“

Stari Wang pita: „Ako je Session predugačak, da li će probiti LLM Context?“

07-4 Znate li mehanizam optimizacije Session-a?

Rekoh: „OpenClaw u fazi učitavanja Session-a do LLM svesti, radi dve stvari:

A. Kompresija i perzistiranje

Kada Session približi context gornjoj granici, OpenClaw će automatski podsmiti Agent-a da upiše Memory, zatim kompresuje Session. Kompresovani sadržaj će se sačuvati na disk, neće se izgubiti.

Konkretno, Compaction će:

Analizirati sve poruke u Session-u
Identifikovati važne informacije (činjenice koje je korisnik jasno izjavio, zaključci razgovora itd.)
Te informacije upisati u Memory
Originalne poruke kompresovati u sažetak, smanjiti zauzeće token-a

B. Prorezivanje

Pre slanja LLM-u, privremeno proreži stare rezultate alata. Npr. alat za pretragu vratio 100 rezultata, ali LLM treba samo prvih 10, ostale će se prorezati.

Strategije prorezivanja uključuju:

Samo zadrži poslednjih N poruka
Samo zadrži sažetak rezultata pozivanja alata, ne čuvaj kompletni izlaz
Spajanje sličnih poruka

Stari Wang pita: „Kakva je razlika između Compaction-a i Pruning-a?“

Rekoh: „Compaction je perzistentan, važne informacije upisuje u Memory, trajno čuva. Pruning je privremen, samo privremeno proreže sadržaj poslat LLM-u, ne menja Session fajl.“

„Metaforički: Compaction je prepisivanje važnih beleški u svesku, trajno čuvanje. Pruning je privremeno precrtavanje irelevantnog sadržaja na papiru za skeiranje, olakšava čitanje.“

Stari Wang pita: „Kako Agent odlučuje da koristi Memory?“

07-5 Znate li mehanizam Memorije?

Rekoh: „Memory je jedan od ključnih mehanizama OpenClaw-a, daje Agent-u 'memoriju'."

Kratkoročna memorija (Session): Kontekst trenutnog razgovora, čuva se u memoriji. Uključuje ulaze korisnika, odgovore Agent-a, rezultate pozivanja alata itd.

Dugoročna memorija (Memory): Preživeća memorija preko razgovora, čuva se na disku. Uključuje preferencije korisnika, istorijske činjenice, važne zaključke itd.

Stari Wang pita: „Kako ove dve memorije sarađuju?“

Kako sarađuju dve memorije?

Rekoh: „Rad Memorije se deli na tri faze:

Faza prva: Pisanje u Memory

Kada Session približi context gornjoj granici, OpenClaw će pokrenuti mehanizam Compaction. Agent će analizirati sadržaj trenutnog Session-a, izvuciti važne informacije, upisati u Memory.

Sadržaj upisa uključuje:

Činjenice koje je korisnik jasno izjavio („Volim Wang Er“)
Važne zaključke u razgovoru („Projekat koristi arhitekturu mikroservisa“)
Vredne informacije koje je generisao Agent („Rezultati pretrage pokazuju...“)

Faza druga: Čuvanje Memory-a

Upisani Memory se čuva u fajlu memory.sqlite.

Svaki Memory uključuje: content: sadržaj memorije, timestamp: vreme upisa, importance: stepen važnosti (1-10), tags: oznake, za pretragu.

Faza treća: Čitanje Memory-a

Kada započne novi razgovor, OpenClaw će na osnovu sadržaja trenutnog razgovora, pretražiti odgovarajući Memory, učitati u kontekst Agent-a.

Strategije pretrage uključuju:

Poklapanje ključnih reči: Pretraga na osnovu ključnih reči unosa korisnika
Semantička sličnost: Koristi vektorsku pretragu, pronalazi semantički srodne Memory
Vremensko opadanje: Noviji Memory ima viši prioritet

Stari Wang pita: „Kako izbeći eksploziju Memory-a?“

07-6 Znate li strategije optimizacije Memorije?

Rekoh: „Ako se Memorija ne dobro menadžira, zaista može smanjiti efikasnost pretrage. OpenClaw ima nekoliko strategija optimizacije:

1. Ocena važnosti. Prilikom upisa Memorije, Agent će oceniti svaki Memory. Samo Memory koji prelazi prag važnosti će biti zadržan.

2. Redovno čišćenje. OpenClaw će redovno očistiti istekli Memory. Podrazumevano čuva 30 dana, može se podesiti kroz konfiguraciju.

3. Spajanje sličnih Memorija. Ako sadržaj više Memorija je sličan, OpenClaw će ih automatski spojiti, izbeći duplikate.

4. Slojevito čuvanje. Visokofrekventni Memory stavlja u memoriju, niskofrekventni Memory stavlja na disk, balansira performanse i kapacitet.

Stari Wang pita: „Agent koristi Memory na dva načina, kaži?“

07-7 Kaži razliku između sessions_send i sessions_spawn?

Rekoh: „Agent koristi Memory na dva načina: sessions_send i sessions_spawn.“

sessions_send: Šalje poruku drugom Agent-u, čeka odgovor. Slično funkcionalnom pozivu, sinhrono blokirajuće.

sessions_spawn: Rađa novu instancu Agent-a, nezavisno radi. Slično višnitretnosti, asinhrono neblokirajuće.

Stari Wang pita: „Koji scenario odgovara kojem načinu?“

Rekoh:

sessions_send odgovara zadacima koji zahtevaju saradnju. Npr. jedan Agent zadužen za pretragu, drugi za sumiranje, pretražni Agent šalje rezultate sumarnom Agent-u.
sessions_spawn odgovara zadacima koji zahtevaju paralelnu obradu. Npr. istovremeno monitoring više izvora podataka, svaki izvor koristi jednog Agent-a, ne smetaju jedni drugima.

Stari Wang pita: „Da li sadržaj razgovora sessions_send ima mehanizam isteka?“

Rekoh: „Ima. OpenClaw će redovno očistiti istekle sesijske podatke, podrazumevano čuva 7 dana. Može se podesiti vreme čuvanja kroz konfiguraciju.“

08,Kaži 8 konfiguracionih fajlova jigule?

Stari Wang pita: „Ranije si spomenuo AGENTS.md, SOUL.md, šta rade ti konfiguracioni fajlovi?“

Rekoh: „Svaki Agent ima odgovarajući workspace, unutra ima 8 ključnih konfiguracionih fajlova.“

„Ovih 8 fajlova čini kompletnu ličnost Agent-a, nedostaje bilo koji od njih nije moguć.“

AGENTS.md: Definiše granice mogućnosti Agent-a. Uključuje ime Agent-a, opis, sistemski Prompt, ograničenja ponašanja itd. Ovo je najvažniji konfiguracioni fajl.

SOUL.md: Ulijeva dušu Agent-a. Definiše karakter, ton, vrednosti Agent-a. Npr. Agent postaje humorističan, rigorozan, ili profesionalan.

TOOLS.json: Označuje zabrane alata Agent-a. Definiše koje alate Agent može koristiti, parametre i povratne vrednosti svakog alata.

SKILLS.json: Konfiguriše koje Skill-se Agent učitava. Može precizno kontrolisati koje Skill-se se učitavaju, izbeći preveliki broj Skill-sa što dovodi do eksplozije Context-a.

MEMORY.json: Konfiguriše strategiju čuvanja i pretrage dugoročne memorije.

SESSION.json: Konfiguriše strategiju menadžmenta Session-a, uključujući prag kompresije, vreme čuvanja itd.

ROUTER.json: Konfiguriše pravila rutiranja poruka, odlučuje koji Agent obrađuje poruku.

CONFIG.json: Ostale razne konfiguracije, npr. izbor LLM modela, API Key itd.

Rekoh: „AGENTS definisu granice mogućnosti, SOUL uliva dušu, TOOLS označava zabrane, ovih 8 fajlova čini kompletnu ličnost Agent-a.“

Stari Wang pita: „Šta konkretno sadrži AGENTS.md?“

08-1 Šta je napisano u AGENTS.md?

Rekoh: „AGENTS.md ovaj fajl, može se reći da je najključniji Prompt fajl OpenClaw-a.“

„Detaljno predstavlja proces startovanja Agent-a, proces menadžmenta Memory-a.“

Proces startovanja: Definiše korake koje Agent izvršava prilikom startovanja, uključujući učitavanje konfiguracije, inicijalizaciju Memory, registraciju alata itd.

Proces menadžmenta Memory-a: Definiše kada upisivati u Memory, kada čitati iz Memory, kako kompresovati Session.

U AGENTS.md će se jasno napisati:

Kada dužina Session pređe koliko token-a, pokrenuti Compaction
Kada se upisuje u Memory, kako oceniti važnost
Kada se čita iz Memory, kako sortirati i filtrirati

Specifikacija pozivanja alata: Definiše format pozivanja alata, obradu grešaka, mehanizam timeout-a.

Uključuje:

JSON format pozivanja alata
Strategija ponavljanja kada ne uspe izvršavanje alata
Obrada timeout-a pri izvršavanju alata

Bezbjednosna ograničenja: Definiše šta Agent ne sme da radi, npr. ne sme brisati sistemske fajlove, ne sme pristupati osetljivim podacima.

Stari Wang pita: „Šta radi SOUL.md?“

08-2 Šta radi SOUL.md?

Rekoh: „Ako AGENTS.md definira mogućnosti Agent-a, onda SOUL.md definira karakter Agent-a.“

„U SOUL.md može se definisati:

Stil izražavanja: Formalan, neformalan, humorističan, ozbiljan
Vrednosti: Prioritet korisnika, prioritet efikasnosti, prioritet bezbednosti
Pravila ponašanja: Proaktivna potvrda, oprezna operacija, transparentna komunikacija

„Npr. možeš Agent-u učiniti da ispadne kao iskusni stari programer, govori direktno, bez lukaviziranja. Takođe možeš Agent-u učiniti da ispadne kao strpljivi učitelj, objašnjava detaljno, korak po korak.

„Ovo je vrednost SOUL.md-a: iste mogućnosti, predstavljaju različitu ličnost.“

Stari Wang pita: „Kako se učitavaju Skill-s?“

08-3 Da li previše Skill-sa izaziva probleme sa performansama?

Rekoh: „Previše Skill-sa zaista stvara teret Context-u Agent-u, čak i pogrešni Skill-s mogu dovesti do toga da Agent pogrešno poziva alate.“

„Zato moramo finom kontrolisati Agent-e.“

Rekoh: „Npr. brave_search ovaj Skill, pripada Agent-u za efikasnu pretragu na mreži, trebalo bi da bude osnovni generički Skill.“

„A skill-s poput revizije koda, samo Agent-u razvojnog scenarija treba da učita.“

Stari Wang pita: „Kako izbeći eksploziju niskokvalitetnih Skill-s?“

Rekoh: „Tri principa:

Princip jednostavnosti: Samo učitavaj neophodne Skill-s, ne traži previše. Generalno, jedan Agent učitava 5-10 Skill-sa je dovoljno.
Princip ocene: Koristi Evals mehanizam da testiraš kvalitet Skill-s. Napiši test case, pusti Agent-a da izvrši, vidi da li rezultat odgovara očekivanom. Nekvalitetni Skill-s ne koristi.
Princip verzije: Verziono menadžiranje Skill-s, izbeći konflikte. Npr. brave_search ima v1 i v2, osiguraj da Agent učitava pravu verziju.

Stari Wang pita: „Kakva je razlika između TOOLS.json i SKILLS.json?“

Rekoh: „Ova dva fajla se lako mešaju, ali imaju različite odgovornosti.

TOOLS.json: Definiše alate koje Agent može koristiti. Alati su donje mogućnosti, npr. čitanje fajlova, mrežni zahtevi, upiti baze podataka itd.

SKILLS.json: Definiše koje Skill-se Agent učitava. Skill-s su gornji omotač, npr. pretraga, revizija koda, analiza podataka itd. Jedan Skill može pozivati više Tool-a.

„Metaforički: Tools su 'ruke i noge', Skills su 'veštine'.

„Npr. 'pretraga' ovaj Skill, možda poziva 'mrežni zahtev' Tool i 'analiza sadržaja' Tool.

Stari Wang pita: „A MEMORY.json i SESSION.json?“

Rekoh: „Ova dva fajla konfigurišu strategiju menadžmenta Memory-ja i Session-a.“

MEMORY.json:

Putanja čuvanja: Gde se čuvaju Memory fajlovi
Maksimalni kapacitet: Najviše koliko Memory-a se čuva
Vreme čuvanja: Koliko dugo se čuva Memory
Strategija pretrage: Kako pretraživati odgovarajući Memory na osnovu ulaza

SESSION.json:

Prag kompresije: Koliko token-a Session dužine pokreće Compaction
Vreme čuvanja: Koliko dugo se čuvaju Session fajlovi
Strategija prorezivanja: Kako prorezivati stare rezultate alata

„Ove dve konfiguracije direktno utiču na 'memoriju' Agent-a. Dobra konfiguracija, Agent može zapamtiti važne informacije; loša konfiguracija, Agent ili zaboravlja, ili Context eksplodira.

Stari Wang pita: „Šta radi ROUTER.json?“

08-4 Šta radi ROUTER.json?

Rekoh: „ROUTER.json konfiguriše pravila rutiranja poruka, odlučuje koji Agent obrađuje poruku.“

„U sistemu više Agent-a, možemo istovremeno imati više Agent-a koji rade. ROUTER.json definira pravila rutiranja, npr.:

Poruke koje sadrže ključnu reč 'kod', rutiraju se CodeAgent-u
Poruke koje sadrže ključnu reč 'pretraga', rutiraju se SearchAgent-u
Podrazumevano rutiraju se GeneralAgent-u

„Tako korisnik šalje jednu poruku, sistem automatski pronalazi najpogodnijeg Agent-a za obradu.“

Stari Wang pita: „A CONFIG.json?“

08-5 Šta radi CONFIG.json?

Rekoh: „CONFIG.json su ostale razne konfiguracije, uključuje:

Izbor LLM modela: Da koristiti Claude ili GPT ili GLM
API Key: API Key svakog modela
Nivo logovanja: DEBUG, INFO, WARN, ERROR
Vreme timeout-a: Razne timeout postavke

„Ove konfiguracije su prilično generičke, različitim Agent-ima konfiguracija može biti slična.“

09,Kakva je razlika između Memory-ja i Session-a?

„Braćo Wang, Memory je jedan od ključnih mehanizama OpenClaw-a, daje Agent-u 'memoriju'."

09-1 Kaži kratkoročnu memoriju?

Kratkoročna memorija se čuva u ~/.openclaw/agents/{agentId}/sessions/*.jsonl fajlovima, automatski se bilježi.

Svaki put kada razgovaraš sa jigulom, OpenClaw će automatski dodati sadržaj razgovora u fajl dnevnika razgovora u JSONL formatu, ovo je najoriginalniji, neobrađen zapis.

09-2 Kaži dugoročnu memoriju?

Dugoročna memorija se čuva u ~/.openclaw/workspace/MEMORY.md i memory/*.md fajlovima, može se ručno kreirati, ali generalno prepustiti OpenClaw automatski generiše.

Može se razumeti da je izvučeno iz kratkoročnih sitnih sećanja koje OpenClaw treba posebno zapamtiti, npr. karakter korisnika, informacije o identitetu, preferencije odgovora itd.

Na primer, kažeš Agent-u: „Ja sam Java backend razvojni, pri odgovaranju na pitanja koristi Java tehnološki stek.“ Ova rečenica će se izvući u dugoročnu memoriju, čuvati se u Markdown fajlu. Sledeći put kada razgovaraš, jigula će automatski pronaći ovo sećanje, po tvojim preferencijama odgovoriti.

Stari Wang ispituje: „Kako se pretvara dugoročna i kratkoročna memorija?“

Rekoh: „Braćo Wang, ima istraživanja.“

09-3 Kako se automatski pretvara memorija?

„Pretvaranje memorije ima dva mehanizma okidača.

Mehanaizam prvi: session-memory Hook

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

Ovaj proces je automatizovan, ne treba ručnu intervenciju. Sistem će analizirati sadržaj razgovora u JSONL fajlu, izvucići ključne informacije, npr. preferencije korisnika, važni kontekst, važne činjenice koje treba dugoročno zapamtiti itd., zatim upisati u memory/YYYY-MM-DD.md fajl.

Mehanaizam drugi: Memory Flush

Ovo je veoma ključan automatski mehanizam.

Kada Session približi context gornjoj granici, OpenClaw će pokrenuti mehanizam Compaction. Agent će analizirati sadržaj trenutnog Session-a, izvuci važne informacije, upisati u Memory.

Stari Wang namigne: „Kako se indeksiraju ti Markdown fajlovi? Ne može svaki put prolaziti kroz sve fajlove, zar ne?“

09-4 Kako se zapravo grampa indeks Memorije?

„Braćo Wang, pravi problem nije 'zabeležiti', već 'sledeći put ga možeš naći među stotinama fajlova'.

OpenClaw ovako obrađuje Memory:

Markdown fajl je telo memorije, to jest source of truth.
SQLite je sloj ubrzanja, zadužen da te Markdown pretvori u 'stvar koje se može pretraživati'.

Oni koji ne razumisu misle da je SQLite sam Memory, ali zapravo nije.

Ti markdown fajlovi su sami Memory, gde

MEMORY.md: bilježi dugoročna sećanja, više 'zaključak' i 'preferencija'
memory/YYYY-MM-DD.md pripada dnevničkim sećanjima, više 'šta se tog dana desilo'

OpenClaw nije 'svaki put kod upita skenira direktorijum', već unapred isece Markdown, grampa indeks, spušta u SQLite fajl. Kad Agent zaista treba da pretraži istoriju, direktno upitaj indeks, ne može samo pretraživati ključne reči, već i pretraživati semantiku, ovakav Agent je veoma inteligentan.

Iz komandne linije je intuitivnije:

openclaw memory status

Ova komanda će nam reći da li Memory trenutno može da radi, šta model koristi, koliko je indeksa, gde se fajl baze nalazi, da li su normalni puntekstualni i vektorski pretraga.

Na mojoj mašini trenutno vidim:

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) označava da je memory korišćenji embedding provajder openaiovaj set interfejsa.

Model: nomic-embed-text pokazuje da je model za vektore, nomic-embed-text.

Store: ~/.openclaw/memory/paismart.sqlite označava da se memory indeks stvarno nalazi u ovom SQLite fajlu.

Indexed: 8/8 files · 14 chunks znači da je ukupno otkriveno 8 memory fajlova, svih 8 je već indeksirano, ukupno isečeno na 14 tekstualnih chunkova.

Vector: ready označava da je vektorska pretraga normalna, to jest semantička pretraga funkcioniše.

FTS: ready označava da je i puntekstualna pretraga normalna. FTS je Full-Text Search, globalna pretraga teksta.

Poverenje stari Wanga u mene se povećalo, zatim pita: „Šta se zapravo radi pri embedding-u?“

09-5 Šta se zapravo radi pri grambanju indeksa?

Može se podeliti u četiri koraka.

Korak prvi, otkrivanje.

OpenClaw će pratiti promene MEMORY.md i memory/*.md. Dodavanje novih fajlova, ili promena sadržaja fajla, označi ovaj fajl kao dirty, spreman za ponovno grambanje indeksa.

Korak drugi, iseckavanje.

Iseci markdown na više chunk-ova, da „jedan chunk izražava samo jedan mali relativno kompletnan smisao“.

Korak treći, indeksiranje.

Svaki chunk neće proći samo embedding, već istovremeno i puntekstualnu pretragu:

Jedan ulazi u vektorski indeks, zadužen za 'sličan značenje i može se pretraživati'
Jedan ulazi u FTS puntekstualni indeks, zadužen za 'tačno pogodjanje ključnih reči'

To jest, OpenClaw ne radi samo vektorsku pretragu, ne radi samo pretragu ključnih reči, već hibridnu pretragu.

**Korak četvrti, spuštanje u bazu.

Na kraju, ovi chunk-ovi, metapodaci, puntekstualni indeks, vektorski indeks, sve će se staviti u lokalni SQLite.

Stari Wang namigne: „Kako se zapravo pretražuje? Čisto vektor, ili ključne reči?“

Rekoh: „Hibridna pretraga.“

09-6 Zašto je hibridna pretraga pouzdanija od čistog vektora?

Daj najjednostavniji primer.

Ako tražimo: memory_search("nomic-embed-text")

Ključ ovog upita nije 'semantička sličnost', već 'ovaj string mora pogoditi'.

Ako se osloniš samo na vektorsku pretragu, možda će izvući 'embedding model', 'lokalni vektorski indeks', 'OpenAI provider' ove semantike, ali upravo će izgubiti najključnije poklapanje ključnih reči.

Ako tražimo:

Šta je zapravo bila ona preferencija pisanja članka koju si ranije rekao?

Tada ključna pretraga nije dovoljna, jer korisnik ne mora da izrekne fiksne izraze 'elaboratoran stil', 'malo koristi ti, mnogo koristi mi svi i mi', ove fiksne reči.

Zato OpenClaw ide ovako:

FTS5 + BM25 zadužen za tačno pogodjanje lekseme
sqlite-vec zadužen za semantičko slično vraćanje
Na kraju objedini rezultate obe strane, vrati rezultat

Zašto FTS5?

Zato što FTS5 SQLite je u suštini laki puntekstualni pretraživač.

Brži je od LIKE '%xxx%', i zna 'koje su reči važnije, koji rezultati bi trebalo biti ispred'.

Vrednost BM25 je ovde.

Reč se pojavljuje 10 puta ne znači da je važnija od one koja se pojavljuje 2 puta, već će se kombinovati:

Učestalost reči
Dužina dokumenta
Da li je ova reč retka u celom korpusu

Tako reči poput memory_flush, session-memory, nomic-embed-text imaju veću težinu.

Zašto još sqlite-vec?

Zato što FTS5 uglavnom rešava 'doslovno pogodjanje', ne može rešiti problem semantičkog poklapanja:

'Onaj stvari pre'
'Preferencija koju si ranije zapamtio'
'Nisam li rekao da ne želim onaj eksplozivan stil'

Ovaj način pitanja, doslovno ne mora da pogodi tačno originalni tekst, ali je semantički sličan. Tada vrednost embedding-a izlazi.

Prvo query vektorizira, zatim računa rastojanje sa vektorom svakog chunk-a, izvlači semantički slične fragmente. Može grubo razumeti ovako:

query
  ↓
embedding(query)
  ↓
Računaj rastojanje sa svakim vektorom u chunks_vec
  ↓
Uzmi top-k

Ako se ovo stavi u SaaS proizvod, treba posebnu vektorsku bazu, npr. PaiCon RAG koristi ElasticSearch.

Ali OpenClaw nije ovako radio.

On koristi sqlite-vec ovu SQLite ekstenziju, stavlja mogućnost vektorske pretrage u lokalni SQLite.

Stari Wang se nasmej: „Dobro, koncept si jasno objasnio. Kako Agent zapravo koristi te Memory-je?“

09-7 Nakon pretrage memorije, kako Agent koristi?

„Braćo Wang, ovaj korak je mesto gde Memory zaista ostvaruje vrednost.“

Mnogi misle da je krajnja tačka Memory sistema 'pronašao'. Zapravo nije.

OpenClaw uglavnom Agent-u izlaže dva alata:

1)`memory_search`

Kada Agent otkrije da problem uključuje prošle odluke, preferencije, istorijski kontekst, neće čitati ceo memory/ direktorijum, već će prvo pokrenuti semantičku pretragu.

Na primer:

memory_search("Ergova preferencija pisanja članaka")

Vraćeni nisu kompletni sadržaj, već najrelevantniji nekoliko snippet + putanja fajla + opseg broja linija.

Ovo ima dve prednosti:

Kontrola token-a, ne ubacuj ceo istorijski sadržaj odjednom u kontekst
Prvo grubo vrati, pronađi 'vredno detaljno čitati' poziciju

2)`memory_get`

Ako memory_search vrati da su ključne informacije u:

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

Tada Agent sledeći korak može koristiti memory_get da pročita konkretne linije segmenta.

Obrati pažnju, ovde ima posebno lako zanemarljivu tačku:

Memorijski fajlovi nisu svaki krug kompletno ubrizgani.

memory/*.md ovakvi dnevni fajlovi podrazumevano neće se ubrizgati u kontekstni prozor, već se kroz memory_search i memory_get čitaju po zahtevu.

Ovo objašnjava zašto OpenClaw-ov Memory može 'što više pamti', ali neće eksplodirati kontekst.

Zašto je memory flush ključni lanac ovog sistema?

OpenClaw će pre nego što sesija dosegne automatsku kompresiju, pokrenuti jedan silent memory flush.

To jest, kada session približi automatskoj kompresiji, sistem će pokrenuti jednu tihi krug, podsetiti model da vredne dugoročno čuvanje sadržaje upiše u memory/YYYY-MM-DD.md.

Stari Wang posluša i prokomentariše: „Ovo razumeš dovoljno duboko. Tada još postavljam jedno praktično pitanje, šta si radio sa stvarnim scenarijem OpenClaw Memory-ja?“

09-8 Pričaj jednu najbolju praksu Memory-ja?

„Braćo Wang, pričam ti jedan stvarni scenario.“

Imam jednog Agent-a koji mi specijalno pomaže pri pregledu gitcode naloga. Ako nema Memory, svaki put pri pregledu, moram mu govoriti neke ponavljajuće informacije, npr.:

Nakon završetka pregleda pošalji poruku u koju Feishu grupu
Dodaj u koju gitcode grupu projekta
Koji format se koristi za odgovor na pregled

Ove informacije svaki put treba ponavljati, veoma naporno. Ovo upiši u Memory i nema problema:

# Korisničke preferencije

## gitcode pregled

- Nakon završetka pregleda pošalji poruku u 'tehnička stranka-operativna grupa'
- Dodaj u grupu projekta: tehnička stranka-grupa članova
- Format odgovora: @korisnik Pregled odobren, dodat u tehnička stranka-grupa članova

## Ostale preferencije

- Ja sam Java backend razvojni, pri odgovaranju na pitanja koristi Java tehnološki stek
- Pri odgovoranju budekratko, ne šetaj

Tako svaki pregled, Agent će automatski pretraživati te preferencije, po tvojim zahtevima izvršavati.

Stari Wang posluša i oči mu se svetle: „Ovaj scenario je praktičan.“

Rekoh: „Ne još. Takođe sam Agent-u uzeo da se seta mojih radnih navika. Npr. volim ujutru da obavljam pregled, Agent će svako jutro aktivno podsetiti koliko zahteva za pregled ima.

Dozvoli, direktno neka jigula nama na licu demonstrira.

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

U povratku je direktno pogodilo ove dve vrste sadržaja: memory/2026-03-19.md, MEMORY.md

I obično sadrži: nomic-embed-text, embedding model, memory pretraga konfiguracija

Ovo pokazuje da je pretraga ključnih reči delotvorna.

Drugi put, izvršimo openclaw memory search "ranije si rekao da ne želiš onaj eksplozivan stil pisanja"

Obrati pažnju, u ovoj rečenici nije direktno napisano 'ne pravj eksplozivan stil', 'elaboratoran stil', 'Ergov ukus'

Ali u povratku je pronašao ove sadržaje bliske 'stil pisanja, preferencija izražavanja, princip memorije', npr. memory/memory-system-deep.md, memory/memory-system.md

Ovo dokazuje da je vektorska pretraga takođe upotrebljiva.

Ništa me ne može zadržati — osim cilja, čak i ako na obali ima ruža, hlad, mirna luka, ja sam brod bez veza.

Serija sadržaja:

GitHub označen sa 17000+ otvorenog baze znanja "Protivnapad na intervju" druga edicija PDF konačno je stigla! Uključuje Java osnove, Java kolekcije okvir, Java istovremeno programiranje, JVM, Spring, Redis, MyBatis, MySQL, operativni sistem, računarske mreže, RocketMQ, distribuirani sistem, mikroservis, dizajn patern, Linux, OpenClaw itd., ukupno 320.000+ reči, 500+ ručno crtanih crteža, može se reći da je lako razumljivo, zabavno i humoristično... Detalji prst: Protivnapad na intervju 2.0 izdanje PDF objavljeno, Java backend programeri moraju da znaju, možda najbolje pitanja za pamćenje 2026. godine