Long-Running AI Agent Runtime: Sessions und Checkpoints

Viacheslav Dubrov

2026-05-26 · Aktualisiert 2026-09-06 · 42 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Artikel-Update

Ursprünglich am 26. Mai 2026 veröffentlicht. Am 6. September 2026 geprüft und aktualisiert. Das Update behandelt neuere Runtime-Funktionen und Deployment-Optionen und enthält korrigierte Plattformvergleiche, Budgetkontrollen und Quelllinks.

Ein Agent Run kann mehrere Stunden dauern, der Worker-Prozess kann jedoch jederzeit neu starten. Der Runtime hält den Zustand des Runs vor, führt seine Tools aus und stellt ihn wieder her, wenn ein Tool Call auf halbem Weg abbricht. Das Model wählt weiterhin die nächste Aktion. Part 6 behandelt den Harness: den Code, der Context bereitstellt, Tool Calls prüft und entscheidet, ob die Arbeit abgeschlossen ist.

Was ist ein AI Agent Runtime?

Ein AI Agent Runtime ist die Infrastruktur, die einen Tool-using Agent nach dem Ende eines Model Calls weiterlaufen lässt. Er speichert den Session-Zustand, führt Tools aus, speichert Checkpoints, verwaltet Secrets, schreibt Traces, setzt Kostenlimits durch und definiert, wie der Service deployed wird. Das Model wählt die nächste Aktion. Der Runtime entscheidet, wo diese Aktion ausgeführt wird, zeichnet das Ergebnis auf und stellt den Run nach einem Fehler wieder her. Der Harness entscheidet, ob eine Aktion zulässig ist. Er ist kein Store, aber die Tabelle führt ihn auf, weil der Runtime ihn irgendwo ausführen muss.

Vier der fünf Primitives speichern Zustand oder begrenzen, was Code tun kann: Session, Sandbox, Checkpoint und Trace. Der Harness trifft die Entscheidungen über Memory, Tool Contracts und Berechtigungen. Dieser Artikel erklärt die Services und Stores, die er dafür benötigt. Part 6 erläutert seine Checks, Retries und Acceptance Tests.

Lange Runs brechen Annahmen über stateless Prozesse

Ein stateless Chat Endpoint kann den Request-Zustand in einem Prozess halten und ihn nach der Response verwerfen. Ein Long-Running Agent Run erstreckt sich über Worker-Neustarts, Deployments, Context Resets und Approval-Pausen. Der Worker-Prozess kann daher nicht mehr die Source of Truth sein.

Das OpenAI-Codex-Team berichtet in seinem Harness-Engineering-Bericht, wie lange diese Runs dauern:

„Wir sehen regelmäßig einzelne Codex Runs, die über sechs Stunden an einer einzigen Aufgabe arbeiten (oft, während die Menschen schlafen).“

Das Engineering-Team von Anthropic beschreibt das entsprechende Zustandsproblem in Effective harnesses for long-running agents:

„Die zentrale Herausforderung bei Long-Running Agents besteht darin, dass sie in diskreten Sessions arbeiten müssen und jede neue Session ohne Erinnerung an das beginnt, was zuvor passiert ist.“

Beide Beobachtungen führen zum selben Runtime-Design: Zustand außerhalb des Workers persistieren und Worker austauschbar machen.

Die Session muss außerhalb des Worker-Prozesses liegen. Ein dauerhafter Store zeichnet Model Calls, Tool Intents und Ergebnisse sowie Approvals auf, damit ein anderer Worker nach einem Crash am letzten sicheren Punkt fortsetzen kann. Ein ausstehender externer Effekt muss vor diesem Resume reconciled werden, damit es als sicher gelten kann. Checkpoints ermöglichen dem Runtime außerdem, bei vollem Context Window eine frische Model Session zu starten, ohne die vollständige Historie erneut abzuspielen. In Anthropics Formulierung sind Harness-Instanzen disposable und restartbar; der dauerhafte Zustand liegt an anderer Stelle.

Fünf Primitives, die Sie vor dem Go-live platzieren sollten

Anthropics Scaling Managed Agents-Bericht liefert eine nützliche Terminologie für fünf Runtime-Verantwortlichkeiten. Der Harness treibt den Agent voran, während die Session aufzeichnet, was er getan hat, und die Sandbox Commands ausführt. Der Checkpoint gibt dem nächsten Worker einen Resume-Punkt; der Trace bewahrt Belege für späteres Debugging. Eine Implementierung kann Komponenten zusammenlegen, aber Verantwortlichkeiten und Fehlergrenzen müssen weiterhin klar benannt werden.

Session. Ein separat geschriebenes Append-only Event Log aus Model Calls, angeforderten und abgeschlossenen Tool Calls, Fehlern und Approvals. Eine Checkpoint-Datenbank unterstützt die Recovery, aber die Graph-State-Historie ist kein Ersatz für dieses Log.

Der Begriff ist überladen; deshalb verwendet dieser Artikel eine Benennung für drei Spans auf Anwendungsebene. Ein Thread ist die Conversation eines Users über mehrere Tage hinweg. Er ist der langlebigste Span und kann viele Runs enthalten.

Eine Model Session ist die kürzeste Einheit: ein zusammenhängender Abschnitt des Model Context. Compaction – der Schritt, der das Window zusammenfasst, damit die Arbeit fortgesetzt werden kann – verlängert eine Model Session, statt sie zu beenden. Ein Restart oder ein bewusst frischer Start beendet sie. Part 6 verwendet „Model Session“ in diesem Sinn.

In diesem Artikel bedeutet „Session“ das dauerhafte Log eines Runs. Mehrere Model Sessions können in ein Log schreiben, und ein Conversation Thread kann mehrere Run Logs enthalten. Für die Recovery wecken Sie den Run auf, laden seine Session, reconciliieren jeden ausstehenden Side Effect und setzen anschließend nach dem letzten Event fort: wake(sessionId) → getSession(id) → reconcile pending effects → resume from last event.

In LangGraph ist thread_id der Storage- und Retrieval-Key des Checkpointers für die Graph-State-Historie eines Threads (siehe LangGraph persistence); er definiert nicht die Conversation-, Model-Session- oder Event-Log-Grenzen dieses Artikels. Geben Sie dem Event Log eine eigene dauerhafte Run- oder Session-ID und legen Sie explizit fest, wie diese IDs auf LangGraph Threads abgebildet werden. Das OpenAI Agents SDK liefert zehn integrierte Session-Backends, darunter SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession und EncryptedSession (siehe die Sessions-Dokumentation). Sie halten eine veränderliche Conversation-History einschließlich Entfernung, Löschung und Compaction vor; bilden Sie eine SDK Session ID bei Bedarf auf die Run-Event-ID ab, behandeln Sie die SDK-History aber nicht ohne gleichwertige Immutability-Garantie als Append-only Recovery- oder Audit-Log.

Harness. Die Orchestration Loop und das einzige Primitive hier, das Entscheidungen trifft. Er stellt den Prompt aus Memory zusammen, ruft das Model auf, prüft den vorgeschlagenen Tool Call gegen seine Berechtigungsregeln, dispatcht zulässige Calls, schreibt Ergebnisse in die Session zurück, wendet Retry-Regeln an und entscheidet, ob die Aufgabe abgeschlossen ist. Planning-Hilfen und Context Management kodieren Annahmen über die Model-Fähigkeiten. Verbindliche Authorization und Isolation setzen außerdem Anforderungen um, die auch bei besseren Models bestehen bleiben. Anthropic formuliert diesen Punkt direkt – das Zitat steht weiter unten im Abschnitt zu Failure Modes und behandelt hauptsächlich, was passiert, wenn diese Annahmen veralten.

Das Codex-Team von OpenAI nennt dies Harness Engineering: Software zu schreiben erfordert weiterhin Engineering-Aufwand, aber ein größerer Anteil fließt nun in das Scaffolding statt in den Code selbst. LangGraphs CompiledStateGraph, LangChains Deep Agents mit seinem create_deep_agent-Entry-Point und Claude Code selbst sind Harnesses in diesem Sinn.

Sandbox. Die isolierte Execution Environment, in der Commands tatsächlich ausgeführt werden. Die Seite zu den Sandbox-Konzepten des OpenAI Agents SDK ordnet Approvals, Tracing, Handoffs und den für Resume erforderlichen Zustand dem äußeren Runtime zu. Commands, Dateiänderungen und Environment Isolation werden der Sandbox Session zugeordnet.

„Äußerer Runtime“ bedeutet dort den Harness zusammen mit seinen State Stores. In der Terminologie dieser Serie sind Approvals und Handoffs Harness-Entscheidungen (Part 4 und Part 6); Tracing und Resume-Bookkeeping sind Session- und Checkpoint-Primitives.

Sandboxes unterscheiden sich darin, wie lange sie leben und was sie zwischen Runs behalten. Die einfachste Variante ist fresh ephemeral: Sie starten eine Sandbox für eine einzelne Aufgabe, zerstören sie nach deren Ende und zahlen bei jedem Run die Cold-Start-Kosten.

