El equipo de ACP inicialmente exploró la adaptación del Protocolo de contexto de modelo (MCP) porque ofrece una base estable para las interacciones modelo-contexto. Sin embargo, rápidamente se encontraron limitaciones arquitectónicas que lo hicieron inadecuado para una verdadera comunicación de agente a agente.
Por qué MCP se queda corto para los sistemas multiagente:
Transmisión: MCP admite transmisión básica, probablemente de mensajes completos, pero no el estilo "delta" más detallado, en el que las actualizaciones se envían tan pronto como ocurren. 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ó MCP, no estaba destinado a interacciones de estilo agente.
Uso compartido de memoria: MCP no admite la ejecución de varios agentes en servidores mientras se mantiene la memoria compartida. ACP tampoco es totalmente compatible con esta función, pero es un área activa de desarrollo.
Estructura del mensaje: 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 mensajes.
Complejidad del protocolo: MCP utiliza JSON-RPC y requiere SDK y tiempos de ejecución específicos. Por su parte, el diseño basado en REST de ACP con soporte asincrónico/sincrónico incorporado es más ligero y fácil de integrar.
Piense en MCP como dar a una persona mejores herramientas, como una calculadora o un libro de referencia, para mejorar su rendimiento. Por el contrario, ACP consiste en permitir que las personas formen equipos, en los que cada persona, o agente, contribuye con sus capacidades de forma colaborativa dentro de la aplicación de IA.
ACP y MCP pueden complementarse entre sí: