MCP vs A2A vs UCP vs AP2 vs A2UI: Objašnjen stek agentskih protokola

Protokoli za AI agente se ubrzano množe: MCP, A2A, UCP, AP2, A2UI i srodni standardi sve se češće pojavljuju na istim dijagramima arhitekture. Često se opisuju kao konkurentski protokoli. U praksi, većina njih rešava različite probleme interoperabilnosti na različitim granicama sistema. Korisno pitanje nije „Koji protokol pobeđuje?“, već „Koji odnos u sistemu treba standardizovati?“

Osnovna greška: poređenje protokola koji se nalaze na različitim granicama

Protokol je koristan zato što je za dva nezavisno implementirana sistema potreban stabilan ugovor. Taj ugovor ima smisla samo ako je granica jasna. Agent koji komunicira sa bazom podataka ima drugačiji problem interoperabilnosti od agenta koji delegira posao drugom agentu, kupca koji autorizuje kupovinu ili udaljenog agenta koji traži od izvorne aplikacije da prikaže formular.

Google-ov vodič za programere za 2026. godinu eksplicitno predstavlja MCP, A2A, UCP, AP2, A2UI i srodne UI protokole kao skup komplementarnih standarda. Isti primer radnog toka može koristiti nekoliko njih zajedno: alate za inventar, udaljene agente za dobavljače, trgovinu za naručivanje, autorizaciju plaćanja za potrošnju i UI protokole za interakciju.

Sloj odgovornosti protokola

1. MCP: povežite agenta sa mogućnostima

Model Context Protocol je otvoreni standard za povezivanje AI aplikacija sa spoljnim sistemima u kojima se nalaze alati, podaci i višekratno upotrebljivi resursi. Server izlaže mogućnosti; MCP domaćin se povezuje sa tim serverom i čini te mogućnosti dostupnim modelu ili aplikaciji.

Trenutna MCP TypeScript v2 dokumentacija opisuje protokol upravo tim rečima: serveri izlažu alate, resurse i promptove, dok se domaćini kao što su razvojna okruženja ili prilagođene aplikacije povezuju sa njima. Zbog toga je MCP prvenstveno protokol za integraciju mogućnosti.

Koristite MCP kada

• AI aplikaciji je potreban standardizovan pristup alatima ili API-jima.
• Želite da jedan server mogućnosti radi sa više kompatibilnih AI domaćina.
• Potreban vam je strukturiran pristup podacima ili resursima bez ručnog kodiranja svake integracije u svakog agenta.
• Spoljni sistem je pružalac mogućnosti, a ne autonomni ravnopravni agent.

2. A2A: povežite nezavisne agente

Agent2Agent (A2A) je dizajniran za komunikaciju između nezavisnih, potencijalno neprozirnih agentskih sistema. Njegova trenutna specifikacija v1.0 fokusira se na otkrivanje mogućnosti, razmenu poruka, zadatke, artefakte, multimodalni sadržaj i dugotrajnu saradnju bez potrebe da jedan agent otkriva svoje interne alate, memoriju ili implementaciju drugom.

Ta neprozirnost je važna granica. Agent koji poziva ne mora da zna da li udaljeni agent interno koristi MCP, prilagođene alate, vlasnički planer, drugog dobavljača modela ili eskalaciju ka ljudima. Potreban mu je ugovor za otkrivanje mogućnosti i delegiranje posla.

A2A v1.0 takođe standardizuje pregovaranje o verzijama i podržava višestruka vezivanja oko zajedničkog modela podataka. Njegov objavljeni mehanizam Agent Card klijentima pruža standardnu tačku otkrivanja za mogućnosti agenta, podržane protokole, zahteve za autentifikaciju i veštine.

Koristite A2A kada

• Jedan autonomni agent treba da delegira posao drugom autonomnom agentu.
• Udaljeni sistem treba da ostane neproziran iza ugovora o mogućnostima.
• Zadaci mogu biti dugotrajni, asinhroni ili zahtevati interakciju čoveka u procesu (human-in-the-loop).
• Agenti su izgrađeni pomoću različitih radnih okvira, jezika, dobavljača ili organizacionog vlasništva.

MCP naspram A2A: vertikalna integracija naspram horizontalne saradnje

