Orkestrering af AI-agenter: fejl, godkendelser og genforsøg

Det lyder ekstremt effektivt at have flere agenter til at arbejde på det samme projekt. Én planlægger arbejdet, en anden står for designet, og en tredje skriver koden. Det fungerer, indtil det ikke gør. Og fejl opstår oftere, end man skulle ønske.

At forebygge disse fejl kræver omhyggelig udformning af arbejdsprocesser. Så lad os se nærmere på, hvad der gør orkestrerede arbejdsprocesser upålidelige, og udforske bedste praksis for orkestrering, der giver pålidelighed i produktion.

Orkestrering af AI-agenter koordinerer flere AI-agenter, modeller og værktøjer for at udføre en opgave i flere trin. Men nogen – eller noget – skal stadig beslutte, hvilken agent der kører først, hvilke oplysninger den modtager, og hvad der sker, når den er færdig. Det er orkestratorens rolle – en AI-agent, der fungerer som leder, eller et softwarestyret udførelseslag.

Kort sagt opdeler et orkestreringslag et mål i mindre opgaver, holder styr på afhængigheder, uddelegerer udførelsen til de rette agenter, styrer den delte kontekst og samler resultaterne.

Diagram over orkestreringens udførelsesmotor: mål og plan, routing til agenter, udførelse af værktøjer i isolation, strukturerede resultater, vedvarende tilstand for arbejdsprocessen og et validerings- og beslutningstrin, der prøver igen, går tilbage, sætter på pause, venter eller fortsætter til næste opgave.

Lad os se på, hvad der sker, når du har givet en orkestrator en opgave.

Tag et eksempel fra Perplexitys Computer-workshop: opbygning af et dashboard med kundeindsigt baseret på oplysninger fra Salesforce, Snowflake, e-mail, kalender og seneste nyheder.

Forstå målet, og planlæg arbejdet. Orkestratoren tager udgangspunkt i det ønskede resultat og opdeler det i opgaver med eksplicitte afhængigheder. I vores dashboardeksempel indebærer det at indsamle oplysninger fra forskellige kilder og omdanne dem til en færdig leverance. Planlæggeren fastlægger, hvilke trin der afhænger af andre, og hvilke der kan køre uafhængigt.
Send opgaver til de relevante agenter. Orkestratoren identificerer opgaver, hvis afhængigheder er opfyldt, og uddelegerer arbejdet til specialiserede agenter eller modeller. Afhængige opgaver venter på deres forudsætninger. Perplexity Computer bruger flere frontier-modeller og sender forskellige dele af arbejdsprocessen til systemer, der egner sig til de pågældende opgaver. Det gør det også muligt at køre uafhængigt arbejde parallelt.
Udfør værktøjskald i kontrollerede miljøer. Agenter interagerer med deres miljø via værktøjer som websøgning, API'er, forbundne applikationer, filhandlinger eller kodeudførelse. Udførelseslaget kører disse handlinger og returnerer resultaterne til agenterne.
Overfør resultater og kontekst mellem agenter. Når en agent er færdig med sin opgave, har den næste agent i kæden brug for det relevante output for at fortsætte. En overdragelsespost kan indeholde et opgave-id, en outputreference, en skemaversion og kildemetadata. Orkestratoren koordinerer disse overdragelser og bevarer samtidig den kontekst, der er nødvendig for de efterfølgende trin. Det er vigtigt, at agenterne ikke behøver at bære hele historikken over alle andre agenters arbejde i deres egne kontekstvinduer.
Registrér udførelsestilstanden adskilt fra agentkonteksten. Når agenter starter, fuldfører eller fejler opgaver, opdaterer udførelsesmotoren en vedvarende arbejdsprocespost med opgavestatusser, udførelsesforsøg, outputreferencer og resterende arbejde. Denne post giver orkestratoren mulighed for at følge fremskridtet og genoptage efter afbrydelser uden at være afhængig af, at en LLM rekonstruerer arbejdsprocessen ud fra samtalehistorikken.
Validér resultaterne, og beslut, hvad der skal ske nu. Når en opgave returnerer, kontrollerer orkestreringslaget, om dens output overholder den forventede kontrakt, og om afhængighederne for den næste opgave er opfyldt. Hvis der findes et problem, kan arbejdsprocessen vende tilbage til et tidligere trin til korrektion eller blive sat på pause. Ellers fortsætter den mod fuldførelse.