Persistent paused-Sandboxes behalten Filesystem und Memory Snapshot zwischen Runs. Beim nächsten Resume entfällt dadurch ein vollständiger Boot. Snapshot or Fork erstellt ein Copy-on-Write-Image aus einem vorbereiteten Parent, sodass viele Aufgaben installierte Dependencies und warme Caches gemeinsam nutzen, ohne ihren beschreibbaren Zustand zu teilen.

Per-Worktree-Workspaces geben Aufgaben separate Checkouts; Git Worktrees teilen Repository-Infrastruktur und sind keine OS-Sandboxes. Begrenzen Sie die Execution separat durch eine Container-, VM- oder Process Policy. Eine Anwendung pro Task kann außerdem einen eigenen Observability-Stack besitzen. Separate Logs, Metrics und Traces ermöglichen das Debugging eines einzelnen Runs, ohne dass sein Zustand in andere Runs überläuft. Die Provider-Tabelle weiter unten vergleicht Isolation- und Persistence-Contracts.

Checkpoint. Der für Resume erforderliche Zustand: welcher Graph Node ausgeführt wurde, seine neuesten Values und was als Nächstes ausgeführt werden soll. Ein Event Log beantwortet die Frage, was passiert ist: angeforderte Actions und ihre Ergebnisse. Ein Checkpoint kann Events, die der Harness nie geloggt hat, nicht rekonstruieren.

LangGraphs PostgresSaver schreibt an jeder Super-Step-Grenze ein Checkpoint. Ein Super-Step ist eine Runde des Graphs, entweder ein einzelner Node oder ein parallel ausgeführter Batch. Per-Task-Writes gehen an checkpoint_writes, sodass erfolgreiche Node-Outputs bei einem Fehler eines Siblings nicht neu berechnet werden.

Ein Checkpoint ist ein plain Dict (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). LangGraph serialisiert ihn mit seinem auf msgpack basierenden JsonPlusSerializer statt mit JSON. datetime, set, Decimal und Dataclasses lassen sich damit round-trippen. Das Format ist auf der langgraph-checkpoint-postgres-PyPI-Seite und in der LangGraph-Checkpoints-Referenz dokumentiert.

StateSnapshot ist die separate, umfangreichere Ansicht, die graph.get_state() auf einem Checkpoint aufbaut. Ein Debug Bundle kann sein .values als letzten bekannten Graph State exportieren; Event-Details, die der Harness nie geloggt hat, kann es nicht rekonstruieren.

Trace. Die Debug- und Audit-Oberfläche. Jeder Model Call, Tool Call und Sub-Agent Step sollte Timing, Status, Model und Provider, Correlation IDs, Token Counts und Kosten emittieren. Prompts, Completions, Tool Arguments und Tool Results sind Opt-in-Content: OpenTelemetrys GenAI Guidance verwendet standardmäßig Metadata, weil diese Felder sensible Daten enthalten können. Erfassen Sie sie erst, nachdem Sie Redaction oder Filtering, Access Controls und Retention festgelegt haben. Wenn ein sechs Stunden langer Run fehlschlägt, lesen Sie den Trace, um herauszufinden, was schiefgelaufen ist. Er kann eine Untersuchung unterstützen, aber Event Log und Checkpoint State ermöglichen zusammen mit Idempotency Handling ein sicheres Resume oder Replay. Die Terminalausgabe des Runs ist zu diesem Zeitpunkt längst verschwunden. OpenTelemetrys GenAI Semantic Conventions standardisieren die Attributnamen (welches Model, welcher Provider, wie viele Tokens, welche Conversation, welcher Workflow). Für ein OTLP-kompatibles Ziel, das diese Conventions unterstützt, kann dieselbe Instrumentierung den Trace in Systeme wie Tempo, Jaeger, Honeycomb oder LangSmith exportieren; Backend-Adapter oder zielsystemspezifische Konfiguration können dennoch erforderlich sein.

Policy und Secrets schneiden sich durch alle Primitives

Zwei Grenzen schneiden sich durch alle fünf Primitives. Sie sind die Runtime-Version des Security-Arguments aus Part 4. Die Permission Decision selbst gehört zum Harness; im Folgenden geht es darum, wo die sie durchsetzende und versorgende Mechanik physisch liegt.

Permission Enforcement

Die Permission Ladder aus Part 4 benötigt einen Ausführungsort. Der Check wird vor jedem Tool Call ausgelöst und entscheidet, ob dieser durchgeführt wird. In Production sind zwei Patterns üblich. Deep Agents’ Filesystem-Permission-Middleware kann die integrierten Filesystem Tools auf deklarierte Pfade begrenzen. Sie steuert keine Sandbox Shell Commands, Custom Tools oder MCP Calls; erzwingen Sie diese in der Sandbox Policy oder hinter einem eigenen Tool Proxy. Anthropic Managed Agents leitet Custom MCP Tool Calls über einen Credential-haltenden Proxy. Sandbox Command Execution und Git Authentication verwenden separate Pfade; der MCP Proxy ist kein universeller Interceptor für jede Aktion. Wenn für einen sensiblen Call eine Human Approval erforderlich ist, pausieren LangGraphs interrupt() und Deep Agents’ Approval Hook den Graph, bis eine Person zustimmt.

Secret Broker

Das Model sollte keine langlebigen Secrets sehen, und normalerweise sollte dies auch für die Sandbox gelten. Das Managed-Agents-Pattern ist das, was Sie übernehmen sollten:

„Für Git verwenden wir das Access Token jedes Repositorys, um das Repository während der Sandbox-Initialisierung zu clonen und es in das lokale Git Remote einzubinden. Git push und pull funktionieren innerhalb der Sandbox, ohne dass der Agent das Token selbst verarbeitet. Für Custom Tools unterstützen wir MCP und speichern OAuth Tokens in einem sicheren Vault. Claude ruft MCP Tools über einen dedizierten Proxy auf; dieser Proxy erhält ein mit der Session verknüpftes Token. … Der Harness erhält niemals Kenntnis von Credentials.“

Im market-analyst-agent-Referenz-Stack – einem kleinen LangGraph Agent, der Market Data abruft und einen Analyst Report schreibt, aufgebaut über diese Serie hinweg – ruft der Worker seine Market-Data-Tools lokal auf. Der optionale MCP Server stellt eine Tool-Oberfläche bereit; er ist kein implementierter Credential Broker zwischen diesem Worker und seinen Providern. Beide Container können das gemeinsame Development-.env lesen. Ein Production Broker würde erfordern, Provider-Credentials in einen Store zu verschieben, den der Worker nicht lesen kann, und jeden relevanten Call über den Broker zu routen.

Platzierung einem Plausibilitätscheck unterziehen

Ein praktischer Plausibilitätscheck besteht darin, jede Komponente und das von ihr implementierte Primitive zu notieren. Postgres könnte Session und Checkpoint abdecken. Der Worker-Container ist der Harness. Ein Service wie Daytona, Modal oder E2B stellt die Sandbox bereit, während Tempo oder LangSmith den Trace speichern.

Untersuchen Sie anschließend gekoppelte Fehler. Wenn zwei Primitives im selben Prozess liegen, reißt ein Crash beide mit. Wenn sie ein Credential teilen, überschreitet ein Leak beide Grenzen. Typische Beispiele sind ein Worker, der zugleich die Trace-Durability besitzt, oder ein Sidecar-Token, das zugleich die Checkpoint-Datenbank freischaltet.

Failure Modes eines AI Agent Runtime in Production

Der Runtime verwaltet Retries, stellt frühere Arbeit wieder her, isoliert Workspaces und setzt Budgets durch. Wenn sich Runs über Worker und Context Windows erstrecken, verlagern sich die Fehler in Richtung State, duplizierter Side Effects, Sandbox Drift und Budgetüberschreitungen.

Die Fehler fallen in vier Gruppen:

• Fehler bei der Output-Qualität: Der Agent erklärt die Arbeit zu früh für abgeschlossen, vergisst nach einem Context-Window-Reset, was er getan hat, oder vertraut auf seine eigene Self-Evaluation und liefert fehlerhaften Output aus.
• Fehler bei der Kostenkontrolle: Der Agent gerät in eine Retry Loop oder verbraucht ein Token- oder Tool-Call-Budget, ohne etwas Nützliches zu produzieren.
• State- und Crash-Fehler: Workspaces driften, weil ein Run Dateien anfasst, die einem anderen Run gehören; Tool Calls werden durch Retries mehrfach ausgeführt; oder Arbeit geht verloren, wenn ein Worker zwischen zwei Events stirbt.
• Context-Window-Fehler: Das Model fasst zusammen und beendet sich frühzeitig, weil es glaubt, der Platz werde knapp, obwohl das Window noch Reserven hat.

Die Tabelle ordnet jedem Fehler eine Mitigation, die Grundlage der Empfehlung und den Runtime Hook zu, der sie durchsetzt. Model-spezifisches Verhalten kann sich ändern. Behandeln Sie Vendor-Beobachtungen daher als Anlass, die Annahme erneut zu testen, nicht als dauerhafte Regeln.

Hinter den meisten dieser Zeilen stehen zwei Ideen. Anthropic über Harness Staleness in Harness Design for Long-Running Application Development:

„Jede Komponente in einem Harness kodiert eine Annahme darüber, was das Model nicht selbst tun kann. Diese Annahmen sollten einem Stresstest unterzogen werden – sowohl weil sie falsch sein können als auch weil sie mit besser werdenden Models schnell veralten können.“

Vercel zum verwandten Problem, dass zu viele Tools zu viele Annahmen kodieren, in We removed 80% of our agent’s tools:

„Wir haben den größten Teil davon gelöscht und den Agent auf ein einziges Tool reduziert: beliebige Bash Commands ausführen. Wir nennen ihn einen File-System-Agent.“

Das Zitat beschreibt den Bash-Kern; der von Vercel ausgelieferte Agent behielt zwei Tools, ExecuteCommand und ExecuteSQL, und ersetzte damit ein altes Codebeispiel, das siebzehn Tools nennt. Part 3 behandelt das vollständige Vorher und Nachher. Das berichtete Ergebnis über fünf repräsentative Queries: Der Erfolg stieg von 4/5 auf 5/5, und der schlechteste Fall sank von 724 s / 100 Steps / 145.463 Tokens (fehlgeschlagen) auf 141 s / 19 Steps / 67.483 Tokens (erfolgreich). Diese Worst-Case-Zeile ist die dramatische; über alle fünf Queries hinweg betrug die Token-Ersparnis durchschnittlich 37 %. Die Lehre lautet nicht „Löschen Sie Ihre Tools“. Optionale Unterstützung kann redundant werden, wenn sich das Model-Verhalten ändert. Testen Sie die Annahme bei einem Model-Wechsel erneut.

Cognition sah bei Sonnet 4.5 dieselbe Veränderlichkeit bei der Session-Länge. In Rebuilding Devin for Claude Sonnet 4.5 beschreiben sie ein Model, das bei vermuteter Context-Erschöpfung proaktiv SUMMARY.md / CHANGELOG.md schreibt, aber unterschätzt, wie viele Tokens noch verfügbar sind. Ihre Lösung bestand darin, den 1M-Token-Context zu aktivieren und die Nutzung auf 200k zu begrenzen, sodass das Model weiterhin glaubt, Reserven zu haben. Als sie dies schrieben, war das ein Beta-Flag.

Anthropics Dokumentation zum Context Window listet, geprüft am 6. September 2026, Sonnet 5 und Opus 5 standardmäßig mit 1M Tokens; Sonnet 4.5 bleibt bei 200k. Aktuelle Sonnet-Models erhalten verbleibende Context-Updates automatisch, und serverseitige Compaction ist für Claude 4.6 und spätere Models in der Beta verfügbar. Bevor Sie Cognitions historischen Cap übernehmen, testen Sie das ausgewählte Model mit den unterstützten Context Controls. Ein größeres Window oder ein Budget Counter garantiert kein zuverlässiges Recall, und beides ersetzt keinen dauerhaften Fortschritt außerhalb des Models.

Das Harness-Team von OpenAI fasst es in einer Zeile zusammen: „Humans steer. Agents execute.“ Wenn etwas fehlschlägt, lautet die nützliche Frage, welche Fähigkeit fehlt und wie diese Fähigkeit für den Agenten zugleich sichtbar und durchsetzbar gemacht werden kann.

Der gesunde Run-Lifecycle

Ein gut funktionierender Run ist langweilig. Er besteht aus einer Kette kleiner, recoverable Steps, und jeder abgeschlossene Step schreibt dauerhaften Zustand, bevor der nächste beginnt.

Wenn jedes Ergebnis vor dem nächsten Step geschrieben wird, bleibt der Crash-Schaden begrenzt. Ein laufender externer Effekt ist die Ausnahme: Ein Worker kann abstürzen, nachdem der Provider ihn committed hat, aber bevor der Harness sein Ergebnis aufzeichnet. Der nächste Worker muss diesen ausstehenden Effekt reconciliieren, bevor er vom letzten abgeschlossenen Step fortsetzt.

1. Booten Sie entweder aus einer frischen oder einer resumed Session. Beim Resume mounten Sie den Workspace aus seinem letzten bekannten Zustand, lesen die von der vorherigen Ausführung hinterlassenen Progress Files (PROGRESS.md, feature-list.json), laden den letzten Checkpoint und untersuchen das Event Log auf ausstehende Tool Intents. Reconciliieren Sie jeden ausstehenden externen Effekt, bevor Sie einen weiteren Model- oder Tool Call ausführen.
2. Planen Sie, bevor Tool Calls ausgelöst werden. Halten Sie fest, wie „done“ aussieht, wie viel der Run ausgeben darf, welche Tools der Agent aufrufen kann und was den Run frühzeitig beenden soll. Diese Plan Values werden zu Runtime Checks; ohne sie hat die Execution nichts, das ihr Grenzen setzt.
3. Serialisieren Sie Side-Effect-erzeugende Tool Calls oder koordinieren Sie sie explizit. Der Permission Check des Harness entscheidet, ob ein Call zulässig ist. Hängen Sie vor dem Dispatch einen pending Intent mit seinem Idempotency Key an; nach der Rückgabe des Providers hängen Sie das Ergebnis an. Unabhängige Read-only- oder idempotente Calls können parallel laufen, wenn jeder einen eigenen dauerhaften Intent-/Result-Record besitzt und die Ergebnisse deterministisch aggregiert werden. Wenn der Worker zwischen einem Side Effect und dem Schreiben des Ergebnisses stirbt, setzen Sie durch eine Abfrage oder einen Retry beim Provider mit demselben Key fort und hängen anschließend entweder das wiederhergestellte Ergebnis oder needs_human an. Stripe liefert beispielsweise bei einem wiederholten Idempotency Key das gespeicherte Ergebnis des ersten Requests zurück; ein anderer Provider benötigt einen gleichwertigen Lookup- oder Retry-Contract.
4. Führen Sie an Super-Step-Grenzen oder in einem einfacheren Harness nach jedem Event einen Checkpoint aus. Persistieren Sie Graph State, Workspace-Diff und Referenzen auf erzeugte Artefakte. Dieser Checkpoint wird beim nächsten Resume von Step 1 gelesen. Fehlt der Checkpoint oder ist er veraltet, muss die Recovery den State möglicherweise aus dem Event Log neu aufbauen, was deutlich langsamer ist.
5. Evaluieren Sie anhand der Artefakte, wenn der Agent glaubt, fertig zu sein: Tests, Evaluator mit frischem Context, Schema Validation, Browser Checks. Besteht der Check, endet der Run erfolgreich. Schlägt er fehl, setzt der Run vom letzten sauberen Checkpoint fort, ergänzt um die Fehlermeldung im Context, und versucht es erneut.

Kein Step dieser Liste erfordert, dass der Agent sich zwischen Runs an etwas erinnert. Der Zustand liegt in Session und Checkpoint und wird bei jedem Resume erneut eingelesen.

Persistieren Sie vor dem Dispatch eine anwendungseigene Operation ID und binden Sie sie an die genehmigten Arguments. Verwenden Sie sie zur Recovery derselben Business Intent, auch wenn eine neue Planung eine neue Model Tool-Call-ID erzeugt. Zeichnen Sie diese Model IDs separat für Correlation auf. Von Natur aus idempotente Updates benötigen stattdessen möglicherweise eine Version Precondition. AWS’ Retry Guidance erklärt, warum die Request Identity die Intent repräsentiert. Definieren Sie, wann eine Aktion tatsächlich neu ist und wie lange die Deduplication gilt: Stripe erlaubt das Entfernen von Keys nach mindestens 24 Stunden. Reconciliieren Sie geänderte Payloads und abgelaufene Keys vor einem weiteren Versuch.

Wählen Sie einen aktiven Writer oder eine Lease pro Thread. Für Input, der während eines Runs eingeht, müssen Sie explizit Reject, Enqueue, Interrupt oder Rollback wählen; Deep Agents’ Runtime Account beschreibt diese Optionen. Cancellation muss neuen Dispatch stoppen, den Request aufzeichnen und laufende Effekte reconciliieren; den Worker zu beenden macht einen Provider Call nicht rückgängig.

Budget Enforcement gehört neben den Dispatch. Concurrent Calls dürfen nicht dieselbe verbleibende Allowance ausgeben. Prometheus ist ein Monitoring-System, kein autoritatives Spending Ledger pro Request. Reservieren Sie konservativ und reconciliieren Sie den tatsächlichen Verbrauch; verzögertes Provider Accounting und Cancellation können weiterhin zu Overshoot führen.

Neue Model Controls helfen, den Run zu steuern, besitzen aber nicht sein Spending Limit. Anthropics Beta-Task Budgets geben unterstützten Messages-API-Models ein Advisory Budget über eine agentic Loop. Dieses kann überschritten werden; max_tokens begrenzt eine Response, nicht den gesamten Run. Die Unterstützung ist Model-spezifisch: Opus 5 unterstützt Task Budgets, Sonnet 5 nicht. Behalten Sie Dispatch Ledger und Cancellation Path auch dann bei, wenn das Model einen Budget Hint erhält.

