Intervjuver: "Pa Agent nije samo LLM sa par alata?", ja: "ReAct, MCP, Skills, Function Call — da li uopšte razumeš?"

Ove godine se traženje posla mnogo promenilo, i verujem da će se sa tim složiti svi koji su bili na intervjuima. Udeo veštačke inteligencije je izvan svake mere — da ne govorimo o pozicijama za razvoj AI aplikacija, čak i za frontend, testiranje i slične pozicije.

Intervjuver na svakom koraku pominje AI Agent.

Na osnovu povratnih informacija pripremio sam skup visokofrekventnih pitanja sa intervjua o velikom modelu Agent — od arhitekture i principa do saradnje više agenata, pokrivene su sve tačke koje intervjuveri najradije pitaju, ukupno preko 7000 reči.

Uz moj open-source projekat PaiAgent, cilj mi je da nakon ovog teksta na intervju imate puno samopouzdanja.

GitHub adresa: https://github.com/itwanger/PaiAgent

01. Osnovni pojmovi i arhitektura

Q1: Opiši osnovnu arhitekturu Agent-a?

Kompletan Agent obično čine četiri jezgra modula.

Prvi je LLM, zadužen za zaključivanje i odlučivanje, ekvivalent CPU-u Agent-a. Prima ulaz, razume nameru i isporučuje plan za sledeći korak.

Drugi je memorija (Memory), podeljena na kratkoročnu i dugoročnu. Kratkoročna memorija je kontekst razgovora i drži se u RAM-u; dugoročna memorija zahteva spoljašnje skladište, npr. vektorsku bazu ili relacionu bazu, radi postojanosti kroz više sesija.

Treći je skup alata (Tools), spoljašnje sposobnosti koje Agent može da poziva, npr. pretraga, izvršavanje koda, upit nad bazom, poziv API-ja. Alati su veza između Agent-a i stvarnog sveta.

Četvrti je izvršilac akcija (Action Executor), koji zaista izvršava operacije koje je LLM odlučio i vraća rezultat nazad.

Razlika u odnosu na tradicionalni LLM Chain?

LLM Chain je fiksni tok: unapred definišete svaki korak — prvo pozovete model A, pa model B, pa na kraju izlaz.

Tok je statičan i ne prilagođava se na osnovu međurezultata. Kao proizvodna traka čiji je redosled montaže uklesan: čak ni kad negde zapne, neće stati da razmisli.

Agent je dinamičko odlučivanje. Svaki korak LLM iznova odlučuje na osnovu trenutnog stanja — "šta dalje" nije unapred napisano, već se zaključuje u realnom vremenu. Agent na osnovu rezultata alata i istorije razgovora dinamički prilagođava putanju akcija.

Jednom rečju: LLM Chain je scenario, Agent je improvizacija.

Q2: Kako radi ReAct obrazac?

Tok rada ReAct-a je neprekidni ciklus "razmišljanje — akcija — posmatranje":

Thought (razmišljanje): LLM analizira trenutnu situaciju i odlučuje šta dalje. Ovaj korak ne ide ka spoljašnjem izlazu, već je samo interno zaključivanje. Na primer: "Korisnik pita kakvo je danas vreme, treba da pozovem alat za prognozu, parametar je trenutni grad."

Action (akcija): LLM odlučuje koji alat da pozove i sa kojim parametrima, a izlaz daje u strukturisanom JSON formatu.

Observation (posmatranje): sistem izvršava Action i vraća rezultat LLM-u. Na primer: "U Pekingu je danas sunčano, 26 °C."

Kada dobije rezultat, LLM ažurira svoj kontekst, ulazi u sledeći krug razmišljanja i ocenjuje da li je zadatak završen. Ako nije — ciklus se nastavlja; ako jeste — isporučuje konačan odgovor.

Koji problem rešava ovaj dizajn?

Omogućava da LLM više ne bude samo "jednokratno pitanje i odgovor", već mašina za zaključivanje koja može da komunicira sa spoljnim okruženjem i prilagođava strategiju na osnovu povratne informacije.

Konkretan primer: tražite od Agent-a "nađi mi koje su sve nedavno objavljene studije o optimizaciji RAG-a".

Prvi krug: Thought → "Treba da pretražim najnovije RAG radove"; Action → poziva alat search sa ključnim rečima "RAG optimization 2026"; Observation → vraća 10 apstrakata radova.

