Interoperabilnost alata za kodiranje s MCP-om i A2A-om

Početna » Piton » Interoperabilnost alata za kodiranje s MCP-om i A2A-om

AI agenti više nisu samo otmjeni chatbotovi koji odgovaraju na pitanja u jednom prozoru. Pretvaraju se u distribuirane sustave koji mogu čitati i pisati kod, pozivati ​​API-je, koordinirati s drugim uslugama, pa čak i pregovarati s drugim agentima kako bi obavili posao. Čim prijeđete s "jednog pametnog asistenta" na "mrežu agenata", pojavljuje se brutalan problem: kako svi ti dijelovi međusobno komuniciraju bez da upadnu u kaos?

To je upravo praznina koju MCP (Model Context Protocol) i A2A (Agent-to-Agent Protocol) pokušavaju popuniti. MCP se fokusira na to kako se agent povezuje s alatima, podacima i kontekstom, dok se A2A fokusira na to kako agenti međusobno komuniciraju i surađuju. Preklapaju se u duhu, ali djeluju na različitim slojevima. U ovom ćemo članku detaljno istražiti što svaki od njih radi, kako se međusobno nadopunjuju, kako se već koriste u stvarnim sustavima i što to znači za budućnost alata za kodiranje i višeagentskih arhitektura.

Što je MCP zapravo u praksi

U svojoj srži, MCP je standardni način izlaganja alata, resursa i uputa AI agentu kako bi ih agent mogao sigurno i dosljedno pozivati. Umjesto izravnog povezivanja svakog alata sa svakim agentom s prilagođenim kodom za spajanje, te alate izlažete iza MCP poslužitelja i dopuštate MCP klijentima (agentima) da ih otkriju i pozovu putem jedinstvenog protokola.

MCP slijedi jasnu klijent-poslužitelj arhitekturu: Host aplikacija (poput editora, CLI-ja ili agenta) ugrađuje MCP klijenta, a taj klijent otvara veze jedan-na-jedan s jednim ili više MCP poslužitelja. Svaki poslužitelj je samo lagani proces koji pruža skup mogućnosti - obično alate, resurse samo za čitanje i upite za višekratnu upotrebu.

Inspiracija je vrlo bliska protokolu jezičnog poslužitelja (LSP). LSP je apstrahirao problem „uređivač ↔ jezične značajke“ tako da nismo morali pisati prilagođene integracije između svakog uređivača i svakog programskog jezika. Ako jednom implementirate jezični poslužitelj, bilo koji LSP-kompatibilni uređivač može s njim komunicirati. MCP uzima istu ideju i primjenjuje je na alate i kontekst za LLM-ove: implementirajte alat jednom kao MCP poslužitelj i svaki MCP-svjestan agent ga može koristiti.

S transportnog gledišta, MCP je fleksibilan, ali dovoljno svojeglav da bude praktičan. Koristi JSON‑RPC 2.0 kao format poruke i podržava više transporta: stdio za lokalne procese (izvrsno za desktop aplikacije i lokalne razvojne programere) i HTTP ili SSE za udaljene poslužitelje (savršeno za Cloud Run ili kontejnerizirane implementacije). Protokol također definira kako klijent otkriva mogućnosti i kako se alati opisuju pomoću JSON Scheme tako da LLM može odlučiti kada i kako ih pozvati.

Ključno je da MCP ne pokušava orkestrirati razmišljanje vašeg agenta. Ne odlučuje kada alat treba pozvati ili kako alati trebaju biti povezani u lanac. MCP je sloj ožičenja: on čini alate, resurse i upute dostupnima na strukturiran, lako vidljiv način, prepuštajući donošenje odluka vašem agentskom okviru, planeru ili inženjerstvu promptova.

Osnovni MCP gradivni blokovi: alati, resursi i upute

MCP poslužitelji se vrte oko tri glavna elementa: alata, resursa i uputa. Ova tri koncepta su dovoljna da pokriju većinu potreba agenata u stvarnom svijetu bez pretvaranja protokola u potpuni okvir za orkestraciju.

