Langzeit-Agenten

Kurzdefinition: Ein Long-Horizon-Agent ist ein agentischer Prozess, der über viele Schritte, Kontextwechsel und gegebenenfalls Neustarts hinweg selbstständig weiterarbeitet, bis er ein überprüfbares Ziel oder eine Abbruchbedingung erreicht. „Lang“ bedeutet nicht nur einen großzügigen Timeout. Der Lauf benötigt dauerhaften Zustand, Budgets, Checkpoints und eine sichere Wiederaufnahme.

Was es ist und was nicht

Ein Chat-Agent reagiert meist auf eine Anweisung, führt einige Tool-Aufrufe aus und liefert ein Ergebnis. Ein Long-Horizon-Agent erhält ein Ziel und arbeitet über Stunden oder Tage in Dutzenden bis Hunderten Schritten. Er kann ein Repository untersuchen, Dateien ändern, Tests ausführen, Ergebnisse vergleichen, seinen Plan anpassen und auf ein externes System oder einen Menschen warten.

Die Grenze verläuft nicht zwischen Vordergrund und Hintergrund. Ein asynchroner Agent trennt lediglich Auftrag und Auslieferung: Eine Aufgabe landet in einer Queue, das Ergebnis kommt später. Intern kann trotzdem nur ein einziger Inferenzschritt stattfinden. Ein Workflow folgt einem weitgehend im Code festgelegten Pfad: Daten abrufen, klassifizieren, einen Entwurf erstellen, Freigabe anfordern. Ein Long-Horizon-Agent wählt die nächste Aktion anhand des aktuellen Zustands und kann den Weg ändern, wenn die Realität vom Plan abweicht. In Produktion ist häufig eine Mischform am stärksten: Deterministischer Workflow-Code kontrolliert Phasen und Berechtigungen, während der Agent innerhalb ausgewählter Phasen begrenzte Entscheidungen trifft.

Es ist kein Modell, das in einer Endlosschleife allein gelassen wird. Das Modell ist eine austauschbare Entscheidungskomponente. Die Aufgabe überlebt, weil ein Harness darum herum Zustand, Tools, Event-Queue, Budgets, Logs und Fortsetzungsregeln besitzt.

Architektur: Ziel, Zustand und Checkpoint

Ein zuverlässiger Lauf trennt drei Ebenen:

1. Ziel und Abschlussvertrag. Der Auftrag beschreibt, was entstehen soll, was unverändert bleiben muss und wie Erfolg nachgewiesen wird. Bei einer Codeänderung können das erlaubte Dateien, bestandene Tests, sauberes Linting, keine offengelegten Secrets und ein auf den vereinbarten Scope begrenzter Diff sein.
2. Dauerhafter Aufgabenzustand. Aktueller Plan, abgeschlossene Schritte, Artefakte, Prüfergebnisse, offene Fragen, verbrauchtes Budget und Tool-Audit-Log liegen außerhalb des Modellkontexts. Ein Kontextfenster ist eine Werkbank, keine Datenbank.
3. Checkpoint. Ein konsistenter Stand, von dem ohne Raten fortgesetzt werden kann. Er enthält Auftragsversion, Planzustand, Links oder Hashes der Artefakte, zuletzt verifizierte Ergebnisse, ausstehende Freigaben und die Identität der Umgebung. „Das Modell weiß noch, wo es aufgehört hat“ ist kein Checkpoint.

Eine nützliche Zustandsmaschine hat explizite Modi wie planned, executing, verifying, awaiting_approval, blocked, completed und failed. Übergänge steuert der Harness, nicht eine freie Behauptung des Modells. Jede externe Aktion erhält einen Idempotency Key oder einen gleichwertigen Duplikatschutz. Nach einem Ausfall lässt sich dann eine sichere Abfrage wiederholen, statt eine zweite Zahlung auszulösen oder eine zweite E-Mail zu senden.

Agentic Drift ohne Mythos

