Ha? Kada vidite ovu sliku, a zatim otvorite Pinduoduo, u vašoj listi preporuka sigurno će se pojaviti figuren Xiaye.

Neko je u grupi bacio deo razgovora, čiji je sadržaj bio otprilike: kada vidite ovu sliku, a zatim otvorite Pinduoduo, u vašoj listi preporuka sigurno će se pojaviti figuren Xiaye.

Mnogi su probali i zaista je tako.

I ja sam probao, rezultat je na slici ispod.

Da li ekstrakcija multimodalnih karakteristika zaista može da ostvari prepoznavanje slika kroz različite aplikacije? Kako kolaborativno filtriranje i duboko CTR rangiranje sarađuju u scenariju preporuke? Koju ulogu u takvom sistemu igra Agent?

Siguran sam da su mnogi znatiželjni, a ja sam upravo prikupio iskustva sa intervjua za poziciju Agent u Pinduoduu, zajedno sa mojim odgovorima delim ih sa svima.

(Ceo tekst je prilično obiman, garantujem da ćete naučiti puno toga, vežite sigurnosne pojaseve, polazimo.)

content

01,Koje AI tehnologije se koriste iza Pinduoduo sistema preporuka?

Prvo pitanje Lao Wang-a: "Korisnik je pogledao sliku, otvorio Pinduoduo i video preporuke povezanih proizvoda. Koji princip stoji iza toga?"

Ako zaista može da se ostvari prepoznavanje slika kroz aplikacije pa do preporuke, to bi otprilike izgledalo ovako:

• Na strani uređaja radi se prikupljanje slika ili OCR, izdvajaju se vizuelne karakteristike;
• U oblaku multimodalni model mapira karakteristike slike na kategorije proizvoda;
• Zatim se ažurira profil interesa korisnika, kroz kolaborativno filtriranje i duboki CTR model radi rangiranja, i konačno gura u glavni info-tok.

Lao Wang je detaljnije pitao: "Kako kolaborativno filtriranje i duboki CTR model sarađuju?"

"Kolaborativno filtriranje rešava pitanje 'šta su još kupili oni koji su slični meni', u suštini je to izračunavanje sličnosti na osnovu matrice ponašanja korisnika. Duboki CTR model (npr. DIN, DIEN) rešava pitanje 'kolika je verovatnoća da će ovaj korisnik u trenutnom kontekstu kliknuti na određeni proizvod', pri čemu se uzimaju u obzir trenutni interesi korisnika, karakteristike proizvoda i kontekstualne karakteristike radi finog rangiranja. Kolaborativno filtriranje radi pronalaženje kandidata, CTR model radi rangiranje, to je klasična kombinacija u sistemu preporuka."

"Međutim, iskreno, lično ocenjujem da je pojava figurena Xiaye najverovatnije slučajnost — to je ionako popularna kategorija, mogu je videti i novi i stari korisnici."

"Ili je prosto bag."

Lao Wang je klimnuo: "U redu, o preporukama toliko. Na biografiji imam projekat PaiCLI koji si sam napravio, hajde da pričamo o unutrašnjem mehanizmu Agent-a."

GitHub adresa: https://github.com/itwanger/PaiCLI-Python

02,Zašto je arhitektura memorije u tri sloja ovako dizajnirana?

Lao Wang pita: "Kako je memorija Agent-a podeljena u slojeve? Zašto baš tako?"

Ja kažem: "U tri sloja. Prvi sloj je kratkoročna memorija, čuva kontekst trenutnog razgovora, uključujući šta je korisnik rekao, šta je asistent odgovorio, koje rezultate je vratio poziv alata."

Njena osnova je LinkedHashMap, održava se redosledom umetanja, sa gornjom granicom budžeta tokena.

Kada token prekorači budžet, automatski se izbacuje najstarija stavka, a izbačene stavke privremeno se smeštaju u red za kompresovani rezime, čekajući da ih LLM naknadno sažme.

"Drugi sloj je dugoročna memorija, perzistira kroz sesije."

