Orkestrering av AI-agenter: feil, godkjenninger og nye forsøk

Å ha flere agenter som jobber på samme prosjekt, høres ekstremt effektivt ut. Én planlegger arbeidet, en annen tar seg av designet, og en tredje skriver koden. Det fungerer – helt til det ikke gjør det. Og feil skjer oftere enn du skulle ønske.

For å forhindre slike feil kreves nøye utforming av arbeidsflyten. Så la oss se nærmere på hva som gjør orkestrerte arbeidsflyter upålitelige, og utforske beste praksis for orkestrering som gir pålitelighet i produksjon.

Orkestrering av AI-agenter koordinerer flere AI-agenter, modeller og verktøy for å fullføre en oppgave med flere trinn. Men noen – eller noe – må fortsatt bestemme hvilken agent som kjører først, hvilken informasjon den får, og hva som skjer når den er ferdig. Dette er rollen til orkestratoren – en AI-agent som fungerer som leder, eller et programvarestyrt utførelseslag.

Enkelt sagt deler et orkestreringslag et mål opp i mindre oppgaver, holder oversikt over avhengigheter, delegerer utførelsen til de riktige agentene, administrerer delt kontekst og samler resultatene.

Diagram over orkestreringens utførelsesmotor: mål og plan, ruting til agenter, isolert utførelse av verktøy, strukturerte resultater, vedvarende arbeidsflyttilstand og et validerings- og beslutningstrinn som prøver på nytt, går tilbake, setter på pause, venter eller går videre til neste oppgave.

La oss se på hva som skjer etter at du har gitt en orkestrator en oppgave.

Ta et eksempel fra Perplexitys Computer-workshop: å bygge et dashbord for kundeinnsikt med informasjon fra Salesforce, Snowflake, e-post, kalender og ferske nyheter.

Forstå målet og planlegg arbeidet. Orkestratoren tar utgangspunkt i det ønskede resultatet og deler det opp i oppgaver med eksplisitte avhengigheter. I dashbordeksempelet vårt innebærer det å samle inn informasjon fra ulike kilder og gjøre den om til en ferdig leveranse. Planleggeren fastslår hvilke trinn som avhenger av andre, og hvilke som kan kjøre uavhengig.
Send oppgaver til de riktige agentene. Orkestratoren identifiserer oppgaver der avhengighetene er oppfylt, og delegerer arbeid til spesialiserte agenter eller modeller. Avhengige oppgaver venter på forutsetningene sine. Perplexity Computer bruker flere ledende frontier-modeller og ruter ulike deler av arbeidsflyten til systemer som egner seg for disse oppgavene. Dette gjør det også mulig å kjøre uavhengig arbeid parallelt.
Utfør verktøykall i kontrollerte miljøer. Agenter samhandler med miljøet sitt gjennom verktøy, for eksempel nettsøk, API-er, tilkoblede applikasjoner, filoperasjoner eller kodekjøring. Utførelseslaget kjører disse handlingene og returnerer resultatene til agentene.
Send resultater og kontekst mellom agenter. Når en agent er ferdig med oppgaven sin, trenger neste agent i kjeden de relevante resultatene for å fortsette. En overleveringspost kan inneholde en oppgave-ID, en resultatreferanse, en skjemaversjon og kildemetadata. Orkestratoren koordinerer disse overleveringene og opprettholder samtidig konteksten som trengs for de påfølgende trinnene. Det er viktig at agentene ikke trenger å bære med seg hele historikken over alle de andre agentenes arbeid i sine egne kontekstvinduer.
Registrer utførelsestilstanden separat fra agentkonteksten. Etter hvert som agenter starter, fullfører eller mislykkes med oppgaver, oppdaterer utførelsesmotoren en vedvarende arbeidsflytpost med oppgavestatuser, utførelsesforsøk, resultatreferanser og gjenværende arbeid. Denne posten lar orkestratoren følge fremdriften og gjenoppta arbeidet etter avbrudd uten å være avhengig av at en LLM rekonstruerer arbeidsflyten fra samtalehistorikken.
Valider resultatene og bestem hva som skal skje videre. Når en oppgave returnerer, kontrollerer orkestreringslaget om resultatet oppfyller den forventede kontrakten, og om avhengighetene for neste oppgave er oppfylt. Hvis det oppdages et problem, kan arbeidsflyten gå tilbake til et tidligere trinn for korrigering eller settes på pause. Ellers fortsetter den mot fullføring.