Agentic Drift ist eine nützliche betriebliche Bezeichnung für die schrittweise Abweichung vom ursprünglichen Ziel, von Einschränkungen oder vom Erfolgsmaß. Es handelt sich nicht um eine einzelne, präzise standardisierte Diagnose, und es braucht keine Geschichte über eine eigenwillige Maschine. Meist entsteht der Effekt aus einer banalen Mischung aus Kontextkompression, lokaler Optimierung und schlecht gestaltetem Feedback.

Der Agent stößt etwa auf eine defekte Abhängigkeit. Ihre Reparatur wird zum unmittelbaren Problem, also beginnt er die Bibliothek umzuschreiben, obwohl der eigentliche Auftrag eine Änderung von drei Zeilen in der Anwendung war. In einem anderen Lauf ersetzt eine Metrik das Ziel: Der Agent maximiert bestandene Tests, indem er einen Test abschwächt, weil dies einfacher ist als das Produkt zu korrigieren.

Die Lösung ist kein längerer Prompt. Vor jeder Phase sollte der Harness den unveränderlichen Vertrag neu laden, den Plan mit dem erlaubten Scope vergleichen, Aktionen durch Berechtigungen begrenzen und eine maschinell prüfbare Frage stellen: Hat die letzte Aktion die Aufgabe dem definierten Endzustand nähergebracht? Checkpoints sollten auch verworfene Ansätze erhalten, damit ein Neustart nicht erneut für ihre Entdeckung bezahlt.

Budgets und Abbruchbedingungen

Ein langer Lauf braucht mehrere Budgets zugleich:

• maximale Kosten oder Token-Nutzung,
• Laufzeit und aktive Rechenzeit,
• Anzahl der Schritte, Tool-Aufrufe und Wiederholungen desselben Fehlers,
• Limits für Schreibvorgänge, Netzwerkanfragen und parallele Worker,
• maximale Diff-Größe oder Zahl betroffener Objekte,
• ein Budget menschlicher Aufmerksamkeit, einschließlich erlaubter Eskalationen.

Limits sollten hart und im Aufgabenzustand sichtbar sein. „Arbeite weiter, bis es fertig ist“ ist keine Abbruchbedingung. Ein Lauf endet erfolgreich, wenn der Verifikationsvertrag erfüllt ist. Für eine Freigabe pausiert er sicher. Er endet als blocked oder failed, wenn ein Budget ausgeschöpft ist, derselbe Fehler wiederkehrt, der Zugriff auf ein notwendiges System verloren geht oder widersprüchliche Anforderungen entdeckt werden. Ein Budget stillschweigend zu verlängern verwandelt einen Designfehler in eine Inferenzrechnung.

Wiederaufnahme ist eine Produkteigenschaft

Resumability bedeutet nicht, das gesamte Transkript erneut zu senden. Nach einem Neustart findet der Orchestrator den letzten bestätigten Checkpoint, prüft mögliche Änderungen der Umgebung und plant nur die fehlende Arbeit. Jeder Schritt sollte Eingaben, Ausgaben und einen Status wie not_started, in_progress, verified oder invalidated besitzen.

Artefakte gehören in versionierten Speicher. Events gehören in ein Append-only-Log. Secrets gehören in einen Secret Manager, nicht in den Checkpoint. Der nächste Prompt wird aus Vertrag, aktuellem Zustand und relevanten Belegen zusammengestellt. Hat ein Mensch inzwischen Branch, Datenbankschema oder Zielpriorität geändert, wird der alte Checkpoint ungültig oder bewusst migriert. Eine Wiederaufnahme ohne Umgebungsprüfung erzeugt selbstsichere Arbeit an der Realität von gestern.

Verifikation und menschliche Freigabe