Ovde se čuvaju informacije koje imaju vrednost i van sesije: preferencije korisnika, činjenice o projektu, ključne odluke. Osnova je ConcurrentHashMap sa sinhronizovanim upisom u JSON datoteku na disk. Pri svakom upisu radi se deduplikacija sadržaja, ako već postoji stavka sa potpuno istim sadržajem, jednostavno se preskače.

"Treći sloj je sloj pretraživanja memorije, on ne čuva podatke, već je odgovoran za pronalaženje memorija iz prethodna dva sloja koje su najrelevantnije za trenutni upit."

Zašto ovakva podela?

"Zato što je kontekstni prozor LLM-a ograničen resurs. Kratkoročna memorija rešava problem 'da se trenutni razgovor ne izgubi', dugoročna memorija rešava problem 'da se setim kroz sesije', a sloj za pretraživanje rešava problem 'koje treba setiti se'. Svaki od tri sloja upravlja svojim delom, bez međusobnog ometanja."

03,Datoteka kao izvor činjenica, zašto ne preko RAG / vektorske baze?

Lao Wang detaljnije: "Dugoročna memorija se čuva u JSON datoteci? Zašto ne vektorska baza?"

Ja kažem: "Zato što dugoročna memorija čuva rafinirane činjenice, a ne duge pasuse teksta. Tipična dugoročna memorija je nešto poput 'korisnik preferira zsh umesto bash'."

Količina podataka je mala, od nekoliko desetina do nekoliko stotina stavki, podudaranje ključnih reči je sasvim dovoljno.

"Još važnije, dugoročna memorija zahteva visoku učestalost čitanja i pisanja i trenutnu konzistenciju. Korisnik kaže 'zapamti, ubuduće prilikom pristupa Yuque-u pre svega koristi Chrome login stanje', ja to moram odmah da sačuvam, da bi u sledećem krugu razgovora moglo da se iskoristi."

Upis u JSON datoteku je sinhron, nakon svake store operacije podaci su na disku. Ako bi se koristila vektorska baza, još bi se čekalo na izračunavanje embedding-a i ažuriranje indeksa, i latencija i kompleksnost bi porasli.

04,Datoteka kao izvor činjenica, kako se osigurava ažurnost i konzistencija?

Lao Wang pita: "Kako skladištenje u datoteci osigurava da podaci ne zastare i da ne dođe do konflikata?"

Ja kažem: "Ažurnost se osigurava pomoću dva mehanizma."

Prvo, upis znači trenutnu perzistenciju. ConcurrentHashMap garantuje bezbednost konkurencije, nakon svakog store-a odmah se cela lista stavki serijalizuje i upisuje na disk.

Drugo, pri pretraživanju postoji vremensko opadanje. timestamp memorije učestvuje u izračunavanju relevantnosti, što je memorija starija to je niže u rangiranju pri pretraživanju. Činjenica unešena pre 24 sata automatski će joj se rezultat smanjiti na polovinu u odnosu na novu činjenicu.

"Konzistencija se osigurava deduplikacijom. Pri store-u dugoročna memorija prolazi kroz postojeće stavke, ako je sadržaj nove stavke potpuno isti kao postojeća, jednostavno se preskače. To sprečava da LLM više puta izdvaja istu činjenicu i dovodi do bubrenja memorije."

"Pored toga, dugoročna memorija razlikuje oblast važenja."

Svaka memorija ima polje scope, podeljeno na project i global. Činjenice na nivou projekta vide se samo u okviru odgovarajuće putanje projekta, dok se globalne preferencije dele kroz projekte. Pri pretraživanju se radi filtriranje vidljivosti po putanji projekta, kako bi se izbeglo da činjenice iz projekta A zagađuju kontekst projekta B.

05,Kada je datoteka prevelika, indeks ne može svaki put da čita celu, šta onda?

Lao Wang klima glavom, zatim pita: "Memorijska datoteka postaje sve veća, učitavanje celog fajla nije realno, šta raditi?"

Na dva nivoa.