Der er mange bevægelige dele bag det, der ligner simpel orkestrering af AI-agenter. Hvordan du organiserer koordineringen af agenter, afgør, hvor meget kontrol du har over udførelsen. Og al den koordinering medfører naturligvis ekstra overhead. Så det er ikke altid det værd.

Overvej orkestrering med flere agenter, når forskellige dele af opgaven kræver særskilt ekspertise, når uafhængigt arbejde kan køre parallelt, eller når du ikke kan fastlægge det næste trin på forhånd.

Orkestrering er derfor nyttig i tre scenarier:

Opgaverne kræver forskellige specialiseringer. Et kodningsprojekt kan for eksempel have gavn af separate agenter til planlægning, design, udvikling og gennemgang.
Uafhængige opgaver kan køre parallelt. I stedet for at lade én agent udføre alt sekventielt kan flere agenter arbejde samtidig og returnere deres resultater til en orkestrator.
Problemet er åbent. Agenterne kan have brug for at udforske forskellige tilgange, træffe beslutninger og samarbejde i stedet for at følge en foruddefineret rækkefølge.

Ud over det er orkestrering blot en dyr trend. Flere agenter betyder også mere koordinering og potentielt højere tokenomkostninger.

»Jeg starter som regel med den enkleste løsning og bygger videre derfra. Hvis vi kender trinnene, og de kan gentages, er det sandsynligvis en arbejdsproces. Jeg ser kun en grund til at indføre flere agenter, når de har forskellige ansvarsområder, tilladelser eller brugere,« siger Josh Spilker, chef for søgemarketing hos AirOps.

Selv da bør du afveje fordelene mod ekstra modelkald, overdragelser, latenstid og fejlpunkter.

Tre almindelige måder at strukturere koordineringen af agenter på – centraliseret, decentraliseret og hierarkisk orkestrering. Valget af den rette arkitektur handler om ét spørgsmål: Hvem styrer arbejdet, og hvordan koordinerer agenterne med hinanden?

Ved centraliseret orkestrering styrer én orkestrator processen. Den opdeler opgaven, uddelegerer arbejdet til specialiserede agenter, følger deres fremskridt og samler deres resultater.

Diagram over centraliseret orkestrering: én orkestrator modtager brugerens anmodning og uddelegerer til research-, analyse- og designagenter, der hver bruger deres egne værktøjer, og hvis resultater samles i et endeligt dashboard.

Afvejningen: Centraliseret koordinering gør det nemmere at følge udførelsen og anvende fælles regler fra ét kontrolpunkt. Orkestratoren kan dog blive en flaskehals, og hvis den fejler, kan det afbryde hele arbejdsprocessen, medmindre systemet understøtter gendannelse.

Ved decentraliseret orkestrering koordinerer agenterne mere direkte i stedet for at være afhængige af én leder, der træffer alle beslutninger. De kan udveksle beskeder, læse delt tilstand og selvstændigt fastlægge deres næste trin.

Diagram over decentraliseret orkestrering: research-, analyse-, design- og gennemgangsagenter kommunikerer direkte med hinanden og med delt tilstand og værktøjer for at skabe et endeligt dashboard.

Afvejningen: Agenterne kan arbejde uden at vente på en central planlægger, hvilket gør denne tilgang nyttig til udforskende arbejde og uafhængige bidrag. Men koordineringen bliver sværere, når agenterne er uenige, opdaterer delte oplysninger eller skal nå frem til et ensartet resultat.

Hierarkisk orkestrering udvider ledermodellen over flere niveauer. En orkestrator på øverste niveau uddelegerer ansvar til underordnede orkestratorer, som koordinerer deres egne grupper af specialiserede agenter.

Forestil dig en arbejdsproces i en virksomhed, der involverer salgs-, økonomi- og juridiske teams. En orkestrator på øverste niveau kan uddelegere hvert arbejdsspor til en domænespecifik koordinator. Disse koordinatorer styrer derefter deres egne specialiserede agenter og rapporterer samlede resultater.

Denne struktur kan hjælpe, når arbejdsprocesserne er for omfattende til, at én orkestrator kan styre dem effektivt.