Alati su zasebne akcije koje agent može pokrenuti. Razmišljati "get_weather","search_inventory","book_flight","run_sql_query"Ili"get_exchange_rateSvaki alat je deklariran s imenom, opisom koji je čitljiv ljudima i ulaznom shemom. Ta shema omogućuje LLM-u da razumije koje parametre treba proslijediti, a također štiti vaš backend validacijom argumenata prije izvršenja.

Resursi predstavljaju podatke samo za čitanje koje poslužitelj može poslužiti na zahtjev. Datoteke, zapisnici, retci baze podataka, isječci dokumentacije, konfiguracijske datoteke – bilo koji dio informacije koji je bolje modelirati kao „dohvati ovo“ nego „pokreni ovu funkciju“. Resursi mogu biti veliki, pa MCP definira načine za njihovo podjeljivanje i strujanje, što je ključno pri unosu konteksta u model s ograničenim prozorom.

Upitnici su predlošci za višekratnu upotrebu koje poslužitelji mogu prikazati klijentima. Umjesto kodiranja dugih, krhkih nizova promptova unutar vašeg agenta, možete ih centralizirati kao MCP prompte. Poslužitelj ih izlaže s imenima, opisima i mjestima za parametre, a klijent popunjava ta mjesta tijekom izvođenja. Ovo je iznenađujuće moćno kada više agenata treba dijeliti iste obrasce za komunikaciju s određenim alatom ili slijediti pravila sigurnosti i usklađenosti na razini cijele tvrtke.

Kada se klijent spoji na poslužitelj, provodi korak otkrivanja mogućnosti. Poslužitelj odgovara katalogom alata, resursa i upita, svaki s detaljnim metapodacima. Taj se katalog zatim unosi u LLM (obično u sažetom obliku) tako da model može zaključiti: „Mogu koristiti get_exchange_rate odgovoriti na ovo pitanje o konverziji valuta i ne bih trebao pokušavati izmisliti odgovor.”

Budući da je sve ovo deklarativno, nove mogućnosti mogu se dodavati ili uklanjati bez dodirivanja osnovne logike agenta. Dodajte novi alat na poslužitelj, ponovno ga rasporedite i svaki MCP klijent koji se spoji vidjet će ga pri sljedećem pregovaranju o mogućnostima. Ovo je trenutak "priključite još jedan USB uređaj" za AI alate.

Konkretan primjer MCP-a: alat za pretvorbu valuta

Demo valutnog agenta iz Googleovog kompleta za razvoj agenata (ADK) savršen je primjer MCP-a u akciji. Počinje izgradnjom malog MCP poslužitelja koji nudi jedan alat, get_exchange_rate, uz podršku javnog Frankfurter API-ja. Na disku je to samo mala Python skripta koja koristi fastmcp.

Poslužitelj definira alat s tipiziranim argumentima za currency_from, currency_to i currency_date, plus robusno zapisivanje i obrada pogrešaka. Kada ga agent pozove, poslužitelj se obraća Frankfurteru putem HTTP-a, validira odgovor i vraća JSON korisni teret s tečajem ili objektom pogreške. Ništa u vezi s ovim nije specifično za umjetnu inteligenciju; MCP samo standardizira način na koji se ova funkcionalnost opisuje i poziva.

Lokalno, pokrećete poslužitelj jednostavnom naredbom i on osluškuje http://localhost:8080. Zaseban testni klijent, koji također koristi MCP, povezuje se i otkriva get_exchange_rate i pokreće poziv za USD → EUR. Zapisnik prikazuje pozivanje alata, odlazni HTTP zahtjev, uspješan odgovor i vraćeni JSON. Iz perspektive vašeg agenta, samo je pitao „koje alate imam?“, a zatim „molim vas, pozovite ovog“.

Implementacija istog poslužitelja u Cloud Run jedva mijenja priču. Kontejnerizirate MCP poslužitelj, implementirate ga s --no-allow-unauthenticated pa zahtijeva IAM-potpomognutu autentifikaciju, a zatim otvoriti sigurni tunel s vašeg lokalnog računala pomoću naredbe Cloud Run proxy. Lokalno, vaš MCP klijent i dalje misli da komunicira s http://127.0.0.1:8080; proxy transparentno obrađuje autentifikaciju i mrežne skokove.

