Google Antigravity: orkiestracja agentów AI i techniczne aspekty architektury 2.0

Platforma Google Antigravity 2.0 przenosi proces wytwarzania oprogramowania w model agent-first, umożliwiając autonomiczną orkiestrację zadań programistycznych w systemach macOS, Linux i Windows. Implementacja rozwiązania w środowisku korporacyjnym wymaga rygorystycznego zarządzania uprawnieniami lokalnymi oraz monitorowania budżetu okna kontekstowego w ramach protokołu Model Context Protocol (MCP).

Architektura ekosystemu Antigravity i jej komponenty techniczne

Ekosystem Google Antigravity 2.0 składa się z czterech głównych komponentów: samodzielnej aplikacji desktopowej (Agent Manager), wyspecjalizowanego środowiska Antigravity IDE, interfejsu wiersza poleceń (CLI) oraz pakietu SDK w języku Python. Wszystkie te elementy współdzielą wspólne środowisko wykonawcze Agent Runtime, co zapewnia spójność stosowanych polityk bezpieczeństwa, mechanizmów planowania oraz logiki operacyjnej niezależnie od wybranego interfejsu użytkownika.

Komponent Charakterystyka techniczna
Antigravity 2.0 Samodzielne centrum dowodzenia do równoległego zarządzania wieloma lokalnymi agentami i zadaniami harmonogramowanymi.
Antigravity IDE Rozwidlenie (fork) VS Code z głęboką integracją agentów, obsługą artefaktów i zrozumieniem struktury bazy kodu.
Antigravity CLI Interfejs terminalowy umożliwiający interakcję z agentami na serwerach, w kontenerach oraz sesjach SSH.
Antigravity SDK Biblioteka Python dająca programistyczny dostęp do runtime’u agenta, pozwalająca na budowę własnych aplikacji agentowych.

Platforma domyślnie wykorzystuje model Gemini 3.5 Flash, który optymalizuje szybkość wnioskowania i pozwala na sprawną obsługę wieloetapowych sesji. W testach demonstracyjnych system Antigravity 2.0 był w stanie wygenerować działający prototyp systemu operacyjnego w czasie 12 godzin poprzez iteracyjną pracę wielu agentów.

Zarządzanie projektami i izolacja kontekstu operacyjnego

Struktura pracy w Antigravity opiera się na projektach, które definiują środowisko i zakres dostępu agenta do wielu folderów jednocześnie, co umożliwia dokonywanie zmian holistycznych w architekturach typu full-stack. Zamiast operowania na pojedynczym katalogu, projekt może obejmować repozytorium frontendowe, backendowe oraz dokumentację, dostarczając agentowi pełny kontekst niezbędny do modyfikacji logiki przepływu danych między systemami.

Kluczowe parametry konfiguracji projektu obejmują: Security Preset: Określa, czy komendy terminala i dostęp do plików wymagają każdorazowego zatwierdzenia przez operatora. Agent Behavior: Definiuje stopień autonomii w egzekucji planu implementacji (z recenzją użytkownika lub bez). Local Permissions: Granularne blokowanie lub zezwalanie na konkretne ścieżki plików oraz adresy URL. MCP Tools: Selektywne przypisywanie narzędzi Model Context Protocol do konkretnego projektu w celu ograniczenia „zaśmiecenia” kontekstu.

W celu optymalizacji wydajności zaleca się archiwizowanie nieaktywnych konwersacji, ponieważ aktywne wątki mogą nadmiarowo wypełniać okno kontekstowe agenta, zwiększając latencję i koszty operacyjne.

Protokół MCP i rozszerzalność poprzez mechanizm umiejętności

Model Context Protocol (MCP) stanowi standard łączności agentów z zewnętrznymi systemami, bazami danych oraz usługami chmurowymi, takimi jak Google Cloud Run. Rozszerzanie natywnych możliwości platformy odbywa się poprzez „umiejętności” (skills) – wyspecjalizowane pakiety instrukcji i narzędzi, które pozostają nieaktywne do momentu, gdy zapytanie użytkownika dopasuje się do ich opisu.

Struktura umiejętności (Skills) obejmuje: Global Scope: Dostępne we wszystkich produktach ekosystemu (lokalizacja: `~/.gemini/config/skills/`). Project Scope: Ograniczone do konkretnego repozytorium (lokalizacja: `/.agents/skills/`). * Metadata: Plik `SKILL.md` zawierający nazwę, opis oraz precyzyjne instrukcje dla modelu.

Użycie umiejętności pozwala na wdrożenie standardów zespołowych, takich jak automatyczna recenzja kodu pod kątem błędów i dobrych praktyk, bez konieczności każdorazowego wprowadzania tych reguł do promptu. SDK Antigravity pozwala dodatkowo na rejestrowanie dowolnych funkcji Pythona jako narzędzi (custom tools), które agent może wywoływać w trakcie realizacji zadania.