Det er mange bevegelige deler bak det som ser ut som enkel orkestrering av AI-agenter. Hvordan du organiserer koordineringen av agenter, avgjør hvor mye kontroll du har over utførelsen. Og all denne koordineringen medfører selvfølgelig ekstra belastning. Derfor er det ikke alltid verdt det.

Vurder orkestrering med flere agenter når ulike deler av oppgaven krever forskjellig ekspertise, uavhengig arbeid kan kjøres parallelt, eller du ikke kan fastslå neste trinn på forhånd.

Orkestrering er derfor nyttig i tre scenarioer:

Oppgavene krever ulike spesialiseringer. Et kodeprosjekt kan for eksempel ha nytte av separate agenter for planlegging, design, utvikling og gjennomgang.
Uavhengige oppgaver kan kjøres parallelt. I stedet for at én agent gjør alt sekvensielt, kan flere agenter jobbe samtidig og returnere resultatene sine til en orkestrator.
Problemet er åpent. Agentene kan måtte utforske ulike tilnærminger, ta beslutninger og samarbeide i stedet for å følge en forhåndsdefinert rekkefølge.

Utover dette er orkestrering bare en kostbar trend. Flere agenter betyr også mer koordinering og potensielt høyere tokenkostnader.

«Jeg starter vanligvis med det enkleste alternativet og bygger videre derfra. Hvis vi kjenner trinnene og de kan gjentas, er det sannsynligvis en arbeidsflyt. Jeg ser bare grunn til å innføre flere agenter når de har ulike ansvarsområder, tillatelser eller brukere», sier Josh Spilker, leder for søkemarkedsføring i AirOps.

Selv da bør du veie fordelene opp mot ekstra modellkall, overleveringer, forsinkelse og feilpunkter.

Tre vanlige måter å strukturere koordinering av agenter på – sentralisert, desentralisert og hierarkisk orkestrering. Valget av riktig arkitektur koker ned til ett spørsmål: Hvem kontrollerer arbeidet, og hvordan koordinerer agentene seg med hverandre?

Ved sentralisert orkestrering styrer én orkestrator prosessen. Den deler opp oppgaven, delegerer arbeid til spesialistagenter, følger med på fremdriften deres og samler resultatene.

Diagram over sentralisert orkestrering: én orkestrator mottar brukerforespørselen og delegerer til agenter for research, analyse og design, som hver bruker sine egne verktøy, og resultatene deres kombineres til et endelig dashbord.

Avveiningen: Sentralisert koordinering gjør det enklere å følge utførelsen og bruke felles regler på ett enkelt kontrollpunkt. Orkestratoren kan imidlertid bli en flaskehals, og feil i den kan avbryte hele arbeidsflyten med mindre systemet støtter gjenoppretting.

Ved desentralisert orkestrering koordinerer agentene mer direkte i stedet for å være avhengige av én leder som tar alle beslutninger. De kan utveksle meldinger, lese delt tilstand og selvstendig bestemme sine neste trinn.

Diagram over desentralisert orkestrering: agenter for research, analyse, design og gjennomgang kommuniserer direkte med hverandre og med delt tilstand og verktøy for å lage et endelig dashbord.

Avveiningen: Agentene kan operere uten å vente på en sentral planlegger, noe som gjør denne tilnærmingen nyttig for utforskende arbeid og uavhengige bidrag. Men koordineringen blir vanskeligere når agentene er uenige, oppdaterer delt informasjon eller må komme frem til et konsistent resultat.

Hierarkisk orkestrering utvider lederprinsippet over flere nivåer. En orkestrator på toppnivå delegerer ansvar til underordnede orkestratorer, som koordinerer sine egne grupper av spesialistagenter.

Tenk deg en arbeidsflyt i en større virksomhet som involverer salgs-, økonomi- og juristteam. En orkestrator på toppnivå kan delegere hver arbeidsstrøm til en domenespesifikk koordinator. Disse koordinatorene vil deretter styre sine egne spesialistagenter og rapportere samlede resultater.