Diagram over hierarkisk orkestrering: en orkestrator på øverste niveau uddelegerer til orkestratorer for salg, økonomi og jura, der hver styrer to specialiserede agenter, og hvis arbejde samles i et konsolideret output.

Afvejningen: Hierarkier giver teams mulighed for at fordele koordineringsansvaret og potentielt håndtere fejl inden for de enkelte grene. De medfører dog ekstra overdragelser, mere kompleks tilstandsstyring og større driftsmæssigt overhead. Lokal gendannelse afhænger også af, hvordan checkpoints og udførelsestilstand er implementeret.

Sådan sammenlignes disse arkitekturer:

Kriterier	Centraliseret	Decentraliseret	Hierarkisk
Ejerskab af udførelsen	Én orkestrator styrer uddelegeringen	Agenter koordinerer via ligestillede eller delt tilstand	Ansvaret er fordelt på flere orkestreringsniveauer
Tilstandskonsistens	Nemmere at koordinere via ét kontrolpunkt	Kræver eksplicit synkronisering og konflikthåndtering	Kræver koordinering inden for og på tværs af grene
Fejlisolering	Den centrale controller kan blive en kritisk afhængighed	De enkelte agenter kan fejle uafhængigt, men delt infrastruktur er fortsat kritisk	Fejl kan begrænses til de enkelte grene, hvis systemet er designet til gendannelse
Håndhævelse af politikker	Fælles kontroller kan håndhæves centralt	Politikker skal håndhæves ensartet på tværs af deltagerne	Kontroller kan anvendes på globalt niveau og på domæneniveau
Driftsmæssig kompleksitet	Generelt lavere	Højere koordineringskompleksitet	Højere kompleksitet på grund af flere orkestreringslag

Der er endnu en forskel, som er værd at forstå. Arkitekturen afgør, hvem der koordinerer agenterne. Udførelsesmønsteret afgør, hvordan deres opgaver skrider frem.

Der findes tre udførelsesmønstre:

Sekventielle arbejdsprocesser: Agenterne arbejder i en foruddefineret rækkefølge, hvor én agents resultat bliver en andens input.
Parallel udførelse: Uafhængige agenter arbejder samtidigt.
Overdragelsesbaseret udførelse: Kontrollen flyttes mellem specialiserede agenter, efterhånden som opgaven skrider frem. Det er nyttigt, når en anden agent er bedre rustet til at håndtere det næste trin, men hver overdragelse skal bevare de oplysninger, der er nødvendige for at fortsætte.

Mønstrene udelukker ikke hinanden, og de svarer ikke én-til-én til orkestreringsarkitekturer. Målet er at vælge den enkleste struktur, der understøtter arbejdsprocessens afhængigheder, koordineringskrav og acceptable driftsmæssige omkostninger.

Alt kan gå galt med orkestrering, fra simple forglemmelser til indviklede blokeringer. Nogle gange kan en agent endda se ud til at udføre sit job korrekt, mens den samlede arbejdsproces fejler. Med udgangspunkt i praktikeres erfaringer har vi samlet nogle af de almindelige fejl bag upålidelige orkestrerede arbejdsprocesser – hold øje med dem:

Overdragelser mellem agenter med informationstab. En orkestrator sender en opsummeret plan videre til en specialiseret agent, men opsummeringen udelader begrænsninger, afhængigheder eller implementeringsdetaljer.
For tidlig fan-in-udførelse. En downstream-agent begynder at samle resultater, før alle upstream-opgaver er afsluttet.
Ikke-deterministiske opdateringer af delt tilstand. Parallelle agenter skriver til de samme tilstandsnøgler uden veldefineret fletningssemantik. Afhængigt af hvordan frameworket håndterer opdateringer, kan det resultere i mistede skrivninger, duplikerede data, rækkefølgeafhængigt output eller modstridende ændringer.
Uoverensstemmelse mellem checkpoints og sideeffekter. En opgave udfører en ekstern handling, men den vellykkede udførelse registreres ikke varigt, før workeren fejler. Ved gendannelse ser orkestratoren en ufærdig opgave og kører den igen.
Race conditions ved genoptagelse efter menneskelig godkendelse. At sætte udførelsen på pause og genoptage den medfører sine egne synkroniseringsproblemer.
Delegeringsløkker og forstærkning af genforsøg. Agenter sender gentagne gange arbejde videre til hinanden, fordi deres ansvarsområder overlapper, afhængighederne er cirkulære, eller betingelserne for færdiggørelse er tvetydige.
Kontroller på instruktionsniveau forveksles med sikkerhed i udførelsen. En orkestrator kan bede agenter om ikke at tilgå bestemte ressourcer eller udføre følsomme handlinger, men modelinstruktioner håndhæver ikke operativsystemets tilladelser, netværksbegrænsninger eller autorisationsgrænser. Perplexitys forskning i sikkerhedsteknik fremhæver, hvorfor agenter kan krydse sikkerhedsgrænser, mens de forfølger legitime mål, selv uden ondsindede instruktioner

