Startseite / Artikel

Zustandsbasierte entfernte Sandboxes mit antigravitativ gesteuerten Agenten und dem GenAI SDK

Antigravity-geführte Agenten mit dem GenAI SDK: Halten eine entfernte Ubuntu-Sandbox über mehrere Spielzüge hinweg am Laufen, verbinden sich erneut über die Umgebungs-ID und holen das Arbeitsplatz-Snapshot ab.

Verlag: REACTAPP.TOP8 Min. Lesezeit1737 Wörter

Quellen: Orchestrating with Antigravity: A Crescendo of Agents (Part 1)

Einige Entwickler leben im Terminal. Wenn ein Tool nicht über Bash skriptbar ist, überspringen sie es, und ihr täglicher AI-Arbeitsablauf basiert auf Befehlszeilen-Tools wie gemini-cli sowie dessen neuerem Pendant antigravity-cli (agy). Das ist die „BashOps“-Arbeitsweise im Gegensatz zur Gruppe der „ClickOps“, die grafische Tools bevorzugt.

Dieser Ansatz stößt an seine Grenzen, wenn die Arbeit der Agenten zunimmt. Das gleichzeitige Ausführen mehrerer Programmier-Agenten, das Steuern mehrstufiger, zustandsbehafteter Schleifen sowie das Überwachen von Dateiveränderungen kann bedeuten, dass man sechs bis zwölf Terminalfenster auf verschiedenen virtuellen Desktops betreuen muss – was schnell zu einer großen mentalen Belastung wird. Der erste Lösungsschritt ist die Persistenz: Jeder Agent erhält einen Arbeitsbereich, der zwischen den Aufrufen erhalten bleibt. Der zweite Schritt, lokale Subagenten sicher parallel mit git worktrees auszuführen, ist ein eigenes Thema.

Hier schauen wir uns an, wie statebasierte Remote-Sandboxen mit Googles Antigravity-Managed-Agents funktionieren, unter Verwendung des Google GenAI SDK sowie des Vorab-Agentenmodells antigravity-preview-05-2026. Sie erfahren, wie Sie sich erneut an eine Containerumgebung anschließen und wie Sie den Arbeitsbereich des Agents über eine lokale Shell auf Ihren eigenen Rechner herunterladen können. Die Architektur sowie der gehostete Teil der Managed-Agents werden an anderer Stelle ausführlich behandelt, beispielsweise in Philipp Schmids Artikel darüber, wie Managed-Agents im Hintergrund arbeiten. Der Fokus hier liegt darauf, sie programmatisch einzusetzen, um Automatisierungszyklen zu erstellen.

Statebasierte Agenten in der Praxis

In einem herkömmlichen API-Aufruf für Agenten gibt es kein Gedächtnis. Man sendet eine Anfrage, der Agent antwortet und der Arbeitsbereich verschwindet. Wenn man möchte, dass der Agent eine Datei bearbeitet, die er in einem vorherigen Schritt erstellt hat, muss man die gesamte Datei erneut in der Anfrage übermitteln. Das kostet Tokens, verursacht Verzögerungen und macht die mehrschrittige Codegenerierung langsam und teuer.

Die Lösung von Antigravity ist der Zustandsbasierte Remote-Sandbox. Man gibt "remote" als Umgebung an, und das SDK kümmert sich um Folgendes:

  1. es erstellt einen privaten, gesicherten Ubuntu-Container in Google Cloud;
  2. der Agent wird darin ausgeführt;
  3. der Container bleibt nach dem Aufruf aktiv, und ein environment_id wird zurückgegeben, um ihn zu identifizieren;
  4. jeder spätere Aufruf kann sich an denselben Container anschließen und feststellen, dass das Dateisystem unverändert ist.

Der einfachste Weg, das zu verstehen, ist, sich den Code anzusehen.

Beispiel: Ein IPO-Analyst, der von Python verdrängt wird

Um die Idee zu veranschaulichen, hier ein Skript, das eine stateful, dreistufige Agentensitzung steuert. Der Agent übernimmt die Rolle eines IPO-Analysten. In der ersten Phase recherchiert er die öffentliche Börsennotierung eines Unternehmens und speichert einen Markdown-Bericht. In der zweiten Phase verbindet sich der Agent erneut mit demselben Container, öffnet diesen Bericht und erstellt daraus ein HTML-Dashboard mit eigener Stylesheet-Datei sowie ein entsprechendes Bild. In der dritten Phase lädt das Skript ein Snapshot des gesamten Arbeitsbereichs herunter.

Die stateful-Funktionen werden über das standardmäßige Google GenAI Python SDK erreicht, indem das Preview-Agentenmodell mit environment="remote" aufgerufen wird.

import os
import requests
import tarfile
from google import genai

client = genai.Client()
print("🚀 Turn 1: Launching SRE/Financial Agent in remote Ubuntu Sandbox...")
# Turn 1: Launch agent to research and write a report in a remote sandbox
interaction_1 = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Research SpaceX IPO and save report as spacex-report.md.",
    environment="remote"  # Launches a remote Ubuntu sandbox
)
env_id = interaction_1.environment_id
print(f"✅ Turn 1 Complete. Container Environment ID: {env_id}")