Sam A2A projekat sada opisuje razliku kao horizontalnu naspram vertikalne: MCP povezuje agente sa internim alatima i bazama podataka, dok A2A omogućava saradnju između ravnopravnih agentskih sistema (peer-to-peer).

3. UCP: standardizacija agentske trgovine

Universal Commerce Protocol nije generički agentski protokol. On standardizuje procese trgovine između korisničkih interfejsa, trgovaca i pružalaca usluga plaćanja. Google-ova implementacija već podržava mogućnosti kao što su kreiranje korpe, plaćanje, ispunjenje porudžbine i životni ciklus porudžbine kroz profilisane verzije i API-je.

Trgovac može objaviti UCP profil pod /.well-known/ucp opisujući usluge, verzije protokola i mogućnosti. Taj obrazac otkrivanja je važan jer agentskom interfejsu ne bi trebalo da bude potreban prilagođeni ugovor o plaćanju za svakog trgovca.

UCP je takođe namerno modularan. Google-ov tehnički pregled navodi da se može integrisati putem API-ja, A2A i MCP-a i da je kompatibilan sa AP2 za autorizaciju agentskih plaćanja.

Koristite UCP kada

• Tok posla uključuje proizvode trgovca, korpe, plaćanje, ispunjenje ili životni ciklus porudžbine.
• Gradite interfejs trgovca koji treba da funkcioniše sa iskustvima agentske kupovine.
• Integraciji je potrebna semantika specifična za trgovinu, a ne generički pozivi alata.
• Želite interoperabilan trgovinski ugovor koji može koegzistirati sa MCP, A2A i protokolima plaćanja.

4. AP2: dokazivanje da je agent imao ovlašćenje da troši

Agentska trgovina uvodi problem koji uobičajeni tokovi plaćanja nisu morali da rešavaju na isti način: agent može izvršiti transakciju u trenutku kada čovek u realnom vremenu ne klikće na završno dugme. Agent Payments Protocol (AP2) rešava pitanja autorizacije, autentičnosti i odgovornosti za plaćanja vođena agentima.

Google-ov vodič kroz protokol za 2026. godinu opisuje AP2 putem tipiziranih mandata koji beleže nameru korisnika, ograničenja potrošnje i konkretnu transakciju koja se autorizuje. AP2 može funkcionisati kao proširenje uz UCP: UCP opisuje trgovinsku transakciju, dok AP2 pruža dokaz da je agent imao ovlašćenje da izvrši plaćanje.

Ova razlika je važna. Protokol za plaćanje može reći trgovcu šta treba kupiti. On sam po sebi ne dokazuje ko je ovlastio agenta da troši, pod kojim limitom, za kog trgovca, na koliko dugo ili da li je konačna korpa ostala u okviru tog ovlašćenja.

UCP naspram AP2: semantika transakcija naspram ovlašćenja

5. A2UI: omogućite agentima da opisuju interfejse bez posedovanja vašeg frontend-a

Agent-to-User Interface (A2UI) rešava drugu granicu: kako udaljeni ili lokalni agent prenosi bogati interaktivni interfejs matičnoj (host) aplikaciji. Umesto slanja proizvoljnog HTML-a, CSS-a i JavaScript-a, A2UI koristi deklarativne podatke koje host renderuje kroz sopstveni pouzdani katalog komponenti.

Ovo čuva sistem dizajna i bezbednosni model matične aplikacije, a pritom omogućava agentu da zahteva dinamičke interfejse. A2UI v0.9 posebno naglašava nameru korisničkog interfejsa nezavisnu od radnog okvira i strimovana ažuriranja na veb, mobilnim i drugim klijentima.

Google-ov kasniji rad na A2UI + MCP Apps takođe pokazuje da ovi UI modeli nisu nužno međusobno isključivi. Deklarativni izvorni UI i bogatija ugrađena iskustva aplikacije mogu koegzistirati u zavisnosti od zadatka.

Koristite A2UI kada

• Udaljeni agent treba da zatraži formulare, kartice, kontrole ili drugi interaktivni UI.
• Matična aplikacija treba da sačuva svoje izvorne komponente, stilizovanje i bezbednosne granice.
• Ne želite da udaljeni agenti šalju proizvoljan izvršni frontend kod.
• Ista namera UI-ja definisana od strane agenta treba da funkcioniše na različitim klijentskim okvirima.

