> Mit szabványosít az Agent2Agent protokoll 1.0-s verziója: agent card, task, bindingek, biztonság, eltérés az MCP-től, és mikor éri meg használni. > > Web page: https://balazscsorba.com/hu/blog/a2a-protocol-agent-interoperability · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/a2a-protocol-agent-interoperability.md) · [Deutsch](https://balazscsorba.com/de/blog/a2a-protocol-agent-interoperability.md) > Author: Balázs Csorba · Published: 2026-10-16 · Keywords: a2a protocol, agent2agent protocol, a2a vs mcp, a2a agent card, agent-card.json well-known, a2a protocol 1.0, a2a task lifecycle, agent to agent communication protocol, a2a security, a2a json-rpc grpc, agent session smuggling [Blog](https://balazscsorba.com/hu/blog)/MI-ágensek # Az A2A protokoll: agent cardok, taskok, és a helye az MCP mellett Mit szabványosít az Agent2Agent protokoll 1.0-s verziója: agent card, task, bindingek, biztonság, eltérés az MCP-től, és mikor éri meg használni. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·12 perc olvasás - A2A - AI agents - MCP - Interoperability - Agent security ![Két, különböző szervezethez tartozó AI-ágens A2A-n cserél taskokat, mindkettő MCP-n kapcsolódik a saját eszközeihez, az agent card egy well-known URL-en érhető el.](https://balazscsorba.com/images/blog/a2a-protocol-agent-interoperability/cover.webp?v=f23e14dffd) ## A lényeg röviden - Az A2A az ágenseket köti össze egymással; az MCP egy ágenst köt az eszközeihez. A legtöbb valós rendszer, amelynek A2A kell, MCP-t is használ. - A /.well-known/agent-card.json címen közzétett agent card leírja az identitást, az interfészeket, a skilleket és a hívótól elvárt biztonsági sémákat. - A munka egy task, szerver által adott azonosítóval és állapotgéppel, így a hosszan futó és többkörös feladatok beépítettek, nem utólag ráragasztottak. - Az 1.0 az első stabil specifikáció, JSON-RPC, gRPC és HTTP+JSON bindinggel, valamint opcionálisan aláírt agent cardokkal. - Egy távoli ágens nem megbízható bemenet: minden műveletet autorizálj, ellenőrizd a webhook-URL-eket, és az érzékeny műveleteket csatornán kívül erősítsd meg. Ezen az oldalon 1. [Mi az A2A protokoll?](https://balazscsorba.com/#what-is-a2a) 2. [Hogyan viszonyul az A2A az MCP-hez?](https://balazscsorba.com/#a2a-vs-mcp) 3. [Mi van egy agent cardban?](https://balazscsorba.com/#agent-cards) 4. [Hogyan működnek a taskok, az üzenetek és az artefaktumok?](https://balazscsorba.com/#tasks-and-messages) 5. [Milyen átviteli módok és frissítési módok vannak?](https://balazscsorba.com/#bindings-and-updates) 6. [Mit jelent a biztonság A2A-nál?](https://balazscsorba.com/#security) 7. [Miért nem megbízható bemenet egy távoli ágens?](https://balazscsorba.com/#trust-between-agents) 8. [Mikor használd az A2A-t, és mikor ne?](https://balazscsorba.com/#when-to-use-a2a) 9. [Hogyan kezdj bele az A2A-ba?](https://balazscsorba.com/#getting-started) 10. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 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](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) 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](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents) 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ó](https://a2a-protocol.org/latest/specification/) 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](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) 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](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) 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.” A kliens ágens soha nem látja a távoli ágens eszközeit, promptjait vagy modelljét; csak egy agent cardot és a taskok eredményeit. Kérdés MCP A2A Ki van a másik oldalon? Egy eszköz- vagy adatszerver Egy másik ágens, amely gondolkodik és tervez Munkaegység Egy eszközhívás argumentumokkal és eredménnyel Egy task azonosítóval, állapotokkal, üzenetekkel és artefaktumokkal Belső működés láthatósága Az eszközsémák láthatók a modell számára A távoli ágens átláthatatlan marad Tipikus határ Egy ágens telepítésén belül Csapatok, szolgáltatások vagy cégek között 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](https://balazscsorba.com/hu/blog/mcp-server-security-checklist). ## 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](https://github.com/a2aproject/A2A/blob/main/specification/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ó](https://a2a-protocol.org/latest/topics/agent-discovery/) 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. A végállapotok: completed, failed, canceled és rejected; az input-required és az auth-required a megszakított állapotok. É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](https://balazscsorba.com/hu/blog/human-in-the-loop-ai-agents) 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: Művelet JSON-RPC és gRPC metódus HTTP+JSON Üzenet küldése `SendMessage` `POST /message:send` Küldés és frissítések streamelése `SendStreamingMessage` `POST /message:stream` Task lekérése `GetTask` `GET /tasks/{id}` Task megszakítása `CancelTask` `POST /tasks/{id}:cancel` Webhook regisztrálása `CreateTaskPushNotificationConfig` `POST /tasks/{id}/pushNotificationConfigs` További műveletek `ListTasks`, `SubscribeToTask`, `GetExtendedAgentCard` megfelelő végpontok 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](https://balazscsorba.com/hu/blog/ai-agent-identity-least-privilege) 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](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/) 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. **A távoli ágens kimenetét kezeld webes tartalomként** Egy másik ágens szövege, adatai és artefaktumai nem megbízható bemenetek a modelled számára, pontosan úgy, mint egy letöltött weboldal. A Unit 42 javaslata: érzékeny műveletek csatornán kívüli megerősítése, az eredeti kéréstől eltávolodó sessionöket lezáró context grounding, ellenőrzött ágensidentitás, és annak megmutatása a felhasználónak, mely távoli utasítások mely eszközhívásokhoz vezettek. Ugyanazok a tervezési szabályok érvényesek, mint a [prompt injection elleni védekezésnél](https://balazscsorba.com/hu/blog/prompt-injection-lethal-trifecta-patterns). ## 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: Helyzet Mit használnék Egy csapat, egy kódbázis, több specializált ágens Al-ágensek vagy függvényhívások a keretrendszerben; protokoll nélkül Egy ágensnek adatbázis, API vagy fájlrendszer kell MCP Különböző csapatok ágensei, külön telepítve és verziózva A2A, OAuth-tal vagy mTLS-sel a szolgáltatások között Egy partner vagy szállító ágenst ad, nem API-t A2A-kliens; a kimenet nem megbízható A másik oldalnak stabil, jól definiált API-ja van Hívd közvetlenül, vagy csomagold MCP-eszközbe Ha azt mérlegeled, kell-e egyáltalán több ágens, a [többágenses rendszerek: mikor érik meg](https://balazscsorba.com/hu/blog/multi-agent-systems-when-worth-it) 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](https://balazscsorba.com/hu/blog/agentic-commerce-protocols-ucp-acp-guide) 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)](https://a2a-protocol.org/latest/specification/) 2. [A2A: a2a.proto, the normative data model (GitHub)](https://github.com/a2aproject/A2A/blob/main/specification/a2a.proto) 3. [A2A docs: A2A and MCP](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) 4. [A2A docs: Agent discovery](https://a2a-protocol.org/latest/topics/agent-discovery/) 5. [Google Developers Blog: Announcing the Agent2Agent Protocol (Apr 2025)](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) 6. [Linux Foundation: Launch of the Agent2Agent Protocol Project (Jun 2025)](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents) 7. [Linux Foundation: A2A surpasses 150 organizations in its first year (Apr 2026)](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) 8. [Unit 42: Agent Session Smuggling in Agent2Agent Systems (Oct 2025)](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/) ## Gyakori kérdések Mi az A2A protokoll? Az Agent2Agent (A2A) nyílt protokoll, amellyel különböző csapatok vagy szállítók AI-ágensei megtalálják egymást, üzeneteket cserélnek és taskokat adnak át. A Google 2025 áprilisában jelentette be, és 2025 júniusában átadta a Linux Foundationnek; az 1.0 az első stabil specifikáció. Mi a különbség az A2A és az MCP között? Az MCP azt szabványosítja, hogyan használ egy ágens eszközöket és erőforrásokat, jellemzően jól definiált függvényeket. Az A2A azt, hogyan működnek együtt független, gyakran átláthatatlan ágensek egyenrangú félként olyan taskokon, amelyek állapotot tartanak, többkörösek és hosszan futnak. Az A2A dokumentációja kiegészítőnek nevezi őket: az A2A az ágenseket köti össze, az MCP minden ágenst a saját eszközeihez. Hol tesszük közzé az A2A agent cardot? A specifikáció egy well-known URI-t határoz meg: https://{server\_domain}/.well-known/agent-card.json, amelyet egyszerű HTTP GET-tel kérnek le. Az ágensek kurált registryken keresztül is megtalálhatók, vagy közvetlenül konfigurálhatók. A részletesebb kártyát a kiterjesztett agent card művelettel csak hitelesített hívók kaphatják meg. Biztonságos az A2A? A protokoll megadja a kapaszkodókat: biztonsági sémák az agent cardban (API-kulcs, HTTP-auth, OAuth 2.0, OpenID Connect, kölcsönös TLS), kötelező autorizáció minden műveletnél és opcionálisan aláírt kártyák. Hogy egy telepítés biztonságos-e, azon múlik, megvalósítod-e ezeket, és nem megbízható bemenetként kezeled-e a távoli ágensek üzeneteit. Kell A2A egy alkalmazáson belüli többágenses rendszerhez? Általában nem. Ha minden ágens a tiéd, és egy kódbázisban futnak, egyszerűbbek az al-ágensek vagy a függvényhívások. Az A2A a határokon térül meg: csapatok, szolgáltatások vagy cégek között, ahol az ágenseket egymástól függetlenül telepítik és verziózzák. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [Kontextusromlás hosszan futó ügynököknél: törlés, tömörítés, memória és al-ügynökök](https://balazscsorba.com/hu/blog/context-rot-compaction-long-running-agents) - [Böngészőágensek E2E-teszteléshez: írják az ágensek a Playwright-teszteket, ne futtassák](https://balazscsorba.com/hu/blog/browser-agents-e2e-testing-playwright) - [Egy senior MI-ügynökökkel vagy egy csapattal: mit mondanak a bizonyítékok](https://balazscsorba.com/hu/blog/ai-assisted-development-economics) - [Spec-driven fejlesztés kódoló ügynököknek: a terv a kód előtt](https://balazscsorba.com/hu/blog/spec-driven-development-coding-agents) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)