Bones pràctiques d’orquestració d’agents d’IA: gestió d’errors, aprovacions i reintents

Tenir diversos agents treballant en el mateix projecte sembla extremadament eficient. Un planifica la feina, un altre s’encarrega del disseny i un tercer escriu el codi. Funciona fins que deixa de funcionar. I les fallades passen més sovint del que voldries.

Evitar aquestes fallades requereix una enginyeria acurada dels fluxos de treball. Així doncs, analitzem què fa que els fluxos de treball orquestrats siguin poc fiables i explorem les millors pràctiques d’orquestració per aconseguir fiabilitat en producció.

Què és l’orquestració d’agents d’IA?

L’orquestració d’agents d’IA coordina diversos agents, models i eines d’IA per completar una tasca de diversos passos. Però algú —o alguna cosa— encara ha de decidir quin agent s’executa primer, quina informació rep i què passa quan acaba. Aquest és el paper de l’orquestrador: un agent d’IA que actua com a gestor o una capa d’execució controlada per programari.

En poques paraules, una capa d’orquestració divideix un objectiu en tasques més petites, fa el seguiment de les dependències, delega l’execució als agents adequats, gestiona el context compartit i combina els resultats.

Com funciona l’orquestració d’agents d’IA: a l’interior del motor d’execució

Amplia

Vegem què passa després que donis una tasca a un orquestrador.

Pensem en un exemple del taller de Computer de Perplexity: crear un tauler d’intel·ligència de comptes amb informació de Salesforce, Snowflake, el correu electrònic, el calendari i notícies recents.

1. Entendre l’objectiu i planificar la feina. L’orquestrador parteix del resultat sol·licitat i el descompon en tasques amb dependències explícites. En el nostre exemple del tauler, això implica recopilar informació de diferents fonts i convertir-la en un lliurable acabat. El planificador estableix quins passos depenen d’altres i quins es poden executar de manera independent.
2. Encaminar les tasques als agents adequats. L’orquestrador identifica les tasques que tenen les dependències satisfetes i delega la feina a agents o models especialitzats. Les tasques dependents esperen que es compleixin els seus requisits previs. Perplexity Computer utilitza diversos models capdavanters i encamina les diferents parts del flux de treball cap als sistemes més adequats per a cada tasca. Això també permet que la feina independent s’executi en paral·lel.
3. Executar crides a eines en entorns controlats. Els agents interactuen amb el seu entorn mitjançant eines, com ara la cerca web, les API, les aplicacions connectades, les operacions amb fitxers o l’execució de codi. La capa d’execució duu a terme aquestes accions i retorna els resultats als agents.
4. Transmetre resultats i context entre agents. Quan un agent acaba la seva tasca, el següent agent de la cadena necessita la sortida rellevant per continuar. Un registre de traspàs podria contenir un identificador de tasca, una referència a la sortida, una versió de l’esquema i metadades d’origen. L’orquestrador coordina aquests traspassos i manté el context necessari per als passos següents. Cal destacar que els agents no han de carregar tot l’historial de la feina de tots els altres agents a les seves pròpies finestres de context.
5. Registrar l’estat d’execució per separat del context dels agents. A mesura que els agents comencen, completen o fallen tasques, el motor d’execució actualitza un registre persistent del flux de treball amb l’estat de les tasques, els intents d’execució, les referències a les sortides i la feina pendent. Aquest registre permet a l’orquestrador fer el seguiment del progrés i reprendre la feina després d’interrupcions sense dependre d’un LLM per reconstruir el flux de treball a partir de l’historial de la conversa.
6. Validar els resultats i decidir què passa a continuació. Quan una tasca retorna, la capa d’orquestració comprova si la sortida compleix el contracte esperat i si es compleixen les dependències de la tasca següent. Si es detecta un problema, el flux de treball pot tornar a un pas anterior per corregir-lo o posar-se en pausa. Altrament, avança cap a la finalització.

Darrere del que sembla una simple orquestració d’agents d’IA hi ha moltes peces en moviment. La manera com organitzes la coordinació dels agents determina quant control tens sobre l’execució. I, és clar, tota aquesta coordinació afegeix una sobrecàrrega. Per tant, no sempre val la pena.

Quan s’ha d’utilitzar l’orquestració d’agents d’IA?

