Zum Hauptinhalt springen

AX (Agent Executor): Googles offene Agenten-Runtime, erklärt für Entwickler (2026)

Experte
What you'll learn
  • AX korrekt in Googles Stack einordnen: Kubernetes, Agent Sandbox, Agent Substrate, AX, dann dein Harness
  • Die vier AX-Ressourcen (Task, Workspace, Gateway, Model) lesen und wissen, was jede davon bringt
  • Erklären, was ein AX-Suspend/Resume wirklich überlebt, was nicht, und was dein Runner-Image dagegen tun muss
  • Einen ersten Task von Anfang bis Ende mit ax apply, ax watch und ax ssh ausführen und die drei Debugging-Fallen kennen
  • Entscheiden, wann eine selbst gehostete Runtime wie AX besser ist als Claude Managed Agents oder die OpenAI Agents API – und wann nicht

In der Nacht des 20. September 2026 kletterte AX: Googles offener agentischer Orchestrator mit 507 Punkten und 222 Kommentaren an die Spitze von Hacker News. In den meisten dieser Kommentare fragten Leute, wofür das Ding eigentlich gut ist. Eine faire Frage, denn das Projekt ist seit dem 20. Mai 2026 (v0.1.0) öffentlich und hat seither zweimal die Gestalt gewechselt – die meisten Blogposts, die du findest, beschreiben also eine CLI, die es nicht mehr gibt.

Hier die Kurzfassung. AX ist kein Modell, kein Agenten-Framework und kein gehosteter Dienst. Es ist eine Control Plane im Kubernetes-Stil mit einer CLI in kubectl-Form, die einen deklarierten Agenten-Task entgegennimmt, ihm eine Sandbox gibt, seine Repos klont, seine MCP-Server und Skills verdrahtet, sein Netzwerk einzäunt und ihn zu einem Snapshot einfrieren und später auf jedem freien Worker wieder auftauen kann. Es sitzt unter dem Harness, das du ohnehin schon benutzt – egal ob Claude Code, Googles ADK, LangChain oder eine selbst geschriebene Python-Schleife.

Der Stack von unten nach oben​

Die Google-Ankündigungen benutzen vier Namen, die leicht zu verwechseln sind. Es sind vier Schichten, und AX ist die oberste.

SchichtWas es istStatus (Sep. 2026)Von Google veröffentlichte Zahlen
Kubernetes / GKEDer Cluster——
Agent Sandbox (kubernetes-sigs/agent-sandbox)Eine Sandbox-CRD: gVisor-isolierte Pods (Kata einsteckbar), Warm Pools, Pod-SnapshotsGA auf GKE seit 21. Mai 2026300 Sandbox-Allokationen/s pro Cluster; Start unter einer Sekunde, 90 % innerhalb von 200 ms
Agent Substrate (agent-substrate/substrate)Eine minimale Control Plane, die viele untätige Actors auf wenige warme Worker multiplext, indem sie RAM + Dateien in einen Object Store snapshottetOpen Source, früh, „kein offiziell unterstütztes Google-Produkt“; verwaltete Variante auf GKE in Evaluierung~250 zustandsbehaftete Actors auf 8 Pods; „10x höhere Dichte“ als normale Container; Aktivierung unter einer Sekunde
AX (google/ax)Deklarative Tasks/Workspaces/Gateways/Models + CLI oben auf Substratev0.3.0, ax.io/v1alpha1, Apache-2.0, 4,3k Sterne„Milliarden Tasks pro Cluster“ (Marketing-Behauptung, kein Benchmark)
Dein HarnessClaude Code, ADK, LangChain, A2A-Agenten, deine eigene Schleife——

Zwei Dinge verschweigt die Tabelle. Erstens: In Substrate steckt das interessante Engineering (die Snapshot- und Teleport-Maschinerie); AX ist die ergonomische Schicht. Zweitens lebt Substrate in einer eigenen GitHub-Organisation, nicht unter google/ – was mehrere HN-Kommentatoren als Signal dafür werteten, wie offiziell das Ganze ist. Betrachte es als ernsthaftes, aber Pre-1.0-Open-Source-Projekt eines Google-Teams, nicht als Produkt mit SLA.

