Google ADK: Agent Development Kit z natywną obsługą A2A

Google ADK (Agent Development Kit) to otwartoźródłowy framework firmy Google do budowy systemów jedno- i wieloagentowych z natywną obsługą protokołu A2A (Agent-to-Agent) i MCP (Model Context Protocol). Jest zoptymalizowany pod modele Gemini i Vertex AI i skierowany przede wszystkim do zespołów, których fundamentem jest Google Cloud. Produkcyjnie agenci działają na Vertex AI, Cloud Run, GKE lub we własnych kontenerach. Ścisłe powiązanie z Vertex AI i Gemini jest jednocześnie atutem i ryzykiem lock-inu.

• Czym jest: framework agentowy Google na warstwie SDK dostawcy, ściśle zintegrowany z Vertex AI i Gemini.
• Atut: natywna obsługa A2A i MCP, umożliwiająca współpracę agentów różnych dostawców.
• Kiedy ma sens: istniejący stos Google Cloud/Gemini i potrzeba interoperacyjności między agentami przez A2A.

Miejsce w stosie agentowym

W warstwowym modelu ekosystemu agentów Google ADK znajduje się na warstwie SDK dostawcy, na której ulokowane są także OpenAI SDK i Anthropic SDK. Powyżej leżą warstwy runtime'u agentów, frameworków oraz orkiestracji/platform, poniżej modele bazowe (foundation models), w kontekście Google przede wszystkim Google Gemini. W poprzek tych warstw przebiegają otwarte protokoły: MCP dla pionowej łączności z narzędziami (agent do narzędzia) i A2A dla poziomej komunikacji między agentami. Obok istnieją AGENTS.md jako konwencja repozytorium i AP2 jako rozszerzenie dla płatności realizowanych przez agentów.

W praktyce oznacza to, że w ADK definiujesz agentów jako komponowalne jednostki złożone z instrukcji, narzędzi i modelu, orkiestrujesz kilka z nich i udostępniasz je przez A2A innym agentom, także tym z obcych stosów. Jako podstawę techniczną ADK, podobnie jak wiele innych frameworków i SDK (OpenAI SDK, Anthropic SDK, LangChain, LlamaIndex, CrewAI), wykorzystuje Pydantic Validation, które zapewnia bezpieczne typowo struktury danych.

Natywna obsługa A2A: własny protokół Google

A2A to wkład Google w interoperacyjność agentów. Google zaprezentował protokół w kwietniu 2025 (na start z około 50 partnerami), a w czerwcu 2025 przekazał go Linux Foundation. Firma podarowała przy tym specyfikację wraz z narzędziami. Po wersji v0.3 (lipiec 2025), która wprowadziła podpisane Agent Cards, A2A osiągnął 12 marca 2026 wersję 1.0 (GA), pierwszą stabilną specyfikację. Z okazji pierwszej rocznicy Linux Foundation poinformowała 9 kwietnia 2026 o ponad 150 organizacjach wspierających, ponad 22 000 gwiazdek na GitHubie i SDK w pięciu językach (Python, JS, Java, Go, .NET).

W ADK protokół A2A, jako własny protokół Google, jest wbudowany bezpośrednio: agenci mogą współpracować z agentami innych dostawców, zamiast pozostawać w zamkniętym ekosystemie Google. MCP i A2A uzupełniają się, a nie konkurują: MCP standaryzuje dostęp do narzędzi (agent do narzędzia), a A2A komunikację między agentami (agent do agenta). ADK natywnie obsługuje obie osie.

Architektura wieloagentowa i wdrożenie

ADK umożliwia budowę zarówno pojedynczych agentów, jak i wielu współpracujących ze sobą agentów. Typowe wzorce (sekwencje, wykonywanie równoległe oraz struktury hierarchiczne lub supervisor-worker) można odwzorować i dzięki A2A łączyć także ponad granicami stosów. Jako zarządzane środowisko uruchomieniowe Google oferuje Agent Runtime, do kwietnia 2026 pod nazwą Vertex AI Agent Engine. Od tego czasu sam Vertex AI jest częścią Gemini Enterprise Agent Platform. Agenci ADK działają jednak także na Cloud Run, GKE lub w dowolnym własnym kontenerze, lokalnie w Dockerze lub Podmanie, a także u europejskich dostawców hostingu. ADK jest zoptymalizowany pod Gemini. W Pythonie inne modele, na przykład od OpenAI, Anthropic lub samodzielnie hostowane modele otwarte, podłączasz przez LiteLLM.

