ACP vs MCP: două protocoale, două straturi diferite

„Avem deja MCP, de ce mai apare un protocol?" E întrebarea care se aude la fiecare discuție de arhitectură din 2026 și are un răspuns scurt: pentru că cele două rezolvă întrebări diferite. MCP răspunde la „la ce are voie să ajungă agentul". ACP răspunde la „unde rulează agentul și cine îi aprobă acțiunile". Confuzia dintre ele produce decizii de tooling proaste, pentru că se compară un cablu cu o priză.

Articolul tratează amândouă protocoalele așa cum sunt definite în specificațiile lor oficiale, arată cum se combină într-un flux real de lucru și traduce partea care contează pentru o echipă: ce dependență de furnizor dispare, ce risc de securitate rămâne și ce nu rezolvă niciunul dintre ele. Dacă MCP e încă vag pentru tine, pornește din ghidul introductiv despre Model Context Protocol.

Două întrebări diferite

Un agent de cod are nevoie de două conexiuni ca să fie util.

Prima e spre exterior: fișiere, baze de date, sisteme de tichete, API-uri interne. Fără ea, agentul e un model care ghicește. Aici lucrează MCP.

A doua e spre om: cine îi dă sarcina, cine vede pașii intermediari, cine aprobă o scriere de fișier, cine oprește execuția. Într-o echipă de development, locul acela e editorul. Aici lucrează ACP.

Sunt straturi suprapuse, nu alternative. Un agent poate vorbi ACP cu editorul și, în același timp, MCP cu uneltele. Analogia corectă nu e „două standarde care se bat pe aceeași nișă", ci „HTTP și SQL": ambele sunt protocoale, niciunul nu îl înlocuiește pe celălalt.

MCP, pe scurt și corect

Model Context Protocol este un standard deschis pentru conectarea aplicațiilor AI la sisteme externe — documentația oficială îl compară cu „un port USB-C pentru aplicații AI". Mesajele circulă prin JSON-RPC 2.0, iar arhitectura are trei roluri:

• Gazde (hosts) — aplicațiile care inițiază conexiunile;
• Clienți (clients) — conectorii din interiorul aplicației gazdă;
• Servere (servers) — serviciile care oferă context și capabilități.

Serverele expun trei tipuri de capabilități: resurse (context și date), prompturi (mesaje și fluxuri șablonizate) și unelte (funcții pe care modelul le poate executa). În sens invers, clienții pot oferi serverelor elicitation — adică posibilitatea ca serverul să ceară utilizatorului informații suplimentare în timpul execuției.

Specificația în vigoare la data acestui articol e revizia din 28 iulie 2026 și adaugă, peste protocolul de bază, extensii opționale negociate la inițializare: execuție asincronă pentru operații de lungă durată, instrucțiuni structurate pentru fluxuri de agent și elemente de interfață randate în conversație.

Inspirația declarată e Language Server Protocol: la fel cum LSP a standardizat suportul pentru limbaje într-un întreg ecosistem de unelte, MCP standardizează modul în care context și unelte suplimentare intră în ecosistemul aplicațiilor AI. Construirea efectivă a serverelor — arhitectură, securitate, deploy — e subiectul cursului MCP: construirea de servere și integrări.

ACP, pe scurt și corect

Agent Client Protocol standardizează comunicarea dintre editoarele de cod și agenții de programare, „potrivit atât pentru scenarii locale, cât și la distanță". A fost creat de Zed Industries și e publicat sub licență Apache, cu implementări de referință deschise.

Rolurile sunt două:

• Agentul — programul care folosește AI generativ pentru a modifica cod autonom, rulând de regulă ca subproces al clientului;
• Clientul — interfața dintre om și agent, de obicei un editor, care administrează mediul, gestionează interacțiunile și controlează accesul la resurse.

Transportul: agenții locali rulează ca subprocese ale editorului și comunică prin JSON-RPC 2.0 peste stdio; agenții la distanță pot comunica prin HTTP sau WebSocket, iar documentația avertizează că suportul complet pentru scenariul la distanță e încă în lucru.

Fluxul unei sarcini arată așa: initialize negociază versiunea și capabilitățile, opțional urmează authenticate, apoi session/new creează sesiunea (sau session/load reia una existentă). Utilizatorul trimite sarcina prin session/prompt, agentul raportează progresul prin notificări session/update, cere aprobări cu session/request_permission, citește și scrie fișiere prin fs/read_text_file și fs/write_text_file — dacă are capabilitatea — și poate opera un terminal. Utilizatorul poate întrerupe oricând cu session/cancel.

Un detaliu de proiectare care spune totul despre relația dintre cele două protocoale: ACP „reutilizează, acolo unde e posibil, reprezentările JSON folosite în MCP", adăugând tipuri proprii pentru elementele de interfață specifice programării cu agenți — de exemplu afișarea diferențelor între versiuni de fișier.

