Agent Cards: jak agenci znajdują się nawzajem (A2A Discovery)

Agent Card to czytelny maszynowo dokument JSON w protokole A2A, za pomocą którego agent AI publikuje swoją tożsamość, swój endpoint, umiejętności, możliwości, modalności i schematy uwierzytelniania. Inni agenci odczytują tę kartę, aby zdecydować, czy i jak zlecić agentowi zadanie. Agent Card jest więc centralnym mechanizmem, dzięki któremu agenci znajdują się nawzajem, bez potrzeby wcześniejszego sztywnego łączenia ich ze sobą.

• Czym jest: publiczny profil agenta, wizytówka i opis interfejsu w jednym.
• Do czego służy: do wykrywania agentów. Agent kliencki sprawdza umiejętności, modalności i uwierzytelnianie, zanim zleci zadanie (task).
• Dlaczego ma znaczenie: bez Agent Card agent jest niewidoczny dla innych systemów i dostępny tylko przez niestandardową integrację.

A2A, MCP i rola Agent Card

W stosie protokołów w 2026 roku upowszechniły się dwa otwarte standardy. Opracowany przez Anthropic Model Context Protocol (MCP) reguluje dostęp agentów do narzędzi i danych, czyli komunikację agent-narzędzie. Od grudnia 2025 roku MCP należy do Agentic AI Foundation działającej pod egidą Linux Foundation. Protokół Agent2Agent (A2A) reguluje współpracę między agentami, czyli komunikację agent-agent. Dokumentacja A2A rozgranicza oba protokoły następująco: przez MCP agent korzysta z funkcji takich jak narzędzia i zasoby, a przez A2A agenci współpracują jako partnerzy nad zadaniem. Oba protokoły się uzupełniają.

Agent Card jest elementem A2A odpowiedzialnym za wykrywanie możliwości. Tam, gdzie serwer MCP opisuje pojedyncze narzędzia, Agent Card opisuje całego agenta jako potencjalnego partnera do współpracy. A2A zaprezentowano w kwietniu 2025 roku na Google Cloud Next, a 23 czerwca 2025 roku przekazano Linux Foundation; członkami założycielami zostały AWS, Cisco, Google, Microsoft, Salesforce, SAP i ServiceNow. Protokół wspiera obecnie ponad 100 firm (stan na 2026 rok).

Budowa Agent Card

Agent Card to dokument JSON, który agent publikuje pod znaną ścieżką swojego hosta. Zawiera następujące kluczowe elementy:

Kluczowa jest zasada projektowa, która za tym stoi: A2A definiuje, jak agenci rozmawiają ze sobą, a nie jak myślą. Wewnętrzna budowa zdalnego agenta, czyli jego prompty, model i pamięć, celowo pozostaje nieprzejrzysta. Właśnie to pozwala agentowi Salesforce wywołać agenta SAP bez ujawniania przez którąkolwiek ze stron promptów, modelu czy danych. Karta jest jedynym kontraktem, który obie strony dzielą.

Mechanizm wykrywania

Wykrywanie przez Agent Cards przebiega w dwóch typowych wariantach.

Wykrywanie bezpośrednie (punkt-punkt). Agent kliencki zna bazowy URL zdalnego agenta i pobiera jego Agent Card. Sprawdza, czy zadeklarowane umiejętności pasują do zadania, czy potrzebna modalność jest obsługiwana i czy jest w stanie obsłużyć schemat uwierzytelniania. Dopiero wtedy otwiera zadanie.

Wykrywanie oparte na katalogu (rejestr). W większych środowiskach Agent Cards rejestruje się centralnie. Zainicjowany przez Cisco projekt open source AGNTCY udostępnia w tym celu Agent Directory: sfederowany rejestr, w którym można publikować, weryfikować i wyszukiwać agentów A2A i serwery MCP. Umiejętności i atrybuty opisuje on za pomocą Open Agentic Schema Framework (OASF). Dzięki temu agent znajduje odpowiednich partnerów przez katalog, a nie przez adresy zapisane na sztywno. SAP łączy porównywalną funkcję w SAP AI Agent Hub w SAP LeanIX. Hub pomyślano jako niezależne od dostawcy centrum sterowania, w którym firmy mogą wyszukiwać, inwentaryzować i nadzorować agentów SAP i innych dostawców oraz serwery MCP. W październiku 2026 roku SAP określa hub jako ogólnie dostępny.

Gdy partner zostanie znaleziony, do gry wchodzi cykl życia zadania A2A. Zgodnie ze specyfikacją A2A zadanie przechodzi przez stany submitted i working, wstrzymuje się w stanie input-required przy pytaniach zwrotnych lub w stanie auth-required, gdy potrzebne jest dodatkowe uwierzytelnienie, i kończy się w stanie completed, failed, canceled lub rejected. W JSON-ie specyfikacji 1.0 stany te nazywają się TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED i tak dalej. Transport odbywa się przez JSON-RPC 2.0 i HTTPS, a specyfikacja definiuje dodatkowo bindingi dla gRPC i HTTP+JSON. Stany pośrednie są strumieniowane przez Server-Sent Events, a dla długich przebiegów dostępne są opcjonalne powiadomienia push. Wynik zadania wraca jako jeden lub więcej Artifacts, a wiadomości mogą być wieloczęściowe i multimodalne.