Die vier Primitive​

Alles in AX ist eine YAML-Ressource in einem atespace (Substrates Mandanteneinheit; default, sofern du nichts anderes angibst). Du wendest sie mit ax apply -f genauso an wie mit kubectl.

Task: die Einheit isolierter Ausführung​

apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: fix-flaky-test
spec:
  image: "ghcr.io/my-org/my-agent-image"
  command: ["my-agent", "--goal", "fix the flaky test"]
  env:
    - name: ENVIRONMENT
      value: "staging"
  resources:
    requests: { cpu: "500m", memory: "1Gi" }
    limits:   { cpu: "2",    memory: "4Gi" }
  workspaces:
    - name: golang
      path: "/workspace"
      goal: "Ensure the Go toolchain is available and built from source"
  gateway:
    name: default-gateway
  debug: true

Ein Task ist bewusst klein gehalten. Die Konzept-Doku beschreibt Agenten, die über ihre Lebensdauer viele Tasks erzeugen, statt in einem einzigen langen Prozess zu leben. Drei Felder sind wichtiger, als sie aussehen:

  • workspaces[].goal ist eine Beschreibung in einfachem Deutsch (bzw. Englisch) der Umgebung, die der Task braucht. Das „generative“ Setup von AX versucht, den Workspace aus diesem Satz heraus zu vervollständigen (Toolchain installieren, Abhängigkeiten holen). Es ist die einzige Stelle, an der ein Modell im Spiel ist, bevor dein Agent startet.
  • debug: true ist der einzige Weg, per ax ssh in die Sandbox zu kommen. Ohne dieses Flag sind die Gast-Dienste nicht exponiert und die CLI verweigert die Verbindung.
  • gateway ist im Schema optional, aber wenn du es weglässt, verlässt du dich auf die Standard-Egress-Policy des Substrats. Deklariere eins.

Workspace: git + MCP + Skills, materialisiert bevor der Agent startet​

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
    - name: origin
      repo: "https://github.com/golang/go.git"
      branch: "my-fix"
  mcp:
    registries:
      - provider: google
        query: "mcp.tags:build"
    servers:
      - name: git-tools
        endpoint: "http://git-mcp.default.svc.cluster.local:8080"
  skills:
    registries:
      - provider: google
        query: "skills.tags:nodejs"
    path: "/.agents/skills"

Das ist die Ressource, die AX zu mehr macht als „Kubernetes-Jobs mit Sandbox“. Ein Workspace klont Repositories vorab, löst MCP-Server auf (über einen expliziten Endpoint oder über eine Registry-Abfrage) und legt Skill-Pakete in einem Pfad ab. Beachte den Standard-Skills-Pfad: /.agents/skills ist dieselbe Verzeichniskonvention, die der harness-übergreifende SKILL.md-Standard für Codex, Cursor und Gemini CLI verwendet – ein Workspace kann also dieselben Skills an jedes Harness übergeben, das im Task läuft.

Gateway: Listener rein, Allowlist raus​

apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
  name: default-gateway
spec:
  listeners:
    - name: http
      port: 8080
      protocol: HTTP
  egress:
    allowlist:
      hosts:
        - host: "api.anthropic.com"
          port: 443

Das Referenz-Manifest kommt mit host: "*" auf 443 – also einer Alles-erlauben-Policy. Ändere das. Egress-Allowlists sind die mit Abstand wirksamste Kontrolle gegen die Exfiltrationsmuster aus unseren Seiten zu Prompt Injection und was dein Agent hochlädt, und AX gibt dir einen deklarativen Ort dafür. Listener sind der Weg, wie ein Task einen Port exponiert (für einen A2A-Endpoint, einen Dev-Server, eine Debug-UI); ax tunnel leitet sie auf deinen Laptop weiter.

Model: Provider + Modell-ID + ein Kubernetes-Secret​

apiVersion: ax.io/v1alpha1
kind: Model
metadata:
  name: claude-model
