Protocolo de Cliente de Agente (ACP)

 (agentclientprotocol.com)
15 puntos por GN⁺ 2025-09-01 | 1 comentarios | Compartir por WhatsApp
  • Agent Client Protocol (ACP) es un protocolo para estandarizar la comunicación entre editores de código y agentes de IA para programación
  • Antes, para que cada editor pudiera conectarse con un agente específico, se requería un trabajo de integración personalizada por separado, lo que provocaba limitaciones de compatibilidad y problemas de lock-in para desarrolladores
  • ACP, al igual que el Language Server Protocol (LSP), ofrece un método de comunicación estandarizado para que, una vez implementado, sea posible conectar libremente cualquier editor y agente compatibles
  • El editor ejecuta al agente como un subproceso y se comunica mediante JSON-RPC over stdio; además, admite elementos de UI como visualización de diff y salida basada en Markdown
  • Actualmente, Zed y Neovim (plugin CodeCompanion), entre otros, son compatibles con ACP, y del lado de los agentes, Gemini CLI es compatible; se espera que el soporte siga ampliándose

Introducción

  • Agent Client Protocol (ACP) es un protocolo abierto diseñado para estandarizar interacciones entre servidor y cliente, como desarrollo remoto, reenvío de puertos y ejecución de comandos
  • Problemas existentes: aunque los agentes de IA para programación y los editores están estrechamente vinculados, la interoperabilidad no está garantizada de forma nativa
    • Cada editor debe construir una integración personalizada para cada agente que quiera soportar
    • Los agentes deben implementar APIs específicas de cada editor para poder llegar a los usuarios
    • Esto genera sobrecarga de integración, compatibilidad limitada y problemas de dependencia del desarrollador
  • La solución de ACP: ACP proporciona un protocolo estandarizado entre agentes y editores
    • Un agente que implemente ACP funciona en cualquier editor compatible
    • Un editor compatible con ACP puede acceder a todo el ecosistema de agentes compatibles con ACP
    • Permite la innovación independiente y que los desarrolladores elijan las herramientas más adecuadas para su flujo de trabajo

Resumen de ACP

  • Cómo funciona: los usuarios trabajan principalmente en un editor de código y llaman al agente para tareas específicas
    • El agente se ejecuta como subproceso del editor
    • La comunicación se realiza usando JSON-RPC a través de stdio
  • Formato de datos: reutiliza el formato JSON de MCP e incluye tipos personalizados para elementos de UX de programación con agentes, como la visualización de diff
  • Formato de texto: usa Markdown como formato predeterminado para mejorar la legibilidad para el usuario
    • Permite formato enriquecido sin necesidad de renderizar HTML
  • El protocolo sigue en desarrollo, pero ya tiene un nivel de madurez suficiente para construir experiencias de usuario interesantes

Estado actual del soporte