Test za izbor protokola

Nemojte počinjati od akronima. Počnite od odnosa kome je potrebna interoperabilnost.

Realan radni tok sa više protokola

Zašto je malo verovatno da će jedan univerzalni agentski protokol zameniti sve njih

Univerzalni protokol zvuči jednostavnije sve dok ne mora da kodira semantiku svakog domena. Otkrivanje alata, dugotrajna saradnja agenata, plaćanje, autorizacija plaćanja i izvorni UI imaju različite zahteve u pogledu životnog ciklusa, bezbednosti i ispravnosti.

Sam veb se razvijao kroz slojevite protokole, a ne kroz jedan format poruka za svaki problem. Nastajući agentski stek se očigledno kreće u istom smeru: zajednički horizontalni primitivi, specijalizovani ugovori domena i eksplicitno otkrivanje/verzionisanje.

Arhitektonski izazov se stoga pomera sa pitanja „koji protokol pobeđuje?“ na to koliko se čisto protokoli mogu kombinovati bez dupliranja semantike identiteta, autorizacije, stanja i revizije.

Kombinovanje protokola stvara nove načine otkaza

Izbor protokola ne zamenjuje arhitekturu aplikacije

Otvoreni standardi smanjuju integraciono sprezanje, ali ne odlučuju o vašem domenskom modelu, politici autorizacije, izvoru istine, strategiji ponovnih pokušaja ili kriterijumima prihvatanja. MCP alat i dalje može izložiti pogrešnu mogućnost. A2A agent i dalje može vratiti loš artefakt. UCP proces plaćanja i dalje može sadržati zastarele podatke trgovca. AP2 mandat i dalje može biti pogrešno primenjen aplikativnom logikom.

Tretirajte protokole kao ugovore između komponenti koje se nezavisno razvijaju. Zadržite domensku istinu i ključne politike u aplikativnom sloju koji ih poseduje, a zatim koristite protokole kako biste granice učinili interoperabilnim.

Šta bi promenilo ovaj odgovor?

Tehnološki stek se menja ako dođe do konvergencije protokola, ako jedan standard formalno apsorbuje drugi, ili ako dobavljači standardizuju zajednički sloj identiteta i autorizacije preko više granica. UCP već demonstrira kompoziciju podržavajući API-je, A2A i MCP i integrišući se sa AP2 umesto da ih zamenjuje.

Odgovor se takođe menja u zavisnosti od obima aplikacije. Malom internom agentu može biti potreban samo MCP. Radni tok između više kompanija može zahtevati A2A. Trgovcu može biti potreban UCP bez A2UI. Delegirani agent za kupovinu može zahtevati sve njih. Koristite najmanji skup protokola koji predstavlja stvarne granice bez urušavanja domenske semantike.

Ograničenja

Protokoli o kojima se ovde govori nalaze se na različitim nivoima zrelosti i imaju različite modele upravljanja. A2A je dostigao stabilnu specifikaciju v1.0, dok drugi standardi nastavljaju ubrzano da se razvijaju. Usvajanje u ekosistemu je takođe neujednačeno među dobavljačima i radnim okvirima.

Ovaj članak se fokusira na arhitektonsku odgovornost, a ne na potpunost implementacije. Konkretne metode autentifikacije, transportna vezivanja, šeme i mehanizmi proširenja moraju se preuzeti iz trenutne specifikacije svakog protokola.

Zaključak

MCP, A2A, UCP, AP2 i A2UI imaju više smisla kada se posmatraju kao protokoli za različite odnose, a ne pet konkurentskih pokušaja da se standardizuju „agenti“.

MCP izlaže mogućnosti. A2A koordiniše nezavisne agente. UCP pruža trgovini sopstveni mašinski čitljiv ugovor. AP2 dodaje proverljivo ovlašćenje za plaćanje. A2UI daje agentima bezbedan deklarativni put ka korisničkim interfejsima. Nastajući agentski veb stoga ne zamenjuje protokole veštačkom inteligencijom; on stvara novi stek protokola oko veštačke inteligencije.

Česta pitanja

Rečnik pojmova

Primarni izvori i dodatna literatura