A2A vs MCP: Dwa uzupełniające się protokoły dla rozwijającego się ekosystemu agentów

Coraz powszechniejsze stosowanie agentów AI — autonomicznych lub półautonomicznych jednostek programowych wykonujących rozumowanie i działania w imieniu użytkowników — prowadzi do powstania nowej warstwy w architekturze aplikacji.

Na początku 2025 roku pojawiły się dwa odrębne protokoły, które mają na to odpowiedzieć — A2A (Agent-to-Agent, Agent do Agenta) i MCP (Model Context Protocol, Protokół Kontekstu Modelu). Prostym sposobem na zrozumienie ich ról jest:

A2A: Jak agenci interagują ze sobą

MCP: Jak agenci interagują z narzędziami lub zewnętrznym kontekstem

źródło: https://google.github.io/A2A/#/topics/a2a_and_mcp

Zajmują się one podstawowym wyzwaniem tworzenia systemów z wieloma agentami, wieloma LLM i wieloma źródłami kontekstu — wszystkie muszą współpracować.

Można to ująć tak: „MCP zapewnia integrację pionową (aplikacja-do-modelu), a A2A zapewnia integrację poziomą (agent-do-agenta)

Niezależnie od tego, czy jesteś deweloperem, czy nie, każdy, kto tworzy produkty AI lub systemy agentów, powinien zrozumieć podstawową architekturę — ponieważ kształtuje to, jak projektujemy produkty, interakcje użytkowników, ekosystemy i długoterminowy rozwój.

Ten artykuł wprowadza oba protokoły w prosty i łatwy do zrozumienia sposób, a także podkreśla kluczowe wnioski dla deweloperów i twórców produktów AI.

Czym jest A2A (Agent-to-Agent)?#

A2A (Agent-to-Agent) to otwarty protokół opracowany przez Google i ponad 50 partnerów z branży. Jego celem jest umożliwienie interoperacyjności między agentami — niezależnie od tego, kto je stworzył, gdzie są hostowane lub jakiej używają struktury.

Mechanizm protokołu A2A#

A2A wykorzystuje JSON-RPC 2.0 przez HTTP(S) jako mechanizm komunikacji, z obsługą Server-Sent Events (SSE) do przesyłania aktualizacji.

Modele komunikacji A2A#

A2A definiuje ustrukturyzowany model, w jaki sposób dwa agenci interagują. Jeden agent przyjmuje rolę agenta „klienta”, który inicjuje żądanie lub zadanie, a drugi działa jako agent „zdalny”, który odbiera żądanie i stara się je zrealizować. Agent klienta może najpierw przeprowadzić odkrywanie zdolności, aby określić, który agent najlepiej nadaje się do danego zadania.

Jak agenci się odkrywają? Każdy agent może opublikować Kartę Agenta (dokument metadanych JSON, często hostowany pod standardowym URL-em jak /.well-known/agent.json) opisującą swoje zdolności, umiejętności, punkty końcowe API i wymagania dotyczące autoryzacji.

Czytając Kartę Agenta, agent klienta może zidentyfikować odpowiedniego agenta partnerskiego do danego zadania — w zasadzie katalog tego, co agent wie lub potrafi zrobić. Po wybraniu docelowego agenta, agent klienta formułuje obiekt Zadanie do wysłania.

źródło: https://google.github.io/A2A/#/

Zarządzanie zadaniami#

Cała interakcja w A2A jest ukierunkowana na wykonywanie zadań. Zadanie to ustrukturyzowany obiekt (zdefiniowany przez schemat protokołu) zawierający szczegóły żądania i śledzący jego stan.

W A2A każdy agent odgrywa jedną z dwóch ról:

• Agent klienta: inicjuje zadanie
• Agent zdalny: odbiera i przetwarza zadanie

Zadania mogą obejmować wszelkie prace: generowanie raportu, pobieranie danych, inicjowanie przepływu pracy. Wyniki są zwracane jako artefakty, a agenci mogą wysyłać ustrukturyzowane wiadomości podczas wykonywania, aby się koordynować lub wyjaśniać.

Współpraca i negocjacja zawartości#

A2A obsługuje więcej niż proste żądania zadań — agenci mogą wymieniać się bogatymi, wieloczęściowymi wiadomościami zawierającymi tekst, JSON, obrazy, wideo lub interaktywną zawartość. To umożliwia negocjację formatu w oparciu o to, co każdy agent może obsłużyć lub wyświetlić.

