2026-05-26 · Aktualisiert 2026-07-22

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Langlaufende AI Agent Runtime im Jahr 2026: Sessions, Sandboxes, Checkpoints sowie Einsatzmöglichkeiten

Teil 5 der Serie „Engineering des Agentic-Stacks“

Die vorherigen vier Beiträge haben das interne Design des Agent behandelt: Reasoning Schleifen, Speicher, Tool Use, und Sicherheit. Dieser Artikel behandelt den Runtime, der dafür sorgt, dass diese Komponenten auch bei lang anhaltenden Sessions-Fehlern sowie Prozessausfällen weiterhin funktionieren.

Ein Lauf von Agent kann mehrere Stunden andauern, wobei der zugehörige Worker-Prozess zu jedem Zeitpunkt neu gestartet werden kann. Der Model wählt weiterhin die nächste Aktion aus, doch der Runtime muss den Zustand bewahren, die Ausführung steuern und nach einem Fehler mitten in einem Tool Call wiederherstellen. In diesem Artikel wird die Grenze des Runtime definiert. Teil 6 wird sich mit dem Harness innerhalb dieser Grenze beschäftigen: der Feedback-, Wiederholungs-, Übertragungs- sowie Akzeptanzlogik, die entscheidet, ob der Agent weiterhin funktioniert oder gestoppt wird.

Was ist ein AI Agent Runtime?

Ein AI Agent Runtime stellt die Infrastruktursschicht dar, die dafür sorgt, dass ein toolnutzender Agent nach Beendigung des Model-Aufrufs weiterhin aktiv bleibt, isoliert ist, überwachbar ist und wieder aufgenommen werden kann. Sie verwaltet den Session-Zustand, die Ausführung der Tools, Checkpoints, Richtlinienprüfungen, Geheimnisse, Traces, Kostenlimits sowie die Deployment-Struktur. Der Model wählt die nächste Aktion aus; der Runtime entscheidet darüber, wo diese Aktion ausgeführt wird, ob sie erlaubt ist, wie sie protokolliert wird und wie die Ausführung nach einem Fehler wieder aufgenommen wird.

Verwenden Sie den Runtime als Design-Einheit für langlaufende Agents-Systeme. Wenn es nicht möglich ist, genau zu beschreiben, wo sich jede primitive Komponente befindet, bleibt der Agent weiterhin ein Prototyp.

Lange Ausführungen untergraben die Annahmen bezüglich zustandsloser Prozesse

Ein stateless-Chat-Endpunkt kann den Zustand einer Anfrage innerhalb eines Prozesses speichern und diesen nach der Antwort löschen. Ein langer Laufzeitzyklus von Agent umfasst Neustarts von Worker-Prozessen, Bereitstellungen, Zurücksetzungen des Kontexts sowie Pausen aufgrund von Genehmigungsverfahren. In solchen Fällen kann der Worker-Prozess nicht länger als einzige Quelle der Wahrheit dienen.

Das Team von OpenAI Codex gibt die Lauflänge in seinem Die Dokumentation von Harness Engineering:

„Wir beobachten regelmäßig, dass einzelne Ausführungen von Codex für eine einzige Aufgabe länger als sechs Stunden andauern – meist während die Menschen schlafen.“

Das Engineering-Team von Anthropic beschreibt das entsprechende Zustandsproblem in Effektive Mechanismen zur Steuerung von langlaufenden Agents:

„Die zentrale Herausforderung bei langlaufenden Agents besteht darin, dass sie in diskreten Sessions arbeiten müssen, wobei jedes neue Session ohne jegliches Gedächtnis an das Vorherige startet.“

Beide Beobachtungen deuten auf dasselbe Runtime-Design hin: den Zustand außerhalb des Workers zu speichern und die Workers austauschbar zu gestalten.

Der Session muss außerhalb des Worker-Prozesses liegen. Ein dauerhafter Speicher protokolliert die Model-Aufrufe, Tool Results-Ereignisse sowie Genehmigungen, damit ein anderer Worker nach einem Absturz an dem letzten sicheren Punkt fortsetzen kann. Checkpoints ermöglicht es zudem dem Runtime, einen neuen Model Session zu starten, sobald der Context Window voll ist – ohne dass die gesamte Historie erneut abgespielt werden muss. In Anthropics Formulierungsstil, Harness Instanzen werden verbrauchbar und neu startbar – der dauerhafte Zustand wird an einem anderen Ort gespeichert.

Der Model bestimmt, welche Aktion als Nächstes ausgeführt werden soll. Der Runtime entscheidet darüber, ob eine Bewegung zulässig ist, wo sie ausgeführt wird, wie sie protokolliert wird sowie wie der Lauf nach einem Absturz wieder aufgenommen wird. Der Rest dieses Beitrags befasst sich mit diesem Runtime.

Die fünf Runtime-Primitiven, die jedes langlaufende AI Agent benötigt

Anthropics Skalierung von verwalteten Agents Der Dokumentationsteil liefert ein nützliches Vokabular für die fünf Runtime-Verantwortungsbereiche. Der Harness treibt den Agent voran, während der Session das Geschehene aufzeichnet und der Sandbox Befehle ausführt. Der Checkpoint übermittelt dem nächsten Prozess einen Fortschrittsstand; der Trace speichert Beweismittel zur späteren Fehlerbehebung. Eine Implementierung kann Komponenten zusammenführen, doch die Verantwortungsbereiche sowie die Grenzen bei Fehlern benötigen weiterhin klare Bezeichnungen.

Session. Ein schreibgeschütztes Protokoll über alles, was geschehen ist: Model-Aufrufe, Tool Calls, Ergebnisse, Fehler sowie Genehmigungen. Die Wiederherstellung erfolgt wake(sessionId) → getSession(id) → resume from last event. In LangGraph wird dies als ein thread_id plus ein Postgres Checkpointer (siehe Persistenz von LangGraph). Der OpenAI Agents SDK stellt zehn integrierte Session Backends zur Verfügung, darunter SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, und EncryptedSession (siehe den) Sessions Dokumentation).

Harness. Der Orchestration-Loop. Er ruft den Model auf, parset Tool Calls, führt diese aus, schreibt die Ergebnisse zurück in den Session und wendet Wiederholungsregeln an. Anthropic formuliert es unverblümt:

„Jedes Komponente in einem Harness kodiert eine Annahme darüber, was das Model nicht eigenständig bewältigen kann.“

Das Codex-Team von OpenAI bezeichnet diese Disziplin als Harness Engineering: Die Entwicklung von Software erfordert weiterhin Disziplin, doch heute fließt ein größerer Anteil dieser Anstrengungen in die Infrastruktur und Strukturen als in den Code selbst. LangGraphs CompiledStateGraph, Deep Agents’ create_deep_agent, Auch Claude Code selbst zählen in diesem Sinne zu den Frameworks.

Sandbox. Die isolierte Ausführungsumgebung, in der die Befehle tatsächlich ausgeführt werden. Der OpenAI Agents SDK Sandbox-Konzepte Die Seite zieht die Grenze sauber:

„Der äußere Runtime ist weiterhin für die Freigaben, Tracing, die Übertragungen sowie die Fortsetzung der Buchhaltung verantwortlich. Der Sandbox Session kümmert sich um Befehle, Dateiveränderungen und die Isolierung der Umgebung.“

Sandboxes unterscheiden sich dadurch, wie lange sie bestehen und was sie zwischen den Ausführungen behalten. Die einfachste Form ist die frische, vorübergehende Variante: Ein solcher Agent wird nur für eine einzige Aufgabe gestartet, nach Abschluss dieser Aufgabe wieder zerstört, wodurch bei jeder Ausführung die Kosten für einen Neustart anfallen.

Persistent paused Sandboxes sorgt dafür, dass das Dateisystem sowie ein Snapshot zwischen den Ausführungen erhalten bleiben. Dadurch kann beim nächsten Start ein vollständiger Neustart vermieden werden. Snapshot oder Fork erzeugen eine Kopie nach dem Schreiben-Prinzip aus einem vorbereiteten Elternbild, wodurch zahlreiche Aufgaben gemeinsam installierte Abhängigkeiten sowie vorgefertigte Caches nutzen können, ohne ihren schreibbaren Zustand teilen zu müssen.

Per-worktree Sandboxes stellt jedem Task einen eigenen Arbeitsraum sowie eine eigene Observability-Stack bereit. Getrennte Protokolle, Metriken und Traces ermöglichen es, einen Lauf zu debuggen, ohne dass der Zustand dieses Laufs auf andere Ausführungen übertragen wird. Die Tabelle mit Anbietern weiter im Artikel vergleicht das Verhalten bei erster Ausführung und bei Persistenz.

