Cele mai bune practici de orchestrare a agenților AI: gestionarea eșecurilor, a aprobărilor și a reîncercărilor

Acest ghid explică modul în care funcționează orchestrarea agenților AI, compară arhitecturile centralizate, descentralizate și ierarhice și prezintă șapte bune practici pentru gestionarea eșecurilor, a aprobărilor și a reîncercărilor în producție.

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

Să ai mai mulți agenți care lucrează la același proiect pare extrem de eficient. Unul planifică munca, altul se ocupă de design, iar un al treilea scrie codul. Funcționează până când nu mai funcționează. Iar eșecurile apar mai des decât ți-ai dori.

Prevenirea acestor eșecuri necesită o proiectare atentă a fluxurilor de lucru. Așadar, hai să analizăm ce face fluxurile de lucru orchestrate să fie nefiabile și să explorăm cele mai bune practici de orchestrare pentru fiabilitate în producție.

Ce este orchestrarea agenților AI?

Orchestrarea agenților AI coordonează mai mulți agenți AI, modele și instrumente pentru a finaliza o sarcină în mai mulți pași. Dar cineva — sau ceva — trebuie totuși să decidă care agent rulează primul, ce informații primește și ce se întâmplă după ce termină. Acesta este rolul orchestratorului — un agent AI care acționează ca manager sau un strat de execuție controlat prin software.

În termeni simpli, un strat de orchestrare împarte un obiectiv în sarcini mai mici, urmărește dependențele, deleagă execuția agenților potriviți, gestionează contextul partajat și reunește rezultatele.

Cum funcționează orchestrarea agenților AI: în interiorul motorului de execuție

Să vedem ce se întâmplă după ce îi dai o sarcină unui orchestrator.

Să luăm un exemplu din atelierul Perplexity despre Computer: crearea unui dashboard de informații despre conturi folosind date din Salesforce, Snowflake, e-mail, calendar și știri recente.

  1. Înțelege obiectivul și planifică munca. Orchestratorul pornește de la rezultatul solicitat și îl descompune în sarcini cu dependențe explicite. În exemplul nostru cu dashboardul, asta presupune colectarea informațiilor din diferite surse și transformarea lor într-un livrabil finalizat. Planificatorul stabilește ce pași depind de alții și care pot rula independent.
  2. Direcționează sarcinile către agenții potriviți. Orchestratorul identifică sarcinile ale căror dependențe sunt îndeplinite și deleagă munca agenților sau modelelor specializate. Sarcinile dependente își așteaptă condițiile prealabile. Perplexity Computer folosește mai multe modele de vârf, direcționând diferite părți ale fluxului de lucru către sistemele potrivite pentru acele sarcini. Acest lucru permite și rularea în paralel a muncii independente.
  3. Execută apelurile de instrumente în medii controlate. Agenții interacționează cu mediul lor prin instrumente, cum ar fi căutarea pe web, API-uri, aplicații conectate, operațiuni cu fișiere sau execuția de cod. Stratul de execuție rulează aceste acțiuni și returnează rezultatele agenților.
  4. Transmite rezultatele și contextul între agenți. După ce un agent își termină sarcina, următorul agent din aval are nevoie de rezultatul relevant pentru a continua. O înregistrare de predare ar putea conține un ID de sarcină, o referință la rezultat, versiunea schemei și metadatele sursei. Orchestratorul coordonează aceste predări, păstrând totodată contextul necesar pentru pașii următori. Important este că agenții nu trebuie să poarte întregul istoric al muncii fiecărui alt agent în propriile ferestre de context.
  5. Înregistrează starea execuției separat de contextul agentului. Pe măsură ce agenții încep, finalizează sau eșuează la sarcini, motorul de execuție actualizează o înregistrare persistentă a fluxului de lucru cu stările sarcinilor, încercările de execuție, referințele la rezultate și munca rămasă. Această înregistrare îi permite orchestratorului să urmărească progresul și să reia activitatea după întreruperi, fără să se bazeze pe un LLM pentru a reconstrui fluxul de lucru din istoricul conversației.
  6. Validează rezultatele și decide ce urmează. Când o sarcină se încheie, stratul de orchestrare verifică dacă rezultatul ei respectă contractul așteptat și dacă dependențele următoarei sarcini sunt îndeplinite. Dacă se constată o problemă, fluxul de lucru poate reveni la un pas anterior pentru corectare sau poate fi întrerupt. În caz contrar, avansează spre finalizare.

