Protocollo ACP: agenti AI diversi, lo stesso editor

Il protocollo ACP (Agent Client Protocol) permette di cambiare agente AI per la programmazione senza cambiare editor, purché entrambi lo supportino. Con Android Studio Rabbit 2, Google rende questa scelta concreta per chi sviluppa su Android: l’annuncio di ottobre parla di oltre 40 agenti per la programmazione, selezionabili direttamente nell’IDE. Il vantaggio è poter mantenere il proprio ambiente di sviluppo e scegliere l’agente a cui affidare il lavoro.

Il numero indicato da Google proviene dall’annuncio di Android Studio del 28 ottobre 2026. Le informazioni su supporto e configurazione riportate qui sono state verificate sul sito del protocollo e nella documentazione degli editor il 3 novembre 2026. Questa guida si basa sulla documentazione: non è un benchmark degli agenti condotto sul campo.

Che cosa cambia con il protocollo ACP

ACP offre a editor e agenti di programmazione un’interfaccia comune per prompt, avanzamento delle attività, permessi e risultati. Un agente è un programma che combina un modello, strumenti e un ciclo di lavoro per svolgere un compito. L’editor, o ambiente di sviluppo integrato (IDE), è invece il luogo in cui si esamina il codice, si rivedono le modifiche e si interagisce con quel programma.

Il paragone più utile è con il Language Server Protocol (LSP), che ha standardizzato il collegamento tra editor e language server. Un language server fornisce funzionalità specifiche per un linguaggio, come la diagnostica. ACP applica la stessa separazione agli agenti di programmazione: l’editor implementa il collegamento lato client, mentre l’agente implementa ACP direttamente o tramite un adapter. La compatibilità deve esserci da entrambe le parti. L’introduzione ad ACP spiega che questo approccio evita di dover creare un’integrazione su misura per ogni abbinamento.

Per chi alterna Claude Code di Anthropic, Codex di OpenAI e Gemini CLI di Google, il vantaggio è la continuità dell’ambiente di lavoro. Si può valutare un altro agente senza dover includere anche l’editor nella migrazione. Le modalità di integrazione con ACP restano però diverse, come mostra la panoramica qui sotto.

Chi ha creato ACP?

ACP è nato in Zed Industries, che ha collaborato con Google per fare di Gemini CLI la prima implementazione di riferimento. Zed ha annunciato la collaborazione il 27 agosto 2025. In seguito si è unita JetBrains, la cui pagina attuale presenta ACP come un protocollo sviluppato apertamente da JetBrains e Zed. Google è uno dei primi partner per l’implementazione e adotta il protocollo in Android Studio. Il post di lancio di Zed e la pagina ACP di JetBrains chiariscono questi ruoli distinti.

È una distinzione utile quando si valuta il supporto: creare il protocollo, mantenere un adapter e distribuire un client integrato in un editor sono contributi diversi.

Quali editor e agenti supportano ACP?

Zed, gli IDE JetBrains e Android Studio documentano come collegarsi agli agenti ACP. Altri editor si affidano a plugin o estensioni: va quindi verificata l’integrazione che si intende effettivamente installare. La presenza in un elenco conferma che esiste un’integrazione, ma non garantisce che ogni funzionalità si comporti allo stesso modo.

I nomi dei plugin riportati nella tabella seguono l’elenco dei client ACP. Le informazioni su Zed, JetBrains e Android Studio provengono dalla rispettiva documentazione, citata nelle sezioni seguenti. È una selezione utile per chi programma, non un elenco completo dei client ACP.

Zed: gli agenti esterni hanno una configurazione propria

Zed integra gli agenti ACP nell’Agent Panel e nella Threads Sidebar. La documentazione attuale cita Claude, Codex, OpenCode, Copilot, Cursor e Pi tra gli agenti esterni più comuni e include anche le istruzioni per configurare Gemini CLI. Il canale principale di installazione è l’ACP Registry. La documentazione di Zed sugli agenti esterni spiega sia l’installazione sia a chi compete la configurazione.

Il limite pratico riguarda le impostazioni ereditate. I profili Zed Agent e le Zed Skills non diventano automaticamente impostazioni dell’agente esterno. Quando si documenta la configurazione del team, occorre annotare anche le istruzioni, le credenziali e gli strumenti propri dell’agente.

JetBrains: verificare i vincoli dell’organizzazione e dell’ambiente