Denne strukturen kan være nyttig når arbeidsflyter er for omfattende til at én orkestrator kan styre dem effektivt.

Diagram over hierarkisk orkestrering: en orkestrator på toppnivå delegerer til orkestratorer for salg, økonomi og juss, som hver styrer to spesialistagenter, og arbeidet deres kombineres til et samlet resultat.

Avveiningen: Hierarkier lar team fordele koordineringsansvaret og potensielt håndtere feil innenfor enkeltgrener. De medfører imidlertid flere overleveringer, mer kompleks tilstandshåndtering og større driftsmessig overhead. Lokal gjenoppretting avhenger også av hvordan sjekkpunkter og utførelsestilstand er implementert.

Slik sammenlignes disse arkitekturene:

Kriterier	Sentralisert	Desentralisert	Hierarkisk
Eierskap til utførelsen	Én orkestrator styrer delegeringen	Agentene koordinerer via likeverdige agenter eller delt tilstand	Ansvaret er fordelt på flere orkestreringsnivåer
Tilstandskonsistens	Enklere å koordinere via ett kontrollpunkt	Krever eksplisitt synkronisering og konflikthåndtering	Krever koordinering innenfor og på tvers av grener
Feilisolering	Den sentrale kontrolleren kan bli en kritisk avhengighet	Enkeltagenter kan feile uavhengig av hverandre, men delt infrastruktur er fortsatt kritisk	Feil kan isoleres innenfor grener hvis systemet er utformet for gjenoppretting
Håndheving av retningslinjer	Felles kontroller kan håndheves sentralt	Retningslinjer må håndheves konsekvent på tvers av deltakerne	Kontroller kan brukes på globalt nivå og domenenivå
Driftskompleksitet	Generelt lavere	Høyere koordineringskompleksitet	Høyere kompleksitet på grunn av flere orkestreringslag

Det er ett skille til som er verdt å forstå. Arkitekturen avgjør hvem som koordinerer agentene. Utførelsesmønsteret avgjør hvordan oppgavene deres utvikler seg.

Dette er tre utførelsesmønstre:

Sekvensielle arbeidsflyter: Agentene jobber i en forhåndsdefinert rekkefølge, der resultatet fra én agent blir input til en annen.
Parallell utførelse: Uavhengige agenter jobber samtidig.
Overleveringsbasert utførelse: Kontrollen flyttes mellom spesialistagenter etter hvert som oppgaven skrider frem. Dette er nyttig når en annen agent er bedre rustet til å håndtere neste steg, men hver overlevering må bevare informasjonen som trengs for å fortsette.

Mønstrene utelukker ikke hverandre, og de samsvarer ikke én-til-én med orkestreringsarkitekturer. Målet er å velge den enkleste strukturen som støtter arbeidsflytens avhengigheter, koordineringskrav og akseptabel driftsmessig overhead.

Alt kan gå galt med orkestrering, fra enkle forglemmelser til innviklede hindringer. Noen ganger kan en agent til og med se ut til å gjøre jobben sin riktig mens arbeidsflyten som helhet feiler. Basert på erfaringer fra fagfolk har vi samlet noen av de vanligste feilene bak upålitelige orkestrerte arbeidsflyter – hold øye med dem:

Overleveringer med informasjonstap. En orkestrator sender en oppsummert plan til en spesialistagent, men oppsummeringen utelater begrensninger, avhengigheter eller implementeringsdetaljer.
For tidlig fan-in-utførelse. En nedstrøms agent begynner å aggregere resultater før alle oppstrøms oppgaver er fullført.
Ikke-deterministiske oppdateringer av delt tilstand. Parallelle agenter skriver til de samme tilstandsnøklene uten veldefinert flettesemantikk. Avhengig av hvordan rammeverket håndterer oppdateringer, kan dette føre til tapte skrivinger, dupliserte data, rekkefølgeavhengig output eller motstridende endringer.
Avvik mellom sjekkpunkter og sideeffekter. En oppgave utfører en ekstern operasjon, men den vellykkede utførelsen blir ikke lagret varig før arbeidsprosessen feiler. Ved gjenoppretting ser orkestratoren en uferdig oppgave og kjører den på nytt.
Kappløpssituasjoner ved gjenopptakelse etter menneskelig godkjenning. Når utførelsen settes på pause og gjenopptas, oppstår det egne synkroniseringsproblemer.
Delegeringssløyfer og forsterkning av nye forsøk. Agenter sender gjentatte ganger arbeid til hverandre fordi ansvarsområdene deres overlapper, avhengighetene er sirkulære eller fullføringsbetingelsene er tvetydige.
Kontroller på instruksjonsnivå forvekslet med sikkerhet i utførelsen. En orkestrator kan be agenter om ikke å få tilgang til bestemte ressurser eller utføre sensitive handlinger, men modellinstruksjoner håndhever ikke operativsystemtillatelser, nettverksbegrensninger eller autorisasjonsgrenser. Perplexitys forskning på sikkerhetsteknikk viser hvorfor agenter kan krysse sikkerhetsgrenser mens de forfølger legitime mål, selv uten ondsinnede instruksjoner

