Fluxuri de lucru agentice care nu se întrerup: apelarea instrumentelor, umanitatea în buclă și cusăturile dintre sisteme

Automatizarea proceselor de afaceri și un agent AI sunt vândute ca fiind același lucru și nu sunt. Automatizarea este o conductă fixă: pasul doi urmează întotdeauna pasul unu în același mod. Un agent este o buclă în care modelul decide ce pas urmează, pe baza a ceea ce tocmai a returnat un apel de instrument. Ambele au un loc - cea mai mare parte a ceea ce are nevoie de fapt o afacere este automatizarea cu unul sau două puncte de decizie agentică, nu un agent care efectuează fiecare apel.

Arhitectura de sub oricare dintre ele este cea care determină dacă supraviețuiește contactului cu datele reale: cum alimentezi contextul modelului, cum obții un răspuns înapoi într-o formă în care codul tău poate avea încredere, cum modelul ajunge în alte sisteme și unde o persoană încă trebuie să spună da. Acea instalație sanitară, nu alegerea modelului, este ceea ce petrec cea mai mare parte a unui proiect.

1. Ingineria contextului: alimentarea modelului cu felia potrivită, nu totul

Ingineria contextului este munca neplăcută de a decide ce vede modelul la un apel dat - care înregistrează, ce ture anterioare, ce instrucțiuni - și, la fel de important, ce nu vede. Transferarea unui întreg istoric al clientului sau a unui document complet în prompt de fiecare dată nu este rigurozitate; zgomotul este cel care împinge întrebarea reală mai departe de atenția modelului și mărește în liniște costurile la fiecare apel.

Modelul care rezistă este mai aproape de o problemă de căutare decât de o problemă de memorie: regăsiți cele două sau trei înregistrări relevante pentru acest pas specific, rezumați ceea ce a apărut înainte în loc să îl reluați textul și lăsați-l pe agent să ceară mai multe doar atunci când are nevoie. Un flux de lucru care extrage în mod fiabil cele cinci linii potrivite din zece mii de bătăi pe una care le îndesa pe toate cele zece mii de speranțe.

2. Ieșirile structurate și apelurile de instrumente/funcții sunt interfața reală

Un model care răspunde în text liber și este analizat cu o expresie regex este cazul în care aceste versiuni eșuează în mod liniștit în producție. Ieșiri structurate - o schemă JSON la care modelul este forțat să răspundă în interior - și apelarea instrumentului/funcției - modelul care solicită o funcție specifică cu argumente tastate în loc să descrie o acțiune în proză - sunt ceea ce lasă codul tău să aibă încredere într-un răspuns suficient pentru a acționa asupra lui fără ca un om să recitească fiecare ieșire.

Validez schema la ieșirea din model și din nou înainte de a ajunge la un sistem real, deoarece un model poate produce JSON valid sintactic, care este încă greșit pentru regula de afaceri la îndemână - o cantitate negativă, o dată din trecut, o monedă pe care contul nu o suportă. Schema prinde erori de formă; un al doilea strat de validare plictisitor le prinde pe cele care sunt valide JSON și încă greșite.

3. Înglobări și o bază de date vectorială - numai atunci când căutarea este locul de muncă real

Înglobările și o bază de date vectorială își câștigă locul atunci când sarcina este cu adevărat recuperarea: găsiți cele trei bilete de asistență cele mai apropiate de aceasta nouă, găsiți clauza într-un contract cea mai apropiată de această întrebare. Sunt instrumentul greșit pentru un set fix, mic de înregistrări la care răspunde deja o interogare normală de bază de date - am văzut o bază de date vectorială fixată într-un flux de lucru care avea unsprezece categorii posibile, în care un tabel de căutare ar fi fost mai rapid, mai ieftin și mai ușor de depanat.

Când este instrumentul potrivit, partea care are de fapt nevoie de îngrijire nu este modelul de încorporare - este ceea ce devine fragmentat, cum și cât de proaspăt rămâne indexul după modificarea documentului sursă. O căutare vectorială peste bucăți învechite oferă un răspuns sigur, greșit și nimic din rezultatul agentului nu vă spune că s-a întâmplat.

4. Human-in-the-loop și orchestrația API: unde se rupe de fapt

Eșecul pe care îl văd cel mai mult nu este raționamentul prost al modelului - este cusătura dintre două sisteme: un apel API care expiră și agentul reîncearcă de două ori, trimițând o comandă duplicată; un webhook care se declanșează înainte ca pasul anterior să termine de scris; un apel de instrument care reușește din partea vânzătorului, dar răspunsul pe care îl primește agentul spune că a eșuat. Orchestrarea apelurilor prin CRM, facturare și e-mail înseamnă să decideți ce se întâmplă în cazul unui timeout sau al unei eșecuri parțiale înainte de a se întâmpla în producție, nu după.

Tot ceea ce trimite bani, șterge o înregistrare sau trimite un e-mail unui client primește un pas de confirmare umană înainte de a se declanșa - nu pentru că modelul nu este de încredere în general, ci pentru că costul unei acțiuni automate greșite este asimetric cu costul unui clic suplimentar. Prefer ca o persoană să aprobe douăzeci de acțiuni corecte pe zi decât ca agentul să trimită automat o factură greșită.

Concluzie: agentul este cel mai ușor 10%

Alegerea unui model și scrierea primului prompt este cu adevărat partea ușoară a unui flux de lucru agentic. Contextul care este alimentat, schema care este validată, căutarea vectorială care rulează doar când ar trebui, logica de reîncercare pe trei APIs și singurul pas pe care un om încă îl aprobă - acesta este celălalt 90% și este cel care decide dacă automatizarea funcționează încă într-o marți de șase luni cu date împotriva cărora nimeni nu a testat. Scrieți prin formular cu procesul pe care doriți să îl automatizați și vă voi spune care 10% este agentul și care 90% este partea care are de fapt nevoie de construcție.