Na przykład agent zdalny mógłby zwrócić wykres jako surowe dane lub jako obraz, lub poprosić o otwarcie interaktywnego formularza. Ten projekt wspiera elastyczną, agnostyczną modalność komunikacji, bez potrzeby dzielenia się agentami wewnętrznymi narzędziami lub pamięcią.

Przykład wykorzystania#

Oto przykład z życia wzięty zastosowania A2A w scenariuszu korporacyjnym:

Nowy pracownik zostaje zatrudniony w dużej firmie. W proces zaadaptowania jest zaangażowanych wiele systemów i działów:

• Dział kadr musi utworzyć zapis i wysłać e-mail powitalny
• Dział IT musi dostarczyć laptopa i konta firmowe
• Dział administracyjny musi przygotować miejsce pracy i kartę dostępu

Tradycyjnie, te kroki są obsługiwane ręcznie lub przez ściśle ze sobą powiązane integracje pomiędzy wewnętrznymi systemami.

Zamiast niestandardowych API między każdym systemem, każdy departament udostępnia swojego agenta przy użyciu protokołu A2A:

System wieloagentowy — nazwijmy go OnboardingPro (np. onboarding-agent.company.com) — koordynuje cały przepływ adaptacji.

1. Odkrywanie: Odczytuje .well-known/agent.json każdego agenta, aby zrozumieć zdolności i autoryzację.
2. Delegowanie zadań:
   • Wysyła zadanie createEmployee do agenta kadr.
   • Wysyła zadania setupEmailAccount i orderHardware do agenta IT.
   • Wysyła assignDesk i generateBadge do agenta działu administracyjnego.
3. Transmisja aktualizacji: Agenci transmitują postęp za pomocą Server-Sent Events (np. „laptop wysłany”, „miejsce pracy przydzielone”).
4. Zbieranie artefaktów: Końcowe wyniki (np. karta identyfikacyjna PDF, e-maile potwierdzające, dane uwierzytelniające konta) są zwracane jako artefakty A2A.
5. Zakończenie: OnboardingPro powiadamia menedżera zatrudniającego po zakończeniu procesu adaptacji.

Czym jest MCP (Model Context Protocol)?#

MCP (Model Context Protocol), opracowany przez Anthropic, zajmuje się innym problemem: jak zewnętrzne aplikacje mogą dostarczać ustrukturyzowany kontekst i narzędzia do agenta opartego na modelu językowym w czasie rzeczywistym.

Zamiast umożliwiania komunikacji między agentami, MCP koncentruje się na oknie kontekstowym — pamięci roboczej LLM. Jego celem jest:

• Dynamiczne wstrzykiwanie odpowiednich narzędzi, dokumentów, funkcji API lub stanu użytkownika do sesji inferencyjnej modelu
• Pozwól modelom na wywoływanie funkcji lub pobieranie dokumentów bez kodowania na sztywno podpowiedzi lub logiki

Kluczowa architektura MCP#

Aby zrozumieć MCP, najpierw musisz zrozumieć ogólną architekturę — jak wszystkie części współpracują ze sobą.

Host MCP: „AI, z którym rozmawiasz”#

Pomyśl o hoscie MCP jak o samej aplikacji AI — na przykład Claude Desktop lub twoim asystencie kodującym.

To interfejs, którego używasz — miejsce, w którym piszesz lub rozmawiasz.

Chce wykorzystać narzędzia i dane, które pomagają modelowi dawać lepsze odpowiedzi.

Klient MCP: „Łącznik”#

Klient MCP to element oprogramowania, który łączy twojego hosta AI (jak Claude) ze światem zewnętrznym. Jest jak centrala telefoniczna — zarządza bezpiecznymi, jednopołączeniowymi połączeniami z różnymi serwerami MCP. Kiedy AI chce uzyskać dostęp do czegoś, działa przez klienta.

Łatwo jest sobie wyobrazić narzędzia takie jak ChatGPT, Claude chat czy Cursor IDE jako hosty MCP — zapewniają interfejs, z którym się wchodzicie w interakcje. W tle korzystają z klienta MCP, aby łączyć się z różnymi narzędziami i źródłami danych poprzez serwery MCP.

źródło: https://modelcontextprotocol.io/introduction

Serwer MCP: „Dostawca narzędzi”#

Serwer MCP to mały, wyspecjalizowany program, który udostępnia jedno konkretne narzędzie lub funkcję — na przykład:

• Wyszukiwanie plików na komputerze
• Wyszukiwanie danych w lokalnej bazie danych
• Wywoływanie zewnętrznego API (takiego jak pogoda, finanse, kalendarz)