Checkpoint. Wiederaufnahmefähiger Zustand. Bei LangGraphs PostgresSaver schreibt einen StateSnapshot an jeder Grenze eines Super-Schritts, durch schrittbezogene Schreibvorgänge pro Aufgabe checkpoint_writes Daher werden erfolgreiche Node-Ausgaben nicht erneut berechnet, wenn ein Zwilling fehlschlägt. Der Snapshot ist ein JSON-serialisierbares Dictionary.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) dokumentiert in dem langgraph-checkpoint-postgres PyPI-Seite und der LangGraph Checkpoints-Referenz.

Trace. Die Wiedergabeschnittstelle sowie die Debugging-Oberfläche. Jeder Aufruf eines Model, Tool Call sowie jeder Unter-Schritt von Agent wird zu einem Span, der Zeitangaben, Eingaben, Ausgaben, Token-Zählwerte sowie Kosten enthält. Wenn eine sechsstündige Ausführung fehlschlägt, dient die Trace dazu, herauszufinden, woran es lag – schließlich sind die Terminalausgaben aus dieser Ausführung bereits längst verschwunden. Die von OpenTelemetry erzeugten semantische Konventionen von GenAI Standardisieren Sie die Namen der Attribute (welcher Model, welcher Anbieter, wie viele Tokens, welche Konversation, welcher Workflow), damit derselbe Trace einheitlich dargestellt werden kann. Geschwindigkeit, Jaeger, Honigwabenstruktur, oder LangSmith ohne erneute Instrumentierung.

Richtlinien und Geheimnisse bilden getrennte Runtime Grenzen

Zwei Grenzen durchqueren alle fünf Primitiven und lassen sich besser als getrennte Aufgaben betrachten. Es handelt sich dabei um die Runtime-Version des Sicherheitsarguments aus Teil 4.

Richtlinienmotor

Eine Berechtigungsprüfung wird vor jedem Tool Call durchgeführt, um zu entscheiden, ob der Aufruf weitergeleitet werden darf. In der Produktion kommen zwei gängige Ansätze zum Einsatz. Bei Deep Agents kann jeder Unteragent angeben, welche Dateipfade er lesen oder schreiben darf, wobei das Middleware-System alles außerhalb dieser Angaben blockiert. Anthropic Managed Agents leitet jeden Tool Call über einen MCP-Proxy weiter, sodass der Proxy statt des Agent-Codes die Berechtigungen durchsetzt. Wenn ein sensibler Aufruf eine menschliche Freigabe benötigt, übernimmt dies bei LangGraphs interrupt() und die Deep Agents-Genehmigungs-Hook-Funktion stoppt den Graphen, bis eine Person „Ja“ sagt.

Geheimer Broker

Der Model darf keine langfristig gültigen Geheimnisse erhalten, und der Sandbox sollte in der Regel ebenfalls keine solchen nutzen. Das Muster des verwalteten Agents ist das, das kopiert werden sollte:

„Für Git nutzen wir den Zugriff Token jedes Repositoriums, um es während der Sandbox-Initialisierung zu klonen und es mit dem lokalen git Remote zu verbinden. Git“ push und pull Es wird direkt innerhalb des Sandbox gearbeitet, wobei der Agent niemals direkt mit dem Token selbst in Berührung kommt. Für benutzerdefinierte Tools unterstützen wir MCP und speichern die OAuth Tokens-Daten in einem sicheren Tresor. Claude ruft die MCP-Tools über einen dedizierten Proxy auf; dieser Proxy erhält dabei eine Token, die mit dem Session verknüpft ist. … Der Harness erhält keinerlei Kenntnis von irgendwelchen Zugangsdaten.

In dem market-analyst-agent Der Referenz-Stack – der MCP Sidecar liest die OAuth-Informationen Tokens aus einem Docker Secret ab (in der Produktion). HashiCorp Vault) und stellt dem LangGraph-Arbeitsspeicher lediglich die Schnittstelle des Tools zur Verfügung. Der Arbeitsspeicher erhält niemals Zugriff auf den Token. git push Funktioniert. cat ~/.ssh/id_rsa nicht.

Eine praktische Überprüfung besteht darin, jedes Komponente aufzulisten sowie festzuhalten, welche der fünf Primitiven es implementiert. PostgreSQL könnte Session und Checkpoint umfassen. Der Worker-Container ist der Harness. Ein Dienst wie Daytona, Modaler Agent, oder E2B bietet den Sandbox an, während Geschwindigkeit oder LangSmith speichert den Trace.

Prüfen Sie nun die gekoppelten Ausfälle. Wenn zwei Primitive im selben Prozess vorhanden sind, führt ein Absturz eines davon dazu, dass beide ausfallen. Teilen sie sich außerdem Zugangsdaten, kann ein Datenleck beide Schutzgrenzen überschreiten. Häufige Beispiele hierfür sind ein Worker, der ebenfalls über die Persistenzfunktion von Trace verfügt, oder ein Sidecar-Modul Token, das gleichzeitig auf die Checkpoint-Datenbank zugreifen kann.

Fehlermodi bei Produktivumgebungen AI Agent Runtime

Der Runtime steuert Wiederholungsversuche, stellt vorherige Arbeit wieder her, isoliert Arbeitsräume und sorgt für die Einhaltung von Budgets. Die fünf oben genannten Primitiven verwalten den gesamten Laufzyklus, während Richtlinien sowie Mechanismen zur Verwaltung sensibler Daten auf diese Primitiven einwirken. Da die Ausführungen über mehrere Worker sowie Context Windows verteilt sind, treten Fehler häufig im Zusammenhang mit Zustandsveränderungen, doppelten Nebeneffekten, Sandbox-Abweichungen sowie der Budgetkontrolle auf.

Die Ausfälle lassen sich in vier Gruppen einteilen:

• Fehler bei der Qualität der Ausgabe: Der Agent erklärt bereits vor Abschluss der Arbeit einen Erfolg, vergisst, was er in einem Kontextfenster-Reset getan hat, oder verlässt sich auf seine eigene Selbstbewertung und liefert eine fehlerhafte Ausgabe aus.
• Fehler bei der Kostenkontrolle: Der Agent gerät in eine Wiederholungsloop, verbraucht ein Token oder das Budget für Toolaufrufe, ohne etwas Nützliches zu erzeugen.
• Fehler bezüglich Zustand und Absturz: Die Arbeitsräume verändern sich, weil eine Ausführung Dateien berührt, die einer anderen Ausführung gehören, Tool Calls wird mehrfach ausgelöst, da Wiederholungen diese Vorgänge erneut ausführen, oder die Arbeit geht verloren, wenn ein Worker zwischen den Ereignissen abstürzt.
• Fehler im Kontextfenster: Der Model fasst zusammen und beendet die Arbeit frühzeitig, weil er annimmt, dass der Speicherplatz erschöpft ist – obwohl im Fenster noch Platz vorhanden ist.

Die Tabelle ordnet jedem Fehler einer Abhilfemethode zu, dem dazu verwendeten Runtime-Hook sowie der Grundlage für die Empfehlung. Da das spezifische Verhalten im Zusammenhang mit Model variieren kann, sollten Herstellerbeobachtungen als Prompts betrachtet werden, um die Annahmen erneut zu überprüfen und nicht als dauerhafte Regeln anzusehen.

In jeder Zeile treten zwei Konzepte auf. Anthropic befasst sich dabei mit der Harness-Alterung. Harness Entwurf für die Entwicklung langlaufender Anwendungen:

„Jeder Komponente in einem Harness kodiert eine Annahme darüber, was der Model nicht allein bewältigen kann, und diese Annahmen sollten gründlich getestet werden – sowohl weil sie falsch sein könnten, als auch weil sie mit der Verbesserung von Models schnell veraltet werden können.“

Vercel befasst sich mit dem damit verbundenen Problem, dass zu viele Tools zu viele Annahmen vornehmen. Wir haben 80 Prozent der Tools unserer Agent entfernt.:

„Wir haben den größten Teil davon entfernt und Agent auf ein einziges Werkzeug reduziert – nämlich die Ausführung beliebiger Bash-Befehle. Wir bezeichnen dies als einen Dateisystem-Agent.“

Vercels gemeldetes Ergebnis für eine repräsentative Abfrage: Die Erfolgsrate stieg von 80 % auf 100 %, und der schlimmste Fall verbesserte sich von 724 s pro 100 Schritten bei 145.463 Tokens (fehlgeschlagen) auf 141 s pro 19 Schritten bei 67.483 Tokens (erfolgreich). Die Lektion lautet nicht „löschen Sie Ihre Tools“, sondern dass jede Primitivfunktion in Ihrem Runtime – einschließlich der Tool-Oberfläche – eine Halbwertszeit hat. Überprüfen Sie die Annahmen erneut, wenn sich die Model ändern.

