Lang laufende KI-Agenten brauchen dauerhafte Kanäle

Die Dokumentation zum Background Mode von OpenAI beschreibt inzwischen ein typisches Agentenproblem: Reasoning-Aufgaben können Minuten dauern, Entwickler können eine Antwort per ID abfragen, die Antwort abbrechen und einen Stream ab einer gespeicherten Sequenznummer fortsetzen.¹

Was sind die wichtigsten Erkenntnisse?

• Eine lang laufende Agentenausführung braucht eine Adresse. Der Client muss sich wieder mit derselben Arbeit verbinden, ab einem bekannten Cursor streamen, einen Steuerbefehl senden, die Ausführung abbrechen und Nachweise prüfen können.
• Polling allein bietet nur einen dünnen Vertrag. Polling kann einen Status melden, aber ernsthafte Agentenarbeit braucht auch Befehle, Ereignisverläufe, fortsetzbare Streams, Artefakte, Autorisierung und Prüfpunkte.
• Dauerhafte Ausführung löst nur einen Teil des Systems. Arbeitsabläufe im Stil von Temporal bewahren Ausführungszustand und Ereignisverlauf, doch der Benutzer braucht trotzdem eine dauerhafte Kommunikationsfläche rund um die laufende Arbeit.²³
• WebSockets helfen, aber ein Socket ist nicht die ganze Adresse. Eine unterbrochene Verbindung darf dem Benutzer nicht den Weg zurück zur Agentenausführung nehmen.
• Die Produktoberfläche zählt. Der Benutzer sollte eine zusammenhängende Ausführung mit Nachweisen, Entscheidungen und nächsten Schritten sehen, nicht verstreute Protokolle und optimistischen Statustext.

Lang laufende KI-Agenten passen nicht in das alte Anfrage-Antwort-Muster. Eine normale Anfrage hat einen Endpunkt, eine Antwort und ein Timeout. Eine ernsthafte Agentenausführung hat eine Dauer, einen Ereignisverlauf, Zwischenartefakte, Eingriffe durch Benutzer, Modell- und Toolzustand, Abbruchregeln und einen Menschen, der gehen und später zurückkommen kann.

Was fehlt, ist keine weitere Chatnachricht. Was fehlt, ist ein dauerhafter Kanal: eine stabile Adresse für ein laufendes Stück Arbeit.

Ich habe bereits argumentiert, dass verwaltete Agenten Laufzeitinfrastruktur übernehmen und dass Ausführungsspuren von Agenten zum Laufzeitvertrag werden. Dauerhafte Kanäle liegen zwischen diesen beiden Ideen. Eine Ausführungsspur belegt, was passiert ist. Eine verwaltete Ausführungsumgebung hält die Arbeit am Leben. Ein dauerhafter Kanal ermöglicht es dem Produkt und dem Benutzer, mit der Arbeit zu interagieren, solange sie läuft.

Was bricht im alten Anfragemodell?

Das alte Webmodell nimmt an, dass Rechenarbeit innerhalb einer Anfrage abgeschlossen wird oder in einen Hintergrundjob wandert. Die Datenbank speichert den dauerhaften Zustand. Der Anwendungsserver bleibt zustandslos. Ein Client kann die Seite neu laden, einen anderen Server erreichen und dieselbe Datenbankzeile lesen.

Agentenarbeit belastet dieses Modell auf drei Arten. Sie kann Minuten oder Stunden laufen. Sie trägt Prozesszustand, der sich nicht sauber auf einen einzelnen Datenbankeintrag reduzieren lässt. Und sie braucht bidirektionale Steuerung: beobachten, unterbrechen, freigeben, umlenken, abbrechen und fortsetzen.

Zak Knill hat denselben Druck als Routingproblem beschrieben. In seinem Beitrag vom Mai 2026 argumentiert er, dass lang laufende, zustandsbehaftete und interaktive Agentenarbeit ein adressierbares Grundelement braucht, das den arbeitenden Prozess erreichen kann, nicht nur die Datenbank, die seine Ergebnisse speichert.⁴ Der nützliche Kern dieses Rahmens: Der Client möchte sagen können: „Stelle Befehl Y an Ausführung X zu“, selbst wenn der ursprüngliche Socket, Worker, Tab oder Prozess verschwunden ist.