Ovaj je obrazac moćan u timovima: možete pokrenuti centralizirani MCP poslužitelj za dijeljene alate poput tečajeva valuta, internih API-ja ili vlasničkih baza podataka. Svaki razvojni agent u organizaciji može se spojiti na taj poslužitelj putem sigurnog transporta umjesto da isporučuje vlastiti, malo drugačiji, napola održavani omotač oko istog API-ja.

Izgradnja agenata na MCP-u: od pojedinačnih alata do cjelovitih tijekova rada

MCP postaje stvarno zanimljiv kada ga ugradite u agentski okvir poput Googleovog ADK-a. U primjeru valutnog agenta, ADK se koristi za stvaranje specijaliziranog LLM agenta čiji je jedini zadatak odgovarati na pitanja o tečajevima pomoću MCP alata. Sistemska uputa agenta doslovno mu govori: „vaša jedina svrha je koristiti get_exchange_rate alat“.

ADK povezuje ovu instrukciju, odabrani model (na primjer gemini-2.5-flash) i an MCPToolset instanca koja pokazuje na URL MCP poslužitelja. Od tada nadalje, kada korisnik pita „Koliko je 250 CAD u USD?“, agent razmatra treba li mu poziv alata, ispunjava parametre alata, šalje zahtjev putem MCP-a, a zatim piše korisniku prilagođen odgovor koristeći vraćeni JSON.

Isti obrazac se skalira i na daleko složenije agente. Umjesto API-ja za jednu valutu, možete povezati više poslužitelja: jedan za interne baze podataka, drugi za SaaS treće strane, treći za pretraživanje dokumenata, plus poslužitelj koji izlaže upite za višekratnu upotrebu ili RAG cjevovode. MCP-u nije važno rade li ti poslužitelji lokalno, na Cloud Runu, u Kubernetesu ili iza VPN-a, sve dok je transport podržan i autentifikacija ispravno konfigurirana.

ADK također dodaje perspektivu koja agenta postavlja na prvo mjesto koju MCP namjerno izbjegava. Tretira agente kao kompozibilne softverske komponente: možete definirati agente temeljene na LLM-u, agente s velikim brojem alata, agente za evaluaciju i orkestratore, a svi oni mogu izgovoriti MCP iz kutije. Rezultat je da "izgradi agenta" počinje puno više nalikovati "izgradi mikroservis", a puno manje "podešavaj beskonačan upit u bilježnici".

Što je A2A – i zašto sam MCP nije dovoljan

Ako se MCP odnosi na povezivanje agenata s alatima, A2A se odnosi na povezivanje agenata s drugim agentima. Čim imate više agenata koji znaju dobro obaviti nešto, potreban vam je način da se međusobno pronađu, razmjenjuju zadatke i ostanu sinkronizirani dok je posao u tijeku. To je problem za koji je A2A dizajniran.

A2A, koji je pokrenuo Google Cloud, a sada je pod okriljem Linux Foundationa, otvoreni je standard za interoperabilnost između agenata. Koristi poznate tehnologije (HTTP(S), JSON‑RPC 2.0 i SSE za streaming), ali ih obavija modelom domene koji razumije agente, vještine, zadatke, artefakte i mogućnosti. Umjesto „poziva alata“, dobivate jezik više razine za suradnju.

Dvije ključne ideje u A2A su kartice agenata i zadaci. Kartica agenta je JSON dokument – ​​obično se može pronaći na /.well-known/agent.json – koji opisuje što agent može učiniti, kako do njega doći, kakvu autentifikaciju očekuje i koje načine ulaza/izlaza podržava. Zadaci su jedinice rada koje jedan agent može poslati drugome, s dobro definiranim životnim ciklusom i strukturiranim rezultatima.