Każdy serwer przestrzega protokołu MCP, więc AI może zrozumieć, co może zrobić i jak go wywołać.

Lokalne źródła danych: „Twoje własne pliki i usługi”#

Niektóre serwery MCP łączą się z rzeczami na twoim własnym urządzeniu — jak:

• Dokumenty i foldery
• Projekty kodu
• Bazy danych lub lokalne aplikacje

To pozwala AI przeszukiwać, pobierać lub obliczać rzeczy bez przesyłania twoich danych do chmury.

Usługi zdalne: „API i narzędzia online”#

Inne serwery MCP są połączone z internetem — łączą się z:

• API (np. Stripe, Notion, GitHub)
• Narzędzia SaaS
• Firmowe bazy danych w chmurze

Więc AI może powiedzieć, na przykład: „Wywołaj serwer GitHub i pobierz listę otwartych PRs”.

MCP teraz obsługuje łączenie z zdalnymi serwerami MCP. To oznacza, że klient MCP może zyskać potężniejsze możliwości. Teoretycznie,

Z odpowiednim zestawem serwerów MCP użytkownicy mogą przekształcić każdego klienta MCP w "wszystko aplikację".

źródło: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Jak to wszystko się łączy#

Użyjmy teraz diagramu, aby zobaczyć, jak wszystko się łączy.

1. Zadajesz AI skomplikowane pytanie
2. AI (host) prosi klienta o pomoc
3. Klient wywołuje właściwy serwer MCP — może taki, który sprawdza pliki lub wywołuje API
4. Serwer przesyła dane lub wykonuje funkcję
5. Wynik trafia z powrotem do modelu, aby pomóc mu w ukończeniu zadania

A2A vs MCP — Porównanie#

Jak one współpracują#

Zamiast być alternatywami, A2A i MCP są uzupełniające się. W wielu systemach oba będą używane razem.

Przykład przepływu pracy#

1. Użytkownik przesyła skomplikowane żądanie w interfejsie agenta korporacyjnego.
2. Agent koordynujący korzysta z A2A, aby delegować podzadania do wyspecjalizowanych agentów (np. analityka, kadry, finanse).
3. Jeden z tych agentów używa wewnętrznie MCP, aby wywołać funkcję wyszukiwania, pobrać dokument lub coś obliczyć za pomocą modelu.
4. Wynik jest zwracany jako artefakt poprzez A2A, umożliwiając końcową współpracę agentów z modułowym dostępem do narzędzi.

Ta architektura rozdziela komunikację między agentami (A2A) od wywoływania zdolności wewnątrz agentów (MCP) — co sprawia, że system jest łatwiejszy do kompozycji, skalowania i zabezpieczenia.

Podsumowanie#

A2A dotyczy rozmowy agentów z innymi agentami poprzez sieć — bezpiecznie, asynchronicznie i skoncentrowane na zadaniach.

MCP dotyczy wstrzykiwania ustrukturyzowanych zdolności do sesji modelu, pozwalając LLM na rozumowanie nad narzędziami i danymi kontekstowymi.

Używane razem, wspierają kompozycyjność, systemy wieloagentowe, które są zarówno rozszerzalne, jak i interoperacyjne.

Jak podstawowa infrastruktura MCP + A2A mogłaby kształtować przyszłość rynku produktów agentów#

Na koniec, chcę omówić, jak ta podstawowa infrastruktura techniczna mogłaby kształtować przyszłość rynku AI — i co to oznacza dla osób budujących produkty AI.

Zmiana interakcji człowiek-komputer#

Jasnym przykładem tej zmiany można zobaczyć w przepływach pracy deweloperów i usług. Dzięki integracji serwerów MCP z IDE i agentami kodującymi, sposób interakcji deweloperów z narzędziami fundamentalnie się zmienia.

Wcześniej typowy przepływ pracy polegał na wyszukiwaniu odpowiedniej usługi, konfigurowaniu hostingu, czytaniu dokumentacji, ręcznej integracji API, pisaniu kodu w IDE i konfigurowaniu funkcji za pomocą panelu niskokodowego. Było to doświadczenie fragmentaryczne, wymagające przełączania kontekstu i technicznych kosztów na każdym kroku.

Teraz, dzięki agentom kodującym połączonym z MCP, znaczna część tej złożoności może zostać usunięta. Deweloperzy mogą odkrywać i używać narzędzi bardziej naturalnie za pomocą poleceń konwersacyjnych. Integracja API staje się częścią samego przepływu kodowania — często bez potrzeby oddzielnego interfejsu użytkownika czy ręcznej konfiguracji. (Pomyśl tylko, jak skomplikowane mogą być panele kontrolne AWS czy Microsoftu). Interakcja staje się bardziej płynna — bardziej polega na kierowaniu zachowaniem niż składa się z funkcji.