Provider Safety Stops benötigen einen eigenen Terminal Path. Bei OpenAIs misalignment_policy_violation stoppen Sie den Dispatch, behalten korrelierte Records und fordern eine Operator Review an, statt zu retrien. Stream Errors nach partieller Ausgabe müssen behandelt und vorherige Effekte reconciliiert werden; Part 4 erklärt die Monitoring-Grenze.

Die Evaluation sollte Evidence außerhalb des Producing Context enthalten. Ein Evaluator mit frischem Context reduziert Shared-Context-Bias, während Tests, Lints, Browser Checks und Schema Validation deterministische Evidence liefern. Der Check kann pass, fail oder needs_human zurückgeben. Bei Code Agents kann der Reviewer eine weitere Model Session mit Read-only Tools sein. Bei Data- und Report-Agents kombinieren Sie deterministische Validation mit einem Reviewer Model, wenn weiterhin Urteilskraft erforderlich ist.

Elf AI-Agent-Deployment-Patterns und was zwischen ihnen entscheidet

Sobald die fünf Primitives benannt sind, stellt sich die Frage, welche Deployment-Form sie ausführt. Mit „Form“ meine ich eine Anordnung dieser Primitives: wo der Harness lebt, wo Zustand persistiert wird und welche Art von Sandbox die Arbeit ausführt. Eine Form ist eine Wiring-Entscheidung, keine Vendor-Auswahl. Das Diagramm unten zeigt, bei welcher Run-Länge sich jede Form wohlfühlt. Der folgende Text beschreibt, was zwischen ihnen entscheidet.

Wenn Sie nur eines der elf Patterns lesen, lesen Sie Pattern 2: Queue + Worker + Checkpoint DB. Es ist die Default-Empfehlung für die meisten Teams, die im Referenz-Repo verwendete Form und das Grundgerüst, von dem die meisten anderen Formen abweichen: Queue → Worker → Durable State, wobei Sandbox-Quelle, Harness-Owner oder State Engine ausgetauscht werden. Wenn Sie Pattern 2 zuerst lesen, lassen sich die übrigen schneller überfliegen.

Das Diagramm vergleicht die Formen anhand der Run-Länge. Die folgende Matrix vergleicht sie anhand der Ownership: Jede umrandete Zelle nennt die Komponente, die dieses Primitive bereitstellt.

1. SDK in einem App Server (synchron, request-scoped)

Die ursprüngliche Form. Das Agent SDK läuft innerhalb eines Request Handlers. Gut für Aufgaben unter 30 Sekunden, Demos und interne Tools. Schlecht für alles, bei dem ein HTTP Client die Verbindung trennen könnte. Cloud Runs HTTP Timeout liegt bei maximal 60 Minuten, und jede Panic im Web-Tier beendet den Run. Das SDK ist der Harness. Untrusted Tool Execution benötigt eine separate Sandbox, und der Zustand liegt normalerweise im Process Memory, sofern Sie ihn nicht explizit an anderer Stelle persistieren. Verwenden Sie dies nicht für mehrstündige Arbeit.

2. Queue + Worker + Checkpoint DB

Die Default-Empfehlung für die meisten Teams und die Production-förmige Demo-Implementierung in market-analyst-agent: ein Python Worker mit PostgreSQL Checkpointer, Redis Streams (oder RabbitMQ) für die Inbound Queue und ein MCP Sidecar für Tools. Geeignet für Runs von zehn Minuten bis zu mehreren Stunden mit idempotenten Steps. Der lokale Runner kann die Queue bei synchroner Entwicklung umgehen; sobald Sie Async Submission und Backpressure benötigen, gehört die Queue jedoch zur Production-Form.

Im Production-Pattern nimmt die App einen Request an, erstellt eine Session Row, legt einen Job in die Queue und gibt eine Run ID zurück. Der Worker holt den Job ab, führt den Harness aus, schreibt Session Events und Checkpoints, streamt Status und speichert Artefakte währenddessen. Postgres bleibt erhalten, Worker sind austauschbar, und die Queue-Tiefe liefert Backpressure. Spot-/Preemptible-Compute funktioniert, solange dauerhafte Event- und Checkpoint-Writes abgeschlossen sind, bevor der Worker Success meldet. Das verlinkte Repository demonstriert die Form, aber keine verifizierte Durable Recovery. Sein Consumer liest neue Messages, ohne Pending Jobs zurückzufordern, bestätigt Exceptions per ACK und liefert Arbeit mit neuem Initial State statt eines definierten Resume Contracts erneut aus. Production benötigt Claim-/Lease-/Reclaim-/ACK-Verhalten und Fault Tests, bevor diese Topologie als recoverable bezeichnet werden kann.

In dieser Form ist der Worker der Harness. Sein Container und der Per-Thread-Workspace liefern eine Execution Boundary; untrusted Code benötigt dennoch eine gehärtete Sandbox oder VM. Der Event Store besitzt die Session-History; PostgresSaver besitzt den Checkpoint State. Sie können eine Datenbank teilen, wenn der Harness beide Schemas explizit schreibt. Traces laufen über OpenTelemetry in den von Ihnen betriebenen Observability-Stack.

3. Durable Workflow Engine (Temporal-Style)

Agent Orchestration Code läuft in einem Temporal Workflow; Model Calls und Tool Calls laufen als Activities. Der Workflow State liegt in einem Event-History-Log, das von Cassandra, MySQL oder Postgres unterstützt wird, und kann über Fehler hinweg replayt werden. Deployments von Workflow Code, die sich mit einer laufenden Execution überschneiden, benötigen Replay-sicheres Worker Versioning oder Patches; Code ohne diese Disziplin zu ersetzen kann Replay brechen. Die Temporal × OpenAI Agents SDK Integration, allgemein verfügbar seit März 2026, liefert ein OpenAIAgentsPlugin und einen activity_as_tool Helper. Der Bericht zu agentic Sandboxes beschreibt, wie ein laufender Agent mitten in der Conversation auf einen anderen Sandbox Provider geforkt werden kann. Idle Workflows verbrauchen keine Compute-Ressourcen. Die Einschränkungen sind real: Realtime Agents werden nicht unterstützt, Streaming ist weiterhin als experimentell markiert, und LocalShellTool sowie ComputerTool sind deaktiviert, weil sie nicht zu einem verteilten Modell passen.

Verwenden Sie diese Form, wenn der Run echte Wartepunkte besitzt: Human Approvals, externe Callbacks, lange Sleeps, Retries mit Business Rules oder Deployment Windows – und das Team replay-sicheres Workflow Versioning betreiben kann. Eine Human Approval wird zu einem dauerhaften Sleep ohne Compute-Verbrauch, nicht zu einer Polling Loop.

Der Workflow Code ist der Harness. Die Sandbox liegt normalerweise außerhalb von Temporal und wird aus Activities aufgerufen. Session- und Checkpoint State fallen im Temporal Event-History-Log zusammen; Trace-Sichtbarkeit kommt aus der Temporal UI plus OpenTelemetry Spans auf jeder Activity.

4. Sandbox Provider pro Session

Eine neuere Form. Jeder Agent Run erhält eine eigene MicroVM oder einen Container von einem Sandbox-as-a-Service-Provider. Der Harness lebt an einem dauerhaften Ort; die Sandbox ist die disposable Execution Environment.

Provider-Startup-Werte messen unterschiedliche Intervalle und ergeben kein Speed-Ranking. Messen Sie API Request bis zum ersten erfolgreichen Command und die Application-Ready-Latency separat – einschließlich Image-/Cache-State, Region, Concurrency sowie p95/p99. Modals ungefähr einsekündiger Container Boot schließt beispielsweise die Application Initialization aus. Prüfen Sie Account-Concurrency-Limits vor einem Load Test.

Daytona zeichnet für jeden unabhängigen Fork eine Parent-Child-Verknüpfung auf und bewahrt dadurch die Lineage abgeleiteter Sandboxes. OpenAIs Codex Harness verwendet die Per-Worktree-Variante: „Codex arbeitet an einer vollständig isolierten Version der App, einschließlich Logs und Metrics, die nach Abschluss der Aufgabe abgebaut werden.“

Verwenden Sie diese Form, wenn der Agent Untrusted Code, Browser Automation, Tests oder Package Installs ausführt. Der Trade-off sind höhere Kosten und stärkere Provider-Kopplung als bei gemeinsam genutzten Workern.

Der Provider besitzt die Sandbox und nichts anderes. Harness, Session, Checkpoint und Trace bleiben auf Ihrer Seite, üblicherweise verdrahtet als Queue + Worker wie in #2.

5. Anthropic Managed Agents (Hosted Harness)

Anthropic hat Managed Agents am 8. April 2026 in einer Public Beta gestartet, aktiviert über den managed-agents-2026-04-01-Beta-Header. Der Service stellt eine Hosted Session, einen Harness, eine Sandbox und einen Vault-backed MCP Proxy bereit. wake(sessionId) kann den Harness auf einem neuen Worker initialisieren, ohne den dauerhaften Session State zu verlieren.

