Aardlekschakelaars voor thuis-AI: waarom één falende tool niet elk verzoek mag ophouden

Een circuit breaker voorkomt dat één falende AI-tool voor thuis elke aanvraag ophoudt door herhaalde aanroepen te stoppen totdat herstel aannemelijk wordt.

Een agent kan afhankelijk zijn van zoeken, transcriptie, een camera-API en een smart-homebridge. Als één tool blijft hangen, kan elke workflow die deze tool gebruikt een worker bezet houden, op een time-out wachten en opnieuw proberen. Een circuit breaker zet herhaalde fouten om in een tijdelijke snelle afwijzing, zodat threads en wachtrijcapaciteit beschikbaar blijven voor aanvragen die nog wel kunnen slagen.

Herhaalde time-outs verbruiken capaciteit buiten de defecte tool

Een time-out houdt een verbinding, worker en workflowdeadline bezet zonder nuttig resultaat op te leveren. Parallelle agentstappen kunnen die kosten vermenigvuldigen en retries kunnen een al ongezonde afhankelijkheid bezig blijven houden. Het lokale model kan snel zijn, terwijl gebruikers wachten op dezelfde gedoemde externe aanroep.

AWS beschrijft het circuit-breakerpatroon als een stateful proxy die fouten monitort en aanvragen blokkeert zodra een drempel wordt bereikt. Het patroon verschilt van een retry doordat het stopt met het verbruiken van capaciteit voor een afhankelijkheid waarvan wordt verwacht dat deze zal falen.

Een snelle foutafhandeling stelt de orchestrator in staat een optionele stap over te slaan, gecachte informatie te gebruiken of gedeeltelijke beschikbaarheid te melden. Ook voorkomt dit dat de hoofdwachtrij volloopt met aanroepen die niet vóór hun deadlines kunnen worden voltooid. Dit onderscheid blijft belangrijk onder realistische omstandigheden in huis.

Gesloten, open en halfopen toestanden sturen herstel

In de gesloten toestand worden aanroepen uitgevoerd en fouten geteld. Zodra de geconfigureerde drempel wordt overschreden, opent het circuit en worden aanroepen gedurende een afkoelperiode afgewezen. In de halfopen toestand wordt vervolgens een beperkte testaanroep toegelaten; bij succes wordt het circuit gesloten en bij een fout opnieuw geopend.

De richtlijnen van Microsoft over breaker-toestanden benadrukken dat foutentellingen, time-outs en herstelgedrag moeten passen bij de bewerking. Eén gedeelde breaker kan te grof zijn wanneer lees- en schrijf-endpoints verschillende fouttypen hebben. De tussenliggende toestand moet zichtbaar blijven voor latere diagnose en evaluatie.

De breaker moet worden afgestemd op de toolbewerking en foutklasse. Authenticatiefouten, rate limits, time-outs, ongeldige argumenten en weigeringen door het model vereisen verschillende herstelregels; wanneer deze onder één teller worden samengevoegd, kan de werkelijke fout verborgen blijven.

Fallbacks kunnen beschikbaarheid behouden en tegelijkertijd correctheid verminderen

Een gecachte weerswaarde kan geschikt zijn voor weergave, maar onveilig zijn om ramen te sluiten tijdens een storm. Een CPU-model kan langzaam maar correct antwoorden, terwijl een generiek resultaat compleet kan lijken en de agent kan misleiden. Circuit breakers beschermen capaciteit, niet de semantische kwaliteit.

De catalogus agent circuit breakers past circuit breaking toe op agenttools en wijst op de noodzaak van fallbacks en observability. Bij een agent moet het resultaat van een open circuit gestructureerd blijven, zodat de planner onbeschikbare informatie kan onderscheiden van een negatief antwoord.

De foutgrens ligt bij elke actie waarvoor het actuele resultaat van de ontbrekende tool nodig is. In dat geval moet de actie veilig worden afgebroken, moet de onbeschikbare afhankelijkheid worden gemeld en moet om goedkeuring worden gevraagd of later opnieuw worden geprobeerd, in plaats van stilzwijgend verouderde of zwakkere informatie te gebruiken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Injecteer één toolfout en traceer de isolatie

Kies één niet-destructieve tool en injecteer time-outs, fouten en trage reacties terwijl gemengde workflows doorgaan. Leg de breakerstatus, het foutvenster, het aantal gelijktijdige aanroepen, de wachtrijdiepte, de gekozen fallback en de hersteltests vast. Controleer of niet-gerelateerde tools hun normale latentie behouden.

Test de CPU-fallbackgrens die wordt beschreven in CPU-failover, maar label gedegradeerde uitvoering expliciet en meet of deze nog steeds binnen de workflowdeadline valt. Controleer of een halfopen testaanroep geen golf van wachtende aanvragen kan veroorzaken.

Slaag alleen als de falende bewerking is geïsoleerd, aanroepers een gestructureerde status voor onbeschikbaarheid ontvangen en herstel het circuit na gecontroleerde testaanroepen sluit. Als gecachte of fallbackresultaten een actie veranderen, voeg dan een beleidscontrole toe voordat die fallback wordt ingeschakeld.