Google AX Agent Executor: Budgets und Selbsthosting

Eine Sandbox kann einen Agenten einsperren, ohne seine Rechnung zu begrenzen. Genau diesen Unterschied sollte man vor dem Einsatz von Googles AX, dem Agent Executor, verstehen. Ein vorbereiteter Arbeitsbereich und begrenzter Netzwerkzugriff sind wertvoll. Nachzuweisen, dass der Agent nicht zu viel ausgibt, eine gefährliche Aktion wiederholt oder seinen Zustand unzugänglich macht, ist eine andere technische Aufgabe.

AX ist ein unter Apache 2.0 lizenziertes Orchestrierungsprojekt in Googles GitHub-Organisation. Seine aktuelle Schnittstelle verwendet vier Ressourcentypen: Task, Workspace, Gateway und Model. Das Repository warnt ausdrücklich vor möglichen grundlegenden Änderungen vor einer stabilen Version. Zum AX-Repository und zum Hinweis auf den Entwicklungsstand.

Quellen geprüft am 20. September 2026, AX-Stand d8ed0fe38bce. Dies ist eine Quellen- und Architekturanalyse, kein Deployment-Test oder Durchsatz-Benchmark. Die konkrete Frage lautet: Was musst du prüfen, damit AX-Agenten unter deiner betrieblichen Kontrolle laufen?

Was steuern die vier deklarativen AX-Bausteine tatsächlich?

AX trennt die Ausführungsumgebung von den Entscheidungen des Agenten. Ein Task kann einen Agenten, eine delegierte Teilaufgabe oder ein anderes Programm ausführen. Ein Workspace beschreibt die Startumgebung, ein Gateway den Netzwerkzugriff und eine Model-Ressource die zentrale Anbieterkonfiguration.

So beschreibt es die Dokumentation der AX-Grundkonzepte. Insbesondere ist Model eine benannte Konfiguration und kein neues Sprachmodell. AX-eigene Komponenten können sie nutzen. Ein beliebiges Programm innerhalb eines Tasks benötigt weiterhin eine passende Integration.

Ist AX ein Agenten-Framework, eine Sandbox oder ein Kubernetes-Ersatz?

AX ist die Orchestrierungsschicht über Agent Substrate, kein Ersatz für die Entscheidungsschleife deines Agenten. API und Controller verwalten Ressourcen. Agent Substrate stellt den darunterliegenden Ausführungslebenszyklus bereit. Kubernetes bleibt Teil der Infrastruktur.

Das an Kubernetes erinnernde YAML kann täuschen: Laut Architektur speichert AX Ressourcenzustände in Redis und verteilt die Abgleicharbeit über Redis Streams. Nicht jeder kurzlebige Task wird als Kubernetes-Custom-Resource gespeichert. Zusätzliche Controller-Replikate ermöglichen horizontale Skalierung. Zur Architektur der Steuerungsebene.

Das ist ein Architekturansatz für viele Aufgaben, kein Nachweis dafür, dass dein Cluster Milliarden gleichzeitig aktiver Agenten bewältigt. Kapazität hängt weiterhin von Aufgabenprofil, Worker-Ressourcen, Speicher, Modelllatenz und betrieblichen Grenzen ab. Behandle die Skalierungsziele des Projekts als Entwicklungsziel, bis ein repräsentativer Benchmark deine tatsächlichen Grenzen belegt.

Unser Leitfaden zum Agent Harness Engineering behandelt Entscheidungsschleifen, Werkzeugaufrufe und Rückmeldungen rund um ein Modell. Dieser Beitrag konzentriert sich auf die Ausführung und die Kontrollgrenzen von AX.

Wie begrenzt du ausgehende Netzwerkverbindungen in Google AX?

Verknüpfe den Task mit einem Gateway, das konkrete Ziele erlaubt, und teste anschließend die tatsächliche Netzwerkgrenze. Das dokumentierte Beispiel enthält host: "*" auf Port 443. Das bedeutet weitreichenden HTTPS-Zugriff, keine auf deine Modell- und Git-Server begrenzte Produktionskonfiguration. Zu den aktuellen Manifest-Beispielen.