Anthropic berechnet Managed Agents zu Standard-Token-Raten plus $0.08 pro Session-Stunde. Die Abrechnung erfolgt auf Millisekundenbasis und gilt nur, solange der Session-Status „running“ ist; Idle Time ist kostenlos. Eine außer Kontrolle geratene Retry Loop verursacht daher zusätzlich zu den Token-Kosten Session-Hour-Kosten.

Beachten Sie die Einschränkungen. Der Batch-API-Rabatt gilt nicht („Sessions sind stateful und interaktiv. Es gibt keinen Batch-Modus.“). Managed Agents ist nicht über AWS Bedrock oder Google Vertex AI verfügbar. Innerhalb der Beta liegen MCP Tunnels und agentisches „Dreaming“ hinter einer zusätzlichen Research Preview, für die Sie Zugang anfordern müssen; Multi-Agent Coordination und rubric-graded Self-Evaluation sind dokumentierte Bestandteile der Beta. Der Lock-in ist hoch: Sie tauschen Harness-Freiheit dagegen, die Loop nicht selbst betreiben zu müssen.

Die Default-Cloud-Konfiguration ordnet alle fünf Primitives Anthropic zu. Mit Self-hosted Sandboxes betreiben Sie Execution, Filesystems und Network Egress, während Anthropic Orchestration und Model übernimmt. Tool Inputs und Results erreichen weiterhin die Control Plane; angehängte Skills und Memory werden dort gespeichert und synchronisiert. Execution selbst zu besitzen macht nicht das Gesamtsystem self-hosted.

Claude Platform on AWS unterstützt ebenfalls Managed Agents und Self-hosted Sandboxes, ist aber von Bedrock getrennt. Dort benötigt eine autonome Session nach sechs Stunden ein User-Role-Event zur Reauthentication, und Self-hosted Sessions können keine Memory Stores anhängen. First-party Managed Agents unterliegt diesen beiden Einschränkungen nicht. Prüfen Sie vor der Übernahme eines Session-Designs sowohl die Plattform als auch das Model.

6. LangChain Deep Agents Deploy (Managed Open Harness)

deepagents deploy verpackt ein deepagents.toml in ein LangSmith Deployment mit Durable Execution, Memory, Multi-Tenancy, Human-in-the-Loop, Observability, sandboxed Code Execution und Scheduled Runs. Cloud-, Hybrid- und Self-hosted-Deployment-Modi werden unterstützt. Sandbox Provider (LangSmith Sandboxes, Daytona, Modal, Runloop oder Custom) lassen sich über einen einzigen Config-Wert austauschen. Agent Files und Memory liegen in einem Virtual Filesystem mit pluggable Backends; Checkpoint Persistence ist getrennt, und Memory kann auf User, Assistant oder beide gescoped werden. Der Lock-in ist geringer als bei Managed Agents: Der Harness ist MIT-lizenziert, Instructions verwenden den offenen AGENTS.md-Standard, und Agents werden über MCP, das A2A-(Agent2Agent-)Protokoll und Agent Protocol bereitgestellt. Siehe LangChains Runtime behind Production Deep Agents-Bericht.

Standardmäßig werden alle fünf Primitives gehostet, aber jedes ist per Config austauschbar. Die Sandbox liegt hinter einem einzigen Config-Wert. Das Memory Filesystem ist von Thread- und Checkpoint-Persistence getrennt. Traces gehen an LangSmith.

7. Google Cloud Run Service oder Job

Cloud Run besitzt zwei verschiedene Runtime-Modi; welcher passt, hängt davon ab, wie der Agent aufgerufen wird. Services sind HTTP-gebunden und skalieren zwischen Requests auf null; der Harness läuft als Request Handler und kehrt zurück, wenn der Run abgeschlossen ist. Jobs laufen ohne HTTP Entry Point bis zum Abschluss; der Harness läuft als One-shot Worker und beendet sich nach dem Ende der Aufgabe. Beide können den Harness hosten, aber keiner hält Zustand über Runs hinweg. Sessions und Checkpoints müssen in Postgres, Spanner oder einem ähnlichen externen Store liegen.

Die harten Limits unterscheiden sich stark. Cloud-Run-Service-Request-Timeout: standardmäßig 300 s, maximal 3.600 s (60 min). WebSockets erhalten dasselbe Timeout. Cloud Run Jobs: standardmäßig 10 min pro Task, maximal 168 h (7 Tage); für Tasks mit GPUs maximal 1 Stunde. Instance-based Billing (always-allocated CPU) erlaubt weiterhin Scale-to-Zero; Minimum Instances ist eine separate Einstellung; Jobs haben kein HTTP und autoskalieren nicht.

Verwenden Sie einen Service für synchrone Runs bis zu 60 Minuten. Verwenden Sie einen Job für längere One-shot- oder Async-Arbeit. Cloud Run Jobs können einen Task mehrere Tage am Leben halten, liefern aber kein Durable Replay über Deployments, Versionsänderungen oder Worker-Replacement hinweg. Ein längerer Workflow kann sich über mehrere Executions erstrecken, wenn ein externer Orchestrator den dauerhaften Fortschritt besitzt.

Cloud Run hostet den Harness. Session- und Checkpoint State liegen in Postgres, Spanner oder einem anderen externen Store; Traces können über Cloud Logging und OpenTelemetry fließen. Der Service Container ist eine Execution Environment; ergänzen Sie eine separate Sandbox, wenn der Agent Untrusted Code ausführt.

8. AWS Lambda: begrenzte Invocations und dauerhafte Workflows

Lambdas maximales Function Timeout beträgt 900 s (15 Minuten) und ist hart begrenzt. Wenn API Gateway die Funktion vorgeschaltet ist, hängt das Integration Limit vom API-Typ ab. HTTP APIs erlauben 30 Sekunden; REST Integrations verwenden standardmäßig 29 Sekunden, während regionale und private REST APIs ein längeres Timeout konfigurieren können. Lambda Durable Functions, im Dezember 2025 gestartet, ergänzen Managed Checkpoints, Steps und Waits über Executions von bis zu einem Jahr. Die aktive Invocation bleibt begrenzt, während der Durable Workflow sie überdauern kann. Vergleichen Sie unterstützte Runtimes, Regionen, Replay Rules und Activity Idempotency mit Ihren Anforderungen.

Lambda kann einen begrenzten Harness innerhalb seines 15-Minuten-Limits halten. Session- und Checkpoint State benötigen weiterhin explizite externe Speicherorte; ergänzen Sie eine separate Sandbox für Untrusted Code und exportieren Sie Traces in externe Telemetry. Ein Durable Lambda Workflow kann stundenlange Arbeit über begrenzte Invocations hinweg orchestrieren.

9. AWS ECS / Fargate Task pro Run

Fargate dokumentiert kein hartes Limit für die Task-Laufzeit – anders als eine gewöhnliche Lambda Invocation. Fargate unterstützt keine GPU Tasks; ECS GPU Workloads benötigen geeignete EC2 Instances oder einen externen GPU Service. Fargate bietet eine virtualisierungsbasierte Task Isolation, doch Credentials und erlaubter Network Access benötigen weiterhin ein Threat Model. Fargate Throttling Quotas erlauben einen Launch Burst von 100 und füllen mit 20 pro Sekunde nach, mit separaten On-Demand- und Spot-Budgets. ECS Service Quotas begrenzen Services mit AWS Cloud Map Discovery auf 1.000 Tasks pro Service und EC2-basierte Cluster auf 5.000 Container Instances.

Fargate erfordert den awsvpc-Modus, sodass jeder Task ein Network Interface und eine private IP erhält. Diese Form passt zu VPC-internem Data Access. Fargate Spot erhöht das Interruption Risk, und Durability bleibt Ihre Verantwortung, weil die Plattform kein Temporal-artiges Replay besitzt.

Fargate hostet den Harness und gibt jedem Run einen eigenen Task. Das trennt Workspaces und Task Credentials, ist aber für sich genommen keine vollständige Sandbox für hostile Code. Session, Checkpoint und Trace gehen an externe Services wie RDS oder DynamoDB plus CloudWatch/X-Ray.

Vergleichen Sie außerdem Amazon Bedrock AgentCore Runtime, bevor Sie die AWS Session Layer selbst bauen. Er hostet Ihren Agent Code mit Managed Session Lifecycle und einer Auswahl an Compute. AWS dokumentiert bis zu 8 Stunden auf serverless MicroVMs oder 14 Tage auf seinem Instances-Compute-Typ, der ebenfalls GPU Workloads unterstützt. Instances verwenden AWS-managed EC2-Ressourcen in Ihrem Account und haben ein anderes Security Model als die serverless Option. Wählen und testen Sie diesen Compute Contract explizit; eine langlebigere Instance garantiert einem externen Side Effect weiterhin keine Exactly-once Execution.

10. Kubernetes Job oder Namespace pro Session