Cognition erkannte beim gleichen beweglichen Ziel über eine Länge von Session mithilfe von Sonnet 4.5 dasselbe Verhalten. Die Neuimplementierung von Devin für Claude Sonnet 4.5 sie beschreiben einen Model, der proaktiv schreibt SUMMARY.md / CHANGELOG.md Da der Agent eine Erschöpfung des Kontexts wahrnimmt, diese jedoch unterschätzt, indem er nicht erkennt, wie viele Tokens noch verfügbar sind. Ihre Lösung besteht darin, die Beta-Version mit 1 Mio. Token zu aktivieren und die Nutzung auf 200k zu begrenzen, sodass der Model weiterhin glaubt, genügend Kapazität zu haben. Auch diese Abhilfemaßnahme wird letztendlich zu einer nutzlosen Weight werden.

Das Team von OpenAI mit dem Harness vertritt in einer prägnanten Formulierung folgende Devise: „Menschen steuern. Agents führen aus.“ Wenn etwas fehlschlägt, lautet die Frage nicht „mehr Anstrengung“, sondern „welche Fähigkeit fehlt und wie können wir diese sowohl für die Agent verständlich als auch durchsetzbar machen?“

Der gesunde Lebenszyklus einer Ausführung

Ein ordnungsgemäß ablaufender Ausführungsprozess ist langweilig – es handelt sich dabei um eine Abfolge kleiner, wiederherstellbarer Schritte, wobei jeder Schritt sein Ergebnis vor dem Start des nächsten in einer dauerhaften Speicherung festhält.

Diese Grenze weist Schäden durch einen Absturz auf. Ein Fehler führt lediglich dazu, dass der aktuelle Schritt im Fluss der Ausführung verloren geht; der nächste Worker setzt die Verarbeitung an dem letzten abgeschlossenen Schritt fort, anstatt den gesamten Vorgang erneut zu starten.

1. Starten Sie entweder von einem neuen Session oder von einem wiederbelebten System aus. Beim Wiederaufnehmen wird der Arbeitsbereich aus seinem letzten bekannten Zustand montiert und alle Fortschrittsdateien, die vom vorherigen Versuch übrig geblieben sind, ausgelesen.PROGRESS.md, feature-list.json), und lädt den letzten Checkpoint aus der Datenbank. An dieser Stelle übergeben die Harness dem Agent alles, was der vorherige Worker im Speicher hatte, bevor er abstürzte.
2. Planen Sie vor jedem Ausführungsvorgang eines Tool Calls sorgfältig. Legen Sie fest, wie ein „abgeschlossenes“ Ergebnis aussieht, wie viel Zeit für die Ausführung zur Verfügung steht, welche Tools die Agent aufrufen dürfen, sowie welche Faktoren eine vorzeitige Beendigung der Ausführung auslösen sollen. Diese Planungswerte werden zu Runtime-Prüfungen; ohne sie hat die Ausführung keinen Anhaltspunkt für Korrekturen.
3. Führen Sie jeweils nur einen Tool Call aus. Die Policy-Schicht entscheidet dabei, ob der Aufruf gestattet wird. Die Harness führt ihn aus, speichert das Ergebnis und schreibt ein Ereignis in das Session-Log. Ein Schritt – ein Ereignis. Ein Absturz zwischen den Ereignissen ist behobar, da das Log und nicht der Speicher des Workers als einzige Quelle der Wahrheit dient.
4. Checkpoint an den Grenzen der Über-Schritte oder nach jedem Ereignis in einem einfacheren Harness. Speichern Sie den Zustand des Graphen, die Unterschiede im Arbeitsbereich sowie Verweise auf alle erzeugten Artefakte. Dieser Checkpoint wird im nächsten Startvorgang vom Schritt 1 gelesen. Falls der Checkpoint fehlt oder veraltet ist, reduziert sich die Wiederherstellung auf das Erneuten Durchlaufen des gesamten Session-Logs von vorn – was deutlich langsamer ist.
5. Es wird eine Bewertung anhand der Artefakte durchgeführt, sobald der Agent der Meinung ist, die Arbeit sei abgeschlossen: Tests, Überprüfung durch einen Prüfer im sauberen Kontext, Validierung des Schemas sowie Browser-Prüfungen. Wenn alle Prüfungen bestehen, endet der Lauf erfolgreich. Sollten sie fehlschlagen, setzt der Lauf von dem letzten korrekten Checkpoint aus und fährt mit der Fehlermeldung im Kontext erneut fort.

In dieser Liste gibt es keinen Schritt, der vom Agent verlangt, zwischen den Ausführungen etwas zu speichern. Der Zustand wird im Session sowie im Checkpoint gespeichert, und der Agent lädt ihn bei jedem Neustart wieder ab.

Tools mit Nebeneffekten benötigen Idempotenz. Jeder Tool, das Nebeneffekte verursacht, muss einen Idempotenz-Schlüssel besitzen, der aus dem Session-ID sowie dem Tool-Aufruf-ID abgeleitet wird und vor Auslösung des Nebeneffekts gespeichert 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). Die mindestens-einmalige Ausführung ist Standard in Warteschlangen sowie Workflow-Engines. Wenn die Wiederholung eines Tool Call tatsächlichen Schaden verursachen kann, ist das Tool noch nicht für Agents bereit.

Die Bewertung muss Belege aus Kontexten enthalten, die nicht zur Erstellung verwendet wurden. Ein frischer Evaluator verringert den Bias durch gemeinsame Kontexte, während Tests, Linter, Browserprüfungen sowie Schema-Validierungen deterministische Belege liefern. Die Prüfung kann einen Rückgabewert liefern. pass, failoder needs_human. Für den Code Agents kann der Prüfer ein weiterer Model Session mit nur lesbaren Berechtigungen sein. Bei Daten und Berichten Agents sollte man deterministische Validierungsverfahren mit einem Prüfer Model kombinieren, bei dem weiterhin eine menschliche Beurteilung erforderlich ist.

Elf AI Agent Deployment Muster und was darüber entscheidet

Sobald die fünf Primitiven benannt sind, stellt sich die Frage, welche Deployment-Struktur sie ausführt. Unter „Struktur“ verstehe ich eine Anordnung dieser Primitiven: Wo sich der Harness befindet, wo der Zustand persistiert und welche Art von Sandbox die Ausführung übernimmt. Es handelt sich dabei nicht einfach um eine Entscheidung eines einzelnen Anbieters. Die folgende Grafik zeigt, in welchem Bereich der Lauflängen-Achse jede Struktur am besten geeignet ist. Der Text dahinter erläutert, was letztendlich zwischen den verschiedenen Strukturen entscheidet.

Falls Sie nur eines der elf Konzepte lesen, sollten Sie sich zunächst mit dem Muster 2 beschäftigen: Warteschlange + Worker + Checkpoint-Datenbank. Dies ist die Standardlösung, die ich für die meisten Teams empfehle, das von dem Referenz-Repo verwendete Muster sowie die Grundstruktur, von der sich die meisten anderen Varianten ableiten – nämlich Warteschlange → Worker → dauerhafter Zustand – wobei dabei die Sandbox-Quelle, der Harness-Eigentümer oder der Zustandsmotor ausgetauscht wird. Wenn Sie zuerst Muster 2 durchlesen, fällt das Durchgehen der übrigen Muster deutlich schneller.

Der Diagramm vergleicht die Formen nach ihrer Lauflänge. Die darunterstehende Matrix vergleicht sie hingegen nach ihrem Eigentumsverhältnis – also dort, wo jede der fünf Primitiven physisch lokalisiert ist. Grüne Zellen deuten darauf hin, dass die jeweilige Form die Primitive selbst bereitstellt; graue Zellen zeigen an, dass diese von außen angebunden werden müssen.

1. SDK innerhalb eines App-Servers (synchron, anfragespezifisch)

Die ursprüngliche Form. Der Agent SDK wird innerhalb eines Request-Handlers ausgeführt. Er eignet sich gut für Aufgaben, die schneller als 30 Sekunden abgeschlossen werden, für Demonstrationen sowie für interne Tools. Für Anwendungen, bei denen ein HTTP-Client möglicherweise die Verbindung trennt, ist er hingegen ungeeignet. Der HTTP-Timer auslaufend in Cloud Run Die Laufzeit ist auf maximal 60 Minuten begrenzt, und ein Absturz im Web-Tier beendet den Lauf sofort. Der SDK stellt dabei den Harness dar; der Web-Prozess fungiert zudem als Sandbox. Der Zustand befindet sich in der Regel im Prozessspeicher, es sei denn, man speichert ihn ausdrücklich an einem anderen Ort ab. Für arbeitsintensive Aufgaben, die mehrere Stunden dauern, sollte dieses Konzept nicht verwendet werden.

2. Warteschlange + Worker + Checkpoint-Datenbank

