Strona główna / Artykuły

Środowiska sandbox zdalne z pamięcią stanu, agentami zarządzanymi antygrawitacją oraz SDK GenAI

Agenci zarządzający antygrawitacją przy użyciu GenAI SDK: utrzymuj zdalną przestrzeń sandbox Ubuntu aktywną między rundami, ponownie podłącz się za pomocą ID środowiska i pobierz zrzut stanu przestrzeni roboczej.

Wydawca: REACTAPP.TOP8 min czytania1737 słów

Źródła: Orchestrating with Antigravity: A Crescendo of Agents (Part 1)

Część programistów żyje w terminalu. Jeśli narzędzie nie da się skonfigurować za pomocą skryptów w bash, pomijają je, a ich codzienna praca z AI opiera się na agentach wiersza poleceń, takich jak gemini-cli oraz jego nowszy odpowiednik antigravity-cli (agy). To jest sposób pracy typu „BashOps”, w przeciwieństwie do grupy „ClickOps”, która woli narzędzia graficzne.

Taki podejście napotyka problemy, gdy rośnie ilość zadań wykonywanych przez agenty. Uruchamianie kilku agentów programistycznych jednocześnie, obsługa wieloetapowych pętli z zachowaniem stanu oraz śledzenie zmian w plikach może oznaczać konieczność nadzorowania od sześciu do dwunastu okien terminala rozproszonych na tylu samych wirtualnych biurkach, co szybko staje się obciążeniem psychicznym. Pierwszym rozwiązaniem jest trwałość: zapewnienie każdemu agentowi przestrzeni roboczej, która przetrwa między kolejnymi wywołaniami. Drugim rozwiązaniem, bezpiecznym uruchamianiu równoległych lokalnych podagentów za pomocą worktree’ów git, jest osobny temat.

Tutaj przyjrzymy się temu, jak stanowe odległe środowiska testowe funkcjonują z zarządzanymi agentami Antigravity firmy Google, wykorzystując SDK Google GenAI oraz model agenta w wersji przeglądowej antigravity-preview-05-2026. Zobaczysz, jak ponownie połączyć się z środowiskiem kontenerowym oraz jak pobrać przestrzeń roboczą agenta z powrotem na swój komputer za pomocą lokalnego shella. Architektura oraz strona hostowana zarządzanych agentów są dobrze opisane w innych źródłach, na przykład w artykule Philippa Schmida o tym, jak te agenci działają wewnętrznie. Tutaj skupiamy się na programowym sterowaniu nimi w celu tworzenia pętli automatyzacji.

Agenty stanowe w praktyce

W tradycyjnym wywołaniu API agenta nie ma pamięci. Wysyłasz prompt, agent odpowiada, a przestrzeń robocza znika. Jeśli chcesz, aby edytował plik stworzony w poprzedniej turze, musisz wysłać cały plik z powrotem w prompt. To kosztuje tokeny, powoduje opóźnienia i sprawia, że generowanie kodu w kilku turach jest wolne i drogie.

Odpowiedzią Antigravity jest stanowy zdalny sandbox. Przekaż "remote" jako środowisko, a SDK zajmie się następującymi rzeczami:

  1. tworzy prywatny, zabezpieczony kontener Ubuntu w Google Cloud;
  2. agent jest wykonywany wewnątrz niego;
  3. kontener pozostaje aktywny po zakończeniu wywołania, a environment_id służy do jego identyfikacji;
  4. każde późniejsze wywołanie może połączyć się z tym samym kontenerem i stwierdzić, że system plików pozostał nietknięty.

Najprostszym sposobem, aby w to uwierzyć, jest zobaczenie kodu.

Przykład: analityk IPO wypierany przez Pythona

