El equipo del ACP exploró inicialmente la adaptación del Model Context Protocol (MCP) porque ofrece una base sólida para las interacciones modelo-contexto. Sin embargo, rápidamente se encontraron con limitaciones arquitectónicas que lo hacían inadecuado para una verdadera comunicación de agente a agente.
Por qué el MCP se queda corto para los sistemas multiagente:
Streaming: el MCP admite el streaming básico, probablemente de mensajes completos, pero no el estilo "delta" más detallado, en el que las actualizaciones se envían tan pronto como se producen. Los flujos delta, como los tokens y las actualizaciones de trayectoria, son flujos compuestos por actualizaciones incrementales en lugar de cargas útiles de datos completas. Esta limitación se debe al hecho de que cuando se creó el MCP, no estaba pensado para interacciones de tipo agente.
Uso compartido de memoria: el MCP no admite la ejecución de varios agentes en servidores mientras se mantiene la memoria compartida. El ACP tampoco es totalmente compatible con esta función, pero es un área activa de desarrollo.
Estructura del mensaje: el MCP acepta cualquier esquema JSON, pero no define la estructura del cuerpo del mensaje. Esta flexibilidad dificulta la interoperabilidad, especialmente para los agentes de construcción que deben interpretar diversos formatos de mensaje.
Complejidad del protocolo: el MCP utiliza JSON-RPC y requiere SDK y tiempos de ejecución específicos. Mientras que el diseño basado en REST del ACP con soporte asincrónico/sincrónico incorporado es más ligero y fácil de integrar.
Piense en el MCP como si fuera dar a una persona mejores herramientas, como una calculadora o un libro de referencia, para mejorar su rendimiento. Por el contrario, el ACP consiste en permitir que las personas formen equipos, en los cuales cada persona o agente contribuye con sus capacidades de forma colaborativa dentro de la aplicación de IA.
El ACP y el MCP pueden complementarse: