A2A en dos máquinas: haz que los Hermes de dos ordenadores se pasen trabajo

Un Hermes en un ordenador no da abasto y quiere que otro Hermes en otra máquina le eche una mano: para eso está A2A. Pero, ¿qué trampas hay al desplegarlo? Usuarios reales ya las han pisado por ti.

Cuándo necesitas realmente dos máquinas

Primero aclara una cosa: ¿de verdad necesitas dos ordenadores, o solo quieres que dos agentes cooperen?

Si los dos agentes viven en la misma máquina, con delegación o un tablero basta: es como en la misma oficina, gritarle al compañero del cubículo de al lado, sin necesidad de llamar por teléfono. A2A está pensado para lo “entre máquinas / entre procesos / entre frameworks”: tu ordenador de escritorio y tu servidor ejecutan cada uno su propio Hermes, con sus propias memorias, herramientas y credenciales de acceso. Solo entonces necesitas el puente de A2A.

Pasos para empezar

Paso 1: activa la plataforma A2A en ambas máquinas. Al instalar Hermes elige A2A, o edita el archivo de configuración y pon gateway.platforms.a2a.enabled en true; el puerto por defecto es el 9900. Este paso equivale a instalarle a cada ordenador una puerta exterior con control de acceso.

Paso 2: configura el token (la llave del control de acceso). En el servidor, define A2A_PEER_TOKENS o A2A_BEARER_TOKEN. Si solo pruebas en local, puedes no poner token, pero la puerta solo se abrirá para 127.0.0.1: como si la tarjeta de acceso solo se la dieran a los vecinos del edificio.

Paso 3: expón la dirección. Para cruzar máquinas es obligatorio definir A2A_HOST, por ejemplo 0.0.0.0 o la IP de la red local. Este paso mueve la puerta del “pasillo interno” a “primera línea de calle”, para que el otro ordenador pueda encontrarte.

Paso 4: empareja a los pares. En el cliente configura a2a_agents, o directamente usa a2a_discover("http://dirección-del-servidor:9900") para ver la Agent Card del otro: es como pasar primero la tarjeta de visita, confirmar quién es el otro y qué sabe hacer.

Paso 5: verifica. Activa el conjunto de herramientas a2a y usa a2a_call para enviar una tarea sencilla de prueba. Ojo con los tiempos de espera: el cliente usa 330 segundos por defecto y la ventana de respuesta del servidor es de 300; para tareas largas hay que subirlos, o te cortarán a mitad de faena por superar el tiempo. Al terminar, echa un vistazo al registro de auditoría en ~/.hermes/a2a_audit.jsonl.

Caso real 1: cómo es un despliegue que funciona

La documentación oficial describe un escenario ideal: tu Hermes de escritorio le entrega una tarea al Hermes del servidor —el servidor tiene más potencia de cálculo, red más estable y una base de datos más completa. A la inversa, el Hermes del servidor también puede pasarle al de escritorio tareas como “mira este archivo local”. Cada lado tiene su propia memoria y sus herramientas, cada uno hace lo suyo, se descubren habilidades mutuamente mediante la Agent Card, la conversación se controla por contextId y admite varios turnos.

Es como dos departamentos de una empresa: el de marketing (el escritorio) necesita un informe de análisis de datos, le manda un correo al de datos (el servidor), el de datos lo hace y lo devuelve, y cada uno guarda sus propios archivos sin interferirse.

Caso real 2: un despliegue que fracasó

En la comunidad hay un caso real (#82910): un usuario desplegó dos nodos en dos macOS —una puerta de enlace orientada al usuario + un worker. Suena parecido al caso de éxito anterior, pero el resultado fue un desastre y al final el equipo retiró ese despliegue.

El problema fue que no se separaron bien los roles de “coordinador” y “worker”. El agente padre (el coordinador) acumuló demasiadas cosas en su propia sesión: cada paso del worker, cada resultado intermedio, cada proceso de razonamiento volvía a la sesión padre, provocando una inflación del contexto: el agente padre se ahogaba en un mar de información y cada vez iba más lento. La transcripción entre agentes lastraba el rendimiento general, y las tareas complejas disparaban bucles de recuperación que lo hundían cada vez más.

La lección es clara: en la colaboración entre máquinas con A2A hay que diseñar primero los límites de responsabilidad —quién coordina, quién trabaja, de quién es cada memoria. No lo apiles todo en la sesión padre; el worker debe tener su propia “libreta”.

Lista de trampas al desplegar

Colapso de identidad tras el proxy inverso (#80534/#80779): si usas nginx, Ingress de K8s o una CDN como proxy inverso, todos los pares comparten el mismo bearer token y las identidades se colapsan todas en la dirección del proxy. La solución es que el proxy transmita X-Forwarded-For y deducir la identidad real a partir del proxy de confianza. Es como cuando la recepción del edificio recoge los paquetes por ti: hay que escribir en el paquete quién es el destinatario real, o todo se amontona en recepción.

Rutas rechazadas con múltiples perfiles de configuración (#80884/#80956): si usas multiplex_profiles para ejecutar varias configuraciones, los mensajes A2A entrantes enrutados a un perfil secundario pueden ser rechazados por la capa de autorización de la puerta de enlace. La solución es capturar el contexto de seguridad del adaptador inmutable al arrancar y conservar las políticas de autenticación, confianza, vinculación y Agent Card de cada perfil. Cada puerta necesita sus propias reglas de acceso; no se puede compartir un mismo sistema.

Tiempos de espera: por defecto, 330 segundos en el cliente frente a 300 en el servidor; en tareas largas, recuerda ajustarlos. Si no, es como una llamada de larga distancia: te cortan sin que termines de hablar.

Modo worker acotado (#82503): es la receta oficial contra la inflación del contexto. Las rutas A2A servidas que no son root pueden ejecutar subprocesos de configuración o workers RPC versionados, con salida acotada, recolección del árbol de procesos, cancelación y terminación exactamente una vez: el worker termina su faena y se retira, sin volcar todo el proceso a la sesión padre.

Qué significa para el usuario

Desplegar A2A en dos máquinas no es tan simple como “conectar dos ordenadores”. Es como abrir una sucursal: hay que pensar bien el local (Agent Card), el control de acceso (token), la división del trabajo (quién coordina y quién trabaja) y el almacén (la memoria de cada uno). Un despliegue con éxito hace que cada máquina luzca sus puntos fuertes; uno fallido ahoga al coordinador en información.

Recuerda tres cosas: primero define los límites de responsabilidad, luego piensa en los detalles técnicos; el proxy inverso tiene que resolver el tema de la identidad; y para tareas largas ajusta los tiempos de espera, y para tareas complejas usa workers acotados. Con esto, los Hermes de dos ordenadores pueden ser de verdad buenos compañeros, y no compañeros que se hunden mutuamente.