Google ADK și A2A: agenți AI care colaborează controlat

Google ADK este un framework pentru construirea agenților AI, iar A2A este un protocol pentru comunicarea dintre agenți. Primul organizează comportamentul unei aplicații; al doilea stabilește cum poate aceasta să colaboreze cu un agent la distanță. Alegerea lor răspunde la întrebări diferite și nu înlocuiește regulile firmei.

Pentru o companie, interoperabilitatea devine utilă când există responsabilități separate: un sistem cunoaște catalogul, altul gestionează solicitarea, iar o persoană aprobă propunerea. Înaintea tehnologiei stabilim ce se transmite, cine poate cere informația și ce rezultat trebuie verificat. Mai mulți agenți nu reprezintă automat o arhitectură mai bună.

Ghidul folosește un exemplu propus de pregătire a unei oferte, nu o implementare de client. Schemele sunt originale. Fotografiile autentice ilustrează analiza documentelor și infrastructura informatică, nu un produs ADK sau o instalare WebHat. Nu trimitem oferte, nu emitem documente fiscale și nu folosim date confidențiale.

ADK, A2A și MCP: ce problemă rezolvă fiecare?

Framework-ul, protocolul și instrumentul nu sunt același strat

Documentația Google definește ADK prin construirea și operarea agenților. Documentația A2A separă colaborarea dintre agenți de conectarea unui agent la instrumente și resurse prin MCP. Aceste nume nu desemnează modele lingvistice. Niciunul nu reprezintă, prin simpla instalare, întreaga aplicație folosită de angajații unei firme.

În exemplul nostru, coordonatorul ar putea folosi ADK pentru comportamentul propriu și A2A pentru a cere informații unui agent de catalog separat. Agentul de catalog poate utiliza intern alt framework. Pentru o citire fixă dintr-un catalog propriu, o integrare API deterministă poate fi suficientă și mai simplu de întreținut.

Harta tipurilor de inteligență artificială ajută la separarea tehnologiei de sarcină și autonomie. Aici discutăm arhitectura aplicației, nu creșterea capacității modelului. Un protocol comun poate face schimbul compatibil; corectitudinea datelor, drepturile și acceptarea rezultatului cer controale proprii, explicite în specificație.

Ce construim efectiv cu Google ADK?

Agentul are un scop delimitat în interiorul aplicației

ADK oferă mecanisme pentru definirea unui agent, a instrumentelor sale și a fluxului de lucru. Pentru coordonatorul propus, cerința este pregătirea unei variante interne de ofertă. Agentul nu primește obiectivul vag de a vinde cu orice preț, ci o responsabilitate care poate fi descrisă și testată.

Definim intrarea acceptată, informațiile obligatorii, situațiile în care cere clarificare și formatul rezultatului. O solicitare fără cantitate nu este completată printr-o presupunere prezentată drept cerință a clientului. Aplicația poate păstra separat câmpurile confirmate, propunerile agentului și întrebările deschise, astfel încât revizorul să vadă diferența.

În proiectarea agenților AI și a nivelului de autonomie, alegem distinct ce poate propune și ce poate executa sistemul. Numele framework-ului nu stabilește autoritatea comercială. Dacă procesul permite doar redactarea unei variante, instrumentele expuse nu trebuie să includă trimiterea automată sau modificarea liberă a catalogului.

Ce adaugă A2A între două aplicații?

Un contract comun pentru un agent al cărui interior rămâne separat

În A2A, clientul comunică cu un agent la distanță fără să primească acces direct la memoria, instrumentele și implementarea acestuia. Schimbul are concepte comune pentru solicitări și rezultate. Această separare este importantă când sistemele sunt întreținute de echipe diferite sau aparțin unor organizații cu reguli distincte.

În scenariul propus, cererea către catalog conține doar specificațiile necesare și identitatea verificabilă a solicitantului în mecanismul de acces. Nu trimitem întregul dosar comercial pentru o întrebare despre compatibilitatea unei componente. Datele returnate trebuie să păstreze referința și versiunea folosite, pentru verificarea ulterioară a propunerii.