Der Standardwert, den ich für die meisten Teams empfehle, sowie die in der Produktion verwendete Form. market-analyst-agent: ein Python-Worker mit einem PostgreSQL-Checkpointer. Redis Streams (oder) RabbitMQ) Für die Eingangs-Warteschlange sowie einen MCP Sidecar für Tools. Geeignet für Laufzeiten von 10 Minuten bis mehreren Stunden mit idempotenten Schritten. Der lokale Runner kann bei synchroner Entwicklung die Warteschlange umgehen, doch sobald asynchrone Einreichung und Backpressure erforderlich sind, gehört die Warteschlange zum Produktionsdesign.

Die Anwendung nimmt eine Anfrage entgegen, erstellt eine Zeile für Session, schickt einen Job los und gibt eine Lauf-ID zurück. Der Worker holt sich den Job, führt den Harness aus, schreibt die Ergebnisse in Checkpoints auf, streamt den Status und speichert dabei die Erzeugnisse. Postgres bleibt weiterhin funktionsfähig, die Worker fungieren dabei wie einfache Ressourcen, und die Warteschlangentiefe sorgt für Rückdruck. Spot-/Preemptible-Rechenressourcen funktionieren solange, wie der Checkpointer das Schreiben auf die Festplatte vor dem Berichten eines Erfolgs abschließen kann.

In dieser Struktur ist der Worker das Harness. Sein Container sowie der Arbeitsraum pro Thread bilden eine Ausführungsgrenze, doch unzuverlässiger Code benötigt weiterhin einen gesicherten Sandbox oder eine virtuelle Maschine. Postgres verwaltet den Zustand von Session und Checkpoint. Traces werden über OpenTelemetry an den jeweiligen Observability-Stack weitergeleitet, der bei der Ausführung genutzt wird.

3. Langlebiger Workflow-Motor (Temporal-Stil)

Agent Orchestration Der Code wird innerhalb eines Temporal Workflow ausgeführt; Model Aufrufe sowie Tool Calls werden als Aktivitäten abgewickelt. Der Workflow Zustand wird in einem Ereignisprotokoll gespeichert, das von Cassandra, MySQL oder Postgres unterstützt wird, wodurch ein reibungsloser Zustandswiederherstellungsprozess bei Neuverteilungen gewährleistet ist. Die öffentliche Vorabversion Integration vonTemporal × OpenAI Agents SDK versendet einen OpenAIAgentsPlugin und ein activity_as_tool Hilfsmodul sowie der Erklärung zu agentic und Sandboxes erläutert das Forken eines laufenden Agent auf einen anderen Sandbox-Anbieter mitten im Gespräch. Inaktive Workflows verbrauchen keinen Rechenaufwand. Die Einschränkungen sind jedoch real: Streamen sowie SprachAgents werden in der aktuellen Integration nicht unterstützt. LocalShellTool und ComputerTool Sie sind deaktiviert, da sie nicht in ein verteiltes Model passen.

Verwenden Sie diese Form, wenn der Ausführungsablauf tatsächliche Wartezeiten aufweist: menschliche Freigaben, externe Aufrufe, lange Wartezeiten, Wiederholungen unter Berücksichtigung von Geschäftsregeln sowie Deployment-Fenster. Eine menschliche Freigabe führt zu einem dauerhaften Wartezustand, der keine Rechenleistung verbraucht – im Gegensatz zu einem Polling-Zyklus, der dies tut.

Der Workflow-Code ist der Harness. Der Sandbox befindet sich in der Regel außerhalb von Temporal und wird von Aktivitäten aufgerufen. Session sowie Checkpoint werden im Ereignisprotokoll von Temporal abgelegt, während die Sichtbarkeit von Trace durch die Temporal-Oberfläche sowie durch OpenTelemetry Spans in jeder Aktivität gewährleistet wird.

4. Sandbox-Anbieter pro Session

Eine neuere Architektur. Jeder Ausführungsvorgang von Agent erhält eine eigene MicroVM oder Container von einem Anbieter von Sandbox als Service. Der Harness wird an einem persistierenden Speicherort gespeichert; der Sandbox stellt hingegen die einmalig verwendbare Ausführungsumgebung dar.

Die Tabelle kombiniert die Vergleich zwischen E2B und Daytona, Daytonas Sandboxes-Dokumentation und Fork/Snapshot Changelog, Modals von Modal Sandboxes und cold Start Leitfäden, die Runloop – Produktseite im AWS Marketplace, und Vercel Sandbox-Preise.

Daytona erfasst für jeden unabhängigen Fork eine Eltern-Kind-Verbindung, wodurch die Abstammungslinie der abgeleiteten Sandboxes erhalten bleibt. OpenAI’s Codex Harness verwendet hingegen die pro-Worktree spezifische Variante: „Codex arbeitet mit einer vollständig isolierten Version dieser Anwendung – einschließlich deren Protokolle und Metriken –, die nach Abschluss der Aufgabe wieder gelöscht wird.“

Wählen Sie diese Konfiguration, wenn der Agent unzuverlässigen Code ausführt, Browserautomatisierung betreibt, Tests durchführt oder Pakete installiert. Der Nachteil besteht in den höheren Kosten sowie einer stärkeren Kopplung an den Anbieter im Vergleich zum Einsatz von Shared Workers.

Der Anbieter besitzt ausschließlich den Sandbox und nichts weiter. Harness, Session, Checkpoint sowie Trace verbleiben auf Ihrer Seite und sind in der Regel im Format von Queue plus Worker gemäß Punkt #2 konfiguriert.

5. Anthropic Managed Agents (hosted Harness)

Anthropic hat Managed Agents am 8. April 2026 in einer öffentlichen Beta-Version veröffentlicht, wobei der Zugang zunächst eingeschränkt war. managed-agents-2026-04-01 Beta-Header. Der Service stellt einen gehosteten Session-, Harness- und Sandbox-Proxy sowie einen durch ein Vault gesicherten MCP-Proxy bereit. wake(sessionId) Es ist möglich, den Harness auf einem neuen Worker zu initialisieren, ohne den dauerhaften Session-Zustand zu verlieren.

Claude berechnet für Managed Agents die üblichen Token Tarife zuzüglich 0,08 US-Dollar pro Session-Stunde. Die Abrechnung erfolgt in Millisekundenauflösung und gilt ausschließlich solange der Session-Status „laufend“ ist; inaktive Zeiten sind kostenlos. Ein unkontrolliertes Wiederholungsloop fügt daher neben den Kosten für Token noch zusätzliche Kosten pro Session-Stunde hinzu.

Lesen Sie die Einschränkungen. Der Rabatt für den Batch-Modus API gilt nicht, da „Sessions“ zustandsbehaftet und interaktiv sind – es existiert somit kein Batch-Modus. Ein gesteuertes Agents ist über diesen Weg nicht verfügbar. AWS Bedrock oder Google Vertex AI. Multi-agent Koordination und Selbstbewertung befinden sich noch in der Forschungsphase. Das Lock-in-Effekt ist stark ausgeprägt: Man gibt die Harness Freiheit auf, um nicht selbst den gesamten Prozess ablaufen zu müssen.

Anthropic stellt alle fünf Primitiven bereit: Session, Harness, Sandbox, Checkpoint sowie Trace. Sie übergeben die Runtime und erhalten anschließend die Ausgaben.

6. LangChain Deep Agents Deployment (verwaltete offene Harness)

deepagents deploy Pakete deepagents.toml in einen LangSmith Deployment mit zuverlässiger Ausführung, Speichermanagement, Multi-Tenancy-Funktionalität, Human-in-the-Loop, Observability, abgeschirmter Codeausführung sowie geplanten Ausführungen. Es werden Cloud-, Hybrid- und selbsthostete Deployment-Modi unterstützt. Sandbox-Anbieter (LangSmith Sandboxes, Daytona, Modal, Runloop oder eigene Lösungen) können über einen einzigen Konfigurationswert ausgetauscht werden. Der Zustand wird in einem virtuellen Dateisystem mit platzierbaren Backends gespeichert; der Speicher ist auf Benutzer, Assistent oder beide Ebenen begrenzt. Die Bindung an einen bestimmten Anbieter ist geringer als bei Managed Agents: die Harness ist unter der MIT-Lizenz verfügbar und die Anleitungen nutzen offene Standards. AGENTS.md Standard sowie Agents werden über das MCP-, A2A- und Agent-Protokoll bereitgestellt. Siehe dazu LangChain. Runtime – hinter der Produktionsumgebung liegende Agents Bericht.

Alle fünf Primitiven werden standardmäßig bereitgestellt, können jedoch jeweils durch Konfiguration ersetzt werden. Der Sandbox ist hinter einem Konfigurationswert verborgen. Session und Checkpoint befinden sich auf einem virtuellen Dateisystem mit austauschbaren Backends. Trace wird an LangSmith übergeben.

7. Google Cloud Run-Dienst oder -Job