Drugi krug: Thought → "Apstrakti su predugi, treba izdvojiti tri najrelevantnija"; Action → poziva alat filter; Observation → tri izabrana rada.

Treći krug: Thought → "Informacija je dovoljno, mogu da dam odgovor"; Final Answer → sređuje ih u čitljiv format i vraća korisniku.

Jedna ključna stvar: u ReAct-u LLM svaki put generiše samo "instrukciju za sledeći korak", dok kontrolu petlje drži spoljašnji program. Zato su pri implementaciji Agent okvira logika petlje i sastavljanje konteksta izuzetno važni.

Q3: Kako se implementira dugoročna memorija Agent-a?

Po vremenskom trajanju skladištenja, memorija se deli na dva nivoa:

Kratkoročna memorija (Working Memory): to je prozor konteksta trenutnog razgovora, u RAM-u. Nedostatak je očigledan — nestaje kad se sesija završi, a ograničena je veličinom kontekstnog prozora, pa se ne može beskonačno gomilati.

Dugoročna memorija (Long-term Memory): mora da se persistira u spoljašnje skladište i da opstane kroz više sesija. Uobičajena su tri rešenja.

Prvo, vektorska baza. Istorija razgovora ili tekst baze znanja vektorizuje se i uskladišti; pri svakom upitu radi se pretraga po sličnosti, pa se najrelevantniji fragmenti vraćaju i umeću u Prompt. To je standardni pristup u RAG-u i trenutno najzastupljenije rešenje za dugoročnu memoriju.

Drugo, strukturisano skladište. Relacione baze poput SQLite i PostgreSQL čuvaju strukturisane podatke — korisničke preferencije, istoriju zadataka, poznate činjenice. Upit ide preko SQL-a, tačno ali ne i previše fleksibilno.

Treće, sažimanje rezimea. Kad razgovor postane dugačak, LLM sažme istoriju u jedan rezime, a taj rezime zamenjuje originalni razgovor u sledećem kontekstu. Tako se u ograničenom prozoru konteksta sačuva više istorije.

02. Saradnja više agenata

Q4: Zašto je potreban Multi-Agent?

Prvo, ograničenje kontekstnog prozora. Količina informacija u složenom zadatku može znatno da premaši kontekstni prozor jednog LLM-a, pa ako sve ne stane — informacije se gube.

Drugo, usko grlo specijalističkih sposobnosti. Tražiti od jednog Agent-a da podjednako savršeno vlada pregledom koda, analizom podataka i pisanjem tekstova daleko je lošije nego tri posebno trenirana, specijalizovana Agent-a, gde svaki radi svoj deo.

Treće, paralelna efikasnost. Serijski zadaci su spori, ali mnogi podzadaci nemaju međusobnih zavisnosti, pa ih je sasvim moguće pustiti paralelno. Jedan Agent ne može da ostvari pravu konkurentnost.

Koji su uobičajeni obrasci saradnje?

Pipeline obrazac: izlaz Agent-a A je ulaz Agent-a B, sve u lancu. Pogodno za zadatke sa jasnim redosledom, npr. "Agent za puzenje → Agent za rasčlanjivanje → Agent za sažetak → Agent za slanje".

Orchestrator-Workers obrazac: jedan Agent-vođa zadužen je za raspodelu i raspoređivanje zadataka, a više izvršilaca radi same zadatke. To je trenutno najzastupljenija multi-Agent arhitektura, mnogo se koristi u LangGraph-u.

Paralelni obrazac: više agenata istovremeno obrađuje različite podzadatke, a rezultati se na kraju objedine. Prikladno za konkurentne zadatke bez međuzavisnosti, npr. istovremeno praćenje tri izvora podataka.

Debate obrazac: više agenata daje odgovore iz različitih uglova na isto pitanje, a zatim se rezultati sintetizuju ili jedan Agent-sudija donosi odluku. Pogodno za scenarije u kojima je potrebna provera iz više uglova; efikasno smanjuje rizik od halucinacija jednog Agent-a.

Q5: Kako sistem više agenata izbegava beskonačne petlje i suvišnu komunikaciju?

Koren beskonačne petlje obično je u tome što Agenti međusobno zavise — A čeka B, B čeka A — ili neki Agent u krugu obradi podzadatak koji nikako ne može da reši.

Tri su uobičajena zaštitna mehanizma. Prvo, ograničenje maksimalnog broja koraka: svaki Agent dobija gornju granicu koraka, pa kad je prekorači, prinudno se zaustavlja i prijavljuje grešku. Drugo, detekcija hesa stanja: beleži se hes stanja nakon svakog izvršenja, pa ako se ponovi isto stanje — proglašava se petljom i prekida. Treće, prekidač po isteku vremena: ako zadatak traje duže od zadatog vremena, prinudno se završava i vraća se trenutno najbolje rešenje.

Problem suvišne komunikacije podmukliji je. Više agenata istovremeno šalje slične rezultate, ili u međufazama nastaje mnoštvo besmislenih poruka, pa Agent-vođa biva preplavljen šumom.

Rešenje je dizajniranje jasnog protokola poruka: svaka poruka nosi Agent ID, ID zadatka i tip poruke (međufaza naspram konačni rezultat), a vođa obrađuje samo poruke tipa "konačni rezultat" i ignoriše međufaze. Uz to, red za deduplikaciju poruka izbacuje poruke sa istim sadržajem.

03. Osnovni obrasci dizajna Agent-a

Q6: Kako birati između toka rada i agenta?

Obrazac toka rada (workflow): tok unapred definiše programer, a LLM samo na fiksnim čvorovima donosi odluke ili generiše sadržaj — celokupan tok je predvidiv.

Prednost: kontrolisan, stabilan, lako se otklanjuju greške. Kad nešto krene loše, zna se u kom koraku, pa je i ispravka laka.

Mane: slaba fleksibilnost. Na situacije izvan unapred definisanog toka, workflow će se zaglaviti ili dati pogrešan rezultat, a za svaku novu situaciju mora da se menja kod toka.

Obrazac agenta: Agent-u se da cilj i on sam planira putanju, poziva alate i dinamički menja strategiju — bez uplitanja odozdo.

Prednost: fleksibilan, može da obradi otvorene zadatke i lako se prilagođava promenama zahteva.

Mane: nekontrolisan. Putanja zaključivanja LLM-a nije transparentna, pa je otkrivanje uzroka teško. Uz to, svaki korak troši Token, pa su i troškovi visoki, a i latencija nestabilna.

Jednostavno pravilo: ako su granice zadatka jasne i koraci mogu da se nabroje, birajte workflow; ako je zadatak otvoren i zahteva mnogo prosuđivanja, birajte agenta.

Češća je hibridna arhitektura: spoljašnji sloj je workflow koji kontroliše glavni tok, dok se pojedini čvorovi u unutrašnjosti zamenjuju agentima za otvorene podzadatke.

Na primer, sistem korisničke podrške: ukupni tok je fiksan (prijem pitanja → klasifikacija → pretraga baze znanja → odgovor), ali korak "pretraga baze znanja" može da bude agent koji sam odlučuje o strategiji pretrage.

Q7: Da li ti je poznat obrazac Orchestrator-Worker?

Orchestrator radi tri stvari: primi originalni zadatak, raščlani ga na podzadatke, raspodeli podzadatke odgovarajućim izvršiocima i na kraju objedini rezultate. Možete ga zamisliti kao projektnog menadžera — sam ne piše kod, ali zadužen je za ukupnu planiranje i praćenje napretka.

Izvršioci (Workers) jesu skup specijalizovanih Agent-a, gde svaki radi samo onaj posao u kom je najbolji — npr. "komesar za pregled koda", "komesar za generisanje dokumentacije", "komesar za pozive API-ja" — jasna podela, bez međusobnog mešanja.

Ključna tačka ovog obrasca jeste kvalitet rasčlanjivanja zadataka od strane orchestratora. Ako je zrnastost pregruba, izvršioci i dalje dobijaju previše složene zadatke i stopa neuspeha je visoka; ako je previše fina, podzadataka bude previše, komunikacioni troškovi rastu, a ni objedinjavanje nije lako.

Dobar upit za orchestrator treba da sadrži: cilj zadatka, spisak dostupnih izvršilaca sa opisom njihovih sposobnosti, zahtev za format rasčlanjivanja zadataka (najčešće lista zadataka u JSON formatu) i zahtev za format objedinjenog izlaza.

U LangGraph-u je orchestrator centralni čvor, izvršioci su lisni čvorovi, a uslovljene grane kontrolišu rutiranje zadataka.