Multe componente sunt implicate în spatele a ceea ce pare o simplă orchestrare a agenților AI. Modul în care organizezi coordonarea agenților determină cât control ai asupra execuției. Și, desigur, toată această coordonare adaugă costuri suplimentare. Așa că nu merită întotdeauna.

Când ar trebui să folosești orchestrarea agenților AI?

Ia în considerare orchestrarea multi-agent atunci când diferite părți ale sarcinii necesită expertize distincte, munca independentă poate rula în paralel sau nu poți stabili dinainte următorul pas.

Prin urmare, orchestrarea este utilă în trei scenarii:

  • Sarcinile necesită specializări diferite. Un proiect de programare, de exemplu, ar putea beneficia de agenți separați pentru planificare, design, dezvoltare și revizuire.
  • Sarcinile independente pot rula în paralel. În loc ca un singur agent să finalizeze totul secvențial, mai mulți agenți pot lucra simultan și își pot returna rezultatele unui orchestrator.
  • Problema are un final deschis. Agenții ar putea avea nevoie să exploreze abordări diferite, să ia decizii și să colaboreze, în loc să urmeze o secvență predefinită.

În afara acestor cazuri, orchestrarea este doar o tendință costisitoare. Mai mulți agenți înseamnă și mai multă coordonare și, potențial, costuri mai mari cu tokenii.

„De obicei încep cu cea mai simplă opțiune și construiesc pornind de acolo. Dacă știm pașii și sunt repetabili, probabil este vorba de un flux de lucru. Văd un motiv pentru a introduce mai mulți agenți doar atunci când aceștia au responsabilități, permisiuni sau utilizatori diferiți”, spune Josh Spilker, șeful departamentului de search marketing la AirOps.

Chiar și atunci, cântărește beneficiile în raport cu apelurile suplimentare către modele, predările, latența și punctele de eșec.

Arhitecturi de orchestrare a agenților AI și compromisurile lor

Există trei modalități comune de a structura coordonarea agenților — orchestrarea centralizată, descentralizată și ierarhică. Alegerea arhitecturii potrivite se reduce la o singură întrebare: Cine controlează munca și cum se coordonează agenții între ei?

Orchestrare centralizată

În orchestrarea centralizată, un singur orchestrator gestionează procesul. Acesta descompune sarcina, deleagă munca agenților specializați, le urmărește progresul și le reunește rezultatele.

Compromisul: Coordonarea centralizată facilitează urmărirea execuției și aplicarea unor reguli comune dintr-un singur punct de control. Totuși, orchestratorul poate deveni un blocaj, iar defectarea lui poate întrerupe întregul flux de lucru, cu excepția cazului în care sistemul permite recuperarea.

Orchestrare descentralizată

În orchestrarea descentralizată, agenții se coordonează mai direct, în loc să se bazeze pe un singur manager care să ia fiecare decizie. Pot schimba mesaje, pot citi starea partajată și își pot stabili independent pașii următori.

Compromisul: Agenții pot funcționa fără să aștepte un planificator central, ceea ce face această abordare utilă pentru munca exploratorie și contribuțiile independente. Însă coordonarea devine mai dificilă atunci când agenții nu sunt de acord, actualizează informații partajate sau trebuie să ajungă la un rezultat consecvent.

Orchestrare ierarhică

Orchestrarea ierarhică extinde abordarea cu manager pe mai multe niveluri. Un orchestrator de nivel superior deleagă responsabilitatea unor orchestratori subordonați, care își coordonează propriile grupuri de agenți specializați.

Gândește-te la un flux de lucru dintr-o companie mare care implică echipele de vânzări, finanțe și juridic. Un orchestrator de nivel superior ar putea delega fiecare flux de lucrări unui coordonator specializat pe domeniu. Acești coordonatori și-ar gestiona apoi propriii agenți specializați și ar raporta rezultate consolidate.