Comparația cu instrumentele de orchestrare a aplicațiilor AI arată de ce protocolul și framework-ul sunt alegeri independente. Un graf intern poate coordona pași locali; A2A definește schimbul la granița cu serviciul distant. Nu presupunem că această graniță transmite automat toate regulile, istoricul sau permisiunile aplicației inițiale.

Ce este Agent Card și ce nu dovedește?

Descrierea unei capacități nu este permisiune de utilizare

Agent Card este descrierea structurată a unui agent: identitate, capacități, puncte de acces și cerințe de autentificare. Documentația A2A descrie descoperirea publică, registrele și configurația privată. Pentru o integrare internă putem alege o listă aprobată de servicii, nu descoperirea liberă a oricărui agent găsit online.

În exemplul de ofertare, faptul că un card anunță consultarea catalogului nu dovedește că utilizatorul poate vedea prețurile negociate. Serviciul de catalog verifică dreptul real pentru solicitarea concretă. Nici descrierea unei competențe și nici numele furnizorului nu sunt, singure, o măsurare a calității răspunsului produs.

Definim cine aprobă agentul partener, ce versiune a contractului este acceptată și cum se schimbă configurația. Dacă descrierea include adrese interne ori competențe sensibile, accesul la aceasta se controlează separat. Cardul nu este locul pentru parole, chei statice sau informații comerciale care nu trebuie expuse celor care îl descoperă.

Cum urmărim o sarcină fără să confundăm progresul cu aprobarea?

Task, context și rezultat au responsabilități distincte

O sarcină A2A poate avea stare urmărită, iar un context poate grupa interacțiuni înrudite. Un mesaj comunică informație; un artifact reprezintă un rezultat produs. Identificatorii ajută aplicația să urmărească procesul, dar nu țin loc de autentificare, drept de acces sau aprobare comercială a conținutului primit.

Coordonatorul poate primi informații parțiale și poate cere clarificări înaintea pregătirii variantei. În interfața firmei afișăm separat starea tehnică și starea reviziei. „Rezultat disponibil” descrie disponibilitatea unei ieșiri; „aprobat pentru trimitere” este o decizie a procesului comercial, luată pentru varianta exactă pe care a văzut-o revizorul.

Documentația ciclului de viață tratează sarcinile terminale ca închise; continuarea înrudită poate necesita o sarcină nouă în același context. Aplicația păstrează legătura dintre versiuni fără să rescrie istoria. O corectură ulterioară nu trebuie prezentată ca și cum ar fi fost rezultatul inițial acceptat ori verificat.

Unde se aplică autentificarea și autorizarea?

Fiecare serviciu verifică identitatea și operațiunea cerută

Specificația A2A separă autentificarea cererii de autorizarea operațiunii. Implementările de producție folosesc transport criptat și verificarea identității serviciului. După identificarea solicitantului, aplicația decide ce informații și acțiuni sunt permise. Compatibilitatea cu protocolul nu acordă automat acces la toate datele deținute de agentul partener.

Pentru catalog, proiectăm drepturi concrete: consultarea caracteristicilor, vizibilitatea anumitor prețuri și imposibilitatea modificării acestora din fluxul de propunere. Un identificator de sarcină ghicit sau primit de la alt utilizator nu trebuie să permită citirea rezultatului. Verificarea se face pe server pentru obiectul și operațiunea solicitate, nu doar în interfață.

Ghidul despre protecția datelor în aplicațiile AI completează analiza schimbului. Pentru proiectul propus stabilim câmpurile permise, perioada de păstrare și cine poate vedea jurnalul. Nu copiem integral documentele în fiecare înregistrare tehnică doar pentru că ar simplifica investigarea unei erori de integrare.

O schimbare a rolului utilizatorului trebuie să aibă efect și asupra sarcinilor începute anterior. Verificăm separat citirea rezultatului, continuarea lucrului și aprobarea variantei. Revocarea dreptului nu trebuie anulată indirect printr-un rezultat păstrat într-o altă componentă. Aceasta este o cerință a aplicației propuse, verificată printr-un caz de test dedicat.

Cum se leagă agenții de datele și instrumentele firmei?

Interoperabilitatea nu repară informațiile incomplete sau operațiunile nesigure