Dla wdrożeń w Europie kluczowa jest ścieżka hostingu: Gemini przez Vertex AI można uruchamiać w regionach UE, co może wspierać rezydencję danych w UE. Ponieważ jednak Google jest amerykańskim dostawcą, dyskusja wokół CLOUD Act pozostaje aktualna. Dotyczy to w tym samym stopniu innych amerykańskich dostawców chmury. Na tej ścieżce profil uzależnienia od dostawcy jest wysoki (natywnie Google). Jeśli sam hostujesz ADK i podłączasz inne modele, wyraźnie ograniczasz lock-in, ale tracisz korzyść z integracji z Vertex AI i Gemini. A2A i MCP pozostają. Znaczenie dla regionu DACH jest średnie: realne, ale mniejsze niż w środowiskach skoncentrowanych na Microsofcie lub Salesforce.

Porównanie z LangGraph, CrewAI i innymi

Poniższa tabela porównuje Google ADK z najczęściej używanymi alternatywami typu code-first. Stan na 2026 rok; wersje i poziom dojrzałości to migawki, które należy sprawdzić przed rozpoczęciem projektu.

Różnice można sprowadzić do trzech punktów. LangGraph to niskopoziomowy framework orkiestracji dla stanowych, długotrwałych, wieloetapowych workflowów z durable execution, checkpointingiem i dojrzałą obserwowalnością (LangSmith); uchodzi za najpopularniejszy otwartoźródłowy runtime orkiestracji w zespołach inżynierskich w regionie DACH i jest niezależny od dostawcy. CrewAI wygrywa przy najszybszym prototypowaniu systemów wieloagentowych opartych na rolach, ale działa tylko w Pythonie i mniej rygorystycznie podchodzi do trwałego stanu. Google ADK nie czerpie przewagi z głębszej logiki grafowej, lecz z natywnego powiązania z Vertex AI, Gemini i światem protokołów A2A/MCP. Jeśli nie masz fundamentu w Google Cloud, z ADK rzadko zyskasz w porównaniu z alternatywami niezależnymi od dostawcy.

Krótki przykład: pipeline wieloagentowy z A2A

Załóżmy, że agencja buduje dla klienta B2B pipeline do researchu i raportowania w Google Cloud. Struktura w pseudokodzie:

```text
research_agent = Agent(
model = "gemini", # warstwa modeli bazowych
tools = [web_search_mcp], # dostęp do narzędzi przez MCP
instruction = "Zbadaj rynek X i podsumuj źródła."
)

report_agent = Agent(
model = "gemini",
instruction = "Utwórz ustrukturyzowany raport na podstawie wyników."
)

pipeline = SequentialAgent([research_agent, report_agent])

Wdrożenie: Vertex AI

deploy(pipeline)

Udostępnienie agentom zewnętrznym przez A2A (Signed Agent Card)

expose_via_a2a(pipeline)
```

Kluczowy krok to ostatnia linia: dzięki A2A pipeline staje się dla zewnętrznych agentów (np. z Microsoft Agent Framework lub ze stosu CrewAI) wykrywalny i wywoływalny jako współpracujący peer, a druga strona nie musi znać kodu specyficznego dla Google. Właśnie to rozdzielenie jest sensem warstwy protokołów: wybór frameworka staje się drugorzędny wobec interoperacyjności.

Dla agencji i decydentów B2B

Dla agencji Google ADK jest istotny, gdy klienci są już zakorzenieni w Google Cloud lub strategicznie postawili na Gemini. Najszybsza dźwignia leży wtedy nie w zastrzeżonych pipeline'ach, lecz w konsekwentnym korzystaniu z A2A i MCP. Dzięki temu prompty, narzędzia i zestawy ewaluacyjne pozostają niezależne od frameworka, a późniejsza zmiana jest realna. Dla decydentów B2B: oceniaj ADK pod kątem stosu językowego, wymagań dotyczących suwerenności i potrzeb wieloagentowych, a nie liczby gwiazdek na GitHubie.

Jeśli celem jest niezależność od dostawcy lub ścisła suwerenność w Europie bez amerykańskiej chmury, również ADK można hostować samodzielnie i używać z innymi modelami. Korzyść z integracji z Vertex AI i Gemini znika wtedy, ale A2A i MCP pozostają. Zwykle bardziej sensownym wyborem są w takim przypadku samodzielnie hostowany LangGraph (np. na STACKIT, IONOS lub OVHcloud), samodzielnie hostowany Pydantic AI albo n8n (Berlin). Region UE usługi Logfire, czyli serwisu obserwowalności od Pydantic, działa jednak na Google Cloud w Holandii. Informacje dotyczące RODO i unijnego AI Act mają charakter informacyjny i nie zastępują porady prawnej. Blck Alpaca pomaga w wyborze frameworka, projektowaniu interoperacyjności A2A/MCP i wyborze suwerennej ścieżki hostingu. Odezwij się do nas, aby przeprowadzić rzetelną ewaluację.