Conectarea a N instrumente la M modele necesita înainte N×M straturi de adaptare. MCP separă partea instrumentelor de partea modelelor, astfel încât fiecare implementează protocolul o singură dată. Articolul explică această alegere de proiectare, abstracția mediilor și acțiunilor din browser și aspectele care încă nu sunt rezolvate.
Când un Agent trebuie să facă efectiv treabă, ajunge de obicei în browser: autentificare, publicare, colectare de date sau completarea formularelor. Dificultatea tehnică nu este dacă poate face clic, ci costul de integrare necesar pentru a pune browserul la dispoziția Agentului.
Capcana adaptărilor N×M
Să presupunem că pe piață există N instrumente și M modele. Furnizorul unui instrument trebuie să scrie câte o integrare pentru fiecare model, iar partea modelului are nevoie de un strat de adaptare pentru fiecare instrument. Ambele părți își întrețin separat implementările, ceea ce duce la N×M variante în total.
Problema este multiplicarea. Adăugarea unui instrument nu înseamnă doar o sarcină în plus, ci conectarea acelui instrument la fiecare model. Invers, când un model schimbă versiunea, instrumentele deja conectate pot necesita o nouă validare. O funcție poate fi foarte bună, dar fără un adaptor pentru un anumit model nu poate fi folosită acolo — instrumentul rămâne blocat în etapa de distribuție.
La început, fiecare trebuia să își scrie propria soluție. Pentru aceleași operațiuni — listarea mediilor, pornirea browserului, citirea unei pagini — integrarea trebuia rescrisă pentru fiecare apelant, iar logica era adesea neuniformă: unii puneau așteptarea în client, alții în server.
Protocolul separă cele două părți
MCP (Model Context Protocol) a fost făcut public la sfârșitul lui 2024. Abordarea sa este standardizarea descoperirii și apelării instrumentelor: ce se expune, cum sunt descriși parametrii și ce structură este returnată sunt definite în protocol.
Arhitectura devine astfel un Agent conectat la un MCP Client, iar Client se conectează conform protocolului la mai multe MCP Server; capabilitățile concrete se află în spatele acelor servere. Volumul de implementare scade de la N×M la N+M: partea modelului implementează clientul o singură dată, iar partea instrumentului serverul o singură dată.
Există doar trei roluri. Host este aplicația care rulează modelul și pornește clientul. Client este implementarea clientului de protocol, în general una pentru fiecare Server. Server este scris de furnizorul instrumentului și expune capabilitățile sub formă de instrumente standardizate.
În prezent există două moduri de comunicare. Modul local folosește intrarea și ieșirea standard, iar clientul și serverul rulează pe aceeași mașină; traseul este scurt și configurația redusă, de aceea este folosit frecvent în automatizare. Modul remote folosește HTTP sau WebSocket și este potrivit pentru implementări distribuite, dar necesită o atenție suplimentară pentru autentificare și limitele rețelei.
În browser sunt expuse trei straturi
Când un mediu de browser este conectat la protocol, capabilitățile expuse se împart, în linii mari, în trei straturi.
Stratul de sus este mediul: listarea mediilor unui cont, crearea unuia nou după o configurație, pornirea unui mediu specific, asocierea unei ieșiri de rețea și închiderea după utilizare. În trecut, aceste operațiuni erau împrăștiate în API-urile diferiților furnizori; acum devin instrumente pe care modelul le poate descoperi și apela. Pornirea returnează de obicei un endpoint de depanare, de exemplu un port sau o adresă WebSocket, care poate fi transmisă unor drivere precum Selenium sau Puppeteer.
Stratul din mijloc este pagina: deschiderea unei adrese, citirea DOM-ului sau a arborelui de accesibilitate, schimbarea filelor și realizarea capturilor de ecran.
Stratul de jos cuprinde acțiunile: clic, introducere de text, derulare, așteptarea unei condiții și gestionarea ferestrelor pop-up.
Schimbarea esențială nu este numărul de acțiuni. Mediul se transformă din cod pe care trebuie să îl scrii singur într-o resursă pe care Agentul o poate alege și folosi. Trebuie doar să precizezi clar obiectivul; Agentul poate decide dacă creează un mediu nou sau reutilizează unul existent și în ce ordine apelează instrumentele. Acest lucru devine deosebit de evident când mai multe medii rulează în paralel: planificarea este descrisă în prompt, nu codificată rigid într-un script.
Ce nu este încă rezolvat
Protocolul rezolvă conectarea, nu corectitudinea. Rămân mai multe aspecte ușor de trecut cu vederea.
Calitatea descrierii instrumentelor determină rezultatul apelurilor. Dacă parametrii sunt greșiți sau este ales instrumentul nepotrivit, protocolul nu poate corecta problema. Pe măsură ce numărul instrumentelor crește, descrierile lor consumă și context, deci trebuie găsit un echilibru între număr și granularitate. Dacă granularitatea este prea mare, modelul nu înțelege câte lucruri poate face un instrument; dacă este prea fină, contextul se umple înainte.
Permisiunile și auditul sunt încă într-un stadiu timpuriu. Multe Server sunt locale, rulează pe o singură mașină, pornesc cu privilegii considerabile și nu au autorizare fină sau jurnale complete ale apelurilor. În modul remote trebuie stabilit mai întâi cine se poate conecta și ce poate vedea.
Instabilitatea paginilor nu dispare nici ea. Elemente care nu pot fi localizate, timpi de încărcare imprevizibili, sesiuni de autentificare expirate și CAPTCHA necesită în continuare așteptări, reîncercări și mecanisme de rezervă. Protocolul standardizează doar punctul de intrare.
Maturitatea ecosistemului este și ea neuniformă. Server diferite nu acceptă exact aceleași tipuri de resurse, structuri de răspuns sau coduri de eroare. Când o sarcină combină mai multe Server, logica de orchestrare trebuie adesea scrisă manual. Protocolul însuși continuă să evolueze, astfel că diferențele de comportament dintre versiuni trebuie urmărite.
Mai există o limită care trebuie menținută clară: protocolul stabilește cum apelează un model instrumentele, nu dacă sarcina în sine este conformă. Dacă colectarea datelor este autorizată, dacă scopul utilizării unui cont este legitim sau dacă sunt încălcate regulile unei platforme sunt evaluări separate și nu depind de cât de bine funcționează conexiunea.
În scenariile cu mai multe medii, izolarea dintre ele și configurarea coerentă a ieșirii de rețea, fusului orar și limbii influențează adesea rezultatul mai mult decât metoda de integrare. La nivelul izolării mediilor, PurpleMark oferă interfețe pentru creare, pornire și configurare de rețea care pot fi apelate de instrumente AI și coordonate de același client.
Acest material explică doar principii tehnice. Folosiți protocoalele și instrumentele relevante în conformitate cu legile și regulile aplicabile.
