Hvorfor AI-agenter har brug for dokumentation, før de prøver igen

Sådan undgår du, at et manglende svar fører til en handling i dublet

En supportagent, der har fået tilladelse til at udstede én refusion, sender anmodningen, men forbindelsen afbrydes. Agenten modtager ingen bekræftelse på, at anmodningen er gennemført, og forsøger at sende refusionen igen. Hvis den oprindelige anmodning blev gennemført, kan agentens gentagne handling føre til en ekstra refusion.

Dette er rent hypotetisk. Eksemplet illustrerer et problem, som ikke kan løses alene ved at gøre modellen mere præcis. Hvad bør en agent gøre, hvis den ikke kan afgøre, om dens tidligere handling har ændret miljøets tilstand?

Unite.AI har undersøgt agenters pålidelighed ud over modellerne. Problemer med genopretning fortjener deres egne regler i disse diskussioner. Før agenten forsøger sig med en konsekvensfuld handling igen, bør den bekræfte, hvad der skete, eller have en gyldig garanti for, at handlingen ikke får dublerede virkninger.

Et manglende svar fastslår ikke, at handlingen mislykkedes

Et manglende svar fastslår ikke, at en handling er mislykkedes. Det viser ikke, om der opstod en fejl før udførelsen, om handlingen blev gennemført uden bekræftelse, eller om processen stadig er i gang.

Dette er et almindeligt problem i distribuerede systemer, som Amazon beskriver. Amazon forklarer, hvorfor mekanismer til nye forsøg kræver særlige sikkerhedsforanstaltninger mod gentagne bivirkninger. Agenter tilføjer en ny beslutningstagende enhed til systemets proces for genopretning. De kan træffe yderligere beslutninger om, hvordan systemet skal komme sig efter fejl.

Disse beslutninger kan ændre den måde, virksomheden drives på. Hvis man for eksempel prøver at gennemføre en refusion igen med et andet beløb, er det ikke blot endnu et forsøg på den samme anmodning. Tilsvarende er det ikke blot endnu et forsøg på den samme anmodning at vælge en anden betalingstjeneste, når den første er holdt op med at svare.

Teams skal skelne mellem at give tilladelse til at udføre en handling og at give tilladelse til at håndtere et ukendt udfald. Den oprindelige godkendelse betyder ikke, at det er sikkert at udføre handlingen igen.

Ny forskning måler risikoen

Et fortryk fra september 2026 med titlen »Where Does Exactly-Once Live?« introducerede LIMBO-benchmarken og testede 25.930 episoder på ni modeller. De simulerede tjenester blev testet med mistede kvitteringer, forsinket behandling og dublerede leveringer.

I 1.279 episoder i forfatternes hovedtest blev der skabt en dubleret virkning; i 90 % af tilfældene rapporterede agenterne, at opgaven var gennemført. En agent kan altså rapportere, at opgaven er gennemført, selvom behandlingen er foregået forkert.

Disse resultater bygger på kontrollerede benchmarks og anslår ikke fejlhyppigheden i produktionsmiljøer. Tjenesterne var simulerede, og flere af analyserne var eksplorative. Teams bør vurdere resultatet af agenternes handlinger separat fra deres rapporter om, at handlingerne er gennemført.

Artiklen behandler også, hvorfor det kan være utilstrækkeligt at kontrollere den aktuelle tilstand. En anmodning, der stadig behandles, kan få virkning, efter at kontrollen er udført. Selv en tom statusbesked betyder ikke, at anmodningen ikke får virkning senere.

Gentagne forsøg vedrører den samme hensigt

En modtagende tjeneste kan genkende gentagne forsøg på at udføre én handling ved hjælp af en idempotensnøgle. Hvis denne metode understøttes korrekt, sikrer den, at gentagne forsøg ikke skaber yderligere virkninger. Idempotensnøglen skal forblive den samme ved alle nye forsøg.

Stripes API-dokumentation indeholder eksempler på både mulighederne og begrænsningerne ved idempotensnøgler. For API v1 kan nøgler slettes efter mindst 24 timer. Hvis en slettet nøgle bruges igen, udløser det en ny anmodning. Stripe kontrollerer også, at de parametre, som anmoderens system har angivet, svarer til dem i den oprindelige anmodning.

I praksis betyder idempotens, at den skal være indbygget i integrationslaget og ikke kun indgå i en prompt. Før en handling sendes af sted, skal den godkendte handling registreres. Gem dens identifikator, de nøjagtige parametre, en reference fra udbyderen, hvis det er relevant, og handlingens status.

Ved en refusion skal forbindelsen mellem godkendelsen og den oprindelige transaktion samt eventuelle refusions-id’er fra udbyderen gemmes. Det er mindre overbevisende dokumentation blot at søge efter en refusion på samme beløb, fordi to legitime anmodninger kan være på samme beløb. Der kan også gå noget tid, fra en refusionsanmodning sendes, til den vises i et søgeresultat. Den oprindelige anmodning kan stadig være under behandling.

