Managed Agent Harness vs. Self-Hosted Agent Loop: Was Sie gewinnen, was Sie verlieren

Der Begriff „selbstgehosteter Agent“ verbirgt heute mindestens drei verschiedene Architekturen. Sie können ein verwaltetes Harness mit von OpenAI gehosteter Rechenleistung nutzen, ein verwaltetes Harness, das mit von Ihnen betriebener Infrastruktur verbunden ist, oder das Harness und die Agentenschleife selbst ausführen. Diese Optionen haben sehr unterschiedliche Auswirkungen auf Kontrolle, Wiederherstellung, Kontextverwaltung, Sicherheit, Latenz und Betriebsaufwand.

Der Fehler: Self-Hosting als eine einzige Entscheidung zu betrachten

Bei herkömmlicher Software bedeutet „selbstgehostet“ meist, dass die Anwendung auf einer von Ihnen kontrollierten Infrastruktur läuft. Agentensysteme verkomplizieren diese Definition, da die Laufzeitumgebung aufgeteilt werden kann. Die Modell-und-Tool-Schleife kann an einem Ort ausgeführt werden, während Codeausführung, Dateien und der Zugriff auf private Netzwerke an einem anderen Ort stattfinden.

Die aktuelle Agents-API-Architektur von OpenAI macht diese Trennung explizit: OpenAI führt das Harness aus, während die Ausführungsumgebung fehlen, von OpenAI gehostet oder selbstgehostet sein kann. Eine selbstgehostete Umgebung bedeutet daher nicht, dass auch die Agentenschleife selbstgehostet ist.

Diese Unterscheidung ist wichtig, da viele Teams eine komplexere Laufzeitumgebung wählen, als sie benötigen. Sie möchten Zugriff auf private Netzwerke oder benutzerdefinierte Pakete, schlussfolgern daraus, dass der gesamte Agent selbstgehostet sein muss, und übernehmen ungewollt die Verantwortung für Kontextverwaltung, Orchestrierung, Wiederherstellung und Lebenszyklus, die eigentlich verwaltet bleiben könnten.

Drei Architekturen, die oft als „selbstgehostet“ bezeichnet werden

Das Zwei-Ebenen-Modell

Verwaltetes Harness: Was Sie tatsächlich gewinnen

Ein verwaltetes Harness nimmt Ihnen mehr als nur eine While-Schleife ab. Die aktuelle Agents-API von OpenAI verwaltet Sitzungen, Orchestrierung, Kontextkompaktierung und Wiederherstellung. Anthropics Arbeit zu verwalteten Agenten beschreibt dieselbe übergeordnete Motivation: Harnesses enthalten Annahmen über das Modellverhalten, und diese Annahmen müssen sich mit der Weiterentwicklung der Modelle anpassen.

Das bedeutet, dass der Vorteil nicht nur in weniger Codezeilen besteht. Die Plattform kann Laufzeitverhalten, langfristige Kontextverarbeitung, Subagenten-Koordination und Wiederherstellung aktualisieren, ohne dass jedes Anwendungsteam diese Mechanismen neu entwickeln muss.

• Weniger anwendungseigener Orchestrierungscode.
• Verwaltetes Verhalten langlebiger Sitzungen.
• Verwaltete Kontextkompaktierung und Wiederherstellung.
• Eine Laufzeitumgebung, die sich mit den Modellfähigkeiten weiterentwickeln kann.
• Einfachere Einführung plattformnativer Funktionen für Subagenten und langlebige Agenten.
• Potenziell geringerer Betriebsaufwand für Teams, deren Unterscheidungsmerkmal nicht das Harness selbst ist.

Verwaltetes Harness: Worauf Sie verzichten

Die Übergabe des Harness bedeutet auch die Abgabe eines Teils der Kontrolle. Ihre Anwendung bestimmt nicht mehr jedes Detail der Iteration, Kontextstrategie, Orchestrierung und Laufzeitentwicklung. Eine Plattformaktualisierung kann das System verbessern, aber auch Verhaltensweisen verändern, auf die sich Ihr Produkt implizit verlassen hat.

Daraus entsteht eine andere Art von Engineering-Anforderung: robuste Evaluierungen, explizite Produktgrenzen und eine Integrationsschicht, die verhindert, dass das Verhalten verwalteter Sitzungen zu Ihrer geschäftlichen Single Source of Truth wird.

Selbst gehostete Ausführungsumgebung: Die mittlere Architektur

