Google AX: Suspend/Resume, Neustartkosten und Selbsthosting

Zurück

Kevin Riedl

14 min Lesezeit · 20. Sep. 2026
Zuletzt geprüft 15. Oktober 2026

Weiter

Ein Agent verbraucht 30 US-Dollar. Sein Prozess verschwindet. Du bezahlst erneut für bereits erledigte Arbeit. Das ist ein Wiederherstellungsproblem. Für Agenten zu bezahlen, die meistens warten, ist ein Auslastungsproblem. Google AX ist für beides interessant. Trotzdem löst nicht dieselbe Funktion automatisch beide Probleme.

AX, auch Agent Executor genannt, ist Googles unter Apache 2.0 lizenzierter Orchestrator für Agenten-Tasks in Sandboxes. Er läuft auf Agent Substrate und nutzt YAML sowie Befehle, die an Kubernetes erinnern. Die Idee: Agentenausführung als Infrastruktur verwalten, statt noch ein Framework für die Denk- und Werkzeugschleife zu bauen. Projektüberblick und Entwicklungshinweis des geprüften AX-Stands.

Geprüft am 15. Oktober 2026: AX 22954f64bb29 und Agent Substrate 6edd1fccfc9d. Dies ist ein Quellen- und Architekturreview, kein Deployment-Test oder Durchsatzbenchmark. Das 30-Dollar-Szenario ist ein Rechenbeispiel, kein von uns gemessenes AX-Ergebnis.

Was orchestriert Google AX heute?

Die aktuelle API hat drei zentrale Ressourcen: Task, Workspace und Model. Ältere Erklärungen mit vier Ressourcen enthalten zusätzlich ein Gateway, das im hier geprüften AX-Schema nicht mehr vorkommt. Eine Ressource beschreibt Konfiguration, nicht automatisch sämtliche Betriebsgarantien.

Ein Task kann den gesamten Agentenauftrag oder eine delegierte Teilaufgabe abbilden. Unter spec.workspaces lassen sich mehrere Workspaces einbinden. Der erste wird zum Arbeitsverzeichnis des Befehls. Aktuelle AX-Konzepte zu Ressourcen und Lebenszyklus.

Was hat sich gegenüber den AX-Beispielen vom September geändert?

Übernimm ein altes Manifest mit vier Ressourcen nicht unverändert. Diese Fassung ersetzt das bisherige Gateway-Beispiel und beschreibt den aktuellen Ausführungsvertrag. Lege zusammenpassende Versionen von CLI, Control Plane und Runner fest, bevor du migrierst.

Das Schema ist die bessere Konfigurationsreferenz als ein verbliebener Satz über „vier Arten“ in der Manifest-Dokumentation. Auch die frühere Erklärung zum reservierten Task-Policy-Feld aus unserem September-Review passt nicht mehr zum aktuellen Schema. Aktuelles AX-API-Schema prüfen.

Ist AX wirklich Kubernetes für KI-Agenten?

Der Vergleich hilft beim Verständnis. AX ersetzt Kubernetes aber nicht. Der Agent Harness steuert Überlegungen und Werkzeugaufrufe. AX verwaltet Task-Definitionen und Lebenszyklen. Agent Substrate übernimmt die Sandbox-Ausführung, während Kubernetes die darunterliegenden Worker verwaltet.

Der aktuelle AX-Server gleicht den Zustand direkt mit Substrate ab, verwendet verteilte Sperren und speichert Ressourcen in Redis. Nicht jeder kurzlebige Task wird als Kubernetes Custom Resource angelegt. Das Design beschreibt Tasks ausdrücklich als unveränderlich. Aktualisiertes Design der AX-Control-Plane.

Die Milliarden-Formulierung im README ist ein Architekturziel. Sie belegt nicht, dass dein Cluster Milliarden gleichzeitig aktive Agenten betreiben kann. Plane anhand aktiver Parallelität, Zustandsgröße, Modelllatenz und Lastspitzen. Die Denk- und Werkzeugschleife behandelt unser Leitfaden zu Agent Harness Engineering.

Welcher Zustand überlebt AX Suspend und Resume?

Laut dokumentiertem AX-Runner bleiben Workspace-Dateien erhalten. Der Befehl startet in einem neuen Prozess. Stop und Suspend senden SIGTERM an PID 1. Der Runner leitet das Signal weiter, damit der Befehl seinen Zustand sichern kann. Dieser geordnete Ablauf ist nicht dasselbe wie ein Rechnerausfall mitten im Aufruf. Der geprüfte Runner-Vertrag beschreibt Persistenz und Herunterfahren.