Cloud Run verfügt über zwei unterschiedliche Runtime-Modi, wobei die Wahl des geeigneten Modus davon abhängt, wie der Agent aufgerufen wird. Services sind an HTTP gebunden und skalieren zwischen den Anfragen auf Null; der Harness fungiert als Anfragenverarbeiter, der nach Abschluss der Ausführung beendet wird. Jobs laufen bis zur vollständigen Fertigstellung ohne HTTP-Eingangspunkt; der Harness agiert als einmaliger Worker, der nach Abschluss der Aufgabe beendet wird. Beide können den Harness beherbergen, speichern jedoch keinen Zustand über mehrere Ausführungen hinweg. Sessions sowie Checkpoints müssen in Postgres, Spanner oder einem ähnlichen externen Speicher gespeichert werden.

Die harten Grenzen unterscheiden sich bei den beiden erheblich voneinander. Zeitüberschreitung bei der Anfrage an den Cloud Run-Dienst: Standardwert: 300 Sekunden, maximale Dauer: 3.600 Sekunden (60 Minuten). WebSockets der gleiche Zeitlimit-Wert wird verwendet. Cloud Run-Jobs: Standardmäßig gelten 10 Minuten pro Aufgabe, maximal 168 Stunden (7 Tage); für Aufgaben, die GPUs verwenden, beträgt die maximale Dauer 1 Stunde. Die Dienste werden auf Null skaliert, es sei denn, Sie aktivieren eine ständige Verfügbarkeit von CPU; Jobs verfügen weder über HTTP-Verbindungen noch über eine automatische Skalierung.

Verwenden Sie einen Service für synchrone Ausführungen mit einer Dauer von bis zu 60 Minuten. Für längere, einmalige oder asynchrone Aufgaben eignen sich Jobs. Cloud Run Jobs können eine Aufgabe mehrere Tage lang am Laufen halten, bieten jedoch keine zuverlässige Wiederausführungsmöglichkeit bei Neuimplementierungen, Versionserweiterungen oder dem Austausch der Worker. Bei einer Laufzeit von mehr als 7 Tagen sollte Cloud Run nicht verwendet werden.

Cloud Run hostet den Harness. Der Zustand von Session und Checkpoint wird in Postgres, Spanner oder einem anderen externen Speicher gespeichert, während Traces über Cloud Logging sowie OpenTelemetry weitergeleitet werden kann. Der Service-Container stellt ein Ausführungsumfeld dar; es sollte ein separater Sandbox hinzugefügt werden, wenn der Agent unsicheren Code ausführt.

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

Die maximale Ausführungszeit einer Lambda-Funktion Es beträgt 900 Sekunden (15 Minuten) – das ist sehr knapp. Wenn das API Gateway die Funktion voranstellt, hängt die Integrationsschwellenwert vom Typ von API ab. HTTP APIs erlaubt eine Verzögerung von 30 Sekunden.; REST-Integrationen verwenden standardmäßig eine Wartezeit von 29 Sekunden, während Regionale und private REST APIs-Instanzen können eine längere Timeout-Dauer konfigurieren.. Keiner dieser Ansätze verwandelt Lambda in einen stundenlang laufenden Worker. Ein langlaufender Harness benötigt weiterhin externe Zustände sowie eine erneute Aufrufung, wodurch wiederum die Struktur aus Queue und Worker entsteht. Nutzen Sie Lambda für begrenzte Tool Calls-Aufgaben wie das Herunterladen von Dateien oder das Hochladen in S3, wobei diese von einem länger laufenden Orchestrierungsprozess aufgerufen werden. Platzieren Sie den Orchestrierungsprozess nicht dort.

Im Höchstfall kann Lambda einen einzigen Tool Call innerhalb seiner 15-minütigen Zeitbeschränkung speichern. Die Harness, Session, Checkpoint, Sandbox sowie Trace müssen daher an einem anderen Ort untergebracht werden.

9. AWS ECS / Fargate-Aufgabe pro Ausführung

In den Fargate-Dokumentationen wird im Gegensatz zu Lambda kein festes Obergrenzen für Tasks festgelegt Runtime. Throttling-Quoten für Fargate Es wird eine Startrate von 100 Einheiten ermöglicht, wobei die Reserven alle 20 Sekunden wieder aufgefüllt werden; dabei gelten getrennte Budgets für On-Demand-Ausführungen und Spot-Preis-Angebote. ECS-Dienstquoten Die Dienste werden mithilfe der AWS Cloud Map-Entdeckungsfunktion auf 1.000 Aufgaben pro Service sowie auf Clustern, die auf EC2 basieren, auf 5.000 Containerinstanzen begrenzt.

Fargate erfordert awsvpc In diesem Modus erhält jede Aufgabe eine eigene Netzwerkschnittstelle sowie eine private IP-Adresse. Diese Struktur eignet sich hervorragend für den Datenzugriff innerhalb einer VPC. Fargate Spot birgt außerdem das Risiko von Unterbrechungen, wobei die Zuverlässigkeit weiterhin in Ihrer Verantwortung liegt, da die Plattform kein Replay-Verfahren im Stil von Temporal bietet.

Fargate hostet den Harness und weist jedem Ausführungsvorgang eine eigene Aufgabe zu. Dadurch werden Arbeitsumgebungen von den Zugriffsdaten der Aufgaben getrennt, doch allein stellt dies keine vollständige Sandbox gegen feindlichen Code dar. Session, Checkpoint und Trace wenden sich an externe Dienste wie RDS oder DynamoDB sowie CloudWatch/X-Ray.

10. Kubernetes Job oder Namespace pro Session

Gut, wenn man bereits damit arbeitet. Kubernetes und man wünscht Sandbox-pro-Session zusammen mit zentralen Steuerungsmöglichkeiten für den gesamten Cluster. Das ist problematisch, wenn eine Startzeit von unter einer Sekunde erforderlich ist, da das Herunterladen der Container-Image und die Initialisierung des Pods auf einem Cold Start zu lange dauern. Das Muster besteht darin, für jeden Agent-Aufruf einen eigenen Job zu verwenden, wobei activeDeadlineSecondseinen PersistentVolumeClaim für den Arbeitsbereich sowie einen Sidecar für den MCP-Server. Die Wiederherstellung nach einem Absturz müssen Sie selbst implementieren. Kubernetes zu nutzen nur zum Hosten von Agents ist aufgrund der hohen Konfigurationsaufwände und des operativen Aufwands kostspielig. Es lohnt sich nur, wenn Sie bereits aus anderen Gründen K8s betreiben.

Kubernetes stellt den Harness sowie die Ausführungsumgebung pro Laufzeit bereit, in der Regel als ein Job und manchmal innerhalb eines dedizierten Namespaces. Eine starke Isolation hängt weiterhin von der Klasse der Runtime, den Netzwerkrichtlinien, der Sicherheit der Pods sowie den Grenzen des zugrunde liegenden Containers oder der VM ab. Der Zustand von Session und Checkpoint wird in einer externen Datenbank oder über einen PersistentVolumeClaim gespeichert.

11. Lokaler Docker Compose (nur für Entwicklung)

Der Referenztext für den nächsten Abschnitt. Der Zweck dieser Struktur besteht darin, die Produktionstopologie eins zu eins abzubilden – mit denselben Primitiven und derselben Netzwerkkonfiguration – und zwar auf einem einzigen Rechner. Lesen Sie vor dem Versand jeglicher solcher Konstruktion unbedingt die am Ende des nächsten Abschnitts aufgeführte Liste mit den „nicht produktionsreifen“ Elementen.

In einem einzigen Host werden mehrere Instanzen von Shape #2 erstellt. Postgres speichert den Zustand von Session und Checkpoint, während der Worker-Container als Harness fungiert. Das Mounten eines gemeinsamen Arbeitsbereichs ist zwar für die Entwicklung praktisch, bietet jedoch keine Isolierung für unzuverlässige Ausführungen. Der optionale OpenTelemetry-Stack protokolliert dabei die Traces-Daten.

Referenz-Stack: Docker Compose

Die Referenztopologie, die in slavadubrov/market-analyst-agent, ist ein LangGraph-Arbeitssprozess sowie ein Postgres-Checkpointer. Qdrant für Retrieval, einen MCP Sidecar, eine Redis-Warteschlange für asynchrone, produktionstypische Ausführungen sowie eine optionale Prometheus / Grafana / Loki / Tempo / OTel Der Stack von Observability. In Local Compose ist Redis lediglich optional, da der synchrone Ausführungsknoten den Worker direkt aufrufen kann. docker compose up führt die gesamte Topologie lokal hoch.

Der einzige Teil, der direkt im Text dargestellt werden sollte, ist die kanonische Verkabelung von LangGraph. Es handelt sich dabei um das kleinste konkrete Beispiel für die Checkpoint-Primitivfunktion:

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"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observability, das den Lauf überlebt

