Creando una sala de redacción de un agente LLM con protocolo A2A y MCP en Elasticsearch: Parte I

Introducción

Los sistemas actuales respaldados por LLM están evolucionando rápidamente más allá de aplicaciones de modelo único hacia redes complejas donde agentes especializados trabajan juntos para realizar tareas que la informática moderna nunca antes consideró posibles. A medida que estos sistemas se vuelven más complejos, la infraestructura que permite la comunicación de agentes y el acceso a herramientas se convierte en el principal foco de desarrollo. Surgieron dos enfoques complementarios para abordar estas necesidades: los protocolos Agent2Agent (A2A) para la coordinación multiagente y el Protocolo de Contexto del Modelo (MCP) para el acceso estandarizado a herramientas y recursos.

Entender cuándo usar cada uno en armonía con y sin el otro puede afectar significativamente la escalabilidad, mantenibilidad y efectividad de tus aplicaciones. Este artículo explora los conceptos e implementaciones de A2A dentro del ejemplo práctico de una redacción digital, donde agentes especializados en LLM colaboran para investigar, escribir, editar y publicar artículos de noticias.

Aquí se puede encontrar un repositorio adjunto, y examinaremos ejemplos concretos de A2A en acción cerca del final del artículo en la Sección 5.

Prerrequisitos

El repositorio consiste en implementaciones basadas en Python de los agentes A2A. Flask proporciona un servidor API, así como un servicio de mensajería personalizado en Python llamado Event Hub, que enruta mensajes para registro y actualizaciones de la interfaz. Por último, se dispone de una interfaz React para el uso independiente de las funciones de la redacción. Todo está contenido dentro de una imagen Docker para facilitar su implementación. Si quieres ejecutar los servicios directamente con tu máquina, querrás cerciorarte de tener estas tecnologías instaladas:

Lenguajes y tiempos de ejecución

• Python 13.12 - Lenguaje central de backend
• Node.js 18+ - Interfaz de React opcional

Frameworks y SDKS básicos:

• A2A SDK 0.3.8 - Coordinación y comunicación de agentes
• SDK Anthropic - Integración de Claude para generación de IA
• Uvicorn - servidor ASGI para ejecutar agentes
• FastMCP 2.12.5+ - Implementación del servidor MCP
• React 18.2 - Marco de interfaz de usuario frontend

Datos y búsqueda

• Elasticsearch 9.1.1+ - Indexación y búsqueda de artículos

Despliegue en Docker (opcional, pero recomendado)

• Docker 28.5.1+

Sección 1: ¿Qué es Agent2Agent (A2A)?

Definición y conceptos fundamentales

Especificaciones oficiales: https://a2a-protocol.org/latest/specification/

Orígenes y evolución

El concepto de comunicación Agent2Agent, o sistemas multiagente, tiene raíces en sistemas distribuidos, microservicios e investigación multiagente que se remontan a décadas atrás. Los primeros trabajos en inteligencia artificial distribuida sentaron las bases para agentes capaces de negociar, coordinar y colaborar. Estos primeros sistemas estaban dedicados a simulaciones sociales a gran escala, investigación académica y gestión de redes eléctricas.

Con la llegada de la disponibilidad de LLMs y la reducción del costo operativo, los sistemas multiagente estuvieron disponibles para los mercados "prosumers", con el respaldo de Google y la comunidad de investigación en IA en general. Ahora conocido como sistemas Agent2Agent, la incorporación del protocolo A2A evolucionó hasta convertir en un estándar moderno diseñado específicamente para la era de múltiples grandes modelos de lenguaje coordinando esfuerzos y tareas.

El protocolo A2A garantiza una comunicación y coordinación fluidas entre agentes aplicando estándares y principios consistentes a los puntos de interacción donde los LLMs se conectan y comunican. Esta estandarización permite que agentes de diferentes desarrolladores —empleando distintos modelos subyacentes— trabajen juntos de forma eficaz.

Los protocolos de comunicación no son nuevos y tienen raíces ampliamente arraigadas en casi todas las transacciones digitales realizadas en Internet. Si escribiste https://www.elastic.co/search-labs en un navegador para acceder a este artículo, las probabilidades son altas de que se ejecutaron protocolos TCP/IP, transporte HTTP y consulta DNS, cerciorando una experiencia de navegación coherente para nosotros.

Características clave

Los sistemas A2A se basan en varios principios fundamentales para garantizar una comunicación fluida. Construir sobre estos principios garantiza que diferentes agentes, basados en distintos LLMs, frameworks y lenguajes de programación, interactúen de forma fluida.