Legg merke til hvor forskjellige disse feilene er. Både en for tidlig overgang i planleggeren og en tvetydig ekstern skriving kan gi feil resultat, men de har opphav i ulike deler av utførelsens livssyklus. Derfor krever pålitelig orkestrering mer enn å forbedre prompter eller legge til nye forsøk.

Vage mål og en uklar definisjon av ferdig fører ofte til skuffende agentgenererte resultater. Løsningen er en prompt-kontrakt (en arbeidsbeskrivelse for en agent): Bli enige om mål, begrensninger, outputformat og feilbetingelser før utførelsen starter.

Her er for eksempel hvordan du kan definere en kontrakt for en agent som skal fikse en integrasjonstest som feiler sporadisk:

Mål: Finn og fiks årsaken til en ustabil integrasjonstest for checkout-API-et.
Input: Testens kildekode, CI-feillogger, nylige commits og relevant applikasjonskode.
Begrensninger: Ikke deaktiver tester, svekk assertions eller endre urelatert applikasjonsatferd.
Forventet output: En kodepatch, en forklaring av rotårsaken og resultater fra testkjøringen.
Akseptansekriterier: Testen som tidligere feilet, består 10 påfølgende kjøringer, og den relevante regresjonstestpakken består.
Feilbetingelser: Rotårsaken kan ikke fastslås, rettelsen introduserer regresjoner, eller det nødvendige testmiljøet er utilgjengelig.

Men det er en annen viktig del: Når bør agenten stoppe?

En agent bør ikke fortsette å iterere i det uendelige fordi den ikke har gitt et tilfredsstillende resultat. Definer hva som utgjør vellykket fullføring, når en delvis fullført oppgave skal returneres, og når agenten skal stoppe fordi et krav ikke kan oppfylles. Angi maksimal delegeringsdybde og iterasjonsgrenser eller utførelsesbudsjetter, slik at uløste oppgaver ikke blir endeløse sløyfer.

Tilbake til CI-eksempelet vårt. Du kan definere følgende stoppbetingelser:

Suksess: Rettelsen består 10 påfølgende testkjøringer og den relevante regresjonstestpakken.
Iterasjonsgrense: Agenten kan prøve maksimalt to mulige rettelser.
Utførelsesbudsjett: Agenten må stoppe etter 60 minutter, selv om problemet fortsatt ikke er løst.
Delegeringsgrense: Agenten kan delegere arbeid til én spesialistagent, uten ytterligere delegering til underagenter.
Delvis fullføring: Hvis begge forsøkene mislykkes eller tidsgrensen utløper, returnerer agenten funnene sine, endringene den har forsøkt og testresultatene.
Blokkert utførelse: Hvis testmiljøet er utilgjengelig, stopper agenten og rapporterer hindringen i stedet for å hevde at den har lyktes.

Noen ganger gir utviklere en orkestrator for mange ansvarsområder, og i stedet for å koordinere spesialistagenter begynner den å skrive kode, feilsøke eller utføre detaljerte gjennomganger selv. Dette skaper en flaskehals: Orkestratoren bruker kontekstbudsjettet sitt på implementeringsdetaljer, forsinker delegering og gjør ansvaret for resultatene uklart.

Så la orkestratorene gjøre jobben sin, og håndhev overleveringer ved å henvise til konkrete artefakter: den opprinnelige oppgaven, relevante input, output-artefakter, utførelsesstatus og eventuelle uløste problemer.