Prvo, kontrola obima same dugoročne memorije. Dugoročna memorija čuva samo rafinirane činjenice, ne čuva original razgovora i izlaze alata. Rezultati alata se u kratkoročnoj memoriji skraćuju na ispod 500 znakova i ne ulaze u dugoročnu memoriju. Uz mehanizam deduplikacije sadržaja, broj dugoročnih memorijskih stavki obično je na nivou od nekoliko desetina do nekoliko stotina, JSON datoteka dostiže najviše nekoliko stotina KB, a učitavanje celog fajla nije nikakav problem.

Drugo, kontrola budžeta pri ubacivanju u kontekst LLM-a. Pre svakog poziva LLM-a, sloj za pretraživanje memorije iz dugoročne memorije izvlači nekoliko najrelevantnijih stavki i ubacuje ih u system prompt, postoji tvrdi gornji limit na količinu ubacivanja, pet hiljaditina context window-a, najviše 5000 tokena.

To znači da čak i ako dugoročna memorija ima 500 stavki, u kontekst LLM-a se ubacuje desetak.

06,Kako Agent poziva alate?

Lao Wang kaže: "Memorija je jasna, hajde o pozivu alata. Kako Agent poziva alate?"

Ja kažem: "Standardni mehanizam Function Calling."

Glavna petlja je while(true) ReAct petlja.

U svakoj iteraciji Agent šalje LLM-u trenutnu istoriju razgovora zajedno sa listom definicija alata.

Odgovor LLM-a ima dve mogućnosti: ako smatra da treba pozvati alat, u odgovoru vraća polje toolCalls koje sadrži ime alata i JSON parametre; ako misli da ima dovoljno informacija, vraća direktan odgovor na prirodnom jeziku.

"Nakon što primi toolCalls, Agent ih umotava u zahtev za poziv i prosleđuje ih registru alata na raspoređivanje i izvršenje."

Registar alata interno održava ConcurrentHashMap, ključ je ime alata, vrednost su definicija alata i izvršilac.

Nakon izvršenja, rezultat se kao poruka sa ulogom tool dodaje u istoriju razgovora, a zatim se ulazi u sledeću iteraciju, LLM nastavlja sa rezonovanjem na osnovu rezultata alata.

"Podržano je i paralelno pozivanje. Ako LLM jednim putom vrati više toolCalls, registar alata koristi fiksni thread pool za paralelno izvršenje, najviše 4 alata istovremeno. Svaki alat ima nezavisnu kontrolu vremenskog ograničenja, pojedinačni alat 60 sekundi, cela grupa 90 sekundi."

Ima li drugih načina poziva?

Lao Wang detaljnije: "Pored Function Calling, ima li drugih načina poziva?"

Ja kažem: "Ima. MCP alati idu drugom putanjom."

MCP alati se ne izvršavaju unutar procesa Agent-a, već putem JSON-RPC 2.0 protokola šalju zahtev spoljnom MCP Server procesu.

Na strani Agent-a postoji namenski modul za upravljanje koji objedinjeno upravlja životnim ciklusom svih MCP Server-a, uključujući pokretanje, inicijalno rukovanje, otkrivanje alata, poziv i gašenje.

"Ali iz ugla LLM-a, MCP alati i ugrađeni alati se ne razlikuju."

Ovaj modul za upravljanje pri pokretanju registruje alate koje izlaže svaki MCP Server u isti registar alata, format imena alata je mcp__serverName__toolName.

LLM ne vodi računa o tome da li je alat ugrađen ili MCP, gleda samo imena i opise parametara u listi definicija alata.

07,Kako Agent procenjuje da li treba pozvati alat?

Lao Wang pita: "Da li je procena da li pozvati alat logika Agent-a ili LLM-a?"

Ja kažem: "LLM sam procenjuje. Agent ne radi nikakvu hardkodovanu procenu 'da li pozvati alat'."

U svakom krugu ReAct petlje Agent prosleđuje LLM-u sve dostupne definicije alata, a LLM nakon dubokog rezonovanja sam odlučuje: koji alat pozvati u ovom krugu, koje parametre proslediti, ili direktno odgovoriti korisniku.