Læg mærke til, hvor forskellige disse fejl er. En for tidlig overgang i scheduleren eller en tvetydig ekstern skrivning kan begge føre til et forkert resultat, men de opstår i forskellige dele af udførelsens livscyklus. Derfor kræver pålidelig orkestrering mere end at forbedre prompts eller tilføje genforsøg.

Vage mål og en uklar definition af, hvornår noget er færdigt, fører ofte til skuffende resultater fra agenter. Løsningen er en promptkontrakt (en arbejdsbeskrivelse for en agent): Aftal målet, begrænsningerne, outputformatet og fejlbetingelserne, før udførelsen begynder.

Her er for eksempel, hvordan du kan definere en kontrakt for en agent, der har ansvaret for at rette en integrationstest, som fejler med mellemrum:

Mål: Identificer og ret årsagen til en ustabil integrationstest af checkout-API'et.
Input: Testens kildekode, CI-fejllogs, nylige commits og relevant applikationskode.
Begrænsninger: Deaktiver ikke tests, løsn ikke assertions, og rediger ikke urelateret applikationsadfærd.
Forventet output: En kodepatch, en forklaring af grundårsagen og resultaterne af testkørslen.
Acceptkriterier: Den test, der tidligere fejlede, består i 10 kørsler i træk, og den relevante regressionstestsuite består.
Fejlbetingelser: Grundårsagen kan ikke fastslås, rettelsen introducerer regressioner, eller det nødvendige testmiljø er ikke tilgængeligt.

Men der er en anden vigtig del: Hvornår skal agenten stoppe?

En agent bør ikke blive ved med at iterere i det uendelige, fordi den ikke har leveret et tilfredsstillende resultat. Definer, hvad der udgør en vellykket færdiggørelse, hvornår en delvist udført opgave skal returneres, og hvornår der skal stoppes, fordi et krav ikke kan opfyldes. Fastsæt en maksimal delegeringsdybde og iterationsgrænser eller udførelsesbudgetter, så uløste opgaver ikke bliver til endeløse løkker.

Tilbage til vores CI-eksempel. Du kan definere følgende stopbetingelser:

Succes: Rettelsen består 10 testkørsler i træk og den relevante regressionstestsuite.
Iterationsgrænse: Agenten kan højst afprøve to mulige rettelser.
Udførelsesbudget: Agenten skal stoppe efter 60 minutter, selv hvis problemet stadig ikke er løst.
Delegeringsgrænse: Agenten kan delegere arbejde til én specialiseret agent uden yderligere delegering til subagenter.
Delvis færdiggørelse: Hvis begge forsøg mislykkes, eller tidsgrænsen udløber, returnerer agenten sine fund, de forsøgte ændringer og testresultaterne.
Blokeret udførelse: Hvis testmiljøet ikke er tilgængeligt, stopper agenten og rapporterer, hvad der blokerer, i stedet for at påstå, at opgaven er lykkedes.

Nogle gange giver udviklere en orkestrator for mange ansvarsområder, og i stedet for at koordinere specialiserede agenter begynder den selv at skrive kode, fejlsøge eller udføre detaljerede gennemgange. Det skaber en flaskehals: Orkestratoren bruger sit kontekstbudget på implementeringsdetaljer, forsinker delegeringen og udvisker ansvaret for resultaterne.

Så lad orkestratorerne gøre deres arbejde, og håndhæv overdragelser ved at henvise til konkrete artefakter: den oprindelige opgave, relevante input, outputartefakter, udførelsesstatus og eventuelle uløste problemer.