Se på dette eksempelet: status: completed viser til agentens tildelte arbeid, ikke hele arbeidsflyten. Siden testene fortsatt er pending, bør ikke orkestratoren godkjenne det endelige resultatet.

json

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

En agents samtalehistorikk er ikke en pålitelig oversikt over fremdriften i arbeidsflyten. Når kontekstvinduet blir fullt, kan automatisk komprimering fjerne viktige detaljer. Og hvis en arbeidsprosess krasjer, må neste agent vite hvilke steg som faktisk ble fullført.

Hvis for eksempel kodeagenten genererer en patch og så krasjer, bør neste arbeidsprosess hente den lagrede artefakten og fortsette fra den registrerte arbeidsflyttilstanden. Men hvis agenten også startet en ekstern CI-kjøring, må orkestratoren avstemme den kjøringen separat før handlingen gjentas

Hold derfor utførelsestilstanden atskilt fra agentens arbeidskontekst. Lagre oppgavestatuser, utførelsesforsøk, fullførte steg og artefaktreferanser i varig lagring. Last samtidig bare inn instruksjonene, inputene og resultatene som er relevante for agentens nåværende oppgave, i stedet for å fylle hele utførelseshistorikken inn i kontekstvinduet.

La oss si at CI-agenten din starter en testkjøring, men API-forespørselen får tidsavbrudd. Klarte ikke testkjøringen å starte, eller satte CI-tjenesten den i kø og mistet svaret?

Et tidsavbrudd betyr ikke nødvendigvis at en operasjon mislyktes. Derfor må du skille mellom feiltyper før du bestemmer hva som skal skje videre:

Forbigående feil (429, 503): Prøv på nytt med begrenset eksponentiell backoff og jitter, og respekter Retry-After når den er oppgitt.
Validerings- eller tillatelsesfeil (400, 403): Stopp eller rett det underliggende problemet i stedet for å gjenta den samme forespørselen.
Tvetydige utfall (tidsavbrudd etter en mulig skriving): Undersøk om operasjonen lyktes før du prøver den på nytt.

Merk: Selv feil som kan prøves på nytt, trenger grenser. Angi et tidsavbrudd for hvert verktøykall, begrens antall nye forsøk og den totale tiden for nye forsøk, og håndhev en overordnet tidsfrist for arbeidsflyten, slik at nestede agenter ikke kan fortsette å starte den samme operasjonen på nytt. Hvis en avhengighet feiler gjentatte ganger, bruker du en circuit breaker for å stoppe forespørsler midlertidig.

For operasjoner med eksterne sideeffekter tildeler du en stabil idempotensnøkkel til hver logiske handling og gjenbruker den på tvers av nye forsøk. Hvis API-et støtter deduplisering på serversiden, kan det gjenkjenne gjentatte forespørsler uten å utføre handlingen to ganger. Hvis ikke, spør du det eksterne systemet ved hjelp av en korrelasjons-ID eller en annen autoritativ referanse.

Når du ikke kan fastslå hva som skjedde, bør du stoppe og eskalere.

Et eksempel på logikken for nye forsøk for CI-agenten vår, uttrykt som pseudokode:

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)

Merknad om koden: Eksempelet forutsetter at CI-API-et støtter oppslag av kjøringer etter forespørsels-ID. request_id forhindrer bare duplikater hvis leverandøren eksplisitt garanterer idempotens. bounded_retry() er illustrerende pseudokode. I produksjon bør nye forsøk begrenses både av et budsjett for nye forsøk per operasjon (maksimalt antall forsøk eller medgått tid) og av den overordnede tidsfristen for arbeidsflyten.

For lengre arbeidsflyter som spenner over flere tjenester, kan du vurdere Saga-mønsteret for å koordinere kompenserende handlinger når senere steg feiler. Bare husk at kompensasjon ikke alltid er en fullstendig tilbakerulling. Du kan reversere en databaseoppdatering, men du kan ikke angre sendingen av en e-post.

Det er to ting som må balanseres her: hvor mye modellkapasitet hver oppgave trenger, og hvor mange oppgaver du kan kjøre samtidig. Tar du feil på ett av punktene, risikerer du at agenter konkurrerer om delte API-kvoter eller bare bruker dyre resonneringsmodeller.