"Agent radi samo dve stvari: prvo, sastavlja ime, opis i parametarski šema alata u standardni JSON format i prosleđuje ih LLM-u, kako bi razumeo šta svaki alat može da uradi; drugo, savesno izvršava toolCalls koje LLM vrati, bez mešanja."

"To je osnovna ideja Function Calling-a — pravo izbora alata se prepusta modelu. Agent je izvršilac, a ne donosilac odluka."

08,Kada poziv alata ne uspe, kako se osigurava da Agent ne upadne u beskonačnu petlju ili ne odgovara nepromišljeno?

Lao Wang odmah detaljnije: "Šta ako poziv alata ne uspe? Da li će Agent stalno iznova pokušavati i upasti u beskonačnu petlju?"

Ja kažem: "Neće, postoje tri odbrambene linije."

Prva je mehanizam budžeta petlje, koji pre svakog kruga radi proveru budžeta.

Mehanizam budžeta prati tri dimenzije: ukupnu potrošnju tokena, broj izvršenih iteracija i detekciju beskonačne petlje.

Princip detekcije beskonačne petlje je da posmatra da li se u poslednjih nekoliko krugova ponavlja isti obrazac poziva alata — ako se u uzastopnim krugovima poziva isti alat sa istim parametrima, direktno se ocenjuje kao zastoj, prisilno izlazi iz petlje i vraća poruku o grešci.

"Druga je obrada izuzetaka na nivou alata."

"Registar alata pri izvršenju alata deli sve izuzetke u tri kategorije: odbijanje smernicom (prekoračenje putanje, komanda je onemogućena) vraća poruku sa prefiksom 'odbijeno smernicom'; običan izuzetak vraća poruku sa prefiksom 'izvršenje alata nije uspelo'; istek alata vraća 'izvršenje alata je isteklo, otkazano'."

U svakom slučaju, izuzetak se hvata i pretvara u nisku na prirodnom jeziku, pa se kao poruka sa ulogom tool vraća LLM-u. Kada LLM vidi poruku o neuspehu, sam odlučuje: da proba na drugi način ili da direktno saopšti korisniku da operacija nije uspela.

"Treća je Reviewer revizija u režimu više Agent-a. Ako se koristi režim kolaboracije više Agent-a, nakon izvršenja svakog koraka prolazi se kroz Reviewer reviziju. Koraci koje Reviewer oceni kao neodgovarajuće ponavljaju se najviše 2 puta, a kada se prekorači broj pokušaja, zadržava se trenutni rezultat i obeležava status koraka, bez beskonačnog ponavljanja."

09,Postoji li preventivni mehanizam protiv višestrukog čuvanja beznačajne memorije?

Lao Wang pita: "Ranije je rečeno da dugoročna memorija automatski izdvaja činjenice. Šta ako LLM izvuče gomilu smeća?"

Ja kažem: "Postoje tri sloja filtriranja."

"Prvi sloj je detekcija namere. Čuvanje dugoročne memorije ima samo dva ulaza: prvi, korisnik izričito kroz razgovor kaže 'zapamti', 'pamti', 'ubuduće se seti', što pokreće alat save_memory; drugi, automatsko izdvajanje činjenica pri kompresiji konteksta. U podsticajnom upitu za automatsko izdvajanje jasno se kaže LLM-u 'apsolutno ne izdvajaj privremeni zadatak koji se izvršava u trenutnom krugu, jednokratna imena datoteka, nagađanja samog modela'."

"Drugi sloj je hardkodovano filtriranje. Čak i ako LLM ipak vrati sadržaj koji ne bi trebalo da se čuva, u kodu postoje dve liste ključnih reči koje rade sekundarno presretanje."

"Jedna lista je prefiks privremenih činjenica — rečenice koje počinju sa 'korisnik želi', 'pomozi mi', 'napravi', 'obriši', 'u trenutnom krugu' i sl. direktno se filtriraju. Druga lista su tragovi nagađanja — rečenice koje sadrže reči 'možda', 'trebalo bi', 'pogodi', 'pretpostavi' i sl. takođe se filtriraju. Samo rečenice koje prođu obe provere i koje sadrže karakteristike trajne činjenice (kao što su ključne reči 'korisničke preferencije', 'projekat', 'tehnološki sklop', 'konfiguracija') zaista se upisuju u dugoročnu memoriju."