Estos son los cuatro principios principales:

• Paso de mensajes: Los agentes se comunican mediante mensajes estructurados con propiedades y formatos bien definidos
• Coordinación: Los agentes orquestan flujos de trabajo complejos delegando tareas entre sí y gestionando dependencias sin bloquear a otros agentes
• Especialización: Cada agente se centra en un dominio o capacidad específica, convertir en un experto en su área y ofreciendo la realización de tareas basar en ese conjunto de habilidades
• Estado distribuido: El estado y el conocimiento se distribuyen entre agentes en lugar de centralizar, con los agentes con la capacidad de actualizar mutuamente sobre el progreso con el estado de la tarea y retornos parciales (artefactos)

La redacción: Un ejemplo recurrente

Imagina una redacción digital impulsada por agentes de IA, cada uno especializado en un aspecto diferente del periodismo:

• Jefe de Noticias (coordinador/cliente): Asigna historias y monitorear el flujo de trabajo
• Agente reportero: Escribe artículos basados en investigaciones y entrevistas
• Agente Investigador: recopila datos, estadísticas e información de fondo
• Archive Agent: Busca en artículos históricos e identifica tendencias usando Elasticsearch
• Editor Agent: Reseña artículos para calidad, estilo y optimización SEO
• Agente editorial: Publica artículos aprobados en la plataforma de blogs vía CI/CD

Estos agentes no actúan de forma aislada; cuando el Jefe de Noticias asigna una noticia sobre la adopción de energías renovables, el Reportero necesita que el Investigador recopile estadísticas, que el Editor revise el borrador y que el Editor publique el texto final. Esta coordinación se realiza a través de protocolos A2A.

Sección 2: comprensión de la arquitectura A2A

Roles de Agente de Cliente y Agente Remoto

En la arquitectura A2A, los agentes asumen dos roles principales. El Agente Cliente es responsable de formular y comunicar tareas a otros agentes del sistema. Identifica a los agentes remotos y sus capacidades, empleando esta información para tomar decisiones informadas sobre la delegación de tareas. El agente cliente coordina el flujo de trabajo general, cerciorando que las tareas se distribuyan correctamente y que el sistema avance hacia sus objetivos.

El Agente Remoto, en cambio, actúa en tareas delegadas por los clientes. Proporciona información o toma acciones específicas en respuesta a solicitudes, pero no inicia acciones de forma independiente. Los agentes remotos también pueden comunicar con otros agentes remotos según sea necesario para cumplir con sus responsabilidades asignadas, creando una red colaborativa de capacidades especializadas.

En nuestra redacción, el Jefe de Noticias actúa como agente cliente, mientras que el Reportero, el Investigador, el Editor y el Editor son agentes remotos que responden a las solicitudes y coordinan entre sí.

Capacidades básicas de A2A

Los protocolos A2A definen varias capacidades que permiten la colaboración multiagente:

1. Descubrimiento

Los servidores A2A deben anunciar sus capacidades para que los clientes sepan cuándo y cómo emplearlas para tareas específicas. Esto se logra mediante Tarjetas de Agente—documentos JSON que describen las habilidades, entradas y salidas de un agente. Las Tarjetas de Agente están disponibles en puntos finales consistentes y conocidos (como el recomendado /.well-known/agent-card.json endpoint), permitiendo a los clientes descubrir y consultar las capacidades de un agente antes de iniciar la colaboración.

A continuación hay un ejemplo de Tarjeta de Agente para el Agente de Archivo personalizado de Elastic, "Archie Archivist". Ten en cuenta que proveedores de software como Elastic alojan sus agentes A2A y proporcionan una URL para el acceso:

Esta Tarjeta de Agente revela varios aspectos importantes del Agente de Archivo de Elastic. El agente se identifica como "Archie Archivist" y deja claro su propósito: ayudar a encontrar documentos históricos de noticias en un índice de Elasticsearch. La tarjeta especifica el proveedor (Elastic) y la versión del protocolo (0.3.0), cerciorando la compatibilidad con otros agentes compatibles con A2A. Lo más importante es que el skills array enumera las capacidades específicas que ofrece este agente, incluyendo una poderosa funcionalidad de búsqueda y una exploración inteligente de índices. Cada habilidad define qué modos de entrada y salida soporta, permitiendo a los clientes entender exactamente cómo comunicar con este agente. Este agente deriva del servicio Agent Builder de Elastic, que ofrece un conjunto de herramientas nativas respaldadas por LLM y endpoints API para mantener una conversación con tu almacén de datos, no solo para recuperarlo de él. El acceso a los agentes A2A en Elasticsearch puede encontrar aquí.

