Az A2A protokoll: agent cardok, taskok, és a helye az MCP mellett

Az ágenseszközök eddig többnyire egy ágensről és az eszközeiről szóltak. A következő probléma akkor jelenik meg, amikor két, különböző csapat által épített ágensnek együtt kell dolgoznia: a webshopod beszerzési ágense meg akarja kérdezni egy beszállító készletágensét, vagy egy belső support-ágens átad egy ügyet a logisztikai csapat ágensének. Mindkét oldalnak saját keretrendszere, modellje és telepítése van. Közös protokoll nélkül minden ilyen párosítás egyedi integráció.

Az Agent2Agent (A2A) erre a problémára született nyílt protokoll. Ez a cikk elmagyarázza, mit szabványosít ténylegesen a specifikáció 1.0-s verziója – agent cardokat, taskokat, üzeneteket, átviteli módokat és biztonságot –, hogyan viszonyul az MCP-hez, milyen bizalmi problémákat nem old meg helyetted, és mikor használnám.

Mi az A2A protokoll?

A Google 2025. április 9-én jelentette be az A2A-t több mint 50 technológiai partnerrel, meglévő szabványokra, köztük a HTTP-re, az SSE-re és a JSON-RPC-re építve. Öt tervezési elve: az ágensképességek felvállalása, építkezés meglévő szabványokra, alapértelmezett biztonság, hosszan futó taskok támogatása és modalitásfüggetlenség. 2025. június 23-án a Linux Foundation elindította az Agent2Agent projektet az Open Source Summit North America konferencián, több mint 100 cég támogatásával, így az irányítás kikerült egyetlen szállító kezéből.

A jelenlegi specifikáció az 1.0.0-s verzió, a 0.1.0, a 0.2.6 és a 0.3.0 után. A kompatibilitást a fő- és alverzió jelzi, a kliensek A2A-Version fejlécet küldenek. A 2026. április 9-i egyéves összefoglalójában a Linux Foundation az 1.0-t az első stabil specifikációnak nevezte, és több mint 150 támogató szervezetről, öt nyelven (Python, JavaScript, Java, Go és .NET) elérhető SDK-król, valamint az Azure AI Foundry, a Copilot Studio és az Amazon Bedrock AgentCore Runtime támogatásáról számolt be.

Hogyan viszonyul az A2A az MCP-hez?

Az A2A dokumentációja a kettőt egymást kiegészítő rétegként írja le. Az MCP vertikális: egy ágensnek strukturált hozzáférést ad eszközökhöz és erőforrásokhoz, amelyek jellemzően jól definiáltak és gyakran állapotmentesek. Az A2A horizontális: független, gyakran átláthatatlan ágensek egyenrangúként működnek együtt, mindkét oldalon reasoninggel, állapottal és többkörös párbeszéddel. A dokumentáció szavaival: „A2A connects the agents to each other; MCP connects each agent to its own tools.”

Az átfedés valós: egy néhány állapotmentes skillel rendelkező A2A-ágens becsomagolható MCP-szerverként, ezt a dokumentáció is kimondja. Az ökölszabályom: ha a másik oldal függvényként viselkedik, MCP; ha visszakérdez, percekig vagy órákig dolgozik, vagy meg akarja tartani magának a reasoningjét, A2A. Az MCP-oldalhoz lásd az MCP biztonsági ellenőrzőlistát.

Mi van egy agent cardban?

Az agent card egy JSON-dokumentum, amelyben egy A2A-szerver leírja önmagát. A normatív adatmodell az a2a.proto; az AgentCard kötelező mezői a név, a leírás, a támogatott interfészek, a verzió, a képességek, az alapértelmezett bemeneti és kimeneti módok, valamint a skillek. Minden interfész megad egy URL-t, egy protokoll-bindinget (JSONRPC, GRPC vagy HTTP+JSON) és egy protokollverziót. Minden skillnek van azonosítója, neve, leírása és címkéi, opcionálisan példái, saját bemeneti és kimeneti módjai és biztonsági követelményei.

// https://agents.supplier.example/.well-known/agent-card.json (illustrative)
{
  "name": "Parts Availability Agent",
  "description": "Answers stock and lead-time questions for industrial spare parts.",
  "version": "2.3.0",
  "provider": { "organization": "Example Supplier GmbH", "url": "https://supplier.example" },
  "supportedInterfaces": [
    { "url": "https://agents.supplier.example/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" },
    { "url": "https://agents.supplier.example/a2a/rest", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true },
  "securitySchemes": {
    "oidc": { "openIdConnectSecurityScheme": { "openIdConnectUrl": "https://login.supplier.example/.well-known/openid-configuration" } }
  },
  "securityRequirements": [ { "schemes": { "oidc": { "list": ["parts.read"] } } } ],
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "check-availability",
      "name": "Check availability",
      "description": "Stock level and lead time for a part number at a given warehouse.",
      "tags": ["inventory", "spare-parts"],
      "examples": ["Is ART-10001 in stock in Vienna?"]
    }
  ]
}

