Kretsbrytning begränsar ett felande externt verktyg genom att stoppa upprepade anrop, returnera ett kontrollerat resultat och kontrollera återhämtningen innan normal trafik återställs.
En lokal agent kan vara beroende av en molnmodell, ett sök-API, en aviseringstjänst eller en fjärransluten brygga för smarta hem, medan resten av arbetsflödet fungerar korrekt. Utan en avgränsningsgräns kan ett långsamt beroende förbruka agentens tidsbudget och utlösa fler återförsök. En kretsbrytare omvandlar det osäkra fjärrtillståndet till ett explicit lokalt tillstånd som orkestreraren kan resonera kring.
Kretsbrytaren sitter mellan verktygsval och extern körning
En agent väljer normalt ett verktyg, validerar argumenten och överlämnar anropet till en exekverare, medan kretsbrytning lägger till ett tillståndsfullt omslag vid denna sista gräns. Den ändrar inte vad modellen begärde; den avgör om exekveraren ska kontakta beroendet, avvisa försöket lokalt eller släppa igenom en begränsad återhämtningskontroll.
Omslaget övervakar slutförda anrop och klassificerar resultat som lyckade anrop, tidsgränsöverskridningar, transportfel, hastighetsbegränsning eller någon annan konfigurerad felsignal. Ett konventionellt kretsbrytarmönster omsluter fjärranrop, spårar fel, öppnas efter en tröskel och tillåter senare testanrop, så att beroendets hälsa hålls utanför modellens bedömning på promptnivå.
Det omedelbara resultatet är därför inte bara ett verktygsundantag. Det är ett strukturerat orkestreringsresultat som innehåller kretsbrytarens tillstånd, huruvida körning försöktes och vilka fortsättningsvägar som fortfarande är tillåtna.
Nya fel komprimeras till en tillståndsövergång
När kretsbrytaren är stängd släpper den igenom anrop och registrerar endast de resultat som är relevanta för policyn, så att ett enstaka tidsgränsfel inte nödvändigtvis inaktiverar ett användbart verktyg. Implementeringar utvärderar vanligtvis ett nyligt antal, en felfrekvens eller ett tidsfönster och öppnar först när de lokala beläggen överskrider den konfigurerade tröskeln för fel eller långsamma anrop.
Tröskeln omvandlar många brusiga händelser till ett stabilt kontrollbeslut. En tröskel för felfrekvens kan begränsa anslutningsstormar under ett nätverksfel i stället för att låta varje begärt åtgärd skapa ännu en anslutning som är dömd att misslyckas.
Vad som räknas som ett fel måste stämma överens med verktygets kontrakt. Nekad autentisering, felaktiga argument och en permanent saknad resurs behöver vanligtvis hanteras på ett annat sätt än fördröjning, tillfällig otillgänglighet eller hastighetsbegränsning.
En procenttröskel behöver också tillräckligt många observationer för att vara meningsfull. Om kretsen öppnas efter ett enda fel blir ett sparsamt använt verktyg instabilt, medan en stor urvalsmängd kan göra att ett ofta felande beroende förblir aktivt för länge. Därför hör samplingsfönstret och kravet på minsta antal anrop till kretsbrytarens policy, inte till språkmodellen.
En öppen krets omvandlar väntan på fjärranrop till ett lokalt fel
När kretsbrytaren har öppnats slutar exekveraren att kontakta beroendet under ett uttryckligt nedkylningsintervall, så att nya försök misslyckas lokalt i stället för att vänta igenom ännu en fjärrtidsgräns. Friska lokala verktyg, hämtsteg och resonemangsturer kan fortsätta utan att ärva det felande beroendets fördröjning.
Denna snabbavvisande väg begränsar både resursbelastning och fördröjning, eftersom upprepade fjärranrop kan hålla uttag, arbetsplatser, minne eller köade uppgifter upptagna medan de väntar. Genom att avvisa åtgärder innan de tilldelar mer kapacitet för externa anrop minskar man resursutmattning under ett långvarigt avbrott.
Avgränsningen är selektiv snarare än global. En kretsbrytare bör normalt omfatta ett enda beroende och ofta en enda åtgärdsklass, eftersom läsningar och skrivningar kan ha olika kostnader vid fel.
Återförsök och tidsgränser påverkar vad kretsbrytaren observerar
Ett återförsök hanterar ett fel som antas vara tillfälligt, medan en kretsbrytare kommer ihåg att felen har blivit tillräckligt ihållande för att försöken ska stoppas. Därför påverkar deras ordningsföljd vilka belägg kretsbrytaren ser. Återförsök inom en skyddad körning kan räknas som ett enda logiskt anrop, medan återförsök utanför kretsbrytaren kan lägga till ett nytt felprov varje gång.
Tidsgränser avgör också när ett långsamt anrop blir ett felprov. Resiliensmönster skiljer mellan tidsgränser, återförsök och kretsbrytare, eftersom varje kontroll ansvarar för en annan felgräns.
Denna åtskillnad blir avgörande när verktyget har icke-idempotenta bieffekter. Samma loopar med upprepade verktygsanrop kan uppstå genom modellbeslut eller återförsökslager under modellen, och en kretsbrytare kan inte bevisa om en tidsgränsöverskriden skrivning redan ändrade det externa systemet.
En säker körningsväg registrerar därför återförsöksbudgeten och kretsbrytarens tillstånd separat, så att orkestreraren kan förklara om en åtgärd aldrig försöktes, försöktes en gång eller blockerades efter upprepade fel i beroendet.
Reservlösningar bevarar arbetsflödets innebörd utan att låtsas att verktyget fungerade
Att öppna kretsen besvarar bara frågan om det primära verktyget får köras, medan orkestreraren fortfarande behöver en fortsättningspolicy som bevarar användarens avsikt. Beroende på uppgiften kan den returnera delresultat, använda cachad läsdata, byta leverantör, köa uppgiften, begära mänsklig granskning eller stoppa.
En reservlösning måste bära metadata om försämringen i stället för att utge sig för att vara originalresultatet. Efterföljande steg kan begränsa åtgärder med stor påverkan när de arbetar med inaktuellt cachat innehåll eller ersättande belägg.
Vissa anrop har ingen säker reservlösning. En avisering kan köas, men ett kommando för dörrstyrning bör inte ersättas med ett gissat tillstånd, och en borttagning av en säkerhetskopia bör inte härledas från ett cachat inventarium.
Halvöppna kontroller återställer åtkomsten utan att släppa fram en våg av återförsök
En öppen krets kan inte förbli stängd för trafik för alltid, eftersom det externa verktyget kan återhämta sig. Därför släpper kretsbrytaren efter ett nedkylningsintervall endast igenom ett litet antal testanrop. Den normala arbetsbelastningen förblir blockerad tills dessa kontroller visar att beroendet åter kan ta emot trafik på ett säkert sätt.
Lyckade kontroller för kretsbrytaren mot stängt tillstånd, medan misslyckade kontroller öppnar den igen och startar om väntetiden. Genom att övervaka kretsbrytarens tillstånd blir upprepade öppningar och långa återhämtningsperioder synliga i stället för att begravas i verktygsfel.
En lyckad hälsokontroll är inte automatiskt ett säkert återspelande av en tidigare skrivning. Beroendet kan besvara en läskontroll samtidigt som en tidigare bieffekt fortfarande är oklar, så idempotensnycklar, kontrollpunkter, avstämning och godkännandegränser styr fortfarande om avbrutna åtgärder får återupptas.
Åtkomst till kontroller begränsas avsiktligt mer än normal trafik, eftersom återhämtningsbevisen blir mindre användbara om hundratals väntande begäranden träffar beroendet samtidigt. Genom att begränsa samtidiga kontroller förhindrar man att själva kretsbrytaren skapar den topp som får ett nyligen återhämtat verktyg att verka ohälsosamt igen.
Teknik- och AI-hubb
Mer att läsa

Tillstånd under körning kontra beständigt tillstånd i Home Assistant: Vad måste överleva en omstart?
Home Assistant sparar inte varje aktuellt värde permanent; konfiguration, register, utvalda återställda tillstånd, historik och distributionsdata har olika roller vid omstart.

Hur autentiserar Home Assistant lokala och fjärranslutna sessioner?
Lokala och fjärranslutna Home Assistant-sessioner använder samma identitetsmodell på serversidan; fjärråtkomst ändrar routningen och TLS-gränsen, men inte det grundläggande tokenflödet.

Varför kan historikfrågor i Home Assistant bli långsammare när Recorder-data växer?
Ökad loggstorlek kan höja kostnaden för historikfrågor när det begärda intervallet omfattar fler rader, cachemissar ökar eller arbete med lagring och index blir långsammare.

