Leitungsschutzschalter für Heim-KI: Warum ein ausfallendes Tool nicht jede Anfrage aufhalten sollte

Ein Circuit Breaker verhindert, dass ein fehlerhaftes KI-Tool im Heimnetzwerk jede Anfrage ausbremst, indem er wiederholte Aufrufe stoppt, bis eine Erholung plausibel ist.

Ein Agent kann von der Suche, der Transkription, einer Kamera-API und einer Smart-Home-Bridge abhängen. Wenn ein Tool hängt, kann jeder Workflow, der es verwendet, einen Worker belegen, auf einen Timeout warten und es erneut versuchen. Ein Circuit Breaker wandelt wiederholte Fehler in eine vorübergehende sofortige Ablehnung um und bewahrt Threads und Warteschlangenkapazität für Anfragen, die weiterhin erfolgreich abgeschlossen werden können.

Wiederholte Timeouts verbrauchen auch außerhalb des fehlerhaften Tools Kapazität

Ein Timeout belegt eine Verbindung, einen Worker und das Workflow-Zeitlimit, ohne ein nützliches Ergebnis zu liefern. Parallele Agentenschritte können diesen Aufwand vervielfachen, und Wiederholungen können eine bereits unzuverlässige Abhängigkeit weiter auslasten. Das lokale Modell kann schnell sein, während Benutzer auf denselben aussichtslosen externen Aufruf warten.

AWS beschreibt das Circuit-Breaker-Muster als zustandsbehafteten Proxy, der Fehler überwacht und Anfragen blockiert, sobald ein Schwellenwert erreicht ist. Das Muster unterscheidet sich von einem Retry, da es verhindert, dass weitere Kapazität für eine voraussichtlich fehlerhafte Abhängigkeit verbraucht wird.

Ein schnelles Fehlschlagen ermöglicht es dem Orchestrator, einen optionalen Schritt auszulassen, zwischengespeicherte Informationen zu verwenden oder eine teilweise Verfügbarkeit zu melden. Außerdem verhindert es, dass sich die Hauptwarteschlange mit Aufrufen füllt, die ihre Zeitlimits nicht einhalten können. Dieser Unterschied bleibt unter realistischen Bedingungen im Haushaltseinsatz wichtig.

Die Zustände „Geschlossen“, „Geöffnet“ und „Halb geöffnet“ steuern die Wiederherstellung

Im geschlossenen Zustand werden Aufrufe ausgeführt und Fehler gezählt. Wird der konfigurierte Schwellenwert überschritten, öffnet sich der Circuit und lehnt Aufrufe für eine Abkühlzeit ab. Im halb geöffneten Zustand wird anschließend eine begrenzte Prüfung zugelassen; bei Erfolg schließt sich der Circuit, bei einem Fehler öffnet er sich erneut.

Die Microsoft-Anleitung zu Breaker-Zuständen betont, dass Fehleranzahl, Timeout und Wiederherstellungsverhalten zur jeweiligen Operation passen müssen. Ein gemeinsamer Breaker kann zu grob sein, wenn Lese- und Schreibendpunkte unterschiedliche Fehlermuster aufweisen. Der Zwischenzustand sollte auch bei späteren Diagnosen und Überprüfungen sichtbar bleiben.

Der Breaker sollte auf die Tool-Operation und die Fehlerklasse begrenzt werden. Authentifizierungsfehler, Rate-Limits, Timeouts, ungültige Argumente und Modellablehnungen benötigen unterschiedliche Wiederherstellungsregeln; wenn sie unter einem einzigen Zähler zusammengefasst werden, kann der eigentliche Fehler verborgen bleiben.

Fallbacks können die Verfügbarkeit erhalten, während die Korrektheit abnimmt

Ein zwischengespeicherter Wetterwert kann für die Anzeige ausreichen, aber beim Schließen von Fenstern während eines Sturms unsicher sein. Ein CPU-Modell kann langsam, aber korrekt antworten, während ein allgemeines Ergebnis vollständig wirken und den Agenten in die Irre führen kann. Circuit Breaker schützen die Kapazität, nicht die semantische Qualität.

Der Katalog Circuit Breaker für Agenten überträgt das Circuit-Breaker-Prinzip auf Agenten-Tools und weist auf die Notwendigkeit von Fallbacks und Beobachtbarkeit hin. Bei einem Agenten muss das Ergebnis eines geöffneten Circuits strukturiert bleiben, damit der Planer nicht verfügbare Informationen von einer negativen Antwort unterscheiden kann.

Die Fehlergrenze liegt bei jeder Aktion, die das aktuelle Ergebnis des fehlenden Tools benötigt. In diesem Fall sollte der Vorgang sicher fehlschlagen, die nicht verfügbare Abhängigkeit offengelegt und eine Genehmigung oder ein späterer erneuter Versuch angefordert werden, anstatt stillschweigend veraltete oder schwächere Informationen einzusetzen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Einen Tool-Fehler einspielen und die Isolation nachvollziehen

Wählen Sie ein nicht destruktives Tool aus und spielen Sie Timeouts, Fehler und langsame Antworten ein, während gemischte Workflows weiterlaufen. Erfassen Sie den Breaker-Zustand, das Fehlerfenster, parallele Aufrufe, die Warteschlangentiefe, den ausgewählten Fallback und die Wiederherstellungsprüfungen. Vergewissern Sie sich, dass nicht betroffene Tools ihre normale Latenz beibehalten.

Testen Sie die in CPU-Failover beschriebene Grenze für den CPU-Fallback, kennzeichnen Sie die beeinträchtigte Ausführung jedoch ausdrücklich und messen Sie, ob das Workflow-Zeitlimit weiterhin eingehalten wird. Stellen Sie sicher, dass eine halb geöffnete Prüfung keine große Anzahl wartender Anfragen auslösen kann.

Der Test ist nur dann bestanden, wenn die fehlerhafte Operation isoliert wird, Aufrufer einen strukturierten Status „Nicht verfügbar“ erhalten und die Wiederherstellung den Breaker nach kontrollierten Prüfungen schließt. Wenn zwischengespeicherte oder alternative Ergebnisse eine Aktion verändern, fügen Sie vor der Aktivierung dieses Fallbacks eine Richtlinienfreigabe hinzu.