Povratna vrednost orchestratora u rezultatu nosi odluku "kojeg izvršioca sledećeg pozvati", pa LangGraph na osnovu te odluke dinamički rutira.

Q8: Šta je Reflection / Self-Correction obrazac?

Obrazac refleksije daje Agent-u sposobnost "samoispravke", što je naročito korisno u scenarijima visoke preciznosti poput generisanja koda ili pisanja dugačkih tekstova.

Osnovni tok je ovakav: Agent generiše početni rezultat, zatim pokrene "korak evaluacije" u kojem isti ili drugi LLM ocenjuje rezultat, traži probleme i daje predloge za poboljšanje. Te povratne informacije se vraćaju Agent-u radi ponovnog generisanja, i ciklus se ponavlja dok se ne zadovolji kriterijum kvaliteta ili ne dostigne maksimalan broj iteracija.

Primer generisanja koda:

Prvi krug, Agent generiše Python kod za puzenje.

Korak refleksije, Critic Agent pregleda kod: "Nema obrade izuzetaka, nedostaju zaglavlja zahteva, antipuzenje ga može blokirati".

Drugi krug, Agent na osnovu povratne informacije popravlja kod, dodaje try/except i postavlja User-Agent.

Korak refleksije, Critic Agent ponovo pregleda: "Čini se da je sada u redu".

Konačan izlaz je kod iz drugog kruga.

Ovaj obrazac ima dve varijante. Jedna je samorefleksija (Self-Reflection): isti LLM ocenjuje sopstveni izlaz — cena je niska, ali pošto je u pitanju isti model, slepa mesta su ista, pa je kvalitet ocene ograničen.

Druga je uzajamna recenzija (Peer Review): koristi se posebno trenirani Critic model — kvalitet je viši, ali je i cena veća.

U produkciji se obično koristi samorefleksija za brze iteracije, dok se poseban Critic model uvodi tek u scenarijima visoke preciznosti (npr. pregled ugovora, medicinski saveti).

04. Dubinska tehnička implementacija i upravljanje stanjem

Q9: Kako Agent za višekružni razgovor rešava eksploziju stanja i preliv konteksta?

Eksplozija stanja znači da se u višekružnom razgovoru prostor stanja povećava eksponencijalno sa brojem krugova, pa sistem postaje sve teži za upravljanje. Na primer, u pedesetom krugu razgovora međuzavisnosti istorijskih stanja su toliko složene da je svaka greška teško ispustljiva.

Rešenje je pojednostavljenje stanja: ne čuvati kompletno stanje svih istorijskih koraka, već samo "najmanji skup informacija potreban da se trenutni zadatak završi". Podzadaci koji su završeni i čiji je rezultat poznat sažmu se u rezime, a originalno stanje može da se arhivira.

Preliv konteksta jeste problem ograničenog kapaciteta kontekstnog prozora LLM-a: što više krugova razgovora, brže se prekorači granica.

Uobičajena su četiri rešenja:

Prvo, klizni prozor: zadrži se samo poslednjih N krugova razgovora, a starije se odseca. Prosto i grubo, ali gubi važne rane informacije.

Drugo, sažimanje rezimea: LLM sažme stare razgovore u rezime, koji zamenjuje original u kontekstu. Zadržava se suština, ali se gube detalji.

Treće, poboljšanje vektorskom pretragom: istorija razgovora smešta se u vektorsku bazu, pa pre svakog kruga pretraga dohvata najrelevantnije fragmente i umeće ih u kontekst, umesto da se sve ubaci u celosti.

Četvrto, izdvajanje ključnih činjenica: posebno se održava "lista važnih činjenica" — ključne informacije iz razgovora (ime korisnika, preferencije, potvrđene odluke) izdvajaju se i trajno čuvaju, pa se u svakom krugu ubacuju u kontekst.

Q10: Kako obezbediti pouzdanost poziva alata (Function Calling) Agent-a?

Nepouzdanost poziva alata obično dolazi iz tri sloja.

Sloj modela: parametri poziva koje generiše LLM mogu biti loše formatirani, s poljima koja nedostaju, ili model uvelle prosledi pogrešno ime alata. Rešenje: u Prompt-u jasno navesti JSON šemu svakog alata i tražiti striktan izlaz; pre poziva izvršiti jednu proveru parametara; ako format ne valja, vratiti modelu da ponovo generiše, sa najviše 3 pokušaja.