Planteja’t l’orquestració multiagent quan diferents parts de la tasca requereixen coneixements especialitzats diferents, la feina independent es pot executar en paral·lel o no pots determinar el pas següent per endavant.

Per tant, l’orquestració és útil en tres escenaris:

• Les tasques requereixen especialitzacions diferents. Un projecte de programació, per exemple, es pot beneficiar d’agents separats de planificació, disseny, desenvolupament i revisió.
• Les tasques independents es poden executar en paral·lel. En lloc que un sol agent ho completi tot de manera seqüencial, diversos agents poden treballar simultàniament i retornar els resultats a un orquestrador.
• El problema és obert. És possible que els agents hagin d’explorar enfocaments diferents, prendre decisions i col·laborar en lloc de seguir una seqüència predefinida.

Fora d’aquests casos, l’orquestració és només una tendència costosa. Més agents també impliquen més coordinació i, potencialment, costos de tokens més elevats.

«Normalment començo per l’opció més senzilla i, a partir d’aquí, vaig avançant. Si coneixem els passos i són repetibles, probablement és un flux de treball. Només veig motius per introduir diversos agents quan tenen responsabilitats, permisos o usuaris diferents», diu Josh Spilker, responsable de màrqueting de cerca a AirOps.

Fins i tot llavors, sospesa els beneficis davant de les crides addicionals als models, els traspassos, la latència i els punts de fallada.

Arquitectures d’orquestració d’agents d’IA i els seus pros i contres

Hi ha tres maneres habituals d’estructurar la coordinació d’agents: l’orquestració centralitzada, la descentralitzada i la jeràrquica. Triar l’arquitectura adequada es redueix a una pregunta: qui controla la feina i com es coordinen els agents entre ells?

Orquestració centralitzada

En l’orquestració centralitzada, un sol orquestrador gestiona el procés. Divideix la tasca, delega la feina a agents especialistes, fa el seguiment del seu progrés i combina els seus resultats.

Amplia

Pros i contres: La coordinació centralitzada facilita el seguiment de l’execució i l’aplicació de regles comunes en un únic punt de control. Tanmateix, l’orquestrador es pot convertir en un coll d’ampolla, i una fallada seva pot interrompre tot el flux de treball si el sistema no admet la recuperació.

Orquestració descentralitzada

En l’orquestració descentralitzada, els agents es coordinen de manera més directa en lloc de dependre d’un sol gestor que prengui totes les decisions. Poden intercanviar missatges, llegir l’estat compartit i determinar de manera independent els passos següents.

Amplia

Pros i contres: Els agents poden funcionar sense esperar un planificador central, cosa que fa que aquest enfocament sigui útil per a la feina exploratòria i les contribucions independents. Però la coordinació es complica quan els agents no estan d’acord, actualitzen informació compartida o han d’arribar a un resultat coherent.

Orquestració jeràrquica

L’orquestració jeràrquica estén l’enfocament del gestor a diversos nivells. Un orquestrador de nivell superior delega responsabilitats en orquestradors subordinats, que coordinen els seus propis grups d’agents especialistes.

Pensa en un flux de treball empresarial en què participen els equips de vendes, finances i assumptes jurídics. Un orquestrador de nivell superior podria delegar cada àmbit de treball en un coordinador específic del domini. Aquests coordinadors gestionarien els seus propis agents especialistes i informarien de resultats consolidats.

Aquesta estructura pot ser útil quan els fluxos de treball són massa amplis perquè un sol orquestrador els gestioni de manera eficaç.

Amplia

Pros i contres: Les jerarquies permeten als equips repartir les responsabilitats de coordinació i, potencialment, gestionar les fallades dins de branques individuals. Tanmateix, introdueixen traspassos addicionals, una gestió de l’estat més complexa i una sobrecàrrega operativa més gran. La recuperació local també depèn de com s’implementin els punts de control i l’estat d’execució.

Comparació d’aquestes arquitectures:

Execució seqüencial, paral·lela i basada en traspassos

Hi ha una altra distinció que val la pena entendre. L’arquitectura determina qui coordina els agents. El patró d’execució determina com avancen les seves tasques.

Aquests són tres patrons d’execució:

• Fluxos de treball seqüencials: Els agents treballen en un ordre predefinit, i el resultat d’un agent es converteix en l’entrada d’un altre.
• Execució paral·lela: Diversos agents independents treballen simultàniament.
• Execució basada en traspassos: El control passa d’un agent especialista a un altre a mesura que avança la tasca. És útil quan un altre agent està més ben preparat per gestionar el pas següent, tot i que cada traspàs ha de conservar la informació necessària per continuar.

Aquests patrons no són mútuament excloents i no es corresponen un a un amb les arquitectures d’orquestració. L’objectiu és triar l’estructura més senzilla que suporti les dependències del teu flux de treball, els requisits de coordinació i la càrrega operativa acceptable.

Errors habituals en l’orquestració d’agents d’IA

En l’orquestració pot fallar qualsevol cosa, des de simples descuits fins a bloquejos complexos. De vegades, fins i tot pot semblar que un agent fa bé la seva feina mentre el flux de treball global falla. A partir de l’experiència de professionals del sector, hem recopilat alguns dels errors habituals que hi ha darrere dels fluxos de treball orquestrats poc fiables. Para-hi atenció:

• Traspassos entre agents amb pèrdua d’informació. Un orquestrador passa un pla resumit a un agent especialista, però el resum omet restriccions, dependències o detalls d’implementació.
• Agregació prematura de resultats (fan-in). Un agent posterior comença a agregar resultats abans que hagin acabat totes les tasques prèvies.
• Actualitzacions no deterministes de l’estat compartit. Diversos agents paral·lels escriuen a les mateixes claus d’estat sense una semàntica de fusió ben definida. Segons com gestioni les actualitzacions el framework, això pot provocar escriptures perdudes, dades duplicades, resultats que depenen de l’ordre o canvis contradictoris.
• Divergència entre els punts de control i els efectes secundaris. Una tasca executa una operació externa, però la seva execució correcta no queda registrada de manera duradora abans que el procés de treball falli. En la recuperació, l’orquestrador veu una tasca inacabada i la torna a executar.
• Condicions de carrera en reprendre l’execució després de l’aprovació humana. Posar en pausa i reprendre l’execució comporta els seus propis problemes de sincronització.
• Bucles de delegació i amplificació de reintents. Els agents es passen la feina repetidament els uns als altres perquè les seves responsabilitats se superposen, les dependències són circulars o les condicions de finalització són ambigües.
• Controls a nivell d’instruccions confosos amb seguretat d’execució. Un orquestrador pot indicar als agents que no accedeixin a determinats recursos o que no facin accions sensibles, però les instruccions del model no imposen permisos del sistema operatiu, restriccions de xarxa ni límits d’autorització. La recerca en enginyeria de seguretat de Perplexity posa de manifest per què els agents poden creuar límits de seguretat mentre persegueixen objectius legítims, fins i tot sense instruccions malicioses

Fixa’t en com són de diferents aquests errors. Una transició prematura del planificador o una escriptura externa ambigua poden produir un resultat incorrecte, però s’originen en parts diferents del cicle de vida de l’execució. Per això, una orquestració fiable requereix més que millorar les indicacions o afegir reintents.

7 bones pràctiques d’orquestració d’agents d’IA per a la fiabilitat en producció

1. Defineix contractes de tasca explícits, criteris d’acceptació i condicions d’aturada

Els objectius vagues i una definició de feina feta poc clara sovint porten a resultats decebedors generats per agents. La solució és un contracte d’indicacions (un abast de treball per a un agent): acorda l’objectiu, les restriccions, el format de sortida i les condicions de fallada abans que comenci l’execució.

Per exemple, així és com podries definir un contracte per a un agent responsable de corregir una prova d’integració que falla de manera intermitent:

• Objectiu: Identificar i corregir la causa d’una prova d’integració inestable de l’API de pagament.
• Entrades: Codi font de la prova, registres d’errors de CI, commits recents i codi de l’aplicació rellevant.
• Restriccions: No desactivar proves, no relaxar assercions ni modificar comportaments de l’aplicació no relacionats.
• Sortida esperada: Un pedaç de codi, una explicació de la causa arrel i els resultats de l’execució de les proves.
• Criteris d’acceptació: La prova que abans fallava passa en 10 execucions consecutives i el conjunt de proves de regressió corresponent també passa.
• Condicions de fallada: No es pot establir la causa arrel, la correcció introdueix regressions o l’entorn de proves necessari no està disponible.