2. Negociación

Clientes y agentes deben acordar los métodos de comunicación —ya sea que las interacciones se realicen mediante texto, formularios, iframes o incluso audio/video— para garantizar una interacción adecuada del usuario y el intercambio de datos. Esta negociación ocurre al inicio de la colaboración entre agentes y establece los protocolos que gobernarán su interacción a lo largo del flujo de trabajo. Por ejemplo, un agente de atención al cliente basado en voz podría negociar para comunicar mediante flujos de audio, mientras que un agente de análisis de datos podría preferir JSON estructurado. El proceso de negociación garantiza que ambas partes puedan intercambiar información de forma eficaz en un formato que se adapte a sus capacidades y a los requisitos de la tarea en cuestión.

Las capacidades listadas en el fragmento JSON anterior tienen todas esquemas de entrada y salida; Estos establecen una expectativa de cómo interactuar con este agente por parte de otros agentes.

3. Gestión de tareas y estado

Los clientes y agentes necesitan mecanismos para comunicar el estado de la tarea, cambios y dependencias a lo largo de la ejecución. Esto incluye gestionar todo el ciclo de vida de una tarea, desde su creación y asignación hasta las actualizaciones de progreso y los cambios de estado. Los estados típicos incluyen estados pendientes, en curso, completados o fallidos. El sistema también debe hacer un seguimiento de las dependencias entre tareas para cerciorar que el trabajo previo se complete antes de que comiencen las tareas dependientes. El manejo de errores y la lógica de reintentos también son componentes esenciales, que permiten al sistema recuperar de forma elegante tras fallos y seguir avanzando hacia el objetivo principal.

Ejemplo de mensaje de tarea:

Este mensaje de tarea de ejemplo demuestra varios aspectos clave de la comunicación A2A.

• La estructura del mensaje incluye metadatos como un identificador único del mensaje, el tipo de mensaje enviado, la identificación del remitente y receptor, y una marca de tiempo para el seguimiento y la depuración.
• La carga útil contiene la información real de la tarea, especificando qué capacidad se está invocando en el agente remoto y proporcionando los parámetros necesarios para ejecutar dicha capacidad.
• La sección de contexto proporciona información adicional que ayuda al agente receptor a comprender el flujo de trabajo más amplio, incluyendo plazos y niveles de prioridad que informan sobre cómo debe asignar sus recursos y programar su trabajo.

4. Colaboración

Clientes y agentes deben apoyar una interacción dinámica pero estructurada, permitiendo a los agentes aplicar aclaraciones, información o subacciones al cliente, otros agentes o usuarios. Esto crea un entorno colaborativo donde los agentes pueden hacer preguntas de seguimiento cuando las instrucciones iniciales son ambiguas, aplicar contexto adicional para tomar mejores decisiones, delegar subtareas a otros agentes con experiencia más adecuada y proporcionar resultados intermedios para recibir retroalimentación antes de proceder con la tarea completa. Esta comunicación multidireccional cerciora que los agentes no actúen de forma aislada, sino que participen en un diálogo continuo que conduce a mejores resultados.

Comunicación distribuida entre pares

A2A permite la comunicación distribuida donde los agentes pueden ser alojados por diferentes organizaciones, con algunos agentes mantenidos internamente mientras que otros son proporcionados por servicios externos. Estos agentes pueden funcionar en diferentes infraestructuras, potencialmente abarcando múltiples proveedores de nube o centros de datos locales. Pueden usar diferentes LLMs subyacentes, con algunos agentes impulsados por modelos GPT, otros por Claude y otros más por alternativas de código abierto. Los agentes incluso podrían operar en diferentes regiones geográficas para cumplir con los requisitos de soberanía de datos o reducir la latencia. A pesar de esta diversidad, todos los agentes acuerdan un protocolo de comunicación común para el intercambio de información, garantizando la interoperabilidad independientemente de los detalles de la implementación. Esta arquitectura distribuida ofrece flexibilidad en la construcción y despliegue de los sistemas, permitiendo a las organizaciones combinar los mejores agentes e infraestructuras según sus necesidades específicas.

Esta es la arquitectura final de la aplicación de redacción:

Sección 3: Protocolo de Contexto de Modelo (MCP)

Definición y propósito