Conclusión

  • ACP, tomando como referencia el caso de éxito de LSP, mejora de forma importante la interoperabilidad entre agentes de IA para programación y editores
  • Los desarrolladores pueden elegir libremente la mejor combinación de herramientas sin quedar atados a un agente o editor específico
  • La expansión del protocolo aumenta la escalabilidad del ecosistema y puede mejorar la eficiencia y flexibilidad de los flujos de trabajo de los desarrolladores

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-09-01
Comentarios de Hacker News

  • Le pidió a Claude que creara un protocolo de comunicación entre agentes de IA y un IDE/editor, y se puso a pensar en pedirle también que desarrollara librerías para Node, Python y Rust, e incluso que construyera un sitio web con landing page.

    • La verdad, me tienta probar si Gemini puede usar un plugin de Sublime Text que implemente este protocolo. Últimamente casi todos los usuarios se están yendo hacia VSCode, así que los nuevos tools tienden a soportar solo esa plataforma. Quiero evitar que me obliguen a migrar por dejar de dar soporte a Sublime; Sublime es de verdad un gran editor, y además no está respaldado por una empresa gigante.

    • Y además, hasta podrían hacer que fuera un agente que solo soporte Gemini para ocultar sus huellas.

    • Qué chistoso, es un deseo demasiado egocéntrico.

  • Ojalá que este proyecto salga muy bien. Zed está volviendo a la esencia de la colaboración, y siento que esta corriente también podría mover cosas dentro de la categoría de IDEs agentic. Si eso pasa, Zed no tendría que gastar tiempo compitiendo de forma directa y además se diferenciaría. Me da curiosidad cuánto se adoptará entre los agentes CLI (también está bueno ver que Gemini CLI ya se integró). La competencia feroz entre los LLM y el mercado de asistentes de programación siempre es bienvenida; creo que estos cambios van a seguir bajando el costo de cambiarse entre herramientas.

    • Yo también estoy a punto de pasarme a Zed. Tiene casi todas las funciones que he querido en un editor durante años, además de varias funciones geniales que ni siquiera imaginaba. En algún momento me decepcioné tanto del estado de las cosas que hasta intenté hacer un prototipo de editor por mi cuenta, pero construir un buen editor requiere muchísimo esfuerzo. Zed sí ha hecho ese trabajo. Me gusta ver que están intentando colaborar de forma abierta.

    • Lo digo en serio: ojalá este cambio sirva para que desaparezcan esos forks mediocres de VS Code. Zed también merece el reconocimiento que le corresponde. Siento que los editores con IA de verdad le están quitando todo el oxígeno a la industria.

  • Estoy creando una herramienta para que Claude Code pueda usar ACP (porque uso mucho CC y Zed), y hasta ahora me ha ido bastante bien con Claude Code SDK y la librería ACP Client. Todavía hay algunas cosas por pulir, pero planeo ajustarlo un poco más mañana y luego abrirlo.

  • Ya existe un ACP llamado agentcommunicationprotocol.dev, así que el nombre puede prestarse a confusión. Aunque sí hay diferencias entre ambos proyectos, es algo que me preocupa.

    • En marzo de 2025 IBM anunció Agent Communication Protocol (ACP), pero ahora decidió abandonar el nombre ACP y fusionar ese trabajo con el protocolo Agent2Agent (A2A) de Google. Esta decisión llega mientras todos los equipos de desarrollo de ACP entran en proceso de disolución y la industria se inclina por respaldar A2A bajo el liderazgo de la Linux Foundation. Con eso se busca evitar la fragmentación de los estándares de agentes de IA y unificarlos en un protocolo abierto impulsado por la comunidad más detalles aquí.

  • Lo que más me intriga es por qué un servidor LSP o una extensión del protocolo LSP no puede cubrir lo que necesita un LLM.

    • Porque LSP nació antes del boom de la IA. La IA está atravesando ahora mismo una etapa de explosión caótica de herramientas, como pasó antes con las librerías de JavaScript. Se están ignorando por completo la experiencia y el conocimiento acumulados, y se están resolviendo los problemas equivocados con las herramientas equivocadas. Al final, este enfoque solo va a acumular más complejidad e ineficiencia, igual que ocurrió con las librerías de JS. Si resuelves mal el problema, aparecen nuevos problemas, y terminas agregando todavía más soluciones equivocadas en un círculo vicioso.

  • A mí me resulta cómodo tratar a la IA como si fuera un desarrollador humano de verdad. Por ejemplo, le pido que implemente una función, corrija un bug o haga un refactor, y luego reviso el commit resultante. Si no me gusta el commit, hago git reset --hard, mejoro el prompt y se lo vuelvo a pedir a la IA. A este método lo llamo "prompt coding". No necesito una interacción directa entre mi entorno de programación y la IA; trabaja como un desarrollador humano, sin andar metiéndose en mi editor explicación relacionada.

    • Últimamente dicen que escribir prompts es mejor, pero lo dudo un poco. La IA sí ayuda en algunas tareas muy específicas, pero todavía suelta muchas tonterías. Sobre todo cuando se inventa cosas que no existen, como APIs; eso sigue siendo difícil de tolerar.

    • Yo no dejo que la IA haga commits. Casi siempre tengo que corregir varias partes del resultado. Me da flojera perder tiempo repitiendo prompts, así que si no me da una buena respuesta desde el principio, prefiero arreglarlo yo directamente. Cuando sí entiende lo que quiero desde el inicio y entrega el código correcto, ahí sí me genera más confianza.

  • Ojalá esta idea se expanda más. Una duda que tengo es la diferencia entre la búsqueda de archivos y los archivos sin guardar. En la práctica, los agentes suelen usar cosas como ripgrep para buscar en el sistema de archivos, pero el problema es que, si el protocolo permite leer y escribir también en archivos no guardados, eso puede afectar la precisión. ripgrep no puede buscar en archivos no guardados.

  • De verdad espero que Anthropic adopte este protocolo en Claude Code. Como mínimo, esperaría un nivel de integración comparable al que ofrece VSCode, y al menos sería bueno que pudiera acceder a la información de diagnósticos del editor.

  • MCP también empezó al principio con JSON-RPC sobre stdio. Con entornos como GitHub Codespaces, devcontainers y "background agents", me pregunto si veremos una evolución hacia algo como JSON over SSE. Mi entorno de desarrollo actual usa Claude Code en local, mientras que la app corre dentro de contenedores. El agente puede ejecutar por su cuenta docker compose exec backend. Los obstáculos para adoptar un flujo de trabajo con git worktree son compartir el motor de base de datos (por falta de recursos locales) y el tiempo de las migraciones iniciales. También es interesante imaginar un escenario donde esa carga se descargue a la nube.

  • Ojalá protocolos como este se vuelvan comunes para no tener que quedarme atado siempre a un solo IDE existente.