Gut geeignet, wenn Sie bereits Kubernetes betreiben und eine Sandbox pro Session mit clusterweiten Controls wünschen. Schlecht geeignet, wenn Sie Sub-Second-Startup benötigen, weil das Ziehen des Container Images und die Initialisierung des Pods bei einem Cold Start zu lange dauern. Das Pattern ist ein Job pro Agent Run mit activeDeadlineSeconds, einer PersistentVolumeClaim für den Workspace und einem Sidecar für den MCP Server. Die Crash Recovery müssen Sie selbst bauen. Kubernetes nur zum Hosten von Agents einzuführen, ist angesichts von Configuration Overhead und operativer Last teuer. Es lohnt sich nur, wenn Sie K8s bereits aus anderen Gründen betreiben.

Kubernetes hostet den Harness und die Per-Run-Execution-Environment, üblicherweise als ein Job und manchmal mit einem dedizierten Namespace. Starke Isolation hängt weiterhin von Runtime Class, Network Policy, Pod Security und der zugrunde liegenden Container- oder VM-Grenze ab. Session- und Checkpoint State liegen in einer externen Datenbank oder auf einer PersistentVolumeClaim.

11. Local Docker Compose (nur Development)

Die Referenz für den nächsten Abschnitt. Der Zweck dieser Form besteht darin, dass sie die Production-Topologie 1:1 abbildet (dieselben Primitives, dieselbe Network-Form), während sie auf einer einzigen Maschine läuft. Nicht abgebildet wird die Isolation: ein gemeinsamer Workspace-Mount, ein Postgres, keine gehärtete Sandbox und keine separaten Failure Domains zwischen Worker und State. Nichts, das so geformt ist, sollte ausgeliefert werden.

Compose bildet Form #2 auf einem einzelnen Host ab. Im Referenz-Stack hält Postgres den Checkpoint State, und der Worker-Container ist der Harness. Eine Production-förmige Session benötigt einen eigenen, separat geschriebenen Append-only Event Store; allein die PostgresSaver-History stellt keinen solchen bereit. Der gemeinsame Workspace-Mount ist für Development praktisch, isoliert aber keine Untrusted Runs. Der optionale OpenTelemetry-Stack zeichnet Traces auf.

Referenz-Stack: Docker Compose

Die Referenz-Topologie, verwendet in slavadubrov/market-analyst-agent, besteht aus einem LangGraph Worker, einem Postgres Checkpointer, Qdrant für Retrieval, einem MCP Sidecar, einer Redis Queue für asynchrone Production-ähnliche Runs sowie einem optionalen Prometheus / Grafana / Loki / Tempo / OTel-Observability-Stack. In Local Compose ist Redis nur deshalb optional, weil der synchrone Runner den Worker direkt aufrufen kann. docker compose up startet die Kern-Topologie lokal; MCP Sidecar und Observability-Stack sind Opt-in-Profile (--profile mcp, --profile observability).

Das Diagramm zeigt das PostgresSaver der lokalen Demo. Eine Production-förmige Session ergänzt ein separat geschriebenes Event Schema für Tool Intents und Outcomes; PostgresSaver bleibt allein Checkpoint State.

Das einzige Stück, das sich inline zu zeigen lohnt, ist das kanonische LangGraph Wiring. Es ist ein illustrativer Ausschnitt, kein Repository-runnable Example. Zur Ausführung benötigen Sie langgraph, langgraph-checkpoint-postgres und psycopg[binary,pool], eine erreichbare PostgreSQL-Datenbank mit Berechtigung zum Erstellen der Checkpointer-Tabellen, POSTGRES_PASSWORD und ein zuvor gebautes StateGraph in builder; siehe LangGraphs Postgres-Checkpointer-Setup.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
# `builder` is your StateGraph, already built
session_id = "session-123"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "Continue the task"}]},
        {"configurable": {"thread_id": session_id}},
    )

Observability, die den Run überdauert

Kurze Request Handler lassen sich leicht debuggen: Wenn etwas fehlschlägt, lesen Sie Response und Live Log. Long-Running Agents haben diesen Luxus nicht. Wenn ein sechs Stunden langer Run fehlschlägt, ereignete sich der interessante Event vor fünf Stunden, die Live-Terminalausgabe ist verschwunden und der Worker, der ihn erzeugte, wurde ersetzt. Niemand wird den Run aus dem Memory rekonstruieren. Sie debuggen daher anhand dauerhafter Artefakte, die geschrieben wurden, während der Run noch lief.

Production-Stacks decken typischerweise vier Artefaktarten in zwei Gruppen ab. Zwei davon lesen Sie nach dem Run, für Postmortems und Replay: ein abfragbares Event Log jedes Steps und OpenTelemetry Traces darüber, wohin Zeit und Tokens flossen. Zwei lesen Sie während des Runs. Das eine ist ein Live Tail dessen, was der Agent im Workspace erzeugt. Das andere ist ein Per-Worktree-Observability-Stack, den der Agent selbst abfragen kann, während er arbeitet.

Strukturiertes Event Log (nach dem Run lesen)

Jeder Model Call, Tool Call, jedes Ergebnis, jeder Fehler und jede Approval wird, nach Session ID und Timestamp verschlüsselt, in Durable Storage geschrieben. Nach Ende des Runs fragen Sie es wie eine normale Datenbanktabelle ab. Addy Osmani setzt in Long-running Agents die Messlatte klar: „Wenn Sie nicht aus Durable Storage rekonstruieren können, was der Agent in den vergangenen 24 Stunden getan hat, haben Sie kein Long-Running Agent, sondern ein Long-Running Shell Script, das zufällig ein LLM aufruft.“

OpenTelemetry GenAI Traces (nach dem Run lesen)

Dieselben schrittweisen Daten werden als Spans mit den Standardattributen aus den gen_ai.*-Semantic Conventions emittiert: Model Name, Provider, Input- und Output-Token-Counts, Conversation ID und Workflow Name. Die Conventions befinden sich weiterhin in der Stability-Stufe Development.

Im Jahr 2026 wurden sie aus OpenTelemetrys zentralem Semantic-Conventions-Repository in ein eigenes GenAI-Semantic-Conventions-Repository verschoben. Die Attributnamen können für die Instrumentierung verwendet werden. Pinnen Sie jedoch die validierte Revision statt einer Version des Main-Repositories. Provider-spezifische Felder liegen in Subnamespaces (anthropic.*, openai.*), die an gen_ai.provider.name angehängt sind. Der Grund für den Standard ist Portabilität: Bei OTLP-kompatiblen Zielen, die diese Conventions unterstützen, muss ein Backend-Wechsel möglicherweise keine erneute Instrumentierung des Codes erfordern; Backend-Adapter oder zielspezifische Konfiguration können dennoch erforderlich sein.

Tool-Call-Timeline plus Workspace-Diffs (während des Runs lesen)

Der schnellste Weg herauszufinden, was ein Agent gerade tut, besteht darin, die von ihm im Workspace erzeugten Artefakte zu tailen, statt ein Session Log zu durchsuchen. Anthropics Harness Primitives for Long-Running Claude Agents Quickstart liefert dafür eine Zwei-Pane-Watch-Loop: watch -n 5 'git log --oneline -8' zeigt die neuesten Commits des Agents, und watch -n 5 'find screenshots -name "*.png" | tail -5' die neuesten Screenshots. Zwei Terminal-Panes, die sich alle fünf Sekunden aktualisieren, reichen aus, um zu erkennen, ob ein Run Fortschritte macht oder rotiert.

Ephemerer Stack pro Worktree (vom Agent selbst während des Runs gelesen)

Nach OpenAIs Harness-Post gilt: „Logs, Metrics und Traces werden Codex über einen lokalen Observability-Stack bereitgestellt, der für jeden Worktree ephemeral ist.“ Jeder Agent Worktree erhält ein eigenes kurzlebiges Loki + Prometheus + Tempo, nur für diesen Run. Der Agent fragt es während seiner Arbeit ab. Dadurch kann ein Prompt wie „Kein Span in diesen vier User Journeys überschreitet zwei Sekunden“ zu etwas werden, das der Agent direkt verifizieren kann, statt es erraten zu müssen.

(Der Evaluator mit frischem Context aus der Failure-Modes-Tabelle liest diese Artefakte, um „done“ zu entscheiden. Er gehört zur Evaluation, nicht zur Observability; siehe § gesunder Run-Lifecycle. Er hängt von jeder oben genannten Oberfläche ab.)

Ein minimaler Self-hosted-Observability-Stack

Für etwas wie market-analyst-agent:

1. OpenTelemetry Collector mit dem GenAI Normalizer Processor (contrib, alpha) für unterstützte GenAI-Attribute. Verwenden Sie die generischen Attributes- oder Transform-Prozessoren, um gen_ai.*-Felder zu filtern oder umzuschreiben.
2. Tempo (oder Jaeger) für Traces, nach gen_ai.conversation.id / thread_id verschlüsselt.
3. Loki für strukturierte Event-Log-Einträge.
4. Prometheus für gen_ai.client.token.usage, gen_ai.client.operation.duration und gen_ai.client.operation.time_to_first_chunk – die gen_ai.server.*-Metriken stammen vom Model Server und sind daher nur verfügbar, wenn Sie die Weights hosten (siehe die GenAI Metrics Conventions).
5. Grafana-Dashboards, verschlüsselt nach gen_ai.agent.name und gen_ai.request.model.

