Wat is een transactierand van een agent en wanneer kan een toolactie worden teruggedraaid?
Een transactieboundary van een agent bepaalt welke effecten als één vastgelegde eenheid worden behandeld en onderscheidt echte rollback van compensatie of onomkeerbare externe acties.
Een thuisagent kan in één plan bestanden hernoemen, een index bijwerken, een bericht versturen, een deur ontgrendelen en een auditrecord schrijven. Slechts enkele bewerkingen delen een databasetransactie; andere worden vastgelegd in onafhankelijke tools of in de fysieke wereld. De boundary bepaalt wanneer de status duurzaam wordt, wat exact kan worden hersteld en waar de workflow een punt bereikt dat compensatie of voorafgaande goedkeuring vereist.
Atomic rollback bestaat alleen binnen één gedeelde transactiemanager
Binnen één transactionele datastore kan de agent of tool wijzigingen voorbereiden en ze gezamenlijk vastleggen, zodat bij een fout vóór het vastleggen niets zichtbaar blijft. Savepoints kunnen een deel van het werk terugdraaien en tegelijkertijd een omringende transactie behouden.
Het saga-patroon onderscheidt een reeks lokale transacties van één globale atomische transactie. Zodra een externe service iets vastlegt, heeft het oorspronkelijke rollbackmechanisme van de database geen controle meer over dat effect. Dit onderscheid blijft zichtbaar tijdens latere tests in het huishouden.
Een agentplan is dus niet automatisch een transactie omdat het meerdere stappen bevat. Elke tool moet commitsemantiek, idempotentie en een duurzame bewerkingsidentificatie beschikbaar stellen waar de orchestrator mee kan redeneren. Het tussenresultaat moet controleerbaar blijven voordat de automatisering verdergaat.
Compensatie creëert een nieuw effect in plaats van de geschiedenis uit te wissen
Een gekopieerd bestand verwijderen, een betaling terugbetalen of een correctie versturen kan een eerdere actie compenseren, maar de oorspronkelijke gebeurtenis heeft nog steeds plaatsgevonden en waarnemers kunnen erop hebben gereageerd. Compensatie moet per tool worden ontworpen en kan zelf mislukken.
De saga-richtlijnen van Azure onderscheiden compenseerbare bewerkingen, pivotstappen en niet-compenseerbare bewerkingen. De pivot markeert een punt waarna de workflow moet doorgaan naar een consistente uitkomst, in plaats van te doen alsof elk eerder effect ongedaan kan worden gemaakt.
Voor een agent horen omkeerbare bestandsverplaatsingen vóór het versturen van berichten, deurbediening, publicatie of apparaatopdrachten te staan. Goedkeuring hoort normaal gesproken direct vóór de eerste onomkeerbare of extern zichtbare pivot te staan. Die boundary moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.
Retries vereisen idempotentie en een gezaghebbend bewerkingslogboek
Na een time-out weet de orchestrator mogelijk niet of een tool vóór of na het vastleggen is mislukt. Opnieuw proberen zonder een idempotentiesleutel kan leiden tot dubbele berichten, betalingen, bestanden of automatiseringen; succes veronderstellen kan noodzakelijk werk overslaan. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen strijden om beperkte context.
De analyse van Temporal over compenserende acties benadrukt expliciete compenserende acties voor eerder voltooide gedistribueerde stappen. De duurzame workflowstatus moet pogingen, bevestigingen, compensaties en de huidige pivot registreren. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.
De foutgrens is een fysiek of extern effect zonder inverse, zoals gegevens openbaar maken, een melding versturen die al is gelezen, een bestand zonder versiebeheer verwijderen of hardware activeren. Geen enkele softwarematige rollback kan de wereld na die grens exact herstellen.
Classificeer elke toolstap voordat de agent deze uitvoert
Leg voor elke actie de resource, transactiemanager, voorbereidings- en vastleggingspunt, idempotentiesleutel, waarneembare bijwerking, inverse, voorwaarden voor compensatie, time-outonduidelijkheid, retryregel, goedkeuringspoort en auditgebeurtenis vast. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.
Reconstructeer beslissingen met het auditspoor van de agent. Injecteer fouten vóór het verzoek, na ontvangst door de tool, na het vastleggen, vóór de bevestiging, tijdens compensatie en na de pivot; controleer onderdrukking van duplicaten en uiteindelijke consistentie. Dit onderscheid blijft zichtbaar tijdens latere tests in het huishouden.
Sta automatische rollback alleen toe wanneer de tool dit garandeert. Gebruik compensatie voor omkeerbare bedrijfseffecten, vereist goedkeuring vóór onomkeerbare pivots en maak onzekerheid zichtbaar in plaats van te beweren dat het volledige agentplan is teruggedraaid. Het tussenresultaat moet controleerbaar blijven voordat de automatisering verdergaat.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kan een lokale LLM de generatie hervatten nadat het proces opnieuw is gestart?
Een mechanismegerichte uitleg van het hervatten van LLM-generatie, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een homeserver embeddings genereren en video transcoderen op dezelfde geïntegreerde GPU?
Een uitleg waarin het mechanisme centraal staat van gedeelde iGPU-embeddings en transcodering, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een...
Welke invloed heeft de levensduur van toegangstokens op de beveiliging en het gedoe in het huishouden?
Een mechanismegerichte uitleg van de levensduur van toegangstokens, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