"Treći sloj je deduplikacija sadržaja pri upisu. Dugoročna memorija pre upisa prolazi kroz postojeće stavke, ako je sadržaj potpuno isti, preskače se."

10,Koji problem rešava MCP protokol?

Lao Wang kaže: "Hajde o MCP-u. Koji je osnovni problem koji rešava?"

Ja kažem: "Jednom rečenju: MCP rešava problem standardizacije pristupa alatima za Agent-a."

Pre MCP-a, za svaki spojeni spoljni alat, u kodu Agent-a se morala hardkodovati jedna logika poziva, za HTTP jedna, za CLI druga, za SDK treća, svi formati parametara i obrada grešaka nepovezani. MCP apstraktuje pristup alatima u jedinstveni sloj protokola.

Kako rešava?

"U tri koraka. Prvi korak je apstrakcija transportnog sloja. MCP definiše dva standardna načina prenosa: Stdio (standardni ulaz/izlaz, pogodno za lokalne procese) i Streamable HTTP (pogodno za udaljene servise). Agent ne mora da vodi računa o tome da li je u podlozi komunikacija procesa ili mrežni zahtev, dovoljno je da implementira isti interfejs transporta."

"Drugi korak je komunikacioni protokol. Zasnovan na JSON-RPC 2.0, sa samo tri vrste poruka: Request (sa id, zahteva odgovor), Response (sa id, poklapa zahtev), Notification (bez id, jednosmerno obaveštenje). Čitav životni ciklus je initialize → tools/list → tools/call → close."

"Treći korak je otkrivanje alata. Nakon pokretanja MCP Server-a, Agent pozivom tools/list dobija imena, opise i parametarske JSON šeme svih alata koje taj Server izlaže."

Agent automatski registruje te alate u svoj registar alata, pa LLM može da poziva MCP alate kao i ugrađene.

Čitav proces je dinamičan, MCP Server može i da pošalje notifications/tools/list_changed obaveštenje, pa će Agent automatski ponovo preuzeti listu alata i ažurirati registar.

11,Šta kada se kontekstni prozor Agent-a napuni?

Lao Wang pita: "Šta raditi kada se kontekstni prozor skoro napuni?"

Ja kažem: "Automatska kompresija. U Agent-u postoji modul za kompresiju istorije razgovora, koji pre poziva LLM-a u svakom krugu ReAct petlje radi jednu proveru. Najpre procenjuje ukupan broj tokena trenutne istorije razgovora, i ako prekorači prag kompresije, pokreće kompresiju."

"Prag kompresije se dinamički izračunava na osnovu context window-a modela: context window umanjen za rezervu izlaza rezimea (najviše 20000 tokena) i umanjen za bafer automatske kompresije (najviše 13000 tokena) jeste prag okidanja. Na primer, za model od 128K, prag je oko 95K."

Kako se vrši kompresija, koji su načini?

Lao Wang detaljnije: "Kako konkretno kompresovati?"

Ja kažem: "Dva sistema za kompresiju rade paralelno, svaki upravlja svojim delom."

"Prvi sistem kompresuje listu poruka koje Agent zaista šalje LLM-u."

Algoritam je sledeći: prvo se pronalaze indeksi pozicija svih user poruka, zadržava se ne-dirnuto poslednjih 3 kruga kompletnih poruka, a sve stare poruke nakon system poruke i pre tačke podele šalju se LLM-u na sažimanje.

Nakon sažimanja, lista poruka se obnavlja: system prompt + jedna user poruka sa rezimeom + jedna assistant poruka koja potvrđuje da je razumela kontekst + poslednja 3 kruga originalnih poruka.

Tačka podele mora da padne na granicu user poruke, kako se ne bi presekao upareni protokol tool_call i tool_result."

"Drugi sistem kompresuje kratkoročnu memoriju."