Această structură poate fi utilă atunci când fluxurile de lucru sunt prea ample pentru ca un singur orchestrator să le gestioneze eficient.

Compromisul: Ierarhiile permit echipelor să împartă responsabilitățile de coordonare și, potențial, să gestioneze eșecurile în cadrul ramurilor individuale. Totuși, ele introduc predări suplimentare, o gestionare mai complexă a stării și costuri operaționale mai mari. Recuperarea locală depinde, de asemenea, de modul în care sunt implementate punctele de control și starea execuției.

Cum se compară aceste arhitecturi:

Criterii

Centralizată

Descentralizată

Ierarhică

Responsabilitatea execuției

Un singur orchestrator controlează delegarea

Agenții se coordonează între ei sau prin starea partajată

Responsabilitatea este distribuită pe niveluri de orchestrare

Consecvența stării

Mai ușor de coordonat printr-un singur punct de control

Necesită sincronizare explicită și gestionarea conflictelor

Necesită coordonare în cadrul ramurilor și între ele

Izolarea eșecurilor

Controlerul central poate deveni o dependență critică

Agenții individuali pot eșua independent, dar infrastructura partajată rămâne critică

Eșecurile pot fi limitate la nivelul ramurilor, dacă sistemul este proiectat pentru recuperare

Aplicarea politicilor

Controalele comune pot fi aplicate centralizat

Politicile trebuie aplicate în mod consecvent de toți participanții

Controalele pot fi aplicate la nivel global și la nivel de domeniu

Complexitate operațională

În general, mai redusă

Complexitate de coordonare mai mare

Complexitate mai mare din cauza multiplelor straturi de orchestrare

Execuție secvențială, paralelă și bazată pe transferuri

Mai există o distincție care merită înțeleasă. Arhitectura determină cine coordonează agenții. Tiparul de execuție determină cum progresează sarcinile acestora.

Acestea sunt trei tipare de execuție:

  • Fluxuri de lucru secvențiale: Agenții lucrează într-o ordine predefinită, iar rezultatul unui agent devine datele de intrare ale altuia.
  • Execuție paralelă: Agenți independenți lucrează simultan.
  • Execuție bazată pe transferuri: Controlul trece de la un agent specializat la altul pe măsură ce sarcina avansează. Acest lucru este util atunci când un alt agent este mai bine pregătit să gestioneze pasul următor, deși fiecare transfer trebuie să păstreze informațiile necesare pentru a continua.

Aceste tipare nu se exclud reciproc și nu corespund unu-la-unu arhitecturilor de orchestrare. Scopul este să alegeți cea mai simplă structură care susține dependențele fluxului dumneavoastră de lucru, cerințele de coordonare și costurile operaționale acceptabile.

Eșecuri frecvente în orchestrarea agenților AI

Orice poate merge prost în orchestrare, de la simple scăpări până la blocaje complicate. Uneori, un agent poate chiar să pară că își face treaba corect, în timp ce fluxul de lucru în ansamblu eșuează. Pornind de la experiențele practicienilor, am adunat câteva dintre greșelile frecvente care stau la baza fluxurilor de lucru orchestrate nefiabile — fiți atenți la ele:

  • Transferuri între agenți cu pierdere de informații. Un orchestrator transmite un plan rezumat unui agent specializat, dar rezumatul omite constrângeri, dependențe sau detalii de implementare.
  • Execuție prematură de tip fan-in. Un agent din aval începe să agrege rezultatele înainte ca toate sarcinile din amonte să se fi încheiat.
  • Actualizări nedeterministe ale stării partajate. Agenți paraleli scriu în aceleași chei de stare fără o semantică de îmbinare bine definită. În funcție de modul în care framework-ul gestionează actualizările, acest lucru poate duce la scrieri pierdute, date duplicate, rezultate dependente de ordine sau modificări conflictuale.
  • Divergența dintre punctele de control și efectele secundare. O sarcină efectuează o operațiune externă, dar executarea ei cu succes nu este înregistrată durabil înainte de căderea workerului. La recuperare, orchestratorul vede o sarcină neterminată și o rulează din nou.
  • Condiții de cursă la reluarea după aprobarea umană. Întreruperea și reluarea execuției introduc propriile probleme de sincronizare.
  • Bucle de delegare și amplificarea reîncercărilor. Agenții își pasează în mod repetat munca unul altuia, deoarece responsabilitățile lor se suprapun, dependențele sunt circulare sau condițiile de finalizare sunt ambigue.
  • Controale la nivel de instrucțiuni confundate cu securitatea execuției. Un orchestrator le poate cere agenților să nu acceseze anumite resurse sau să nu efectueze acțiuni sensibile, dar instrucțiunile date modelului nu impun permisiuni ale sistemului de operare, restricții de rețea sau limite de autorizare. Cercetarea de inginerie a securității realizată de Perplexity arată de ce agenții pot depăși limitele de securitate în timp ce urmăresc obiective legitime, chiar și fără instrucțiuni rău intenționate