print("\n🔄 Turn 2: Re-attaching to same container and converting to HTML...")
# Turn 2: Re-attach to the SAME sandbox and preserve conversation memory
interaction_2 = client.interactions.create(
    agent="antigravity-preview-05-2026",
    environment=env_id,                              # ← Re-attaches to same sandbox
    previous_interaction_id=interaction_1.id,       # ← Preserves conversation memory
    input="Convert that spacex-report.md file into a clean index.html webpage" +
          " with styling and generate a custom nanobanana image."
)
print("✅ Turn 2 Complete.")

print("\n📦 Turn 3: Downloading the entire container snapshot (.tar) locally...")
# Turn 3: Download the entire sandbox environment state (.tar) locally
api_key = os.environ.get("GEMINI_API_KEY")
response = requests.get(
    f"https://generativelanguage.googleapis.com/v1beta/files/environment-{env_id}:download",
    params={"alt": "media"},
    headers={"x-goog-api-key": api_key},
)
tar_path = "snapshot_env.tar"
with open(tar_path, "wb") as f:
    f.write(response.content)
print(f"✅ Snapshot downloaded to {tar_path}. Extracting...")
with tarfile.open(tar_path) as tar:
    tar.extractall(path="./workspace_extract")
# Wow! We've dumped the remote agent workspace locally!
print("🎉 Workspace extracted successfully! Check ./workspace_extract/")

Was die Skriptschritte Schritt für Schritt tun:

  1. Starten und untersuchen. Google startet einen Container auf einem Ubuntu-System, einer echten Instanz mit einer echten Festplatte, und der Agent beginnt mit seiner Untersuchung.
  2. Weitermachen und konvertieren. In der zweiten Phase wird Markdown in HTML umgewandelt. Das ist eine unnötige Trennung, da die erste Phase direkt HTML erzeugen hätte können, doch es zeigt, dass man die Arbeit heute pausieren und morgen mit unveränderten Daten fortsetzen kann – vielleicht sogar über eine Chat-App.
  3. Ergebnisse lokal abrufen. Das ist der Teil, der es real wirken lässt. Der Container enthält einen echten Arbeitsbereich, möglicherweise mit einem geklonten Repository sowie zusätzlichen Unit-Tests. In diesem Lauf enthielt er den Markdown-Bericht aus der ersten Phase, eine index.html-Datei, ein Bildfile sowie eine Stylesheet-Datei aus der zweiten Phase.

Durch Öffnen von index.html in einem Browser wird das erzeugte Dashboard angezeigt, einschließlich eines Abschnitts zum Vergleich von Bären- und Bullenmärkten für den Investitionsfall.

Beispiel: Prototyping eines kleinen Kinderspiels

Das gleiche Muster gilt auch für die Entwicklung von Software. Betrachten wir ein Spiel zum Lesen von Uhren für Kinder. Das Problem, das es löst, ist konkret: Ein Kind, das in Arithmetik gut ist, kann trotzdem Schwierigkeiten haben, ein analoges Uhrzifferblatt – zum Beispiel eines, das 19:45 anzeigt – in die entsprechende digitale Zeichenfolge umzuwandeln. Sobald die digitale Darstellung vorliegt, ist es einfach, Differenzen wie 08:45 plus oder minus 20 Minuten zu berechnen. Das Hindernis ist rein visueller Natur, weshalb ein Spiel, das diese beiden Formate miteinander verbindet, nützlich ist.

Das Ziel war ein plattformübergreifendes Mobile-Spiel in Flutter – teilweise, weil häufige Reisen ein App nötig machen, die während eines Fluges offline auf dem Handy funktioniert. Zunächst wurde mit einem einzigen, zustandsbasierten Skript das erste Prototyp erstellt. Diesem Skript wurde eine detaillierte, mehrstufige Anweisung gegeben, die es aufforderte, eine Datei mit Produkterfordernissen zu lesen, das Spiel zu implementieren, einen lokalen Server zu starten, einen Screenshot anzufertigen und anschließend einen Pull Request auf GitHub zu öffnen.

Der Kern dieses Skripts verwendet das google-genai SDK, um den entfernten Sandbox bereitzustellen, das Git-Repository einzubinden und anschließend den endgültigen Arbeitsplatz-Snapshot herunterzuladen und zu extrahieren:

from google import genai
import requests, os

client = genai.Client()
api_key    = os.environ["GEMINI_API_KEY"]
gh_token   = os.environ.get("GITHUB_TOKEN")  # optional: enables the agent to push a PR

# Mount the git repo AND inject the GitHub token as a file into the sandbox
sources = [
    {"type": "repository",
     "source": "https://github.com/palladius/orologia.io",
     "target": "/workspace"},

    {"type": "inline",
     "target": "/workspace/.github_token",
     "content": gh_token},  # ← secret injection!
]
# The prompt tells the agent exactly what to build
prompt = """
You are an expert full-stack developer agent.

The repo orologia.io is mounted at /workspace.
1. Read docs/PRD.md and implement a beautiful clock-learning game...
2. Make it stunning: analog clock with rotating hands, digital display, ..
3. Optionally screenshot it, then commit and open a PR using the token
   at /workspace/.github_token.
"""  # Full prompt: https://github.com/palladius/orologia.io/blob/main/solutions/20260615-antigravity-managed-agents/run-agent-prototype.py
# Launch remote stateful sandbox agent
interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input=prompt,
    environment={"type": "remote", "sources": sources}
)
# Download final snapshot locally
url = ...
response = requests.get(url, headers={"x-goog-api-key": api_key}, params={"alt": "media"})

