Zum Inhalt

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Runtime für langlaufende AI-Agenten im Jahr 2026: Sessions, Sandboxes, Checkpoints und Harnesses

Teil 5 der Reihe Engineering the Agentic Stack

Die vorherigen vier Beiträge behandelten das Innere des Agenten: Reasoning Loops, Memory-Architektur, Tool-Nutzung, Sicherheit. Dieser hier behandelt die Außenseite: die Produktions-Runtime um langlaufende AI-Agenten herum.

Produktive AI-Agenten im Jahr 2026 sind keine Request-Handler mehr, sondern Background-Worker. Ein Run kann mehrere Stunden dauern. Der Worker, auf dem er läuft, vielleicht nicht. Die interessante Engineering-Arbeit ist aus dem Agenten heraus in die Runtime um ihn herum gewandert. Das Modell wählt den nächsten Schritt. Die Runtime entscheidet, was mit diesem Schritt passiert, wenn der Worker mitten im Call stirbt.

TL;DR: Langlaufende AI-Agenten brauchen eine Runtime außerhalb des Modells: Session-Logs, Harness-Logik, Sandbox-Isolation, Checkpoints, Traces, Policy-Checks, Secrets und Kostenlimits. Queue + Worker + Checkpoint-DB ist der Standard, wenn ihr den Stack selbst betreibt; gehostete Harnesses passen, wenn die Vendor-Constraints akzeptabel sind. Entscheidet zuerst nach Run-Länge, dann nach Recovery-Semantik, Replay-Bedarf, Sandbox-Isolation und operativer Ownership.

Es ist ein langer Beitrag. Das findet ihr darin:

Die erste Hälfte geht die fünf Runtime-Primitiven und die Failure-Modes durch, die jede davon abfangen soll. Die zweite Hälfte vergleicht elf Deployment-Formen — SDK-im-App-Server, Queue + Worker, Temporal, Anthropic Managed Agents, Deep Agents Deploy, Cloud Run, Lambda, ECS, Kubernetes Job pro Session plus zwei weitere — und endet mit einem Entscheidungsleitfaden für die Auswahl.

Was sich ändert, wenn langlaufende Agent-Sessions Prozesse überleben

Vor einem Jahr bedeutete „einen Agenten deployen“, einen Chat-Endpunkt in einen Container zu packen und einen Load Balancer darauf zu zeigen. Die Arbeit war von jedem anderen Python-Webservice nicht zu unterscheiden. Das änderte sich in dem Moment, als Agenten Stunden statt Sekunden liefen.

Das OpenAI-Codex-Team hat in seinem Write-up zu Harness Engineering eine Zahl für diese neue Baseline genannt:

„We regularly see single Codex runs work on a single task for upwards of six hours (often while the humans are sleeping).“

Das Engineering-Team von Anthropic formulierte das strukturelle Problem ebenso klar in Effective harnesses for long-running agents:

„The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before.“

Nehmt diesen Satz ernst, und der gesamte Runtime-Stack verändert seine Form. Aus „diskrete Sessions ohne geteilten Speicher“ folgen drei Konsequenzen, und jede davon erzwingt eine bestimmte Infrastrukturkomponente.

Wenn Sessions diskret sind, muss die Session außerhalb des Prozesses leben. In-Memory-State ist weg, sobald der Worker endet, also muss die Session in einen dauerhaften Store geschrieben werden, den der nächste Worker lesen kann. Wenn eine Session nach einem Crash fortgesetzt werden kann, muss der dauerhafte Record alles enthalten, was bis dahin passiert ist, nicht nur die finale Antwort. So kann der nächste Worker am richtigen Punkt weitermachen, statt den Run komplett neu abzuspielen. Wenn das Modell sein Context Window füllt, bevor die Arbeit fertig ist, muss etwas den Fortschritt checkpointen, die aktuelle Session beenden und eine frische starten, die den Checkpoint lädt, statt die gesamte Historie zu replayen. In Anthropics Formulierung wird das Harness zu „cattle“: austauschbare, neu startbare, identische Instanzen. Der State lebt woanders.

Das Modell entscheidet, was als Nächstes zu tun ist. Die Runtime entscheidet, ob der Schritt erlaubt ist, wo er ausgeführt wird, wie er aufgezeichnet wird und wie der Run nach einem Crash fortgesetzt wird. Der Rest dieses Beitrags behandelt genau diese Runtime.

Die fünf Runtime-Primitiven, die jeder langlaufende AI-Agent braucht

Der Text Scaling Managed Agents von Anthropic hat der Branche ein brauchbares Vokabular gegeben, und große Teile des Feldes haben sich darauf geeinigt. Fünf Komponenten leisten den Großteil der Runtime-Arbeit. Das Harness treibt den Agenten Schritt für Schritt voran; die Session zeichnet auf, was er getan hat; die Sandbox ist der Ort, an dem Kommandos ausgeführt werden; der Checkpoint ist das, was der nächste Worker beim Resume liest; der Trace ist das, was ihr Tage später lest, wenn ihr verstehen müsst, was schiefgelaufen ist. Jede Komponente ist austauschbar, solange die Verantwortung erhalten bleibt.

Die fünf Runtime-Primitiven

Session. Ein Append-only-Log von allem, was passiert ist: Modell-Calls, Tool-Calls, Ergebnisse, Fehler, Freigaben. Recovery ist wake(sessionId) → getSession(id) → resume from last event. In LangGraph ist das ein thread_id plus ein Postgres-Checkpointer (siehe LangGraph persistence). Das OpenAI Agents SDK bringt zehn eingebaute Session-Backends mit, darunter SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession und EncryptedSession (siehe die Sessions-Dokumentation).

Harness. Die Orchestrierungsschleife. Sie ruft das Modell auf, parst Tool-Calls, führt sie aus, schreibt Ergebnisse zurück in die Session und wendet Retry-Regeln an. Anthropic formuliert es direkt:

„every component in a harness encodes an assumption about what the model can't do on its own.“

Das Codex-Team von OpenAI nennt diese Disziplin harness engineering: Software zu schreiben erfordert weiter Disziplin, aber ein größerer Teil davon fließt jetzt in das Scaffold statt in den Code selbst. LangGraphs CompiledStateGraph, Deep Agents’ create_deep_agent und Claude Code selbst sind in diesem Sinn alles Harnesses.

Sandbox. Die isolierte Ausführungsumgebung, in der Kommandos tatsächlich laufen. Die Seite zu Sandbox-Konzepten im OpenAI Agents SDK zieht die Grenze sauber:

„The outer runtime still owns approvals, tracing, handoffs, and resume bookkeeping. The sandbox session owns commands, file changes, and environment isolation.“

Sandboxes unterscheiden sich darin, wie lange sie leben und was sie zwischen Runs behalten. Die einfachste Form ist fresh ephemeral: für einen einzelnen Task hochfahren, nach Ende des Tasks zerstören und bei jedem Run die Cold-Start-Kosten zahlen. Persistent paused-Sandboxes bleiben zwischen Runs in pausiertem Zustand erhalten; Dateisystem und Memory-Snapshot bleiben bestehen, sodass der nächste Resume unter einer Sekunde statt nach vollständigem Boot erfolgt. Snapshot or fork geht einen Schritt weiter: Jeder Task verzweigt ein Copy-on-Write-Image von einem Parent, in dem Dependencies bereits installiert und Caches aufgewärmt sind, sodass die teure Setup-Arbeit einmal statt N-mal passiert. Per-worktree-Sandboxes geben jedem Task seinen eigenen Workspace und seinen eigenen Observability-Stack: getrennte Logs, Metriken und Traces. Damit könnt ihr den Run eines Agenten debuggen, ohne dass er in andere hineinblutet. Konkrete Cold-Start- und Persistenzzahlen pro Provider stehen weiter unten in diesem Abschnitt in der Tabelle.

