So implementiert man automatisches Wiederholen für Agent-CLIs wie Claude Code und Codex

18.04.2026

So implementiert man automatisches Wiederholen für Agent-CLIs wie Claude Code und Codex

Automatisches Wiederholen mag wie ein kleiner Schalter aussehen, aber in der Engineering-Praxis ist es weit mehr als das. Hallo Produzenten, ich bin Yu Kun, HagiCode-Produzent. Heute geht es nicht um leere Phrasen, sondern darum, wie man das automatische Wiederholen für Agent-CLIs wie Claude Code und Codex wirklich richtig macht – sodass Fehler abgefangen werden, ohne das System in eine endlose Wiederholungsschleife zu stürzen.

Hintergrund

Wenn Sie sich in letzter Zeit auch mit KI-Programmierung beschäftigen, sind Ihnen diese Probleme wahrscheinlich schon begegnet: Die Aufgabe bricht nicht sofort ab, sondern scheitert auf halber Strecke.

Bei normalen HTTP-Anfragen bedeutet das meistens einfach einen erneuten Versuch, höchstens mit exponentiellem Backoff. Bei Agent-CLIs ist das aber anders. Tools wie Claude Code und Codex werden typischerweise streaming-basiert ausgeführt, die Ausgabe kommt stückweise, und dabei werden Thread, Session oder Resume-Token gebunden. Mit anderen Worten, es geht nicht darum, ob „diese Anfrage fehlgeschlagen ist”, sondern:

• Ist der bereits ausgegebene Inhalt noch gültig?
• Kann der aktuelle Kontext fortgesetzt werden?
• Soll dieser Fehler automatisch wiederhergestellt werden?
• Wenn ja, wann erneut versuchen, was senden, soll der ursprüngliche Kontext wiederverwendet werden?

Viele Teams schreiben beim ersten Versuch die naivste Version: Bei Fehler einfach nochmal probieren. Das ist ein natürlicher Gedanke, aber im Projekt tauchen dann die Probleme auf:

• Manche Fehler sind temporäre Störungen, werden aber als endgültiges Fehlschlagen behandelt
• Manche Fehler sind nicht wert, wiederholt zu werden, werden aber vom System ständig wiederholt
• Anfragen mit Thread und ohne Thread werden gleich behandelt
• Der Backoff hat keine Grenzen, Backend-Anfragen überlasten sich selbst

HagiCode ist bei der Integration verschiedener Agent-CLIs ebenfalls in diese Fallen getappt. Insbesondere bei Codex wurde ein reconnect-Befehl nicht als wiederholbarer Endzustand erkannt, wodurch der bestehende Wiederherstellungsmechanismus gar nicht erst greifen konnte. Das Problem war also nicht, dass das System kein automatisches Wiederholen hatte, sondern dass es nicht erkannte, dass „dieser Versuch es wert ist, wiederholt zu werden”.

Deshalb ist der Kernpunkt dieses Artikels klar: Automatisches Wiederholen ist kein Knopf, sondern ein Schichtendesign.

Über HagiCode

Die in diesem Artikel vorgestellte Lösung stammt aus der echten Praxis im HagiCode Projekt. HagiCode zielt nicht darauf ab, nur ein Modell anzubinden, sondern die Streaming-Nachrichten, Tool-Aufrufe, Fehlerwiederherstellung und Session-Kontexte verschiedener Agent-CLIs zu einem langfristig wartbaren Ausführungsmodell zu vereinheitlichen.

Eine meiner größten Sorgen ist, wie man KI-Programmierung wirklich in der Engineering-Praxis verankert. Demos zu schreiben ist nicht schwer, schwer ist es, Demos zu etwas zu machen, das ein Team langfristig nutzen möchte. HagiCode nimmt automatisches Wiederholen ernst, nicht weil die Funktion fortschrittlich aussieht, sondern weil bei langen Streaming-, fortsetzbaren CLI-Ausführungen, die nicht stabil angebunden sind, der Benutzer keinen intelligenten Assistenten sieht, sondern einen Kommandozeilen-Wrapper, der ständig abbricht.

Wenn Sie einen ersten Eindruck gewinnen möchten, hier zwei Einstiegspunkte:

• GitHub: github.com/HagiCode-org/site
• Website: hagicode.com

Übrigens ist HagiCode mittlerweile auch auf Steam erhältlich – wer Steam hat, kann sich die Wunschliste hinzufügen:

• Steam-Store-Seite (Wunschliste / Details)

Warum ist automatisches Wiederholen bei Agent-CLIs schwieriger als normal?

Die Antwort vorweg: Die Schwierigkeit liegt nicht im „nochmal nach ein paar Sekunden”, sondern im „kann man im ursprünglichen Kontext weitermachen?”.

Vergleichen Sie es mit einem langen Gespräch: Ein normaler API-Retry ist wie wenn die Leitung besetzt ist und man nochmal wählt. Ein Agent-CLI-Retry ist eher, als wenn der Gesprächspartner mitten im Satz die Verbindung verliert – man muss erst entscheiden, ob man zurückrufen soll, ob man von vorne anfangen muss und ob sich der andere noch an das Gespräch erinnert. Das sind zwei völlig verschiedene Engineering-Probleme.

Konkret gibt es vier typische Schwierigkeiten.

1. Es ist streaming-basiert

Sobald die Ausgabe an den Benutzer gesendet wurde, können Sie den Fehler nicht einfach verschlucken und heimlich neu starten. Da der erste Teil bereits sichtbar war, führt eine falsche Replay-Strategie zu doppeltem Text, fehlerhaftem Zustand und gestörten Tool-Aufruf-Lebenszyklen.

2. Es bindet typischerweise Session-Kontexte

Provider wie Codex binden Threads; Claude-Code hat Continuation Targets oder äquivalente Fortsetzungskontexte. Die Voraussetzung für automatisches Wiederholen ist nicht nur „dieser Fehler sieht wie eine temporäre Störung aus”, sondern auch „gibt es noch einen Träger, um die Ausführung fortzusetzen?”.

3. Nicht alle Fehler sind es wert, wiederholt zu werden

Netzwerkschwankungen, SSE-Idle-Timeouts, temporäre Upstream-Ausfälle – diese kann man versuchen. Aber bei Authentifizierungsfehlern, verlorenem Kontext oder wenn der Provider keine Resume-Fähigkeit hat, ist ein erneuter Versuch meist keine Wiederherstellung, sondern Lärmerzeugung.

4. Es braucht Grenzen

Unbegrenztes automatisches Wiederholen ist fast immer falsch. Ein Grundprinzip der Technik lautet: Fehlerwiederherstellung muss Grenzen haben. Das System muss wissen, wie oft es maximal versucht, wie lange es wartet und wann es aufgeben soll.

Gerade wegen dieser Merkmale hat HagiCode das automatische Wiederholen nicht als ein paar try/catch-Zeilen in einem Provider geschrieben, sondern als eine Shared-Capability-Schicht extrahiert.

HagiCodes Ansatz: Retry aus dem Provider herausziehen

HagiCodes aktuelle Implementierung lässt sich auf einen Satz komprimieren:

Eine gemeinsame Schicht verwaltet den Retry-Prozess einheitlich; konkrete Provider müssen nur zwei Fragen beantworten: Ist dieser Endzustand es wert, wiederholt zu werden? Kann der aktuelle Kontext fortgesetzt werden?

Das ist nicht kompliziert, aber entscheidend. Sobald die Verantwortlichkeiten getrennt sind, können Claude Code, Codex und andere Agent-CLIs dasselbe Gerüst nutzen. Modelle werden sich ändern, Tools werden sich ändern, Workflows werden upgegradet, aber die engineering-Basis bleibt bestehen.

Erste Schicht: Einheitlicher Koordinator verwaltet die Retry-Schleife

Der Kernimplementierungs-Ausschnitt sieht ungefähr so aus:

internal static class ProviderErrorAutoRetryCoordinator
{
    public static async IAsyncEnumerable<CliMessage> ExecuteAsync(
        string prompt,
        ProviderErrorAutoRetrySettings? settings,
        Func<string, IAsyncEnumerable<CliMessage>> executeAttemptAsync,
        Func<bool> canRetryInSameContext,
        Func<TimeSpan, CancellationToken, Task> delayAsync,
        Func<CliMessage, bool> isRetryableTerminalMessage,
        [EnumeratorCancellation] CancellationToken cancellationToken)
    {
        var normalizedSettings = ProviderErrorAutoRetrySettings.Normalize(settings);
        var retrySchedule = normalizedSettings.Enabled
            ? normalizedSettings.GetRetrySchedule()
            : [];

        for (var attempt = 0; ; attempt++)
        {
            var attemptPrompt = attempt == 0
                ? prompt
                : ProviderErrorAutoRetrySettings.ContinuationPrompt;

            CliMessage? terminalFailure = null;

            await foreach (var message in executeAttemptAsync(attemptPrompt)
                               .WithCancellation(cancellationToken))
            {
                if (isRetryableTerminalMessage(message))
                {
                    terminalFailure = message;
                    break;
                }

                yield return message;
            }

            if (terminalFailure is null)
            {
                yield break;
            }

            if (attempt >= retrySchedule.Count || !canRetryInSameContext())
            {
                yield return terminalFailure;
                yield break;
            }

            await delayAsync(retrySchedule[attempt], cancellationToken);
        }
    }
}

Dieser Code tut etwas sehr Einfaches, aber Effektives:

• Bei Zwischenfällen wird der Fehler nicht direkt weitergeleitet; der Koordinator prüft zuerst, ob eine Wiederherstellung möglich ist
• Erst wenn das Retry-Budget erschöpft ist, wird der endgültige Fehler an die obere Schicht weitergegeben
• Ab dem zweiten Durchlauf wird nicht mehr der ursprüngliche Prompt gesendet, sondern ein einheitlicher Continuation Prompt

Zweite Schicht: Retry-Strategie als Snapshot

Eine oft übersehene Frage: Wer entscheidet, ob diese Anfrage automatisches Wiederholen aktiviert?

HagiCodes Antwort: Nicht auf eine „aktuelle globale Konfiguration” verlassen, sondern die Strategie als Snapshot zusammen mit der Anfrage mitführen. So gehen bei Session-Warteschlange, Nachrichten-Persistenz, Ausführungsweiterleitung und Provider-Adaption die Strategie nicht verloren.

Dritte Schicht: Provider übernimmt nur Endzustand- und Kontextbeurteilung

Beim konkreten Claude Code oder Codex Provider ist die Verantwortung paradoxerweise sehr dünn. Verstehen Sie es als Verstärkung, nicht als Ersatz.

Für Codex muss der Provider beim Anschluss an den gemeinsamen Koordinator im Wesentlichen nur drei Dinge bereitstellen:

await foreach (var message in ProviderErrorAutoRetryCoordinator.ExecuteAsync(
                   prompt,
                   options.ProviderErrorAutoRetry,
                   retryPrompt => ExecuteCodexAttemptAsync(...),
                   () => !string.IsNullOrWhiteSpace(resolvedThreadId),
                   DelayAsync,
                   IsRetryableTerminalFailure,
                   cancellationToken))
{
    yield return message;
}

Die eigentlichen Provider-spezifischen Beurteilungen sind nur zwei:

• IsRetryableTerminalFailure
• canRetryInSameContext

Codex prüft, ob der Thread noch fortgesetzt werden kann; Claude Code prüft, ob das Continuation Target noch existiert. Backoff-Strategie, Retry-Anzahl und nachfolgende Prompts sollten nicht vom Provider neu erfunden werden.

Ein häufiger Fehler: Nicht alle Fehler sind retryable

Was in dieser Analyse am meisten hervorzuheben ist, ist nicht „wie man Retry implementiert”, sondern „wie man falsches Retry vermeidet”.

Das ursprüngliche Einstiegsproblem war, dass Codex eine reconnect-Nachricht nicht erkannt hatte. Intuitiv würden viele eine Minimallösung wählen: einen weiteren String-Präfix in die Whitelist aufnehmen. Das ist eher eine Demo-Lösung als eine langfristig wartbare Lösung.