Però hi ha una altra part important: quan s’ha d’aturar l’agent?

Un agent no hauria de continuar iterant indefinidament perquè no ha obtingut un resultat satisfactori. Defineix què constitueix una finalització correcta, quan s’ha de retornar una tasca completada parcialment i quan cal aturar-se perquè no es pot complir un requisit. Estableix una profunditat màxima de delegació i límits d’iteració o pressupostos d’execució perquè les tasques no resoltes no es converteixin en bucles infinits.

Tornem al nostre exemple de CI. Podries definir les condicions d’aturada següents:

• Èxit: La correcció passa 10 execucions consecutives de la prova i el conjunt de proves de regressió corresponent.
• Límit d’iteracions: L’agent no pot provar més de dues correccions candidates.
• Pressupost d’execució: L’agent s’ha d’aturar al cap de 60 minuts, encara que el problema continuï sense resoldre’s.
• Límit de delegació: L’agent pot delegar feina a un agent especialista, sense cap més delegació a subagents.
• Finalització parcial: Si tots dos intents fallen o s’esgota el límit de temps, l’agent retorna les seves conclusions, els canvis que ha intentat i els resultats de les proves.
• Execució bloquejada: Si l’entorn de proves no està disponible, l’agent s’atura i informa del bloqueig en lloc d’afirmar que ha tingut èxit.

2. Mantén els orquestradors lleugers i imposa traspassos estructurats

De vegades, els desenvolupadors donen massa responsabilitats a un orquestrador i, en lloc de coordinar agents especialistes, comença a escriure codi, depurar o fer revisions detallades pel seu compte. Això crea un coll d’ampolla: l’orquestrador gasta el seu pressupost de context en detalls d’implementació, endarrereix la delegació i desdibuixa la responsabilitat sobre els resultats.

Així doncs, deixa que els orquestradors facin la seva feina i imposa traspassos que facin referència a artefactes concrets: la tasca original, les entrades rellevants, els artefactes de sortida, l’estat de l’execució i qualsevol problema no resolt.

Considera aquest exemple: status: completed fa referència a la feina assignada a l’agent, no a tot el flux de treball. Com que les proves encara estan en estat pending, l’orquestrador no hauria d’aprovar el resultat final.

3. Fes persistent l’estat del flux de treball i controla el creixement del context

L’historial de conversa d’un agent no és un registre fiable del progrés del flux de treball. Quan se li omple la finestra de context, la compactació automàtica pot eliminar detalls importants. I si un procés de treball falla, el següent agent ha de saber quins passos s’han completat realment.

Per exemple, si l’agent de programació genera un pedaç i després falla, el següent procés de treball hauria de recuperar l’artefacte desat i continuar des de l’estat del flux de treball registrat. Però si l’agent també ha activat una execució externa de CI, l’orquestrador ha de conciliar aquesta execució per separat abans de repetir l’acció

Per tant, mantén l’estat d’execució separat del context de treball de l’agent. Desa els estats de les tasques, els intents d’execució, els passos completats i les referències als artefactes en un emmagatzematge durador. Mentrestant, carrega només les instruccions, les entrades i els resultats rellevants per a la tasca actual de l’agent, en lloc d’omplir la seva finestra de context amb tot l’historial d’execució.

4. Dissenya reintents conscients dels errors i una execució d’eines recuperable

Suposem que el teu agent de CI activa una execució de proves, però la sol·licitud a l’API esgota el temps d’espera. L’execució de proves no s’ha pogut iniciar, o bé el servei de CI l’ha posada a la cua i se n’ha perdut la resposta?

Que s’esgoti el temps d’espera no vol dir necessàriament que una operació hagi fallat. Per això, cal distingir entre tipus d’errors abans de decidir què passa a continuació:

• Errors transitoris (429, 503): Torna-ho a provar amb un retrocés exponencial limitat i una variació aleatòria (jitter), respectant Retry-After quan s’indiqui.
• Errors de validació o de permisos (400, 403): Atura’t o corregeix el problema subjacent en lloc de repetir la mateixa sol·licitud.
• Resultats ambigus (temps d’espera esgotat després d’una possible escriptura): Comprova si l’operació s’ha completat correctament abans de tornar-la a intentar.