Hosted Alternativen (eine auswählen, nicht drei):

• LangSmith: native LangGraph Integration; außerdem das Deployment-Ziel für Deep Agents Deploy.
• Braintrust: besonders geeignet, wenn Eval-first Regression Suites Priorität haben.
• Arize Phoenix: OSS, nativ zu OTLP (dem OpenTelemetry Wire Protocol), kombiniert mit OpenInference-Instrumentation.
• OpenAIs Tracing Dashboard: automatisch bei Verwendung des OpenAI Agents SDK oder seiner Temporal Integration.
• Anthropics Claude Tracing: für Sessions, die innerhalb von Managed Agents laufen.

Den LangGraph Node instrumentieren

Dies ist ein illustrativer Ausschnitt und wird vom Example Runner des Repositorys übersprungen. Er setzt voraus, dass der LangGraph Node bereits einen aktiven OpenTelemetry span, das aktuelle thread_id und ein Provider-Response-usage-Objekt mit input_tokens und output_tokens besitzt; Tracer Setup, Export-Konfiguration und Provider-spezifisches Usage Mapping liegen außerhalb des Snippets.

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "<your-model-id>")
span.set_attribute("gen_ai.response.model", "<your-model-id>")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Die Attributnamen stammen unverändert aus der OpenTelemetry GenAI Semantic Conventions Registry.

Drei Dashboard-Queries, die Sie haben sollten