Agentul de catalog poate folosi intern o căutare sau o integrare cu sistemul existent. Alegerea depinde de structura datelor și de cerință. Pentru câmpurile comerciale controlate păstrăm sursa autoritară; o formulare fluentă produsă de model nu devine automat prețul ori termenul de livrare confirmat al companiei.

Relația cu RAG, fine-tuning și prompt engineering privește accesul la informație și comportamentul răspunsului. Protocolul A2A nu spune singur care document este actual sau ce fragment susține concluzia. În propunere păstrăm referințele interne necesare reviziei și marcăm informațiile care cer confirmare.

Integrarea are nevoie și de tratarea întreruperilor. Dacă răspunsul întârzie, coordonatorul nu presupune că serviciul distant nu a făcut nimic. Definește o stare de verificat și o procedură de reconciliere. Pentru efecte externe, cheia operațiunii și evidența persistentă se proiectează la nivelul aplicației, nu se deduc dintr-un simplu retry.

Cum verificăm colaborarea dintre agenți?

Evaluăm contractele și refuzurile, nu doar un dialog reușit

Pentru fiecare caz de test, fixăm cererea, drepturile utilizatorului, versiunea catalogului și rezultatul așteptat. Verificăm dacă propunerea folosește numai datele permise și dacă lipsurile rămân vizibile. O demonstrație cu o solicitare completă nu acoperă comportamentul când apare o eroare, o întârziere sau o modificare a sursei.

Un test important schimbă drepturile înaintea reluării. Altul modifică versiunea catalogului după redactare, dar înaintea reviziei. Procesul trebuie să aplice regula definită: oprire, reverificare sau recalculare. Nu acceptăm automat ieșirea veche doar pentru că sarcina distantă a avut o stare tehnică de succes.

Ghidul despre automatizări AI și controlul repetării operațiunilor explică o problemă comună și integrărilor cu agenți. Măsurăm separat timpul de răspuns, calitatea conținutului, refuzurile corecte și cazurile care cer intervenție. Niciun scor compus inventat nu înlocuiește analiza unei expuneri nepermise de informație.

Ce verificăm înaintea alegerii unei implementări ADK/A2A?

Versiunea și maturitatea funcției intră în decizia tehnică

La verificarea din 2 noiembrie 2026, documentația ADK marchează integrarea A2A ca experimentală. Alegerea unei implementări cere verificarea versiunilor, a bindingului de protocol și a funcțiilor folosite. Nu transformăm existența unui exemplu de pornire în dovada compatibilității pentru toate combinațiile de limbaj, SDK și serviciu partener.

Documentația confirmării instrumentelor ADK menționează caracterul experimental și limitări pentru anumite servicii de sesiune, inclusiv DatabaseSessionService și VertexAiSessionService. Pentru un flux care așteaptă revizie și trebuie să supraviețuiască repornirii, verificăm exact combinația aleasă. Aprobarea persistentă nu este dedusă din simpla existență a unui buton de confirmare într-un exemplu.

Într-un proiect de dezvoltare software pentru procesele firmei, aceste condiții intră în arhitectură, test și mentenanță. Putem păstra responsabilitățile separate prin interfețe proprii, astfel încât o schimbare de framework să nu rescrie regulile comerciale. Alegem tehnologia după cerințele demonstrate, nu invers, după o listă de produse.

În fișa tehnică păstrăm combinația evaluată, funcțiile folosite și cazurile acceptate. O actualizare se verifică pe aceleași scenarii înainte de a înlocui versiunea aflată în operare. Dacă schimbarea afectează formatul unei ieșiri, ajustăm contractul și validatorul la sursă; nu acumulăm transformări ascunse care fac dificilă înțelegerea rezultatului final.

Ce costuri și responsabilități rămân în afara protocolului?

Repository-ul verificat pentru ADK Python are licență Apache 2.0. Aceasta identifică licența proiectului respectiv, nu prețul tuturor modelelor, serviciilor sau integrărilor conectate. Pentru buget separăm infrastructura, apelurile de model, stocarea, observabilitatea, dezvoltarea și timpul de verificare umană. Folosirea unui protocol deschis nu elimină aceste componente.

