Većina AI timova koji žele poboljšati rad agenata poseže za istim polugama: većim kontekstnim prozorima, većim brojem dokumenata i pametnijim upitima. Ovaj članak tvrdi da je taj instinkt posve pogrešan. Ne nedostaje nam više informacija. Nedostaje nam kontrola. Dobro osmišljen kontrolni sloj odvaja agenta koji radi u demonstraciji od onoga koji radi u produkciji.
Veća memorija, više dokumenata ili dulji kontekstni prozor ne čine AI agenta pametnijim, nego samo sporijim i skupljim. Pravi napredak postiže se kada agent nauči odabrati što mu treba i kada mu to treba, umjesto da sve obrađuje odjednom.
Pouzdanost proizlazi iz petlje, a ne iz modela. Razlika između agenta koji oduševljava u demonstraciji i onoga koji je pouzdan u produkciji nije u kvaliteti umjetne inteligencije, nego u tome provjerava li sustav vlastiti rad. Agenti koji u svakom koraku planiraju, djeluju, promatraju i provjeravaju uočavaju vlastite pogreš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 pokušati drukčije. Odgovarajući kontrolni sloj — jasni kriteriji uspjeha, strukturirano stanje i validacijske provjere — pretvara objekt nalik agentu u nešto čemu doista možete vjerovati.
Što ste jučer ručali?
Vjerojatno niste ponovno proživjeli svako sjećanje dok niste došli do „jučer + ručak”. Odmah ste prešli na dio iskustva u kojem se nalaze ti pojmovi. To je koristan mentalni model za izgradnju agenata:
Golem kontekstni prozor nije memorija.
Hrpa dohvaćenih dokumenata nije razumijevanje.
Dug lanac razmišljanja nije pouzdanost.
To su sastojci. No ono zbog čega agent djeluje kao agent isto je ono zbog čega vaš mozak ne pretražuje grubom silom cijelu vašu životnu povijest: kontrola.
Nedavni pregled — Agentic Reasoning for Large Language Models — izvrsno je sažeo (i imenovao) promjenu koju su mnogi od nas osjetili tijekom razvoja: od rasuđivanja unutar modela do rasuđivanja kroz interakciju. Ova objava nije sažetak tog rada. Ona je pokušaj prevođenja te promjene u praktičan dizajn sustava:
Ako agente gradite kao chatbotove s alatima, i dalje ćete nailaziti na tipične pogreške chatbotova, samo s većom cijenom.
Neko je vrijeme naš standardni recept za „pametniji model” zapravo glasio: bolji upiti, lanac razmišljanja, samodosljednost / poboljšanja temeljena na uzorkovanju i možda malo pretraživanja.
ReAct je bio prekretnica jer je slijed „misao → radnja → opažanje” učinio prirodnim. No obratite pozornost na implicitno ograničenje: mnogo toga i dalje završava kao „zaključivanje s jednim primjerom, ali s više tokena”. Pregled to preciznije opisuje: agentsko rasuđivanje naglašava skaliranje interakcije tijekom testiranja i pretvara zaključivanje u iterativan proces u čijoj petlji ostaju model, memorija i okruženje.
Ako ste gradili (ili upotrebljavali) agente koji djeluju impresivno u demonstracijama, ali su krhki u stvarnim tijekovima rada, ovo je za vas.
Opisat ću obrazac koji sam često viđao (i čije sam inačice svakako i sam gradio):
Uzmite dobar model za razgovor
Dodajte nekoliko alata (pretraživanje, upite bazi podataka, možda izvršavanje koda)
Dodajte RAG
Dodajte sistemski upit „you are an autonomous agent”
Sve omotajte while-petljom dok se ne zaustavi ili ne istekne vrijeme
Čestitamo, imate objekt nalik agentu. No on obično griješi na predvidljive načine:
Napušen kontekst: svako se opažanje dodaje, pa upiti postaju arheološki slojevi.
Nasumično posezanje za alatima: „pogrešan alat, ali s punim samopouzdanjem” postaje zadani način neuspjeha.
Nema uvjeta zaustavljanja: nastavlja jer može, a ne zato što bi trebao.
Nema discipline utemeljenja: ne primjećuje da griješi ako ga na to ne prisilite.
Memorija = povijest razgovora: što je zapravo pisanje zapisnika koje se naziva učenjem.
Zato „agenti” često djeluju čarobno u demonstracijama, a neuredno u produkciji. To potvrđuje i naše iskustvo uvođenja agentskih sustava u produkciju: kada više ne evaluirate model, nego sustav, načini neuspjeha obuhvaćaju navigaciju, pravilnu uporabu alata, sažimanje konteksta i dizajn evaluacije, a ne samo pitanje „je li model točno odgovorio”.
Stoga pitanje glasi: kako izgleda namjenski agent?
Da ovo bude manje apstraktno, slijedi jednostavan tijek rada koji većina 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 dohvaća hrpu dokumenata o pravilima zračnih prijevoznika / putovanja (čak i ako još nisu potrebni).
Poziva alat za pretraživanje, umeće dugačak popis rezultata u upit i „odabire jedan”.
Prerano obavlja rezervaciju bez provjere ograničenja (vrijeme dolaska / prtljaga / sjedalo / pravila).
Ako ne uspije, pokušava ponovno na malo drukčiji način, ali bez jasnog poimanja toga što se promijenilo ili što je naučio.
Problem nije u tome što model ne može rasuđivati, nego u tome što sustav ne upravlja tijekom rada.
Agentskija inačica zadatak tretira kao interaktivan proces s eksplicitnim stanjem i provjerama:
PLANIRAJ: ponovi ograničenja i navedi podatke koji nedostaju (npr. „koju zračnu luku preferirate?” / „odgovara li vam jedno presjedanje?”).
DJELUJ: pozovi pretraživanje letova strukturiranim upitom (raspon datuma, ograničenje dolaska, proračun).
PROMATRAJ: spremi rezultate u sažet objekt stanja (pet najboljih opcija s cijenom, vremenom dolaska i presjedanjima), a ne u golem zalijepljeni blok teksta.
AŽURIRAJ: doradi upit ako ograničenja nisu zadovoljena (npr. „dolazak prije 18 sati previše je strog — želite li proširiti vremenski raspon ili povećati proračun?”).
PROVJERI: pokreni validatore („dolazak < 18:00”, „cijena ≤ 900 £”, „usklađeno s pravilima”, „dostupan odabir sjedala”).
ZAUSTAVI: tek kada API za rezervacije vrati potvrdu i svi validatori prođu.
Promjena je suptilna, ali presudna. Dohvaćanje je uvjetno (nije refleks), kontekstom se upravlja (stanje je strukturirano, a ne nagomilano), a provjera je dio petlje (nije prepuštena korisniku). Zamijenite „rezervaciju leta” „izradom narudžbenice”, „izdavanjem povrata”, „promjenom produkcijske konfiguracije” ili „isporukom PR-a” i priča je ista: kada agent može djelovati, petlja je važnija od upita.
Prethodno spomenuti pregled dijeli agentsko rasuđivanje na tri razine: temeljnu (planiranje / uporaba alata / pretraživanje), samorazvijajuću (povratne informacije i memorija) i kolektivnu (koordinacija više agenata).
No dublja je ideja da rasuđivanje postaje temeljno načelo organizacije planiranja, odlučivanja i provjere, a ne samo generiranja uvjerljivog lanca razmišljanja. To zvuči apstraktno dok ne preslikate promjene na svoju arhitekturu. Treba zapamtiti tri ključne točke:
Dobar agent ne bi trebao dohvaćanje shvaćati kao nešto što se „uvijek radi”. Dohvaćanje je odluka, a ne refleks.
Evo praktičnog pravila:
Ako vaš sustav dohvaća podatke u svakom koraku, niste izgradili dohvaćanje, nego porez na kontekst.
To se neprestano pojavljuje u stvarnom radu. Pri otklanjanju produkcijskog incidenta ne ubacujete sve zapisnike u kontekst, nego na temelju trenutačne 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 da: sastavite upit, dohvatite, pregledajte i izdvojite
Ako su dokazi proturječni: dohvatite ponovno
Tek zatim izvedite zaključak
Tu se „agentski RAG” počinje razlikovati od tradicionalnog RAG-a: dohvaćanje postaje namjeran korak rasuđivanja, a ne zadana faza procesnog lanca.
Čim prestanete evaluirati „model” i počnete evaluirati „sustav”, praćenje stanja i bilježenje tijeka postaju važni.
Industrija je dosad jasnije definirala potrebu za opažljivošću tijekova rada agenata. Primjerice, OpenAI Agents SDK dolazi s ugrađenim praćenjem i nadzornom pločom Traces koja bilježi izvršavanja agenata (generiranja, pozive alata, prijenose, zaštitne mehanizme i prilagođene događaje) kako biste mogli korak po korak otkloniti pogreške i provjeriti što se dogodilo.
To nije tek „poželjna značajka”. To je razlika između sustava u kojem možete otklanjati pogreške i sustava koji možete procijeniti samo po osjećaju.
Po mojem mišljenju, najprimjenjiviji je dio pregleda njegova izravnost u pogledu povratnih informacija. Povratne informacije dijeli na tri režima: refleksivne povratne informacije (generiraj → kritički procijeni → doradi), parametarsku prilagodbu (učenje finim podešavanjem / RL-om) i povratne informacije vođene validatorom (ponavljaj dok provjera validatora ne uspije).
Većina timova trebala bi početi s povratnim informacijama vođenima validatorom jer je taj pristup dosadan, ali učinkovit. Ako možete napisati bilo kakav validator koji provodi jedinične testove, provjerava shemu, primjenjuje poslovna pravila / ograničenja („nema povrata iznad X bez eskalacije”) ili utvrđuje činjeničnu točnost („izvori su obvezni”), nedeterministički izlaz modela možete pretvoriti u nešto čemu doista možete vjerovati.
Jedna je od promjena povezanih s „nepoznatim nepoznanicama” jednostavna: u svijetu agenata pouzdanost često više proizlazi iz petlje nego iz modela.
Ovo je najjednostavniji disciplinirani pristup petlji koji, prema mojem iskustvu, pouzdano poboljšava ponašanje bez treniranja:
Radite u koracima: planiraj → djeluj → promatraj → ažuriraj,
nakon svake radnje sažmite opažanje u jednoj do tri natuknice,
zaustavite se kada su ispunjeni kriteriji uspjeha ili dosegnut proračun; vratite najbolji poznati rezultat i preostale neizvjesnosti.
Cilj nije učiniti model opširnim. Cilj je sustav učiniti razumljivim i u svakom koraku prisiliti ga na „dodir sa stvarnošću”. Inženjerima je posebno blizak primjer utemeljenje zatvorene petlje nalik CI-ju:
Planiraj: predloži popis izmjena
Djeluj: pokreni testove / lintanje
Promatraj: raščlani neuspjehe
Ažuriraj: zakrpaj i pokušaj ponovno
Nekoliko pitanja koja često razotkrivaju slučajno nastale dizajne agenata:
„Odabire li moj agent što treba dohvatiti ili uvijek sve dohvaćam?”
Ako je dohvaćanje bezuvjetno, cijenu ćete platiti većom latencijom i troškovima, razvodnjenim kontekstom te višim rizikom od načela „smeće unutra, smeće van”.
„Može li moj agent primijetiti da griješi?”
Ako je jedini povratni signal 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 u memoriju zapisivati i poboljšava li se ona s vremenom?”
Ako je vaša „memorija” samo nadopunjavanje povijesti razgovora, zapravo pišete zapisnike. Način na koji pregled opisuje memoriju važan je: ona postaje kontekst koji dinamički raste i koji agenti s vremenom usavršavaju, a ne tek transkript.
Zapisnici vam govore što se dogodilo, a memorija što sljedeći put trebate učiniti. Povijest razgovora jest transkript. Memorija je evoluirajuća politika o tome što vrijedi sačuvati za budućnost.
Za početak je praktična mala tablica „naučenih lekcija” u kojoj ključ čine vrsta zadatka, alat i način neuspjeha, a vrijednost ono što je uspjelo i š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 sustave koji s vremenom postaju bolji.
Primamljivo je problemu dodavati agente, no time se često umnožavaju troškovi koordinacije. Dobar obrazac „minimalno održivog tima”:
Koordinator: raščlanjuje i dodjeljuje
Izvršitelj: poziva alate / provodi izmjene
Kritičar/evaluator: provjerava ispravnost/rizik
Čuvar memorije: zapisuje/uređuje naučene lekcije
Ako ne možete objasniti za što je svaki agent odgovoran, vjerojatno vam više agenata još nije potrebno.
Ako doista prihvatimo promjenu paradigme, vjerojatno ćemo prestati trpati sve u upite, tretirati neuspjehe kao konačne rezultate i evaluirati agente kao chatbotove. Umjesto toga agente ćemo početi tretirati onakvima kakvi jesu: kao softverske sustave u kojima je jezik upravljačka ravnina, a pouzdanost proizlazi iz petlje.
Prije nego što dodate još jedan model, dodajte još jednu evaluacijsku petlju. Prije nego što dohvatite sve, uvedite uvjete za dohvaćanje. Isporučite jedan validator prije nego što ih 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, nego obrasci koji su se dokazali u produkciji.