Für einfache Aufgaben reichen Hintergrundjobs weiterhin aus. Eine Bildgrößenänderung, ein Rechnungsexport oder eine nächtliche Synchronisierung braucht vielleicht nur queued, running, succeeded oder failed. Agentenarbeit überschreitet diese Grenze, sobald der Benutzer die Arbeit steuern muss, bevor sie fertig ist.

Warum reicht Polling nicht aus?

Polling gibt dem Client eine Möglichkeit zu fragen: „Sind Sie schon fertig?“ Es liefert aber keinen vollständigen Interaktionsvertrag.

Der Background Mode von OpenAI enthält Polling, weil Polling das Timeout-Problem löst. Die Dokumentation weist Entwickler an, eine Hintergrundantwort abzurufen, solange der Status queued oder in_progress bleibt, und aufzuhören, sobald ein Endzustand erreicht ist.¹ Dieselbe Seite stellt außerdem Abbruch und Stream-Fortsetzung mit einem sequence_number-Cursor bereit. Das weist über einfaches Polling hinaus auf einen reicheren Ausführungsvertrag.¹

Ein Produkt, das bei Polling stehen bleibt, verteilt Agentenzustand meist auf zu viele Stellen:

Polling kann ein Zugriffsweg bleiben. Der Fehler besteht darin, Polling als Produktvertrag zu behandeln.

Was sollte ein dauerhafter Kanal enthalten?

Ein dauerhafter Kanal ist ein benannter Kommunikationsvertrag rund um eine Ausführung. Die Umsetzung kann eine Engine für Arbeitsabläufe, eine Warteschlange, eine Ereignistabelle, einen WebSocket, einen SSE-Stream, ein Pub/Sub-Topic, eine verwaltete Agentensitzung oder eine Mischung daraus verwenden. Der Produktvertrag ist wichtiger als der Transport.

Der Mindestvertrag besteht aus neun Teilen:

Jedes Ereignis braucht einen Typ, eine Sequenznummer, einen Zeitstempel, einen Akteur, eine Payload-Referenz und eine Schwärzungsrichtlinie. Ohne diese Struktur wird das Ereignisprotokoll zu einem weiteren Chattranskript.

Der Kanal braucht außerdem Urteilsvermögen. Streamen Sie nicht jedes Token, wenn der Benutzer Entscheidungen braucht. Verstecken Sie Toolfehler nicht hinter einem freundlichen Spinner. Machen Sie aus einem laufenden Agenten keinen Benachrichtigungssturm. Ein guter Kanal zeigt die wenigen Ereignisse, die dem Benutzer helfen, der Arbeit zu vertrauen, sie zu steuern oder sie zu stoppen.

Wie deuten bestehende Systeme auf dieses Muster hin?

Temporal gibt der Ausführungsseite ein ausgereiftes Vokabular. Die Ausführung eines Arbeitsablaufs hat einen Ereignisverlauf, Replay, deterministischen Ablaufcode und Activities für Arbeit mit der Außenwelt, etwa API-Aufrufe, Datenbankabfragen, LLM-Aufrufe und Datei-I/O.² Die Dokumentation von Temporal zum TypeScript Message Passing beschreibt Arbeitsabläufe als zustandsbehaftete Dienste, die Queries, Signals und Updates empfangen. Clients können über eine Arbeitsablauf-ID ein Handle abrufen, Zustand abfragen, Signale senden und Updates ausführen.³

Dieses Modell passt gut zu Agentenarbeit. Queries beantworten: „Welchen Zustand meldet die Ausführung?“ Signals beantworten: „Bitte ändern Sie die Richtung.“ Updates beantworten: „Führen Sie eine nachverfolgbare Änderung aus und geben Sie ein Ergebnis zurück.“ Der Ereignisverlauf beantwortet: „Was ist passiert?“ Ein Team muss Temporal nicht einsetzen, um aus dieser Form zu lernen. Aber die Form gibt Agentenprodukten ein besseres Vokabular als „Hintergrundjob plus Chat“.