Tag dette eksempel: status: completed henviser til det arbejde, agenten har fået tildelt, ikke til hele arbejdsprocessen. Da testene stadig er pending, bør orkestratoren ikke godkende det endelige resultat.

json

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

En agents samtalehistorik er ikke en pålidelig registrering af arbejdsprocessens fremskridt. Når dens kontekstvindue bliver fyldt, kan automatisk komprimering fjerne vigtige detaljer. Og hvis en worker går ned, skal den næste agent vide, hvilke trin der faktisk blev gennemført.

Hvis kodeagenten for eksempel genererer en patch og derefter går ned, bør den næste worker hente det gemte artefakt og fortsætte fra arbejdsprocessens registrerede tilstand. Men hvis agenten også startede en ekstern CI-kørsel, skal orkestratoren afstemme den kørsel separat, før handlingen gentages

Hold derfor udførelsestilstanden adskilt fra agentens arbejdskontekst. Gem opgavestatusser, udførelsesforsøg, gennemførte trin og artefaktreferencer i varig lagring. Indlæs samtidig kun de instruktioner, input og resultater, der er relevante for agentens aktuelle opgave, i stedet for at proppe hele udførelseshistorikken ind i dens kontekstvindue.

Lad os sige, at din CI-agent starter en testkørsel, men API-anmodningen får timeout. Lykkedes det ikke at starte testkørslen, eller satte CI-tjenesten den i kø og mistede svaret?

En timeout betyder ikke nødvendigvis, at en handling mislykkedes. Derfor skal du skelne mellem fejltyper, før du beslutter, hvad der skal ske derefter:

Midlertidige fejl (429, 503): Prøv igen med begrænset eksponentiel backoff og jitter, og respekter Retry-After, når den er angivet.
Validerings- eller tilladelsesfejl (400, 403): Stop, eller ret det underliggende problem i stedet for at gentage den samme anmodning.
Tvetydige udfald (timeout efter en mulig skrivning): Undersøg, om handlingen lykkedes, før du forsøger den igen.

Bemærk: Selv fejl, der kan forsøges igen, kræver grænser. Angiv en timeout for hvert værktøjskald, begræns antallet af genforsøg og den samlede tid til genforsøg, og håndhæv en overordnet deadline for arbejdsprocessen, så indlejrede agenter ikke kan blive ved med at genstarte den samme handling. Hvis en afhængighed fejler gentagne gange, så brug en circuit breaker til midlertidigt at stoppe anmodninger.

For handlinger med eksterne sideeffekter skal du tildele en stabil idempotensnøgle til hver logisk handling og genbruge den på tværs af genforsøg. Hvis API'et understøtter deduplikering på serversiden, kan det genkende gentagne anmodninger uden at udføre handlingen to gange. Hvis det ikke gør, så forespørg det eksterne system ved hjælp af et korrelations-id eller en anden autoritativ reference.

Når du ikke kan fastslå, hvad der skete, så stop og eskaler.

Et eksempel på logikken for genforsøg for vores CI-agent, udtrykt 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)

Kodenote: Eksemplet forudsætter, at CI-API'et understøtter opslag af kørsler efter anmodnings-id. Værdien request_id forhindrer kun dubletter, hvis udbyderen udtrykkeligt garanterer idempotens. bounded_retry() er illustrativ pseudokode. I produktion bør genforsøg begrænses af både et genforsøgsbudget pr. handling (maksimalt antal forsøg eller forløbet tid) og den overordnede deadline for arbejdsprocessen.

Ved længere arbejdsprocesser, der spænder over flere tjenester, kan du overveje Saga-mønsteret til at koordinere kompenserende handlinger, når senere trin mislykkes. Husk blot, at kompensation ikke altid er en fuldstændig tilbagerulning. Du kan rulle en databaseopdatering tilbage, men du kan ikke fortryde afsendelsen af en e-mail.

Der er to ting, der skal balanceres her: hvor meget modelkapacitet hver opgave kræver, og hvor mange opgaver du kan køre samtidigt. Rammer du forkert på en af dem, risikerer du, at agenter konkurrerer om delte API-kvoter eller udelukkende er afhængige af dyre ræsonneringsmodeller.