Kurze Anfragen-Handler sind leicht zu debuggen: Wenn etwas fehlschlägt, kann man die Antwort sowie das Echtzeit-Logfile einsehen. Langlaufende Agents verfügen nicht über diesen Vorteil. Wenn eine sechsstündige Ausführung schließlich fehlschlägt, hat das relevante Ereignis bereits vor fünf Stunden stattgefunden, die Echtzeit-Ausgabe im Terminal ist verschwunden und der Prozess, der sie erzeugt hat, wurde bereits ersetzt. Niemand wird versuchen, den Ablauf aus dem Gedächtnis wiederherzustellen. Deshalb erfolgt die Fehlersuche anhand dauerhafter Artefakte, die während der noch laufenden Ausführung erstellt wurden.

Produktionsumgebungen umfassen in der Regel vier Arten von Artefakten, die in zwei Gruppen eingeteilt sind. Zwei davon werden nach Abschluss des Laufs zur Durchführung von Postmortems und Wiedergabe analysiert: ein abfragbarer Ereignisprotokoll aller Schritte sowie OpenTelemetry Traces, die Aufschluss darüber geben, wohin Zeit und Tokens verbraucht wurden. Zwei weitere werden während des Laufs betrachtet, um den Ablauf in Echtzeit zu verfolgen: ein Live-Überblick darüber, was die Agent im Arbeitsbereich erzeugt, sowie eine pro-Worktree Observability gestrukte Struktur, die von der Agent selbst noch während des Laufs abgefragt werden kann.

Strukturiertes Ereignisprotokoll (zur Auswertung nach dem Ausführungsvorgang)

Jeder Aufruf von Model, Tool Call, das Ergebnis, Fehlermeldungen sowie Genehmigungen werden in einer dauerhaften Speicherung gespeichert und über einen Schlüssel aus der Session-ID sowie dem Zeitstempel identifiziert. Sobald die Ausführung abgeschlossen ist, kann man darauf wie auf eine normale Datenbanktabelle zugreifen. Addy Osmani legt hier dabei klare Standards fest. langlaufende Agents: „Falls es nicht möglich ist, aus dauerhaften Speichern wiederherzustellen, was der Agent in den letzten 24 Stunden getan hat, handelt es sich dabei um ein langlaufendes Shell-Skript, das zufällig einen LLM aufruft – und nicht um einen langlaufenden Agent.“

OpenTelemetry GenAI Traces (zur Lektüre nach dem Ausführen)

Derselbe Art von schrittweisen Daten, allerdings als Spans unter Verwendung der Standardattribute aus dem gen_ai.* semantische Konventionen: Model Name, Anbieter, Eingabe- und Ausgabedaten Token Zählwerte, Konversations-ID, Workflow Name (Entwicklungsstatus ab Version 1.36.0). Anbieterbezogene Felder befinden sich in Unter-Namenräumen.anthropic.*, openai.*) abgeschaltet gen_ai.provider.name. Der Grund für die Verwendung des Standards liegt in der Portabilität: Derselbe Trace wird in Tempo, Jaeger, Honeycomb oder LangSmith einwandfrei dargestellt, ohne dass jedes Mal erneut Instrumentierungskodierungen hinzugefügt werden müssen, sobald man den Backends wechselt.

Zeitverlauf der Tool-Aufrufe zusammen mit Workspace-Diffen (während des Laufs einsehbar)

Der schnellste Weg, herauszufinden, was ein Agent gerade tut, besteht darin, die Ausgaben, die es im Arbeitsbereich erzeugt, zu überwachen – anstatt durch ein Session-Log zu suchen. Bei Anthropic ist das… Harness Primitivestrukturen für langlaufende Claude-Instanzen Agents Der Quick-Start liefert zwei Hooks dafür: watch -n 5 'git log --oneline -8' zeigt die neuesten Commit‑Vorgänge an, die der Agent vorgenommen hat, und watch -n 5 'find screenshots -name "*.png" | tail -5' Es werden die neuesten Screenshots angezeigt, die der Agent aufgenommen hat. Zwei Terminalfenster, die alle fünf Sekunden aktualisiert werden, reichen aus, um festzustellen, ob eine Ausführung tatsächlich Fortschritte macht oder lediglich Zeit verschwendet wird.

Vorübergehender Stack pro Worktree (von dem Agent selbst während des Laufs ausgelesen)

Jedes OpenAIs Beitrag zu Harness: Protokolle, Metriken und Traces sind über eine lokale Verbindung dem Codex ausgesetzt. Observability Stack, der für einen gegebenen Zeitraum vorübergehend ist Worktree”Jeder” Agent Worktree erhält eigene, kurzlebige Instanzen von Loki, Prometheus und Tempo, die ausschließlich auf diesen einzelnen Lauf beschränkt sind. Agent es während seiner Ausführung abfragt. Genau das ermöglicht es einem Prompt wie „nein“ Span in diesen vier Benutzerjourneys die Dauer länger als zwei Sekunden beträgt Agent man kann dies direkt überprüfen, anstatt Rückschlüsse daraus ziehen zu müssen.