On koristi Map-Reduce obrazac: prvo se stare memorijske stavke dele u grupe po 5, svaki parčić se posebno daje LLM-u na sažimanje, a zatim se svi sažeci parčića objedinjuju u jedan ukupni rezime.

Ukupni rezime se pod tipom SUMMARY ubacuje nazad u kratkoročnu memoriju. Istovremeno, tokom kompresije automatski se iz starog razgovora izdvajaju trajne činjenice i upisuju u dugoročnu memoriju.

12,Konkretan tok RAG-a

Lao Wang zamišljeno: "U redu, onda pričajmo o RAG-u. Koji je čitav tok RAG-a?"

Ja kažem: "Četiri koraka. Prvi korak je podela. Podela koda za Java datoteke radi AST raščlanjivanje, JavaParser-om se raščlanjuju sve deklaracije klasa i metoda, na nivou klase generiše se jedan chunk, za svaku metodu posebno jedan chunk. Ne-Java datoteke se dele po broju znakova, svaki segment do 2000 znakova."

"Drugi korak Embedding. Tekst svakog chunk-a šalje se Embedding modelu radi generisanja vektora. Podržani su Ollama lokalni modeli i OpenAI kompatibilni udaljeni API. Vektor i metapodaci chunk-a zajedno se upisuju u SQLite bazu."

"Treći korak izgradnja indeksa. U SQLite-u postoje dve ključne tabele: code_chunks čuva blokove koda i vektore, code_relations čuva odnose zavisnosti između kodova (ko koga poziva, ko od kog nasleđuje). Indeks je izolovan po putanji projekta."

"Četvrti korak pretraživanje. Korisnik unese upit na prirodnom jeziku, pretraživač istovremeno ide dvema putanjama: semantičko pretraživanje i pretraživanje po ključnim rečima, a nakon objedinjavanja rezultata i deduplikacije vraća TopK."

13,Embedding, kako RAG pretražuje vektore?

Lao Wang detaljnije: "Kako konkretno radi hibridno pretraživanje?"

Ja kažem: "Semantičko pretraživanje je standardno pretraživanje po sličnosti vektora."

Tekst korisničkog upita šalje se Embedding modelu i dobija se vektor upita, a zatim se sa vektorima svih chunk-ova u bazi pojedinačno izračunava kosinusna sličnost, i rangira se opadajuće po sličnosti pa uzima TopK.

Izračunavanje kosinusne sličnosti radi se u memoriji, jer je obim chunk-ova baze koda obično od nekoliko stotina do nekoliko hiljada, pa grubo prelaženje sasvim izdrži.

"Pretraživanje po ključnim rečima ne prolazi kroz Embedding, direktno u SQLite-u radi LIKE upit, i podudara ime i sadržaj chunk-a."

Osnovni rezultat pogodaka pretraživanja ključnih reči postavljen je na 0.3, a zatim se na osnovu pozicije pogotka dodaje dodatni rezultat: pogodak imena klase ili metode dodaje 0.3, pogodak putanje datoteke dodaje 0.1, pogodak u sadržaju dodaje 0.1.

"Logika objedinjavanja je: sa filePath#name kao jedinstvenim ključem radi se deduplikacija, ako se isti chunk pojavi u obe putanje pretraživanja (dvostruki pogodak), dodatno se dodaje 0.1 bonus poena."

"Zatim postoji i dodavanje poena za tip koda: tip method dodaje 0.15, tip class dodaje 0.10, jer metode i klase direktnije odgovaraju na pitanje 'kako se implementira' nego cela datoteka. Konačno se rangira opadajuće po ukupnom rezultatu, s tim da se iz iste datoteke zadržava najviše 2 rezultata, kako se ne bi jedna velika datoteka domogla svih mesta."

14,Kako se upravlja memorijom Agent-a? Gde se sve čuva?

Lao Wang pita: "Ukratko, gde se sve čuva memorija Agent-a?"

Ja kažem: "Na četiri mesta."