Checkpoint. Wiederaufnehmbarer State. LangGraphs PostgresSaver schreibt an jeder Super-Step-Grenze einen StateSnapshot, mit per-Task-Writes nach checkpoint_writes, sodass erfolgreiche Node-Outputs nicht neu berechnet werden, wenn ein Sibling fehlschlägt. Der Snapshot ist ein JSON-serialisierbares Dict (v, ts, id, channel_values, channel_versions, versions_seen, pending_sends), dokumentiert auf der PyPI-Seite langgraph-checkpoint-postgres und in der LangGraph-Referenz zu Checkpoints.

Trace. Die Oberfläche für Replay und Debugging. Jeder Modell-Call, Tool-Call und jeder Subagent-Schritt wird zu einem Span mit Timing, Inputs, Outputs, Token-Zahlen und Kosten. Wenn ein sechs Stunden dauernder Run fehlschlägt, ist der Trace das, was ihr lest, um herauszufinden, was schiefging. Die Terminal-Ausgabe des Runs ist dann längst weg. Die GenAI Semantic Conventions von OpenTelemetry standardisieren die Attributnamen (welches Modell, welcher Provider, wie viele Tokens, welche Conversation, welcher Workflow), sodass derselbe Trace ohne Re-Instrumentierung sauber in Tempo, Jaeger, Honeycomb oder LangSmith dargestellt wird.

Policy und Secrets sind eigene Runtime-Grenzen

Zwei Grenzen schneiden quer über alle fünf Primitiven und lassen sich leichter als separate Concerns denken. Sie sind die Runtime-Version des Sicherheitsarguments aus Teil 4.

Policy Engine

Vor jedem Tool-Call läuft ein Permission-Check und entscheidet, ob er durchgeht. In Produktion sind zwei Muster verbreitet. Deep Agents lässt jeden Subagent deklarieren, welche Dateipfade er lesen oder schreiben darf, und die Middleware blockiert alles außerhalb dieser Deklaration. Anthropic Managed Agents routet jeden Tool-Call durch einen MCP-Proxy, sodass der Proxy die Berechtigungen durchsetzt statt des Agent-Codes. Wenn ein sensibler Call menschliche Freigabe braucht, pausieren LangGraphs interrupt() und der Approval Hook von Deep Agents den Graphen, bis eine Person zustimmt.

Secret Broker

Das Modell sollte keine langlebigen Secrets sehen, und die Sandbox in der Regel auch nicht. Das Managed-Agents-Muster ist das, das man kopieren sollte:

„For Git, we use each repository's access token to clone the repo during sandbox initialization and wire it into the local git remote. Git push and pull work from inside the sandbox without the agent ever handling the token itself. For custom tools, we support MCP and store OAuth tokens in a secure vault. Claude calls MCP tools via a dedicated proxy; this proxy takes in a token associated with the session. … The harness is never made aware of any credentials.“

Im Referenz-Stack market-analyst-agent liest der MCP-Sidecar OAuth-Tokens aus einem Docker-Secret (in Produktion: HashiCorp Vault) und exponiert dem LangGraph-Worker nur die Tool-Oberfläche. Der Worker sieht das Token nie. git push funktioniert. cat ~/.ssh/id_rsa nicht.

Ein praktischer Sanity-Check für euren eigenen Stack: Schreibt jede Komponente auf, die ihr betreibt, und welches der fünf Primitiven sie implementiert. Postgres kann Session und Checkpoint abdecken. Der Worker-Container ist das Harness. Ein Hosted-Sandbox-Service wie Daytona, Modal oder E2B ist die Sandbox. Tempo oder LangSmith ist der Trace. Wenn zwei Primitiven im selben Prozess leben, reißt ein Crash beide mit. Wenn zwei sich ein Credential teilen, reißt ein Leak beide mit. Beides führt man leicht versehentlich ein, wenn man schnell arbeitet: ein Worker, der auch Traces schreibt, ein Sidecar-Token, das auch die Checkpoint-DB aufschließt.

Failure-Modes in der Runtime produktiver AI-Agenten

Die Runtime existiert für Dinge, die das Modell nicht alleine kann: Retries steuern, sich erinnern, was es vor drei Stunden getan hat, das Dateisystem eines Runs von einem anderen isolieren, sich stoppen, bevor das Budget verbraucht ist. Wir haben inzwischen sieben Teile benannt: Harness, Session-Log, Sandbox, Checkpointer, Tracer, Policy Engine, Secret Broker. Sobald ein einzelner Agent-Run etwa 30 Minuten Wall Time überschreitet, taucht ein wiedererkennbares Set von Fehlern auf. Die meisten davon haben nichts mit Reasoning-Qualität zu tun; es sind Probleme mit State, Retries, Sandboxes und Budgets.

Die Fehler fallen lose in vier Gruppen:

  • Fehler in der Ausgabequalität: Der Agent meldet Erfolg, bevor die Arbeit tatsächlich fertig ist, vergisst bei einem Context-Window-Reset, was er getan hat, oder vertraut seiner eigenen Selbstbewertung und liefert kaputten Output aus.
  • Fehler bei der Kostenkontrolle: Der Agent bleibt in einer Retry-Schleife hängen oder verbraucht ein Token- oder Tool-Call-Budget, ohne etwas Nützliches zu produzieren.
  • State- und Crash-Fehler: Workspaces driften, weil ein Run Dateien eines anderen anfasst, Tool-Calls feuern mehrfach, weil Retries sie replayen, oder Arbeit geht verloren, wenn ein Worker zwischen Events stirbt.
  • Context-Window-Fehler: Das Modell fasst zusammen und beendet vorzeitig, weil es glaubt, ihm gehe der Platz aus, obwohl noch Spielraum im Window ist.

Die folgende Tabelle ordnet jedem Fehler das Mitigationsmuster, den Runtime-Hook, an dem die Mitigation sitzt, und ob die Mitigation bei der aktuellen Modellgeneration noch gebraucht wird, zu. Manche werden nicht mehr gebraucht. Je älter euer Harness ist, desto mehr veraltete Mitigations enthält es wahrscheinlich.

Failure-Modes und ihre Mitigations