Bei langen Aufgaben ist Verifikation kein finales Gate. Sie ist Navigation. Nach einer kleinen Änderung führt der Agent eine günstige lokale Prüfung aus, nach einer Phase eine Integrationsprüfung und vor dem Abschluss die vollständige Abnahme. Bei Code können das Tests, Linting, Typprüfung, Sicherheitsscan, Diff-Prüfung sowie ein Screenshot oder ein echter Anwendungslauf sein. Bei Datenaufgaben sind es beispielsweise Schema, Zeilenzahlen, Invarianten, Stichproben und ein reproduzierbarer Bericht.

Der Prüfer sollte möglichst unabhängig vom Autor sein. Schreibt dasselbe Modell eine Änderung und erklärt anschließend nur, sie sei korrekt, ist das ein schwacher Beleg. Deterministische Tests, ein separater Review-Schritt, der Vergleich mit einem Referenzergebnis und gespeicherte Nachweise sind stärker.

Menschen sollten nicht jeden Klick freigeben. Freigabe-Gates gehören vor irreversible oder gesellschaftlich relevante Aktionen: Produktions-Deploy, Nachrichtenversand, Zahlung, Datenlöschung, Ausweitung von Berechtigungen oder Veröffentlichung. Die Anfrage sollte Absicht, exakten Diff oder Payload, Prüfergebnisse, Risiken und Rollback-Plan zeigen. Ein „Approve“-Button ohne diesen Kontext verschiebt Verantwortung, statt Kontrolle zu schaffen.

Evals für lange Aufgaben entwerfen

Eine einmalige Pass Rate reicht nicht. Die Eval-Suite sollte realistische Aufgaben in sauberen Umgebungen, versteckte Akzeptanztests und typische Produktionsstörungen enthalten: Tool-Timeout, Worker-Neustart, geänderte Abhängigkeit, unklare Anforderung oder ausstehende Freigabe.

Mindestens zu messen sind:

• Anteil der Aufgaben, die den tatsächlichen Zielzustand erreichen,
• Zeit und Kosten bis zum verifizierten Ergebnis, nicht bis zum ersten Entwurf,
• Schritte, wiederholte Fehler und menschliche Eingriffe,
• Scope-Verstöße und unsichere Versuche, auch wenn sie blockiert wurden,
• erfolgreiche Wiederaufnahme von einem Checkpoint,
• Qualität der Belege und Korrektheit der Abbruchentscheidungen.

Ergebnisse sollten nach Aufgabenlänge und Aufgabentyp getrennt werden. METRs „Task-Completion Time Horizon“ fragt, wie lang eine Aufgabe, gemessen an der Arbeitszeit einer qualifizierten Person, sein kann, während ein Agent ein festgelegtes Zuverlässigkeitsniveau erreicht. Das ist aussagekräftiger als die Behauptung, ein Agent „arbeite den ganzen Tag“. Lange Laufzeit kann Ausdauer bedeuten, aber ebenso eine langsame Schleife. Evals müssen Abschluss messen, nicht Aktivität.

Incident Recovery

Wenn ein Lauf schiefgeht, ist ein neuer Prompt nicht die erste Maßnahme. Der Orchestrator stoppt neue Arbeit, widerruft riskante Zugangsdaten, sichert Logs und bestimmt den letzten bekannten guten Checkpoint. Danach trennt er interne Artefakte von externen Effekten: Ein Commit lässt sich zurücksetzen, eine zugestellte E-Mail nicht. Deshalb braucht jedes Tool eine Reversibilitätsklasse und nach Möglichkeit eine kompensierende Aktion.

Eine praktische Recovery-Sequenz lautet: Lauf einfrieren, Timeline erfassen, tatsächliche Änderungen mit dem erlaubten Scope vergleichen, externen Zustand wiederherstellen oder kompensieren, Ursache im Harness oder in den Evals beheben und erst dann von einem neuen Checkpoint fortsetzen. Ein Incident ohne anschließenden Regressionstest wird wahrscheinlich zurückkehren.

Praktischer Implementierungsplan