JetBrains AI Assistant rende disponibili gli agenti ACP tramite AI Chat. È possibile installare un agente da Settings > Tools > AI Assistant > Agents, oppure aggiungerne uno personalizzato usando acp.json. La documentazione precisa inoltre che gli agenti ACP al momento non sono supportati in Windows Subsystem for Linux (WSL) e che gli amministratori possono limitare le voci del registro o gli agenti personalizzati. La documentazione ACP di JetBrains è il riferimento per questi vincoli.

Per un responsabile tecnico, questo significa verificare l’ambiente della postazione prima di consigliare l’integrazione. Il fatto che funzioni sul portatile di un collega non dimostra che sia supportata nel flusso di lavoro WSL gestito dall’organizzazione.

Agenti: supporto nativo e adapter non sono la stessa cosa

L’elenco degli agenti ACP identifica con precisione le integrazioni disponibili:

• Claude Agent compare tramite l’adapter SDK di Zed. È il nome usato nell’elenco per l’integrazione con Claude; non significa che la CLI di Claude Code supporti ACP in modo nativo.
• Codex CLI compare tramite l’adapter di ACP. Anche l’adapter va incluso nell’elenco dei componenti avviati dall’editor.
• Gemini CLI compare come agente che implementa il protocollo, senza indicazioni relative a un adapter.
• GitHub Copilot è esplicitamente contrassegnato come anteprima pubblica nella pagina.

La stessa pagina elenca anche Augment Code, Cline, Cursor, cagent di Docker, Factory Droid, Goose, Hermes Agent, Junie di JetBrains, Kimi CLI, Kiro CLI, Mistral Vibe, OpenCode, OpenHands e Qwen Code. Pi compare tramite un adapter pi-acp. Sono alcune delle voci presenti, riportate con i nomi dell’elenco; la pagina collegata contiene la lista completa.

Questo elenco non va interpretato come una garanzia di compatibilità universale con gli editor. La combinazione effettivamente utilizzabile dipende dall’agente, dall’eventuale adapter, dall’integrazione nell’editor e dalle funzionalità che le parti negoziano.

Che cosa offre Bring Your Own Agent in Android Studio

Android Studio consente di scegliere l’agente di programmazione mantenendo gli strumenti per lo sviluppo Android. Nell’annuncio della versione stabile, Google cita Claude Agent, Codex, Junie e Google Antigravity e dichiara che gli agenti possono accedere ad Android Emulator, ai sistemi di build, a Logcat e alle skill per Android. Logcat è lo strumento di Android per visualizzare i log delle applicazioni e del sistema. L’annuncio di Google su Rabbit 2 documenta l’accesso a questi strumenti.

Chi sviluppa per Android può pensare all’analisi di un crash: serve un agente che lavori insieme agli strumenti di build e diagnostica del progetto, mantenendo l’ambiente familiare in cui esaminare la correzione. BYOA permette di scegliere l’agente indipendentemente da quello spazio di lavoro. La sua capacità di diagnosticare bene il crash resta da valutare.

Per un responsabile tecnico, questo rende più utile una sperimentazione iniziale. Basta mantenere invariati repository, attività e processo di revisione per confrontare gli agenti approvati nello stesso ambiente. Vanno valutati la patch prodotta, i comandi richiesti e le evidenze a sostegno della risposta. Il solo fatto che il collegamento funzioni non basta a rendere riuscita l’adozione.

Dal lancio in anteprima alla versione stabile

Google ha presentato BYOA in anteprima il 24 settembre 2026, a partire da Android Studio Rabbit 2 Canary. Il 28 ottobre 2026 ha annunciato la versione stabile di Rabbit 2, con BYOA incluso. Il nuovo annuncio supera quindi lo stato di anteprima indicato nel post di lancio. Annuncio dell’anteprima, annuncio della versione stabile.

L’etichetta di anteprima va sempre riferita al componente specifico a cui si applica. Il rilascio stabile di Android Studio non elimina l’eventuale stato di anteprima pubblica di un altro agente e non garantisce che un adapter offra tutte le stesse funzionalità.

Come funziona una sessione ACP

L’editor avvia l’agente e scambia con esso messaggi strutturati. Con il trasporto locale, l’editor avvia un sottoprocesso, cioè un altro programma in esecuzione nel sistema operativo. La connessione usa JSON-RPC 2.0, un formato per richieste, risposte e notifiche, su stdio, i flussi di input e output standard del processo. Si tratta quindi di una comunicazione strutturata, non della lettura del testo visualizzato in un terminale. Panoramica del protocollo, specifica dei trasporti.