Når det gjelder modellvalg, bør du tilpasse modellkapasitet og resonneringsinnsats til oppgavens kompleksitet – enkelt, men ofte oversett. Merk at du enten kan konfigurere rutingsregler og evaluere modeller selv, eller bruke en orkestreringsplattform som håndterer modellvalget for deg.

For eksempel lar Effort Mode i Perplexity Computer deg velge hvor mye innsats en oppgave fortjener, uten at du må velge modell manuelt. Velg Light, Standard, High eller Ultra, så velger Perplexity automatisk orkestreringsmodellen og resonneringsnivået. Orkestratoren delegerer deretter deloppgaver til støtteagenter, som kan bruke modeller fra ulike leverandører.

Perplexity evaluerer modellkonfigurasjoner med tanke på kvalitet og kostnad, og foretrekker rimeligere alternativer som gir sammenlignbare resultater. Du kan også bruke Custom-kontrollene hvis du foretrekker å velge modell og resonneringsnivå selv.

Når det gjelder parallellitet, bør grensen styres av infrastrukturen og de eksterne avhengighetene dine. Valider forespørsels- og tokengrensene for delte API-er, og belastningstest deretter arbeidsflyten med økende samtidighet. Følg med på om gjennomstrømningen øker, eller om forespørsler begynner å havne i kø, gå tregere eller returnere 429-feil.

For å holde ressursforbruket forutsigbart bør du håndheve ressursgrenser og planleggingskontroller:

Kontroller samtidighet og forespørselsrater: Begrens antall pågående kall per tjeneste, og sett overskytende arbeid i kø. Husk at en samtidighetsgrense alene ikke håndhever grenser for forespørsler per minutt eller tokener per minutt.
Spor token- og kostnadsbudsjetter: Ta hensyn til forbruket i hele arbeidsflyten, inkludert underagenter, og slutt å starte nytt arbeid når det gjenværende budsjettet ikke strekker til.
Håndhev tidsfrister for utførelse: Angi tidsgrenser for oppgaver og arbeidsflyter, og videreformidle avbrudd til agenter som kjører, der det støttes.
Respekter avhengigheter: Start nedstrøms oppgaver først når de nødvendige inputene er tilgjengelige, i stedet for å starte alle agentene samtidig.

Be aldri modellen avgjøre om dens egne handlinger er trygge. Gi i stedet agentene tillatelser etter prinsippet om minste privilegium, og håndhev risikobaserte godkjenningsregler i applikasjonskoden. Hvis agenter kjører kode, må du isolere kjøringen fra vertsmiljøet ditt og begrense tilgangen til filer, nettverk og legitimasjon. Dette begrenser skaden hvis agenten gjør en feil eller kjører usikker kode.

«Jeg er skeptisk til altfor kompliserte multiagentsystemer, spesielt når agenter gjennomgår og godkjenner hverandres arbeid. Du kan ende opp med at flere agenter selvsikkert sender den samme feilen videre, uten at noen faktisk oppdager den», advarer Spilker.

Diagram over en godkjenningsflyt: En agent foreslår en operasjon med parametere, målressurs og tilstandsversjon; et menneske godkjenner eller avviser den; godkjente operasjoner valideres på nytt og kjøres i et isolert miljø med begrenset tilgang til filer, nettverk og legitimasjon. Avviste eller utløpte forespørsler lukkes, og endrede forespørsler krever ny godkjenning.

For handlinger som krever menneskelig godkjenning, setter du utførelsen på pause og lagrer nøyaktig den foreslåtte operasjonen:

parameterne
målressursen
commiten eller tilstandsversjonen
kontrollørens beslutning

Definer også hva som skjer hvis godkjenningen avvises, utløper eller må eskaleres. Dette er avgjørende for rammeverk som kan gjenopptas, ettersom gjenopptakelse av en avbrutt node kjører koden på nytt fra begynnelsen av noden. Eventuelle sideeffekter før avbruddet kan kjøres på nytt.

Så hvis godkjenningen avvises eller utløper, lukkes forespørselen. Hvis målcommiten, parameterne eller tillatelsene endres før utførelsen, må du ugyldiggjøre godkjenningen og be om en ny.