Cloudflare Durable Objects zeigen auf einen anderen Teil: adressierbare Koordination. Cloudflare beschreibt jedes Durable Object als global eindeutige Instanz mit Speicher, nützlich für zustandsbehaftete Koordination über mehrere Clients hinweg.⁵ Die WebSocket-Dokumentation beschreibt langlebige bidirektionale Verbindungen und Hibernation, durch die Clients verbunden bleiben, während das Objekt schläft, und das Objekt geweckt wird, sobald eine Nachricht eintrifft.⁶ Das macht Durable Objects nicht zu einer universellen Agentenlaufzeit. Es zeigt aber, warum sich ein adressierbares Koordinationsobjekt für Live-Oberflächen von Agenten natürlich anfühlt.

Der Beitrag von Anthropic zu lang laufenden Agenten ergänzt die Perspektive menschlicher Arbeit. Er beschreibt, dass Agenten über viele Kontextfenster hinweg weiterhin Schwierigkeiten haben, und zeigt ein Muster, bei dem spätere Sitzungen schrittweise Fortschritt erzielen und klare Artefakte für die nächste Sitzung hinterlassen.⁷ Dauerhafte Kanäle sollten diese Artefakte in die Produktoberfläche tragen, statt sie in privaten Protokollen zu vergraben.

Was würde ich zuerst bauen?

Ich würde mit einem kleinen Ausführungsdienst beginnen, nicht mit einer großen Orchestrierungsplattform.

Legen Sie eine runs-Tabelle mit Eigentümerschaft, Status, Zeitstempeln und aktueller Zusammenfassung an. Legen Sie eine run_events-Tabelle oder einen Stream mit monoton steigenden Sequenznummern an. Speichern Sie große Payloads und Artefakte separat und referenzieren Sie sie aus Ereignissen. Ergänzen Sie einen fortsetzbaren Stream-Endpunkt und einen Endpunkt für typisierte Signale. Machen Sie den Abbruch idempotent. Schreiben Sie jeden Zustandsübergang in das Ereignisprotokoll.

Begrenzen Sie dann das Ereignisvokabular:

Die UI kann nun eine zusammenhängende Ausführung anzeigen. Der Benutzer kann gehen, zurückkommen, Ereignisse prüfen, Artefakte ansehen und von derselben Adresse aus steuern. Der Agent muss Erfolg nicht mehr in Prosa behaupten, sondern kann Nachweise an Zustandsübergänge hängen.

Was sollten Teams vermeiden?

Vermeiden Sie drei Abkürzungen.

Erstens: Vermeiden Sie ein reines Chattranskript. Chat kann Arbeit anstoßen und Rückfragen sammeln. Er sollte nicht das einzige Laufzeitobjekt für eine lang laufende Aufgabe sein.

Zweitens: Vermeiden Sie rohes Token-Streaming als wichtigste Fortschrittsoberfläche. Token-Streams helfen Entwicklern beim Debugging von Latenz, aber die meisten Benutzer brauchen Meilensteine, Blockaden, Artefakte und Entscheidungen. Ein dauerhafter Kanal kann rohe Ereignisse weiterhin für fachkundige Prüfung verfügbar machen.

Drittens: Vermeiden Sie das Durchsickern privater Prozessdetails. Eine öffentliche Produktoberfläche sollte Nachweise zeigen, nicht private Prompts, Hook-Inhalte, lokale Dateipfade oder interne Bewertungsmechanik. Der Benutzer braucht genug, um der Arbeit zu vertrauen. Er braucht nicht jeden internen Trick, der die Arbeit möglich gemacht hat.

Diese Datenschutzlinie gilt auch für öffentliches Schreiben über Agentensysteme. Teilen Sie den Vertrag. Halten Sie die private Mechanik privat.

Wie verändert ein dauerhafter Kanal die Bewertung?

Ein dauerhafter Kanal macht Bewertung weniger theatralisch.

