- Agent Client Protocol (ACP) é um protocolo para padronizar a comunicação entre editores de código e agentes de codificação com IA
- Antes, para que cada editor se conectasse a um agente específico, era necessário um trabalho separado de integração personalizada, o que gerava limitações de compatibilidade e problemas de lock-in de desenvolvedor
- Assim como o Language Server Protocol (LSP), o ACP fornece uma forma de comunicação padronizada, permitindo que, após uma única implementação, qualquer editor e agente compatíveis possam se conectar livremente
- O editor executa o agente como um subprocesso, comunica-se via JSON-RPC over stdio, e a interface suporta elementos como exibição de diff e saída baseada em Markdown
- Atualmente, Zed e neovim (plugin CodeCompanion), entre outros, oferecem suporte ao ACP, e no lado dos agentes o Gemini CLI é compatível, com a expectativa de ampliação do suporte no futuro
Introdução
- Agent Client Protocol (ACP) é um protocolo aberto projetado para padronizar interações entre servidor e cliente, como desenvolvimento remoto, encaminhamento de portas e execução de comandos
- Problema existente: agentes de codificação com IA e editores estão fortemente conectados, mas a interoperabilidade não é garantida por padrão
- Cada editor precisa criar uma integração personalizada para cada agente que deseja suportar
- Os agentes precisam implementar APIs específicas de cada editor para alcançar os usuários
- Isso gera sobrecarga de integração, compatibilidade limitada e problemas de dependência do desenvolvedor
- Solução do ACP: o ACP fornece um protocolo padronizado entre agentes e editores
- Um agente que implementa ACP funciona em todos os editores compatíveis
- Um editor que oferece suporte ao ACP pode acessar todo o ecossistema de agentes compatíveis com ACP
- Isso viabiliza inovação independente e permite que desenvolvedores escolham as ferramentas mais adequadas ao seu fluxo de trabalho
Visão geral do ACP
- Como funciona: os usuários trabalham principalmente no editor de código e invocam o agente para tarefas específicas
- O agente é executado como subprocesso do editor
- A comunicação usa JSON-RPC via stdio
- Formato de dados: reutiliza o formato JSON do MCP e inclui tipos personalizados para elementos de UX de codificação com agentes, como exibição de diff
- Formato de texto: usa Markdown como padrão para melhorar a legibilidade para o usuário
- Permite formatação rica sem renderização de HTML
- O protocolo ainda está em desenvolvimento, mas já tem maturidade suficiente para construir experiências de usuário interessantes
Status atual de suporte
- Editores
- Agentes
- Gemini: suporte ao ACP por meio do Gemini CLI
- Suporte a mais agentes previsto
Conclusão
- Inspirado no sucesso do LSP, o ACP melhora de forma significativa a interoperabilidade entre agentes de codificação com IA e editores
- Os desenvolvedores podem escolher livremente a combinação ideal de ferramentas, sem ficarem presos a um agente ou editor específico
- A expansão do protocolo pode aumentar a escalabilidade do ecossistema e ampliar a eficiência e a flexibilidade do fluxo de trabalho dos desenvolvedores
1 comentários
Comentários no Hacker News
Pedi ao Claude para criar um protocolo de comunicação entre agentes de IA e IDEs/editores, desenvolver bibliotecas para Node, Python e Rust, e até montar um site com landing page
Sinceramente, fico tentado a testar se o Gemini consegue usar um plugin do Sublime Text que implemente esse protocolo; ultimamente, a maioria dos usuários parece estar migrando para o VSCode, então as ferramentas novas tendem a oferecer suporte só para lá. Quero evitar ser forçado a migrar porque o Sublime deixou de ser suportado; o Sublime é um editor realmente bom e nem conta com o apoio de uma grande empresa
E também daria para fazer um agente que só suporte Gemini para esconder os rastros
Engraçado, é um desejo muito egocêntrico
Espero muito que esse projeto dê certo. O Zed está voltando ao essencial da colaboração, e acho que isso pode mudar também a categoria dos IDEs agentic. Assim, o Zed não precisa gastar tempo competindo diretamente e ainda ganha diferenciação. Fico curioso para ver o quanto isso será adotado entre os agentes de CLI (já é bom ver que o Gemini CLI foi integrado). A concorrência acirrada no mercado de LLMs e assistentes de programação é sempre bem-vinda, e acho que mudanças assim reduzem continuamente o custo de migração entre ferramentas
Eu também quase já migrei para o Zed; ele tem quase tudo que eu queria num editor há anos, além de vários recursos incríveis que eu nem tinha imaginado. Já cheguei a prototipar meu próprio editor por frustração com o estado atual das coisas, mas fazer um bom editor exige um esforço enorme. O Zed fez esse esforço. Gosto de ver esse movimento deles de colaborar de forma aberta
Falo sério: espero que essa mudança ajude a acabar com esses forks vagabundos do VS Code. O Zed também merece o reconhecimento devido. Parece mesmo que os editores com IA sugaram todo o oxigênio da indústria
Estou criando uma ferramenta para permitir que o Claude Code use ACP (porque uso bastante CC e Zed), e até agora tenho tido bastante sucesso com o Claude Code SDK e a biblioteca ACP Client. Ainda falta polir algumas partes, mas pretendo dar mais uma refinada amanhã e abrir o código
Já existe um ACP chamado agentcommunicationprotocol.dev, então o nome pode causar confusão. Existem diferenças entre os dois projetos, mas isso ainda incomoda
O que mais me intriga é por que um servidor LSP ou uma extensão do protocolo LSP não consegue cobrir o que os LLMs precisam
Eu me sinto confortável tratando a IA como um desenvolvedor humano de verdade. Por exemplo, peço para ela implementar um recurso, corrigir um bug ou refatorar algo, depois leio o commit resultante. Se eu não gostar do commit, faço
git reset --hard, melhoro o prompt e peço de novo para a IA. Chamo esse método de "prompt coding". Não preciso de interação direta entre meu ambiente de programação e a IA; ela trabalha sem mexer no meu editor, como um desenvolvedor humano explicação relacionadaHoje em dia dizem que escrever prompts está melhor, mas sou um pouco cético quanto a isso. A IA ajuda em algumas tarefas bem específicas, mas ainda fala muita bobagem; especialmente quando inventa coisas, como APIs que não existem, isso continua difícil de tolerar
Eu não chego a deixar a IA fazer commits. Quase sempre preciso editar várias partes do resultado dela, e como acho perda de tempo ficar repetindo reprompt, se ela não acerta o que quero logo de início eu simplesmente corrijo por conta própria. Quando ela entende desde o começo o que eu quero e entrega o código certo, aí minha confiança nela aumenta bastante
Espero que essa ideia se espalhe mais. Uma coisa que me deixa curioso é a diferença entre buscar arquivos e lidar com arquivos não salvos. Na prática, os agentes costumam usar coisas como
ripgreppara pesquisar no sistema de arquivos, mas o problema é que, se o protocolo também permitir ler e escrever arquivos não salvos, isso pode afetar a precisão. Oripgrepnão consegue pesquisar em arquivos não salvosEu realmente queria que a Anthropic adotasse esse protocolo no Claude Code; no mínimo, espero um nível de integração equivalente ao oferecido no VSCode. E seria ótimo se ao menos houvesse acesso às informações de diagnóstico do editor
O MCP também começou em cima de stdio com JSON-RPC. Com o surgimento de ambientes como GitHub Codespaces, devcontainers e "background agents", fico curioso se pode haver uma evolução para algo como JSON over SSE. Hoje meu ambiente de desenvolvimento usa Claude Code localmente, enquanto o app roda em contêineres. O agente consegue executar
docker compose exec backendde forma autônoma. Os obstáculos para adotar um fluxo com git worktree são o compartilhamento do mecanismo de banco de dados (por falta de recursos locais) e o tempo inicial de migração. Transferir esse peso para a nuvem também parece um cenário interessanteEspero que protocolos assim se espalhem para que eu não precise ficar preso para sempre a um único IDE existente