# Loki: output tokens per agent in the last hour (one completion event per call)
sum by (gen_ai_agent_name) (
    sum_over_time({service_name="market-analyst-agent"} | json | event = "model_call_completed" | unwrap gen_ai_usage_output_tokens | __error__="" [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Die LogQL Aggregation setzt genau ein geloggtes Completion Event pro Model Call voraus. Deduplicaten Sie diese Events vor der Ingestion; rate würde Tokens pro Sekunde statt dieser einstündigen Gesamtsumme melden. Validieren Sie das Field Mapping gegen Ihren deployed Loki Stream.

Das Debug-Bundle-Pattern

Wenn ein Run fehlschlägt, sollte der Worker ein /workspaces/${THREAD_ID}/_debug/ mit den Artefakten ablegen, die Sie in einem Postmortem anfordern würden:

• events.jsonl: Export aus dem separat geschriebenen Append-only Event Store des Harness, einschließlich Tool Intents, Outcomes, Approvals und Errors.
• checkpoints.jsonl: Graph-State-History aus checkpointer.list({"configurable": {"thread_id": ...}}), als Checkpoints statt als Event Log gekennzeichnet.
• last_state.json: StateSnapshot.values aus dem letzten erfolgreichen Super-Step.
• trace.json: OTLP-exportierte Spans des Runs; Metadata ist die Basis, und erfasster Content folgt der Trace Policy.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: Workspace Directory plus git diff gegen den Initializer Commit.
• screenshots/*.png: was der Agent gesehen hat.
• PROGRESS.md, feature-list.json und alle anderen vom Agent verfassten Progress Files.
• env.txt: Image Tags, Model Version, Harness Commit SHA.

Zusammen können diese Artefakte einem Menschen oder Reviewer Agent genügend Evidence liefern, um den Fehler zu rekonstruieren – vorausgesetzt, der Harness hat den Event Store geschrieben, solange der Run aktiv war. „Der Agent ist stecken geblieben“ ist vage. Ein illustrativer Report ist konkret: Session s_123 verbrauchte 71 Prozent ihrer Tokens damit, drei Commands zu wiederholen, nachdem npm install fehlgeschlagen war.

Die richtige Form auswählen: ein Entscheidungsleitfaden

Der Großteil des obigen Vergleichs lässt sich auf einige wenige Entscheidungen reduzieren.

Mit der Run-Länge beginnen

Verwenden Sie die Run-Länge als ersten Filter:

• Unter 30 Sekunden, idempotent: Request-Lifecycle-SDK in einem App Server.
• 30 s bis 60 min: Queue + Worker + Checkpoint DB.
• 60 min bis 24 h: dieselbe Queue + Worker-Form oder ein Cloud Run Job für One-shot-Arbeit. Verwenden Sie eine Durable Workflow Engine, wenn Sie zusätzlich Versioning und Replay benötigen.
• Mehr als 24 h, muss Deployments überstehen: Durable Workflow Engine (Temporal-Style). Cloud Run Jobs können lange Arbeit bis zu ihrem Task-Limit halten, bieten aber keine Replay-Semantics.
• Multi-Day Reinforcement-Learning-Training-Loops: K8s Job + Volume + Temporal.

Prüfen Sie nach diesem groben Filter Side Effects, Recovery, Replay, Isolation, Data Location und das Team, das den Service betreiben wird.

Plattform-Fit nach Use Case

Die Matrix ist dicht, und keine einzelne grüne Zelle entscheidet die Architektur; meist entscheiden die Conditional Cells, bei denen eine Plattform etwas nur mit einer Einschränkung unterstützt. Eine breite Workload-Abdeckung ist nützlich, zeigt aber weder Data Residency noch Replay Semantics, Provider Dependence, Operational Maturity oder die Kosten einer späteren State-Migration.

Die Conditional Cells folgen bei jeder Plattform derselben Regel. Die AWS/VPC- und GPU-Optionen von Deep Agents hängen von Hybrid Deployment oder einem Sandbox Provider ab; Managed Agents kann kundenbetriebene Execution verwenden, während die Orchestration gehostet bleibt. Die Zeile zur Sandbox-Auswahl enthält eine Integration mit einem externen Provider, die Sie auf einem eigenen Runtime bauen oder in einem Managed Harness konfigurieren. Sie verspricht keinen Snapshot des laufenden Zustands. Ein Kubernetes Job benötigt für einen interaktiven Request ebenfalls eine API- oder Queue-Schicht; schnelles Abschließen macht ihn nicht zu einem HTTP Service. Vergleichen Sie Network Access, Hardware, Recovery und State-Export-Path des ausgewählten Deployments, bevor Sie sich entscheiden. Die Zeile zum Harness Code betrifft den Zugang zur Loop-Implementierung, nicht die Portabilität eines Managed Deployments oder seines States. Kubernetes GPU Execution benötigt außerdem GPU Nodes, Treiber und ein Device Plugin.

Managed Agents erfordert Claude und eine von Anthropic betriebene Orchestration. Seine optionale Self-hosted Sandbox kann zu Execution in einem privaten Netzwerk passen; eine Anforderung, Inference oder Control Plane selbst zu hosten, schließt es jedoch weiterhin aus. Prüfen Sie, welche Tool Inputs, Results, Skills und Memory diese Grenze überschreiten dürfen. Interne Coding-Arbeit kann passen, wenn diese Data Flows akzeptabel sind und das Team den Betrieb des Harness delegieren möchte.

Modellieren Sie die Kosten, bevor Sie sich festlegen, nicht danach. Die Session-Hour-Zeile beträgt $0.08/Stunde zusätzlich zu den Standard-Token-Kosten. Wenn eine einzelne Session kontinuierlich liefe, wären das etwa $58/Monat pro Session. Bei 100 kontinuierlich laufenden Sessions wären es etwa $5.800/Monat vor Tokens. Multiplizieren Sie $0.08 mit Ihren erwarteten Concurrent-Session-Stunden, addieren Sie die Summe zu Ihrer Token-Rechnung und vergleichen Sie sie mit den Kosten eines Queue + Worker Stacks auf Ihrer eigenen Infrastruktur. Eine spätere Migration weg von Managed Agents ist ein Re-Platforming, keine Config-Änderung.

Hosted Harness versus Owned Harness

Die Unterscheidung betrifft, wer den Harness betreibt, nicht, wer seinen Code geschrieben hat. Hosted bedeutet, dass der Vendor die Harness Loop in seiner Infrastruktur betreibt und Sie eine API aufrufen. Owned bedeutet, dass Sie die Loop auf Ihrer eigenen Infrastruktur betreiben, selbst wenn der Harness Code von einem Vendor stammt.

LangChain erscheint auf beiden Seiten dieser Grenze, was häufig zu Verwirrung führt. Das Unternehmen liefert LangGraph, eine MIT-lizenzierte Library, die Sie selbst hosten (owned), und Deep Agents Deploy, ein Managed Product, das im Default-Cloud-Modus einen Deep-Agents-Harness auf LangSmith Deployment ausführt (hosted). Dasselbe Unternehmen, zwei unterschiedliche Operational Models. Sie wählen, wer die Loop betreibt, nicht wessen Logo auf der Library steht. (Deep Agents Deploy besitzt auch einen Self-hosted-Modus für Teams, die Harness-Ergonomie ohne die Cloud-Komponente möchten; dieser Modus gehört in die Owned-Kategorie.)

Wählen Sie einen Hosted Harness, wenn Model Support, Data Boundary, Recovery-Verhalten und Extension Points bereits passen. Wählen Sie einen Owned Harness, wenn Sie erwarten, dass sich diese Constraints ändern. Eine Migration zwischen beiden verändert State, Observability und Execution Boundaries. Testen Sie daher den Exit Path, bevor Production Data davon abhängt.

Hosted Sandbox versus eigene Execution Environment

Wählen Sie eine Hosted Sandbox, wenn Isolation, Pause/Resume oder Fork Semantics des Providers zum Threat Model und Startup Budget passen. Docker oder Fargate können für Trusted Internal Workloads mit VPC Access oder strikter Data Residency geeignet sein, aber ein Standard-Container ist keine ausreichende Boundary für Hostile Code. Part 4 behandelt das Isolation-Menü für diesen Fall.

State Stores: Git, DB und Object Storage nebeneinander

Long-Running Agents verwenden normalerweise drei State Stores gleichzeitig, weil jeder Store ein anderes Artefakt besitzt.

Git speichert Workspace State: den Code, die Dokumente und die Progress Files, die der Agent verändert. Jeder Commit gibt dem Harness einen stabilen Recovery Point und der nächsten Session eine kompakte History.

Die Checkpoint-Datenbank speichert Graph State: was entschieden wurde, welche Nodes liefen, welche Results zurückkamen und was als Nächstes laufen soll. Der Artifact Store hält große finale Outputs wie PDFs, Parquet-Dateien und Screenshots. Diese Artefakte gehören weder in Git noch in die Checkpoint-Datenbank.

Wann Git als State verwenden

Verwenden Sie Git, wenn der Workload codeförmig ist (Multi-File-Edits, Refactorings, App Generation) oder dokumentförmig genug, dass File History relevant ist. Das Pattern ist einfach: Erstellen Sie einen Run Branch, legen Sie einen Initializer Commit an und committen Sie an sinnvollen Grenzen: nach dem Setup, nach jedem Feature, nach erfolgreichen Tests und nach dem finalen Cleanup. Speichern Sie die neueste Workspace Commit SHA neben der Checkpoint Row. Beim Resume checkt der nächste Worker den Branch aus, liest git log --oneline -8, untersucht git status und den neuesten Diff und liest anschließend PROGRESS.md oder das Handoff File, das die vorherige Session geschrieben hat.

Damit wird Git zu einer Recovery-Oberfläche für das bearbeitete Artefakt, nicht zu einem Ersatz für die Checkpoint DB. Git kann zwei Fragen beantworten: Was wurde geändert, und welche Version hat die Tests bestanden? Es kann dem Harness nicht mitteilen, welcher Graph Node als Nächstes laufen soll, welcher Tool Call auf Approval wartet oder welcher Retry seinen Idempotency Key bereits verwendet hat. Anthropics Harness verwendet Initializer Commits plus Per-Feature-Commits als Source of Truth für die Workspace Recovery; das Model liest git log --oneline -8, um den State wiederherzustellen. Überspringen Sie Git, wenn das Arbeitsergebnis aus einer einzelnen Conversational Answer besteht. Der Overhead lohnt sich dann nicht.

Wann DB-Checkpointing verwenden

Verwenden Sie PostgresSaver-artiges Checkpointing, wenn der Agent eine Graph-Struktur mit mehreren Nodes besitzt, deren Intermediate State relevant ist (Planner → Researcher → Writer → Verifier). Das Referenz-Repo verwendet dies genau aus diesem Grund. Legen Sie keine Workspace-Artefakte im Terabyte-Maßstab in den Checkpoint; sie gehören in Object Storage.

Wann einen Artifact Store (S3 / GCS) verwenden

Verwenden Sie Object Storage, wenn:

• der Output größer ist, als die Checkpoint-Datenbank tragen sollte;
• Downstream Consumer ein URL-addressable Artifact benötigen, ohne über den Agent zu gehen; oder
• Deliverable und Run State unterschiedliche Retention Windows haben.

Sie könnten beispielsweise das Session Log nach 30 Tagen löschen, den finalen Report aber jahrelang aufbewahren. Strukturieren Sie das Layout nach (thread_id, checkpoint_id, artifact_name), damit der erzeugende Run reconstructable bleibt.

Wann eine Human Approval erforderlich ist

Legen Sie Approval Requirements anhand des Action Risks, der bereits erteilten Authority und der Deployment Policy fest. Ein reversibler Draft Database Write unterscheidet sich von einer Kundenbelastung oder einer destruktiven Production-Änderung. Wenn eine Approval erforderlich ist, zeigen Sie die tatsächliche Aktion, Arguments und Destination an, persistieren Sie die Entscheidung und prüfen Sie sie erneut, wenn sich der vorgeschlagene Call ändert; führen Sie einen abgelehnten Call nicht aus. LangGraphs interrupt() und Deep Agents’ Approval Middleware können den Run für diese Entscheidung pausieren. Part 4 erklärt, warum es sich hierbei um eine Permission Decision und nicht um eine Prompt Instruction handelt.

Eine praktische Production-Checkliste

Bevor ein Long-Running Agent ausgeliefert wird, beantworten Sie diese Fragen in konkreten Infrastrukturbegriffen.

1. Welcher Store besitzt Session Events und Checkpoints?
2. Was passiert, wenn der Worker mitten in einem Tool Call stirbt?
3. Kann ein Run den Workspace eines anderen Runs beschädigen?
4. Welche Actions benötigen Approval?
5. Können Model oder Sandbox Raw Credentials lesen?
6. Welche Tool Calls können sicher retried werden?
7. Wo wird das Cost Cap pro Run durchgesetzt?
8. Welche deterministische Evidence entscheidet über Completion, und welche verbleibenden Kriterien benötigen einen Reviewer?
9. Wo liegen die finalen Outputs, nachdem die Sandbox verschwunden ist?
10. Können wir morgen einen fehlgeschlagenen Run erklären, ohne ihn erneut auszuführen?

Wenn die Antwort auf eine dieser Fragen lautet: „Der Prompt weist den Agent an, vorsichtig zu sein“, ist das System noch nicht deployed. Es ist weiterhin eine Demo.

Die nächste Schicht ist die Harness Loop

Dieser Runtime kann einen Run am Leben und recoverable halten, aber Durability beweist nicht, dass die Arbeit korrekt ist. Part 6, Harness Engineering for AI Agents, öffnet das oben tabellarisch beschriebene Harness Primitive: wie ein Trace zeigt, welche von mehreren Failure Modes tatsächlich vorliegt, wo Retry- und Stop-Regeln liegen, was ein Handoff bewahren muss und wie ein externer Acceptance Check entscheidet, dass ein Run abgeschlossen ist. Dies ist zugleich der letzte Beitrag der Serie.

Referenzen

Engineering-Berichte

• OpenAI, Harness engineering: leveraging Codex in an agent-first world.
• Anthropic Engineering, Effective harnesses for long-running agents.
• Anthropic Engineering, Harness design for long-running application development.
• Anthropic Engineering, Scaling Managed Agents: Decoupling the brain from the hands, 8. April 2026.
• Cognition AI, Rebuilding Devin for Claude Sonnet 4.5: Lessons and Challenges.
• Vercel, We removed 80% of our agent’s tools.
• Addy Osmani, Long-running Agents.

LangGraph und Deep Agents

• LangGraph Docs, Persistence.
• LangGraph Reference, Checkpoints.
• langgraph-checkpoint-postgres auf PyPI.
• LangChain Docs, Deep Agents Overview.
• LangChain Docs, Deep Agents Permissions.
• LangChain Blog, The runtime behind production Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox Concepts.

Temporal

• Temporal Blog, Introducing Temporal and agentic sandboxes: the OpenAI Agents SDK.
• Temporal Blog, Production-ready agents with the OpenAI Agents SDK + Temporal.
• Temporal × OpenAI Agents SDK Contrib README (temporalio/sdk-python).

Anthropic Platform

• Anthropic, Claude platform pricing: Managed-Agents-Session-Hour-Raten.
• anthropics/cwc-long-running-agents: Code with Claude 2026 Take-home mit Evaluator Sub-Agent und Progress-File-Patterns.

Sandbox Provider

• ZenML, E2B vs Daytona: sandbox comparison for platform engineers.
• Daytona Docs, Sandboxes.
• Daytona Changelog, Sandbox fork and snapshot endpoints.
• Modal Docs, Sandboxes.
• Modal Docs, Cold start guide.
• Runloop on AWS Marketplace.
• Vercel Sandbox pricing and limits.

Cloud-Platform-Timeouts und Quotas

• Google Cloud, Configure request timeout for services.
• Google Cloud, Using WebSockets.
• Google Cloud, Set task timeout for jobs.
• AWS, Configure Lambda function timeout.
• AWS, Lambda quotas.
• AWS, Fargate throttling quotas.
• AWS, ECS service quotas and API throttling limits.

Observability

• OpenTelemetry, Semantic conventions for generative AI systems.
• OpenTelemetry, Gen AI attributes registry.
• OpenTelemetry, Semantic conventions for GenAI agent and framework spans.
• OpenTelemetry, Semantic conventions for generative AI metrics.

Der Market Analyst Agent Code (LangGraph Worker, Postgres Checkpointer, Qdrant Memory, MCP Sidecar und die oben beschriebene Docker-Compose-Topologie) befindet sich auf GitHub.