Ved modelvalg skal du matche modelkapacitet og ræsonneringsindsats med opgavens kompleksitet – enkelt, men ofte overset. Bemærk, at du enten kan konfigurere routingregler og evaluere modeller selv eller bruge en orkestreringsplatform, der håndterer modelvalget for dig.

Effort Mode i Perplexity Computer lader dig for eksempel vælge, hvor stor en indsats en opgave fortjener, uden at du manuelt skal vælge en model. Vælg Light, Standard, High eller Ultra, så vælger Perplexity automatisk den orkestrerende model og dens ræsonneringsniveau. Orkestratoren delegerer derefter delopgaver til understøttende agenter, som kan bruge modeller fra forskellige udbydere.

Perplexity evaluerer modelkonfigurationer ud fra kvalitet og omkostninger og foretrækker billigere muligheder, der leverer sammenlignelige resultater. Du kan også bruge Custom-indstillingerne, hvis du foretrækker selv at vælge modellen og ræsonneringsniveauet.

Ved parallelisering bør grænsen bestemmes af din infrastruktur og dine eksterne afhængigheder. Valider grænserne for anmodninger og tokens for delte API'er, og belastningstest derefter din arbejdsproces med stigende samtidighed. Hold øje med, om gennemløbet forbedres, eller om anmodninger begynder at stå i kø, blive langsommere eller returnere 429-fejl.

Håndhæv ressourcegrænser og planlægningskontroller for at holde ressourceforbruget forudsigeligt:

Kontrollér samtidighed og anmodningsrater: Begræns antallet af igangværende kald pr. tjeneste, og sæt overskydende arbejde i kø. Husk, at en grænse for samtidighed alene ikke håndhæver grænser for anmodninger pr. minut eller tokens pr. minut.
Hold styr på token- og omkostningsbudgetter: Medregn forbruget på tværs af hele arbejdsprocessen, herunder subagenter, og stop med at starte nyt arbejde, når det resterende budget ikke er tilstrækkeligt.
Håndhæv deadlines for udførelse: Angiv tidsgrænser for opgaver og arbejdsprocesser, og send annullering videre til kørende agenter, hvor det understøttes.
Respekter afhængigheder: Start kun downstream-opgaver, når deres nødvendige input er tilgængelige, i stedet for at starte alle agenter samtidigt.

Bed aldrig modellen om at afgøre, om dens egne handlinger er sikre. Giv i stedet agenter tilladelser efter princippet om mindste privilegium, og håndhæv risikobaserede godkendelsesregler i applikationskoden. Hvis agenter udfører kode, så isoler udførelsen fra dit værtsmiljø, og begræns adgangen til filer, netværk og legitimationsoplysninger. Det begrænser skaden, hvis agenten begår en fejl eller udfører usikker kode.

”Jeg er skeptisk over for alt for komplicerede multiagentsystemer, især når agenter gennemgår og godkender hinandens arbejde. Man kan ende med, at flere agenter selvsikkert sender den samme fejl videre, uden at nogen faktisk fanger den,” advarer Spilker.

Diagram over et godkendelsesflow: En agent foreslår en handling med parametre, målressource og tilstandsversion; et menneske godkender eller afviser den; godkendte handlinger genvalideres og køres i et isoleret miljø med begrænset adgang til filer, netværk og legitimationsoplysninger. Afviste eller udløbne anmodninger lukkes, og ændrede anmodninger kræver ny godkendelse.

Ved handlinger, der kræver menneskelig godkendelse, skal du sætte udførelsen på pause og gemme den nøjagtige foreslåede handling:

dens parametre
dens målressource
dens commit eller tilstandsversion
reviewerens beslutning

Definer også, hvad der sker, hvis godkendelsen afvises, udløber eller skal eskaleres. Det er afgørende for frameworks, der kan genoptages, da genoptagelse af en afbrudt node udfører koden igen fra begyndelsen af den pågældende node. Eventuelle sideeffekter før afbrydelsen kan blive kørt igen.

Så hvis godkendelsen afvises eller udløber, lukkes anmodningen. Hvis mål-committen, parametrene eller tilladelserne ændres før udførelsen, skal godkendelsen gøres ugyldig, og der skal anmodes om en ny.