Anstatt direkt zu einer komplexen Flutter-App überzugehen, erstellte der Agent ein schnelles, provisorisches Prototypenprojekt mit reinem HTML, CSS und JavaScript. Auf der Grundlage einer Beschreibung des Uhrverhaltens sowie dessen Rückkopplungsschleife innerhalb einer einzigen Iteration entwickelte der Agent in etwa einer Minute eine responsive Uhr-App. Zudem entwarf er interaktive Optionen, bei denen eine analoge Uhrzeit mit mehreren digitalen Antwortknöpfen abgeglichen werden konnte.

Das zeigte den Wert des schnellen Prototypierens mit einem einzelnen Agenten. Das Erweitern auf mehr als ein Prototyp ist ein anderes Problem, denn die Implementierung des vollständigen Flutter-Spiels mit mehreren Unteragenten gleichzeitig stellt eine Herausforderung dar – hier fängt ein einfacher CLI-Zyklus an, Schwierigkeiten zu haben. Eine sichere Handhabung erfordert isolierte git-Worktrees sowie eine spezielle Orchestrierungsstruktur.

Wofür eignen sich Remote-Agenten

Die natürliche Frage ist, wozu diese Remote-Agenten eigentlich gut sind. Man könnte argumentieren, dass alles auf localhost bequemer ist. Eine interessantere Sichtweise betrachtet sie als ersten Schritt in Richtung „Dockerfiles für Agenten“. Man beginnt mit Experimenten lokal und entwickelt anschließend schrittweise einen Agenten-Container mit eigenen Skripten, einer Tool-Konfigurationsdatei und möglicherweise einem Cloud-Service-Account-Schlüssel. Bald hat man einen wiederholbaren, selbstständigen und sicheren Sandbox, in dem ein Agent auf das Internet zugreifen kann – wobei git clone und API-Schlüssel eine starke Kombination bilden.

Praktische Anleitung:

  • Überspringen Sie dies bei einmaligen Untersuchungen. Die Web-Oberfläche oder eine lokale CLI sind viel schneller.
  • Verwenden Sie es für wiederholbare Workflows, bei denen die Einrichtung weitaus umfangreicher ist als die endgültige Anfrage. Wenn Sie fünf Anfragen senden und die ersten vier sich nie ändern, während die fünfte stets wechselt, dann ist das der ideale Fall.
  • Probieren Sie auch die Befehlszeilentooling-Optionen der Gemini API aus, die Philipp Schmid in seinem Entwicklerleitfaden zu managed Agents beschreibt.
  • Ein Beispiel für einen wiederholbaren Fall ist ein in Containern gehosteter Familien-Reiseplaner, bei dem Sie nur Zielort, Daten und Einschränkungen angeben. Er verhält sich etwas wie ein fein abgestimmtes Modell, mit dem Unterschied, dass der gesamte Dateisystem zugänglich und anpassbar ist, sodass Sie anschließend die erzeugte index.html-Datei herunterladen können. Bei einer einzigen Ausführung erstellte ein Agent einen vollständigen Reiseplan für eine Insel mit einer Routenkarte und überprüfbaren Buchungslinks – wobei die ersten beiden der drei Anfragen unverändert blieben.

    Achtungsmomente vor der Einführung

    Für eine solche Einrichtung gelten einige sinnvolle Überprüfungen:

    • Eine Snapshots kann alles enthalten, was der Agent gesehen hat, einschließlich geklonter Repositorien und aller von Ihnen eingebundenen Anmeldeinformationen. Behandeln Sie die tar-Datei als vertraulich und halten Sie die Schlüssel der Service-Konten außerhalb der Sandboxes, es sei denn, sie sind unbedingt notwendig.
    • Der hier angegebene Modellname ist eine veraltete Vorschauversion. Fixieren Sie ihn absichtlich, da sich das Verhalten sowie die Endpunkte ändern können.
    • Speichern Sie die Umgebungs-ID an einem dauerhaften Ort auf. Ohne sie verlieren Sie die Möglichkeit, die Umgebung erneut anzubinden.
    • Prüfen Sie, wie teuer eine stateful Sandbox ist und wie lange sie besteht, bevor Sie sich auf „morgen wieder“-Workflows verlassen.

    Verwandte Literatur

  • Agentic Engineering und der Outer Loop: Wo Antigravity sowie die Agents CLI passen — Spezifikationen, Bewertungen und Sicherheitsmaßnahmen definieren Agentic Engineering. Ein Überblick über Googles Agents CLI, seine GCP-Produktionsschicht und wie Antigravity sich von anderen Programmierwerkzeugen unterscheidet.