Aby pokazać tę koncepcję, oto skrypt, który koordynuje sesję agenta pracującego w trzech etapach i przechowującego stan. Agent odgrywa rolę analityka IPO. W pierwszym etapie bada ofertę publiczną danej firmy i zapisuje raport w formacie Markdown. W drugim etapie ponownie łączy się z tym samym kontenerem, otwiera raport i przekształca go w panel sterowania w formacie HTML z własnym stylem, a także tworzy odpowiadające mu obrazki. W trzecim etapie skrypt pobiera zrzut całego obszaru pracy.

Funkcje związane z przechowywaniem stanu są realizowane za pomocą standardowego SDK Google GenAI dla Pythona, poprzez wywołanie modelu agenta do przeglądania z parametrem environment="remote".

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/")

To, co robi skrypt, krok po kroku:

  1. Uruchomienie i badanie. Google uruchamia kontener na maszynie z systemem Ubuntu, prawdziwym urządzeniu z rzeczywistym dyskiem, a agent rozpoczyna swoje badania.
  2. Kontynuacja i konwersja. Drugi etap przekształca Markdown w HTML. To dziwne podzielenie na etapy, ponieważ pierwszy etap mógłby bezpośrednio wygenerować HTML, ale pokazuje to, że można przerwać pracę na dziś i wznowić ją jutro z nienaruszoną sesją, być może nawet z aplikacji do czatowania.
  3. Pobranie wyników lokalnie. To właśnie ta część sprawia wrażenie rzeczywistości. Kontener zawiera rzeczywiste środowisko pracy, być może z sklonowanym repozytorium oraz dodanymi testami jednostkowymi. W tym przypadku zawierał raport w formacie Markdown z pierwszego etapu, plik index.html, plik obrazu oraz plik z szablonami stylów z drugiego etapu.

Otwarcie pliku index.html w przeglądarce pokazuje stworzoną panel kontrolny, w tym sekcję porównującą sytuację „byków” z „niedźwiedziami” dotyczącą strategii inwestycyjnej.

Przykład: prototypowanie małej gry dla dzieci

To samo podejście sprawdza się przy tworzeniu oprogramowania. Weźmy na przykład grę polegającą na odczytywaniu godziny dla dzieci. Problem, który rozwiązuje, jest konkretny: dziecko, które jest dobrym w arytmetyce, może mieć trudności z przekształceniem wskazań zegara analogowego, na przykład godziny 19:45, na odpowiednią wartość cyfrową. Gdy już mamy formę cyfrową, obliczanie różnic, takich jak 08:45 plus lub minus 20 minut, jest proste. Przeszkoda jest czysto wizualna, dlatego przydatna jest gra, która łączy te dwa aspekty.

Celem było stworzenie gry mobilnej wieloplatformowej w Flutterze, po części dlatego, że częste podróże sprawiają, że aplikacja działająca offline w telefonie podczas lotu jest bardzo przydatna. Na początku pierwszy prototyp został stworzony za pomocą pojedynczego skryptu z stanem. Dostarczono mu szczegółowe, wieloetapowe polecenia, które nakazywały mu przeczytać plik z wymaganiami produktu, zaimplementować grę, uruchomić lokalny serwer, zrobić zrzut ekranu oraz otworzyć prośbę o połączenie na GitHubie.

Podstawa tego skryptu wykorzystuje SDK google-genai do przygotowania zdalnej przestrzeni sandbox, podłączenia repozytorium git, a następnie pobrania i wyekstrakcji ostatecznego zrzutu stanu przestrzeni roboczej:

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"})

Zamiast od razu przechodzić do złożonej aplikacji Flutter, agent napisał szybki prototyp wykorzystujący tylko HTML, CSS i JavaScript. Na podstawie opisu zachowania zegara oraz jego pętli sprzężenia zwrotnego w ciągu jednej rundy, agent stworzył responsywną aplikację zegara w ciągu około minuty. Opracował również interaktywne opcje łączące czas analogowy z kilkoma cyfrowymi przyciskami odpowiedzi.