Spilker støtter heller ikke idéen om fuldt autonome end-to-end-agenter, som ofte opfattes som målet. ”For mig er den bedre tilgang at bygge nogle få fokuserede agenter med klare ansvarsområder, definerede tilladelser og menneskelig gennemgang de rigtige steder. Man opnår stadig effektivitet uden at give afkald på den fulde kontrol,” konkluderer han.

Har du nogensinde haft en agent, der rapporterede Success, selvom den faktisk fejlede? Det er irriterende, hvis ikke ligefrem frustrerende, og løsningen er ikke hurtig, fordi agentens endelige besked ikke nødvendigvis fortæller dig, hvor det gik galt.

For at undersøge det skal du spore, hvad der skete under udførelsen, og verificere resultaterne uafhængigt. Så lad os bruge lidt tid på at isolere og løse problemet.

Før du fejlsøger en agents prompts, skal du registrere hele udførelsesforløbet. Du har brug for en sporing, der forbinder agentkald, værktøjskald, fejl og genforsøg under den samme kørsel af arbejdsprocessen.

OpenTelemetrys semantiske konventioner for GenAI giver en standardiseret måde at beskrive disse handlinger på. For eksempel identificerer invoke_workflow udførelsen af en arbejdsproces, invoke_agent et agentkald og execute_tool et værktøjskald. Hver handling kan registreres som et span med tilhørende timing, status og relevante metadata.

Dette trin giver dig en sporing af udførelsesforløbet, så du kan se, hvor en agent stødte på problemer.

plaintext

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

agent_response: "Success"

Et illustrativt eksempel på en udførelsessporing.

Brug programmatiske kontroller, hvor det er muligt. Valider output mod JSON-skemaer, kør enheds- og integrationstests, kontrollér, at de nødvendige artefakter findes, og forespørg eksterne systemer for at bekræfte, at handlingerne faktisk lykkedes.

For output, der kræver en subjektiv vurdering – og derfor ikke kan vurderes via programmatiske kontroller – kan du indføre en uafhængig reviewer-agent. En tilgang er en implementer–reviewer–resolver-løkke, hvor én agent producerer et artefakt, en reviewer med frisk kontekst identificerer problemer, og en resolver håndterer dem, før valideringen køres igen.

Du skal stadig validere reviewerens fund, hvor det er muligt, og hvis du bruger LLM-baserede bedømmere til gentagne evalueringer, så kalibrer deres vurderinger mod eksempler, der er gennemgået af mennesker.

Indtil nu har du sporet, hvad agenterne udførte, og kontrolleret, om deres output var korrekt. Men hvad sker der, når en worker går ned midt i en opgave, eller et API får timeout efter at have accepteret en anmodning? Overraskende nok kan din arbejdsproces fungere helt fint under normale forhold, men fejle under genoprettelsen.

For at teste dette skal du bevidst indsætte fejl i et testmiljø:

Simuler API-timeouts
Få workers til at gå ned mellem eksterne skrivninger og checkpoints
Returner fejlformateret output fra værktøjer
Lad godkendelser udløbe

Efter hver test skal du gennemgå eksekveringssporet for at se, hvilke trin der blev kørt, hvor arbejdsprocessen blev genoptaget, og om nogen handlinger blev gentaget eller sprunget over. Gennemgå derefter de faktiske resultater.

Forestil dig, at din CI-agent sender en anmodning om at starte en testkørsel, men API-svaret får timeout. Agenten prøver igen, modtager et vellykket svar og rapporterer Success. Alt ser fint ud, indtil du tjekker CI-tjenesten og opdager, at der blev oprettet to testkørsler i stedet for én.

Derfor bør du verificere både arbejdsprocessens registrerede tilstand og de faktiske ændringer i eksterne systemer. En genoprettelsestest bør kun bestå, når arbejdsprocessen når den forventede tilstand uden utilsigtede bivirkninger.

Føj de fejl, du afdækker, til dine regressionstests, så fremtidige ændringer ikke genintroducerer dem.

I sidste ende betyder succes, at arbejdsprocessen bestod de påkrævede kontroller, og at dens eksterne resultater blev verificeret.