Sloj izvršenja: sam alat može da istekne, baci izuzetak ili vrati neočekivani rezultat. Standardni postupak: zadati gornju granicu vremena za svaki poziv alata, dodati logiku retry (sa eksponencijalnim povratnim čekanjem), a na povratnu vrednost uraditi osnovnu proveru valjanosti; u slučaju izuzetka zapisati u dnevnik i prijaviti Agent-u "poziv neuspešan, razlog: xxx", te prepustiti Agent-u da odluči o sledećem koraku.

Sloj sistema: pri visokoj istovremenosti više agenata istovremeno pogađa istu spoljnu uslugu, što može srušiti nizvodni servis. Uvesti limitiranje protoka i prekidače (circuit breaker); zadati gornju granicu paralelnih poziva za pojedinačni alat; po okidanju prekidača vratiti degradirani rezultat.

Jedan često zanemaren detalj: kvalitet opisa alata direktno utiče na tačnost poziva.

Što su name i description alata jasniji, to je manja šansa da model pogrešno izabere alat.

Q11: Čime se Node i Edge u LangGraph-u razlikuju od klasičnog toka rada?

Grana klasičnog toka rada je statična: jednom nacrtan dijagram toka, podaci teku fiksnom putanjom, bez runtime procene.

Inovacija LangGraph-a jeste uslovna grana (Conditional Edge). Obična grana je fiksni A → B; uslovna grana je A → f(state) → B ili C ili D, gde sledeći korak zavisi od rezultata izračunavanja nad trenutnim stanjem. Time usmereni graf dobija moć dinamičkog rutiranja.

Čvor (Node) u LangGraph-u prima trenutno stanje, odradi neku obradu i vraća ažuriranje stanja. Stanje je deljeno kroz čitav graf, a svaki čvor ažurira samo ona polja stanja koja ga se tiču.

Ovaj dizajn donosi dve moći koje klasični tok rada nema:

Prvo, podrška za petlje. LangGraph izričito dozvoljava petlje u grafu, što je osnova za implementaciju ReAct ciklusa. Klasični DAG (usmereni aciklični graf) ne dozvoljava petlje, ali Agent-ov ciklus zaključivanja po svojoj prirodi zahteva petlju.

Drugo, postojanost stanja. LangGraph može da sačuva snimak stanja posle svakog koraka i da podrži "čovek u petlji (Human-in-the-Loop)" — pauziranje na ključnim čvorovima, čekanje ljudske potvrde, pa nastavak. To je veoma korisno u poslovnim procesima koji zahtevaju ljudsku odobrenje.

Q12: Šta je suštinska razlika između Function Call, MCP i Skills?

Function Calling jeste native sposobnost na strani modela. Prodavac mikrofino-tjunovanjem omogućava LLM-u da isporuči strukturisanu instrukciju poziva koja odgovara određenoj JSON šemi.

Na primer, na pitanje "kakvo je danas vreme u Pekingu", model će dati {"tool": "weather_query", "params": {"city": "Peking"}}, umesto da odgovori direktno. Problem koji rešava jeste: kako navesti model da tačno okine poziv alata, umesto da alat pogađa iz prirodnog jezika.

MCP (Model Context Protocol) jeste standardizovani protokol za priključenje alata, ekvivalent "USB priključku" sveta veštačke inteligencije.

Problem koji rešava nije "kako model poziva alat", već "kako različiti alati na jedinstven način izlažu svoje sposobnosti različitim modelima". MCP usvaja arhitekturu Host-Client-Server i komunicira na osnovu JSON-RPC 2.0, tako da alat implementirate jednom i on je dostupan svim MCP-podržanim modelima — bez posebnog prilagođavanja po modelu.

Skills su "fajlovi iskustva" koje Agent akumulira tokom izvršenja zadataka — suštinski, Markdown dokument koji opisuje uspešnu putanju. To nije mehanizam poziva, nije komunikacioni protokol, to je "mišićna memorija" Agent-a.

Hermes Agent automatski pretvara rešenje složenog zadatka u Skill, pa sledeći put kad naiđe na sličan zadatak to iskustvo direktno iskoristi, što drastično podiže efikasnost.