A felfedezésre a dokumentáció három utat ad: a https://{server_domain}/.well-known/agent-card.json well-known URI-t, a kurált registryket (ezekhez a specifikáció nem határoz meg szabványos API-t) és a közvetlen konfigurációt. A kártya végpontja küldjön max-age értékkel ellátott Cache-Control fejlécet és ETag-et, a kliensek pedig feltételes kéréseket használjanak. A kártyák JSON Web Signature (RFC 7515) aláírással láthatók el a JSON Canonicalization Scheme (RFC 8785) szerint kanonizált alakon, és a kliensek legalább egy aláírást ellenőrizzenek, mielőtt megbíznak egy aláírt kártyában.

Egy nyilvános kártya ne szivárogtasson ki belső részleteket. Ha megbízható partnereknek több skillt vagy belső URL-t kell mutatnod, állítsd be a capabilities.extendedAgentCard mezőt, és a teljes kártyát a GetExtendedAgentCard művelettel szolgáld ki, amelynek kötelező hitelesítést kérnie. Statikus titok egyetlen kártyába se kerüljön.

A skillek leírását modellnek írd, ne marketingoldalnak. A kliensoldalon gyakran egy LLM olvassa el a kártyát, hogy eldöntse, melyik távoli ágens és melyik skill illik egy kéréshez, így a leírás ugyanazt a szerepet tölti be, mint egy eszközleírás az MCP-ben: mondd meg, mit csinál a skill, milyen bemenetet vár, és mit nem csinál. Minden skillváltozásnál emeld a version értékét, hogy a cache-elt kártyák és az ETagek értelmesek maradjanak.

Hogyan működnek a taskok, az üzenetek és az artefaktumok?

Az üzenet egy kommunikációs kör, messageId azonosítóval, szereppel (ROLE_USER a kliensnek, ROLE_AGENT a szervernek) és partok listájával. A part a legkisebb tartalmi egység: szöveg, nyers bájtok, URL vagy strukturált adat, opcionális mediaType és filename mezővel. Amikor a szerver munkát vállal, létrehoz egy taskot szerver által generált id azonosítóval, az összetartozó taskokat és üzeneteket csoportosító contextId mezővel, státusszal, előzménnyel és artefaktumokkal, vagyis a kimenetekkel, például dokumentumokkal vagy strukturált adatokkal, amelyek szintén partokból állnak.

Érdemes kiemelni a TASK_STATE_AUTH_REQUIRED állapotot: egy ágens a task közepén megállhat, mert a felhasználónak hozzáférést kell adnia valamihez, és ez pontosan az a fajta jóváhagyási lépés, amely mellett az ember a hurokban AI-ágenseknél cikkben érveltem. Egy többkörös párbeszéd folytatásához a kliens új üzenetet küld ugyanazzal a contextId értékkel és a meglévő task taskId azonosítójával; az össze nem illő azonosítókat a szerver elutasítja.

Milyen átviteli módok és frissítési módok vannak?

Az 1.0 három szabványos bindinget határoz meg – JSON-RPC, gRPC és HTTP+JSON (REST) –, és egyedieket is megenged. Minden bindingnek egyenértékűen kell viselkednie, az adatobjektumok mérvadó forrása a proto-fájl. Az alapműveletek így képeződnek le:

A SendMessage alapból blokkol; returnImmediately mellett azonnal visszatér, és a kliens háromféleképpen követheti a taskot: lekérdezéssel (GetTask), streameléssel (SendStreamingMessage vagy SubscribeToTask), vagy push értesítéssel, amikor a szerver POST-tal küldi a frissítéseket a kliens által regisztrált webhookra. Órákig futó taskoknál a push a jó választás, mert ennyi ideig senki sem akar nyitva tartani egy streamet. Egy JSON-RPC-hívás így néz ki:

// POST https://agents.supplier.example/a2a  (JSON-RPC binding, illustrative)
{
  "jsonrpc": "2.0",
  "id": "req-42",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "9b0c7e7a-2f1d-4c55-9f0e-1f6a2d0c3e11",
      "role": "ROLE_USER",
      "parts": [{ "text": "Is ART-10001 in stock in Vienna, and what is the lead time for 40 units?" }]
    }
  }
}

Hogy melyik bindinget választod, főleg azon múlik, mit beszélnek már most a szolgáltatásaid. A példákban és az SDK-kban a JSON-RPC a leggyakoribb, a HTTP+JSON azoknak a csapatoknak való, amelyek REST-gatewayt futtatnak, és olvasható URL-eket szeretnének a naplóikban, a gRPC pedig a protobufot már használó belső service meshekhez illik. Egy kártya több interfészt is felsorolhat, így a szerver két bindinget is kínálhat, a kliens pedig választ.