La sessione segue una sequenza precisa:

1. Avvio e negoziazione. L’editor avvia l’agente o l’adapter e invia initialize. Le due parti si scambiano le versioni del protocollo e le funzionalità supportate.
2. Autenticazione, se richiesta. Si completa la procedura di autenticazione indicata dall’agente. Una connessione riuscita con l’editor non fornisce un account per l’agente.
3. Apertura della conversazione. L’editor invia session/new con la directory di lavoro e gli eventuali server MCP che mette a disposizione. L’agente restituisce un identificatore di sessione.
4. Invio dell’attività e aggiornamenti sull’avanzamento. L’editor invia session/prompt; l’agente comunica messaggi e attività degli strumenti tramite notifiche session/update.
5. Gestione delle azioni richieste. Quando l’agente chiede un’autorizzazione, l’editor mostra le opzioni disponibili e restituisce la decisione. Il turno si conclude con una risposta che ne indica il motivo di arresto.

Sono il flusso dei messaggi e le regole per la creazione delle sessioni descritti nella documentazione. Una sessione è la conversazione dell’agente, con il proprio contesto e stato, non un file di conversazione universale condiviso tra tutti i fornitori.

Modifiche ai file e comandi nel terminale

L’accesso ai file e al terminale dipende dalle funzionalità negoziate. Quando sono supportate, l’agente può usare fs/read_text_file per leggere tramite l’editor, comprese le modifiche non salvate, e fs/write_text_file per scrivere attraverso di esso. È rilevante quando il contenuto del buffer visualizzato non coincide con il file salvato su disco. Specifica ACP per il filesystem.

Per i comandi, terminal/create chiede al client di avviare un processo. Altri metodi permettono di recuperarne l’output, attenderne la conclusione, interrompere il comando e rilasciare il terminale. Prima di usarli, l’agente deve verificare che il client abbia dichiarato il supporto al terminale. Specifica ACP per i terminali.

Un agente può anche eseguire autonomamente le proprie operazioni e usare ACP per comunicare le modifiche sotto forma di diff e l’avanzamento degli strumenti. Vedere un’attività nell’editor non significa che sia stato l’editor a eseguirla. Specifica delle chiamate agli strumenti.

ACP vs MCP: quali collegamenti gestiscono?

ACP collega l’editor all’agente; Model Context Protocol (MCP) collega un’applicazione o un agente AI a strumenti e dati. I due protocolli possono collaborare nella stessa sessione. Il confronto si basa sulla specifica delle sessioni ACP e sull’introduzione a MCP.

Quando manca uno strumento, occorre controllare sia il collegamento allo strumento sia quello all’editor. JetBrains, per esempio, dispone di impostazioni distinte per passare agli agenti i server MCP personalizzati e il proprio server IntelliJ MCP integrato. Il supporto ad ACP, da solo, non attiva tutti gli strumenti. Le impostazioni del registro di JetBrains documentano questi controlli.

Se si sta progettando l’interfaccia del servizio sottostante, MCP vs API affronta una scelta diversa: come esporre le funzionalità di un’applicazione. Per chi costruisce un’applicazione attorno agli agenti di programmazione, la guida all’adapter ACP di Vercel AI SDK approfondisce quel livello di integrazione.

Come collegare Claude Agent ad Android Studio

Si sceglie l’agente dal selettore di Android Studio e ci si autentica presso il suo fornitore. La procedura attuale di Google passa dalla finestra degli agenti o da Settings > Tools > AI > Agents. Le istruzioni di lancio prevedono l’accesso con un account oppure l’inserimento di una chiave API; i piani di account supportati dipendono dal fornitore. Procedura di configurazione attuale, istruzioni per l’autenticazione.

1. 1

   Usa una versione con BYOA

   Usa Android Studio Rabbit 2 stabile oppure una versione successiva la cui documentazione includa BYOA. L’indicazione iniziale di usare esclusivamente Canary risale al lancio in anteprima.

2. 2

   Seleziona Claude Agent

   Apri la finestra degli agenti e seleziona Claude Agent. Puoi scegliere gli agenti anche da Settings > Tools > AI > Agents.

3. 3

   Autenticati per usare l’agente

   Segui la procedura di accesso dell’agente oppure inserisci una chiave API, se l’opzione è disponibile. Usa l’account e il metodo di accesso approvati per il progetto. Per collegare un altro agente servono l’autenticazione e i diritti di accesso previsti da quell’agente.

4. 4

   Invia un primo prompt circoscritto

   La configurazione descritta da Google si conclude con l’invio di un prompt. Una prima attività utile può essere: «Spiega come viene compilato questo progetto e individua il task di test pertinente. Non modificare i file». È un punto di partenza suggerito, non il risultato di un test del fornitore.

5. 5

   Verifica il flusso di lavoro prima di estenderne l’uso

   Chiedi poi una piccola modifica, facile da rivedere, su un branch di lavoro. Esamina la modifica proposta, le opzioni di autorizzazione e gli eventuali comandi richiesti. Prima di assegnare un’attività più ampia, accertati di comprendere il risultato. Questi sono consigli per l’adozione, aggiuntivi rispetto ai passaggi di connessione del fornitore.

Se l’autenticazione fallisce, correggi la configurazione dell’account o della chiave dell’agente selezionato. Se invece l’agente si collega ma non riesce a usare uno strumento, verifica le funzionalità esposte dall’integrazione. Sono punti di errore diversi: conviene registrarli separatamente nelle note di configurazione.

I limiti da valutare in un team

Standardizzare il collegamento non elimina la necessità di verificare il comportamento di ciascun agente. Il protocollo evita di ripetere il lavoro di integrazione, ma non rende gli agenti intercambiabili in ogni dettaglio operativo.

L’autenticazione resta specifica per ogni agente. Per ciascun fornitore scelto occorre prevedere una modalità di accesso o di gestione delle chiavi API. Un’implementazione può riutilizzare credenziali esistenti, ma ACP non è un account condiviso né un insieme comune di quote d’uso. Zed, per esempio, documenta l’autenticazione propria degli agenti esterni e i rapporti con i rispettivi fornitori. Ambiti di configurazione in Zed.

Il ripristino delle sessioni è subordinato al supporto dell’agente. L’operazione session/load del protocollo richiede la funzionalità loadSession dell’agente. Dove implementata, consente di caricare una sessione esistente; non dimostra che un altro fornitore possa ereditare lo stato privato dell’agente originale. Prima di promettere un passaggio senza attriti, occorre verificare esattamente come la combinazione scelta gestisce la cronologia. Specifica del caricamento delle sessioni.

Il supporto remoto va verificato nella singola implementazione. La pagina attuale sui trasporti definisce stdio e indica che un trasporto Streamable HTTP è in fase di specifica. Sono ammessi trasporti personalizzati. Non si può presumere che un’integrazione funzionante in locale operi automaticamente anche con l’endpoint di un agente remoto. Specifica dei trasporti ACP.

Le richieste di autorizzazione non sono una sandbox

ACP definisce un formato di messaggio per le decisioni sui permessi, ma non impone un confine di isolamento a livello di sistema operativo. La specifica chiarisce che l’agente viene eseguito con i permessi del proprio processo, che le richieste di autorizzazione hanno carattere consultivo e che spetta all’agente rispettare le decisioni. Separatamente, il client esegue i metodi relativi a filesystem e terminale richiesti tramite le funzionalità che mette a disposizione. Considerazioni sulla sicurezza di ACP.

Una richiesta può offrire opzioni per approvare o rifiutare una sola volta, oppure per ricordare la scelta. L’ambito e la persistenza delle decisioni memorizzate dipendono dall’agente. Prima di presumere che «sempre» riguardi solo il comando o la directory corrente, occorre leggere l’opzione proposta. Significato delle opzioni di autorizzazione.

Chi gestisce una piattaforma deve verificare il binario dell’agente, l’ambiente di esecuzione e la policy dei permessi insieme alla configurazione dell’editor. Una finestra di approvazione rende più visibili le operazioni, ma la sua sola presenza non dimostra che l’esecuzione sia confinata.

Quali promesse sono eccessive e a chi conviene muoversi?

Il vantaggio concreto è una minore dipendenza reciproca tra editor e agente. Il supporto ad ACP non dimostra che un agente scriva codice migliore, che la sua configurazione si trasferisca da un altro agente o che ogni abbinamento offra lo stesso flusso di lavoro. Sono risultati da valutare direttamente.

Chi cambia già agente può iniziare subito. Prova un agente supportato nell’editor che usi abitualmente. La verifica decisiva è capire se la revisione delle modifiche, la visibilità sui comandi e la gestione del contesto aiutano a completare un’attività rappresentativa del tuo lavoro.