spec:
  provider: anthropic
  model: claude-opus-5
  secretKey:
    name: anthropic-api-secret
    key: ANTHROPIC_API_KEY
  parameters:
    maxTokens: 16000
    temperature: 0.9

Die Referenzdoku zeigt die Provider google und anthropic. Die Zugangsdaten sind eine Referenz auf ein Kubernetes-Secret, das Manifest enthält den Schlüssel also nie und der Schlüssel wird dort rotiert, wo du ohnehin schon Secrets rotierst. AX ist nicht Gemini-exklusiv; die Runner-Doku erwähnt allerdings, dass GEMINI_API_KEY automatisch injiziert wird, wenn der atespace Gemini-Zugangsdaten hat – die eine Stelle, an der Googles eigenes Modell eine Abkürzung bekommt.

Was innerhalb eines Tasks tatsächlich passiert​

Das ist der Teil, den kein Launch-Post abdeckt, und hier verlierst du einen Nachmittag, wenn du ihn überspringst. Aus docs/runner.md:

  1. Der Entrypoint ist fix. Egal welches spec.image du lieferst, der Controller startet den Container mit /usr/local/bin/ax-task-runner als PID 1. Dein Image muss unter diesem Pfad eine ausführbare Datei enthalten (ein Symlink genügt). Das veröffentlichte Base-Image ist gcr.io/ax-substrate/ate-images/ax-task-runner, und es zu erweitern ist der normale Weg.
  2. Dein Kommando kommt über die Umgebung an, nicht über argv. Der Runner erhält AX_TASK_YAML (den ganzen Task inklusive Status) und AX_WORKSPACES_YAML (jeden gebundenen Workspace als Multi-Dokument-YAML), parst spec.command aus dem Task heraus und startet es als Kindprozess mit dem ersten Workspace als Arbeitsverzeichnis. Außerdem stellt er AX_METADATA_URL bereit, einen kleinen lokalen HTTP-Metadatenserver.
  3. Der Bootstrap hat eine 10-Minuten-Uhr. Die Materialisierung des Workspace (Klone, MCP-Auflösung, Skill-Installation, der generative goal-Schritt) muss innerhalb von AX_BOOTSTRAP_TIMEOUT fertig werden, standardmäßig 10 Minuten. Große Monorepos auf einem kalten Worker können das sprengen.
  4. Die Control Plane liest deinen Exit-Code nicht. Der Runner loggt den Exit-Status des Kommandos, bleibt aber als PID 1 am Leben, egal ob dein Agent noch läuft oder nicht. Ein Task in Phase Running bedeutet also nicht, dass dein Agent lebt. Schreib dein eigenes Abschlusssignal (eine Datei im Workspace, eine Nachricht an deine eigene Queue, eine Task-Löschung von innen) und überwache das.
  5. Shutdown ist SIGTERM, 10 Sekunden, SIGKILL. Der Runner leitet SIGTERM an die Prozessgruppe des Kommandos weiter und wartet eine begrenzte Gnadenfrist ab. Schreib deinen Zustand früh weg.

Suspend und Resume: was überlebt​

Suspend/Resume ist das Feature, das den ganzen Stack rechtfertigt. Agenten verbringen die meiste Uhrzeit damit, auf ein Modell, ein Tool oder einen Menschen zu warten, und Substrates Wette ist, dass ein untätiger Agent Speicherplatz kosten sollte, keinen warmen Pod.

ax suspend task fix-flaky-test   # Ready=False, snapshot taken
ax resume  task fix-flaky-test   # restored on any free worker

Was laut Doku überlebt und was nicht:

Überlebt ein Suspend/ResumeÜberlebt nicht
Das Volume /workspace (Dateien, Klone, Build-Artefakte)Der Prozessbaum: dein Agent startet von seinem Entrypoint neu
Der Actor-Memory-Snapshot auf Substrate-Ebene (RAM + Dateien, auf der Substrate-Schicht)Offene Netzwerkverbindungen (GKE-Doku: Agenten müssen mit Reconnects umgehen können)
Task-Spec und -StatusAlles, was außerhalb des Workspace-Volumes geschrieben wurde