Failure-Mode Mitigation Noch nötig? Runtime-Hook
Vorzeitiger Abschluss: Agent meldet zu früh Erfolg Generator/Evaluator-Split: Ein Evaluator mit frischem Kontext liest Dateien (nicht den Chat) und stimmt mit „done“ oder „not done“ ab. Default-FAIL bei jedem Acceptance-Check. Ja; auch Anthropics eigener Quick-Start cwc-long-running-agents bringt weiter einen Evaluator-Subagent mit. Subagent ohne Write/Edit-Tools und mit eigenem Context Window
Feature-Amnesie über Context Windows hinweg Initializer-Agent schreibt claude-progress.txt, feature-list.json, init.sh. Coding-Agent liest sie bei jedem Cold Boot. Ja; Compaction allein schließt die Lücke nicht. Boot-Hook vor dem ersten Modell-Call jeder Session
Doppelte Arbeit nach Session-Reset Append-only-Event-Log plus strukturierte Handoff-Datei. Jede neue Session startet mit pwd → read PROGRESS.md → review tests. Ja LangGraph-PostgresSaver-Checkpoint plus progress.md-Artefakt
Context Anxiety: Modell fasst zusammen und beendet früh (a) Die 1M-Token-Beta aktivieren, aber effektive Nutzung bei 200k deckeln (Cognitions Sonnet-4.5-Fix). (b) Die Session beenden und aus einem Handoff neu aufbauen. Nein auf Opus 4.5; Anthropic berichtet, „the behavior was gone“ und die Resets seien „dead weight“ geworden. Ja auf Sonnet 4.5 und GPT-5/Codex. Outer Driver deckelt die Session-Länge, startet die nächste und setzt vom Checkpoint aus fort
Optimistische Selbstbewertung: Modell markiert Arbeit als bestanden Separater Evaluator plus Playwright/MCP-Grounding im echten DOM, nicht in Screenshots. Anthropics Harness-Design-Rubrik für Frontends bestraft „AI-style“-Defaults. Ja Evaluator läuft in einer separaten Sandbox-Session ohne Write-Tools
Hängende Loops und Retry-Stürme Iterationslimit pro Turn, exponentielles Backoff, Circuit Breaker auf Tool-Fehlerrate. Hartes Budget auf Tool-Calls. Ja Decorator auf dem Tool-Execution-Node; RetryPolicy auf Temporal Activities (siehe Temporal OpenAI Agents SDK contrib)
Workspace Drift: Agent bearbeitet nicht zusammenhängende Dateien Git-Commits als Checkpoints, File-Permission-Middleware, Workspace-Mount pro Session. Deep-Agents-Middleware lässt Read/Write auf Pfade deklarieren. Ja LangGraph-File-Permission-Middleware oder Daytona/Runloop-Fork pro Task
Ausreißende Token- oder Tool-Kosten Token-Budget pro Run, Budget pro Tool, Kill-Switch gekoppelt an einen Prometheus-Counter. Ja; eine 24-Stunden-Opus-Session mit schlechtem Budgeting kann an einem Nachmittag ein Wochenbudget an API-Kosten verbrennen (Addy Osmani über langlaufende Agenten). Span-Attribute für Kostenattribution plus Alertmanager-Regel
Nicht-idempotente Tool-Calls Idempotency-Key pro Tool-Call. In dauerhaften Workflows können Retries denselben Tool-Call mehrfach auslösen, daher blockiert ein Deduplication-Key das Duplikat. Ja Temporal Activity mit start_to_close_timeout und Idempotency-Key
Verlorene Arbeit nach Prozess- oder Sandbox-Crash Dauerhaftes Session-Log außerhalb des Prozesses; Checkpoint nach jedem Super-Step. wake(sessionId) → getSession(id) → resume. Ja PostgresSaver bei jedem Super-Step, oder als Temporal Workflow kapseln

Zwei Ideen tauchen in jeder Zeile auf. Anthropic, über Harness-Veraltung in Harness design for long-running application development:

„Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve.“

Vercel, über das verwandte Problem, dass zu viele Tools zu viele Annahmen codieren, in We removed 80% of our agent's tools:

„We deleted most of it and stripped the agent down to a single tool: execute arbitrary bash commands. We call this a file system agent.“

Vercels berichtetes Ergebnis auf einer repräsentativen Query: Die Erfolgsrate stieg von 80 % auf 100 %, und der Worst Case fiel von 724 s / 100 Schritten / 145.463 Tokens (fehlgeschlagen) auf 141 s / 19 Schritte / 67.483 Tokens (erfolgreich). Die Lehre ist nicht „löscht eure Tools“. Sie lautet: Jedes Primitive in eurer Runtime, einschließlich der Tool-Oberfläche, hat eine Halbwertszeit. Testet die Annahme neu, wenn sich das Modell ändert.

Cognition sah dasselbe bewegliche Ziel bei der Session-Länge mit Sonnet 4.5. In Rebuilding Devin for Claude Sonnet 4.5 beschreiben sie ein Modell, das proaktiv SUMMARY.md / CHANGELOG.md schreibt, wenn es eine Erschöpfung des Kontexts spürt, aber unterschätzt, wie viele Tokens noch übrig sind. Ihr Fix ist, die 1M-Token-Beta zu aktivieren und die Nutzung bei 200k zu deckeln, sodass das Modell weiter glaubt, Headroom zu haben. Auch diese Mitigation wird irgendwann Dead Weight werden.

Das Harness-Team von OpenAI hat die One-Line-Version dieser Disziplin: „Humans steer. Agents execute.“ Wenn etwas fehlschlägt, lautet die Frage nicht „noch härter versuchen“. Sie lautet: „Welche Fähigkeit fehlt, und wie machen wir sie für den Agenten sowohl lesbar als auch erzwingbar?“

Der gesunde Run-Lifecycle

Ein gut erzogener Run ist langweilig. Er ist eine Kette kleiner, wiederherstellbarer Schritte, von denen jeder sein Ergebnis in durable Storage schreibt, bevor der nächste beginnt, statt eines einzigen großen Requests, der end-to-end erfolgreich sein muss. Einen Run so in Schritte zu teilen, lässt ihn Crashes überleben: Wenn etwas fehlschlägt, geht nur der Schritt verloren, der gerade in Flight war, und der nächste Worker setzt beim letzten abgeschlossenen Schritt fort, statt neu zu beginnen.

Der Lifecycle eines deployten Agent-Runs

  1. Boot entweder aus einer frischen Session oder einer fortgesetzten. Beim Resume den Workspace aus seinem letzten bekannten Zustand mounten, Progress-Dateien lesen, die der vorherige Versuch hinterlassen hat (PROGRESS.md, feature-list.json), und den letzten Checkpoint aus der Datenbank laden. Hier gibt das Harness dem Agenten alles, was der vorherige Worker im Speicher hatte, bevor er starb.
  2. Planen, bevor Tool-Calls feuern. Festhalten, wie „done“ aussieht, wie viel der Run ausgeben darf, welche Tools der Agent aufrufen darf und was den Run frühzeitig stoppen soll. Diese Planwerte werden zu Runtime-Checks; ohne sie hat die Ausführung nichts, woran sie sich reiben kann.
  3. Genau einen Tool-Call zur Zeit ausführen. Die Policy-Schicht entscheidet, ob der Call erlaubt wird. Das Harness führt ihn aus, erfasst das Ergebnis und schreibt ein Event in das Session-Log. Ein Schritt, ein Event. Ein Crash zwischen Events ist recoverable, weil das Log und nicht der Speicher des Workers die Source of Truth ist.
  4. An Super-Step-Grenzen checkpointen, oder nach jedem Event in einem einfacheren Harness. Den Graph-State, den Workspace-Diff und Referenzen auf produzierte Artefakte persistieren. Diesen Checkpoint liest Schritt 1 beim nächsten Resume. Fehlt der Checkpoint oder ist er stale, degradiert Recovery zu einem Replay des kompletten Session-Logs von vorne, was viel langsamer ist.
  5. Gegen die Artefakte evaluieren, wenn der Agent glaubt, fertig zu sein: Tests, ein Reviewer mit frischem Kontext, Schema-Validierung, Browser-Checks. Wenn der Check besteht, endet der Run erfolgreich. Wenn nicht, setzt der Run vom letzten sauberen Checkpoint aus fort, ergänzt die Failure-Message im Kontext und versucht es erneut.

In dieser Liste gibt es keinen Schritt, der voraussetzt, dass sich der Agent zwischen Runs etwas merkt. Der State lebt in Session und Checkpoint, und der Agent liest ihn bei jedem Resume wieder ein.

Tools mit Side Effects brauchen Idempotenz. Jedes Tool mit Side Effects braucht einen Idempotency-Key, abgeleitet aus Session-ID und Tool-Call-ID, der gespeichert wird, bevor der Side Effect ausgelöst wird. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). At-least-once-Execution ist der Default in Queues und Workflow-Engines. Wenn das Wiederholen eines Tool-Calls realen Schaden verursachen kann, ist das Tool für Agenten nicht bereit.