U A2A interakciji, jedan agent preuzima ulogu „klijentskog agenta“, a drugi djeluje kao „udaljeni agent“. Klijent otkriva karticu udaljenog agenta, odlučuje je li to pravi partner za posao, a zatim kreira zahtjev za zadatak. Udaljeni agent prima zadatak, koristi vlastiti LLM i interne alate (često putem MCP-a) za njegovo izvršenje, a zatim šalje natrag ažuriranja napretka i konačne artefakte.

Ovaj dizajn čini A2A izvorno point-to-point komunikacijom, asinhronom i prilagođenom mreži. Ispod haube, Python implementacije se temelje na ASGI okvirima poput Starlette (putem A2AStarletteApplication) i uvicorn, s artefaktima i ažuriranjima zadataka koji teku putem JSON-RPC-a i SSE-a. To znači da se zadaci mogu izvršavati sekundama ili satima bez blokiranja ijednog HTTP zahtjeva, što je ključno za stvarne višeagentne tijekove rada.

Primjer A2A: otkrivanje agenta "Hello" i dalje

Kanonski A2A “HelloWorldAgent” prikazuje mehaniku u pojednostavljenom obliku. Vi definirate AgentExecutor podklasa koja implementira execute metoda. Unutra, kao rezultat zadatka, u red čekanja događaja stavljate jednu tekstualnu poruku – „Pozdrav iz A2A!“. Otkazivanje postaje nemoguće u ovom jednostavnom slučaju, ali udica postoji za stvarna opterećenja.

Zatim kreirate AgentSkill opisujući što ovaj agent može učiniti. U primjeru, vještina hello nosi naziv, opis, skup oznaka i reprezentativne korisničke upite. Ta se vještina zatim objedinjuje u AgentCard zajedno s imenom agenta, verzijom, URL-om, mogućnostima i podržanim načinima rada ulaza/izlaza.

Konačno, sve spojite u A2AStarletteApplication sa DefaultRequestHandler i pokrenite ga pod uvicornom. Što se tiče vanjskog svijeta, sada imate punopravnog A2A agenta koji vas sluša. http://localhost:9000Bilo koji klijent koji podržava A2A može dohvatiti /.well-known/agent.json, razumjeti što ovaj agent nudi i poslati mu zadatke.

U realnijim implementacijama, isti se obrazac skalira na scenarije orkestracije poput rezervacije putovanja, uvođenja u posao ili automatizacije podrške. „Putnički agent“ može otkriti i razgovarati s „Agentom za letove“, „Agentom za hotele“ i „Agentom za najam automobila“, pri čemu svaki radi iza vlastite A2A krajnje točke i skriva svoje interne alate i API ugovore specifične za dobavljače. Putnički agent vidi samo zadatke, vještine i artefakte.

Tu dolazi do izražaja A2A-ino odvajanje briga. Svaki agent nizvodno može odabrati vlastite modele, okvire i alate – hotelski agent izgrađen s ADK-om i MCP-om, agent zrakoplovne tvrtke izgrađen s drugim paketom, agent za iznajmljivanje automobila smješten u partnerskoj infrastrukturi – i svi i dalje čisto surađuju putem A2A površine.

Spajanje MCP-a i A2A u jednu arhitekturu

Na papiru podjela zvuči uredno – MCP za alate, A2A za agente – ali u praksi se granice brzo zamagljuju. Pravi sustavi često žele sakriti A2A iza MCP-a, slojevito postaviti MCP unutar A2A ili kombinirati oboje u istom procesu. Službeni A2A primjeri čak omotavaju A2A komunikaciju kao MCP alate izložene s jednog poslužitelja, tako da LLM vidi „jedan MCP skup alata“ umjesto dva paralelna protokolna stoga.

Jedan uobičajeni obrazac je tretirati MCP kao unutarnje ožičenje svakog agenta, a A2A kao vanjsku mrežu između agenata. Unutar agenta, vaš LLM poziva MCP alate za pristup bazama podataka, API-jima ili spremištima dokumenata. Izvana, vaš orkestrator komunicira s tim agentom putem A2A, predajući zadatke i čitajući artefakte natrag. Iz perspektive orkestratora, agent je usluga crne kutije s čistim, tipiziranim sučeljem.