(Der frische Kontext Evaluator aus der Tabelle der Fehlermodi liest diese Artefakte, um eine Entscheidung über den „Abschluss“ zu treffen. Er gehört zur Bewertung und nicht zu Observability; siehe § Gesunder Laufzeitzyklus eines Agenten.

Ein minimales selbst gehostetes Observability-Stack

Für etwas in der Art von market-analyst-agent:

1. OpenTelemetry Sammler mit dem GenAI-Prozessor sowie einem Attributfilter gen_ai.*.
2. Tempo (oder Jaeger) für Traces, keybasiert auf gen_ai.conversation.id / thread_id.
3. Loki für strukturierte Einträge in Protokollen von Ereignissen.
4. Prometheus für gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (siehe den Konventionen für Metriken von Generativen KI-Systemen).
5. Grafana-Dashboards, die auf … basieren gen_ai.agent.name und gen_ai.request.model.

Hostete Alternativen (wählen Sie eine, nicht drei):

• LangSmith: nativer LangGraph-Integrationssupport; außerdem das Deployment-Ziel für die Implementierung von Deep Agents. Expertenrat: Die beste Lösung ist es, Eval – die ersten Regressionstests – als Priorität zu behandeln.
• Arize Phoenix: OSS-kompatibel, OTLP-nativ, kompatibel mit OpenInference Instrumentierung. – OpenAI’s Tracing-Dashboard: automatisch, wenn man die OpenAI Agents SDK-Plattform oder deren Temporal-Integration verwendet. – Anthropics Claude Tracing: zur Durchführung von Sessions-Aufgaben innerhalb von Managed Agents-Umgebungen.

Der 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, die wörtlich aus dem OpenTelemetry Register für semantische Konventionen von Generativen KI-Systemen.

Anfragen zu drei häufigen Fehlern

# 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 eine Ausführung fehlschlägt, sollte der Worker sie abbrechen. /workspaces/${THREAD_ID}/_debug/ mit den Artefakten, die Sie bei einer Postmortem-Analyse anfordern würden:

• session.jsonl: vollständige Ausgabe des Ereignisprotokolls aus dem PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values vom letzten erfolgreichen Super-Step. trace.json: OTLP-exportierter Spans für den Lauf.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: Der Arbeitsverzeichnis-Ordner plus git diff im Gegensatz zum Initialisierungs-Commit. screenshots/*.png: Was der Agent wahrnahm.
• PROGRESS.md, feature-list.jsonsowie alle anderen von Agent erstellten Fortschrittsdateien. env.txt: Bildunterschriften, Model-Version, Harness-Commit-SHA.

Dieses Paket liefert einem Menschen oder Prüfer Agent ausreichende Belege, um den Fehler rekonstruieren zu können. Die Aussage „Der Agent ist stecken geblieben“ ist vage. Ein veranschaulichender Bericht hingegen ist konkret: Session s_123 verbrachte 71 Prozent seiner Zeit damit, Tokens dreimal denselben Befehl zu wiederholen. npm install Fehler aufgetreten.

Die richtige Form wählen: Leitfaden zur Entscheidungsfindung

Der größte Teil des obigen Vergleichs reduziert sich letztendlich auf eine Handvoll Entscheidungen.

Beginnen mit der Lauflängenmethode

Verwenden Sie die Lauflänge als ersten Filter:

• Unter 30 Sekunden, idempotent: Request-Lifecycle SDK auf einem App-Server.
• 30 Sekunden bis 60 Minuten, keine Crash-Wiederherstellung erforderlich: Queue + Worker + Checkpoint-DB.
• 60 Minuten bis 24 Stunden: Dieselbe Queue + Worker oder ein Cloud Run Job für einmalige Aufgaben. Verwenden Sie einen persistenten Workflow-Motor, falls auch Versionierung und Wiederausführung erforderlich sind.
• Länger als 24 Stunden – muss Deploys überstehen: Persistenter Workflow-Motor im Temporal-Stil. Cloud Run Jobs können lange Aufgaben bis zu ihrem Task-Limit speichern, bieten jedoch keine Wiederausführungssemantik.
• Mehrtägige RL-Trainingszyklen: K8s Job + Volume + Temporal.

Nach diesem groben Filter sollten Nebeneffekte, Wiederherstellbarkeit, Wiedergabefunktionen, Isolierung, Datenstandort sowie das Team, das das System betreiben wird, überprüft werden.

Plattformgeeignetheit nach Anwendungsfall

Die Matrix ist dicht, da keine einzelne grüne Zelle über die Architektur entscheidet. Eine breite Abdeckung der Arbeitslasten ist zwar vorteilhaft, liefert jedoch keine Informationen zur Datenresidenz, zu Replay-Semantiken, zur Abhängigkeit vom Anbieter, zur betrieblichen Reife oder zu den Kosten für spätere Zustandsverschiebungen.

Deep Agents Deploy umfasst alle Arten von Arbeitslasten, die in der Matrix erfasst sind, wodurch es eine geeignete Lösung darstellt, wenn eine Plattform sowohl kurze Ausführungen, mehrstündige Aufgaben, Code Agents, Forschungsarbeiten Agents als auch terminierte Jobs bewältigen muss. Aufgrund dieser Breite weist es jedoch eine kürzere Einsatzhistorie im Produktivumfeld im Vergleich zu einem Stack aus Queue, Worker und Postgres auf. Betrachten Sie die grün markierten Felder als Aussagen zu den verfügbaren Fähigkeiten, die überprüft werden sollten, und vergleichen Sie anschließend die betrieblichen Einschränkungen, die in der Matrix nicht dargestellt werden können.

Anthropic Managed Agents passt entweder vollständig zu Ihrer Arbeitslast oder gar nicht. Das Produkt weist drei strenge Einschränkungen auf: Es ist ausschließlich hostbasiert, ausschließlich für Claude vorgesehen und erlaubt Laufzeiten von unter 24 Stunden pro Session. Falls Ihre Arbeitslast all diese Bedingungen erfüllt – beispielsweise interne Programmierarbeiten Agent, die in Intervallen von 2 bis 6 Stunden ausgeführt werden – und Sie keine eigene Harness betreiben möchten, dann ist Managed Agents eine hervorragende Lösung, da sie einen großen Teil der Plattformverwaltung von Ihrem Team abnimmt. Sollte eine dieser Einschränkungen nicht erfüllt werden, weil Sie beispielsweise einen nicht-Claude Model benötigen, eine selbst gehostete Infrastruktur wünschen oder längere Laufzeiten von 48 Stunden benötigen, eignet sich Managed Agents nicht – unabhängig von eventuellen Konfigurationsanpassungen.

Es lohnt sich, die Kostenstruktur im Voraus zu modellieren, bevor man eine Entscheidung trifft – und nicht erst danach. Die Session-Stundenkosten betragen 0,08 US-Dollar pro Stunde zusätzlich zu den üblichen Token-Kosten. Wenn ein einzelner Session kontinuierlich läuft, entspricht das etwa 58 US-Dollar pro Monat pro Session. Bei 100 Sessions, die ständig in Betrieb sind, liegen die Kosten vor Abzug der Token etwa bei 5.800 US-Dollar pro Monat. Multiplizieren Sie 0,08 mit der erwarteten Anzahl an gleichzeitigen Session-Stunden, addieren Sie diesen Betrag zu Ihrer Token-Rechnung und vergleichen Sie ihn mit den Kosten einer eigenen Queue- sowie Worker-Infrastruktur. Führen Sie diese Berechnungen unbedingt vor dem finalen Commit durch, denn ein späterer Wechsel von Managed Agents erfordert in der Regel einen kompletten Umstieg auf eine andere Plattform, statt lediglich eine Konfigurationsanpassung.

Hosteter Harness im Vergleich zu eigenem Harness

Der Unterschied liegt hier im Betriebsmodell und nicht daran, wer den Code für Harness geschrieben hat. Hosted bedeutet, dass der Anbieter die Harness-Schleife in seiner Infrastruktur ausführt und Sie eine API aufrufen. Owned bedeutet hingegen, dass Sie die Schleife in Ihrer eigenen Infrastruktur betreiben – selbst dann, wenn der Code für Harness ursprünglich von einem Anbieter stammt.

LangChain tritt auf beiden Seiten dieser Zeile auf, was zu Verwirrung führt. Das Unternehmen stellt LangGraph bereit – eine unter MIT-Lizenz stehende Bibliothek, die man selbst hosten kann – sowie Deep Agents Deploy, ein verwaltetes Produkt, das einen Deep Agents Harness auf LangSmith Deployment im Standard-Cloud-Modus ausführt. Es handelt sich um dasselbe Unternehmen mit zwei unterschiedlichen Betriebsmodellen Models. Man wählt das jeweilige Plattform-Modell Model aus, nicht den Anbieter. (Deep Agents Deploy verfügt außerdem über einen selbst gehosteten Modus für Teams, die die Benutzerfreundlichkeit Harness ohne Cloud-Komponente wünschen; dieser Modus fällt in die Kategorie der selbst gehosteten Lösungen.)

Wählen Sie einen gehosteten Harness, wenn seine Unterstützung für Model, die Datengrenzen, das Wiederherstellungsverhalten sowie die Erweiterungspunkte bereits passen. Wählen Sie hingegen einen eigenen Harness, wenn diese Einschränkungen Aspekte sind, die Sie geplant haben, in Zukunft zu ändern. Der Wechsel zwischen diesen beiden Ansätzen verändert den Observability sowie die Ausführungsgrenzen, weshalb der Abbruchweg unbedingt vor dem Einsatz mit Produktionsdaten getestet werden muss.

Hosteter Sandbox im Vergleich zu einer eigenen Ausführungsumgebung

Wählen Sie einen gehosteten Sandbox aus, wenn die Isolierungsmechanismen des Anbieters, die Funktionen zum Pause/Weiterführen sowie die Fork-Semantik mit den Anforderungen bezüglich der Bedrohung Model sowie des verfügbaren Startbudgets übereinstimmen. Docker oder Fargate eignen sich für vertrauenswürdige interne Workloads, die auf VPC-Zugriff oder strenge Datenerhaltung angewiesen sind, doch ein herkömmlicher Container stellt keine ausreichende Abschottung gegen feindlichen Code dar. Fügen Sie gVisor, Kata, eine MicroVM oder einen weiteren verschlüsselten Runtime hinzu, falls das Agent unvertrauenswürdige Pakete installiert oder generierte Programme ausführt.

Zustandsspeicher: Git, Datenbanken und Objektspeicher nebeneinander

Lange laufende Agents nutzen in der Regel gleichzeitig drei Zustandsspeicher, da jeder Speicher für ein unterschiedliches Artefakt zuständig ist.

Git speichert den Zustand des Arbeitsbereichs: den Code, die Dokumente sowie die Fortschrittsdateien, die durch Agent verändert werden. Jeder Commit liefert dem Harness einen stabilen Wiederherstellungspunkt und dem folgenden Session eine kompakte Historie.

Die Checkpoint-Datenbank speichert den Zustand des Graphen: Was entschieden wurde, welche Knoten ausgeführt wurden, welche Ergebnisse zurückgegeben wurden und was als Nächstes ausgeführt werden soll. Der Artefaktspeicher enthält große Endausgaben wie PDFs, Parquet-Dateien sowie Screenshote. Solche Artefakte gehören weder in Git noch in die Checkpoint-Datenbank.

Wann sollte git als Zustandsverwaltung verwendet werden?

Verwenden Sie Git, wenn die Arbeitslast kodenbasiert ist – also mehrere Dateien bearbeitet werden müssen, Refaktorisierungen durchgeführt oder Anwendungen generiert werden – oder wenn es sich um dokumentenbasierte Arbeiten handelt, bei denen die Versionsgeschichte der Dateien von Bedeutung ist. Das Muster ist einfach: Erstellen Sie einen Ausführungs-Zweig, führen Sie einen Initialisierungs-Commit durch und fügen Sie anschließend Commits an sinnvollen Meilensteinen hinzu – nach der Einrichtung, nach jedem Feature, nachdem die Tests bestanden haben sowie nach der abschließenden Aufräumarbeit. Speichern Sie den SHA-Wert des neuesten Workspace-Commits neben der Zeile Checkpoint. Beim Wiederaufnehmen überprüft der nächste Mitarbeiter den Zweig und liest git log --oneline -8, prüft git status und der neueste Diff, anschließend wird er ausgelesen. PROGRESS.md oder irgendein Übertragungsfile, das der vorherige Session erstellt hat.

Dadurch wird Git zu einer Wiederherstellungsoberfläche für das gerade bearbeitete Artefakt und nicht zu einem Ersatz für die Checkpoint-Datenbank. Git kann zwei Fragen beantworten: Was hat sich geändert und welche Version hat die Tests bestanden. Er kann dem Harness jedoch nicht mitteilen, welcher Graphenknoten als Nächstes ausgeführt werden soll, welcher Tool Call auf Freigabe wartet oder welche Wiederholung bereits ihre Idempotenzschlüssel verwendet hat. Anthropics Harness nutzt Initialisierungscommits zusammen mit Featurespezifischen Commits als Quelle der Wahrheit zur Wiederherstellung des Arbeitsbereichs; der Model liest diese Informationen ein. git log --oneline -8 um den Zustand wiederherzustellen. Überspringen Sie Git, wenn das Ergebnis eine einzelne, konversationelle Antwort ist – der damit verbundene Aufwand lohnt sich in diesem Fall nicht.

Wann DB-Checkpointing eingesetzt werden sollte

Verwenden PostgresSaver-stiliges Checkpointing, wenn der Agent über eine Graphenstruktur mit mehreren Knoten verfügt, bei der der Zwischenzustand von Bedeutung ist (Planner → Forscher → Autor → Prüfer). Das Referenz-Repo nutzt dieses Verfahren aus genau diesem Grund. Legen Sie keine Arbeitsplatzdaten im Terabyte-Bereich in den Checkpoint ab; diese sollten in Object Storage gespeichert werden.

Wann ein Artifact-Store (S3 / GCS) verwendet werden sollte

Verwenden Sie Objektspeicher, wenn:

• Die Ausgabe ist größer, als die Checkpoint-Datenbank aufnehmen kann;
• die nachgelagerten Verarbeiter benötigen ein über eine URL aufrufbares Artefakt, ohne dabei über den Agent gehen zu müssen; oder
• das Lieferprodukt und der Laufzustand weisen unterschiedliche Aufbewahrungsfristen auf.

Zum Beispiel kann man das Session-Log nach 30 Tagen löschen, während der endgültige Bericht über Jahre hinweg aufbewahrt wird. Die Struktur sollte dabei entsprechend definiert werden. (thread_id, checkpoint_id, artifact_name) Damit bleibt der Erstellungsprozess rekonstruierbar.

Wann man Zustimmungsgate für Menschen einrichten sollte

Fügen Sie Gateways hinzu, wenn der Tool Call zerstörerisch und irreversibel ist (Datenbankschreibvorgänge, Geldtransfers, Sendung externer Kommunikationen), wenn der Tool Call den Einflussbereich des Agent verlässt (Produktivumsetzungen, Veröffentlichungen für Kunden) oder wenn Aufsichtsbehörden eine Überprüfung erfordern. LangGraphs interrupt() Sowohl das Deep Agents’-Approvals-Middleware als auch die entsprechenden Genehmigungsmechanismen verfügen über integrierte Unterstützung für diese Kontrollpunkte. Teil 4 Erklärt, warum diese Gates ein Berechtigungsproblem darstellen und nicht ein Prompt-Problem.

Eine praktische Überprülliste für die Produktion

Bevor ein langlaufender Agent veröffentlicht wird, beantworten Sie diese Fragen unter Verwendung konkreter Begriffe aus der Infrastruktur.

1. Welcher Store ist für die Session-Ereignisse sowie die Checkpoints verantwortlich?
2. Was geschieht, wenn der Worker mitten in einem Tool Call abbricht?
3. Kann eine Ausführung den Arbeitsraum einer anderen Ausführung beschädigen?
4. Welche Aktionen erfordern eine Genehmigung?
5. Können der Model oder der Sandbox rohe Anmeldeinformationen einsehen?
6. Welcher Tool Calls kann sicher wiederholt werden?
7. Wo wird die Obergrenze für die Kosten pro Ausführung durchgesetzt?
8. Welche Prüfung des frischen Kontexts entscheidet über den Status „abgeschlossen“?
9. Wo werden die endgültigen Ausgaben nach Beendigung des Sandbox gespeichert?
10. Können wir einen fehlgeschlagenen Lauf morgen ohne Neuausführung erklären?

Falls die Antwort auf eine dieser Fragen lautet: „Der Prompt weist den Agent an, vorsichtig zu sein“, dann ist das System noch nicht im Einsatz. Es handelt sich weiterhin um eine Demo-Version.

Die nächste Schicht ist die Harness-Schleife

Dieser Runtime kann einen Lauf am Laufen halten und wiederherstellbar machen, doch Langlebigkeit beweist nicht, dass die Arbeit korrekt ist. Teil 6, Harness Engineering für AI Agents, umfasst den Zyklus rund um den Model: wie ein Trace zu einem Testfall wird, wo sich die Regeln für Wiederholungsversuche und Abbruch befinden, was bei der Übertragung unbedingt beibehalten werden muss, sowie wie eine externe Akzeptanzprüfung festlegt, dass eine Ausführung abgeschlossen ist.

Referenzen

Ingenieurtechnische Dokumentationen

• OpenAI, Harness Engineering: Nutzung von Codex in einer Agent-ersten Welt.
• Anthropic Engineering, Effektive Mechanismen zur Steuerung von langlaufenden Agents.
• Anthropic Engineering, Harness Entwurf für die Entwicklung langlaufender Anwendungen.
• Anthropic Engineering, Skalierung von verwalteten Agents-Systemen: Trennung des „Gehirns“ von den „Händen“, 8. April 2026.
• Kognition AI, Die Neuimplementierung von Devin für Claude Sonnet 4.5: Erkenntnisse und Herausforderungen.
• Vercel, Wir haben 80 Prozent der Tools unserer Agent entfernt..
• Addy Osmani, langlaufende Agents.

LangGraph und Deep Agents

• LangGraph-Dokumentation, Persistenz.
• LangGraph-Referenz, Checkpoints.
• langgraph-checkpoint-postgres auf PyPI.
• LangChain-Dokumentation, Überblick zu Deep Agents.
• LangChain-Blog, Der Runtime hinter der produktiven Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox-Konzepte.

Temporale Aspekte

• Zeitbasiertes Blog, Einführung in Temporal und agentic Sandboxes: den OpenAI Agents SDK.
• Zeitbasiertes Blog, Produktionsreifes Agents mithilfe des OpenAI Agents SDK + Zeitbezogene Aspekte.
• Temporal × OpenAI Agents SDK-Beitrag im README (temporalio/sdk-python).

Anthropic-Plattform

• Anthropic, Preisstruktur der Claude-Plattform: Gemanagte Stundensätze für Agents Session. anthropics/cwc-long-running-agents: Der Code für Claude 2026 im Selbststudium verwendet Evaluator-Subagenten sowie Muster für Fortschrittsdateien.

Sandbox-Anbieter

• ZenML, E2B gegen Daytona: Vergleich von Sandbox für Plattformingenieure.
• Daytona-Dokumentation, Sandboxes.
• Daytona-Changelog, die Endpunkte Sandbox, Fork und Snapshot.
• Modale Dokumentationen, Sandboxes.
• Modale Dokumentationen, Cold Start-Anleitung.
• Laufschleife auf AWS Marketplace.
• Vercel Sandbox-Preise und -Limitierungen.

Zeitüberschreitungen und Quoten der Cloud-Plattform

• Google Cloud, Konfigurieren Sie die Anfragedauerüberschreitung für die Dienste..
• Google Cloud, Verwendung von WebSockets.
• Google Cloud, Zeitlimit für Aufgaben festlegen.
• AWS, Die Timeout-Einstellung der Lambda-Funktion konfigurieren.
• AWS, Lambda-Quoten.
• AWS, Throttling-Quoten für Fargate.
• AWS, ECS-Dienstquoten sowie Throttling-Grenzen für API.

Observability

• OpenTelemetry, Semantische Konventionen für generative AI-Systeme.
• OpenTelemetry, Registrierung der AI-Attribute.
• OpenTelemetry, Semantische Konventionen für GenAI Agent und Framework Spans.
• OpenTelemetry, Semantische Konventionen für generative AI-Metriken.

Serie

• Teil 1: AI Agent Reasoning Schleifen im Jahr 2026: ReAct, ReWOO sowie Plan-and-Execute. Teil 2: AI Agent Memory Architektur im Jahr 2026: Checkpoints, Vector Stores sowie das Dokumentenmemory. Teil 3: AI Agent Tool Use im Jahr 2026: MCP, CLI, Fähigkeiten, Ausführung von Code sowie ACI.
• Teil 4: AI Agent Sicherheit im Jahr 2026: - Guardrails, Berechtigungen, Sandboxes, HITL sowie MCP-Bereichsdefinitionen.
• Teil 5: Langlaufende AI Agent Runtime im Jahr 2026 (dieser Beitrag) Teil 6: Harness Engineering für AI Agents: Akzeptanzprüfungen, Traces, Wiederholungsversuche, Übergaben sowie der Schleifenprozess innerhalb des Model.

Der von dem Marktanalysten Agent verwendete Code (LangGraph-Worker, Postgres-Checkpointer, Qdrant-Memory, der MCP Sidecar sowie die oben beschriebene Docker Compose-Topologie) ist bereits in Betrieb. GitHub._