Die Runner-Doku benennt die Konsequenz explizit: Nach einem Resume sieht der Runner dieselben Dateien, aber einen neuen Prozessbaum – er muss also nachhalten, ob das Workspace-Setup bereits gelaufen ist (Marker-Dateien sind der vorgeschlagene Mechanismus), sonst klont er jedes Repo erneut. Wenn dein Agent seinen Plan oder seine Konversation nur im Prozessspeicher hält, geht das beim Resume verloren; halte das Transkript auf der Platte im Workspace. Das ist dieselbe Lektion wie auf unserer Seite zu Harnesses für langlaufende Agenten, nur von der Infrastruktur erzwungen.

Guided walkthrough1 of 6
  1. go install github.com/google/ax/cmd/ax@latest. AX folgt deinem aktiven kubeconfig-Kontext (kubectx funktioniert) und verwendet standardmäßig den Namespace ax-system und den atespace default. Für den Laptop richten die hack/-Skripte im Agent-Substrate-Repo einen kind-Cluster mit installiertem Substrat ein; die Control Plane von AX wird dann mit make deploy AX_IMAGE_REPO=<your registry> deployt, wofür du ko und eine Registry brauchst, in die du pushen kannst.

Lass Claude die Manifeste für einen Agenten entwerfen, den du schon betreibst

I run an agent as a container image ghcr.io/acme/triage-agent:1.4. Its entrypoint is "triage --repo REPO_PATH --model MODEL_ID". It needs: the repo github.com/acme/backend on branch main, an MCP server for Linear reachable at http://linear-mcp.tools.svc.cluster.local:8080, outbound access only to api.anthropic.com:443 and github.com:443, and the Anthropic key from the Kubernetes Secret "anthropic-api-secret" (key ANTHROPIC_API_KEY).

Write the four google/ax v1alpha1 manifests (Model, Gateway, Workspace, Task) for this, following docs/manifests.md in the repo. Then write a Dockerfile that extends the published ax-task-runner base image and installs my agent WITHOUT changing the entrypoint. Finally, list what I must change in the agent so that (a) it treats the first workspace as its working directory, (b) it survives a suspend/resume by keeping its plan and transcript on disk under /workspace and using a marker file to skip re-setup, and (c) it signals completion in a way the AX control plane can't (it ignores exit codes).

Wo AX neben den gehosteten Agenten-Loops steht​

Die am häufigsten hochgevotete Frage im HN-Thread war: „Was ist der Vorteil gegenüber der OpenAI Agents API?“ Die ehrliche Antwort: Das sind unterschiedliche Schichten.

AX + Agent SubstrateClaude Managed AgentsOpenAI Agents APICloudflares Isolate-Runtime
Wer betreibt die SchleifeDu (jedes Harness im Container)Anthropic (das Harness gehört ihnen)OpenAI (das Codex-Harness)Du, auf Workers/Durable Objects
Wo es läuftDein Kubernetes-Cluster, jede Cloud oder on-premAnthropics InfrastrukturOpenAIs, oder eine selbst gehostete SandboxCloudflares Edge
IsolationgVisor-/Cloud-Hypervisor-Sandbox pro TaskVon Anthropic verwaltete UmgebungGehostete oder selbst gehostete SandboxV8-Isolate, Container bei Bedarf
ModellauswahlJeder Provider, den du in eine Model-Ressource steckstClaudeOpenAI-ModelleBeliebig (über API)
Kostenmodell im LeerlaufSnapshot in den Speicher, Resume bei BedarfAbrechnung pro SessionAbrechnung pro SessionIsolates gehen in den Ruhezustand
Dir gehörtCluster, Upgrades, Secrets, Egress-PolicyEin API-SchlüsselEin API-SchlüsselEin Workers-Account