I responsabili tecnici dovrebbero sperimentare prima di standardizzare. Mantieni invariati attività e criteri di accettazione nel confronto tra agenti. Documenta autenticazione, strumenti supportati, ripristino delle sessioni e gestione dei permessi. Scegli in base al lavoro prodotto e alla possibilità di controllarlo, non alle dimensioni di un registro.

Chi gestisce una piattaforma dovrebbe attendere se un ambiente necessario non è supportato. La limitazione di JetBrains su WSL, riportata nella documentazione, è un esempio concreto. Anche un flusso di lavoro remoto che dipende da un comportamento del trasporto ancora da accertare richiede di convalidare la combinazione prima dell’adozione.

Per chi si trova bene a lavorare nel terminale cambia poco. Non c’è motivo di cambiare interfaccia solo perché esiste un protocollo. Se resta da capire quale agente affronti meglio il tuo lavoro, il confronto tra Codex e Claude Code aiuta a impostare la scelta, da verificare poi sul tuo repository.

Domande frequenti

Che cos’è Agent Client Protocol?

Agent Client Protocol è l’interfaccia comune tra un agente di programmazione e un editor o un altro client. Permette alle implementazioni compatibili di scambiarsi prompt, aggiornamenti sull’avanzamento e azioni senza un’integrazione su misura per ogni abbinamento.

Qual è la differenza tra ACP e MCP?

ACP gestisce il collegamento tra editor e agente. MCP collega un’applicazione o un agente AI a strumenti e dati esterni. Una sessione ACP può fornire le configurazioni dei server MCP, quindi entrambi i protocolli possono partecipare allo stesso flusso di lavoro.

Che differenza c’è tra A2A e MCP?

Agent2Agent (A2A) standardizza la comunicazione tra agenti indipendenti. MCP collega le applicazioni AI a funzionalità e dati esterni. A2A riguarda la collaborazione tra agenti, mentre l’ACP trattato in questo articolo riguarda il collegamento con l’editor. Si veda la spiegazione del progetto A2A.

Claude Code supporta Agent Client Protocol?

La voce precisa nell’elenco è Claude Agent tramite l’adapter SDK di Zed. Va usata l’integrazione supportata e documentata dal proprio editor: quella voce non implica un supporto ACP nativo in ogni eseguibile di Claude Code. Zed descrive Claude Agent come un agente esterno con autenticazione propria.

Claude Code è ancora il migliore agente per programmare?

Il supporto ad ACP non può dare questa risposta. Confronta gli agenti sul tuo repository, mantenendo uguali attività, criteri di revisione e strumenti consentiti. Preferisci l’agente di cui riesci a convalidare le modifiche e il cui flusso di lavoro si adatta alle attività che svolgi abitualmente.

Chi ha sviluppato Agent Client Protocol?

Zed ha creato ACP e ha collaborato con Google per fare di Gemini CLI la prima implementazione di riferimento. JetBrains si è unita al progetto e nella documentazione attuale descrive ACP come un protocollo sviluppato apertamente da JetBrains e Zed.

Qual è la differenza tra Agent Client Protocol e Agent Communication Protocol?

Sono progetti diversi che condividono lo stesso acronimo. Agent Client Protocol collega editor e agenti di programmazione. Agent Communication Protocol di IBM riguardava la comunicazione tra agenti; IBM Research oggi lo indica come parte di A2A.

Come funziona ACP?

Per una sessione locale, l’editor avvia l’agente come sottoprocesso e comunica tramite JSON-RPC su stdio. Le due parti negoziano le funzionalità, completano l’eventuale autenticazione, aprono una sessione e si scambiano prompt, aggiornamenti e decisioni sui permessi.

Che cosa significa ACP nell’AI agentica?

Nell’integrazione con un editor, ACP indica di solito Agent Client Protocol. Quando si esamina un’architettura o si sceglie una libreria, è bene verificare il nome per esteso: lo stesso acronimo può indicare Agent Communication Protocol, che è un altro progetto.

Da dove partire nella prossima sessione di lavoro

Mantieni il tuo editor, scegli un agente ACP approvato e inizia con una piccola attività sul repository il cui risultato sia facile da rivedere. Annota l’agente e l’adapter usati, il metodo di autenticazione, gli strumenti disponibili e la gestione dei permessi. Estendi la sperimentazione solo quando l’intero ciclo di lavoro è chiaro, compreso ciò che accade quando rifiuti un’azione.

Per guide pratiche sui cambiamenti nel modo di sviluppare software, iscriviti alla newsletter.