HagiCode geht mittlerweile einen stabileren Weg: Anstatt nur auf einen bestimmten String zu achten, werden wiederherstellbare Endzustände einheitlich an den gemeinsamen Koordinator delegiert. Vorteile:

• Weniger anfällig gegen kleine Textänderungen
• Testabdeckung kann um „Endzustand-Envelopes” statt einzelner hartcodierter Texte aufgebaut werden
• Die Retry-Logik desselben Providers bleibt konsistenter

Grenze: Universaler bedeutet nicht großzügiger. Wenn der aktuelle Kontext nicht fortgesetzt werden kann, sollte auch bei fehlerähnlich scheinendem temporären Ausfall kein blindes Replay erfolgen.

Drei bewährte Praxistipps

1. Retry-Budget muss Grenzen haben

HagiCodes aktueller Standard-Backoff-Rhythmus:

• 10 Sekunden
• 20 Sekunden
• 60 Sekunden

Dieser Rhythmus passt nicht für alle Systeme, aber „Grenzen haben” muss bleiben. Sonst wird aus dem Wiederherstellungsmechanismus schnell ein Fehlerverstärker.

2. Continuation Prompt einheitlich halten

Das Projekt verwendet einen festen Continuation Prompt, sodass nachfolgende Attempts klar den Pfad „aktuellen Kontext fortsetzen” wählen. Das ist kein fancy Feature, aber in der Praxis unverzichtbar.

3. Shared Library und Adapter-Schicht beide testen

HagiCode hat beide Schichten mit Tests abgedeckt:

• Shared Provider testet „wurde wirklich automatisch fortgesetzt?”
• Adapter-Schicht testet „wurden Endfehler und Streaming-Nachrichten nicht beschädigt?”

Zusammenfassung

Auf einen Satz komprimiert:

Automatisches Wiederholen für Agent-CLIs wie Claude Code und Codex sollte am besten nicht als lokaler Trick innerhalb eines Providers implementiert werden, sondern als Kombination aus gemeinsamem Koordinator + Strategie-Snapshot + Kontextbeurteilung + Spiegelungstests.

Die Vorteile sind konkret:

• Logik nur einmal geschrieben, mehrere Provider nutzen sie
• Ob Retry erlaubt ist, verlässt zuverlässig die Ausführungskette
• Mit Kontext weitermachen, ohne Kontext rechtzeitig aufhören
• Das Frontend sieht einen stabilen Abschluss- oder Fehlerzustand, kein Zwischenrauschen

Wenn Ihnen dieser Artikel geholfen hat, werfen Sie auch einen Blick auf HagiCodes öffentliche Einstiegspunkte:

• GitHub: github.com/HagiCode-org/site
• Website: hagicode.com
• 30-minütige Praxis-Demo: www.bilibili.com/video/BV1pirZBuEzq/
• Desktop-Installation: hagicode.com/desktop/
• Steam: Steam-Store-Seite

Referenzmaterialien

• HagiCode Projekt-Homepage: https://www.hagicode.com
• HagiCode GitHub-Repository: https://github.com/HagiCode-org/site
• Offizielles Demo-Video: https://www.bilibili.com/video/BV1pirZBuEzq/
• Desktop-Installationsanleitung: https://www.hagicode.com/desktop/

Urheberrechtshinweis

Vielen Dank für Ihr Interesse. Wenn Sie diesen Artikel nützlich fanden, freuen wir uns über Likes, Lesezeichen und Shares. Dieser Inhalt wurde unter Mitwirkung von Künstlicher Intelligenz erstellt und vom Autor überprüft.

• Autor: newbe36524
• Original-Link: https://docs.hagicode.com/blog/2026-02-11-agent-cli-automatic-retry/
• Urheberrecht: Soweit nicht anders angegeben, stehen alle Blog-Artikel unter der BY-NC-SA-Lizenz. Bitte geben Sie die Quelle an!

Tags:

• Agent CLI
• Claude Code
• Codex
• Automatisches Wiederholen
• HagiCode

Anpassung der OpenSpec-Schritte zur Verbesserung der KI-Generierungsergebnisse

Hermes installieren und verwenden: Ein Schnellstart von der lokalen CLI bis zur Feishu-Integration