Gestalte Wiederholungen idempotent: Eine Aktion erhält eine dauerhaft gespeicherte Kennung, damit derselbe Aufruf nicht unbemerkt denselben Effekt erneut auslöst. Melde außerdem Erfolg oder Fehler ausdrücklich. Ready, WorkspaceReady und ein gesunder Runner ersetzen kein abgenommenes Ergebnis.

Wichtig ist die Trennung der Schichten. Agent Substrate beschreibt vollständige Snapshots für RAM und Dateisystem und zeigt rund 250 Actors auf acht Pods. Das ersetzt nicht den spezifischen AX-Runner-Vertrag. Prüfe genau die Kombination aus Runner und Backend, die du einsetzen willst. Substrate-Snapshots, Demonstration und Deployment-Dokumentation.

Bedeutet Wiederaufnahme unter einer Sekunde null Kaltstarts und null Leerlaufkosten?

Nein. Eine schnelle Aktivierung ist eine Latenzaussage, keine Garantie über die gesamte Rechnung. Das Substrate-README nennt Wiederaufnahmen unter 500 ms und mehr als 500 Suspend/Resume-Aktivierungen pro Sekunde. Das sind Projektangaben, kein Wavect-Benchmark und kein Versprechen für jeden AX-Workload.

Ein erster Start, fehlende Worker-Kapazität, große Snapshots, Dependency-Installationen oder langsame Modellaufrufe können nutzbare Ergebnisse trotzdem verzögern. Miss sowohl die Zeit bis zur Bereitschaft als auch bis zum ersten brauchbaren Ergebnis, einschließlich p95-Latenz.

Freigegebene CPU und RAM eines pausierten Actors können die Flottenauslastung verbessern. Worker-Pools, Redis, Snapshot-Speicher, Netzwerk und Betrieb werden dadurch nicht kostenlos. Bereits angenommene Modellanfragen können weiter Kosten verursachen, während der lokale Agent wartet. Infrastrukturleerlauf und Tokenverbrauch sind getrennte Kostenpositionen.

Unterscheide außerdem Befehle von Automatisierung. AX dokumentiert ax suspend und ax resume. Automatische Leerlauferkennung und Suspend stehen weiterhin auf der Roadmap, ebenso Token-/Timeout-Budgets und Freigaberegeln. Ein vorhandener Befehl belegt keine aktive Leerlaufautomatik. Prüfe, welche AX-Funktionen noch auf der Roadmap stehen.

Wie viel können bessere Neustarts tatsächlich sparen?

Miss die nach einer Unterbrechung wiederholte Arbeit, nicht den gesamten ursprünglichen Auftrag. Ein brauchbarer Checkpoint kann Wiederholungen reduzieren. Bereits verbrauchte Inferenz wird dadurch nicht erstattet. Eine Suspend-Funktion beweist noch keine Wiederherstellung nach einem Absturz.

Ein Rechenbeispiel: 1.000 Aufträge pro Monat, davon 10 % mit genau einer Unterbrechung. Wiederholt jeder betroffene Auftrag Modell- und Werkzeugarbeit im Wert von 30 US-Dollar, entstehen 3.000 US-Dollar Wiederholungskosten. Senkt geprüfte Wiederherstellung diesen Anteil auf 3 US-Dollar, bleiben 300 US-Dollar. Das sind 2.700 US-Dollar vermiedene Wiederholungen, keine garantierte Ersparnis durch die Installation von AX.

Kosten zusätzliche Laufzeit, Snapshots und Betrieb zusammen 600 US-Dollar, bleiben im Szenario 2.100 US-Dollar vor weiteren veränderten Kosten. Alle Werte sind illustrative USD-Annahmen, keine Anbieterpreise oder Kundenergebnisse. Die Verbesserung muss auch bei abruptem Ausfall bestehen, nicht nur nach geordnetem Pausieren.

Die vollständige Methode mit menschlicher Prüfung und abgenommenen Ergebnissen findest du im Leitfaden zu Kosten pro Agentenaktion. Hier geht es gezielt um Wiederholungskosten und Wiederherstellung bei AX.

Wie prüfst du AX-Dateiwiederherstellung ohne Modell-Token?