• Istorija razgovora: lista poruka koje Agent šalje LLM-u, čuva se u JVM heap memoriji, a po završetku sesije uništava se. To je kontekst koji LLM zaista vidi
• Kratkoročna memorija: takođe u JVM heap memoriji, ali sa nezavisnim budžetom tokena i strategijom izbacivanja. Održava se paralelno sa istorijom razgovora — prvo je ulaz za LLM, drugo je unutrašnje stanje sistema memorije
• Dugoročna memorija: čuva se u datoteci ~/.paicli/memory/long_term_memory.json, perzistira kroz sesije. Pri pokretanju se kompletno učita u ConcurrentHashMap, a tokom rada se svaki upis sinhrono radi flush na disk
• Vektorski indeks (RAG): indeks vektora koda, čuva se u SQLite bazi ~/.paicli/rag/codebase.db. Ovo ne pripada memoriji razgovora, već je oflajn indeks baze koda

"Modul za upravljanje memorijom je fasada ovog sistema, objedinjeno upravlja kratkoročnom memorijom, dugoročnom memorijom, kompresorom konteksta i pretraživačem memorije. Agent komunicira samo sa njim, a ne dira direktno podložno skladište."

15,Sistem više Agent-a, kako Agent-i sarađuju?

Lao Wang kaže: "Hajde o više Agent-a. Kako Agent-i u sistemu sarađuju?"

Ja kažem: "Master-slave arhitektura, jedan Orchestrator plus tri uloge Sub-agenta: Planner, Worker i Reviewer."

"Tok saradnje se deli u četiri faze. U prvoj fazi, nakon što korisnik pošalje zadatak, orchestrator predaje zadatak Planner-u. Zadatak Planner-a je da razloži zadatak na skup podkoraka sa zavisnostima, i da izbaci izvršni plan u JSON formatu, gde svaki korak ima id, opis i listu zavisnosti."

"U drugoj fazi, orchestrator raščlanjuje izvršni plan i radi topološko sortiranje po zavisnostima. Koraci bez međusobnih zavisnosti unutar iste grupe mogu paralelno da se izvršavaju. Pri paralelnom izvršenju, Worker-i se uzimaju iz bazena BlockingQueue, kako bi se osiguralo da isti Worker ne bude istovremeno zauzet sa dva koraka. Svaki paralelni korak koristi nezavisni PrintStream za baferisanje izlaza, a nakon grupe po redosledu step_id radi flush na terminal, kako bi se izbeglo mešanje sadržaja zbog upisa više niti u isti izlazni tok."

"U trećoj fazi, nakon izvršenja svakog koraka predaje se Reviewer-u na reviziju. Reviewer izbacuje JSON sa poljem approved, a orchestrator raščlanjuje rezultat odobrenja. Koraci koji nisu prošli vraćaju se Worker-u na ponovno izvršenje uz Reviewer-ov povratnu informaciju, najviše 2 puta."

"U četvrtoj fazi, kada su svi koraci završeni, orchestrator objedinjuje rezultate i vraća ih korisniku."

Kako se upravlja kontekstom između više Agent-a?

Lao Wang detaljnije: "Da li je kontekst između ovih Sub-agenta deljen ili izolovan?"

Ja kažem: "Istorija razgovora je izolovana, registar alata je deljen."

Svaki Sub-agent ima svoju nezavisnu istoriju razgovora i sistemski podsticaj (prema ulozi koristi različite šablone podsticaja), međusobno se ne ometaju. Ali dele isti registar alata — što znači da je skup alata koje mogu da pozivaju svi Sub-agenti isti, samo što Planner i Reviewer ne pozivaju alate, to radi samo Worker.

"Nakon izvršenja svakog koraka, Worker čisti svoju istoriju razgovora, zadržavajući samo sistemski podsticaj. To je da Worker pri obradi sledećeg koraka ne bi bio ometan zaostalim kontekstom prethodnog."

Kako se prenosi status zadatka?

"Status zadatka se prenosi preko nepromenljivog objekta zapisa koraka."

Svaki korak ima pet polja: id, description, dependencies, result i status. status prelazi iz PENDING → RUNNING → COMPLETED/FAILED.