Spilker støtter heller ikke ideen om at helt autonome ende-til-ende-agenter skal være målet. «For meg er den beste tilnærmingen å bygge noen få fokuserte agenter med tydelige ansvarsområder, definerte tillatelser og menneskelig gjennomgang på de riktige punktene. Du får fortsatt effektivitet uten å gi fra deg full kontroll», konkluderer han.

Har du noen gang hatt en agent som rapporterte Success når den egentlig hadde mislyktes? Irriterende, for ikke å si frustrerende, og det er ikke gjort i en håndvending å fikse det, fordi agentens siste melding ikke nødvendigvis forteller deg hvor det gikk galt.

For å undersøke dette må du spore hva som skjedde under utførelsen, og verifisere resultatene uavhengig. Så la oss bruke litt tid på å isolere og løse problemet.

Før du feilsøker en agents prompter, bør du registrere hele utførelsesbanen. Du trenger en sporing som kobler sammen agentkall, verktøykall, feil og nye forsøk under samme arbeidsflytkjøring.

OpenTelemetrys semantiske konvensjoner for GenAI gir en standardisert måte å beskrive disse operasjonene på. For eksempel identifiserer invoke_workflow utførelse av en arbeidsflyt, invoke_agent et agentkall og execute_tool et verktøykall. Hver operasjon kan registreres som et span med tidsbruk, status og relevante metadata.

Dette steget gir deg en sporing av utførelsesbanen, slik at du kan finne ut hvor en agent snublet.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

En illustrerende utførelsessporing.

Bruk programmatiske kontroller der det er mulig. Valider output mot JSON-skjemaer, kjør enhets- og integrasjonstester, kontroller at nødvendige artefakter finnes, og spør eksterne systemer for å bekrefte at handlingene faktisk lyktes.

For output som krever subjektiv vurdering – og som derfor ikke kan håndteres med programmatiske kontroller – bør du innføre en uavhengig kontrollagent. Én tilnærming er en implementerer–kontrollør–løser-sløyfe, der én agent produserer en artefakt, en kontrollør med ny kontekst identifiserer problemer, og en løser håndterer dem før valideringen kjøres på nytt.

Du må fortsatt validere funnene fra gjennomgangeren der det er mulig, og hvis du bruker LLM-baserte vurderere til gjentatte evalueringer, bør du kalibrere vurderingene deres mot eksempler som er gjennomgått av mennesker.

Så langt har du sporet hva agentene utførte, og sjekket om resultatene deres var riktige. Men hva skjer når en worker-prosess krasjer midt i en oppgave, eller et API får tidsavbrudd etter å ha akseptert en forespørsel? Overraskende nok kan arbeidsflyten din fungere helt fint under normale forhold, men feile under gjenoppretting.

For å teste dette bør du bevisst injisere feil i et testmiljø:

Simuler tidsavbrudd i API-er
Få worker-prosesser til å krasje mellom eksterne skriveoperasjoner og sjekkpunkter
Returner feilformaterte verktøyutdata
La godkjenninger utløpe

Etter hver test bør du inspisere kjøringssporet for å se hvilke trinn som ble kjørt, hvor arbeidsflyten ble gjenopptatt, og om noen handlinger ble gjentatt eller hoppet over. Gå deretter gjennom de faktiske resultatene.

La oss si at CI-agenten din sender en forespørsel om å starte en testkjøring, men API-svaret får tidsavbrudd. Agenten prøver på nytt, mottar et vellykket svar og rapporterer Success. Alt ser bra ut helt til du sjekker CI-tjenesten og oppdager at det ble opprettet to testkjøringer i stedet for én.

Derfor bør du verifisere både arbeidsflytens registrerte tilstand og de faktiske endringene i eksterne systemer. En gjenopprettingstest bør bare bestå når arbeidsflyten når forventet tilstand uten utilsiktede bivirkninger.

Legg til feil du avdekker i regresjonstestene dine, slik at fremtidige endringer ikke gjeninnfører dem.

Til syvende og sist betyr suksess at arbeidsflyten besto de påkrevde kontrollene, og at de eksterne utfallene ble verifisert.