El Protocolo de Contexto del Modelo (MCP) es un protocolo estandarizado desarrollado por Anthropic para mejorar y potenciar un LLM individual con herramientas, recursos y prompts definidos por el usuario, entre otras adiciones suplementarias a la base de código. MCP proporciona una interfaz universal entre los modelos de lenguaje y los recursos externos que necesitan para completar tareas de manera eficaz. Este artículo describe el estado actual de MCP con ejemplos de casos de uso, tendencias emergentes y la propia implementación de Elastic.

Conceptos centrales de MCP

MCP opera sobre una arquitectura cliente-servidor con tres componentes principales:

• Clientes: aplicaciones (como Claude Desktop o aplicaciones de IA personalizadas) que se conectan a servidores MCP para acceder a sus capacidades.
• Servidores: aplicaciones que exponen recursos, herramientas y prompts a modelos de lenguaje. Cada servidor se especializa en proporcionar acceso a capacidades o fuentes de datos específicas.
  • Herramientas: funciones definidas por el usuario que los modelos pueden invocar para realizar acciones, como bases de datos de búsqueda, llamar a APIs externas o transformaciones de ejecución sobre datos
  • Recursos: fuentes de datos de las que los modelos pueden leer, que se sirven con datos dinámicos o estáticos y se acceden mediante patrones URI (similares a rutas REST)
  • Prompts: plantillas reutilizables de prompts con variables que guían el modelo para realizar tareas específicas.

Patrón de petición-respuesta

MCP sigue un patrón de interacción petición-respuesta familiar similar a las APIs REST. El cliente (LLM) aplicar un recurso o invoca una herramienta, luego el servidor MCP procesa la solicitud y devuelve el resultado, que el LLM emplea para continuar su tarea. Este modelo centralizado con servidores periféricos proporciona un patrón de integración más sencillo en comparación con la comunicación entre agentes entre iguales.

MCP en la redacción

En nuestro ejemplo de redacción, los agentes individuales emplean servidores MCP para acceder a las herramientas y datos que necesitan:

• Utilizaciones de Researcher Agent :
  • Servidor MCP de la API de Noticias (acceso a bases de datos de noticias)
  • Verificación de hechos del servidor MCP (verificar afirmaciones frente a fuentes confiables)
  • Servidor MCP de la base de datos académica (artículos académicos e investigaciones)
• Reporter Agent emplea:
  • Guía de estilo MCP Server (estándares de redacción para redacción)
  • Servidor MCP de plantillas (plantillas y formatos de artículos)
  • Servidor MCP de Biblioteca de Imágenes (fotos de archivo y gráficos)
• Editor Agent emplea:
  • Grammar Checker MCP Server (herramientas de calidad del lenguaje)
  • Servidor MCP de detección de plagio (verificación de originalidad)
  • Análisis SEO Servidor MCP (optimización de titulares y palabras clave)
• Utilizaciones del Agente de la Editorial :
  • CMS MCP Server (API del sistema de gestión de contenidos)
  • Servidor CI/CD MCP (Pipeline de despliegue)
  • Servidor MCP de Análisis (seguimiento y monitorización)

Sección 4: comparación de arquitectura

Cuándo usar A2A

La arquitectura A2A destaca en escenarios que requieren colaboración genuina entre múltiples agentes. Los flujos de trabajo de varios pasos que requieren coordinación se benefician enormemente de A2A, especialmente cuando las tareas implican múltiples pasos secuenciales o paralelos, flujos de trabajo que requieren iteración y refinamiento, y procesos con puntos de control y necesidades de validación. En nuestro ejemplo de redacción, el flujo de trabajo de la historia requiere que el Reportero escriba, pero puede que tenga que iterar de nuevo al Investigador si la confianza en ciertos hechos es baja, luego proceder al Editor y finalmente al Editor.

La especialización específica de dominio en múltiples áreas es otro caso de uso estable para A2A. Cuando se necesitan múltiples expertos en distintos campos para realizar una tarea mayor, con cada agente aportando un profundo conocimiento del dominio y capacidades de razonamiento especializadas para distintos aspectos, A2A proporciona el marco de coordinación necesario para establecer esas conexiones. La redacción lo ejemplifica perfectamente: el investigador se especializa en la recopilación de información, el reportero en la escritura y el editor en el control de calidad, cada uno con una experiencia distinta.

