AI agent nije prompt s pridruženom petljom. Čim softver može pozvati API, promijeniti zapis u bazi podataka, poslati poruku ili pokrenuti tijek rada za implementaciju, postaje dio operativnog sustava. Njegova korisnost manje ovisi o rječitim uputama, a više o arhitekturi koja okružuje njegove odluke.

Ta je razlika važna za backend timove. Chatbot može tolerirati povremeno nejasan odgovor. Agent koji izrađuje zahtjeve za podršku, usklađuje fakture ili mijenja podatke o korisnicima ne može. Svrhovito djelovanje zahtijeva jasne granice, trajno stanje, vidljivo ponašanje i rukovanje pogreškama koje je jednako pažljivo osmišljeno kao i interakcija s modelom.

Započnite s ograničenim zadatkom, a ne ciljem opće inteligencije

Najjači početni agenti rješavaju uski tijek rada s jasnom definicijom uspjeha. „Pomažite korisnicima” nije zahtjev spreman za implementaciju. „Klasificirajte dolazni zahtjev, dohvatite odobrene podatke o računu i izradite nacrt slučaja podrške kada je pouzdanost dovoljna” jest.

Definirajte ugovor agenta prije odabira modela ili okvira. Ugovor treba navesti što agent smije čitati, što smije mijenjati, koje alate može koristiti i kada mora prepustiti zadatak čovjeku ili drugoj determinističkoj usluzi.

• Ulazi: događaj, identitet korisnika, kontekst zakupca i dopušteni izvorni podaci.
• Izlazi: strukturirani rezultat, poput nacrta, preporuke ili naredbe stavljene u red čekanja.
• Ovlasti: točne radnje dopuštene za ovaj tijek rada.
• Uvjeti završetka: uspjeh, eskalacija, odbijanje, vremensko ograničenje ili pogreška koja se može ponovno pokušati.

Ovakvo uokvirivanje sprječava čestu pogrešku: davanje agentu širokih vjerodajnica uz nadu da će prompt osigurati suzdržanost. Promptovi su korisne smjernice, ali autorizacija pripada aplikacijskom kodu i infrastrukturi.

Odvojite zaključivanje od izvršavanja

Pouzdan agent ima namjernu granicu između odlučivanja o tome što bi se trebalo dogoditi i njegova izvršavanja. Model može predložiti radnju, ali backend usluga trebala bi je provjeriti i izvršiti.

Primjerice, agent za upravljanje narudžbama mogao bi vratiti strukturirani zahtjev umjesto da izravno pozove krajnju točku za povrat novca:

{
  "action": "request_refund",
  "order_id": "ord_4821",
  "reason": "duplicate_charge",
  "amount": 49.00,
  "currency": "USD"
}

Vaša aplikacija zatim treba provjeriti je li radnja poznata, pripada li narudžba trenutnom zakupcu, je li iznos valjan i ima li akter potrebne ovlasti. Također treba primijeniti poslovna pravila koja ne pripadaju promptu, poput rokova za povrat novca, statusa plaćanja i pragova za odobrenje.

U PHP-u to često znači tretirati izlaz modela kao nepouzdan ulaz. Raščlanite ga u DTO, provjerite ga i usmjerite kroz aplikacijsku uslugu umjesto da dopustite kodu agenta izravan pristup repozitorijima ili vanjskim klijentima.

$command = RefundRequest::fromArray($modelOutput);
$validator->validate($command);

if (!$policy->canRequestRefund($actor, $command)) {
    throw new AuthorizationException();
}

$refundService->request($command, $idempotencyKey);

Model može pomoći pri odabiru puta; deterministički kod i dalje je odgovoran za njegovo provođenje.

Dizajnirajte alate kao javne API-je

Alati su ruke agenta. Svaki zaslužuje jednaku pažnju kao API koji koristi drugi inženjerski tim. Dajte alatima uska imena, tipizirane parametre, predvidljive odgovore i eksplicitne kodove pogrešaka. Izbjegavajte nejasan alat poput run_database_query kada mogu poslužiti namjenski izrađeni find_open_invoices ili create_invoice_draft.

Uski alati poboljšavaju sigurnost i olakšavaju testiranje ponašanja agenta. Također smanjuju dvosmislenost. Veća je vjerojatnost da će model ispravno koristiti dobro opisan poslovni postupak nego fleksibilno sučelje niske razine s desecima mogućih nuspojava.

Učinite upise idempotentnima

Agenti mogu ponovno pokušati nakon mrežnih kvarova, vremenskih ograničenja pružatelja usluge ili ponovnog pokretanja procesa. Bez idempotentnosti, ponovni pokušaj može stvoriti duplicirane zahtjeve, izdati duplicirane povrate novca ili poslati ponovljene obavijesti.