Das folgende Gateway veranschaulicht die Konfiguration und ist kein vollständiges Deployment. Ersetze den Beispiel-Hostnamen durch einen von dir kontrollierten Endpunkt, den die Sandbox auflösen und erreichen kann. Die Infrastruktur muss separat bereitgestellt werden.

apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
  name: research-egress
spec:
  egress:
    allowlist:
      hosts:
        - host: llm-gateway.internal.example
          port: 443

Ergänze die folgende Referenz im bestehenden spec des Tasks. Eine ungenutzte Gateway-Ressource in der Steuerungsebene schränkt diesen Task nicht ein.

gateway:
  name: research-egress
debug: false

Unsere Empfehlung für ein Deployment: GatewayReady als Voraussetzung prüfen, gesperrte Ziele tatsächlich testen und debug: false beibehalten, solange keine kontrollierte Fehlersuche erforderlich ist. Prüfe Weiterleitungen, direkte Anbieterzugriffe, interne Metadaten-Endpunkte und alternative Netzwerkpfade. Das sind Abnahmetests, keine von uns in AX nachgewiesenen Schwachstellen.

Ein erlaubter Hostname bleibt eine große Vertrauensgrenze. Ein freigegebener Tool-Server kann mehrere Mandanten bedienen oder selbst weitere Verbindungen aufbauen. Die Autorisierung einzelner Anfragen gehört deshalb weiterhin auf diesen Server; auch nachgelagerte Ziele müssen geprüft werden. Für die umfassendere Prüfung nutze unsere Sicherheitscheckliste für Agenten-Sandboxes.

Stoppt Google AX automatisch ausufernde Tokenkosten?

Gehe nicht davon aus, dass die aktuelle Task-API eine kumulierte Token- oder Kostengrenze durchsetzt. Im geprüften Schema ist Feld 9 von TaskSpec ausdrücklich reserviert. Es hieß zuvor policies, enthielt Budget- und Freigabekonfiguration und wurde laut Kommentar vorerst entfernt. Tokenzähler in UsageStats und der Statustyp PendingApproval existieren weiterhin. Datentypen und Zähler belegen jedoch noch keinen wirksamen Kontrollmechanismus. Zum geprüften AX-API-Schema mit festem Commit.

CPU- und Speicherlimits begrenzen lokale Rechenressourcen. Sie begrenzen nicht, wie viele kostenpflichtige Modellanfragen eine ressourcensparende Endlosschleife senden kann. Auch ein Ausgabelimit pro Modellantwort deckelt nicht die Gesamtkosten von Wiederholungen, parallelen Teilaufgaben und weiteren Aufrufen. Ebenso darfst du aus einem freigabebezogenen Statusfeld allein keinen funktionierenden fachlichen Genehmigungsprozess ableiten.

Google Cloud unterscheidet außerdem zwischen reinen Benachrichtigungsbudgets und Ausgabenkontrollen: Ein alerts-only-Budget beendet Nutzung und Abrechnung nicht automatisch. Die Dokumentation verweist separat auf Ausgabenlimits in einer Vorschauversion für unterstützte Dienste. Beides belegt kein auftragsbezogenes Limit für sämtliche externen Modelle, die dein Agent erreichen kann. Zur Unterscheidung in der Cloud-Billing-Dokumentation.

Das Budget muss außerhalb der Schreibrechte des Agenten liegen

Wir empfehlen einen vom Betreiber kontrollierten Modell-Proxy mit gemeinsamem Budgetkonto für den Hauptauftrag und alle daraus entstehenden Teilaufgaben. Reserviere vor jeder Anfrage deren begrenzte Maximalkosten atomar. Gleiche danach den tatsächlichen Verbrauch ab, berücksichtige Wiederholungen und Parallelität und lehne neue Anfragen bei unzureichendem Restbudget ab. Zugangsdaten für die Durchsetzung und das Budgetkonto gehören nicht in die vom Agenten veränderbare Umgebung.