Obrnuti obrazac – privlačenje pozornosti na A2A kao MCP alate – atraktivan je s gledišta integracije. Mnogi pružatelji LLM-a već imaju usavršene alate za MCP: devtools, UI demoe, SDK-ove i sigurnosne vodiče. Izlaganjem "kontakta udaljenog agenta X" kao jednog MCP alata, omogućujete LLM-u da pokrene A2A interakciju s minimalnim postavljanjem. Registrirate samo jedan MCP poslužitelj, ali ispod haube, taj poslužitelj može posredovati u zadacima na cijeloj A2A mreži.

Upravo to pokazuju neki primjeri repozitorija: umjesto izravnog povezivanja svakog udaljenog A2A agenta s modelom, MCP poslužitelj nudi kompaktan skup alata koji sami komuniciraju A2A. To razbija naivni mentalni model („MCP i A2A moraju biti potpuno odvojeni“), ali uvelike pojednostavljuje praktičnu integraciju i održava vašu LLM površinu sučelja malom i dobro organiziranom.

Također vas ništa ne sprječava da koristite MCP i A2A izolirano tamo gdje to ima smisla. Mnogim projektima će uvijek trebati MCP za povezivanje samo jednog agenta s nekoliko alata. Drugi, posebno prilikom povezivanja dobavljača ili internih timova, uvelike će se oslanjati na A2A za međuorganizacijsku koordinaciju koristeći vlastito interno ožičenje umjesto MCP-a. Važno je da se protokoli ne natječu - oni se dopunjuju.

Interoperabilnost, okviri i nedostajuća „velika struktura“

Sami protokoli ne jamče interoperabilnost ako ih svatko ugrađuje u vrlo različite arhitekture više razine. Možete savršeno govoriti MCP i A2A, a ipak završiti s hrpom međusobno nekompatibilnih obrazaca agenata koji svaki reinventiraju planiranje, pamćenje, rukovanje pogreškama i upravljanje.

Vjerojatni sljedeći korak u ekosustavu je sloj okvira izgrađenih na vrhu MCP-a i A2A-e koji standardiziraju ne samo žice, već i širu strukturu. Razmislite o tome kako su se web okviri pojavili na temelju HTTP-a ili kako su se ORM-ovi gradili na temelju SQL-a. To počinjemo vidjeti s ADK-om, orkestratorima sličnim LangGraphu, upravljanim platformama poput Vertex AI Agent Enginea i AI pristupnicima koji razumiju oba protokola.

Nakon što se industrija usaglasi oko nekoliko pragmatičnih obrazaca – „ovako se strukturira višeagentski tijek rada preko A2A i MCP“, „ovako se otkrivaju alati timova koji stoje iza MCP-a“ – prepirke oko toga treba li nešto „biti iza MCP-a ili A2A“ počet će nestajati. Većina programera će jednostavno odabrati framework, priključiti jedan ili dva poslužitelja i dobiti razumne zadane postavke.

Zamršeniji i sporiji problem je brzo inženjerstvo i brza interoperabilnost. Čak i uz savršene protokole, kada povezujete sustave putem MCP-a i A2A, učinkovito dopuštate proizvoljnim uputama - uputama sustava, opisima alata, sigurnosnim ogradama - da cure i međusobno djeluju preko granica. Ako su te upute neusklađene, redundantne ili potpuno kontradiktorne, vaše performanse pate mnogo prije nego što se pojave sigurnosni problemi.

U praksi, loše dizajnirani upiti i upute na MCP + A2A stogu mogu proizvesti ogromnu latenciju, halucinacije i nestabilnost. Svaki agent može biti lokalno „dobro informiran“, ali kada ih slojevito rasporedite, tokovi mogu postati krhki: alati su pogrešno prioritizirani, kontekstni prozori su uzaludni, a očekivanja na razini korisnika su kršena. A2A može koordinirati zadatke, MCP može izložiti alate, ali nijedan vas ne prisiljava da upute budu koherentne.