Evaluation muss außerhalb des produzierenden Kontexts laufen. Derselbe Kontext, der die Antwort produziert hat, kann nicht zuverlässig beurteilen, ob die Antwort korrekt ist. Ein frischer Evaluator liest Dateien und Artefakte, führt Tests, Lints, Browser-Checks oder Schema-Validierung aus und gibt pass, fail oder needs_human zurück. Für Code-Agenten ist das eine weitere Modell-Session mit Read-only-Tools. Für Daten- und Report-Agenten ist es ein deterministischer Validator plus ein Review-Modell.

Elf Deployment-Muster für AI-Agenten und was die Auswahl bestimmt

Sobald die fünf Primitiven benannt sind, lautet die Frage, welche Deployment-Form sie ausführt. Mit „Form“ meine ich eine Anordnung dieser Primitiven: wo das Harness lebt, wo State persistiert und welche Art von Sandbox die Arbeit ausführt. Es geht nicht nur um die Wahl eines einzelnen Vendors. Die folgende Grafik zeigt, bei welcher Run-Länge sich jede Form wohlfühlt. Der Text danach erklärt, was zwischen ihnen entscheidet.

Wenn ihr nur eine der elf Formen lest, dann Form 2: Queue + Worker + Checkpoint-DB. Das ist die Default-Empfehlung für die meisten Teams, die Form des Referenz-Repos und das Skelett, von dem die meisten anderen Formen Varianten sind: queue → worker → durable state, wobei Sandbox-Quelle, Harness-Owner oder State-Engine ausgetauscht werden. Wer Form 2 zuerst liest, scannt den Rest schneller.

Deployment-Formen und ihre Sweet Spots bei der Run-Länge

Die Grafik vergleicht die Formen nach Run-Länge. Die Matrix darunter vergleicht sie nach Ownership: wo jedes der fünf Primitiven physisch lebt. Grüne Zellen sind die Stellen, an denen die Form das Primitive bereitstellt; Grau ist das, was ihr selbst verdrahtet.

Wo jedes Primitive in jeder Deployment-Form lebt

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

Die ursprüngliche Form. Das Agent-SDK läuft in einem Request-Handler. Gut für Tasks unter 30 Sekunden, Demos und interne Tools. Schlecht für alles, von dem ein HTTP-Client die Verbindung trennen könnte. Das HTTP-Timeout von Cloud Run endet bei 60 Minuten, und jede Web-Tier-Panik tötet den Run. Das SDK ist das Harness, der Webprozess fungiert zusätzlich als Sandbox, und State lebt meistens im Prozessspeicher, außer ihr schiebt ihn explizit woanders hin. Für Arbeit über mehrere Stunden ist das ungeeignet.

2. Queue + Worker + Checkpoint-DB

Die Standardempfehlung für die meisten Teams und die Produktionsform in market-analyst-agent: ein Python-Worker mit PostgreSQL-Checkpointer, Redis Streams (oder RabbitMQ) als eingehende Queue und ein MCP-Sidecar für Tools. Gut für Runs von 10 Minuten bis zu mehreren Stunden mit idempotenten Schritten. Der lokale Runner kann die Queue für synchrone Entwicklung umgehen, aber in Produktion gehört die Queue zur Form, sobald ihr asynchrone Submission und Backpressure braucht.

Die App nimmt einen Request an, legt eine Session-Zeile an, schiebt einen Job in die Queue und gibt eine Run-ID zurück. Der Worker zieht den Job, führt das Harness aus, schreibt Checkpoints, streamt Status und speichert währenddessen Artefakte. Postgres überlebt, Worker sind cattle, und Queue-Tiefe gibt euch Backpressure. Spot-/Preemptible-Compute funktioniert, solange der Checkpointer fertig in den Speicher schreibt, bevor er Erfolg meldet.

In dieser Form ist der Worker das Harness. Der Worker-Container plus ein Workspace-Mount pro Thread ist die Sandbox. Postgres hält Session- und Checkpoint-State. Traces gehen per OpenTelemetry in euren jeweiligen Observability-Stack.

3. Durable Workflow Engine (Temporal-Stil)

Agent-Orchestrierungscode läuft in einem Temporal Workflow; Modell-Calls und Tool-Calls laufen als Activities. Workflow-State lebt in einem Event-History-Log auf Basis von Cassandra, MySQL oder Postgres, sodass State Deploys sauber überlebt und replayt wird. Die Public-Preview-Integration Temporal × OpenAI Agents SDK bringt einen OpenAIAgentsPlugin und einen activity_as_tool-Helper mit, und der Text zu agentic sandboxes beschreibt, wie ein laufender Agent mitten in der Conversation auf einen anderen Sandbox-Provider umgezogen wird. Idle Workflows verbrauchen keine Compute-Ressourcen. Die Caveats sind real: Streaming- und Voice-Agenten werden in der aktuellen Integration nicht unterstützt, und LocalShellTool und ComputerTool sind deaktiviert, weil sie nicht zu einem verteilten Modell passen.

Nutzt diese Form, wenn der Run echte Waiting Points hat: menschliche Freigaben, externe Callbacks, lange Sleeps, Retries mit Business-Regeln, Deploy-Fenster. Eine menschliche Freigabe wird dann zu einem dauerhaften Sleep ohne Compute-Verbrauch statt zu einer Polling-Schleife.

Der Workflow-Code ist das Harness. Die Sandbox lebt meist außerhalb von Temporal und wird aus Activities aufgerufen. Session- und Checkpoint-State fallen in das Event-History-Log von Temporal zusammen, während Trace-Sichtbarkeit aus Temporal UI plus OpenTelemetry-Spans pro Activity kommt.

4. Sandbox-Provider pro Session

Eine neuere Form. Jeder Agent-Run bekommt seine eigene microVM oder seinen eigenen Container von einem Sandbox-as-a-Service-Provider. Das Harness lebt irgendwo durable; die Sandbox ist die wegwerfbare Ausführungsumgebung.

Provider Isolation Max. Session Concurrency Persistenz Cold Start
E2B Firecracker microVM 1 h Hobby / 24 h Pro 20 / 100 (bis 1.100 per Add-on) Pause/Resume, ~4 s/GiB Pause, ~1 s Resume (Public Beta) ~150 ms p50
Vercel Sandbox Firecracker microVM 45 min Hobby / 5 h Pro/Ent 10 / 2.000 Wegwerfbar n/a
Daytona Docker (optional Kata) konfigurierbares Auto-Stop/Archive tier-basiert Stop → Archive → Delete; Fork unterstützt ~90 ms (einige Konfigurationen 27 ms)
Modal Sandboxes gVisor typischerweise 1–15 min Lifecycle hoch Volumes für Persistenz; Memory Snapshot in Preview „about one second“ laut Modal-Doku
Runloop Devboxes microVM (custom hypervisor) suspend/resume; snapshot+branch „more than 30,000 concurrent instances“ laut AWS-Marketplace-Eintrag Snapshot + Branch aus Disk-State unter 1 s

Quellen: der Vergleich E2B vs Daytona, Dayonas eigene Sandboxes-Dokumentation und Fork/Snapshot-Changelog, Modals Sandboxes-Guide und Cold-Start-Guide, der Runloop-Eintrag im AWS Marketplace und Vercel-Sandbox-Preise. Die Daytona-Dokumentation enthält einen nützlichen Hinweis zur Fork-Semantik: „the new sandbox is fully independent … Daytona tracks the parent-child relationship in a fork tree.“ Jede geforkte Sandbox hält also einen aufgezeichneten Link zurück zur Basis, von der sie abgezweigt wurde, sodass sich die Lineage jeder abgeleiteten Sandbox abfragen lässt. Das Codex-Harness von OpenAI nutzt die Per-Worktree-Variante: „Codex works on a fully isolated version of that app, including its logs and metrics, which get torn down once that task is complete.“