Das Modell der selbst gehosteten Umgebung von OpenAI ist wichtig, da es private Rechenressourcen von der Kontrolle über das Harness entkoppelt. Die Plattform führt weiterhin das Codex-Harness aus, während ein Executor in Ihrer Umgebung läuft und Befehle über eine ausgehende Verbindung empfängt.

Sie kontrollieren Bereitstellung, Dateien, Abhängigkeiten, Netzwerkzugriff und Bereinigung. Das Harness kann somit auf private Infrastruktur oder individuelle Software zugreifen, ohne dass die gesamte Agenten-Laufzeitumgebung in Ihre Anwendung verlagert werden muss.

Der Preis dafür ist die Verantwortung für den Lebenszyklus. Ihre Anwendung muss Sitzungen Rechenressourcen zuweisen, doppelte Bereitstellungen vermeiden, Umgebungen wieder verbinden, das Herunterfahren koordinieren und alle Dateien aufbewahren, die die Umgebung überdauern müssen.

Wann eine selbst gehostete Ausführung ausreicht

• Der Agent benötigt Zugriff auf eine private VPC oder einen internen Dienst.
• Der Agent benötigt benutzerdefinierte Binärdateien, Pakete, Treiber oder Systemsoftware.
• Die Arbeitslast muss auf Hardware oder Cloud-Konten ausgeführt werden, die Sie kontrollieren.
• Dateien müssen innerhalb einer kontrollierten Umgebung verbleiben.
• Sie benötigen Ihren eigenen Sandbox-Anbieter oder ein eigenes Isolationsmodell.
• Sie möchten eine plattformverwaltete Orchestrierung, aber eine infrastrukturkontrollierte Ausführung.

Wann Sie möglicherweise auch das Harness selbst betreiben müssen

Der eigene Betrieb des Harness ist dann gerechtfertigt, wenn das Harness selbst Teil Ihrer Produktdifferenzierung oder Ihrer Vorgaben ist. OpenAIs aktuelle Laufzeitübersicht positioniert das Codex SDK für den Betrieb des Codex-Harness in der von Ihnen betriebenen Infrastruktur, während Responses die Low-Level-Option darstellt, wenn Sie die Agentenschleife vollständig selbst verwalten möchten.

Entscheidend ist, eine Anforderung zu identifizieren, die tatsächlich auf der Harness-Ebene und nicht auf der Ausführungsebene liegt.

Der Kontroll-Eskalationstest

Wählen Sie die am wenigsten selbst gehostete Architektur, die die tatsächliche Anforderung erfüllt. Erhöhen Sie den Kontrollgrad schrittweise Schicht für Schicht.

Der Betriebsaufwand wächst nichtlinear, wenn Sie das Harness selbst betreiben

Eine selbst betriebene Schleife klingt in einer Demo simpel: Modell aufrufen, Tool-Aufruf prüfen, Tool ausführen, Ergebnis anhängen, wiederholen. Der Produktivbetrieb bringt jedoch langlebigen Zustand, Wiederholungsversuche, doppelte Ereignisse, Abbrüche, Genehmigungen, Kontextüberlauf, Tool-Timeouts, Prozessneustarts, Trace-Persistenz, Gegendruck (Backpressure), nebenläufige Arbeit und die Wiederherstellung nach partiellen Seiteneffekten mit sich.

Die Forschung von Anthropic zu langlebigen Agenten zeigt immer wieder, dass das Harness-Design die Leistung maßgeblich beeinflusst. Ihre Arbeit zur Entwicklung langlebiger Anwendungen nutzt explizite Planung, strukturierte Artefakte und Evaluator-Agenten, da naive Schleifen dazu neigen, Fortschritte zu verlieren oder vorzeitig abzubrechen. Das Harness ist daher Produktionslogik, keine bloße Infrastruktur-Verkabelung.

Sicherheitsgrenze: Selbst gehostete Rechenleistung macht den Agenten nicht automatisch privat

Eine selbst gehostete Ausführungsumgebung kontrolliert, wo Befehle ausgeführt werden und wo Dateien liegen, doch das verwaltete Harness und die Modellinteraktion überschreiten weiterhin die Dienstgrenze. Teams sollten Datenflüsse daher explizit abbilden, anstatt „selbst gehostet“ als Synonym für Datenschutz zu verwenden.