Observați cât de diferite sunt aceste eșecuri. O tranziție prematură a planificatorului sau o scriere externă ambiguă pot produce un rezultat incorect, dar își au originea în părți diferite ale ciclului de viață al execuției. De aceea, orchestrarea fiabilă necesită mai mult decât îmbunătățirea prompturilor sau adăugarea de reîncercări.

7 bune practici de orchestrare a agenților AI pentru fiabilitate în producție

1. Definiți contracte explicite pentru sarcini, criterii de acceptare și condiții de oprire

Obiectivele vagi și o definiție a finalizării neclară duc adesea la rezultate dezamăgitoare generate de agenți. Soluția este un contract de prompt (un caiet de sarcini pentru un agent): stabiliți obiectivul, constrângerile, formatul rezultatului și condițiile de eșec înainte de începerea execuției.

De exemplu, iată cum ați putea defini un contract pentru un agent responsabil cu remedierea unui test de integrare care eșuează intermitent:

  • Obiectiv: Identificarea și remedierea cauzei unui test de integrare instabil pentru API-ul de checkout.
  • Date de intrare: Codul sursă al testului, jurnalele de eșec din CI, commiturile recente și codul relevant al aplicației.
  • Constrângeri: Nu dezactivați testele, nu relaxați aserțiunile și nu modificați comportamentul aplicației care nu are legătură cu problema.
  • Rezultat așteptat: Un patch de cod, o explicație a cauzei principale și rezultatele execuției testelor.
  • Criterii de acceptare: Testul care eșua anterior trece în 10 rulări consecutive, iar suita de regresie relevantă trece.
  • Condiții de eșec: Cauza principală nu poate fi stabilită, remedierea introduce regresii sau mediul de testare necesar nu este disponibil.

Dar mai există un aspect important: când ar trebui să se oprească agentul?

Un agent nu ar trebui să continue iterațiile la nesfârșit doar pentru că nu a produs un rezultat satisfăcător. Definiți ce înseamnă finalizarea cu succes, când trebuie returnată o sarcină parțial finalizată și când trebuie oprit lucrul pentru că o cerință nu poate fi îndeplinită. Stabiliți o adâncime maximă de delegare și limite de iterații sau bugete de execuție, astfel încât sarcinile nerezolvate să nu devină bucle nesfârșite.

Să revenim la exemplul nostru de CI. Ați putea defini următoarele condiții de oprire:

  • Succes: Remedierea trece 10 rulări consecutive ale testului și suita de regresie relevantă.
  • Limită de iterații: Agentul poate încerca cel mult două remedieri candidate.
  • Buget de execuție: Agentul trebuie să se oprească după 60 de minute, chiar dacă problema rămâne nerezolvată.
  • Limită de delegare: Agentul poate delega munca unui singur agent specializat, fără delegări suplimentare către subagenți.
  • Finalizare parțială: Dacă ambele încercări eșuează sau limita de timp expiră, agentul returnează constatările, modificările încercate și rezultatele testelor.
  • Execuție blocată: Dacă mediul de testare nu este disponibil, agentul se oprește și raportează blocajul, în loc să pretindă că a reușit.

2. Păstrați orchestratorii simpli și impuneți transferuri structurate