Greift zu dieser Form, wenn der Agent nicht vertrauenswürdigen Code, Browser-Automatisierung, Tests oder Package-Installationen ausführt. Der Trade-off sind Kosten und Provider-Kopplung, beides höher als bei gemeinsam genutzten Workern.

Der Provider hält nur die Sandbox und sonst nichts. Harness, Session, Checkpoint und Trace bleiben auf eurer Seite, meist als Queue+Worker-Form aus #2 verdrahtet.

5. Anthropic Managed Agents (gehostetes Harness)

Am 8. April 2026 als Public Beta gestartet, hinter dem Beta-Header managed-agents-2026-04-01. Claude berechnet für Managed Agents Standard-Tokenpreise plus $0.08 pro Session-Stunde. Die Abrechnung ist millisekundengenau und fällt nur an, solange der Session-Status „running“ ist. Idle Time ist kostenlos; Session-Runtime „replaces the Code Execution container-hour billing model when using Claude Managed Agents.“ Ihr bekommt eine gehostete Session, ein gehostetes Harness, eine gehostete Sandbox und einen MCP-Proxy mit Vault-Backing. Der Brain/Hands-Split ist das, was wake(sessionId) bezahlt: Das Harness kann auf einem neuen Worker neu initialisiert werden, ohne State zu verlieren. Modelliert die Kostenform sorgfältig; eine ausreißende Retry-Schleife auf Session-Stunden-Basis summiert sich schneller als auf Token-Basis.

Lest die Caveats. Der Batch-API-Rabatt gilt nicht („Sessions are stateful and interactive. There is no batch mode.“). Managed Agents sind weder über AWS Bedrock noch über Google Vertex AI verfügbar. Multi-Agent-Koordination und Self-Evaluation bleiben Research Preview. Lock-in ist hoch: Ihr tauscht Harness-Freiheit gegen den Wegfall des eigenen Betriebs der Schleife.

Anthropic hostet alle fünf Primitiven: Session, Harness, Sandbox, Checkpoint und Trace. Ihr gebt die Runtime ab und bekommt die Outputs.

6. LangChain Deep Agents Deploy (gemanagtes offenes Harness)

deepagents deploy verpackt einen deepagents.toml in ein LangSmith Deployment mit durable Execution, Memory, Multi-Tenancy, Human-in-the-Loop, Observability, sandboxes für Code-Ausführung 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 einzelnen Config-Wert umschalten. State lebt in einem virtuellen Dateisystem mit austauschbaren Backends; Memory ist auf User, Assistant oder beide scoped. Lock-in ist geringer als bei Managed Agents: Das Harness ist MIT-lizenziert, Instructions nutzen den offenen Standard AGENTS.md, und Agenten werden via MCP, A2A und Agent Protocol exponiert. Siehe den LangChain-Beitrag runtime-behind-production-deep-agents.

Standardmäßig sind alle fünf Primitiven gehostet, aber jedes davon ist per Config austauschbar. Die Sandbox hängt hinter einem Config-Wert. Session und Checkpoint leben auf einem virtuellen Dateisystem mit austauschbaren Backends. Trace geht an LangSmith.

7. Google Cloud Run Service oder Job

Cloud Run hat zwei verschiedene Runtime-Modi, und welcher passt, hängt davon ab, wie der Agent aufgerufen wird. Services sind an HTTP gebunden und skalieren zwischen Requests auf null; das Harness läuft als Request-Handler, der zurückkehrt, wenn der Run fertig ist. Jobs laufen ohne HTTP-Entrypoint bis zur Fertigstellung; das Harness läuft als One-Shot-Worker, der endet, wenn der Task fertig ist. Beide können das Harness hosten, aber keiner hält State über Runs hinweg. Sessions und Checkpoints müssen in Postgres, Spanner oder einem ähnlichen externen Store leben.

Die harten Limits unterscheiden sich stark zwischen den beiden. Request-Timeout für Cloud Run Services: Default 300 s, Maximum 3.600 s (60 min). WebSockets haben dasselbe Timeout. Cloud Run Jobs: Default 10 min pro Task, Maximum 168 h (7 Tage); für Tasks mit GPUs maximal 1 Stunde. Services skalieren auf null, sofern ihr nicht always-on CPU aktiviert; Jobs haben kein HTTP und kein Autoscaling.

Nutzt einen Service für synchrone Runs bis 60 Minuten. Nutzt einen Job für längere One-Shot- oder Async-Arbeit. Cloud Run Jobs können einen Task tagelang am Leben halten, aber sie geben euch kein durable Replay über Deploys, Versionswechsel oder Worker-Ersatz hinweg. Oberhalb von 7 Tagen ist Cloud Run ungeeignet.

Cloud Run hostet das Harness. Session, Checkpoint, Sandbox und Trace sind externe Services, die ihr verdrahtet, typischerweise Postgres oder Spanner für Session/Checkpoint, der Container selbst als Sandbox und Cloud Logging plus OpenTelemetry für Trace.

8. AWS Lambda (warum es das falsche Werkzeug ist)

Das maximale Function-Timeout von Lambda beträgt hart 900 s (15 Minuten). API Gateway legt darauf noch ein separates Limit von 29 s. Ein Agent-Harness, dessen minimale sinnvolle Run-Dauer „Minuten bis Stunden“ ist, kann auf Lambda ohne externen State-Store und Re-Invocation-Strategie nicht überleben; damit baut ihr im Wesentlichen die Queue+Worker-Form von Grund auf neu nach. Nutzt Lambda für einzelne Tool-Calls, etwa Dateiabfragen oder S3-Uploads, aufgerufen von einem länger laufenden Orchestrator. Legt den Orchestrator nicht dort ab.

Im besten Fall hält Lambda einen Tool-Call innerhalb seines 15-Minuten-Limits. Harness, Session, Checkpoint, Sandbox und Trace müssen alle woanders leben.

9. AWS ECS / Fargate Task pro Run

Keine dokumentierte harte Obergrenze für die Laufzeit eines Tasks (anders als bei Lambda). Laut Fargate throttling quotas sind Starts aber rate-limitiert: Burst von 100, Refill mit 20 pro Sekunde, wobei On-Demand und Spot auf getrennten 20/s-Budgets laufen. ECS service quotas: Services mit AWS Cloud Map Service Discovery sind auf 1.000 Tasks pro Service begrenzt; die theoretische Obergrenze liegt bei 5.000 EC2-Instanzen pro Cluster. Fargate verlangt den Modus awsvpc, sodass jeder Task seine eigene Netzwerkschnittstelle und private IP bekommt — die richtige Form, wenn ihr auf VPC-interne Datenquellen zugreifen müsst. Fargate Spot ist verfügbar; plant Unterbrechungen ein. Durability liegt bei euch: Es gibt kein eingebautes Temporal-artiges Replay.

Fargate hostet das Harness und gibt jedem Run seine eigene Sandbox: ein Task pro Run. Session, Checkpoint und Trace gehen in externe Services. RDS oder DynamoDB plus CloudWatch/X-Ray sind die üblichen Picks.

10. Kubernetes Job oder Namespace pro Session

