OpenIDE adiciona ACP: como o protocolo de JetBrains e Zed muda a forma como agentes de AI trabalham em IDEs

ACP se torna uma nova camada de compatibilidade entre IDE e agentes de IA: em vez de uma integração separada para cada ferramenta, o editor e o agente concordam em um protocolo comum. OpenIDE já implementou suporte básico para ACP e está se preparando para testes beta.

O que é ACP

No ano passado, o mercado de ferramentas de IA para desenvolvimento se tornou uma mistura de ecossistemas separados. Claude Code, Codex, Cursor, Windsurf, Kilo Code, Qwen Code e outros agentes conseguem escrever, corrigir e refatorar código, mas quase cada um vem com seu próprio esquema de conexão ao editor. Como resultado, o desenvolvedor escolhe não apenas o agente mais forte, mas também o editor onde uma integração para ele já foi escrita.

ACP tenta quebrar essa dependência. Em seu conceito, ACP é muito semelhante ao LSP, que uma vez libertou os editores da necessidade de implementar separadamente o suporte a cada linguagem. Se naquela época um protocolo unificado conectava o editor ao servidor de linguagem, agora uma camada de compatibilidade assim está surgindo entre a IDE e o agente de IA.

O protocolo descreve como as partes trocam mensagens, contexto, solicitações de ação e status de execução. Na prática, isso significa que um agente pode ser conectado inteiramente — junto com sua lógica, ferramentas e forma de funcionamento, em vez de simplesmente enviar solicitações para o modelo selecionado via API.

Por que é difícil sem padrões

O principal problema do mercado atual é que muitas integrações permanecem personalizadas. Um editor consegue trabalhar com um agente, outro com dois, um terceiro requer um plugin separado ou script semi-oficial. Enquanto isso parece tolerável se você usar uma ferramenta.

Mas assim que quiser comparar vários agentes, você rapidamente encontra incompatibilidades, configurações extras e aprisionamento do fornecedor. Para equipes, isso é ainda mais doloroso: mudar um editor ou agente começa a exigir migração de processos extras. ACP é necessário precisamente para dividir os papéis.

A IDE é responsável pelo ambiente de desenvolvimento: navegação de código, destaque, diffs, refatoração, trabalho com arquivos e terminal. O agente é responsável pela lógica autônoma: como construir um plano, quais ferramentas chamar, como fazer alterações e quando pedir confirmação. Na descrição oficial do protocolo, estão previstos tanto estágios básicos como inicialização e transmissão de prompt, quanto coisas mais práticas — leitura e escrita de arquivos, criação de terminal, atualizações de tarefas e solicitações de permissões de ação.

Outro ponto importante: conectar um modelo via API não é o mesmo que conectar um agente. Quando você simplesmente fornece uma chave para um LLM, o editor em si permanece o orquestrador e apenas envia solicitações ao provedor. ACP permite incorporar um agente pronto na IDE como uma entidade separada.

Para o desenvolvedor, isso é mais conveniente: você pode usar seu editor favorito sem perder os recursos de uma ferramenta de IA específica. Em outras palavras, o padrão traz não apenas um modelo para a IDE, mas seu loop de trabalho completo.

O que aparecerá em OpenIDE

A Haulmont escreve que a implementação básica de ACP em OpenIDE já está pronta, e o próximo estágio é testes beta. Para os usuários, isso não é um abstrato "vamos apoiar eventualmente", mas um passo bastante prático em direção a uma IDE onde um agente é conectado como um componente padrão. Se o suporte chegar a um lançamento estável sem limitações sérias, OpenIDE será capaz de adotar novos agentes compatíveis mais rapidamente sem integrações personalizadas separadas para cada um.

• Suporte básico de ACP já está implementado
• O recurso fará parte do OpenIDE Pro
• Durante o período beta, compatibilidade é prometida na versão base do OpenIDE
• Os interessados podem solicitar acesso antecipado e configuração com antecedência

A lógica é clara: em vez de apoiar manualmente um número crescente de plugins de IA separados, a IDE recebe uma única interface para agentes externos. Ao mesmo tempo, OpenIDE em si continua confiando em coisas familiares aos desenvolvedores — o editor, navegação, refatoração, terminal e o ecossistema de plugins. O artigo enfatiza especificamente que o ambiente está atualmente projetado para Java, Spring, Python, Go, JavaScript e TypeScript, e também pode funcionar com Docker e extensões de um marketplace compatível. ACP neste esquema parece não como um complemento moderno, mas como a próxima camada de infraestrutura.

O que isso significa

Se ACP se consolidar da forma que LSP uma vez fez, o mercado de codificação de IA se tornará notavelmente mais aberto. Os desenvolvedores poderão escolher o melhor agente separadamente de sua IDE favorita, e criadores de agentes gastarão menos esforço em dúzias de integrações individuais. Para OpenIDE, essa é uma chance de conectar ferramentas populares mais rapidamente, e para todo o ecossistema, um passo de um zoo caótico de plugins de IA para um padrão mais coerente. São geralmente esses protocolos que determinam quais abordagens se tornam mainstream e quais permanecem nicho.