Uneori, dezvoltatorii îi atribuie unui orchestrator prea multe responsabilități, iar în loc să coordoneze agenți specializați, acesta începe să scrie cod, să depaneze sau să efectueze singur revizuiri detaliate. Acest lucru creează un blocaj: orchestratorul își consumă bugetul de context pe detalii de implementare, amână delegarea și estompează responsabilitatea pentru rezultate.

Așadar, lăsați orchestratorii să-și facă treaba și impuneți transferuri care fac referire la artefacte concrete: sarcina inițială, datele de intrare relevante, artefactele rezultate, starea execuției și orice probleme nerezolvate.

Luați în considerare acest exemplu: status: completed se referă la munca atribuită agentului, nu la întregul flux de lucru. Deoarece testele sunt încă în starea pending, orchestratorul nu ar trebui să aprobe rezultatul final.

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. Stocați persistent starea fluxului de lucru și controlați creșterea contextului

Istoricul conversației unui agent nu este o evidență fiabilă a progresului fluxului de lucru. Când fereastra de context se umple, compactarea automată poate elimina detalii importante. Iar dacă un worker se prăbușește, următorul agent trebuie să știe ce pași au fost efectiv finalizați.

De exemplu, dacă agentul de programare generează un patch și apoi se prăbușește, următorul worker ar trebui să recupereze artefactul salvat și să continue de la starea înregistrată a fluxului de lucru. Dar dacă agentul a declanșat și o rulare CI externă, orchestratorul trebuie să reconcilieze separat acea rulare înainte de a repeta acțiunea

Așadar, păstrați starea execuției separat de contextul de lucru al agentului. Salvați stările sarcinilor, încercările de execuție, pașii finalizați și referințele la artefacte într-un spațiu de stocare durabil. Între timp, încărcați doar instrucțiunile, datele de intrare și rezultatele relevante pentru sarcina curentă a agentului, în loc să înghesuiți întregul istoric al execuției în fereastra lui de context.

4. Proiectați reîncercări care țin cont de eșecuri și o execuție recuperabilă a instrumentelor

Să presupunem că agentul CI declanșează o rulare de teste, dar solicitarea API expiră. Rularea testelor nu a pornit sau serviciul CI a pus-o în coadă și a pierdut răspunsul?

Expirarea timpului de așteptare nu înseamnă neapărat că o operațiune a eșuat. De aceea, trebuie să faceți distincția între tipurile de erori înainte de a decide ce urmează:

  • Erori tranzitorii (429, 503): Reîncercați cu backoff exponențial limitat și jitter, respectând Retry-After atunci când este furnizat.
  • Erori de validare sau de permisiune (400, 403): Opriți-vă sau corectați problema de fond în loc să repetați aceeași solicitare.
  • Rezultate ambigue (expirare după o posibilă scriere): Verificați dacă operațiunea a reușit înainte de a o încerca din nou.

Notă: Chiar și erorile care permit reîncercarea au nevoie de limite. Setați un timeout pentru fiecare apel de instrument, limitați numărul de reîncercări și timpul total de reîncercare și impuneți un termen-limită general pentru fluxul de lucru, astfel încât agenții imbricați să nu poată reporni la nesfârșit aceeași operațiune. Dacă o dependență eșuează în mod repetat, folosiți un circuit breaker pentru a opri temporar solicitările.

Pentru operațiunile cu efecte secundare externe, atribuiți o cheie de idempotență stabilă fiecărei acțiuni logice și reutilizați-o la toate reîncercările. Dacă API-ul acceptă deduplicarea pe server, acesta poate recunoaște solicitările repetate fără să efectueze acțiunea de două ori. Dacă nu, interogați sistemul extern folosind un ID de corelare sau o altă referință autoritativă.

Când nu puteți stabili ce s-a întâmplat, opriți-vă și escaladați.

Un exemplu de logică de reîncercare pentru agentul nostru CI, exprimat ca pseudocod:

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

Notă despre cod: Exemplul presupune că API-ul CI permite căutarea rulărilor după ID-ul solicitării. Parametrul request_id previne duplicatele doar dacă furnizorul garantează explicit idempotența. bounded_retry() este un pseudocod ilustrativ. În producție, reîncercările ar trebui limitate atât de un buget de reîncercări per operațiune (număr maxim de încercări sau timp scurs), cât și de termenul-limită general al fluxului de lucru.