W tym modelu, interakcja użytkownika lub dewelopera przesuwa się z konfigurowania funkcji do orkiestracji zachowań. To również zmienia rolę projektowania produktów.

Zamiast używać interfejsów użytkownika do „zakrywania” technicznych wyzwań (np. „to za trudne do kodowania, zróbmy panel konfiguracyjny”), teraz musimy:

• Myśleć o doświadczeniu końcowym
• Projektować, jak i kiedy interakcje AI + użytkownik powinny się łączyć
• Pozwalać AI obsługiwać logikę, i prowadzić użytkowników poprzez intencję i przepływ

Wyzwanie polega na decydowaniu, kiedy i jak AI i użytkownik powinni się łączyć, pozwolić AI na obsługę logiki, i prowadzić użytkowników poprzez intencję i przepływ oraz jak wstawić odpowiednie interakcje w odpowiednim czasie.

Użyłem producenta usług deweloperskich i produktu API jako przykładu, aby pokazać, jak mogłaby się zmienić interakcja użytkownika — ale to samo dotyczy oprogramowania biznesowego. Przez długi czas narzędzia biznesowe były skomplikowane i trudne w użyciu. Interakcja języka naturalnego ma potencjał, aby uprościć wiele z tych przepływów pracy.

Paradygmaty produktów agentowych i ich wpływ na SaaS#

Zaczynamy widzieć, jak powstaje coraz większa liczba serwerów MCP. Wyobraź sobie Airbnb oferujące serwer MCP do rezerwacji, lub Google Maps wystawiające serwer MCP mapy. Agent (jako klient MCP) mógłby jednocześnie łączyć się z wieloma z tych serwerów — odblokowując przepływy pracy, które wcześniej wymagały niestandardowych integracji lub ściśle związanych aplikacji.

W porównaniu do ery SaaS, kiedy integracje były często ręczne i sztywne, ten model umożliwia bardziej autonomiczne przepływy pracy i elastyczne połączenia między usługami. Oto dwa przykłady:

1. Projektowanie z dokumentów

   Piszesz PRD w Notion. Agent Figma odczytuje dokument i automatycznie tworzy szkic, który rozkłada główne koncepcje — bez potrzeby ręcznego przekazywania.

2. Badanie konkurencji, od początku do końca

   Prosisz o analizę konkurencji. Grupa agentów przeszukuje internet, rejestruje się do odpowiednich usług w twoim imieniu (z bezpiecznym uwierzytelnieniem), zbiera wyniki i dostarcza artefakty z powrotem — już zorganizowane w twoim workspace Notion.

Wyzwania związane z granicami uwierzytelnienia i autoryzacji#

Wraz z rosnącą liczbą połączeń między agentem a agentem, połączenia między klientem MCP a serwerem MCP, istnieje wiele ukrytych potrzeb dotyczących uwierzytelnienia i autoryzacji, ponieważ agent będzie działał w imieniu człowieka, a użytkownicy i dane uwierzytelniające muszą być zabezpieczone na tej drodze.

Do tej pory istnieje kilka scenariuszy specyficznych dla nowego wzrostu połączeń między agentem a agentem i MCP.

1. Agent vs SaaS & WebsiteApp
2. Klient MCP (Agent) vs Serwer MCP
3. Użytkownik vs Agent
4. Agent vs Agent

Innym interesującym przypadkiem użycia jest federacja wielotożsamości Google wspomniana:

Na przykład, Użytkownik U współpracuje z Agentem A wymagającym identyfikatora A-systemu. Jeśli Agent A zależy od Narzędzia B lub Agenta B, który wymaga identyfikatora B-systemu, użytkownik może potrzebować dostarczyć tożsamości zarówno dla A-systemu, jak i B-systemu w jednym zapytaniu. (Zakładając, że A-system to tożsamość LDAP przedsiębiorstwa, a B-system to tożsamość dostawcy SaaS).

Logto to dostawca OIDC i OAuth, dobrze dostosowany do przyszłości integracji AI.

Dzięki swojej elastycznej infrastrukturze, aktywnie rozszerzamy jego zdolności i opublikowaliśmy serię samouczków, aby pomóc deweloperom szybko zacząć.

Czy masz pytania?

Skontaktuj się z nami — albo zanurz się i odkryj, co możesz zbudować z Logto już dziś.