Analiza ryzyk, podatności i kwestii bezpieczeństwa

Wdrożenie Antigravity 2.0 wiąże się z konkretnymi ograniczeniami prawnymi i technicznymi, w tym brakiem certyfikacji SOC 2 Type II oraz brakiem formalnej umowy przetwarzania danych (DPA) zgodnej z GDPR (stan na maj 2026). Z perspektywy architekta IT, kluczowe ryzyko stanowi autonomia agentów, która przy braku odpowiednich barier może prowadzić do niepożądanych modyfikacji w krytycznych bazach kodu.

Zidentyfikowane podatności i ryzyka projektowe: Compute Credit Opacity: Google stosuje niejawny metrykę „wysiłku obliczeniowego”, co uniemożliwia precyzyjne budżetowanie kosztów przy złożonych zadaniach wieloagentowych. Infrastruktura Preview: Platforma wykazuje niestabilność; odnotowano przerwy w dostępie do modeli trwające od 44 minut do ponad 9 godzin. Lock-in: Głęboka integracja z Firebase jako domyślnym celem wdrożeniowym utrudnia migrację do innych dostawców chmurowych. Konflikty rozszerzeń: Jako fork VS Code, Antigravity nie obsługuje oficjalnego Marketplace Microsoftu, co wyklucza użycie narzędzi takich jak C# Dev Kit czy oficjalne rozszerzenie GitHub Authentication.

W celu mitygacji ryzyk zaleca się stosowanie mechanizmu git worktrees, co pozwala agentowi pracować w odizolowanym środowisku systemu plików, eliminując ryzyko uszkodzenia głównej gałęzi kodu przy błędnej interpretacji zadania przez model.

Wnioski praktyczne i rekomendacje

  • Skonfiguruj izolację projektów: Przypisuj agentom dostęp wyłącznie do niezbędnych folderów i ograniczaj uprawnienia MCP do zestawu narzędzi wymaganego przez dany stos technologiczny.
  • Wdróż mechanizm recenzji artefaktów: Nigdy nie ustawiaj polityki `Always Proceed` w projektach produkcyjnych; każdorazowo weryfikuj „Implementation Plan” oraz „Task List” przed ich zatwierdzeniem.
  • Zoptymalizuj budżet kontekstu: Przekształcaj powtarzalne instrukcje w „Skills” zamiast umieszczać je w długich wątkach konwersacji, co zredukuje konsumpcję tokenów.
  • Zabezpiecz proces wdrożenia: Wykorzystuj Antigravity głównie do szybkiego prototypowania i budowy szkieletów aplikacji (scaffolding), przenosząc hardening i audyt bezpieczeństwa do konserwatywnych narzędzi recenzenckich przed produkcją.
  • Monitoruj dostępność usługi: Korzystaj z zewnętrznych narzędzi monitorujących, takich jak StatusGator, aby unikać blokady prac deweloperskich w okresach niestabilności infrastruktury Google Antigravity.

Źródła

Przemysław Majdak

Przemysław Majdak · AI Automation Engineer

Założyciel Baluarte i wydawca BitBiz.pl. Członek ISSA Polska. Ekspert z 18-letnim stażem w branży IT — wdraża bezpieczne automatyzacje AI, systemy full-stack i zaawansowane procedury cyberbezpieczeństwa dla firm. Wszystkie artykuły autora →

2 odpowiedzi

💬 Kliknij tutaj, aby dodać komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

  1. Awatar KasiaZpodlasia
    KasiaZpodlasia

    No dobra, to „budżetowanie okna kontekstowego” w MCP przy orkiestracji agentów to jest konkret, o którym się mało mówi, a który w praktyce korporacyjnej potrafi zrobić większy bałagan niż zarządzanie uprawnieniami – ciekawe, czy Google faktycznie wprowadza jakieś twarde limity na poziomie protokołu, czy to tylko metaforyczne „budżetowanie” na potrzeby dokumentacji.

  2. Awatar Marek.K
    Marek.K

    Ciekawe, że przy całym szumie wokół agent-first w artykule przewija się coś, co rzadko kto waży się poruszać w praktyce – realne zarządzanie budżetem okna kontekstowego przez MCP. Większość pokazuje agentów jak magiczną skrzynkę, a tutaj od razu widać, że architektura 2.0 zakłada, że kontekst to ograniczony, kosztowny zasób, którym trzeba sterować tak samo jak pamięcią czy CPU w korporacyjnym deploymentcie. To zmienia narrację z „autonomia za wszelką cenę” na „autonomia w ramach kontrolowanego wycieku promptu”.