Beginne mit einem Wegwerf-Workspace und einem harmlosen, wartenden Prozess. Das Beispiel verwendet aktuelle Manifest-Felder. Es enthält keinen Modellaufruf, keine Repository-Zugangsdaten und keinen zielbasierten Bootstrap. Infrastrukturressourcen verbraucht es trotzdem. Vergleiche das Beispiel mit der aktuellen Manifest-Referenz.

Voraussetzung sind eine installierte, kompatible AX/Substrate-Kombination, die CLI und berechtigter Clusterzugriff. Speichere das Beispiel als task.yaml. debug: true ist für diesen isolierten Diagnosetask bewusst gesetzt: SSH erlaubt Ausführung und Dateizugriff. Das ist keine öffentliche oder produktive Standardeinstellung.

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: recovery-lab
spec:
  files:
    - path: README.txt
      content: "Disposable recovery test. No model calls."
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: recovery-lab-001
spec:
  workspaces:
    - name: recovery-lab
      path: /workspace/recovery-lab
  command: ["python3", "-c", "import time; time.sleep(3600)"]
  debug: true

Wende das Manifest an und warte auf Ready. Beende den laufenden Watch mit Strg+C. Das beendet die Beobachtung, nicht den Task.

ax apply -f task.yaml
ax watch task recovery-lab-001

Schreibe den Marker erst nach dem Start. Pausiere den Task und setze ihn fort. Der Task-Befehl legt diese Datei nicht neu an. Das spätere Lesen prüft damit Persistenz statt wiederholter Initialisierung.

ax ssh recovery-lab-001 -- sh -c 'printf "%s\n" "checkpoint-before-suspend" > /workspace/recovery-lab/recovery-marker.txt'
ax suspend task recovery-lab-001
ax resume task recovery-lab-001
ax watch task recovery-lab-001

Warte erneut auf Ready, beende den Watch mit Strg+C und lies den Marker:

ax ssh recovery-lab-001 -- cat /workspace/recovery-lab/recovery-marker.txt

Erwartet wird checkpoint-before-suspend. Ein erfolgreicher Test zeigt nur, dass diese Datei einen geordneten Suspend/Resume-Zyklus überlebt hat. RAM-Wiederherstellung, dauerhafte Sicherung bei Abstürzen und sichere Wiederholungen externer Aktionen sind damit nicht bewiesen. Wir haben diesen Clustertest hier nicht ausgeführt.

Sichere benötigte Nachweise. Lösche anschließend nur die oben angelegten Wegwerf-Ressourcen. Diese Befehle entfernen den Testtask und seine Workspace-Definition:

ax delete task recovery-lab-001
ax delete workspace recovery-lab

Wo liegen Netzwerkregeln nach dem Wegfall von AX Gateway?

Verwende das alte AX-Gateway-Beispiel nicht weiter. Das geprüfte Task-Schema enthält keine gateway-Bindung. Beschränke ausgehende Verbindungen in der tatsächlichen Laufzeit- beziehungsweise Netzwerkschicht und prüfe, ob die Regeln den Actor des Tasks erfassen.

Die aktuelle Substrate-Egress-Dokumentation beschreibt HTTP(S) mit Policies, eingeschränkte DNS-Auflösung sowie gesperrte WebSocket-, Forward-Proxy-CONNECT- und andere TCP-Verbindungen. Das ist ein Protokollvertrag, den du mit der installierten Version abgleichen musst, kein Ersatzfeld im AX-YAML. Das wird relevant, wenn ein SDK oder MCP-Transport eine nicht erlaubte Verbindungsart voraussetzt. Ausgehende Netzwerkregeln von Substrate prüfen.

Teste erlaubte Modell- und Tool-Endpunkte, gesperrte Ziele, Weiterleitungen, direkte Anbieterzugriffe und Rechteentzug. Erlaubte Server brauchen weiterhin Autorisierung pro Anfrage. Ein erlaubter Hostname bedeutet keinen Zugriff auf alle dahinterliegenden Mandanten oder Dokumente. Das sind vorgeschlagene Prüfungen, keine von uns reproduzierten Schwachstellen. Die Sicherheitscheckliste für Agenten-Sandboxes behandelt den umfassenderen Schutzbereich.

Stoppt AX automatisch eine ausufernde Tokenrechnung?