Der selbst gehostete Executor von OpenAI verwendet eingeschränkte Umgebungs-Anmeldedaten und ausgehende Verbindungen. Das ist eine nützliche Isolierung, aber Ihre Anwendung benötigt dennoch eigene Regeln für Secrets, Freigaben privater Netzwerke, Benutzer-zu-Umgebungs-Isolierung, Dateiaufbewahrung, Tool-Autorisierung und Datenklassifizierung.

Latenz und Kosten: Kontrolle kann Engpässe verschieben statt beseitigen

Self-Hosting kann einige Datenpfad- oder Umgebung-Startkosten senken, aber auch Bereitstellungszeit, WebSocket-Lebenszyklen, Kaltstarts, Sandbox-Bereinigung, Observability-Infrastruktur und Engineering-Overhead verursachen. Eine verwaltete Umgebung kostet pro Recheneinheit möglicherweise mehr, ist bei geringem oder unregelmäßigem Volumen jedoch oft günstiger im Betrieb.

Der zutreffende Vergleich sind die Gesamtsystemkosten: Modell- und Tool-Nutzung, Umgebungszeit, Infrastruktur, Entwicklungsaufwand, Bereitschaftsbelastung, Fehlerbehebung und die Kosten einer langsameren Iteration.

Eine Entscheidungsmatrix für die Produktion

Hybrid ist kein Kompromiss – es ist oft die sauberere Architektur

Ein verwaltetes Harness mit selbst gehosteter Ausführung ist nicht „halb selbst gehostet“. Es ist eine bewusste Trennung von Zuständigkeiten. Die Plattform übernimmt die Komplexität der Agentenlaufzeit für lange Zeithorizonte, während Ihre Infrastruktur die Ausführung, private Konnektivität und Dateien verantwortet.

Diese Abgrenzung ähnelt anderen Cloud-Architekturen: verwaltete Control Plane, kundengesteuerte Data oder Execution Plane. Die wesentliche Entwurfsarbeit besteht darin, den Vertrag dazwischen zu definieren – Sitzungsidentität, Umgebungsidentität, Anmeldedaten, Dateien, Tool-Berechtigungen, Lifecycle-Ereignisse und Bereinigung.

Was würde diese Einschätzung ändern?

Die Empfehlung ändert sich, wenn verwaltete Harnesses deutlich mehr Laufzeitkontrolle bieten, wenn selbst gehostete Harnesses einfachere Primitive für persistente Sitzungen und Wiederherstellung erhalten oder wenn regulatorische Vorgaben vorschreiben, dass die gesamte Agentenschleife und Modellinteraktion innerhalb der von Ihnen betriebenen Infrastruktur verbleiben muss.

Es ändert sich auch mit den Fähigkeiten der Modelle. Anthropic weist ausdrücklich darauf hin, dass Annahmen über den Harness veralten können, wenn sich Modelle verbessern. Ein Kontrollmechanismus, der heute unverzichtbar ist, kann später überflüssig werden, während eine neue Modellfähigkeit eine neue Governance-Anforderung schaffen kann.

Einschränkungen

Dieser Artikel grenzt architektonische Verantwortlichkeiten voneinander ab; er behauptet nicht, dass ein Hosting-Modell durchgehend sicherer, kostengünstiger oder zuverlässiger ist. Diese Ergebnisse hängen von der Implementierung, dem Workload, den Compliance-Anforderungen, den Fähigkeiten des Teams und dem Verhalten des Anbieters ab.

Die OpenAI Agents API befindet sich noch in der Public Beta, und Managed-Agent-Produkte verschiedener Anbieter weisen unterschiedliche Abgrenzungen auf. Das Zwei-Ebenen-Modell soll dabei helfen, diese Architekturen zu vergleichen, ohne vorauszusetzen, dass jeder Anbieter identische Begriffe verwendet.

Fazit

Die sinnvolle Frage lautet nicht: „Sollten wir den Agenten selbst hosten?“ Sie lautet: Welche Ebene müssen wir tatsächlich kontrollieren?

Wenn die Anforderung privates Compute, benutzerdefinierte Pakete, lokale Dateien oder Zugriff auf interne Netzwerke ist, hosten Sie die Execution Plane selbst und belassen Sie den Harness als Managed Service. Wenn die Anforderung Orchestrierungssemantik, Kontextstrategie, Anbieterkontrolle oder der Runtime-Lebenszyklus selbst ist, kann ein eigener Harness gerechtfertigt sein. Eskalieren Sie die Kontrolle nur so weit, wie es die Anforderung erfordert.

FAQ

Glossar

Primärquellen und weiterführende Literatur