Statt zu fragen, ob die finale Antwort plausibel klingt, kann der Prüfer die Ausführung untersuchen:

• Hat die Ausführung mit dem richtigen Eigentümer, den richtigen Berechtigungen und dem richtigen Umfang begonnen?
• Hat der Agent vor dem Handeln einen Plan ausgegeben?
• Stammt jedes behauptete Artefakt aus einem aufgezeichneten Ereignis?
• Haben Fehler nützliche Prüfpunkte erzeugt?
• Haben Benutzersignale die Ausführung wie erwartet verändert?
• Endete ein Abbruch mit genau einem Endzustand?
• Zitiert der Abschlussbericht Nachweise aus dem Ereignisprotokoll?

Diese Liste macht die Nachweisschwelle zu etwas, das die Ausführungsumgebung direkt unterstützen kann. Sie verbindet sich außerdem mit der Aufräumebene: Viele Agentenprodukte werden gewinnen, indem sie unordentliche Ausführungen verständlich, fortsetzbar und prüfbar machen.

Kurzzusammenfassung

Lang laufende KI-Agenten brauchen dauerhafte Kanäle, weil der Benutzer einen stabilen Weg zurück zur Arbeit braucht. Polling kann Status melden, aber es kann den ganzen Vertrag nicht allein tragen. Eine gute Agentenausführung braucht eine Arbeitsablauf-ID, geordnete Ereignisse, fortsetzbare Streams, typisierte Signale, idempotenten Abbruch, Artefaktreferenzen, Berechtigungen und menschenlesbare Prüfpunkte. Dauerhafte Ausführung hält die Arbeit am Leben; dauerhafte Kanäle ermöglichen es Benutzer und Produkt, mit ihr zu interagieren.

FAQ: Lang laufende KI-Agenten und dauerhafte Kanäle

Brauchen lang laufende KI-Agenten Temporal?

Nein. Temporal gibt Teams ein starkes Vokabular für Arbeitsabläufe und ein ausgereiftes Ausführungsmodell, aber der Vertrag eines dauerhaften Kanals kann auf einfacherer Infrastruktur laufen. Beginnen Sie mit stabilen Ausführungs-IDs, geordneten Ereignissen, fortsetzbaren Streams, typisierten Befehlen und Artefakten. Wechseln Sie zu einer Engine für Arbeitsabläufe, wenn Wiederholungen, Replay, Timer und operative Skalierung es rechtfertigen.

Reichen WebSockets für Agentenfortschritt aus?

Nein. WebSockets liefern eine bidirektionale Live-Verbindung. Das Produkt braucht trotzdem eine dauerhafte Adresse, einen Ereignisverlauf, einen Wiederverbindungs-Cursor, Berechtigungen und Endzustände. Ein Socket kann einen Kanal transportieren, sollte aber nicht den ganzen Kanal definieren.

Ist Polling immer schlecht?

Nein. Polling funktioniert für einfache Statusprüfungen und kann als Ausweichpfad bestehen bleiben. Probleme beginnen, wenn Polling zur einzigen Möglichkeit wird, eine lang laufende Agentenausführung zu beobachten, zu steuern oder wiederaufzunehmen.

Was sollte ein kleines Team zuerst bauen?

Bauen Sie eine runs-Ressource und ein nur anhängbares run_events-Protokoll. Ergänzen Sie einen fortsetzbaren Stream, sobald das Ereignisprotokoll Sequenznummern hat. Fügen Sie typisierte Signale nur für Befehle hinzu, die das Produkt sicher einhalten kann: approve, pause, revise, add context und cancel.

Was gehört in Ereignisse einer Agentenausführung?

Zeichnen Sie Zustandsübergänge, Pläne, Toolstarts und -abschlüsse, Artefakterstellung, menschliche Signale, Blockaden, Abbrüche, Fehlschläge und Abschlüsse auf. Halten Sie sensible Payloads aus Inline-Ereignistext heraus. Speichern Sie private Details hinter geschwärzten Referenzen und Zugriffskontrollen.

Quellen