Die Entscheidung lautet nicht „Welches Logo hostet den Agenten?“, sondern „Wer kann jeden Teil der Laufzeit betreiben, prüfen, wiederherstellen und ändern?“
Was umfasst KI-Agent-Hosting?
KI-Agent-Hosting umfasst die Laufzeit und jede Abhängigkeit, die die Arbeit des Agenten verfügbar, prüfbar und wiederherstellbar hält. Die Referenzarchitektur von Google Cloud trennt Hosting-Plattform, Agent-Interaktionen, Modelle, Speicher, Vektordatenbanken, Werkzeuge und Codeausführung (Google Cloud, geprüft am 18. September 2026). Mastra trennt ebenfalls Laufzeit, Modellzugang, dauerhaften Speicher, Secrets, Traces und Werkzeugaufrufe (Mastra, geprüft am 18. September 2026).
Verwenden Sie diese Zuständigkeitskarte:
- Compute und Laufzeit. Halten Sie fest, wo der Agent-Prozess läuft und wer ihn bereitstellen, stoppen, neu starten oder aktualisieren kann. Cloud Run dokumentiert Dienste, Instanzen, Worker Pools und Jobs als verschiedene Ressourcen für Agent-Workloads (Google Cloud, geprüft am 18. September 2026).
- Modellzugang. Erfassen Sie jeden Modell-Endpunkt, das zugehörige Konto und die Person mit Änderungsrecht. Die Google-Cloud-Architektur zeigt, dass die Orchestrierung Modelle über mehrere mögliche Dienste aufrufen kann (Google Cloud, geprüft am 18. September 2026).
- Dateien und Zustand. Erfassen Sie Arbeitsdateien, Gesprächszustand, Workflow-Checkpoints, Speicher und den jeweiligen Datenspeicher. Mastra erklärt, dass zustandsbehaftete Agenten einen dauerhaften Speicher brauchen und dass Zustand im Arbeitsspeicher einen Serverneustart nicht überlebt (Mastra, geprüft am 18. September 2026).
- Secrets. Erfassen Sie Modellschlüssel, Datenbankzugänge und Werkzeugzugänge sowie die Personen, die sie erstellen, lesen, rotieren oder widerrufen dürfen. Mastra empfiehlt, Zugangsdaten serverseitig in Umgebungsvariablen oder einem Secret Store statt fest im Code zu halten (Mastra, geprüft am 18. September 2026).
- Logs und Traces. Erfassen Sie die aufgezeichneten Ereignisse, deren Ziel und die Prüfer. Mastra beschreibt Traces für Modellaufrufe, Werkzeugaufrufe, Speicherabrufe und die endgültige Antwort (Mastra, geprüft am 18. September 2026).
- Backups. Definieren Sie die dauerhaften Speicher, Dateien und Konfigurationen im Backup-Umfang. Die Quellen belegen, dass Zustand außerhalb des Prozessspeichers fortbestehen muss; der genaue Backup-Umfang bleibt eine Bereitstellungsentscheidung (Mastra, geprüft am 18. September 2026).
- Recovery. Benennen Sie, wer jede aufbewahrte Komponente wiederherstellt und wer den wiederhergestellten Dienst abnimmt. Mastra nennt Wiederholungen und Fehlerbehebung als Produktionsthemen, während das konkrete Verfahren von der Bereitstellung abhängt (Mastra, geprüft am 18. September 2026).
Die Liste macht eine häufige Trennung sichtbar. Ein Anbieter kann Compute betreiben, während Ihr Unternehmen Modellkonten, Werkzeugzugänge, Datenspeicher oder Recovery-Entscheidungen besitzt. Eine selbst betriebene Box kann die Compute-Zuständigkeit umkehren und weiterhin externe Modelle und Werkzeuge aufrufen (Google Cloud, geprüft am 18. September 2026).
Wie unterscheiden sich Managed Hosting und eine selbst betriebene Box?
Sie unterscheiden sich durch den standardmäßigen Laufzeitbetreiber, nicht durch die Zahl der zuzuweisenden Aufgaben. Mastra beschreibt Managed Runtimes als Tausch von Betriebsarbeit gegen Bindung an Abstraktionen und Preismodell des Anbieters. Selbst gehostete Server bieten laut Mastra Flexibilität, während der Betreiber Skalierung, Überwachung und Neustarts übernimmt (Mastra, geprüft am 18. September 2026).
| Zuständigkeit | Managed Agent Hosting | Selbst betriebene Box | Nachweis |
|---|---|---|---|
| Compute | Anbieter betreibt die gelieferte Laufzeit innerhalb der dokumentierten Grenze | Benannter Betreiber verwaltet Host oder Container | Bereitstellungsziel, Administratoren, Neustartweg (Mastra, geprüft am 18. September 2026) |
| Modellzugang | Kann enthalten oder über ein getrenntes Konto verbunden sein | Betreiber konfiguriert lokale oder externe Endpunkte | Endpunktliste, Kontoinhaber, Änderungsrecht (Google Cloud, geprüft am 18. September 2026) |
| Dateien und Zustand | Anbieter kann Speicher liefern oder Käufer verbindet einen Speicher | Betreiber wählt und betreibt dauerhafte Speicher | Speicherkarte, Rollen, Persistenztest (Mastra, geprüft am 18. September 2026) |
| Secrets | Secret Store der Plattform kann Zugangsdaten halten | Betreiber wählt den Mechanismus | Inventar, Rotation, Widerrufsweg (Mastra, geprüft am 18. September 2026) |
| Logs und Traces | Anbieterwerkzeuge können ausgewählte Ereignisse erfassen | Betreiber wählt und betreibt Logging | Ereignisliste, Ziel, Leserollen (Mastra, geprüft am 18. September 2026) |
| Backups | Enthaltene Speicher und Dateien genau bestätigen | Betreiber definiert und führt den Umfang aus | Komponenten, Backup-Verantwortlicher, aktueller Nachweis (Mastra, geprüft am 18. September 2026) |
| Recovery | Aufgaben von Anbieter und Käufer getrennt bestätigen | Betreiber besitzt den schriftlichen Wiederherstellungsweg | Wiederherstellung, Abnahme, Protokoll (Mastra, geprüft am 18. September 2026) |
Die Tabelle ist ein Arbeitsblatt und keine Anbietergarantie. Füllen Sie sie aus aktueller Dokumentation, Konfiguration und Betriebsnachweisen des gewählten Dienstes aus.
Sehen Sie sich das AI Jungle OS Cockpit an, wenn Sie eine selbst betriebene Done-with-you-Box mit einer Managed Runtime vergleichen möchten, ohne die Zuständigkeiten zu verdecken.
Kann ich einen KI-Agenten hosten?
Ja. Sie können einen KI-Agenten als anfragegesteuerten Dienst, dauerhafte Instanz, Hintergrund-Worker oder abgeschlossenen Job hosten, wenn die Ressource zur Arbeit passt. Google Cloud ordnet zustandslose, anfragegesteuerte Agenten Diensten zu, dauerhafte zustandsbehaftete Schleifen Instanzen, verteilte Hintergrundflotten Worker Pools und begrenzte Abläufe Jobs (Google Cloud, geprüft am 18. September 2026).
Das Bereitstellungsziel ist nur ein Teil der Karte. Ein gehosteter Agent kann externe Modelle aufrufen, Speicher in einem getrennten Dienst halten, eine Vektordatenbank abfragen, Werkzeuge nutzen und Code ausführen (Google Cloud, geprüft am 18. September 2026). Hosting wird erst zur tragfähigen Betriebsentscheidung, wenn auch diese Wege Eigentümer haben.
Ordnen Sie die Laufzeit der Arbeit zu:
- Nutzen Sie einen Dienst für anfragegesteuerte Arbeit. Google Cloud beschreibt Dienste für zustandslose Agenten mit variablem Nutzerverkehr (Google Cloud, geprüft am 18. September 2026).
- Nutzen Sie eine Instanz für eine dauerhafte Schleife. Google Cloud beschreibt Instanzen für dedizierte, zustandsbehaftete und ständig aktive Agent-Schleifen (Google Cloud, geprüft am 18. September 2026).
- Nutzen Sie einen Worker Pool für Warteschlangenarbeit. Google Cloud beschreibt Worker Pools für verteilte Agenten, die Aufgaben ohne öffentlichen HTTP-Endpunkt verarbeiten (Google Cloud, geprüft am 18. September 2026).
- Nutzen Sie einen Job für begrenzte Ausführung. Google Cloud beschreibt Jobs für Abläufe, die bis zum Abschluss laufen, darunter geplante oder gebündelte Arbeit (Google Cloud, geprüft am 18. September 2026).
Dies sind Beispiele aus dem Ressourcenmodell einer Plattform, keine universellen Produktkategorien. Wenden Sie die Workload-Beschreibung auf jeden Kandidaten an und prüfen Sie seine tatsächlichen Grenzen.
Wo sollten Dateien, Secrets und Logs liegen?
Legen Sie jeden Betriebsdatensatz in einem benannten Speicher ab und weisen Sie Zugang und Wartung zu. Ein zustandsbehafteter Agent braucht dauerhaften Speicher für Gesprächsverlauf, Arbeitsspeicher oder Checkpoints, wenn dieser Zustand einen Neustart überstehen muss (Mastra, geprüft am 18. September 2026). Google Cloud führt Speicher und Vektordatenbank als getrennte Komponenten auf (Google Cloud, geprüft am 18. September 2026).
Fassen Sie diese Speicher nicht unter dem Wort „Daten“ zusammen. Schreiben Sie je eine Zeile für hochgeladene Dateien, Workflow-Zustand, Gesprächsspeicher, abgerufene Dokumente und Ergebnisse, sofern die Workload sie nutzt. Benennen Sie jeweils Speicherdienst, Zugriffsrollen, Aufbewahrungsentscheidung, Backup-Umfang und Recovery-Verantwortlichen. Die Quellen stützen die Trennung von Speicher, Datenbanken und Laufzeitzustand; Aufbewahrung und Recovery gehören zur konkreten Bereitstellung (Google Cloud, geprüft am 18. September 2026; Mastra, geprüft am 18. September 2026).
Halten Sie Secrets vom Inhalt getrennt. Mastra sagt, dass Modellschlüssel, Datenbankverbindungen und Werkzeugschlüssel serverseitig in Umgebungsvariablen oder einem passenden Secret Store liegen sollen (Mastra, geprüft am 18. September 2026). Halten Sie fest, wer jedes Secret ändern und widerrufen kann.
Behandeln Sie Logs als eigenen Datenweg. Mastra beschreibt Produktionstraces für Modellaufrufe, Werkzeuge, Speicherabrufe und die endgültige Antwort (Mastra, geprüft am 18. September 2026). Entscheiden Sie, welche Ereignisse die Workload braucht, wohin sie gehen und wer sie prüfen kann. Leiten Sie die Antwort nicht vom Compute-Standort ab.
Der Standort einer Box ist keine Datenkarte. Der nützliche Nachweis nennt jeden Speicher, Zugangspfad, Log-Ziel und externen Dienst des Agenten.
Wer besitzt Backups und Recovery?
Der Backup-Verantwortliche bewahrt die vereinbarten Komponenten auf; der Recovery-Verantwortliche stellt sie wieder her und legt das Ergebnis zur Abnahme vor. Dauerhafter Zustand verhindert, dass der laufende Prozess die einzige Kopie ist. Dauerhafter Speicher definiert jedoch noch kein Backup oder Wiederherstellungsverfahren (Mastra, geprüft am 18. September 2026).
Schreiben Sie die Übergabe vor dem Start:
- Umfang. Listen Sie Dateien, Zustandsspeicher, Konfiguration und Aufzeichnungen im Backup auf. Mastra trennt Anwendungszustand und dauerhaften Speicher vom Laufzeitprozess (Mastra, geprüft am 18. September 2026).
- Betreiber. Benennen Sie Person oder Anbieter für den Backup-Prozess. Managed und selbst gehostete Optionen verteilen Betriebsarbeit anders; bestätigen Sie die Aufgabe für den gewählten Dienst (Mastra, geprüft am 18. September 2026).
- Wiederherstellungsweg. Schreiben Sie die Reihenfolge der Komponenten und den Ausführenden jeder Aktion auf. Mastra behandelt Recovery als Produktionsthema, schreibt aber kein universelles Verfahren vor (Mastra, geprüft am 18. September 2026).
- Abnahme. Benennen Sie die Person, die nach der Wiederherstellung die genehmigte Arbeit prüft. Google Cloud trennt Laufzeittypen und verbundene Komponenten; die Abnahme muss zur eingesetzten Architektur passen (Google Cloud, geprüft am 18. September 2026).
- Nachweis. Bewahren Sie den letzten Backup- und Recovery-Nachweis bei der Matrix auf. Die Quellen belegen Komponenten und Persistenzbedarf; dieser Nachweis dokumentiert den gewählten Betrieb (Mastra, geprüft am 18. September 2026).
Wenn ein Managed-Angebot „Backups enthalten“ sagt, fragen Sie nach den erfassten Speichern und Konfigurationen. Wenn eine eigene Box „Wir kontrollieren die Daten“ sagt, fragen Sie nach Backup-Ausführung und Restore-Abnahme. Das sind Beschaffungsfragen, keine Behauptungen über eines der Modelle.
Welche KI-Agent-Hosting-Plattformen sind die besten?
Die beste Plattform hat eine dokumentierte Laufzeit, die zur Workload passt, und eine Verantwortungsmatrix, die Ihr Team tatsächlich betreiben kann. Das ist eine redaktionelle Entscheidungsregel, kein Anbieter-Ranking. Die erlaubten Quellen dokumentieren Ressourcentypen und Betriebskompromisse, aber keinen universellen Sieger.
Vergleichen Sie jeden Kandidaten mit derselben Workload und Zuständigkeitskarte. Erfassen Sie jedes externe Modell, jeden Speicher, jedes Werkzeug, jedes Secret und jedes Log-Ziel. Weisen Sie Backup und Recovery zu. Halten Sie jede fehlende Antwort als offen fest. So beantworten Managed Runtime und eigene Box dieselben Fragen.
Häufig gestellte Fragen
Kann ich einen KI-Agenten hosten?
Ja. Je nach Workload kann die Laufzeit als anfragegesteuerter Dienst, dauerhafte Instanz, Worker Pool oder Job bereitgestellt werden (Google Cloud, geprüft am 18. September 2026). Sie brauchen weiterhin benannte Verantwortliche für Modelle, Zustand, Werkzeuge, Secrets, Logs, Backups und Recovery.
Welche KI-Agent-Hosting-Plattformen sind die besten?
Die erfassten Quellen stützen kein universelles Ranking. Vergleichen Sie Laufzeittyp und Zuständigkeit für Compute, Modellzugang, Dateien, Secrets, Logs, Backups und Recovery. Wählen Sie den Kandidaten, der zur Workload passt und keine benötigte Aufgabe ohne Eigentümer lässt.
Sehen Sie sich das AI Jungle OS Cockpit an, um eine selbst betriebene Done-with-you-Box mit sichtbarer Verantwortungsmatrix zu prüfen.
Written by Tileo, who operates a portfolio of internet businesses on this same cockpit.