Gut, wenn ihr bereits Kubernetes betreibt und Sandbox-pro-Session mit clusterweiten Kontrollen wollt. Schlecht, wenn ihr Sub-Sekunden-Startup braucht, weil Image-Pull und Pod-Initialisierung im Cold Start zu lange dauern. Das Muster ist ein Job pro Agent-Run, mit activeDeadlineSeconds, einem PersistentVolumeClaim für den Workspace und einem Sidecar für den MCP-Server. Crash-Recovery müsst ihr selbst bauen. Nur um Agenten zu hosten, auf Kubernetes zu wechseln, ist teuer in Konfigurations-Overhead und Betriebsaufwand. Lohnt sich nur, wenn ihr K8s ohnehin aus anderen Gründen betreibt.

K8s hostet Harness und Sandbox, meist als ein Job pro Run und manchmal mit dediziertem Namespace für stärkere Isolation. Session und Checkpoint leben in einer externen DB oder auf einem PersistentVolumeClaim. Trace fließt in den In-Cluster-Observability-Stack, den ihr ohnehin betreibt.

11. Lokales Docker Compose (nur Dev)

Die Referenz für den nächsten Abschnitt. Der Punkt dieser Form ist, dass sie die Produktionstopologie eins zu eins spiegelt (gleiche Primitiven, gleiche Netzform), während alles auf einer einzelnen Maschine läuft. Lest die Liste „not production-safe“ am Ende des nächsten Abschnitts, bevor ihr irgendetwas ausliefert, das so aussieht.

Compose spiegelt Form #2 auf einem einzelnen Host. Postgres hält Session und Checkpoint. Der Worker-Container ist das Harness. Der Workspace-Mount ist die geteilte Sandbox. Der optionale OpenTelemetry-Stack ist der Trace.

Referenz-Stack: Docker Compose

Die Referenztopologie, genutzt in slavadubrov/market-analyst-agent, ist ein LangGraph-Worker, ein Postgres-Checkpointer, Qdrant für Retrieval, ein MCP-Sidecar, eine Redis-Queue für asynchrone produktionsähnliche Runs und ein optionaler Prometheus / Grafana / Loki / Tempo / OTel-Observability-Stack. In lokalem Compose ist Redis nur deshalb optional, weil der synchrone Runner den Worker direkt aufrufen kann. docker compose up fährt die gesamte Topologie lokal hoch.

Die Referenz-Docker-Compose-Topologie

Das eine Teil, das sich inline zu zeigen lohnt, ist das kanonische LangGraph-Wiring. Es ist das kleinste konkrete Beispiel für das Checkpoint-Primitive:

from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://agent:${POSTGRES_PASSWORD}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observability, die den Run überlebt

Kurze Request-Handler sind leicht zu debuggen: Wenn etwas fehlschlägt, lest ihr die Response und das Live-Log. Langlaufende Agenten haben diesen Luxus nicht. Wenn ein sechs Stunden langer Run fehlschlägt, ist das interessante Event fünf Stunden alt, die Live-Terminal-Ausgabe weg und der Worker, der sie produziert hat, bereits ersetzt. Niemand rekonstruiert den Run aus dem Gedächtnis. Debugging läuft also über dauerhafte Artefakte, die geschrieben wurden, während der Run noch lebte.

Produktions-Stacks decken meist vier Artefaktarten in zwei Gruppen ab. Zwei davon lest ihr nach dem Run, für Postmortems und Replay: ein abfragbares Event-Log jedes Schritts und OpenTelemetry-Traces darüber, wo Zeit und Tokens hingingen. Zwei davon lest ihr während des Runs, um ihn live zu beobachten: ein Live-Tail dessen, was der Agent im Workspace produziert, und ein Observability-Stack pro Worktree, den der Agent selbst abfragen kann, solange er noch läuft.

Strukturiertes Event-Log (nach dem Run lesen)

Jeder Modell-Call, Tool-Call, jedes Ergebnis, jeder Fehler und jede Freigabe wird in durable Storage geschrieben, indiziert nach Session-ID und Timestamp. Sobald der Run endet, fragt ihr es wie eine normale Datenbanktabelle ab. Addy Osmani setzt die Messlatte in Long-running Agents klar: „If you can't reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent.“

OpenTelemetry-GenAI-Traces (nach dem Run lesen)

Dieselbe Art schrittweiser Daten, aber als Spans mit den Standardattributen aus den Semantic Conventions gen_ai.*: Modellname, Provider, Eingabe- und Ausgabe-Tokenzahlen, Conversation-ID, Workflow-Name (Development-Status ab v1.36.0). Provider-spezifische Felder leben in Subnamespaces (anthropic.*, openai.*), die sich an gen_ai.provider.name orientieren. Der Grund, den Standard zu verwenden, ist Portabilität: Derselbe Trace rendert sauber in Tempo, Jaeger, Honeycomb oder LangSmith, ohne den Code bei jedem Backend-Wechsel neu zu instrumentieren.

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

Der schnellste Weg zu wissen, was ein Agent jetzt tut, ist, das zu tailen, was er im Workspace produziert, nicht das Session-Log zu durchsuchen. Anthropics Quick-Start Harness Primitives for Long-Running Claude Agents bringt dafür zwei Hooks mit: watch -n 5 'git log --oneline -8' zeigt die neuesten Commits des Agenten, und watch -n 5 'find screenshots -name "*.png" | tail -5' zeigt die neuesten Screenshots, die er aufgenommen hat. Zwei Terminal-Panes, die alle fünf Sekunden aktualisieren, reichen aus, um zu sehen, ob ein Run echten Fortschritt macht oder nur rotiert.

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

Laut OpenAIs Harness-Beitrag: „Logs, metrics, and traces are exposed to Codex via a local observability stack that's ephemeral for any given worktree.“ Jeder Agent-Worktree bekommt seinen eigenen kurzlebigen Loki + Prometheus + Tempo, auf genau diesen Run begrenzt. Der Agent fragt ihn während der Arbeit ab. Genau das macht einen Prompt wie „no span in these four user journeys exceeds two seconds“ zu etwas, das der Agent direkt verifizieren kann, statt es zu raten.

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

Ein minimaler Self-Hosted-Observability-Stack

Für so etwas wie market-analyst-agent:

  1. OpenTelemetry Collector mit dem GenAI-Prozessor und einem Attributfilter auf gen_ai.*.
  2. Tempo (oder Jaeger) für Traces, indiziert nach gen_ai.conversation.id / thread_id.
  3. Loki für strukturierte Event-Log-Einträge.
  4. Prometheus für gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (siehe die GenAI-Metrik-Konventionen).
  5. Grafana-Dashboards, indiziert nach gen_ai.agent.name und gen_ai.request.model.

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

  • LangSmith: native LangGraph-Integration; außerdem das Deployment-Ziel für Deep Agents Deploy.
  • Braintrust: stärkster Fit, wenn Eval-first-Regression-Suites Priorität haben.
  • Arize Phoenix: OSS, OTLP-nativ, kombiniert gut mit OpenInference-Instrumentation.
  • OpenAIs Tracing-Dashboard: automatisch, wenn ihr das OpenAI Agents SDK oder seine Temporal-Integration verwendet.
  • Anthropics Claude-Tracing: für Sessions, die in Managed Agents laufen.

Den LangGraph-Node instrumentieren

# 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", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
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)

Attributnamen wörtlich übernommen aus dem OpenTelemetry-Registry für GenAI Semantic Conventions.

Drei Queries, die ihr tatsächlich braucht

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [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 }

Das Debug-Bundle-Muster