Pentru fluxurile de lucru mai lungi, care se întind pe mai multe servicii, luați în considerare tiparul Saga pentru a coordona acțiunile compensatorii atunci când pașii ulteriori eșuează. Nu uitați însă că o compensare nu este întotdeauna o anulare completă. Puteți inversa o actualizare a bazei de date, dar nu puteți anula trimiterea unui e-mail.

5. Direcționați și paralelizați munca folosind bugete explicite de resurse

Aici trebuie echilibrate două lucruri: câtă capacitate a modelului necesită fiecare sarcină și câte sarcini puteți rula simultan. Dacă greșiți oricare dintre ele, riscați ca agenții să concureze pentru cotele API partajate sau să se bazeze exclusiv pe modele de raționament costisitoare.

Pentru selecția modelului, potriviți capacitatea modelului și efortul de raționament cu complexitatea sarcinii — simplu, dar destul de des trecut cu vederea. Rețineți că puteți fie să configurați singur reguli de direcționare și să evaluați modelele, fie să folosiți o platformă de orchestrare care gestionează selecția modelului pentru dumneavoastră.

De exemplu, modul de efort din Perplexity Computer vă permite să alegeți cât efort merită o sarcină, fără să selectați manual un model. Alegeți Light, Standard, High sau Ultra, iar Perplexity selectează automat modelul de orchestrare și nivelul său de raționament. Orchestratorul deleagă apoi subsarcini agenților de suport, care pot folosi modele de la furnizori diferiți.

Perplexity evaluează configurațiile modelelor din punctul de vedere al calității și al costului, favorizând opțiunile mai puțin costisitoare care oferă rezultate comparabile. Puteți folosi și controalele Custom dacă preferați să alegeți singur modelul și nivelul de raționament.

Pentru paralelism, limita ar trebui să fie dictată de infrastructura și dependențele dumneavoastră externe. Verificați limitele de rată pentru solicitări și tokenuri ale API-urilor partajate, apoi testați fluxul de lucru sub sarcină cu un nivel crescător de concurență. Urmăriți dacă debitul se îmbunătățește sau dacă solicitările încep să fie puse în coadă, să încetinească ori să returneze erori 429.

Pentru a menține un consum de resurse previzibil, impuneți limite de resurse și controale de planificare:

  • Controlați concurența și ratele de solicitare: Limitați apelurile în curs per serviciu și puneți în coadă munca în exces. Rețineți că o limită de concurență nu impune, de una singură, limite de solicitări pe minut sau de tokenuri pe minut.
  • Urmăriți bugetele de tokenuri și de costuri: Contabilizați utilizarea în întregul flux de lucru, inclusiv în subagenți, și nu mai lansați sarcini noi atunci când bugetul rămas este insuficient.
  • Impuneți termene-limită de execuție: Stabiliți limite de timp pentru sarcini și pentru fluxul de lucru și propagați anularea către agenții care rulează, acolo unde este posibil.
  • Respectați dependențele: Porniți sarcinile din aval doar atunci când datele de intrare necesare sunt disponibile, în loc să lansați toți agenții simultan.

6. Impuneți aprobări și izolați execuția agenților

Nu cereți niciodată modelului să decidă dacă propriile acțiuni sunt sigure. În schimb, acordați agenților permisiuni după principiul privilegiului minim și impuneți reguli de aprobare bazate pe risc în codul aplicației. Dacă agenții execută cod, izolați execuția de mediul gazdă și restricționați accesul la fișiere, rețele și credențiale. Astfel, limitați daunele dacă agentul face o greșeală sau execută cod nesigur.

„Sunt sceptic în privința sistemelor multi-agent prea complicate, mai ales când agenții își revizuiesc și își aprobă reciproc munca. Puteți ajunge la situația în care mai mulți agenți transmit mai departe, cu încredere, aceeași greșeală, fără ca cineva să o observe de fapt”, avertizează Spilker.

Pentru acțiunile care necesită aprobare umană, întrerupeți execuția și salvați exact operațiunea propusă:

  • parametrii acesteia
  • resursa sa țintă
  • commitul sau versiunea stării sale
  • decizia evaluatorului