Zato timovi koji su zapravo isporučili LLM proizvode u velikim razmjerima imaju tendenciju tretirati brzi inženjering kao prvorazrednu inženjersku brigu, a ne kao podešavanje u zadnji čas. Poslovni dionici često vide upute kao čaroban način da se sve popravi; inženjeri ponekad odbacuju upute kao sekundarni detalj u usporedbi s kodom. Stvarnost je negdje u sredini: upute neće učiniti loš sustav dobrim, ali loše izrađene upute mogu apsolutno uništiti inače solidnu arhitekturu.

Sigurnost, identitet i upravljanje u MCP-u i A2A-i

Nakon što počnete dopuštati agentima da djeluju u ime ljudi preko granica MCP-a i A2A-e, identitet i autorizacija brzo postaju središnji problemi. Jedan zahtjev može proći kroz nekoliko slojeva delegiranja: korisnik razgovara s orkestracijskim agentom, koji poziva alat preko MCP-a, koji interno poziva druge MCP poslužitelje ili A2A agente koji zahtijevaju zasebne vjerodajnice.

Konkretni scenariji se pojavljuju posvuda: SaaS aplikacija otkriva MCP poslužitelj kojem su potrebni OAuth tokeni; interni HR agent iza A2A koristi korporativne LDAP identitete; alat za analitiku treće strane koristi vlastiti SSO. Korisnik očekuje „prijavi se jednom i obavi posao“, ali iza kulisa više sustava identiteta mora biti federirano.

Googleova A2A dokumentacija izričito navodi federaciju više identiteta kao ključni izazov. Korisnik U može komunicirati s agentom A kojem je potreban identitet sustava A (npr. poslovni LDAP), dok agent A interno treba delegirati agentu B kojem je potreban identitet sustava B (npr. vanjskom SaaS pružatelju usluga). Protokoli moraju podržavati prenošenje i određivanje opsega tih identiteta bez prisiljavanja korisnika na ručnu ponovnu autentifikaciju za svaki skok.

Pružatelji identiteta i OAuth/OIDC platforme brzo se prilagođavaju ovoj novoj stvarnosti. Infrastruktura poput Logtoa, Auth0 ili internih pružatelja identiteta već može izdavati tokene koje agenti nose putem MCP i A2A poziva. Otvoreno pitanje nije je li to moguće – očito jest – već kako standardizirati obrasce tako da alat izgrađen danas sutra ne postane sigurnosni ili upravljački problem.

Uz autorizaciju, vidljivost i provođenje pravila vjerojatno će se preseliti u zajedničke "agentske prolaze". Ti pristupnici mogu prekidati MCP i A2A promet, centralizirati bilježenje, provoditi ograničenja brzine, povezivati ​​identitete korisnika i agenata, pa čak i filtrirati kojim su alatima ili agentima dostupni podaci u kojim kontekstima. To počinje jako nalikovati API pristupnicima - samo podešenima za AI promet umjesto za obični HTTP.

MCP i A2A, korak po korak, tiho mijenjaju način na koji razmišljamo o integraciji softvera i alatima za kodiranje. Za razvojne programere, asistent za kodiranje priključen na MCP i ACP (Agent Client Protocol za IDE-ove) može otkrivati ​​alate, pozivati ​​jezične poslužitelje, integrirati se s kontrolom verzija i komunicirati s agentima drugih programera – sve putem standardnih protokola. Za poduzeća, višeagentski sustavi mogu međusobno surađivati ​​​​različitim timovima i dobavljačima bez ponovnog povezivanja svega za svaki novi slučaj upotrebe.

Dugoročni pomak je od „hard-integriranih aplikacija“ do „agentskih ekosustava“. Baš kao što su USB i HTTP omogućili povezivanje proizvoljnih uređaja i usluga, MCP i A2A imaju za cilj učiniti alate i agente priključnima. Pobjednici će biti timovi koji ove protokole ne tretiraju kao sjajne logotipe, već kao temeljnu infrastrukturu za način na koji njihovi sustavi komuniciraju, surađuju i razvijaju se tijekom vremena.