Odnos tri pojma: Function Call je sloj osnovne sposobnosti i rešava "kako komuniciraju model i funkcija"; MCP je sloj protokola i rešava "kako se alat standardizovano priključuje"; Skills je sloj iskustva i rešava "kako ponovo iskoristiti prošla uspešna iskustva".

Kompletan sistem Agent-a obično ima sva tri sloja: Function Call okida alat, MCP upravlja registracijom alata, a Skills akumulira iskustvo izvršenja.

Q13: Sadržaj baze znanja brzo se ažurira — kako se s tim nosi RAG sistem?

Uobičajajena su tri nivoa odbrane.

Prvi nivo, mehanizam inkrementalnog ažuriranja. Ne radi svaki put punu obnovu indeksa, već pratiti događaje izmena u izvoru podataka i ponovo vektorizuje samo ono što je dodato ili izmenjeno.

Drugi nivo, filter vremenske aktualnosti. U pretragu se doda vremenski filter, pa se dohvata samo sadržaj iz poslednjih N dana, a dokumenti van roka isključuju se. Uz to, svaki dokument dobija polja za vreme kreiranja i rok važenja, pa rezultat pretrage sam po sebi nosi informaciju o aktualnosti.

Treći nivo, padobran alata u realnom vremenu. Za sadržaj koji se ažurira izuzetno brzo, vektorska baza ionako ne može da prati — jednostavno se ne skladišti, već se u Agent-u zakači alat za upit u realnom vremenu, pa model povlači podatke kad zatreba, bez ulaženja u vektorsku pretragu.

Q14: Kako podići tačnost RAG odgovaranja na pitanja?

Problemi sa tačnošću najčešće su u dve faze: loša faza vraćanja (recall) i loša faza generisanja, i one se moraju posebno dijagnostikovati.

Najčešći problem u fazi vraćanja je neprecizno semantičko poklapanje. Rešenje je hibridna pretraga: vektorska pretraga (semantička) i pretraga po ključnim rečima (BM25) rade paralelno, a rezultati se spajaju algoritmom inverznog rangiranja (reciprocal rank fusion), što daje 15-30 % viši recall nego jednostavna pretraga.

Drugi čest problem: pregrubo ili prefino seckanje dokumenta. Pregrubo — u jednom isječku bude previše različitih informacija pa se sličnost razvodni; prefino — kontekst puca, pa model dobije isječak koji ne razume. Preporuka je 512-1024 tokena po isječku, sa po 50-100 tokena preklapanja na početku i kraju, da se ključne informacije ne bi presekle.

Problem u fazi generisanja obično je u dizajnu upita. Modelu treba jasno reći: "Odgovaraj isključivo na osnovu sledećih dokumenata; ako u dokumentima nema relevantnih informacija, kaži direktno da ne znaš, ne izmišljaj." Uz tu dopunu, stopa halucinacija znatno pada.

Pored toga, prerasporedba (reranking) jeste jedan od najisplativijih načina za podizanje tačnosti. Prvo vektorskom pretragom grubo dohvati 20 dokumenata, a zatim reranking model radi precizno rangiranje po relevantnosti i uzima se prvih 5 za fazu generisanja. Reranking model bolje razume semantički odnos između pitanja i dokumenta nego obična vektorska sličnost, pa je poboljšanje jasno.

ending

Oblast Agent-a je sada veoma vrela, svi se natžu, ali onih koji zaista mogu na intervjuu da izlože principe mnogo je manje nego što se čini.

Preporuka je da učite uz PaiAgent projekat — adresa tutorijala je ovde: https://paicoding.com/column/14/1; od nule podignite jedan sistem Agent-a, sve ove koncepte sprovedite kroz praksu, pa ćete na intervju moći da izložite sopstveno razumevanje, a ne da ponavljate tuđe definicije.

[Pravo razumevanje počinje od padova.]

Da ste radili projekte i da ste padali — to su uverljive reference. Ako u biografiji imate kompletno iskustvo na Agent projektu poput PaiAgent-a, na pitanje intervjuvera "kako kod vas radi preliv konteksta" možete direktno reći: "Koristili smo troslojno rešenje — klizni prozor čuva poslednjih deset krugova, sažimanje rezimea pokriva srednji deo istorije, a ključne činjenice izdvajamo zasebno..." — taj osećaj nije isto kao učenje napamet.

Snaga i napredak svima nama.