Dodijelite ključ idempotentnosti na granici tijeka rada i trajno pohranite ishod svakog upisa. Ako ista naredba ponovno stigne, vratite izvorni rezultat umjesto da radnju izvršite dvaput. To nije obrazac specifičan za AI; to je uobičajena disciplina distribuiranih sustava primijenjena ondje gdje postaje osobito važna.

Stanje je dio proizvoda

Sama povijest razgovora loša je baza podataka. Skupa je, nepotpuna, teško ju je pretraživati i sklona je prenošenju zastarjelih pretpostavki. Operativno stanje pohranite u bazu podataka: status tijeka rada, pozive alata, odobrenja, identifikatore korelacije, ponovne pokušaje i konačne ishode.

Praktičan dizajn koristi trajni zapis tijeka rada uz zapis događaja koji se samo nadodaje. Zapis tijeka rada odgovara na pitanje: „Što se sada događa?” Zapis događaja odgovara na pitanje: „Kako smo došli ovamo?” Zajedno podržavaju oporavak, istrage podrške i ciljana poboljšanja.

Držite osjetljive podatke o korisnicima izvan promptova kad god je to moguće. Dohvaćajte samo polja potrebna za odluku, prema potrebi ih redigirajte i provodite izolaciju zakupaca u sloju pristupa podacima. Prompt koji kaže „pristupajte samo ovom korisniku” nije zamjena za upit ograničen identifikatorima korisnika i zakupca.

Planirajte neizvjesnost i neuspjeh

Agentu treba biti dopušteno da, sistemskim riječima, kaže: „Ne mogu sigurno nastaviti.” To je značajka, a ne slabost. Izradite eksplicitne grane za nedostajuće informacije, klasifikacije niske pouzdanosti, nedostupne ovisnosti, sukobe pravila i radnje koje zahtijevaju odobrenje.

Ponovni pokušaji trebaju biti selektivni. Ponovno pokušajte prolazne neuspjehe poput privremene API pogreške, po mogućnosti s ograničenim postupnim odgađanjem. Nemojte ponovno pokušavati neuspjehe provjere valjanosti, odbijanja autorizacije ili neispravne argumente alata bez promjene temeljnih uvjeta. Nakon ograničenja broja pokušaja, premjestite tijek rada u vidljivo stanje neuspjeha ili stanje koje zahtijeva pregled.

Za dugotrajni rad koristite red čekanja i radnik umjesto da HTTP zahtjev ostane otvoren. Docker ovo razdvajanje čini jednostavnim: pokrenite web-proces i radnik kao zasebne usluge, dajte objema istu sliku aplikacije i konfigurirajte provjere stanja prema ovisnostima koje im stvarno trebaju. Radnik može nastaviti trajne poslove nakon ponovnog pokretanja; agent vezan uz zahtjev ne može.

Promatrajte radnje, a ne samo odgovore

Tradicionalno praćenje aplikacija i dalje se primjenjuje: latencija, stope pogrešaka, dubina reda čekanja, performanse baze podataka i stanje ovisnosti. Agenti dodaju još jedan sloj. Zabilježite koji su alati predloženi i pozvani, neuspjehe provjere valjanosti, stope eskalacije, broj ponovnih pokušaja i prijelaz stanja tijeka rada koji je slijedio nakon svake radnje.

Nemojte neselektivno zapisivati osjetljive promptove ili odgovore modela. Zapisivanje treba biti korisno za dijagnostiku uz poštovanje zahtjeva za klasifikaciju i zadržavanje podataka. Identifikatori korelacije osobito su vrijedni: jedan identifikator treba povezati dolazni zahtjev, interakciju s modelom, izvršavanje alata, transakciju baze podataka i asinkroni posao.

Evaluacija se treba usredotočiti na operativne ishode. Može li agent odabrati ispravan alat? Odbija li zabranjene radnje? Oporavlja li se od duplicirane isporuke? Eskalira li kada je potrebno? Mali skup reprezentativnih scenarija, uključujući slučajeve neuspjeha, vredniji je od uglađenog demonstracijskog razgovora.

Gradite agente koji postupno zaslužuju ovlasti

Razuman napredak započinje pomoći samo za čitanje, prelazi na izradu nacrta, a zatim dodaje odobrene radnje uskog opsega. Svaki korak otkriva gdje su upute nejasne, nedostaju podaci ili poslovna pravila trebaju postati kod. Ovlasti se trebaju proširiti tek kada okolne kontrole pokažu da mogu obuzdati pogreške.

Zapamtljivi dio korisnog agenta rijetko je prompt. To je nenametljivo inženjerstvo oko njega: jasan ugovor, ograničeni alati, provjerene naredbe, trajno stanje, idempotentni upisi i iskren put do ljudskog pregleda. Kada su ti temelji postavljeni, AI postaje manje kazališna značajka, a više ono što backend programeri najviše cijene: pouzdana komponenta koja pomaže sustavu obavljati smislen posao.