Cum se combină, într-un flux real

Un exemplu concret, cu ambele straturi active:

1. Deschizi editorul și pornești un agent compatibil ACP. Editorul îl lansează ca subproces și negociază capabilitățile.
2. Îi ceri, prin session/prompt, să adauge validare pe un endpoint și să actualizeze testele.
3. Agentul are nevoie de schema bazei de date. O obține de la un server MCP intern, care expune schema ca resursă. Editorul nu e implicat în această conexiune.
4. Agentul vrea să scrie în două fișiere. Cere permisiunea prin session/request_permission; editorul îți arată diferențele și aștepți tu decizia.
5. Rulează testele într-un terminal gestionat de editor, raportează progresul prin session/update și se oprește cu un motiv explicit.

Observă unde stă fiecare responsabilitate: contextul vine prin MCP, controlul trece prin ACP. Dacă mâine schimbi agentul, serverele MCP rămân. Dacă schimbi editorul, agentul rămâne.

Un amănunt din pasul întâi merită subliniat, pentru că explică de ce ecosistemul poate crește fără să se rupă: negocierea de capabilități. La inițializare, cele două părți își spun reciproc ce știu să facă — dacă editorul oferă acces la fișiere, dacă agentul știe să reia sesiuni, dacă terminalul e disponibil. Un agent nou, cu funcții pe care editorul tău nu le înțelege încă, nu cade; funcționează cu setul comun. E aceeași logică prin care un server de limbaj modern rămâne utilizabil într-un editor mai vechi, și e motivul practic pentru care poți actualiza agentul fără să aștepți o versiune nouă de IDE.

De ce contează pentru o echipă

1. Agentul devine interschimbabil. Până acum, alegerea editorului implica agentul, iar migrarea costa o săptămână de reconfigurare pe om. Cu un strat standard între ele, poți schimba furnizorul de agent când se schimbă prețul sau politica lui de date, păstrând editorul.

2. Aprobările se centralizează în editor. Cererile de permisiune ajung în aceeași interfață, indiferent de agent. Pentru o firmă, asta înseamnă un singur loc în care se definește ce înseamnă „acțiune care cere confirmare".

3. Standardizarea internă devine posibilă fără uniformizare forțată. Poți impune editorul și controalele, lăsând fiecărei echipe agentul potrivit sarcinii ei.

4. Costul următoarei schimbări scade. E singurul argument care contează la nivel de buget: nu economisești azi, ci reduci prețul deciziei de anul viitor.

Partea care rămâne, indiferent de protocol, e arhitectura agentului însuși — cum îi limitezi acțiunile, cum îl evaluezi, cum îl duci în producție. E subiectul cursului AI Agents: arhitectura și automatizarea sistemelor autonome.

Cine implementează, la august 2026

Pe partea de editoare, pagina oficială a protocolului listează Zed, IDE-urile JetBrains, Visual Studio Code, Emacs, Neovim și un set în creștere de aplicații mai mici, de la unelte de notebook până la clienți de chat. Prima integrare a fost Gemini CLI, iar JetBrains a colaborat pentru aducerea protocolului în propriile IDE-uri.

Pe partea de agenți, lista publică depășește patruzeci de implementări și include agenți folosiți zilnic în echipe: agentul Claude, Codex CLI, GitHub Copilot, Cline, OpenHands, Goose, Qwen Code, Devin.

Adopția cea mai vizibilă a venit în iunie 2026, când Devin Desktop — fostul Windsurf — a fost lansat cu suport ACP, astfel încât orice agent compatibil să poată rula în interiorul editorului. Contextul complet al schimbării e în articolul despre ce s-a întâmplat cu Windsurf.

Securitate: unde ajută și unde nu

ACP ajută prin proiectare: accesul la fișiere și la terminal e mediat de capabilități, iar acțiunile sensibile trec printr-o cerere explicită de permisiune, afișată de editor. Zed precizează, pentru agenții terți, că „nimic nu ajunge pe serverele noastre" și că nu stochează și nu antrenează pe codul utilizatorilor fără consimțământ explicit — dar asta e o afirmație despre editor, nu despre agentul pe care îl rulezi în el. Politica de date a agentului rămâne o verificare separată.

MCP, la rândul lui, e explicit despre limitele proprii: specificația spune că protocolul „nu poate impune aceste principii de securitate la nivel de protocol" și pune în sarcina implementatorilor consimțământul, controlul și fluxurile de autorizare. Un avertisment merită citat integral, pentru că e ignorat sistematic: descrierile comportamentului unei unelte, inclusiv adnotările, „trebuie considerate ca fiind de neîncredere, dacă nu provin de la un server de încredere".

Traducerea operațională, pentru o echipă:

• Injecția de prompt rămâne riscul principal. Un server MCP compromis sau o pagină citită de agent pot introduce instrucțiuni. Niciun protocol nu filtrează asta în locul tău.
• Oboseala de aprobare e un risc real. Dacă agentul cere confirmare la fiecare linie, oamenii aprobă în orb. Definește din start ce clase de acțiuni sunt automate și care cer ochi uman.
• Inventarul contează. Ce servere MCP sunt conectate, de cine, cu ce credențiale — e o listă care trebuie să existe scrisă, în registrul intern de sisteme AI.

Ce nu rezolvă ACP

Ca să eviți așteptări greșite:

• Nu standardizează calitatea. Un agent slab rămâne slab în orice editor.
• Nu unifică prețurile sau modelele de facturare. Fiecare agent își păstrează modelul lui de cost.
• Nu configurează MCP în locul tău. Serverele rămân definite la nivel de agent, în fișierele lui de configurare.
• Nu e complet pentru agenți la distanță. Documentația spune explicit că suportul pentru scenariile găzduite în cloud e în lucru.
• Nu înlocuiește politica internă. Cine are voie să ruleze agenți pe ce repository e o decizie de firmă, nu o setare.

Cum îl încerci în treizeci de minute

Pentru cine vrea să verifice singur, fără să mute echipa: alege un editor cu suport nativ, pornește în el un agent compatibil, deschide un proiect de test fără date sensibile și dă-i o sarcină care atinge două-trei fișiere. Urmărește trei lucruri: cum arată cererile de permisiune, cum sunt prezentate diferențele înainte de scriere și dacă întreruperea funcționează instantaneu. Apoi conectează un singur server MCP — de exemplu unul care expune documentația internă — și repetă sarcina. Diferența de calitate dintre cele două rulări e exact valoarea pe care o aduce stratul de context.

Întrebări frecvente

Î: ACP înlocuiește MCP? R: Nu. MCP standardizează legătura dintre aplicația AI și sursele de date sau unelte. ACP standardizează legătura dintre editor și agentul de cod. Un agent poate — și, de regulă, chiar o face — să folosească ambele simultan.

Î: Cine controlează ACP și sub ce licență e publicat? R: A fost creat de Zed Industries și e publicat sub licență Apache, cu specificația și implementările disponibile public. Google a realizat prima integrare, prin Gemini CLI, iar JetBrains a colaborat pentru suportul din propriile IDE-uri.

Î: Ce transport folosesc cele două protocoale? R: Ambele folosesc JSON-RPC 2.0. În ACP, agenții locali rulează ca subprocese ale editorului și comunică prin stdio, iar scenariile la distanță folosesc HTTP sau WebSocket, cu suport încă în dezvoltare.

Î: Dacă folosesc deja servere MCP interne, trebuie să le modific pentru ACP? R: Nu. Serverele MCP rămân conectate la agent, nu la editor. ACP schimbă doar felul în care agentul comunică cu interfața în care lucrezi.

Î: Reduce ACP dependența de un singur furnizor? R: Reduce costul schimbării, ceea ce e altceva. Poți înlocui agentul păstrând editorul și integrările MCP, dar rămâi dependent de calitatea, prețul și politica de date ale agentului pe care îl alegi.

Concluzie

Cele două protocoale desenează, împreună, arhitectura de lucru a anului 2026: MCP a standardizat accesul agentului la context, ACP standardizează relația dintre agent și locul în care omul aprobă, verifică și oprește. Prima a rezolvat problema „agentul nu știe nimic despre sistemele noastre". A doua rezolvă problema „alegerea uneltei ne blochează pentru doi ani".

Pentru o echipă, decizia practică nu e „ACP sau MCP", ci una de ordine: întâi definești ce context are voie să atingă un agent și cum se aprobă acțiunile lui, apoi alegi uneltele care respectă definiția. Protocoalele fac schimbarea ieftină; regulile rămân treaba voastră.

Surse

• Agent Client Protocol — documentația oficială: https://agentclientprotocol.com/
• Agent Client Protocol — prezentarea protocolului, roluri și metode: https://agentclientprotocol.com/protocol/overview
• Agent Client Protocol — cod sursă și licență: https://github.com/agentclientprotocol/agent-client-protocol
• Zed, pagina ACP (editoare și agenți compatibili, licență, declarația privind datele): https://zed.dev/acp
• Model Context Protocol — introducere: https://modelcontextprotocol.io/docs/getting-started/intro
• Model Context Protocol — specificația, revizia 28 iulie 2026: https://modelcontextprotocol.io/specification/2026-07-28
• Cognition, „Introducing Devin Desktop" (suport ACP, iunie 2026): https://cognition.com/blog/introducing-devin-desktop

Articol informativ, publicat la 22 august 2026. Specificațiile protocoalelor și lista implementărilor se modifică frecvent — verificați documentația oficială înainte de a lua decizii de arhitectură.