Po stronie badań projekt NANDA z MIT Media Lab pokazuje, dokąd wykrywanie może zmierzać w dłuższej perspektywie: zdecentralizowany indeks agentów z kryptograficznie weryfikowalnymi AgentFacts i Zero Trust Agentic Access. W 2026 roku jest to jednak wciąż etap badawczy, a nie podstawa decyzji produkcyjnych.

Przykład: wykrywanie między dwoma agentami

Załóżmy, że agent CRM w Salesforce ma zlecić wstępną weryfikację przychodzących faktur od dostawców i w tym celu skorzystać z wyspecjalizowanego agenta do obsługi faktur przygotowanego przez agencję.

Agent Card agenta do obsługi faktur, skrócona i z nazwami pól ze specyfikacji A2A 1.0:

• "name": "Invoice-Triage-Agent", "version": "2.0.0"
• "supportedInterfaces": [{ "url": "https://agents.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }]
• "capabilities": { "streaming": true, "pushNotifications": true }
• "defaultInputModes": ["text/plain", "application/pdf"], "defaultOutputModes": ["application/json"]
• "securitySchemes": { "oauth": { "oauth2SecurityScheme": { "flows": { … } } } }
• "skills": [{ "id": "klassifiziere_rechnung", "name": "Rechnung klassifizieren", "description": "Liefert Kategorie und Konfidenz (0 bis 1)", "tags": ["rechnung"] }]

Przebieg:

1. Agent CRM pobiera kartę: GET https://agents.example.com/.well-known/agent-card.json
2. Sprawdza: umiejętność pasuje, format wejściowy i OAuth 2.0 są obsługiwane.
3. Otwiera zadanie przez POST https://agents.example.com/a2a, a zadanie startuje w stanie TASK_STATE_SUBMITTED.
4. Zadanie przechodzi przez TASK_STATE_WORKING i kończy się w TASK_STATE_COMPLETED. Jako Artifact wraca: { "kategorie": "Wareneingang", "konfidenz": 0.94 }

Agent CRM nie musiał nic wiedzieć o wewnętrznym modelu ani promptach agenta do obsługi faktur. Wyłącznie na podstawie karty zdecydował, że ten agent może wykonać zadanie, a następnie zlecił mu je przez ustandaryzowany kontrakt zadania. Właśnie to rozdzielenie umożliwia przepływy pracy obejmujące platformy różnych dostawców, takie jak Agentforce, Joule i Copilot Studio. W przypadku Joule SAP zapowiedział w maju 2026 roku, że dwukierunkowe funkcje A2A będą ogólnie dostępne w czwartym kwartale 2026 roku.

Bezpieczeństwo i nadzór

Każde nowe połączenie między agentami to nowa granica zaufania, a tym samym nowa powierzchnia ataku. Szczególnie istotne są tu cztery ryzyka: naruszenia granic zaufania, ponieważ każdy peer A2A jest dla pozostałych nieprzejrzysty; dryf możliwości, gdy karta obiecuje więcej, niż agent faktycznie potrafi bezpiecznie zrealizować; luki w ścieżce audytu, gdy tylko wiadomości przekraczają granice procesów; oraz wzmacnianie ataków prompt injection, ponieważ każdy dodatkowy kontekst agenta to kolejna okazja do obejścia zabezpieczeń. Ryzyko pośredniego prompt injection (XPIA) rośnie z każdym agentem, który przetwarza niezaufane treści.

Praktyczne konsekwencje dla wdrożeń w Europie: tokeny o ograniczonym zakresie i krótkim czasie życia dla każdego zadania, zasada najmniejszych uprawnień dla umiejętności deklarowanych w karcie, ciągłe identyfikatory korelacji dla każdego zadania A2A oraz brak własnościowych rozszerzeń semantyki kart lub zadań, które podważałyby właśnie tę przenośność, dla której wybiera się A2A. W regulowanych przepływach pracy odtwarzalność wymaga rejestrowania użytych Agent Cards w każdym przebiegu i przypinania wersji modeli.

Dla agencji i B2B

Dla agencji marketingowych i cyfrowych w Europie publikowanie Agent Cards to najważniejsza dźwignia produktowa w 2026 roku. Tylko agenta, którego można wykryć przez A2A, da się wywołać bezpośrednio ze środowisk Salesforce, SAP Joule lub Copilot Studio Twoich klientów, bez budowania osobnej integracji dla każdego klienta. Kto pomija Agent Cards, zostaje na stałe skazany na ręczną integrację. Nasza rekomendacja: dyscyplina w zakresie kart od pierwszego dnia, wymuszanie typowanych kontraktów wyjściowych (np. przez Pydantic lub JSON Schema) i wymóg posiadania karty przez każdego agenta oferowanego jako produkt, zanim trafi na produkcję.

Dla decydentów B2B kluczowe jest pytanie zakupowe: czy Twoja umowa na Agentforce, Joule lub Copilot Studio gwarantuje interoperacyjność A2A i zgodność ze standardem MCP? I czy zawiera klauzule dotyczące publikowania Agent Cards oraz wyjścia z umowy? Blck Alpaca pomaga Ci projektować agentów zgodnych z A2A, starannie modelować Agent Cards i osadzać je w architekturze wykrywania, która spełnia wymogi nadzoru.