Nota: Fins i tot els errors que es poden reintentar necessiten límits. Estableix un temps d’espera per a cada crida a eines, limita el nombre de reintents i el temps total de reintents, i imposa un termini global per al flux de treball perquè els agents imbricats no puguin continuar reiniciant la mateixa operació. Si una dependència falla repetidament, fes servir un interruptor de circuit (circuit breaker) per aturar temporalment les sol·licituds.

Per a les operacions amb efectes secundaris externs, assigna una clau d’idempotència estable a cada acció lògica i reutilitza-la en tots els reintents. Si l’API admet la deduplicació al costat del servidor, pot reconèixer les sol·licituds repetides sense executar l’acció dues vegades. Si no l’admet, consulta el sistema extern amb un identificador de correlació o una altra referència fidedigna.

Quan no puguis determinar què ha passat, atura’t i escala el problema.

Un exemple de la lògica de reintents del nostre agent de CI, expressat en pseudocodi:

Nota sobre el codi: L’exemple suposa que l’API de CI permet cercar execucions per ID de sol·licitud. El request_id només evita duplicats si el proveïdor garanteix explícitament la idempotència. bounded_retry() és pseudocodi il·lustratiu. En producció, els reintents s’haurien de limitar tant amb un pressupost de reintents per operació (nombre màxim d’intents o temps transcorregut) com amb el termini global del flux de treball.

Per a fluxos de treball més llargs que abasten diversos serveis, considera el patró Saga per coordinar accions compensatòries quan fallen passos posteriors. Recorda, però, que la compensació no sempre és una reversió completa. Pots revertir una actualització d’una base de dades, però no pots anul·lar l’enviament d’un correu electrònic.

5. Encamina i paral·lelitza la feina amb pressupostos de recursos explícits

Aquí cal equilibrar dues coses: quanta capacitat de model necessita cada tasca i quantes tasques pots executar simultàniament. Si t’equivoques en qualsevol de les dues, corres el risc que els agents competeixin per quotes d’API compartides o que depenguin només de models de raonament cars.

Per a la selecció de models, ajusta la capacitat del model i l’esforç de raonament a la complexitat de la tasca: és senzill, però sovint es passa per alt. Tingues en compte que pots configurar regles d’encaminament i avaluar els models tu mateix, o bé fer servir una plataforma d’orquestració que s’encarregui de seleccionar el model per tu.

Per exemple, el mode d’esforç de Perplexity Computer et permet triar quant d’esforç mereix una tasca sense haver de seleccionar un model manualment. Tria Light, Standard, High o Ultra, i Perplexity selecciona automàticament el model orquestrador i el seu nivell de raonament. Després, aquest orquestrador delega subtasques a agents de suport, que poden fer servir models de diferents proveïdors.

Perplexity avalua les configuracions dels models en termes de qualitat i cost, i prioritza les opcions més econòmiques que ofereixen resultats comparables. També pots fer servir els controls personalitzats (Custom) si prefereixes triar tu mateix el model i el nivell de raonament.

Pel que fa al paral·lelisme, el límit l’han de determinar la teva infraestructura i les dependències externes. Valida els límits de freqüència de sol·licituds i de tokens de les API compartides i, després, fes proves de càrrega del flux de treball amb una concurrència creixent. Observa si el rendiment millora o si les sol·licituds comencen a quedar-se a la cua, a alentir-se o a retornar errors 429.

Perquè el consum de recursos sigui previsible, imposa límits de recursos i controls de planificació:

• Controla la concurrència i la freqüència de sol·licituds: Limita les crides en curs per servei i posa a la cua la feina excedent. Recorda que un límit de concurrència per si sol no imposa límits de sol·licituds per minut ni de tokens per minut.
• Fes el seguiment dels pressupostos de tokens i de cost: Tingues en compte l’ús en tot el flux de treball, inclosos els subagents, i deixa d’iniciar feina nova quan el pressupost restant sigui insuficient.
• Imposa terminis d’execució: Estableix límits de temps per a les tasques i el flux de treball, i propaga la cancel·lació als agents en execució quan sigui possible.
• Respecta les dependències: Inicia les tasques posteriors només quan les entrades que necessiten estiguin disponibles, en lloc d’iniciar tots els agents alhora.

6. Imposa aprovacions i aïlla l’execució dels agents