Ergänze eine maximale Laufzeit, Grenzen für Wiederholungen, Arbeitsschritte und parallele Teilaufgaben sowie eine Erkennung wiederholter Aktionen. An der Grenze werden neue Modellaufrufe blockiert und Abbruch oder Suspendierung ausgelöst. Bereits zugelassene Anfragen können weiter Kosten erzeugen. Definiere und teste deshalb eine maximale Überschreitung, statt einen sofortigen kostenfreien Stopp zu versprechen. Berücksichtige auch den Agenten zur Workspace-Vorbereitung, nicht nur den eigentlichen Task-Befehl.

Die übergeordnete Wirtschaftlichkeit behandelt unser Beitrag zu Kosten pro KI-Agenten-Aktion. Hier geht es gezielt um die Durchsetzung von Grenzen rund um AX.

Welcher Zustand bleibt bei AX nach Suspend und Resume erhalten?

Der geprüfte AX-Runner-Vertrag beschreibt einen wiederhergestellten Workspace mit einem neuen Prozessbaum. /workspace ist das dauerhafte Verzeichnis; beim Fortsetzen wird es in einen neuen Container eingespielt. Daraus folgt keine Zusage, dass Python-Objekte, offene Verbindungen oder noch nicht gespeicherte Speicherinhalte unverändert weiterleben. Zum Lebenszyklus und Austauschvertrag des Runners.

Diese Aussage betrifft die dokumentierte Runner-Integration von AX, nicht die maximalen Snapshot-Fähigkeiten jedes Agent-Substrate-Backends. Entscheidend ist die Abnahme auf der Ebene, die deine Anwendung tatsächlich verwendet.

Speichere Gesprächs- oder Sitzungsstände, Kennungen bereits abgeschlossener Operationen und Wiederanlaufinformationen im dauerhaften Verzeichnis. Nutze zum Fortsetzen den vorgesehenen Sitzungsmechanismus des Agenten. Ein Dateisystem-Snapshot macht eine bereits verschickte E-Mail oder angeforderte Zahlung nicht rückgängig. Externe Schreibvorgänge benötigen Idempotenzschlüssel und einen dauerhaft gespeicherten Abschlussnachweis.

Eine bereite Sandbox ist noch kein erfolgreich erledigter Auftrag

Laut demselben Runner-Vertrag bleibt der Runner nach dem Ende des Befehls aktiv; die Steuerungsebene liest dessen Exit-Status derzeit nicht zurück. Überwache ein ausdrückliches Abschlussereignis oder Ergebnisartefakt statt ausschließlich Running, Ready oder einen antwortenden Health-Endpunkt. Teste sowohl einen erfolgreichen als auch einen fehlgeschlagenen Befehl.

Lässt sich Google AX ohne GCP selbst hosten?

Die dokumentierten Wege sind nicht ausschließlich an GCP gebunden. Portierbar bedeutet aber nicht sofort einsatzbereit. Der AX-Schnellstart benötigt Kubernetes, eine Container-Registry, Redis und eine erreichbare Agent-Substrate-Control-API. Agent Substrate dokumentiert sowohl eine lokale Entwicklungsumgebung mit kind als auch einen GKE-Weg mit Google-Cloud-Ressourcen. Das Projekt bezeichnet sich außerdem als frühe Entwicklung, noch nicht produktionsreif und nicht als offiziell unterstütztes Google-Produkt. Zu den lokalen und GKE-Installationswegen von Agent Substrate.

Der lokale Substrate-Schnellstart belegt einen Entwicklungsweg ohne GCP für die zugrunde liegende Laufzeit. Er beweist nicht, dass AX, dein Speicher-Backend und deine Sicherheitskonfiguration gemeinsam ein vollständiges On-Premises-Deployment bestanden haben. Eine lokale Ausführungsebene macht außerdem entfernte Modellinferenz nicht lokal.