Når en agent eller en worker genstartes, bør eksekveringslaget bevare den pågældende identitet. Det bør afvise en ændret anmodning, der indsendes som den samme handling. En sådan ændring udgør en ny handling, som ifølge arbejdsgangens regler kræver en ny godkendelsesbeslutning.

Beskrivelser af værktøjer er ikke nok

Ud over beskrivelser af værktøjer skal du kontrollere, hvad den modtagende tjeneste lover med hensyn til understøttelse af idempotens. Test implementeringen for at bekræfte, hvilke garantier der faktisk overholdes.

Behandl usikkerhed som en driftstilstand

Figur 1. En foreslået genoprettelsesproces for handlinger med konsekvenser. Hvert nyt forsøg kræver også en aktuel godkendelse.

Bekræftet gennemførelse betyder, at arbejdsgangen dokumenterer resultatet og fortsætter uden at gentage handlingen. Bekræftet manglende udførelse giver kun mulighed for et nyt forsøg, hvis ingen oprindelig anmodning stadig afventer, og autorisationen fortsat er gældende.

Der er meget mere at tage højde for, når udfaldet er uafklaret. Hvis der findes en gyldig garanti fra udbyderen mod dobbelte virkninger, kan du tillade, at den oprindelige anmodning forsøges igen med den samme nøgle. Ellers skal du standse skrivninger og afklare situationen via en statusforespørgsel, udbyderens support eller en autoriseret operatør. En uafklaret kontrol giver ikke tilstrækkelig grund til at godkende endnu et forsøg.

Det kan også være berettiget at sætte processen på pause, når udbyderen dokumenterer grænser for behandling og synlighed. Uden sådanne grænser kan den forløbne tid alene ikke bekræfte, at handlingen ikke blev udført. Du skal fastlægge, hvem der har ansvaret for uafklarede sager, og hvornår de ansvarlige skal gennemgå dem.

Genopretning efter fejl kan kræve en anden forretningsproces

Hvis en tilbagebetaling gennemføres, men den efterfølgende kundemeddelelse mislykkes, kan en gentagelse af hele arbejdsgangen føre til, at tilbagebetalingen gennemføres igen. Genopretningen bør fokusere på at fuldføre det uafsluttede trin og samtidig bevare dokumentationen for det arbejde, der allerede er udført.

Hvis det er nødvendigt at træffe korrigerende foranstaltninger for handlinger, der allerede er udført, giver Microsoft vejledning om kompenserende transaktioner. Hver applikation afgør, hvordan fejl bedst kompenseres. Kompensering bringer ikke nødvendigvis tingene tilbage til udgangspunktet, og selve kompenseringen kan mislykkes.

Derudover kan annullering af en transaktion medføre en debitering. En rettelse af en meddelelse kan ikke sikre, at ingen har set en tidligere version. Derfor skal enhver genopretningsaktivitet udtrykkeligt begrænse, hvad agenten kan omgøre, ændre eller forpligte sig til. Beslutninger, der ligger uden for disse begrænsninger, skal henvises til en person med den nødvendige bemyndigelse.

Afprøv det andet forsøg, før det sættes i drift

Vælg et værktøj med væsentlige konsekvenser, og gennemfør en målrettet test af genopretningen i et testmiljø. Når udførelsen er lykkedes, skal du kassere svaret på den oprindelige anmodning. Udsæt udførelsen af den første anmodning, indtil en statuskontrol er foretaget. Genstart arbejdsprocessen under genopretningen. Vent, indtil nøglens opbevaringsperiode udløber, før du forsøger igen. Ændr én parameter under gentagne forsøg.

Vurder de resulterende forretningsregistreringer i stedet for blot at stole på værktøjssvarene. Registrer dobbelte virkninger, uafklarede handlinger, forsømt arbejde, genopretningstid og yderligere manuelle indgreb. Beregn omkostningen pr. korrekt fuldført opgave ud fra de samlede omkostninger ved arbejdsgangen, herunder tilbageførsel af transaktioner og kompensation til kunder.

Afprøv også en reel, ny anmodning, der ligner den oprindelige. Sørg for, at systemet undgår at oprette dubletter uden at forhindre nyt arbejde. Vurder særskilt, om dubletter undgås, og om opgaverne med tiden bliver fuldført. Ellers kan en agent, der afslutter alle opgaver, fremstå sikker, samtidig med at den leverer ringe eller ingen værdi.

Evalueringsspørgsmålet skal være klart formuleret. Kunne systemet forklare:

• Hvilken handling var godkendt?
• Hvilken dokumentation forelå for at fastslå udfaldet?
• Hvorfor var det tilladt at forsøge igen?

En agent, der sætter arbejdet på pause på grund af uafklaret usikkerhed, kan virke mindre effektiv under demonstrationer. I produktionsmiljøer kan en pause imidlertid bevare kundens oprindelige hensigt. Nyttig vedholdenhed indebærer, at systemet fuldfører godkendte opgaver uden stiltiende at udføre dem flere gange.