La necesidad de un comportamiento autónomo de agentes hace que A2A sea especialmente valioso. Los agentes que pueden tomar decisiones independientes, mostrar un comportamiento proactivo basado en condiciones cambiantes y adaptar dinámicamente a los requisitos del flujo de trabajo prosperan en una arquitectura A2A. La escalada horizontal de funciones especializadas es otro beneficio clave: en lugar de tener un único maestro de todos los oficios, múltiples agentes especializados trabajan coordinados, y múltiples instancias del mismo agente pueden manejar subtareas de forma asíncrona. Durante noticias de última hora en nuestra redacción, por ejemplo, varios agentes de Reporter pueden trabajar simultáneamente en diferentes ángulos de la misma historia.

Por último, las tareas que requieren colaboración genuina entre múltiples agentes son ideales para A2A. Esto incluye mecanismos de evaluación de los LLM como jurado , sistemas de construcción de consenso y votación, y la resolución colaborativa de problemas donde se necesitan múltiples perspectivas para alcanzar el mejor resultado.

Cuándo usar MCP

El Protocolo de Contexto del Modelo es ideal para ampliar las capacidades de un solo modelo de IA. Cuando un único modelo de IA necesita acceso a múltiples herramientas y fuentes de datos, MCP ofrece la solución perfecta con razonamiento centralizado combinado con herramientas distribuidas e integración sencilla de herramientas. En nuestro ejemplo de redacción, el Agente de Investigación (un modelo) necesita acceso a múltiples fuentes de datos, incluyendo News API, servicios de verificación de hechos y bases de datos académicas, todo ello accedido a través de servidores MCP estandarizados.

La integración estandarizada de herramientas se convierte en una prioridad cuando la ampliación de la compartición y la reutilización de las integraciones de herramientas importan. MCP destaca aquí con su ecosistema de servidores MCP preconstruidos que reducen significativamente el tiempo de desarrollo para integraciones comunes. Cuando se requiere simplicidad y mantenibilidad, los patrones de solicitud-respuesta de MCP son familiares para los desarrolladores, más fáciles de entender y depurar que los sistemas distribuidos, y tienen una menor complejidad operativa.

Por último, MCP suele ser ofrecido por proveedores de software para facilitar la comunicación remota con sus sistemas. Estos servidores MCP ofrecidos por el proveedor reducen significativamente el tiempo de incorporación y desarrollo, al tiempo que ofrecen una interfaz estandarizada con sistemas propietarios, haciendo que la integración sea mucho más sencilla que el desarrollo de APIs personalizadas.

Cuándo usar ambos (MCP de A2A ❤️)

Muchos sistemas sofisticados se benefician de combinar A2A y MCP, como se indica en la documentación de A2A sobre integración MCP. Los sistemas que requieren tanto coordinación como estandarización son candidatos ideales para un enfoque híbrido. A2A se encarga de la coordinación de agentes y la orquestación de flujos de trabajo, mientras que MCP proporciona acceso a herramientas individuales a los agentes. En nuestro ejemplo de redacción, los agentes coordinan mediante A2A; con el flujo de trabajo pasando de reportero a investigador, luego editor y luego editor. Sin embargo, cada agente emplea servidores MCP para sus herramientas especializadas, creando una separación arquitectónica limpia.

Múltiples agentes especializados, cada uno usando MCP para acceder a herramientas, representan un patrón común donde hay una capa de coordinación de agentes gestionada por A2A y una capa de acceso a herramientas gestionada por MCP. Esta clara separación de preocupaciones facilita la comprensión y el mantenimiento de los sistemas.

Los beneficios de combinar ambos enfoques son sustanciales. Obtienes los beneficios organizacionales de los sistemas multiagente, incluyendo especialización, autonomía y procesamiento en paralelo, además de disfrutar de los beneficios de estandarización y ecosistema del MCP, como la integración de herramientas y el acceso a recursos. Hay una clara separación entre la coordinación de agentes (A2A) y el acceso a recursos (MCP), y lo importante es que A2A no es necesario solo para tareas pequeñas como el acceso a API—MCP las gestiona de forma eficiente sin la sobrecarga de la orquestación multiagente.

Preguntas frecuentes: A2A vs. MCP - Casos de uso

Conclusión

Esta es la primera sección de dos partes que cubren la implementación de agentes basados en A2A reforzados con servidores MCP para proporcionar soporte y acceso externo a datos y herramientas. El siguiente artículo explorará el código real para demostrar que trabajan juntos para emular las actividades en una redacción online. Aunque ambos sistemas son extremadamente capaces y flexibles por sí mismos, verás cuánto se complementan cuando trabajan en conjunto.