Wähle AX, wenn du Datensouveränität brauchst, Modelle mehrerer Anbieter hinter einer einzigen Policy betreiben willst, ohnehin schon Kubernetes betreibst oder Agenten willst, die tagelang schlafen können, ohne Rechenzeit zu kosten. Wähle einen gehosteten Loop, wenn du heute ein funktionierendes Harness willst und keinen Cluster besitzen möchtest. Viele Teams werden beides tun: einen gehosteten Loop für interaktive Sitzungen, AX-artige Infrastruktur für Flotten von Hintergrund-Tasks.

Fallstricke und der Widerspruch, dem zuzuhören sich lohnt​

  • Die Doku aus dem Juni beschreibt ein anderes Werkzeug. Die Mai-Preview bot eine konversationszentrierte CLI (ax exec --conversation … --resume, ax fork für Trajektorien-Branching, ein AgentService-Protokoll mit ADK- und A2A-Brücken). Die Kommandoreferenz des September-README ist ressourcenzentriert: apply, get, describe, watch, suspend, resume, delete, ssh, tunnel, ctx. Wenn ein Tutorial ax fork zeigt, stammt es aus der Zeit vor dem Redesign. Die fünf Kernfähigkeiten aus dem Mai-Blogpost (dauerhafte Ausführung, Isolation, Single-Writer-Session-Konsistenz, Verbindungswiederherstellung, Trajektorien-Branching) sind weiterhin die erklärten Ziele; wie viel von der Branching-Geschichte im Ressourcenmodell überlebt, ist zum Zeitpunkt dieses Textes nicht dokumentiert.
  • v1alpha1 ist ernst gemeint. Das README warnt vor größeren Breaking Changes vor einem stabilen Release. Pinne die CLI-Version und den Digest des Runner-Images und lies docs/manifests.md bei jedem Upgrade neu.
  • Kubernetes ist nicht optional. Die meistwiederholte Beschwerde im Thread. Der Substrate-Quickstart läuft auf kind, du kannst es also auf einem Laptop ausprobieren, aber Produktion heißt echter Cluster. Wenn du nicht ohnehin schon Kubernetes betreibst, ist AX kein Grund, damit anzufangen.
  • Managed GKE Agent Substrate hat harte Anforderungen. GKE 1.37+ (1.36 mit Beta-Flags), Workload Identity, bei der Cluster-Erstellung aktivierte Beta-APIs, einheitliche Maschinentypen pro ActorTemplate (kein E2), ein Cloud-Storage-Bucket für Snapshots, gVisor- oder Cloud-Hypervisor-Isolation und kein GPU-Passthrough. Der Produktiveinsatz steckt hinter einem privaten GA-Programm mit Allowlist.
  • Die Egress-Defaults in den Beispielen sind großzügig. host: "*" auf 443 lässt einen Agenten jeden HTTPS-Endpoint erreichen. Das ist das Gegenteil von dem, was du für einen Task willst, der nicht vertrauenswürdige Repos liest. Befolge dieselben Regeln wie unter lokale und hybride Agenten absichern.
  • Zwei Projekte, zwei Organisationen, ein Disclaimer. AX liegt unter google/; Substrate liegt unter agent-substrate/ und erklärt selbst, kein offiziell unterstütztes Google-Produkt zu sein. Keines der beiden ist für Googles OSS-Vulnerability-Rewards-Programm qualifiziert. Plane Zeit ein, um Quellcode zu lesen, wenn etwas kaputtgeht.
AX-Vokabular
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 8

Selbsttest

0/6
  1. Du lieferst spec.image mit deinem eigenen ENTRYPOINT. Was führt AX als PID 1 aus?
  2. Dein Agent beendet sich mit Status 1. Was zeigt ax get task?
  3. Nach ax resume klont dein Agent jedes Repository erneut. Warum?
  4. ax ssh verweigert die Verbindung zu deinem Task. Wahrscheinlichste Ursache?
  5. Welche Schicht implementiert tatsächlich das Snapshotten untätiger Agenten in den Speicher und ihre Wiederherstellung auf einem warmen Worker?
  6. Ein Tutorial vom Juni 2026 sagt dir, du sollst ax fork ausführen, um eine Trajektorie zu verzweigen. Was solltest du erwarten?

Quellen & weiterführende Literatur​

Weiter​