Introduction Uvod U početku, samo pokušajte da komunicirate sa ChatGPT preko API-ja, bacite u nekoliko redova konteksta, i osjetite se iznenađeni da uopšte odgovara. Tako se rodio agent. Ako ste također proveli proteklu godinu skupljajući agente iz skriptova i omotača, eksperimentirajući i tinkering, a vi ste još uvijek u potrazi za čistijim, održivijim načinom da ih izgradite - ovaj članak je za vas. Razmislite o tome kao o praktičnom prevarnom listu - skupu inženjerskih principa koji pomažu voditi agenta od peska do proizvodnje: od jednostavnog API-ja do stabilnog, kontrolisanog i skaliranog sistema. Disclaimer U (Izgradnja efikasnih agenata), Anthropic definira agenta kao sistem u kojem LLM-ovi dinamički usmjeravaju svoje procese i upotrebu alata, održavajući kontrolu nad načinom na koji obavljaju zadatke. Sistemi u kojima su LLM-ovi i alati orkestrirani putem unapred definisanih putova koda koje zovu tokovi posla. Oba su deo šireg koncepta - Agent Systems. Ovaj članak U ovom tekstu, Agent = Agent sistem, gde zbog stabilnosti i kontrole ja ću češće nasloniti na tokove rada. Nadam se da će u bliskoj budućnosti biti 1-2 više okreta evolucije i pravi Agenti će biti svuda, ali za sada to nije slučaj 1. Design the Foundation 1. dizajnirati fondaciju Rane verzije agenata obično dolaze brzo: nekoliko funkcija, nekoliko upozorenja - i hej, to radi. Rane verzije agenata obično dolaze brzo: nekoliko funkcija, nekoliko upozorenja - i hej, to radi. “If it works, why make it complicated?” U početku, sve stabilan. Agent reaguje, izvršava kod, ponaša se razumno. Ali kada prebacite model, restartujete sistem ili uključite novi sučelje – odjednom postaje nestabilan, nepredvidljiv, teško debugirati. Izgleda I često, korijen uzroka nije u logici ili pozivima, već mnogo ranije: slomljeno upravljanje memorijom, hardcoded osoblje, nema načina da se nastavi sesije, ili jedna rigidna ulazna tačka. Ovaj odeljak prolazi kroz četiri ključna načela koja će vam pomoći da izgradite čvrst temelj - jedan koji sve drugo može sigurno rasti na vrhu. 1. Keep State Outside Problem: Ako se agent prekine (crash, timeout, bilo šta), trebao bi biti u mogućnosti da pokupi tačno gde je prestao. Potreban vam je način da precizno reproducirate ono što se dogodilo - za testiranje, debugiranje i druga takva zadovoljstva. Ovo nije strogo problem, ali ipak: Paralelizacija. Pre ili kasnije ćete želeti da paralelizujete logiku agenta. Možda je potrebno usporediti više opcija usred dijaloga (“Koji od ovih je bolji?”). (Memorija je čitava zasebna tema - doći ćemo do toga uskoro) Premještanje države agent - u bazu podataka, cache, sloj skladištenja - čak i JSON datoteka će učiniti. Solution: outside Checklist: Agent se može pokrenuti iz bilo kojeg koraka, imajući samo session_id – identifikator sesije – i vanjsko stanje (na primer, sačuvani koraci u bazi podataka ili JSON datoteci). Test slučaj: prekinut agent ne gubi kontekst, nakon ponovnog pokretanja rezultat je isti Stanje je serializabilno u bilo kojem trenutku bez gubitka funkcionalnosti Možete hraniti stanje u više istorija paralelno usred dijaloga 2. Make Knowledge External : LLM-ovi se ne sećaju. Čak i unutar jedne sesije, model može zaboraviti ono što ste već objasnili, pomiješati faze, izgubiti nit razgovora ili početi da "popunjavaju" detalje koji nisu bili tamo. I čini se da vrijeme prolazi, okno konteksta raste sve veće i veće, oduševljava nas novim mogućnostima. LinkedIn je pun postova u kojima ljudi uspoređuju koju knjigu ili koliko sati YouTube videa sada uklapa u novu verziju modela. Problem Posebno ako: Dugačak dijalog Dokumenti su veliki Upute su složene i tokeni još nisu beskonačni Čak i uz povećanje okvira za kontekst (8k, 16k, 128k...), problemi ostaju: "Izgubljen u sredini" - model posvećuje više pažnje početku i kraju (i može osloboditi detalje iz sredine) Troškovi - više žetona = više novca; I još uvijek se ne uklapa. što znači da će biti gubitka, iskrivljenosti ili halucinacija. Dokle god transformatori rade na samopouzdanju sa kvadratnom složenosti (O(n2)), ovo ograničenje će biti s nama. Odvojite „radnu memoriju“ od „skladištenja“ – kao u klasičnim računalnim sistemima. Agenat bi trebao moći da radi sa spoljnom memorijom: skladišti, preuzmi, sažeti i ažurira znanje izvan modela. Solution: Approaches Memory Buffer Prodavnice Najnoviji Pokušajte da napravite brzi prototip. k jednostavan, brz, dovoljan za kratke zadatke + gubi važne informacije, ne skala, ne pamti "juče" - Summarization Memory Komprimirajte istoriju da bi se više uklopilo. štednja tokena, proširenje memorije + deformacije, gubitak nijanse, greške u višestupanjskom kompresije - RAG (Retrieval-Augmented Generation) Povlači znanje iz spoljnih baza podataka. Većinu vremena ćete biti ovde. Široko rasprostranjena, svježa, proverljiva + složeno podešavanje, osjetljivo na kvalitetu preuzimanja, latentnost - Knowledge Graphs Uvek elegantno, seksi i teško, na kraju ćete raditi RAG u svakom slučaju. logika, objašnjivost, stabilnost + visoka barijera za ulazak, složenost LLM integracije - Checklist: Sva povijest razgovora je dostupna na jednom mestu (izvan prompt) Izvor znanja se beleži i može se ponovno upotrijebiti Skale istorije bez rizika od prekoračenja okvira konteksta 3. Model as a Config LLMs are rapidly evolving; Google, Anthropic, OpenAI, etc. constantly release updates, racing against each other across different benchmarks. This is a feast for us as engineers, and we want to make the most of it. Our agent should be able to easily switch to a better (or conversely, cheaper) model seamlessly. Problem: Solution: Implementirati model_id konfiguraciju: Koristite model_id parametar u konfiguracionim datotekama ili promjenama okruženja da biste odredili model koji se koristi. Korišćenje abstraktnih interfejsa: Kreirajte interfejse ili klase za zavijanje koje interagiraju sa modelima putem jedinstvenog API-ja. Primijenite rješenja srednjeg softvera (oprezno - razgovaraćemo o okvirima malo kasnije) Checklist: Zamjena modela ne utječe na ostatak koda i ne utječe na funkcionalnost agenta, orkestraciju, memoriju ili alate Dodavanje novog modela zahtijeva samo konfiguraciju i, opcionalno, adapter (jednostavan sloj koji donosi novi model na potreban sučelje) Jednostavno i brzo možete prebaciti modele. Idealno – svi modeli, barem – prebacujući se unutar porodice modela 4. One Agent, Many Interfaces: Be Where the Users Are Čak i ako je u početku agent namijenjen da ima samo jedan komunikacioni interfejs (na primer, korisnički interfejs), na kraju ćete želeti dati korisnicima više fleksibilnosti i pogodnosti dodavanjem interakcije kroz Slack, WhatsApp, ili, usuđujem se reći, SMS - bilo šta. API može se pretvoriti u CLI (ili ćete želeti jedan za debugging). Izgradite ovo u svoj dizajn od početka; omogući da koristite svog agenta gde god je prikladno. Problem: Razvijte API ili drugi mehanizam koji će poslužiti kao univerzalni sučelje za sve kanale. Solution: Creating a unified input contract Checklist: Agent is callable from CLI, API, UI All input goes through a single endpoint/parser/schema All interfaces use the same input format No channel contains business logic Adding a new channel = only an adapter, no changes to core Definicija ponašanja agenta Iako postoji samo jedan zadatak, sve je jednostavno, kao u postovima AI evangelista.Ali čim dodate alate, logiku donošenja odluka i više faza, agent se pretvara u nered. Iako postoji samo jedan zadatak, sve je jednostavno, kao u postovima AI evangelista.Ali čim dodate alate, logiku donošenja odluka i više faza, agent se pretvara u nered. Ona gubi trag, ne zna šta da radi s greškama, zaboravlja da pozove pravu alatku - a vi ste opet ostavljeni sami sa dnevnicima u kojima "dobro, sve izgleda da je napisano tamo." Kako bi se to izbjegao, agentu je potreban jasan što radi, koje alate ima, ko donosi odluke, kako ljudi intervenišu i šta da rade kada nešto pođe po zlu. behavioral model Ovaj odeljak obuhvaća principe koji će vam pomoći da vašem agentu date koherentnu strategiju akcije umjesto nada da će "model to na neki način shvatiti". 5. Design for Tool Use Ova točka može izgledati očigledno, ali i dalje naići agenti izgrađeni na "Plain Prompting + sirovi LLM ishod analiziranje." To je kao da pokušavaju kontrolisati složen mehanizam povlačenjem slučajnih niza i nadajući se najboljem. Problem: Brittleness: Najmanja promjena u formulaciji LLM odgovora (jedna reč dodana, redoslijed fraze promijenjen) može prekinuti čitavo analiziranje. Ambiguitet: Prirodni jezik je inherentno dvosmislen. Ono što čoveku izgleda očigledno može biti zagonetka za istraživača. „Zovite Johna Smitha“ – koji je od tri Johna Smitha u vašoj bazi podataka? Kompleksnost održavanja: Parsing kod raste, postaje zbunjen i teško debugirati.Svaki novi agent "sposobnost" zahtijeva pisanje novih pravila parsing. Ograničene mogućnosti: Teško je da model pouzdano pozove više alata ili prenese složene podatkovne strukture kroz jednostavan izlaz teksta. Model vraća JSON (ili drugi strukturirani format) – sistem izvršava. Solution: Ključna ideja ovde je ostaviti odgovornost za Korisnik namjera i alata za LLM, dok još dodjeljuju Od te namere do preko jasno definisanog interfejsa. Interpretacija Izbornik Izvršenje Sistem Srećom, gotovo svi pružatelji (OpenAI, Google, Anthropic, ili tko god drugi želite) podržavaju tzv. ili mogućnost generisanja izlaza u strogo definisanom JSON formatu. "function calling" Samo da osvežite kako to funkcioniše: Opis alata: Definišete funkcije (alate) kao JSON shemu sa imenom, opisom, parametrima. Opis je kritično važan – model se oslanja na njega. Prelazak na LLM: Na svakom pozivu, model prima sheme alata zajedno sa pozivom. Instead of text, the model returns JSON with: Model output: name of the function to call arguments—parameters according to schema Izvršenje: Kod potvrđuje JSON i poziva odgovarajuću funkciju sa parametrima. Model odgovor (opcionalno): Rezultat izvršenja se vraća na LLM za konačnu generaciju odgovora. Opisi alata su takođe pozivnice. nejasno opis = pogrešan izbor funkcije. Important: What to do without function calling? Ako model ne podržava pozive na alate ili ih želite izbjeći iz nekog razloga: Zatražite od modela da vrati JSON u uputstvu. Budite sigurni da odredite format; možete dodati primere. Analizirajte odgovor i potvrdite ga s nečim poput Pydantica. Postoje pravi fanovi ovog pristupa. Checklist: Odgovor je strogo formalizovan (npr. JSON) Sheme se koriste (JSON shema ili Pydantic) Validation is applied before function calls Greške generacije ne uzrokuju prekid (obrada grešaka formata postoji) LLM = izbor funkcije, izvršenje = kod 6. Own the Control Flow Obično agenti rade kao "dialogovi" - prvo korisnik govori, a zatim agent reaguje. To je kao da se igra ping-pong: hit-odgovor. Problem: Such an agent cannot: Učinite nešto sami bez zahteva Izvršavanje aktivnosti paralelno Plan steps in advance Napravite nekoliko koraka u redoslijedu Provjerite napredak i vratite se neuspjelim koracima Umjesto toga, agent bi trebao upravljati svojim vlastitim "protokom izvršenja" - odlučiti šta da uradi sledeće i kako to učiniti. This means the agent: Odlučuje kada da nešto uradi sam can take steps one after another can retry failed steps can switch between tasks može raditi čak i bez direktnih zahtjeva Umesto da dozvolimo LLM da kontroliše svu logiku, mi izvučemo u kod. Model samo pomaže unutar koraka ili predlaže sledeći. Ovo je pomak od "pisanja uputstava" na U kontrolisanom ponašanju. Solution: control flow engineering a system Pogledajmo tri popularna pristupa: 1. FSM (Finite State Machines) Šta je to: Zadatak podijeljen na države i jasne tranzicije. LLM: Određuje sledeći korak ili djeluje unutar države. Prednosti: Jednostavnost, predvidljivost, dobro za linearne scenarije. StateFlow, YAML configurations, State Pattern. Tools: 2. DAG (Directed Graphs) Ne-linearni ili paralelni zadaci kao grafikon: čvorovi su akcije, rubovi su zavisnosti. LLM: Može biti čvor ili pomoć u izgradnji plana. Flexibility, parallelism, visualizable. Pros: Alat: LangGraph, Trellis, LLMCompiler, prilagođeni DAG dijagramovi. 3. Planner + Executor Šta je to: LLM gradi plan, kod ili drugi agenti ga sprovode. LLM: "Veliki" jedan plan, "mali" oni izvršiti. Prednosti: odvajanje briga, kontrola troškova, skalabilnost. Tools: LangChain Plan-and-Execute alat za planiranje i izvršenje. Why this matters: Increases , , . controllability reliability scalability Omogućuje kombiniranje različitih modela i ubrzanje izvršenja. Tok zadataka postaje vidljiv i testiran. Checklist: Koristi FSM, DAG ili scenarij s eksplicitnim tranzicijama Model odlučuje šta da radi, ali ne kontroliše protok Ponašanje se može vizualizirati i testirati Upravljanje greškama je ugrađeno u tok 7. Include the Human in the Loop Čak i ako agent koristi strukturirane alate i ima jasan protok kontrole, potpuna autonomija LLM agenata u stvarnom svetu je još uvek više san (ili noćna mora, ovisno o kontekstu). LLM-ovi nemaju pravo razumijevanje i nisu odgovorni za ništa. Problem: Main risks of full autonomy: Trajne greške: Agent može izvršiti radnje sa ozbiljnim posljedicama (brisanje podataka, slanje pogrešne poruke važnom klijentu, pokretanje robotskog ustanka). Povrede usklađenosti: Agent može slučajno prekršiti unutrašnje propise, zakonske zahteve ili povrijediti osjećaje korisnika (ako to nije bio plan, ignorišite ovu točku). Nedostatak zdravog razuma i etike: LLM-ovi mogu propustiti društvene nijanse ili delovati protiv "zajedničkog razuma". Gubitak poverenja korisnika: Ako agent učestvuje u greškama, korisnici će prestati da mu veruju. Revizija i složenost odgovornosti: Tko je kriv kada autonomni agent "prevrne"? Integracija ljudi u proces donošenja odluka u ključnim fazama. Solution: Strateški poziv na životne oblike zasnovane na ugljeniku HITL Implementation Options 1. Approval Flow Kada: akcija je kritična, skupo, nepovratno Kako: agent formulira predlog i čeka potvrdu 2. Confidence-aware Routing Kada: model je neizvesan How: self-assessment (logits, LLM-as-a-judge, P(IK)) escalation when confidence falls below threshold 3. Human-as-a-Tool Kada: nedovoljni podaci ili nejasna formulacija zahteva Kako: agent traži pojašnjenje (npr. HumanTool u CrewAI) 4. Fallback Escalation Kada: ponovljena greška ili nerešiva situacija Kako: zadatak se prenosi na operatora sa kontekstom 5. RLHF (Human Feedback) for model improvement When: Kako: čovek procjenjuje odgovore, odlaze u obuku Checklist: Akcije koje zahtijevaju odobrenje su definirane Postoji mehanizam za procjenu poverenja Agent može postavljati ljudska pitanja Kritike zahtijevaju potvrdu Postoji interfejs za unose odgovora 8. Compact Errors into Context Standardno ponašanje mnogih sistema kada se dogodi greška je ili da se "crash" ili jednostavno prijaviti grešku i zaustaviti. Za agenta koji bi trebao samostalno riješiti zadatke, ovo nije baš najbolji model ponašanja. Problem: Što ćemo se suočiti: Krhkost: Svaki neuspeh u vanjskom alatu ili neočekivan odgovor LLM može zaustaviti čitav proces ili ga dovesti u zabludu. Neefikasnost: Stalno ponavljanje i ručna intervencija troše vrijeme i resurse. Nemogućnost učenja (u širokom smislu): Ako agent ne "vidi" svoje greške u kontekstu, ne može pokušati da ih popravi ili prilagodi svoje ponašanje. Halucinacije i opet. Greške su uključene u upit ili memoriju. Ideja je da se pokuša implementirati neku vrstu "samo-lečenja". Solution: Teški tokovi: Razumevanje greške Self-correction: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool) Self-correction mechanisms: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance. Impact of reflection type: Training LLMs for self-correction by introducing errors and their fixes into training data. Internal Self-Correction: Zatražite ljudsku pomoć: Ako samoregulacija ne uspe, agens eskalira problem na čoveka (vidjeti Princip 7). Checklist: Greška prethodnog koraka je sačuvana u kontekstu Retry logika postoji Fallback / ljudska eskalacija se koristi za ponavljane neuspehe 9. Break Complexity into Agents Vratimo se ključnom ograničenju LLM-a (ona stvar kontekstnog prozora), ali pogledajte ovaj problem iz drugog ugla. Što je zadatak veći i složeniji, to će biti potrebno više koraka, što znači duži kontekstni prozor. Kako kontekst raste, LLM-ovi imaju veću šansu da se izgube ili izgube fokus. Koncentrirajući agente na određene domene sa 3-10, možda maksimalno 20 koraka, održavamo upravljive kontekstne prozore i visoke performanse LLM-a. Problem: Koristite manje agente usmjerene na određene zadatke. jedan agent = jedan zadatak; orkestracija odozgo. Solution: Prednosti malih, fokusiranih agenata: Upravljat kontekst: Manji kontekst prozori znače bolju izvedbu LLM Jasne odgovornosti: Svaki agent ima dobro definisan opseg i svrhu Bolja pouzdanost: Manje šanse da se izgubi u složenim tokovima posla Jednostavnije testiranje: lakše testiranje i potvrđivanje specifičnih funkcionalnosti Poboljšano rješavanje problema: lakše je identificirati i popraviti probleme kada se pojave Nažalost, ne postoji jasna heuristika za razumevanje kada je komad logike već dovoljno velik da se podijeli na više agenata. Ja sam prilično siguran da dok čitate ovaj tekst, LLM-ovi su postali pametniji negde u laboratorijama. I oni nastavljaju da postaju bolji i bolji, tako da je svaki pokušaj da se formalizuje ova granica osuđen od početka. Da, što je manji zadatak, to je jednostavnije, ali što je veći, to je bolji potencijal realizovan. Prava intuicija će doći samo sa iskustvom. Checklist: Scenario is built from microservice calls Agents can be restarted and tested separately Agent = minimal autonomous logic. You can explain what it does in 1-2 sentences. Kontrolni model interakcije The model handles generation. Everything else is on you. Model se bavi generacijom.Sve ostalo je na vama. Kako ste formulirali zahtjev, šta ste proslijedili u kontekstu, koje upute ste dali – sve to određuje hoće li rezultat biti koherentan ili „kreativan“. LLM-ovi ne čitaju umove, čitaju žetone. To znači da se svaka ulazna greška pretvara u izlazni bug – jednostavno nije odmah primjetna. Ovaj odeljak je o tome da se ne dopusti da sve drhti: prompts = kod, eksplicitno upravljanje kontekstom, ograničavanje modela unutar granica. 10. Treat Prompts as Code Vrlo uobičajen uzorak, posebno među ljudima bez ML ili SE pozadine, je skladištenje uputa direktno u kod ili, u najboljem slučaju, nesistematično skladištenje u vanjskim datotekama. Problem: Ovaj pristup dovodi do nekoliko poteškoća u održavanju i skaliranju: Navigacija, razumijevanje i modifikacija postaju komplicirani kako kompleksnost projekta i broj uputa rastu. Bez eksplicitnog izdavanja verzija, vrlo je teško pratiti trenutnu evoluciju, razloge za promene i vratiti se na prethodne stabilne verzije u slučaju pogoršanja performansi. Neefikasan proces poboljšanja i debugiranja: Brza optimizacija bez objektivnih metrika i testiranja postaje subjektivan i naporan proces s nestabilnim rezultatima. Percepcija drugih članova tima postaje komplicirana, uključujući (a posebno) buduće vas. Prompte u ovom kontekstu nisu mnogo različiti od koda i iste osnovne inženjerske prakse treba primijeniti na njih Solution: This implies: Store separately and systematically, using specialized files (like , , , ) or even template management systems (e.g., Jinja2, Handlebars, or specialized tools like BAML). .txt .md .yaml .json Eksplicitno upućivanje na verziju. Možete čak napraviti A / B testove s različitim verzijama nakon toga. Testing. You heard that right. This could be something like unit tests, where you compare LLM responses to specific inputs against reference answers or expected characteristics depending on the prompt Evaluation datasets Format compliance checks and presence/absence of key elements - For example, if a prompt should return JSON, the test can validate its structure Even LLM-as-a-judge if your project and design justify it. O testiranju ćemo govoriti detaljnije u principu 14. Checklist: Prompti se čuvaju u odvojenim datotekama, odvojeno od poslovne logike Postoji diff i promjena istorije Testovi se koriste (po potrebi) (Opcionalno) Šta je sa prompt revizijom kao dijelom revizije koda? Kontekst inženjering 11. Već smo razgovarali o "zapostavljenosti" LLM-ova, delimično rešavajući to odlaganjem istorije u vanjsku memoriju i korišćenjem različitih agenata za različite zadatke. ali to nije sve. predlažem da razmotrimo i eksplicitno upravljanje kontekstnim prozorom (i ovdje ne govorim samo o komprimiranju istorije kako bi se uklopila u optimalnu veličinu ili uključivanju grešaka iz prethodnih koraka u kontekst). Problem: A simple list of messages in the "role-content" ( ) format je osnovna linija, ali može biti teška, ne dovoljno informativna ili slaba u prenosu složenog stanja vašeg agenta. Standard formats aren't always optimal: system/user/assistant Većina LLM klijenata koristi standardni format poruke (seznam objekata sa : "system", "user", "assistant", i ponekad u poljima) role content tool_calls Iako ovo "djeluje odlično za većinu slučajeva", da bi se postiglo (u smislu i žetona i pažnje modela), možemo pristupiti oblikovanju konteksta kreativnije. maximum efficiency Da se tretira stvaranje čitavog informativnog paketa prenesenog na LLM kao To znači: Solution: "Context Engineering." Potpuna kontrola: Uzimanje punog vlasništva za koje informacije ulaze u kontekst LLM-a, u kojem obliku, volumenu i redoslijedu. Kreiranje prilagođenih formata: Ne ograničavajući se na standardne liste poruka. Razvijanje vlastitih, zadatcima optimizovanih načina predstavljanja konteksta. Na primjer, možete razmotriti upotrebu XML-like strukture za glatko pakiranje različitih vrsta informacija (poruke, pozive na alate, njihovi rezultati, greške itd.) u jednu ili više poruka. Holistički pristup: Gledanje na kontekst ne samo kao istoriju dijaloga, već kao ukupnu sumu svega što bi moglo biti potrebno modelu: neposredni poziv, upute, podaci iz RAG sistema, povijest poziva alata, stanje agenta, memorija iz drugih interakcija, pa čak i upute o željenom formatu izlaza. (Instead of a checklist) How do you know when this makes sense? Ako ste zainteresovani za bilo koji od sledećih: Maksimalno značenje sa minimalnim buke. Troškovna efikasnost: Smanjenje broja žetona u kojima možemo dobiti usporedivu kvalitetu po nižoj cijeni. Poboljšano pogrešno rukovanje. Bezbednost. rješavanje uključivanja osetljivih informacija, kontrolisanje, filtriranje, i završiti sve tako što će izaći iz klasičnog "izvinite, ja sam samo mali mali veliki model jezika" odgovor. 12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs Već smo učinili mnogo u ime stabilnosti, ali ništa nije srebrna metka.To znači da je vrijedno gledati na najkritičnije potencijalne probleme odvojeno i eksplicitno uzeti neko "osiguranje". Problem: Na ovom principu razmišljamo o: Moguće Prompt Injection. Ako vaš agent će komunicirati direktno sa korisnikom, morate kontrolisati što se hrani kao unos. Ovisno o vrsti korisnika, možete dobiti onaj koji želi da prekine vaš tok i prisili agenta da ignoriše svoje početne ciljeve, pruži pogrešne informacije, izvrši štetne akcije ili generira zlonamjerni sadržaj. Iz gore navedenog razloga, ili pod vodstvom "glasova u glavi", agent može otkriti važne informacije, kao što su lični podaci korisnika, korporativne tajne, itd. Generiranje toksičnog ili zlonamernog sadržaja. Ako je to po dizajnu, ignorišite ovu tačku. Stvaranje stvari kada je informacija odsutna – večna bol. No, ozbiljno, u svom procesu razmatranja, agent može doći do vrlo ne-trivialnih rešenja, koja neće svi biti unutar okvira normalnog ponašanja. Sigurnost i osnivanje LLM agenta nije jedna mera, već višeslojni sistem zaštite ("odbrana-u dubini") koji pokriva čitav životni ciklus interakcije. Pretnje su raznolike, a nijedna metoda zaštite nije panaceja. Moramo se obvezati na višeslojni obrambeni sistem, razmišljati i eksplicitno rješavati sve slučajeve i potencijalne scenarije, i imati jasan odgovor spreman za sve što bi se moglo dogoditi. Solution: U osnovnoj konfiguraciji, treba uzeti u obzir: Secure Inputs. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one. Control input from external sources, even if they are your own tools. Control the privileges of both the agent and its tools (granting the minimum necessary), clearly define and limit the list of available tools, validate parameters at the input to tools, and enable Principle #7 (Human in the Loop). Guarded Actions. Design a system of checks for what the model outputs, especially if it goes directly to the user. These can be checks for relevance (ensuring the model uses what's in the RAG and doesn't just make things up) as well as checks for general appropriateness. There are also ready-made solutions (e.g., the OpenAI Moderation API). Output Moderation. Konačni sistem, međutim, zavisi od vaših zadataka i procjene rizika. Checklist: User input validation is in place. For tasks requiring factual information, the data within the RAG is used. The prompt for the LLM in a RAG system explicitly instructs the model to base its answer on the retrieved context. LLM output filtering is implemented to prevent PII (Personally Identifiable Information) leakage. The response includes a link or reference to the source. LLM output moderation for undesirable content is implemented. The agent and its tools operate following the principle of least privilege. The agent's actions are monitored, with HITL (Human-in-the-Loop) for critical operations. IV. Keep It Alive Agent koji "kinda radi" je bug sa odgođenim učinkom. Agent koji "kinda radi" je bug sa odgođenim učinkom. U prod, ne razbija sve odjednom. i ne saznaš o tome odmah. ponekad, ne saznaš uopće. Ovaj odjeljak govori o inženjerskom naviku i Logovi, praćenje, testovi – sve što čini ponašanje agenta transparentnim i pouzdanim, čak i kada spavate ili razvijate svog sledećeg agenta. seeing what's happening checking that everything is still working 13. Trace Everything Na ovaj ili onaj način, vi ćete se stalno suočavati sa situacijama u kojima agent ne radi kako ste očekivali. Tokom razvoja, testiranja, izmjena ili normalnog rada. To je neizbježno, a u ovom trenutku, to je normalno u određenoj mjeri. To znači da ste osuđeni da provedete satima i danima debugiranje, pokušavajući da razumete šta je pogrešno, reproducirajući problem i popravljajući ga. Želeo bih da mislim da ste do ovog trenutka već implementirali Princip #1 (Keep State Outside) i #8 (Kompaktne greške u kontekst). U većini slučajeva, to će biti dovoljno da učinite vaš život mnogo jednostavnijim. Neki drugi principi će također indirektno pomoći ovdje. Problem: Čak i tako (i pogotovo ako ste odlučili da se ne brinete s njima za sada), ima mnogo smisla razmišljati o debugiranju unaprijed i uštedjeti sebi vrijeme i živce u budućnosti pridržavajući se ovog principa. Prijavite ceo put od zahteva do akcije. Čak i ako već imate dnevnike za pojedinačne komponente, praćenje čitavog lanca može biti problem. Čak i ako ste veliki obožavatelj zagonetki ili Lego, u nekom trenutku, to će prestati biti zabavno. Stoga, dnevnici moraju postojati, moraju biti od kraja do kraja, i moraju pokrivati sve. Solution: Why it's needed: Debugging – Brzo pronaći gde su stvari otišle pogrešno. Analitičari – Pogledajte gde su prepreke i kako ih poboljšati. Procjena kvaliteta – Pogledajte kako promene utiču na ponašanje. — You can precisely reconstruct the steps. Reproducibility Revizija – dnevnik svih odluka i akcija agenata. Osnovni "gentleman set" izgleda ovako: Uvod: početni korisnički zahtev, parametri primljeni iz prethodnog koraka. Status agenta: Ključne promjenjive stanja agenta prije izvršenja koraka. Prompt: Cijeli tekst uputstva poslanog LLM-u, uključujući upute o sistemu, istoriju dijaloga, preuzeti kontekst RAG-a, opise alata itd. LLM Output: Potpuni, sirovi odgovor iz LLM-a, pre bilo kakvog analiziranja ili obrade. Poziv na alat: Ako je LLM odlučio pozvati alat – ime alata i točni parametri kojima je pozvan (prema strukturiranom izlazu). Rezultat alata: Odgovor koji je alat vratio, uključujući i uspešne rezultate i poruke o greškama. Odluka agenta: Koju odluku je agent doneo na osnovu odgovora LLM-a ili rezultata alata (npr. koji sledeći korak treba izvršiti, koji odgovor dati korisniku). Step execution time, the LLM model used, the cost of the call (if available), the code/prompt version. Metadata: Pogledajte postojeće alate za praćenje; pod određenim uslovima, oni će vam olakšati život. LangSmith, na primjer, pruža detaljnu vizualizaciju lanca poziva, pozivnica, odgovora i upotrebe alata. Također možete prilagoditi alate kao što su Arize, Weights & Biases, OpenTelemetry, itd. za vaše potrebe. Note: Checklist: Svi koraci agenta su zabeleženi (vaša verzija "gentleman set"). Korak je povezan sa session_id i step_id. Postoji interfejs za pregled celog lanca. Prompt poslan na LLM može se reproducirati u bilo kojoj fazi. 14. Test Before You Ship Do ovog trenutka, najverovatnije imate neku vrstu praktično gotovog rešenja. Djeluje, možda čak i na način na koji ste želeli. radi? Čak i nakon sledećeg manjeg ažuriranja? Da, vodim nas na temu testiranja. Problem: Nastavak Očigledno je da ažuriranja u sistemima LLM, baš kao i u bilo kojem drugom – bilo da se radi o promjenama kodova aplikacija, ažuriranjima skupova podataka za fino podešavanje ili RAG, novoj verziji osnovnog LLM-a, ili čak manjim promptnim prilagodbama – često dovode do nenamjernih prekida u postojećoj logici i neočekivanog, ponekad degradirajućeg ponašanja agenta. Možda je dobavljač ažurirao svoj model, možda se priroda ulaznih podataka promijenila (data drift) – ono što je radilo juče možda prestaje da radi danas. Čak i mala promena prompt može prekinuti uspostavljenu logiku i iskriviti ishod. Ne-determinizam LLM-ova: Kao što znate, mnogi LLM-ovi su ne-deterministički (osobito s temperaturom > 0), što znači da će generisati različite odgovore na isti unos na svakom pozivu. Bit će lakše za vas ako ste implementirali prvi princip, ali reproduciranje određene greške za debugiranje može biti teško čak i sa fiksnim podacima i stanicama. U složenim sistemima, ažuriranje jednog elementa (kao što je model ili pozivnica) može kaskadirati kroz lanac API-ja, baza podataka, alata itd., i dovesti do promene ponašanja na drugom mestu. za halucinacije. Ali već razumijemo da tradicionalni testovi, usredotočeni na provjeru eksplicitne logike koda, nisu u potpunosti sposobni pokriti ta pitanja. Morat ćemo osmisliti složen, sveobuhvatan pristup koji pokriva mnoge stvari, kombinirajući klasična i domena specifična rešenja. Solution: Multi-level testiranje: Kombinacija različitih tipova testova usmjerenih na različite aspekte sistema: od testova jedinica niskog nivoa za pojedinačne funkcije i pozivnice do složenih scenarija koji provjeravaju tok posla agenta od kraja do kraja i interakciju korisnika. Fokus na ponašanje i kvalitetu LLM: Testiranje treba da oceni ne samo funkcionalnu ispravnost, već i kvalitativne karakteristike LLM odgovora, kao što su relevantnost, tačnost, dosljednost, odsustvo štetnog ili pristranog sadržaja, i pridržavanje uputa i određenog stila. Regresijski i kvalitativni testovi koji uključuju "zlatne skupove podataka" koji sadrže različite primjere ulaza i referentne (ili prihvatljive raspone) izlaza. Automatizacija i integracija u CI/CD. Human-in-the-loop evaluacija: Specifične faze LLM-eval treba da uključe čoveka za kalibraciju metrikama i pregled složenih ili kritičnih slučajeva. Iterativni pristup prompt razvoju i testiranju: Prompt inženjering treba tretirati kao iterativni proces u kojem je svaka verzija prompt temeljito testirana i ocijenjena prije implementacije. Testing at different levels of abstraction: Individual modules (parsers, validators, API calls) and their integration. Component testing: Isolated testing of prompts on various inputs. Prompt testing: Verifying the logic and interaction of components within an agent. Chain/Agent testing: Evaluating the completion of full user tasks. End-to-end system testing: Checklist: Logic is broken down into modules: functions, prompts, APIs—everything is tested separately and in combination. Response quality is checked against benchmark data, evaluating meaning, style, and correctness. Scenarios cover typical and edge cases: from normal dialogues to failures and provocative inputs. The agent must not fail due to noise, erroneous input, or prompt injections—all of this is tested. Any updates are run through CI and monitored in prod—the agent's behavior must not change unnoticed. Principle 15: Own the Execution Path Ovo je meta princip; radi kroz sve gore navedene. Srećom, danas imamo na desetke alata i okvira za bilo koji zadatak.To je super, to je prikladno, i to je zamka. Gotovo uvek, odabir gotovog rešenja znači dobijate brzinu i lak početak, ali gubite . trade-off flexibility, control, and, potentially, security Ovo je posebno važno u razvoju agenata, gde je važno upravljati: nepredvidivost LLM-ova kompleksna logika za tranzicije i samo-korekciju, biti spreman za prilagodbu i evoluciju sistema, čak i ako njegovi osnovni zadaci ostaju nepromijenjeni. Okviri donose : oni odlučuju za vas kako bi agent trebao raditi.To može pojednostaviti prototip, ali komplicirati njegov dugoročni razvoj. inversion of control Mnogi od gore opisanih načela mogu se implementirati pomoću off-the-shelf rešenja – i to je često opravdano. i pruža neusporedivo više . explicit implementation of the core logic takes a comparable amount of time transparency, manageability, and adaptability Postoji i suprotna krajnost - , želja da se sve napiše od nule.To je također greška. over-engineering Inženjer bira za sebe: gde je razumno oslanjati se na okvir, i gde je važno održavati kontrolu. This is why the key is balance. Morate zapamtiti: industrija i dalje dobija oblik. Mnogo alata stvoreno je prije nego što su se pojavili trenutni standardi. Conclusion Zaključak U redu, prošli smo preko 15 principa koji, iskustvo pokazuje, pomažu pretvoriti početno uzbuđenje "to je živo!" u povjerenje da će vaš LLM agent raditi na stabilan, predvidljiv i koristan način pod realnim uslovima. Trebali biste razmotriti svaki od njih da biste videli ima li smisla primijeniti ga na vaš projekat. Key takeaways to carry with you: Inženjerski pristup je ključ: Ne oslanjajte se na "magiju" LLM-ova. Struktura, predvidljivost, upravljivost i testiranost su vaši najbolji prijatelji. LLM je moćna komponenta, ali ipak samo jedna komponenta: Tretirajte LLM kao vrlo pametan, ali ipak, jedinstvena komponenta vašeg sistema. Iteracija i povratne informacije su ključ uspjeha: Rijetko je stvoriti savršenog agenta na prvi pokušaj. Budite spremni za eksperimente, mjerenja, analizu grešaka i kontinuirano poboljšanje – i samog agenta i vaših razvojnih procesa. Zajednica i otvorenost: Polje LLM agenti brzo se razvija. Držite oči na nova istraživanja, alate i najbolje prakse, i podeliti svoja iskustva. Nadam se da ste pronašli nešto novo i korisno ovde, a možda ćete čak želeti da se vratite na ovo dok dizajnirate svog sledećeg agenta.