Das geprüfte Task-Schema enthält kein kumuliertes Geld- oder Tokenlimit. UsageStats und PendingApproval belegen keine Budgetdurchsetzung. CPU-Limits begrenzen ebenfalls keine Rechnung eines entfernten Modells.

Nutze eine unabhängig kontrollierte Zulassungsschicht vor Modellaufrufen. Ordne Vorbereitung, Teilaufträge und Wiederholungen derselben dauerhaften Auftragskennung zu. Reserviere Budget vor parallelen Aufrufen, gleiche den Verbrauch anschließend ab und lasse am Limit keine neuen Aufrufe mehr zu. Bereits angenommene Anfragen können weiter kosten. Definiere deshalb eine begrenzte Überschreitung statt eines angeblich verzögerungsfreien Null-Overrun-Stopps.

Die Instanz für Rechteentzug und Anfragesperren gehört außerhalb des vom Agenten beschreibbaren Workspaces. Ein Prompt mit der Bitte, das Budget einzuhalten, ist keine Kostenkontrolle.

Lässt sich AX ohne Google Cloud selbst hosten?

Es gibt einen Entwicklungsweg ohne GCP. Produktive Portabilität musst du gesondert prüfen. Substrate dokumentiert lokale kind- und GKE-Quickstarts. AX benötigt eine erreichbare Substrate-Control-API, die eigene Control Plane samt Redis und passende Runner-Images. Lokale Ausführung kann weiterhin entfernte Inferenz verwenden.

Das aktuelle Substrate-README beschreibt einen Stand vor Version 1.0 ohne Garantie für Rückwärtskompatibilität. AX warnt vor großen inkompatiblen Änderungen. Auf seiner Roadmap steht weiterhin die Migration zur Substrate-Actor-API. Wähle ein geprüftes Versionspaar, statt automatisch die jeweils neueste Revision beider Projekte zu kombinieren.

Braucht jeder Task Antigravity?

Nein. Der dokumentierte Standard-Runner nutzt Antigravity für Workspace-Bindungen mit einem goal. Dieser Weg benötigt GEMINI_API_KEY und hat standardmäßig zehn Minuten Bootstrap-Zeitlimit, anpassbar über AX_BOOTSTRAP_TIMEOUT. Eine vorbereitete Umgebung ohne Goal umgeht diesen konkreten Bootstrap-Pfad. Dieselbe Dokumentation legt Metadaten auf Loopback und verweist auf AX_METADATA_URL. Aktueller Startablauf und Metadatenvertrag der Sandbox.

Was gilt für Pi oder einen eigenen Agent Harness?

Behandle das als zu prüfende Integration, nicht als fertigen AX-Adapter, den dieses Review bestätigt. Ein eigenes Image muss /usr/local/bin/ax-task-runner bereitstellen, AX_TASK_YAML und AX_WORKSPACES_YAML lesen, dauerhafte Workspaces vorbereiten, Bereitschaft melden und das Herunterfahren überwachen. Prüfe Sitzungsablage und Wiederaufnahme des Harness separat.

Das Repository zu besitzen ist nur ein Teil der Kontrolle über deine KI. Du solltest Ausführung prüfen, Zustand exportieren, Inferenzanbieter wählen, Rechte entziehen und das Deployment verlassen können. Der Cloud-Standort beantwortet diese Fragen nicht allein.

Was muss ein AX-Pilot vor dem Produktivbetrieb beweisen?

Starte mit synthetischen Aufgaben und Wegwerf-Systemen. Das sind unsere vorgeschlagenen Abnahmekriterien, keine von AX in unserer Umgebung bestandenen Tests.

Dokumentiere AX-/Substrate-Revisionen, Runner-Digest, Modellroute, Policy-Konfiguration und Ergebnisse pro Durchlauf. Wähle AX, wenn gemessene Vorteile bei Auslastung und Wiederherstellung den Plattformaufwand rechtfertigen. Eine kleine Flotte mit kurzen, günstigen Aufträgen benötigt diese zusätzliche Infrastruktur möglicherweise noch nicht.

Wavects KI-Engineering-Leistungen umfassen Integration und Produktionshärtung. Unsere Twinsoft-AI-Fallstudie zeigt separate Umsetzungserfahrung, kein AX-Referenzdeployment. Nutze die QA-Checkliste vor dem Launch für Abnahmenachweise oder besprich deine Agenten-Neustartkosten und Laufzeitanforderungen mit uns.