Isolerede agenter kan løse hver deres opgaver korrekt, men alligevel give inkonsistente resultater samlet set. Forestil dig en salgsagent, der henter kundevilkår kl. 10.00, en prisagent, der beregner et tilbud med opdaterede priser kl. 10.05, og en juridisk agent, der tjekker en kontrakt, som blev ændret kl. 10.07. Hver agent arbejder med et forskelligt øjebliksbillede af virksomheden, så deres output kan modsige hinanden.

Problemet bliver mere markant i virksomhedsskala, fordi agenter interagerer med flere systemer, der opdateres uafhængigt af hinanden, opererer med forskellige tilladelser og ikke nødvendigvis deler kontekst eller udførelsestilstand.

Sæt grænser på flere niveauer: maksimalt antal genforsøg for værktøjskald, maksimalt antal agentiterationer, delegeringsdybde og en samlet deadline for arbejdsprocessen. Klassificer fejl, før du prøver igen. Ved midlertidige 429-svar skal du respektere Retry-After, når den er angivet. Ellers skal du bruge begrænset eksponentiel backoff med jitter.

Stop med at gentage uændrede anmodninger efter validerings- eller tilladelsesfejl. Hvis en downstream-tjeneste fejler gentagne gange, kan en circuit breaker forhindre agenter i at generere yderligere belastning.

Genoprettelsesmekanismen afhænger af din runtime. Med LangGraph gemmer en persistent checkpointer som PostgresSaver graftilstanden under et thread_id, så eksekveringen kan fortsætte fra den gemte tilstand. Med Temporal kan en anden worker rekonstruere en arbejdsproces ved at afspille dens hændelseshistorik igen. Under genafspilningen genbruger den tidligere registrerede aktivitetsresultater.

Hvis applikationen genudrulles, mens arbejdsprocesser stadig kører, er gemt tilstand og eksekveringshistorik muligvis ikke længere kompatible. Temporal håndterer dette via Worker Versioning og patching af arbejdsprocesser. For checkpoint-baserede systemer bør du planlægge skemamigreringer og teste genoprettelse mod eksisterende gemte tilstande, før du udruller inkompatible ændringer.

Kør de samme repræsentative opgaver flere gange, og skeln mellem pass@k (om mindst ét af k forsøg lykkes) og pass^k (om alle k forsøg lykkes)

Mål resultater efter opgavekategori og version af arbejdsprocessen i stedet for at forlade dig på én samlet succesrate. Følg succes ved første forsøg, konsistens på tværs af gentagne kørsler, p95-latenstid, omkostning pr. gennemført opgave og andelen, der kræver menneskelig indgriben. Angiv stikprøvestørrelser og usikkerhedsintervaller for succesrater.

Hvad er orkestrering af AI-agenter?

Sådan fungerer orkestrering af AI-agenter: Et kig ind i udførelsesmotoren

Hvornår bør du bruge orkestrering af AI-agenter?

Arkitekturer til orkestrering af AI-agenter og deres fordele og ulemper

Centraliseret orkestrering

Decentraliseret orkestrering

Hierarkisk orkestrering

Sekventiel, parallel og overdragelsesbaseret udførelse

Almindelige fejl i orkestrering af AI-agenter

7 bedste praksisser for orkestrering af AI-agenter, der sikrer pålidelighed i produktion

1. Definer eksplicitte opgavekontrakter, acceptkriterier og stopbetingelser

2. Hold orkestratorer slanke, og håndhæv strukturerede overdragelser

3. Gem arbejdsprocessens tilstand varigt, og begræns væksten i konteksten

4. Design genforsøg, der tager højde for fejltypen, og værktøjsudførelse, der kan gendannes

5. Fordel og paralleliser arbejdet med eksplicitte ressourcebudgetter

6. Håndhæv godkendelser, og isoler agenternes udførelse

7. Verificer output uafhængigt, og test gendannelsesadfærden

Spor arbejdsprocessen for at finde ud af, hvad der gik galt

Gennemgå outputtet uafhængigt

Injicer fejl for at teste gendannelse

Ofte stillede spørgsmål om orkestrering af AI-agenter

Hvorfor bryder isolerede AI-agenter sammen i virksomhedsskala?

Hvordan forhindrer man uendelige genforsøgsløkker i AI-agenter?

Hvordan genoptager man en arbejdsproces med AI-agenter efter et nedbrud?

Hvordan tester man pålideligheden af orkestrering af AI-agenter?