Orchestrator pri dodeljivanju sledeće grupe izvršivih koraka proverava da li su sve dependencies svakog PENDING koraka u COMPLETED stanju.

"Prenos konteksta između koraka sastavlja orchestrator: on rezultate završenih koraka od kojih trenutni korak zavisi sastavlja u jedan kontekst i ubacuje u opis zadatka za Worker-a. Tako Worker ne mora da vidi istoriju svih koraka, već samo rezultate prethodnih koraka koji su direktno povezani sa njim."

16,Kako se kvantifikuje i ocenjuje tok rada i rezultati sistema više Agent-a?

Lao Wang je na kraju postavio otvoreno pitanje: "Kako se ocenjuju rezultati ovog sistema više Agent-a?"

Ja kažem: "Tri dimenzije. Prva je stopa završetka zadatka. Ako su svi koraci u COMPLETED stanju, računa se kao završeno; ako ima FAILED koraka, računa se kao delimično završeno. Ovaj pokazatelj odražava end-to-end pouzdanost."

"Druga je stopa prolaznosti Reviewer-a i stopa ponavljanja. Ako veliki broj koraka zahteva ponavljanje da bi prošli Reviewer reviziju, to ukazuje na problem u Worker-ovom podsticaju ili kombinaciji alata. Najviše 2 ponavljanja po koraku je tvrdi gornji limit, kad se prekorači prisilno se zadržava trenutni rezultat. Ovaj pokazatelj odražava kvalitet izvršenja pojedinačnog koraka."

"Treća su potrošnja tokena i vreme. Svaki poziv LLM-a svakog Sub-agenta putem mehanizma budžeta beleži input token, output token i cached input token. Orchestrator može da izračuna ukupnu potrošnju tokena za čitav zadatak. Paralelno izvršeni koraci mogu se proceniti poređenjem vremena grupe sa procenom serijskog vremena, čime se dobija ubrzanje od paralelizacije."

"Iskreno, ocenjivanje sistema više Agent-a još uvek nema jedinstveni standard u industriji. Trenutno se uglavnom oslanjam na Reviewer-ov mehanizam revizije za onlajn kontrolu kvaliteta, dok je oflajn ocenjivanje još uvek u fazi istraživanja."

Kako upisati PaiCLI u biografiju?

Ime projekta: PaiCLI Kratak opis projekta: Java Agent komandni alat uporediv sa Claude Code-om, podržava ReAct petlju, sistem memorije u tri sloja, integraciju MCP protokola, RAG pretraživanje koda i kolaboraciju više Agent-a Tehnološki sklop: Java 17, JSON-RPC 2.0, SQLite, JavaParser, OkHttp

Ključne odgovornosti:

• Dizajnirao i implementirao arhitekturu memorije u tri sloja (kratkoročna/dugoročna/pretraživanje), putem Map-Reduce sažimanja i ocenjivanja sa vremenskim opadanjem, povećao stopu kompresije konteksta na preko 60%, uz zadržavanje celovitosti ključnih informacija
• Implementirao klijent MCP protokola, podržava Stdio i Streamable HTTP dva načina prenosa, dinamički otkriva i registruje spoljne alate, ostvaruje plug-and-play ekosistem alata za Agent-a
• Izgradio sistem hibridnog RAG pretraživanja, kombinuje AST nivou podelu koda, vektorsko semantičko pretraživanje i precizno podudaranje ključnih reči, uz ponderisano objedinjavanje dvostrukih pogodaka; tačnost lociranja koda znatno je bolja nego kod čistog semantičkog pretraživanja
• Implementirao okvir za kolaboraciju više Agent-a (Planner/Worker/Reviewer arhitektura), podržava topološko sortiranje zavisnosti i paralelno izvršenje grupa, a preko nezavisnog baferisanja izlaza i poolinga Worker-a izbegava konflikte konkurencije
• Dizajnirao mehanizam kontrole budžeta petlje, integrisao detekciju beskonačne petlje, praćenje ukupnih tokena i tro slojnu obradu izuzetaka alata, čime se osigurava stabilan rad Agent-a u dugim sesijama bez gubitka kontrole

Vidimo se u sledećem.