To pokazało wartość szybkiego projektowania prototypów przy użyciu pojedynczego agenta. Skalowanie ponad jeden prototyp to inny problem, ponieważ wdrożenie pełnej gry w Flutter z kilkoma podagentami jednocześnie sprawia trudności zwykłej pętli CLI. Bezpieczne radzenie sobie z tym wymaga izolowanych worktree’ów git oraz dedykowanej infrastruktury orkiestracji.

Dla czego nadają się zdalne agenci

Naturalne pytanie brzmi, do czego właściwie przydają się te zdalne agenty. Można by argumentować, że wszystko jest wygodniejsze w środowisku localhost. Bardziej interesujące podejście traktuje je jako pierwszy krok w kierunku „Dockerfiles dla agentów”. Zaczyna się od eksperymentowania lokalnie, a następnie stopniowo tworzy się kontener agenta z własnymi skryptami, folderem konfiguracji narzędzi oraz być może kluczem konta usługi chmurowej. Wkrótce ma się gotowe, powtarzalne, samodzielne i bezpieczne środowisko, w którym agent może uzyskać dostęp do Internetu, przy użyciu potężnej kombinacji git clone i kluczy API.

Praktyczne wskazówki:

  • Pomijaj to przy jednorazowych badaniach – interfejs internetowy lub lokalna linia poleceń są znacznie szybsze.
  • Wykorzystaj go do procesów pracy powtarzalnych, w których konfiguracja jest znacznie bardziej skomplikowana niż ostateczny prompt. Jeśli uruchamiasz pięć promptów, a pierwsze cztery nigdy się nie zmieniają, podczas gdy piąty zawsze się zmienia, to jest idealne zastosowanie.
  • Spróbuj także narzędzi linii poleceń API Gemini, które Philipp Schmid opisuje w swoim przewodniku dla programistów zajmujących się zarządzanymi agentami.

Przykładem takiego przypadku jest zautomatyzowany planer podróży rodzinnej w formie kontenera, w którym podajesz jedynie destynację, daty i ograniczenia. Działa on nieco jak dostrojony model, z tą różnicą, że cały system plików jest widoczny i dostępny do modyfikacji, więc możesz później pobrać wygenerowany plik index.html. Podczas jednego uruchomienia agent stworzył kompletny plan podróży na wyspę, wraz z mapą trasy i linkami do potwierdzalnych rezerwacji, na podstawie trzech promptów, z których pierwsze dwa pozostały niezmienne.

Uwagi przed wdrożeniem

W przypadku takiej konfiguracji obowiązują kilka istotnych sprawdzeń:

  • Zrzut stanu może zawierać wszystko, co zobaczył agent, w tym sklonowane repozytoria oraz wszystkie dane uwierzytelniające, które zostały podłączone. Traktuj plik tar jako poufny i unikaj umieszczania kluczy kont usługowych w środowiskach testowych, chyba że są one bezwzględnie konieczne.
  • Nazwa modelu jest tutaj wersją wstępną z określonym terminem obowiązywania. Umieść ją celowo w stałym miejscu, biorąc pod uwagę, że zachowanie i punkty końcowe mogą ulec zmianie.
  • Zachowaj identyfikator środowiska w miejscu trwałym. Jego utrata oznacza utratę możliwości ponownego podłączenia się.
  • Sprawdź, ile kosztuje środowisko testowe z pamięcią stanu oraz jak długo istnieje, zanim polegasz na schematach pracy typu „wróć jutro”.

Literatura pokrewna

  • Inżynieria agentów i zewnętrzny cykl: gdzie pasują Antigravity oraz Agents CLI — Specyfikacje, oceny i zasady bezpieczeństwa definiują inżynierię agentów. Przegląd narzędzia Agents CLI firmy Google, jego warstwy produkcyjnej w GCP oraz różnice pomiędzy Antigravity a innymi narzędziami programistycznymi.