Isolerte agenter kan utføre de individuelle oppgavene sine riktig, men likevel gi inkonsekvente resultater sammen. Tenk deg en salgsagent som henter kundevilkår kl. 10.00, en prisagent som beregner et tilbud med oppdaterte priser kl. 10.05, og en juridisk agent som sjekker en kontrakt som ble endret kl. 10.07. Hver agent jobber med et ulikt øyeblikksbilde av virksomheten, så resultatene deres kan motsi hverandre.

Problemet blir mer utpreget i bedriftsskala fordi agentene samhandler med flere systemer som oppdateres uavhengig av hverandre, opererer med ulike tillatelser og ikke nødvendigvis deler kontekst eller kjøringstilstand.

Sett grenser på flere nivåer: maksimalt antall nye forsøk for verktøykall, maksimalt antall agentiterasjoner, delegeringsdybde og en samlet tidsfrist for arbeidsflyten. Klassifiser feil før du prøver på nytt. For midlertidige 429-svar bør du respektere Retry-After når den er oppgitt. Ellers bruker du begrenset eksponentiell backoff med jitter.

Slutt å prøve uendrede forespørsler på nytt etter validerings- eller tillatelsesfeil. Hvis en nedstrøms tjeneste feiler gjentatte ganger, kan en circuit breaker hindre agentene i å generere ekstra belastning.

Gjenopprettingsmekanismen avhenger av kjøretidsmiljøet ditt. Med LangGraph lagrer en persistent checkpointer, for eksempel PostgresSaver, graftilstanden under en thread_id, slik at kjøringen kan fortsette fra den lagrede tilstanden. Med Temporal kan en annen worker-prosess rekonstruere en arbeidsflyt ved å spille av hendelseshistorikken på nytt. Under avspillingen gjenbrukes tidligere registrerte aktivitetsresultater.

Hvis applikasjonen distribueres på nytt mens arbeidsflyter fortsatt kjører, kan det hende at lagret tilstand og kjøringshistorikk ikke lenger er kompatible. Temporal løser dette med Worker Versioning og patching av arbeidsflyter. For sjekkpunktbaserte systemer bør du planlegge skjemamigreringer og teste gjenoppretting mot eksisterende lagrede tilstander før du ruller ut inkompatible endringer.

Kjør de samme representative oppgavene flere ganger, og skill mellom pass@k (om minst ett av k forsøk lykkes) og pass^k (om alle k forsøk lykkes)

Mål resultatene etter oppgavekategori og arbeidsflytversjon i stedet for å basere deg på én samlet suksessrate. Følg med på suksess ved første forsøk, konsistens på tvers av gjentatte kjøringer, p95-latens, kostnad per fullførte oppgave og andelen som krever menneskelig inngripen. Oppgi utvalgsstørrelser og usikkerhetsintervaller for suksessratene.

Hva er orkestrering av AI-agenter?

Slik fungerer orkestrering av AI-agenter: Inne i utførelsesmotoren

Når bør du bruke orkestrering av AI-agenter?

Arkitekturer for orkestrering av AI-agenter og deres avveininger

Sentralisert orkestrering

Desentralisert orkestrering

Hierarkisk orkestrering

Sekvensiell, parallell og overleveringsbasert utførelse

Vanlige feil ved orkestrering av AI-agenter

7 beste praksiser for orkestrering av AI-agenter for pålitelighet i produksjon

1. Definer eksplisitte oppgavekontrakter, akseptansekriterier og stoppbetingelser

2. Hold orkestratorene slanke og håndhev strukturerte overleveringer

3. Lagre arbeidsflytens tilstand varig og kontroller kontekstveksten

4. Utform feilbevisste nye forsøk og gjenopprettbar verktøyutførelse

5. Fordel og parallelliser arbeid med eksplisitte ressursbudsjetter

6. Håndhev godkjenninger og isoler agentutførelse

7. Verifiser output uavhengig og test gjenopprettingsatferden

Spor arbeidsflyten for å finne ut hva som gikk galt

Gjennomgå output uavhengig

Injiser feil for å teste gjenoppretting

Vanlige spørsmål om orkestrering av AI-agenter

Hvorfor bryter isolerte AI-agenter sammen i bedriftsskala?

Hvordan forhindrer du uendelige løkker med nye forsøk i AI-agenter?

Hvordan gjenopptar du en arbeidsflyt for AI-agenter etter et krasj?

Hvordan tester du påliteligheten til orkestrering av AI-agenter?