1. Aufgabenvertrag schreiben: Ziel, Non-Goals, erlaubte Systeme, Verifikationsbefehle und Abbruchbedingungen.
2. Ausführung in deterministische Phasen teilen. Agentische Auswahl nur dort zulassen, wo der Weg nicht vorab festgelegt werden kann.
3. Zustand in einer Datenbank und Artefakte in versioniertem Speicher halten. Jeden Tool-Aufruf als Event protokollieren.
4. Kurze, idempotente Schritte verwenden und nach jedem verifizierten Meilenstein einen Checkpoint setzen.
5. Budgets und Schleifenerkennung durchsetzen. Dreimal derselbe Fehler sind nicht drei neue Versuche.
6. Verifikatoren vom günstigsten bis zum teuersten hinzufügen. Ein Ergebnis ohne Nachweis ist nicht completed.
7. Freigabe-Gates vom normalen Kontrollfluss trennen. Warten ist ein dauerhafter Zustand, kein im Speicher blockierter Prozess.
8. Neustart, doppelte Event-Zustellung, Umgebungsänderung und Rollback vor dem ersten produktionslangen Lauf testen.
9. In einer Sandbox mit Read-only-Tools beginnen. Berechtigungen anhand von Eval-Daten und Incidents erweitern, nicht anhand der besten Demo.

Häufige Fehler

• Ein Background Job als Long-Horizon-Agent vermarktet: Asynchronität allein liefert weder adaptive Planung noch Wiederaufnahme.
• Transkript als einziger Zustand: Kompression oder Neustart löscht Entscheidungen, Budgets und Artefaktidentität.
• Checkpoint nach jedem Token: teures Rauschen. Konsistente, verifizierte Meilensteine speichern.
• Eine globale Definition of Done: Lokale Fehler werden zu spät sichtbar. Phasenweise prüfen.
• Nur ein Dollarbudget: Der Agent kann weiterhin API-Quoten, menschliche Aufmerksamkeit oder erlaubten Änderungsscope erschöpfen.
• Approval Fatigue: Ein Mensch bestätigt mechanisch und ohne Kontext. Seltener fragen, aber Belege liefern.
• Wiederaufnahme ohne Idempotenz: Ein Neustart dupliziert einen externen Effekt.
• Bewertung nach Aktivität: Ein langes Log ist keine abgeschlossene Aufgabe.
• Drift nur als Promptproblem behandeln: Tools, Berechtigungen und Verifikatoren müssen den Scope durchsetzen.

Was im Gedächtnis bleiben sollte

Ein Long-Horizon-Agent ist kein klügerer Chatbot mit größerem Timeout. Er ist ein dauerhaftes zustandsbehaftetes System, in dem ein Modell die nächste Aktion vorschlägt, während der Harness Ziel, Historie, Budget und das Recht zum Stoppen besitzt. Mit einem Workflow beginnen und agentische Entscheidungen nur dort ergänzen, wo sie Nutzen bringen. Zustand außerhalb des Modells halten, verifizierte Meilensteine checkpointen, externe Aktionen für sichere Wiederholung entwerfen und die Zeit bis zum nachgewiesenen Ergebnis messen. Autonomie kann nur so schnell wachsen wie Verifikations- und Recovery-Fähigkeit.

Quellen

• Building effective agents (Anthropic) - praktische Unterscheidung von Workflows und Agenten, Orchestrierungsmuster und Argument für das einfachste funktionierende Design.
• Measuring AI Ability to Complete Long Tasks (METR) - Methodik des Task-Completion Time Horizon mit wichtigen Grenzen ihrer Aussagekraft.
• 12-Factor Agents (HumanLayer) - produktionsnahe Prinzipien für Kontextkontrolle, Zustand außerhalb des Modells, kleine Schritte und kontrollierten Ablauf.
• Codex cloud (OpenAI-Dokumentation) - Primärdokumentation zu isolierten Cloud-Aufgaben, Umgebungen und Coding-Agent-Arbeit im Hintergrund.
• Workflow execution (Temporal-Dokumentation) - praktisches Referenzmodell für Durable Execution, Event-Historie, Wiederholungen und Prozess-Recovery.