Construirea de agenți AI pregătiți pentru producție
De ce o rulare de agent aparține unui job de fundal, cât costă de fapt un buget de tokeni și cele patru bariere pe care le pun în fața fiecărui apel la model.
Un agent este un job de fundal, nu o cerere
Primul lucru care merge prost când un agent ajunge într-un produs este forma execuției. O singură rulare de agent durează minute. Apelează un model, citește fișiere, apelează modelul din nou și scrie ceva. Asta nu e o cerere web.
În Lemniscate, agentul rulează ca job într-un worker Redis și BullMQ. Citește un repository, propune schimbări, scrie codul, împinge o ramură și deschide un pull request. Browserul nu ține conexiunea deschisă așteptând rezultatul; urmărește un flux de log prin server-sent events și poate fi închis și redeschis fără să omoare rularea.
Al doilea lucru care merge prost este să ai încredere într-o singură trecere. Lemniscate trimite opțional propriul diff la un al doilea apel de model înainte de orice merge. Recenzentul e mai ieftin decât autorul și prinde greșelile evidente.
Bugetul de tokeni e un buget real
Cea mai scumpă lecție pe care am învățat-o a venit de la un model de raționament. Facturează lanțul de gândire din aceeași alocație de output ca și răspunsul. La un răspuns lung, raționamentul a consumat tot bugetul, iar modelul nu a returnat nimic: nici răspuns, nici eroare, doar un string gol.
L-am măsurat în loc să ghicesc, am ridicat plafonul și am adăugat o gestionare a continuării care cere modelului să reia exact din punctul în care s-a oprit și îi interzice să repete ce a scris deja. De atunci, costul unui răspuns lung e un număr pe care îl pot prevedea, nu o surpriză.
Fiecare integrare pe care o construiesc acum are patru lucruri în fața apelului la model: un timeout, o verificare de schemă pe output, un plafon dur de tokeni și o cale de rezervă.
Căile de rezervă nu sunt paranoia
Doctorul AI de pe site răspunde la întrebări despre datele mele de sănătate prin apeluri către tool-uri. Când modelul găzduit nu e disponibil, trece pe un model care rulează pe același server, mai lent și mai puțin capabil, dar prezent. Când API-ul returnează un output malformat, asistentul răspunde cu ce poate verifica în loc să inventeze un număr.
Asta e diferența dintre o funcționalitate și un demo. Un demo presupune că furnizorul e disponibil, că răspunsul e bine format și că utilizatorul are răbdare.
Fă rularea auditabilă
Un agent care schimbă cod trebuie să lase o urmă. În Touchstone, API-ul pentru agenți returnează scheme de raport versionate (report/v1), așa că un client poate spune ce formă de răspuns a primit. Fiecare pas e înregistrat: ce s-a cerut, ce a returnat modelul, ce a fost acceptat.
Fără urma asta nu poți răspunde la singura întrebare care contează după un incident: ce a făcut de fapt.
Concluzia onestă
Un agent de producție e în mare parte muncă obișnuită de sisteme distribuite: cozi, retry-uri, idempotență, bugete, loguri, căi de rezervă. Modelul e o singură dependență în mecanismul acela și se comportă ca o dependență cu latență imprevizibilă, cost real și obiceiul de a greși cu încredere.
Tratează-l așa și funcționalitățile rezistă. Tratează-l ca pe magie și livrezi ceva care merge exact o dată, pe mașina ta, în timpul demo-ului.