Hermes Agent en Discord no responde: soluciones

Tu bot está en línea y te ignora

El punto verde está encendido. El bot aparece en la lista de miembros de tu servidor. Le haces @mención, le mandas un slash command, escribes un mensaje normal y no vuelve nada. Sin errores en los logs, sin respuesta en el canal. Discord muestra el bot como activo y Hermes Agent muestra el gateway como conectado.

Casi todos los casos que vemos se reducen a una de cuatro causas. Tres de ellas fallan en silencio por diseño, y por eso el bot parece sano mientras no hace nada. Este post repasa cada causa, cómo confirmar que es la tuya y la solución exacta.

Causa 1: el Message Content Intent está desactivado

Es la causa más común de un bot de Discord que se conecta y luego ignora cualquier mensaje normal. Síntoma: tus slash commands funcionan, pero no ocurre nada cuando escribes un mensaje o una respuesta corriente. En los logs ves llegar eventos MESSAGE_CREATE, pero el campo content está vacío.

Qué pasa: Message Content es un intent privilegiado del gateway. Discord lo envía desactivado por defecto. Sin él, tu bot recibe cada evento de mensaje pero no puede ver el texto, así que cualquier handler que intente hacer match por palabra clave, mención o prefijo falla en silencio.

La solución: abre el Discord Developer Portal, selecciona tu aplicación, entra en Bot en la barra lateral, baja hasta Privileged Gateway Intents y activa Message Content Intent. Guarda.

Para bots en menos de 100 servidores no hace falta aprobación, el toggle surte efecto de inmediato. Por encima de 100 servidores tienes que enviar la app a verificación y Discord aprueba el intent aparte.

No hace falta reiniciar Hermes Agent tras el cambio. El siguiente mensaje entrante llegará ya con el campo content poblado.

Causa 2: invitaste a la aplicación equivocada

Esta duele porque a simple vista todo está bien. Hay un bot en tu servidor, está en línea y tiene el avatar correcto. Pero escribas lo que escribas, nunca contesta.

Qué pasa: seguramente creaste varias aplicaciones de Discord mientras configurabas (una de pruebas, la real, alguna renombrada), y la URL de invitación que usaste apunta a una aplicación distinta a aquella cuyo token está corriendo Hermes Agent. Discord conecta felizmente ambas apps al gateway, las dos aparecen en línea, pero solo la app cuyo token tienes recibe eventos de tu servidor, y si esa app no está invitada, no recibe nada.

Comprueba primero: en el Developer Portal abre la aplicación cuyo token está en tu .env de Hermes Agent y copia el Application ID de General Information. Después, en tu servidor de Discord, haz clic derecho en el bot dentro de la lista de miembros y elige Copiar ID de usuario. Si esos dos IDs no coinciden, invitaste a otra app.

La solución: regenera la URL de invitación OAuth2 para la aplicación correcta (los scopes exactos están en la Causa 3), expulsa el bot equivocado de tu servidor e invita al bueno. Confirma que los IDs coinciden antes de seguir.

Panel del Discord Developer Portal con el Application ID junto a la ficha de un miembro del servidor mostrando un User ID que coincide con el del bot

Causa 3: la invitación no incluía bot o applications.commands

Si tu bot aparece en el servidor pero nunca recibe slash commands, o directamente no aparece como un usuario bot real, la URL de invitación OAuth2 se generó con los scopes equivocados.

OAuth2 de Discord requiere dos scopes distintos para instalar un bot completo:

bot, que es lo que convierte a la aplicación invitada en un usuario bot dentro del servidor.
applications.commands, que es lo que permite al bot registrar y recibir slash commands.

Sin el primero, Discord instala la app como una integración y no como un miembro bot, y el token no tiene a qué asociarse. Sin el segundo, el bot sí es un miembro real pero los slash commands no se registran, así que /loquesea devuelve Ha fallado la interacción o ni siquiera autocompleta.

La solución: en el Developer Portal ve a OAuth2 en la barra lateral, entra en URL Generator, marca bot y applications.commands en la sección Scopes y en el panel de Bot Permissions que aparece debajo marca como mínimo:

Send Messages
Read Message History
Embed Links
Attach Files
Use Slash Commands

Copia la URL generada al pie de la página, ábrela en el navegador, elige tu servidor y confirma. Una URL mínima válida se ve así:

https://discord.com/oauth2/authorize?client_id=<APPLICATION_ID>&scope=bot+applications.commands&permissions=277562616896

Si tu bot necesita unirse a canales de voz para responder por TTS, marca también Connect y Speak en la matriz de permisos y vuelve a invitar. Discord actualiza la pertenencia existente en lugar de añadir un duplicado.

Causa 4: el canal deniega el rol del bot

Los permisos a nivel de servidor son solo la mitad de la historia. Discord aplica overrides de canal y de categoría encima de los permisos del rol, y un único deny a nivel de canal sobre Send Messages o Read Message History silencia un bot que funciona en el resto del servidor.

Síntoma: tu bot responde en algunos canales y en otros no. O el bot está mudo en todos los canales, pero solo en este servidor, aunque el mismo bot funciona en tu servidor de pruebas.

Qué pasa: los overrides de canal pesan más que los permisos del rol. Si alguien de tu servidor denegó Send Messages para @everyone en este canal, o lo restringió a un rol que tu bot no tiene, tu bot no puede publicar allí aunque el rol tenga Send Messages a nivel de servidor. Read Message History es un permiso distinto de View Channel, así que un bot puede ver que llega un mensaje nuevo y aun así fallar al responder si el historial está denegado, porque algunas skills de Hermes Agent leen el contexto reciente antes de contestar.

Comprueba primero: clic derecho en el canal afectado, Editar canal, Permisos, y mira el rol de tu bot (o @everyone si el bot no tiene rol asignado). Busca una X roja en cualquiera de: View Channel, Send Messages, Read Message History, Send Messages in Threads, Use Application Commands.

La solución: o bien añade un ✓ explícito para el rol del bot en el canal afectado, o quita el deny en el nivel de categoría (los denies de categoría se propagan a todos los canales dentro). Si tu bot debe responder dentro de threads, Send Messages in Threads es un permiso aparte y necesita su propia concesión. En el hilo de soporte de Discord sobre overrides de canal tienes las reglas completas de precedencia.

Panel de permisos de canal de Discord mostrando un rol de bot con checks verdes en Send Messages y Read Message History

Orden de diagnóstico que ahorra tiempo

Cuando un bot se queda mudo, revisa las causas en este orden en lugar de saltar al arreglo más llamativo:

Compara Application ID y User ID del bot. Sesenta segundos, atrapa el caso de la app equivocada antes de tocar nada más.
Revisa Message Content Intent. Sesenta segundos en el Developer Portal, arregla la mayor parte de los bots mudos con un solo toggle.
Mira tus eventos entrantes. Si corres Hermes Agent con HERMES_LOG_LEVEL=debug, verás si el bot recibe eventos y si el campo content de los mensajes está vacío.
Vuelve a revisar los scopes de la invitación. Si el síntoma son los slash commands, esta suele ser la respuesta. Vuelve a invitar con los dos scopes marcados.
Audita los overrides de canal. Solo merece la pena una vez descartadas las cuatro anteriores, porque es lo más lento de comprobar y la causa menos frecuente cuando el bot está mudo en todas partes.

Para la ruta completa de instalación en Discord desde cero, mira la guía de setup de Hermes Agent en Discord. Si tu bot no logra conectarse a Discord (en lugar de conectar y quedarse mudo), el post Hermes Agent Docker container keeps restarting cubre los crash loops del gateway.

Cuando prefieres no pelearte con Discord cada semana

Los intents, el modelo de scopes y la matriz de overrides por canal de Discord son lo que son. Si tu lectura es que un agente conversacional simple no debería exigir un flujo OAuth y una revisión de intent privilegiado para saludar, empieza con Hermify. Hermify ejecuta un Hermes Agent gestionado en Telegram con la misma memoria y las mismas skills, activo en cerca de un minuto, sin configuración de gateway que vigilar.