Većina AI timova koji žele bolje performanse agenata poseže za istim polugama: većim kontekstnim prozorima, većim brojem dokumenata i pametnijim upitima. Ovaj članak tvrdi da je taj instinkt potpuno pogrešan. Ne nedostaje nam više informacija. Nedostaje kontrola. Dobro osmišljen kontrolni sloj razlikuje agenta koji radi u demonstraciji od onog koji radi u produkciji.
Veća memorija, više dokumenata ili duži kontekstni prozor ne čine AI agenta pametnijim, već samo sporijim i skupljim. Pravi napredak dolazi kada agenta naučite da bira šta mu treba i kada mu treba, umjesto da sve obrađuje odjednom.
Pouzdanost dolazi iz petlje, a ne iz modela. Razlika između agenta koji impresionira u demonstraciji i onog koji se dobro pokazuje u produkciji nije u kvalitetu AI-ja, već u tome provjerava li sistem vlastiti rad. Agenti koji planiraju, djeluju, posmatraju i verificiraju svaki korak uočavaju vlastite greške umjesto da samouvjereno griješe.
Većina današnjih AI agenata zapravo su chatbotovi s dodatnim koracima — nemaju mehanizam kojim bi znali jesu li na pravom putu, kada trebaju stati ili kada trebaju isprobati drugačiji pristup. Dodavanje odgovarajućeg kontrolnog sloja — jasnih kriterija uspjeha, strukturiranog stanja i validacijskih provjera — pretvara objekt nalik agentu u nešto čemu zaista možete vjerovati.
Šta ste jučer ručali?
Vjerovatno niste ponovo proživjeli svako sjećanje koje imate dok niste stigli do „jučer + ručak“. Odmah ste prešli na dio iskustva u kojem se ti pojmovi nalaze. To je koristan mentalni model za izgradnju agenata:
Ogroman kontekstni prozor nije memorija.
Gomila dohvaćenih dokumenata nije razumijevanje.
Dug lanac razmišljanja nije pouzdanost.
To su sastojci. Ali ono zbog čega agent zaista djeluje kao agent isto je ono zbog čega vaš mozak ne pretražuje grubom silom cijelu vašu životnu historiju: kontrola.
Nedavni pregled — Agentic Reasoning for Large Language Models — odlično je sažeo (i imenovao) promjenu koju su mnogi od nas osjetili tokom razvoja: prelazak s rezonovanja unutar modela na rezonovanje putem interakcije. Ova objava nije sažetak tog rada. Ona pokušava pretočiti tu promjenu u praktičan dizajn sistema:
Ako agente gradite kao chatbotove s alatima, i dalje ćete dobijati tipične greške chatbotova, samo sa skupljim posljedicama.
Neko vrijeme naš zadani recept za „učiniti model pametnijim“ u suštini je bio: bolji upiti, lanac razmišljanja, samodosljednost / poboljšanja zasnovana na uzorkovanju i možda malo pretraživanja.
ReAct je bio prekretnica jer je obrazac „misao → radnja → zapažanje“ učinio prirodnim. Ali obratite pažnju na implicitno ograničenje: mnogo toga i dalje završi kao „zaključivanje učenjem s jednim primjerom, ali s više tokena“. Pregled to preciznije opisuje: agentsko rezonovanje naglašava skaliranje interakcije tokom testiranja — pretvaranje zaključivanja u iterativni proces u kojem model, memorija i okruženje ostaju dio petlje.
Ako ste izgradili (ili koristili) agente koji djeluju impresivno u demonstracijama, ali su krhki u stvarnim radnim tokovima, ovo je za vas.
Opisat ću obrazac koji sam često viđao (i čije sam verzije svakako i sam gradio):
Uzmite dobar model za razgovor
Dodajte nekoliko alata (pretraživanje, upit bazi podataka, možda izvršavanje koda)
Dodajte RAG
Dodajte sistemski upit „you are an autonomous agent“
Sve obuhvatite while-petljom dok se ne zaustavi ili ne istekne vrijeme
Čestitamo, dobili ste objekt nalik agentu. Ali obično zakaže na predvidljive načine:
Nadut kontekst: svako zapažanje se dopisuje, a upiti postaju arheološki slojevi.
Nasumično korištenje alata: „pogrešan alat, ali samouvjereno“ postaje zadani način neuspjeha.
Nema uslova za zaustavljanje: nastavlja jer može, a ne zato što treba.
Nema discipline uzemljenja: ne primjećuje da griješi osim ako ga na to ne prisilite.
Memorija = historija razgovora: što je zapravo pisanje zapisnika i nazivanje toga učenjem.
Zato „agenti“ često djeluju čarobno u demonstracijama, a haotično u produkciji. To potvrđuje i naše iskustvo s uvođenjem agentskih sistema u produkciju: kada više ne procjenjujete model nego sistem, načini neuspjeha obuhvataju navigaciju, pravilnu upotrebu alata, sažimanje konteksta i dizajn evaluacije, a ne samo pitanje „je li model tačno odgovorio“.
Stoga se postavlja pitanje: kako izgleda namjenski agent?
Da ovo bude manje apstraktno, slijedi jednostavan radni tok koji većina ljudi može zamisliti: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Uobičajena implementacija „nalik agentu“ izgleda ovako:
Odmah dohvati mnoštvo dokumenata o pravilima aviokompanija / putovanja (čak i ako još nijedan nije potreban).
Pozove alat za pretraživanje, zalijepi dugu listu rezultata u upit i „odabere jedan“.
Prerano izvrši rezervaciju bez provjere ograničenja (vrijeme dolaska / prtljag / sjedište / pravila).
Ako ne uspije, pokušava ponovo na malo drugačiji način, ali bez jasnog uvida u to šta se promijenilo ili šta je naučio.
Problem nije u tome što model ne može rezonovati, već u tome što sistem ne kontrolira radni tok.
Agentski pristup tretira zadatak kao interaktivan proces s eksplicitnim stanjem i provjerama:
PLANIRAJ: ponovi ograničenja i navedi podatke koji nedostaju (npr. „koji aerodrom preferirate?“ / „odgovara li vam jedno presjedanje?“).
DJELUJ: pozovi pretragu letova strukturiranim upitom (raspon datuma, ograničenje vremena dolaska, budžet).
POSMATRAJ: pohrani rezultate u sažet objekt stanja (pet najboljih opcija s cijenom, vremenom dolaska i presjedanjima), a ne kao golem zalijepljeni blok.
AŽURIRAJ: doradi upit ako ograničenja nisu ispunjena (npr. „dolazak prije 18 sati previše je strog — proširiti vremenski raspon ili povećati budžet?“).
VERIFICIRAJ: pokreni validatore („dolazak < 18:00“, „cijena ≤ £900“, „usklađeno s pravilima“, „dostupan odabir sjedišta“).
ZAUSTAVI: tek kada API za rezervacije vrati potvrdu i svi validatori odobre rezultat.
Promjena je suptilna, ali presudna. Dohvaćanje je uslovno (nije refleks), kontekstom se upravlja (stanje je strukturirano, a ne nagomilano), a verifikacija je dio petlje (nije prepuštena korisniku). Zamijenite „rezervaciju leta“ s „izradom narudžbenice“, „izdavanjem povrata novca“, „promjenom produkcijske konfiguracije“ ili „isporukom PR-a“ i priča ostaje ista: kada agent može djelovati, petlja postaje važnija od upita.
Prethodno spomenuti pregled organizira agentsko rezonovanje u tri sloja: temeljni (planiranje / upotreba alata / pretraživanje), samorazvijajući (povratne informacije i memorija) i kolektivni (koordinacija više agenata).
Međutim, dublja ideja glasi: rezonovanje postaje princip organizacije planiranja, odlučivanja i verifikacije, a ne samo generiranja uvjerljivog lanca razmišljanja. To zvuči apstraktno dok ne utvrdite šta se time mijenja u vašoj arhitekturi. Treba zapamtiti tri ključne stvari:
Dobar agent ne bi trebao pristupati dohvaćanju kao nečemu što se „uvijek radi“. Dohvaćanje je odluka, a ne refleks.
Evo praktičnog pravila:
Ako vaš sistem dohvaća podatke pri svakom koraku, niste izgradili dohvaćanje, već porez na kontekst.
To se stalno pojavljuje u stvarnom radu. Pri otklanjanju produkcijskog incidenta ne ubacujete sve zapisnike u kontekst; na osnovu trenutne hipoteze odlučujete koje ćete metrike ili zapisnike sljedeće dohvatiti. To je „agentsko dohvaćanje“. Evo konkretnijeg obrasca:
Odlučite trebate li dohvaćanje
Ako trebate: sastavite upit, dohvatite, pregledajte i izdvojite
Ako su dokazi proturječni: dohvatite ponovo
Tek tada objedinite zaključke
Tu se i „agentski RAG“ počinje razlikovati od tradicionalnog RAG-a: dohvaćanje postaje promišljen korak rezonovanja, a ne zadana faza procesnog toka.
Čim prestanete procjenjivati „model“ i počnete procjenjivati „sistem“, praćenje stanja i toka izvršavanja postaju važni.
Industrija je do sada jasnije definirala, između ostalog, opservabilnost radnih tokova agenata. Naprimjer, OpenAI Agents SDK ima ugrađeno praćenje i nadzornu ploču Traces koja bilježi izvršavanja agenata (generiranja, pozive alata, primopredaje, zaštitne mehanizme i prilagođene događaje), upravo kako biste mogli korak po korak otkloniti greške i provjeriti šta se dogodilo.
To nije tek „poželjna opcija“. To je razlika između sistema u kojem možete otkloniti greške i onog koji možete procijeniti samo po osjećaju.
Po mom mišljenju, najprimjenjiviji dio pregleda jeste njegova direktnost u pogledu povratnih informacija. Povratne informacije dijeli u tri režima: refleksivne povratne informacije (generiraj → kritiziraj → revidiraj), parametarsku prilagodbu (učenje finim podešavanjem / RL-om) i povratne informacije vođene validatorom (ponavljaj dok validator ne odobri rezultat).
Većina timova trebala bi početi s povratnim informacijama vođenim validatorom jer su dosadne, ali djelotvorne. Ako možete napisati bilo kakav validator koji provodi jedinične testove, provjerava šemu, primjenjuje poslovna pravila / ograničenja („bez povrata iznad X bez eskalacije“) ili utvrđuje činjeničnu tačnost („izvori su obavezni“), nedeterministički izlaz modela možete pretvoriti u nešto čemu zaista možete vjerovati.
Jedna od promjena iz kategorije „nepoznatih nepoznanica“ jednostavna je: u svijetu agenata pouzdanost često više proizlazi iz petlje nego iz modela.
Ovo je najjednostavnija disciplina petlje koju sam pronašao, a koja pouzdano poboljšava ponašanje bez obučavanja:
Radite u koracima: Planiraj → Djeluj → Posmatraj → Ažuriraj,
Nakon svakog koraka Djeluj sažmite zapažanje u 1–3 stavke,
Zaustavite se kada su kriteriji uspjeha ispunjeni ili je budžet potrošen; vratite najbolji poznati rezultat i preostale neizvjesnosti.
Cilj nije učiniti model opširnim. Cilj je učiniti sistem razumljivim i na svakom koraku nametnuti „dodir sa stvarnošću“. Primjer vrlo blizak inženjerima jeste uzemljenje u zatvorenoj petlji po uzoru na CI:
Planiraj: predloži spisak izmjena
Djeluj: pokreni testove / lintanje
Posmatraj: analiziraj neuspjehe
Ažuriraj: primijeni zakrpu i pokušaj ponovo
Nekoliko pitanja koja obično razotkriju slučajno nastale dizajne agenata:
„Bira li moj agent šta treba dohvatiti ili ja uvijek dohvatam podatke?“
Ako je dohvaćanje bezuslovno, platit ćete većom latencijom i troškovima, razvodnjenim kontekstom te većim rizikom da loš ulaz proizvede loš izlaz.
„Može li moj agent primijetiti da griješi?“
Ako je jedini signal povratne informacije vašeg agenta to da se „korisnik iznervira“, provodite RL uz ljudsku patnju. Petlja ponovnih pokušaja vođena validatorom najjednostavniji je način da ga suočite sa stvarnošću.
„Može li se pisati u memoriju i poboljšava li se ona s vremenom?“
Ako vaša „memorija“ samo dopisuje historiju razgovora, zapravo pišete zapisnike. Način na koji pregled opisuje memoriju važan je: memorija postaje dinamički rastući kontekst koji agenti s vremenom usavršavaju, a ne samo transkript.
Zapisnici vam govore šta se dogodilo, a memorija šta sljedeći put trebate učiniti. Historija razgovora je transkript. Memorija je politika koja se razvija i određuje šta vrijedi zadržati za ubuduće.
Za početak je praktična mala tabela „naučenih lekcija“, u kojoj ključ čine vrsta zadatka, alat i način neuspjeha, a vrijednost ono što je uspjelo i ono što treba izbjegavati. Cilj nije izgraditi savršen graf znanja. Cilj je stvoriti kumulativno poboljšanje ponašanja: memorija i povratne informacije pretvaraju agente iz „pomagača bez stanja“ u sisteme koji se s vremenom poboljšavaju.
Primamljivo je problemu dodavati sve više agenata, ali to često umnožava troškove koordinacije. Dobar obrazac „minimalno održivog tima“:
Koordinator: raščlanjuje i dodjeljuje
Izvršilac: poziva alate / provodi izmjene
Kritičar/evaluator: provjerava tačnost/rizik
Čuvar memorije: zapisuje i uređuje naučene lekcije
Ako ne možete objasniti za šta je svaki agent odgovoran, vjerovatno vam još ne treba više agenata.
Ako zaista prihvatimo promjenu paradigme, vjerovatno ćemo prestati trpati sve u upite, tretirati neuspjehe kao konačne izlaze i procjenjivati agente kao chatbotove. Počet ćemo tretirati agente kao ono što jesu: softverske sisteme u kojima je jezik kontrolna ravan, a pouzdanost proizlazi iz petlje.
Prije nego što dodate još jedan model, dodajte još jednu evaluacijsku petlju. Prije nego što dohvatite sve, učinite dohvaćanje uslovnim. Isporučite jedan validator prije nego što isporučite deset. Memoriju tretirajte kao odluke o pravilima, a ne kao bazu podataka. A kada prelazite na više agenata, počnite s dva, a ne s dvadeset. To nisu pravila, već obrasci koji su opstali u produkciji.