Mit jelent a biztonság A2A-nál?

A hitelesítést deklarálják, nem kitalálják: az agent card felsorolja a securitySchemes sémákat – API-kulcs, HTTP-auth, OAuth 2.0 (authorization code, client credentials vagy device code folyamat), OpenID Connect vagy kölcsönös TLS –, és megadja, melyik kötelező. A hitelesítő adatok a szállítási rétegben utaznak, mint bármely HTTP API-nál. Cégek közötti ágens–ágens hívásoknál az OAuth client credentials vagy az mTLS a természetes választás, és a hívó ágensnek saját, szűk scope-okkal rendelkező identitása legyen, ahogy az AI-ágensek identitások cikkben leírtam.

A specifikáció biztonsági része olyan kötelezettségeket tesz hozzá, amelyek a gyakorlatban számítanak:

• Autorizáció minden műveletnél, a hívóra szűkített eredményekkel akkor is, ha nincs szűrő, és ellenőrzéssel minden olyan keresés előtt, amely elárulhatná a hatókörön kívüli erőforrások létezését.
• Webhook-ellenőrzés SSRF ellen: utasítsd el a privát tartományokat, például a 10.0.0.0/8-at és a 192.168.0.0/16-ot, a localhostot és a link-local címeket, és ahol lehet, használj engedélylistát; a webhook-kéréseket 10–30 másodperc után szakítsd meg.
• Bemenetellenőrzés és korlátok az üzenetméretre, a fájlméretre és a kérés összetettségére, plusz rate limit minden műveleten.
• A webhook fogadója ellenőrzi, hogy minden értesítés általa indított taskra vonatkozik-e, és elviseli a többszörös kézbesítést.

Miért nem megbízható bemenet egy távoli ágens?

A hitelesítés azt mondja meg, ki a másik ágens, azt nem, hogy biztonságos-e, amit mond. 2025. október 31-én a Unit 42 közzétette az agent session smuggling technikát: egy rosszindulatú távoli ágens egy már létrejött sessiont kihasználva rejtett utasításokat küld a kliens ágensnek. A Google Agent Development Kitjével készült koncepcióbizonyításban a távoli ágens rávett egy pénzügyi asszisztenst, hogy felfedje a konfigurációját és a session előzményét, és meghívjon egy buy_stock eszközt, amelyet a felhasználó nem kért. A Unit 42 egyértelműen kimondja, hogy ez nem az A2A sebezhetősége; bármely állapottartó, többkörös protokollban az ágensek közötti hallgatólagos bizalmat használja ki.

Mikor használd az A2A-t, és mikor ne?

Egy protokollnak ára van: karbantartandó agent card, task-tár, szolgáltatások közötti hitelesítés, verziókezelés. Határokon térül meg, nem egy kódbázison belül. A döntési segédletem:

Ha azt mérlegeled, kell-e egyáltalán több ágens, a többágenses rendszerek: mikor érik meg cikk a tokenköltséget és a hibamódokat tárgyalja. A kereskedelemben az Agent Payments Protocol (AP2) az A2A ökoszisztémájához tartozik; az agentic commerce protokollok cikkben vetem össze a UCP-vel és az ACP-vel.

Hogyan kezdj bele az A2A-ba?

1. Válassz egy határt, ahol két ágens már most is egyedi integráción keresztül beszél, és modellezd a cserét explicit állapotú taskokként.
2. Először az agent cardot írd meg: világos leírású, példákkal ellátott skillek, kezdésnek egyetlen binding, és az a biztonsági séma, amelyet ténylegesen betartatsz.
3. Hivatalos SDK-t használj a saját nyelveden ahelyett, hogy kézzel írnád meg a protokollt, és rögzítsd a protokollverziót.
4. Tárold tartósan a taskokat újraindítást túlélő tárban, mert egy task túlélheti a folyamatot; minden lassú dologhoz push értesítést használj.
5. Kövesd a határon át: a task- és context-azonosító minden naplósorban szerepeljen, hogy egy hiba az egyik ágenstől a másikig követhető legyen.

Források

1. A2A Protocol Specification (latest, v1.0)
2. A2A: a2a.proto, the normative data model (GitHub)
3. A2A docs: A2A and MCP
4. A2A docs: Agent discovery
5. Google Developers Blog: Announcing the Agent2Agent Protocol (Apr 2025)
6. Linux Foundation: Launch of the Agent2Agent Protocol Project (Jun 2025)
7. Linux Foundation: A2A surpasses 150 organizations in its first year (Apr 2026)
8. Unit 42: Agent Session Smuggling in Agent2Agent Systems (Oct 2025)