De asemenea, definiți ce se întâmplă dacă aprobarea este respinsă, expiră sau necesită escaladare. Acest lucru este esențial pentru framework-urile cu reluare, deoarece reluarea unui nod întrerupt execută din nou codul de la începutul acelui nod. Orice efecte secundare produse înainte de întrerupere se pot repeta.

Așadar, dacă aprobarea este respinsă sau expiră, solicitarea se închide. Dacă commitul țintă, parametrii sau permisiunile se modifică înainte de execuție, invalidați aprobarea și solicitați una nouă.

De asemenea, Spilker nu susține ideea agenților complet autonomi, end-to-end, văzuți ca obiectiv final. „Pentru mine, abordarea mai bună este să construiești câțiva agenți concentrați, cu responsabilități clare, permisiuni definite și revizuire umană în punctele potrivite. Obții în continuare eficiență fără să renunți la controlul deplin”, conchide el.

7. Verificați rezultatele în mod independent și testați comportamentul de recuperare

Vi s-a întâmplat vreodată ca un agent să raporteze Success când, de fapt, a eșuat? Este enervant, dacă nu chiar exasperant, iar remedierea nu e rapidă, pentru că mesajul final al agentului nu vă va spune neapărat unde au mers lucrurile prost.

Pentru a investiga, urmăriți ce s-a întâmplat în timpul execuției și verificați independent rezultatele. Așadar, haideți să dedicăm puțin timp izolării și rezolvării problemei.

Urmăriți fluxul de lucru pentru a identifica ce a mers prost

Înainte de a depana prompturile unui agent, capturați întreaga cale de execuție. Aveți nevoie de un trace care să conecteze invocările agenților, apelurile de instrumente, erorile și reîncercările în cadrul aceleiași rulări a fluxului de lucru.

Convențiile semantice GenAI ale OpenTelemetry oferă o modalitate standardizată de a descrie aceste operațiuni. De exemplu, invoke_workflow identifică execuția fluxului de lucru, invoke_agent o invocare de agent, iar execute_tool un apel de instrument. Fiecare operațiune poate fi înregistrată ca un span, cu durata, starea și metadatele relevante.

Acest pas vă oferă un trace al căii de execuție, astfel încât să puteți identifica unde s-a împotmolit un agent.

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

Un exemplu ilustrativ de trace de execuție.

Verificați rezultatul în mod independent

Folosiți verificări programatice ori de câte ori este posibil. Validați rezultatele pe baza schemelor JSON, rulați teste unitare și de integrare, verificați existența artefactelor necesare și interogați sistemele externe pentru a confirma că acțiunile au reușit cu adevărat.

Pentru rezultatele care necesită o judecată subiectivă — și, prin urmare, nu pot fi evaluate prin verificări programatice — introduceți un agent evaluator independent. O abordare este o buclă implementator–evaluator–rezolvator, în care un agent produce un artefact, un evaluator cu context nou identifică problemele, iar un rezolvator le soluționează înainte ca validarea să ruleze din nou.

Trebuie în continuare să validați constatările evaluatorului acolo unde este posibil, iar dacă folosiți evaluatori bazați pe LLM pentru evaluări repetate, calibrați-le judecățile pe baza unor exemple revizuite de oameni.

Injectați eșecuri pentru a testa recuperarea

Până acum, ați urmărit ce au executat agenții și ați verificat dacă rezultatele lor au fost corecte. Dar ce se întâmplă când un worker se oprește neașteptat la jumătatea unei sarcini sau când un API depășește timpul de răspuns după ce a acceptat o cerere? Surprinzător, fluxul de lucru poate funcționa perfect în condiții normale, dar poate eșua în timpul recuperării.

Pentru a testa acest lucru, injectați deliberat defecțiuni într-un mediu de testare:

  • Simulați depășiri ale timpului de răspuns al API-ului
  • Opriți forțat workerii între scrierile externe și punctele de control
  • Returnați rezultate ale instrumentelor formatate incorect
  • Faceți ca aprobările să expire

După fiecare test, inspectați urma de execuție pentru a vedea ce pași au rulat, de unde și-a reluat fluxul de lucru execuția și dacă vreo acțiune a fost repetată sau omisă. Apoi analizați rezultatele reale.

