Az Agent2Agent (A2A) nyílt protokoll, amely különálló, egymás számára átlátszatlan ügynökrendszerek közötti kommunikációt és együttműködést szabályozza. Nem modell és nem futtatókeret, hanem közös nyelv azoknak az ügynököknek, amelyeket más csapat, más keretrendszer vagy más szolgáltató épített.

A kiindulópont az, hogy az ügynök nem eszköz. Ha egy ügynököt eszközként csomagolunk egy másik ügynök elé, elveszik az, amiért ügynök: a párbeszéd, a képesség-egyeztetés és a hosszú, állapottal rendelkező munka. Az A2A ezért nem burkol, hanem meghatározza, hogyan írja le egy ügynök önmagát, és hogyan folyik egy megosztott feladat.

Az ügynökkártya és a felfedezés

Minden A2A szerver, vagyis a távoli ügynök, közzétesz egy JSON dokumentumot: az ügynökkártyát (Agent Card). Ebben áll a név, a leírás, a szolgáltató, a szolgáltatás végpontja (url), a támogatott opcionális képességek (streaming, pushNotifications), a hitelesítési sémák, valamint a skillek, mindegyik azonosítóval, példákkal és be- és kimeneti módokkal.

Nyilvános esetben a kártya a szabványos, jól ismert útvonalon érhető el, /.well-known/agent-card.json. A dokumentáció két másik utat is leír: a központi regisztert és a kézi konfigurációt. A regiszterhez kimondott korlát is tartozik: a specifikáció nem ír elő szabványos API-t a regiszterekhez, azt minden üzemeltető maga alakítja ki. A kártya érzékeny adatot tartalmazhat, ezért a dokumentáció autentikált, kiterjesztett kártyát és védett végpontot javasol, statikus titok nélkül.

Feladat, üzenet, artefakt

Kétféle válasz létezik. Az egyszerű, állapot nélküli Message egy menetben lezárul, és nincs mögötte követhető munka. A Task ezzel szemben állapottal rendelkező munkaegység, saját azonosítóval és életciklussal:

working: a feladat fut.
input-required és auth-required: a feladat megállt, és a kliens bemenetére vagy hitelesítésére vár.
completed, failed, canceled, rejected: végállapotok.

A contextId fogja össze a beszélgetést, így a folytatás nem vész el, a taskId pedig mindig a szerver oldalán keletkezik: a kliens nem hozhat létre feladatot saját azonosítóval. A kimenet artifact, amely part-okból áll, és text, fájlhivatkozás vagy strukturált adat lehet.

Két szabály érdemel külön figyelmet: a végállapotba került feladat nem indítható újra, a finomítás ugyanabban a kontextusban új feladatot nyit; és az artefaktumok verziókövetése nem része a protokollnak, azt a kliens oldalán kell vezetni.

Hogyan érkeznek a frissítések?

Három, egymást kiegészítő út van:

Lekérdezés: a kliens GetTask hívással kérdez rá az állapotra. Egyszerű, de nagyobb késleltetéssel jár.
Folyam: SendStreamingMessage, szakadás esetén pedig SubscribeToTask. A szerver text/event-stream választ ad, és TaskStatusUpdateEvent és TaskArtifactUpdateEvent eseményeket küld. Az események sorrendje kötelező, és egy feladathoz több párhuzamos folyam is csatlakozhat.
Push értesítés: a szerver a kliens webhookjára küld HTTP POST kérést, így a kliensnek nem kell nyitva tartania a kapcsolatot.

Mindhárom út feltételes: a szervernek be kell jelentenie a kártyájában a streaming vagy pushNotifications képességet, különben a hívás hibát ad vissza. A SendMessage alapból blokkol, amíg a feladat el nem éri a vég- vagy várakozó állapotot. A használt verziót a kliens az A2A-Version fejlécben jelzi minden kérésnél.

Hogyan viszonyul az MCP-hez?

A két protokoll nem versenytárs, hanem más irányban kapcsol. Az MCP egy ügynököt mélyít: eszközöket, erőforrásokat és adatforrásokat köt hozzá. Az A2A oldalra nyit: külön futó, akár más szervezethez tartozó ügynököket köt össze.

A dokumentáció ezt függőleges és vízszintes rétegként írja le: az A2A a közös munkáról szól, az MCP a képességek használatáról, és egy jól definiált, állapot nélkül hívható skill MCP-kompatibilis erőforrásként is megjelenhet.

Nálunk az MCP adja az eszközréteget a Hermes Agent alatt, az A2A pedig az ügynökök közötti oldal, ahol a Paperclip csapat tagjai feladatot adnak át egymásnak.

Amire figyelni kell

Amit nem jelentettek be, az nem használható. A képesség-egyeztetés a kártya alapján történik, ezért a kliensnek a hívás előtt ellenőriznie kell a támogatást.
Az azonosítás a protokollon kívül történik. Az A2A üzenet nem hordoz felhasználói identitást; a hitelesítés HTTP fejlécekben megy, a token beszerzése pedig a protokollon kívüli folyamat. A feladat közben kért másodlagos hitelesítés szintén kívül esik rajta.
A webhook valódi támadási felület. A szerver nem küldhet vakon POST kérést bármilyen megadott URL-re, mert azzal SSRF-hez vagy elosztott túlterheléshez asszisztálhat. Engedélylista, tulajdonjog-ellenőrzés és kimenő hálózati szabályok kellenek, a fogadó oldalnak pedig ellenőriznie kell az aláírást, és vissza kell utasítania a lejárt vagy ismételt értesítéseket.
A hibaválasz nem szivároghat. A nem létező és a nem engedélyezett erőforrást a szervernek nem szabad megkülönböztetnie.
Nyitott pontok. A dokumentáció maga sorolja a következő lépések közé a feladaton belüli dinamikus mód-egyeztetést, egy QuerySkill() hívást és a folyamok megbízhatóságának javítását.

Nálunk a CyberElectro az A2A-t az ügynökök közötti határvonalon használja, ahol a feladatátvételnek állapotot és életciklust kell követnie.

Tovább olvasás

A2A Protocol Specification - a protokoll hivatalos szövege, verzióra bontva.
A2A and MCP - a két protokoll viszonya a hivatalos dokumentációból.
a2aproject/A2A - a projekt forrása, a roadmap és az SDK-k listája.