Separarea în mai multe servicii adaugă granițe de acces, erori de rețea și versiuni de întreținut. Beneficiul trebuie să fie concret: responsabilitate independentă, reutilizare sau integrarea unor sisteme deja separate. Dacă aceleași cerințe sunt acoperite de o aplicație simplă cu pași expliciți, nu introducem agenți suplimentari doar pentru aspectul demonstrației.

Stabilim și responsabilul operațional pentru fiecare serviciu. Cine investighează un rezultat lipsă, cine schimbă contractul și cine retrage un agent partener din lista aprobată? Aceste întrebări au răspunsuri în proiect înaintea lansării. Ele fac diferența dintre un schimb tehnic demonstrabil și o funcție pe care firma o poate administra coerent.

Cum pornim un proiect cu agenți interoperabili?

Începem cu o singură colaborare, cu intrări și ieșiri clare, fără efecte externe automate. Pentru varianta de ofertă, verificăm întâi accesul la catalog și calitatea propunerii. Abia după validarea acestora discutăm operațiuni suplimentare și aprobările lor, fiecare pentru o cerință identificată și un rezultat observabil.

Prin automatizări business cu integrare AI, WebHat poate proiecta fluxul pornind de la sistemele existente și rolurile echipei. Livrabilul include contractele dintre componente, interfața de revizie, verificările de acces și dovezile de test. ADK și A2A sunt opțiuni tehnice în această arhitectură, nu obiectivul comercial în sine.

La predare, echipa trebuie să înțeleagă ce vede în fiecare stare și ce poate face în continuare. O cerere de clarificare, un refuz de acces și o eroare tehnică au mesaje și acțiuni diferite. Interfața păstrează această diferență, astfel încât operatorul să rezolve cauza, nu să repete aceeași solicitare fără informație nouă.

Întrebări frecvente despre Google ADK și A2A

ADK și A2A sunt același lucru?

Nu. ADK este un framework pentru construirea agenților, iar A2A este un protocol pentru comunicarea dintre agenți. Un agent construit cu ADK poate utiliza A2A într-o implementare compatibilă. Agentul partener poate avea alt framework, iar aplicația poate folosi o integrare mai simplă dacă cerința nu solicită colaborare între agenți.

Agent Card îi dă utilizatorului acces la toate competențele descrise?

Nu. Cardul descrie ce oferă serviciul și condițiile de conectare. Serverul verifică identitatea, drepturile și operațiunea concretă. Pentru catalogul din exemplu, vizibilitatea caracteristicilor și a prețurilor poate fi diferită. Descrierea unei competențe nu înlocuiește această regulă și nu confirmă calitatea fiecărui rezultat produs de agent.

O sarcină finalizată înseamnă că oferta poate fi trimisă?

Finalizarea tehnică arată starea sarcinii, nu aprobarea comercială. Propunerea trebuie verificată pentru varianta exactă, cu sursele și drepturile actuale. Procesul definește separat cine o poate accepta și cine poate autoriza trimiterea. În exemplul articolului, operațiunea externă nu este executată și nu sunt emise documente fiscale.

Avem nevoie și de MCP pentru a folosi A2A?

Nu există o cerință generală ca fiecare aplicație să le folosească împreună. A2A și MCP acoperă relații diferite: colaborarea între agenți, respectiv conectarea la instrumente și resurse. Arhitectura alege mecanismul potrivit pentru fiecare graniță. Un serviciu existent poate fi integrat și printr-o interfață proprie bine definită.

Ce se întâmplă dacă agentul partener nu răspunde la timp?

Aplicația aplică procedura de tratare a stării necunoscute, cu identificatorii și verificările definite în contract. O întârziere nu dovedește că operațiunea nu a avut loc. Pentru efecte externe, reconcilierea și protecția împotriva repetării se proiectează explicit. Nu relansăm orbește aceeași acțiune doar pentru a obține un răspuns vizibil.

Când merită să separăm procesul în mai mulți agenți?

Când separarea are un rol concret: servicii administrate independent, competențe reutilizabile sau colaborare între sisteme cu granițe reale. Comparăm această arhitectură cu un flux determinist și cu un singur agent. Alegerea se bazează pe cerințe, teste, controlul datelor și costul de operare, nu pe numărul de agenți din schemă.