Das ist unsere betriebliche Definition von „die eigene KI kontrollieren“. Ein Cloud-Deployment kann sinnvolle Kontrolle ermöglichen. Selbsthosting kann weiterhin von externen Modellen, Registries oder Zugangsdiensten abhängen. Entscheide diesen Zielkonflikt bewusst, statt den Betriebsort mit einem Bedrohungsmodell zu verwechseln.

Wie stark ist AX an Antigravity gebunden?

Die konkrete Abhängigkeit liegt in der zielbasierten Workspace-Vorbereitung. Der Standard-Runner übergibt ein Workspace-Ziel an einen Antigravity-Agenten und benötigt dafür GEMINI_API_KEY. Die dokumentierte Vorbereitungsfrist beträgt standardmäßig zehn Minuten und lässt sich über AX_BOOTSTRAP_TIMEOUT ändern. Diese Frist ist kein Budget für die gesamte Laufzeit des Auftrags. Zum dokumentierten Startablauf der Sandbox.

Das ist hilfreicher als die pauschale Behauptung, das gesamte Projekt sei „mit Antigravity programmiert“. Die Laufzeitdokumentation belegt den Einsatz während der Vorbereitung, nicht die Entstehung jeder Quelldatei.

Für mehr Kontrolle kannst du eine vorgebaute Umgebung ohne zielbasierten Bootstrap prüfen oder einen kompatiblen eigenen Runner implementieren. AX erwartet dessen ausführbare Datei unter /usr/local/bin/ax-task-runner. Ein beliebiges Agenten-Image einzutragen genügt nicht. Prüfe vor dem Austausch Readiness-Endpunkte, Signalweitergabe und dauerhafte Zustandsspeicherung anhand des Runner-Vertrags.

Kann ein Pi-Coding-Agent das AX-Ausführungsmodell nutzen?

Pi dokumentiert interaktive Ausführung, Print/JSON, RPC und SDK-Modi. Das sind mögliche Integrationsschnittstellen, aber kein Nachweis eines sofort nutzbaren AX-Adapters. Zur Dokumentation des Pi-Coding-Harness.

Ein sinnvoller Versuch wäre, Pi hinter einem AX-kompatiblen Runner zu paketieren, über spec.command zu starten, Modellverkehr über die externe Budgetkontrolle zu führen und wiederaufnehmbare Sitzungen unter /workspace abzulegen. Das ist ein Integrationsvorschlag, keine von uns ausgerollte Konfiguration oder hier bestätigte offizielle Integration.

Du kannst diese Trennung auch ohne AX übernehmen: Workspace deklarieren, Ausführung isolieren, Netzwerkzugriff außerhalb des Prozesses durchsetzen und Modellzugänge sowie Budgetregeln beim Betreiber belassen. Entscheidend ist die Kontrollgrenze, nicht das Kopieren einer cloudspezifischen Implementierung.

Was muss ein AX-Pilot vor dem Zugriff auf echte Zugangsdaten beweisen?

Beginne mit einem entbehrlichen Repository, synthetischen Daten und einem Modellzugang mit minimalen Rechten. Die folgenden Punkte sind unsere Abnahmekriterien, keine Behauptung, das Projekt erfülle sie bereits.

Dokumentiere die AX- und Substrate-Revisionen, den Runner-Image-Digest, den aktiven Modellpfad, die Gateway-Regeln und die beobachteten Ergebnisse. Halte während der API-Änderungen einen Rückweg bereit. Ein kleiner bestandener Versuch ist nützlicher als ein ungeprüftes Versprechen über eine ganze Agentenflotte.

Wavects Leistungen für KI-Entwicklung umfassen Implementierung und Produktionshärtung. Die Twinsoft-AI-Fallstudie beschreibt separate Umsetzungserfahrung, kein AX-Referenzdeployment. Mit unserer QA-Checkliste vor dem Launch machst du aus dem Piloten belastbare Abnahmenachweise. Alternativ besprechen wir deine Anforderungen an Agentenlaufzeit und Kontrolle.