No demanis mai al model que decideixi si les seves pròpies accions són segures. En lloc d’això, dona als agents permisos de mínim privilegi i aplica regles d’aprovació basades en el risc al codi de l’aplicació. Si els agents executen codi, aïlla aquesta execució del teu entorn amfitrió i restringeix l’accés a fitxers, xarxes i credencials. Això limita els danys si l’agent s’equivoca o executa codi no segur.

«Soc escèptic amb els sistemes multiagent massa complicats, sobretot quan els agents revisen i aproven la feina els uns dels altres. Pots acabar amb diversos agents que es passen amb tota confiança el mateix error sense que ningú el detecti realment», adverteix Spilker.

Amplia

Per a les accions que requereixen aprovació humana, posa en pausa l’execució i desa l’operació proposada exacta:

• els seus paràmetres
• el seu recurs de destinació
• la seva versió de commit o d’estat
• la decisió del revisor

A més, defineix què passa si l’aprovació es rebutja, caduca o s’ha d’escalar. Això és essencial per als frameworks que permeten reprendre l’execució, ja que, en reprendre un node interromput, el codi es torna a executar des del principi d’aquest node. Qualsevol efecte secundari anterior a la interrupció es pot tornar a executar.

Per tant, si l’aprovació es rebutja o caduca, la sol·licitud es tanca. Si el commit de destinació, els paràmetres o els permisos canvien abans de l’execució, invalida l’aprovació i sol·licita’n una de nova.

Spilker tampoc no comparteix la idea que l’objectiu hagin de ser agents totalment autònoms i d’extrem a extrem. «Per a mi, el millor enfocament és crear uns quants agents especialitzats amb responsabilitats clares, permisos definits i revisió humana en els moments adequats. Continues guanyant eficiència sense renunciar al control total», conclou.

7. Verifica els resultats de manera independent i prova el comportament de recuperació

Alguna vegada un agent t’ha retornat Success quan en realitat havia fallat? És molest, per no dir exasperant, i la solució no és ràpida perquè el missatge final de l’agent no et dirà necessàriament on han anat malament les coses.

Per investigar-ho, traça què ha passat durant l’execució i verifica els resultats de manera independent. Així doncs, dediquem una mica de temps a aïllar i resoldre el problema.

Traça el flux de treball per identificar què ha fallat

Abans de depurar les indicacions d’un agent, captura tot el camí d’execució. Necessites una traça que connecti les invocacions d’agents, les crides a eines, els errors i els reintents dins de la mateixa execució del flux de treball.

Les convencions semàntiques de GenAI d’OpenTelemetry proporcionen una manera estandarditzada de descriure aquestes operacions. Per exemple, invoke_workflow identifica l’execució d’un flux de treball; invoke_agent, la invocació d’un agent, i execute_tool, una crida a una eina. Cada operació es pot registrar com un span amb el seu temps, el seu estat i les metadades rellevants.

Aquest pas et proporciona una traça del camí d’execució, de manera que pots identificar on ha ensopegat un agent.

Una traça d’execució il·lustrativa.

Revisa el resultat de manera independent

Fes servir comprovacions programàtiques sempre que sigui possible. Valida els resultats amb esquemes JSON, executa proves unitàries i d’integració, comprova que existeixen els artefactes necessaris i consulta els sistemes externs per confirmar que les accions s’han completat realment.

Per als resultats que requereixen un judici subjectiu —i que, per tant, no es poden avaluar mitjançant comprovacions programàtiques—, introdueix un agent revisor independent. Un enfocament possible és un bucle implementador–revisor–resolutor, en què un agent produeix un artefacte, un revisor amb un context nou identifica problemes i un resolutor els corregeix abans que la validació es torni a executar.

Tot i així, has de validar les conclusions del revisor sempre que sigui possible i, si fas servir avaluadors basats en LLM per a avaluacions repetides, calibra’n els judicis amb exemples revisats per persones.

Injecta errors per provar la recuperació

Fins ara, has rastrejat què han executat els agents i has comprovat si els seus resultats eren correctes. Però què passa quan un worker falla a mig fer una tasca o quan una API esgota el temps d’espera després d’acceptar una sol·licitud? Sorprenentment, el teu flux de treball pot funcionar perfectament en condicions normals però fallar durant la recuperació.