Wenn ein Run fehlschlägt, sollte der Worker ein /workspaces/${THREAD_ID}/_debug/ ablegen, das die Artefakte enthält, die ihr in einem Postmortem ohnehin anfordern würdet:

  • session.jsonl: vollständiger Event-Log-Dump aus dem PostgresSaver (checkpointer.list({"thread_id": ...})).
  • last_state.json: StateSnapshot.values aus dem letzten erfolgreichen Super-Step.
  • trace.json: OTLP-exportierte Spans für den Run.
  • tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
  • workspace.tar.zst: das Workspace-Verzeichnis plus git diff gegen den Initializer-Commit.
  • screenshots/*.png: das, was der Agent gesehen hat.
  • PROGRESS.md, feature-list.json und alle anderen vom Agenten verfassten Progress-Dateien.
  • env.txt: Image-Tags, Modellversion, Harness-Commit-SHA.

Dieses Bundle ist das, was ein Mensch (oder ein anderer Agent) braucht, um herauszufinden, was passiert ist. Ohne es bleibt jeder gescheiterte Run eine Vermutung. „Der Agent ist stecken geblieben“ ist vage. Ein nützlicher Failure-Report sieht eher so aus: Session s_123 verbrauchte 71 Prozent der Tokens in einer Retry-Schleife aus drei Kommandos, nachdem npm install fehlgeschlagen war.

Die richtige Form wählen: ein Entscheidungsleitfaden

Der Großteil des obigen Vergleichs reduziert sich auf einige wenige Entscheidungen.

Mit der Run-Länge anfangen

Nutzt die Run-Länge als ersten Filter:

  • Unter 30 Sekunden, idempotent: request-lifecycle SDK in einem App-Server.
  • 30 s bis 60 min, keine Crash-Recovery nötig: Queue + Worker + Checkpoint-DB.
  • 60 min bis 24 h: dieselbe Queue+Worker-Form oder ein Cloud Run Job für One-Shot-Arbeit. Nutzt eine durable Workflow Engine, wenn ihr zusätzlich Versionierung und Replay braucht.
  • Mehr als 24 h, muss Deploys überleben: durable Workflow Engine (Temporal-Stil). Cloud Run Jobs können lange Arbeit bis zu ihrem Task-Limit halten, liefern aber keine Replay-Semantik.
  • Mehrtägige RL-Trainingsloops: K8s Job + Volume + Temporal.

Sobald die Run-Länge feststeht, ist der Rest Plattformwahl.

Plattform-Fit nach Use Case

Plattform-Fit nach Use Case

Die Matrix ist absichtlich dicht: elf Formen über viele Workload-Typen in einer Ansicht. Zwei Muster prägen fast jede Lesart.

Deep Agents Deploy ist die einzige Spalte mit Grün in jeder Zeile. Das bedeutet: Es ist die einzige Form in der Auswahl, die zu jedem Workload-Typ passt, den die Matrix abbildet: kurze Runs, mehrstündige Runs, Code-Agenten, Research-Agenten, Scheduled Jobs. Diese Breite ist das stärkste Argument dafür. Der Trade-off ist Reife. Das Harness wurde erst kürzlich ausgeliefert, und der Produktions-Track-Record ist geringer als bei älteren Alternativen wie einem Queue+Worker+Postgres-Stack, den Teams seit Jahren betreiben. Wenn „passt zu jedem Workload-Typ ohne Re-Platforming“ die wichtigste Constraint ist, akzeptiert die geringere Reife und wählt Deep Agents Deploy. Ansonsten bevorzugt die Form, die ihr ohnehin schon betreibt.

Anthropic Managed Agents passt entweder vollständig zu eurem Workload oder gar nicht. Das Produkt hat drei harte Constraints: hosted-only, Claude-only und unter 24 Stunden pro Session. Wenn euer Workload alle drei erfüllt — etwa ein interner Coding-Agent, der in 2–6-Stunden-Bursts läuft und bei dem ihr das Harness lieber nicht selbst betreiben wollt — dann passt Managed Agents gut und nimmt eurem Team einen großen Teil der Plattformarbeit ab. Wenn eine Constraint nicht passt, weil ihr ein Nicht-Claude-Modell, Self-Hosted-Compliance oder 48-Stunden-Runs braucht, dann passt Managed Agents nicht. Daran ändert keine Konfiguration etwas.

Das Pricing solltet ihr vor der Entscheidung modellieren, nicht danach. Die Session-Stunden-Zeile liegt bei $0.08/Stunde zusätzlich zu den Standard-Tokenkosten. Läuft eine einzelne Session durchgehend, sind das etwa $58/Monat pro Session. Bei 100 Sessions, die durchgehend laufen, sind das etwa $5.800/Monat vor Tokens. Multipliziert $0.08 mit euren erwarteten gleichzeitigen Session-Stunden, addiert es zu eurer Token-Rechnung und vergleicht es mit den Kosten eines Queue+Worker-Stacks auf eigener Infrastruktur. Macht das vor der Entscheidung, denn eine spätere Migration weg von Managed Agents ist Re-Platforming, kein Config-Change.

Gehostetes Harness vs. eigenes Harness

Der Unterschied ist hier operativ, nicht wer den Harness-Code geschrieben hat. Hosted bedeutet: Der Vendor betreibt die Harness-Schleife in seiner Infrastruktur und ihr ruft eine API auf. Owned bedeutet: Ihr betreibt die Schleife auf eurer eigenen Infrastruktur, selbst wenn der Harness-Code selbst von einem Vendor stammt.

LangChain taucht auf beiden Seiten dieser Linie auf, was Menschen oft verwirrt. Sie liefern LangGraph, eine MIT-lizenzierte Library, die ihr selbst hostet (owned), und Deep Agents Deploy, ein gemanagtes Produkt, das ein Deep-Agents-Harness auf LangSmith Deployment in seinem Standard-Cloud-Modus betreibt (hosted). Gleiches Unternehmen, zwei verschiedene Betriebsmodelle. Ihr wählt das Modell, nicht den Vendor. (Deep Agents Deploy hat auch einen Self-Hosted-Modus für Teams, die die Harness-Ergonomie ohne Cloud-Komponente wollen; dieser Modus gehört in die Owned-Kategorie.)

Wählt ein gehostetes Harness, wenn ihr keine Plattformkapazität habt und die Vendor-Constraints passen. Managed Agents bedeutet Claude-only. Deep Agents Deploy im Cloud-Modus bedeutet LangSmith in Produktion. Im Gegenzug übernimmt der Vendor Caching und Compaction.

Ein eigenes Harness (LangGraph, Deep Agents Deploy im Self-Hosted-Modus oder ein Custom-Harness auf einem SDK) ist die richtige Wahl, wenn ihr Plattform-Engineers habt, wenn ihr die Harness-Form schneller ändern müsst, als ein Vendor Updates ausliefert, wenn Compliance Datenresidenz unter eurer Kontrolle verlangt oder wenn Multi-Model-Routing über mehrere Provider nicht verhandelbar ist. Ihr bezahlt dafür mit Pagern und operativer Fläche.

Die meisten Teams sollten hosted starten, messen, was sie ändern müssen, und erst dann auf owned migrieren, wenn die Hosted-Constraints wirklich wehtun.

Hosted Sandbox vs. Docker-/Fargate-Sandbox

Wählt eine Hosted Sandbox, wenn die Zeit zur Sandbox-Erstellung zählt (unter 200 ms), ihr Session Pause/Resume mit Memory-State braucht oder Fork/Branch-Semantik benötigt. Wählt Docker oder Fargate, wenn ihr diese Compute ohnehin bezahlt, VPC-internen Zugriff auf sensitive Datenquellen braucht oder harte Data-Residency-Constraints habt.

State Stores: Git, DB und Object Storage nebeneinander

Langlaufende Agenten betreiben meist drei State Stores gleichzeitig, nicht einen, und jeder hält einen anderen State-Typ. Git speichert den Workspace-State: Code, Dokumente und Progress-Dateien, die der Agent verändert. Jeder Commit gibt dem Harness einen stabilen Recovery-Punkt und der nächsten Session eine kompakte Historie zur Inspektion. Die Checkpoint-DB hält den Graph-State des Harnesses: was entschieden wurde, welche Nodes liefen, welche Ergebnisse zurückkamen und was als Nächstes laufen soll. Genau das lässt den nächsten Worker mitten im Run fortsetzen. Der Artefakt-Store hält die großen finalen Outputs, etwa PDFs, Parquet-Dateien und Screenshots. Diese gehören weder in Git noch in die Checkpoint-DB.

Wann Git als State genutzt werden sollte

Nutzt Git, wenn der Workload code-shaped ist (Multi-File-Edits, Refactorings, App-Generierung) oder dokumentförmig genug, dass Dateihistorie zählt. Das Muster ist einfach: einen Run-Branch anlegen, einen Initializer-Commit machen und dann an sinnvollen Grenzen committen: nach Setup, nach jedem Feature, nachdem Tests bestehen, nach dem finalen Cleanup. Die aktuelle Workspace-Commit-SHA neben der Checkpoint-Zeile speichern. Beim Resume checkt der nächste Worker den Branch aus, liest git log --oneline -8, inspiziert git status und den letzten Diff und liest dann PROGRESS.md oder welche Handoff-Datei auch immer die vorige Session geschrieben hat.

Damit wird Git zu einer Recovery-Oberfläche für das zu bearbeitende Artefakt, nicht zu einem Ersatz für die Checkpoint-DB. Git kann zwei Fragen beantworten: Was hat sich geändert, und welche Version hat die Tests bestanden? Es kann dem Harness nicht sagen, welche Graph-Node als Nächstes laufen soll, welcher Tool-Call auf Freigabe wartet oder welcher Retry seinen Idempotency-Key schon verbraucht hat. Anthropics Harness nutzt Initializer-Commits plus Commits pro Feature als Source of Truth für Workspace-Recovery; das Modell liest git log --oneline -8, um den State zu rekonstruieren. Überspringt Git, wenn das Arbeitsprodukt nur eine einzelne konversationelle Antwort ist. Dann lohnt sich der Overhead nicht.

Wann DB-Checkpointing genutzt werden sollte

Nutzt Checkpointing im Stil von PostgresSaver, wenn der Agent eine Graph-Struktur mit mehreren Nodes hat, deren Zwischenzustand wichtig ist (planner → researcher → writer → verifier). Das Referenz-Repo nutzt genau deshalb dieses Muster. Legt keine Workspace-Artefakte im Terabyte-Bereich in den Checkpoint; diese gehören in Object Storage.

Wann ein Artefakt-Store (S3 / GCS) nötig ist

Greift in drei Situationen zu Object Storage. Erstens: Der Output ist größer als einige hundert KB. Checkpoint-DBs sind nicht dafür gebaut, große Blobs zu halten, und der Versuch macht sowohl DB als auch Checkpoint-Format schmerzhaft. Zweitens: Downstream-Consumer wie BI-Tools, Kunden oder andere Services brauchen URL-adressierbare Artefakte, die sie selbst abrufen können, ohne durch den Agenten zu gehen. Drittens: Das Retention-Window für den Run-State und das Retention-Window für das Deliverable driften auseinander. Ihr könnt das Session-Log nach 30 Tagen löschen, den finalen Report aber Jahre behalten. Strukturieret das Layout nach (thread_id, checkpoint_id, artifact_name), damit ihr immer rekonstruieren könnt, welcher Run welches Artefakt erzeugt hat.

Wann Human-Approval-Gates hinzugefügt werden sollten

Fügt Gates hinzu, wenn der Tool-Call destruktiv und irreversibel ist (DB-Writes, Geldbewegungen, Versand externer Kommunikation), wenn der Tool-Call den Blast Radius des Agenten verlässt (Produktivdeploys, kundenwirksame Veröffentlichungen) oder wenn Regulatorik Review verlangt. Sowohl LangGraphs interrupt() als auch die Approval-Middleware von Deep Agents unterstützen diese Gates nativ. Teil 4 erklärte, warum diese Gates ein Berechtigungsthema sind, kein Prompt-Thema.

Eine praktische Produktions-Checkliste

Bevor ein langlaufender Agent ausgeliefert wird, beantwortet diese Fragen in konkreten Infrastrukturbegriffen.

  1. Welcher Store hält Session-Events und Checkpoints?
  2. Was passiert, wenn der Worker mitten in einem Tool-Call stirbt?
  3. Kann ein Run den Workspace eines anderen beschädigen?
  4. Welche Aktionen brauchen Freigabe?
  5. Können Modell oder Sandbox rohe Credentials lesen?
  6. Welche Tool-Calls lassen sich sicher retrien?
  7. Wo wird das Kostenlimit pro Run erzwungen?
  8. Welcher Fresh-Context-Check entscheidet über „done“?
  9. Wo leben die finalen Outputs, nachdem die Sandbox weg ist?
  10. Können wir einen gescheiterten Run morgen erklären, ohne ihn neu auszuführen?

Wenn die Antwort auf eine dieser Fragen „der Prompt sagt dem Agenten, vorsichtig zu sein“ lautet, ist das System noch nicht deployed. Es ist noch eine Demo.

Wichtigste Erkenntnisse

  1. Langlaufende Agenten brauchen eine Runtime, nicht nur ein größeres HTTP-Timeout. Die Runtime hält Session, Workspace, Tool-Ergebnisse, Checkpoints, Traces, Budgets, Freigaben und Credentials außerhalb des Modellgedächtnisses.
  2. Die Kernkomponenten sind Session, Harness, Sandbox, Checkpoint und Trace. Policy-Checks und Secret Brokering schneiden quer über alle hinweg.
  3. Die erste Deployment-Frage ist die Run-Länge. Ein 20-Sekunden-Helfer kann in einem App-Server leben. Ein sechs Stunden laufender Coding- oder Research-Run braucht Queue, Worker, durable State und eine Sandbox-Strategie.
  4. Queue + Worker + Checkpoint-DB ist der praktische Default, wenn ihr die Runtime selbst betreiben wollt. Hosted Harnesses wie Anthropic Managed Agents oder Deep Agents Deploy sind besser, wenn deren Vendor-Constraints passen und ihr die Schleife nicht selbst betreiben wollt.
  5. Tools mit Side Effects brauchen Idempotency-Keys. In Queues und Workflow-Engines sind Retries normal. Ohne Deduplication kann ein Retry dieselbe E-Mail versenden, denselben PR anlegen oder denselben Kunden zweimal belasten.
  6. Observability muss den Worker überleben. Für einen fehlgeschlagenen sechs Stunden langen Run sind die nützlichen Artefakte Event-Log, letzter Checkpoint, Trace, Tool-Call-Timeline, Workspace-Diff, Screenshots und Environment-Metadaten.
  7. Runtime-Annahmen altern, wenn sich Modelle ändern. Testet Context-Resets, Evaluator-Muster, Tool-Oberflächen und Budget-Regeln neu, wenn ihr Modelle oder Harnesses wechselt.
  8. Secrets sollten außerhalb des Harnesses und außerhalb des Modellkontexts bleiben. Der Agent bekommt Tool-Fähigkeiten, nicht rohe Credentials.

Referenzen

Engineering-Write-ups

LangGraph und Deep Agents

OpenAI Agents SDK

Temporal

Anthropic-Plattform

Sandbox-Provider

Timeouts und Quotas von Cloud-Plattformen

Observability

Reihe

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