Să presupunem că agentul CI trimite o cerere pentru a porni o rulare de teste, dar răspunsul API-ului depășește timpul de așteptare. Agentul reîncearcă, primește un răspuns reușit și raportează Succes. Totul pare în regulă până când verificați serviciul CI și descoperiți că au fost create două rulări de teste în loc de una.

De aceea, ar trebui să verificați atât starea înregistrată a fluxului de lucru, cât și modificările reale din sistemele externe. Un test de recuperare ar trebui să treacă doar atunci când fluxul de lucru ajunge la starea așteptată fără efecte secundare neintenționate.

Adăugați eșecurile pe care le descoperiți în testele de regresie, astfel încât modificările viitoare să nu le reintroducă.

În cele din urmă, succes înseamnă că fluxul de lucru a trecut verificările obligatorii, iar rezultatele sale externe au fost verificate.

Întrebări frecvente despre orchestrarea agenților AI

De ce eșuează agenții AI izolați la scară de întreprindere?

Agenții izolați își pot îndeplini corect sarcinile individuale, dar împreună pot produce rezultate inconsecvente. Imaginați-vă un agent de vânzări care preia condițiile clientului la 10:00, un agent de prețuri care calculează o ofertă folosind prețuri actualizate la 10:05 și un agent juridic care verifică un contract modificat la 10:07. Fiecare agent lucrează cu o imagine diferită a afacerii, astfel încât rezultatele lor se pot contrazice reciproc.

Problema devine mai pronunțată la scară de întreprindere, deoarece agenții interacționează cu mai multe sisteme care se actualizează independent, funcționează cu permisiuni diferite și nu partajează neapărat contextul sau starea de execuție.

Cum preveniți buclele infinite de reîncercări la agenții AI?

Stabiliți limite pe mai multe niveluri: numărul maxim de reîncercări ale apelurilor de instrumente, numărul maxim de iterații ale agentului, adâncimea delegării și un termen-limită general pentru fluxul de lucru. Clasificați eșecurile înainte de a reîncerca. Pentru răspunsurile tranzitorii 429, respectați Retry-After atunci când este furnizat. În caz contrar, folosiți un backoff exponențial limitat, cu jitter.

Nu mai reîncercați cererile nemodificate după erori de validare sau de permisiuni. Dacă un serviciu din aval eșuează în mod repetat, un mecanism de tip circuit breaker poate împiedica agenții să genereze încărcare suplimentară.

Cum reluați un flux de lucru cu agenți AI după o oprire neașteptată?

Mecanismul de recuperare depinde de mediul de rulare. Cu LangGraph, un checkpointer persistent, cum ar fi PostgresSaver, stochează starea grafului sub un thread_id, permițând continuarea execuției din starea persistată. Cu Temporal, un alt worker poate reconstrui un flux de lucru prin redarea istoricului său de evenimente. În timpul redării, acesta reutilizează rezultatele activităților înregistrate anterior.

Dacă aplicația este reimplementată în timp ce fluxurile de lucru încă rulează, starea salvată și istoricele de execuție s-ar putea să nu mai fie compatibile. Temporal rezolvă această problemă prin Worker Versioning și aplicarea de patch-uri pentru fluxurile de lucru. Pentru sistemele bazate pe puncte de control, planificați migrările de schemă și testați recuperarea pornind de la stările salvate existente înainte de a lansa modificări incompatibile.

Cum testați fiabilitatea orchestrării agenților AI?

Rulați aceleași sarcini reprezentative de mai multe ori și faceți distincția între pass@k (dacă cel puțin una dintre cele k încercări reușește) și pass^k (dacă toate cele k încercări reușesc)

Măsurați rezultatele în funcție de categoria sarcinii și de versiunea fluxului de lucru, în loc să vă bazați pe o singură rată de succes agregată. Urmăriți succesul la prima încercare, consecvența între rulările repetate, latența p95, costul per sarcină finalizată și proporția de sarcini care necesită intervenție umană. Raportați dimensiunile eșantioanelor și intervalele de incertitudine pentru ratele de succes.