Per provar-ho, injecta errors deliberadament en un entorn de proves:

• Simula esgotaments del temps d’espera de l’API
• Fes fallar els workers entre les escriptures externes i els punts de control
• Retorna sortides d’eines mal formades
• Fes caducar les aprovacions

Després de cada prova, inspecciona la traça d’execució per veure quins passos s’han executat, on s’ha reprès el flux de treball i si alguna acció s’ha repetit o s’ha omès. Després, revisa els resultats reals.

Suposem que el teu agent de CI envia una sol·licitud per iniciar una execució de proves, però la resposta de l’API esgota el temps d’espera. L’agent torna a intentar-ho, rep una resposta correcta i informa d’Èxit. Tot sembla correcte fins que comproves el servei de CI i descobreixes que s’han creat dues execucions de proves en lloc d’una.

Per això has de verificar tant l’estat registrat del flux de treball com els canvis reals en els sistemes externs. Una prova de recuperació només s’hauria de superar quan el flux de treball arriba a l’estat esperat sense efectes secundaris no desitjats.

Afegeix els errors que descobreixis a les teves proves de regressió perquè els canvis futurs no els tornin a introduir.

En definitiva, l’èxit vol dir que el flux de treball ha superat les comprovacions requerides i que se n’han verificat els resultats externs.

Preguntes freqüents sobre l’orquestració d’agents d’IA

Per què els agents d’IA aïllats fallen a escala empresarial?

Els agents aïllats poden completar correctament les seves tasques individuals, però produir resultats incoherents en conjunt. Imagina un agent de vendes que obté les condicions d’un client a les 10:00, un agent de preus que calcula un pressupost amb preus actualitzats a les 10:05 i un agent jurídic que revisa un contracte que ha canviat a les 10:07. Cada agent treballa amb una instantània diferent del negoci, de manera que els seus resultats es poden contradir entre si.

El problema s’accentua a escala empresarial perquè els agents interactuen amb diversos sistemes que s’actualitzen de manera independent, funcionen amb permisos diferents i no necessàriament comparteixen el context ni l’estat d’execució.

Com s’eviten els bucles infinits de reintents en els agents d’IA?

Estableix límits a diversos nivells: un màxim de reintents de crides a eines, un màxim d’iteracions de l’agent, una profunditat de delegació i un termini global per al flux de treball. Classifica els errors abans de tornar-ho a intentar. Per a les respostes 429 transitòries, respecta Retry-After quan s’indiqui. Si no, utilitza un retrocés exponencial limitat amb jitter.

Deixa de reintentar sol·licituds sense canvis després d’errors de validació o de permisos. Si un servei posterior falla repetidament, un interruptor de circuit (circuit breaker) pot evitar que els agents generin més càrrega.

Com es reprèn un flux de treball d’agents d’IA després d’una fallada?

El mecanisme de recuperació depèn del teu entorn d’execució. Amb LangGraph, un checkpointer persistent com PostgresSaver desa l’estat del graf associat a un thread_id, cosa que permet continuar l’execució a partir de l’estat persistit. Amb Temporal, un altre worker pot reconstruir un flux de treball reproduint-ne l’historial d’esdeveniments. Durant la reproducció, reutilitza els resultats de les activitats registrats prèviament.

Si l’aplicació es torna a desplegar mentre encara hi ha fluxos de treball en execució, és possible que l’estat desat i els historials d’execució deixin de ser compatibles. Temporal ho resol amb Worker Versioning i l’aplicació de pegats als fluxos de treball. En els sistemes basats en punts de control, planifica les migracions d’esquema i prova la recuperació amb els estats desats existents abans de desplegar canvis incompatibles.

Com es prova la fiabilitat de l’orquestració d’agents d’IA?

Executa les mateixes tasques representatives diverses vegades i distingeix pass@k (si almenys un dels k intents té èxit) de pass^k (si tots els k intents tenen èxit)

Mesura els resultats per categoria de tasca i versió del flux de treball en lloc de basar-te en una única taxa d’èxit agregada. Fes el seguiment de l’èxit al primer intent, la coherència entre execucions repetides, la latència p95, el cost per tasca completada i la proporció que requereix intervenció humana. Indica les mides de les mostres i els intervals d’incertesa de les taxes d’èxit.