Empleos cron de agente hermes: programación que funciona

Hola, soy Lena. Tuve un trabajo cron montado durante unos tres días antes de darme cuenta de que en realidad no estaba haciendo lo que yo pensaba.

Parecía bien en la lista. El horario era correcto. El prompt parecía claro cuando lo escribí un martes por la tarde. Pero las partidas producían resultados que se sentían un poco desajustados — no rotos, solo... no el mismo tipo de resultado que obtendría si le preguntara lo mismo al agente en un chat normal. Hice una pausa aquí. Lo había estado tratando como un cron de Linux. La cuestión es que **Hermes Agent **cron no es realmente un cron de Linux. Solo toma prestada la sintaxis del horario.

Este es un resumen de lo que poco a poco he ido entendiendo sobre cómo funciona realmente cron dentro de Hermes — y por qué tantos trabajos acaban pareciendo estar bien programados pero funcionando mal. Es el tipo de cosa que probablemente no es urgente hasta que lo es.

Lo que realmente hace Hermes Cron

Lo primero que vale la pena decir en voz alta: un trabajo cron de Hermes** no es un comando shell en un temporizador. Es una sesión de agente que se ejecuta según un horario.**

Esa distinción importa más de lo que pensaba. Según la documentación oficial de Hermes cron, cada ejecución programada comienza en una sesión de agente completamente nueva. Sin historial de conversaciones. Sin memoria de la última ejecución. Sin contexto acumulado de tus sesiones interactivas. Lo que el agente necesite para hacer su trabajo, el prompt tiene que proporcionarlo — o las habilidades adjuntas.

La segunda cosa: la pasarela tiene que estar funcionando. El planificador no es un demonio separado que puedas ignorar. En modo gateway, el tick del planificador forma parte del bucle principal de eventos de la pasarela, llamado aproximadamente cada 60 segundos. Si la puerta de enlace no está activa, tu trabajo se queda en jobs.json y espera, pareciendo perfectamente programado y sin hacer nada. Aprendí esto por accidente: un trabajo que "no estaba ejecutándose" en realidad estaba bien; la pasarela se había bloqueado dos días antes.

La tercera cosa es la entrega. La respuesta final del agente se entrega automáticamente al destino configurado. Así que si has escrito un prompt que termina con "y envíamelo por Telegram", y el destino es Telegram, Hermes detectará el duplicado y solo enviará una vez. Esa parte está gestionada. No tienes que pensarlo — pero sí tienes que saber que está ocurriendo.

! [imagen] (https://uploads.evomap.ai/blog/74fe446f26d1f469.png)

Formatos de programa, repeticiones, habilidades, destinos

Hermes acepta tanto intervalos en lenguaje natural como expresiones cron POSIX estándar de 5 campos. Así que every 1h, 30m y 0 9 * * 1-5 funcionan. El formato de 5 campos es básicamente el mismo que se utiliza en todas partes — crontab de Linux, CronJobs de Kubernetes, GitHub Actions — y la entrada de Wikipedia sobre cron es una referencia sorprendentemente buena si quieres confirmar exactamente cómo los valores por pasos y los rangos interactúan en el dialecto Vixie, que es lo que siguen la mayoría de los sistemas incluyendo Hermes.

Si no estás seguro de que tu expresión realmente significa lo que crees, crontab.guru es la herramienta a la que siempre vuelvo. Pega la expresión, lee la versión en inglés sencillo, verifica mentalmente los próximos 5 tiempos de ejecución. Esto es de esas cosas que toma treinta segundos y te ahorra una tarde de depuración.

Puedes adjuntar habilidades con --skill name (una o muchas), establecer un destino con --deliver, darle un nombre al trabajo y anular el modelo en función de cada trabajo. Los registros de trabajos se almacenan como JSON en ~/.hermes/cron/jobs.json con escrituras atómicas — lo que significa que si una escritura se interrumpe no terminas con un archivo parcialmente dañado.

Crear trabajos que sobrevivan al uso real

El patrón que he terminado usando se ve algo así:

hermes cron create "0 9 * * 1-5" \
  "Pull yesterday's commits from the repo at ~/work/project, \
   summarize what changed in 5 bullets, and flag anything that \
   looks unusual" \
  --skill git-summary \
  --name "Weekday standup prep"

Tres cosas que quiero destacar:

• El horario es explícito. 0 9 * * 1-5 — 9 am, días laborables. No every day at 9. La expresión cron es inequívoca para cualquier lector que conozca la sintaxis, incluyendo mi yo futuro a las 11 pm tratando de depurar por qué algo se ejecutó un sábado.
• El prompt es autosuficiente. Indica dónde está el repositorio. Indica qué resumir. Indica cuántos puntos. No asume que el agente recuerde nada de ejecuciones anteriores.
• Se adjunta una habilidad. La habilidad git-summary (hipotética aquí) lleva el procedimiento real — cómo leer el git log, qué formato usar, qué se considera “inusual”. El prompt cron solo tiene que decir qué hacer, no cómo.

Ese tercer punto es el que sigo reaprendiendo.

Por qué los prompts autosuficientes importan más de lo que la gente espera

Aquí hay un prompt que escribí en la primera semana que no funcionó como quería:

"Igual que la última vez pero para los datos de esta semana."

En mi sesión interactiva ese prompt está bien. El agente tiene el historial de conversaciones. Sabe cuál fue la "última vez". Sabe qué datos estábamos revisando. En una ejecución de cron ninguna de esas cosas existe. Sesión nueva. Sin memoria. Sin contexto. El agente lee "igual que la última vez" y no tiene nada con qué comparar.

Una versión que realmente funciona:

"Lee el CSV en ~/data/weekly-signups.csv. Calcula el porcentaje de cambio en las inscripciones respecto a los 7 días anteriores. Informa el número, el cambio y las 3 principales fuentes de derivación. Formatea como un mensaje de Slack."

Aburrido. Verboso. Específico. Funciona siempre.

Los documentos de Hermes tienen un buen ejemplo de la misma idea, donde el patrón recomendado es esencialmente: asumir que el agente está leyendo tu prompt por primera vez, de forma aislada, sin contexto salvo las habilidades adjuntas. Si el prompt no tiene sentido como una instrucción independiente para un desconocido, tampoco tendrá sentido para una sesión cron** nueva.**

Fallos comunes de cron y cómo prevenirlos

Algunos patrones que he visto salir mal, sobre todo en mi propio montaje:

El silencio del gateway no está ejecutado. El trabajo está programado. La lista lo muestra. El estado parece correcto. No se activa nada. La solución suele ser: hermes cron status confirmar que el programador está activo, luego asegurarse de que el gateway esté instalado como un servicio para que sobreviva a los reinicios y cerrar sesión. Hasta que lo hayas instalado como servicio de usuario o del sistema, cada hermes gateway primera línea en primer plano está a un cierre de terminal de fallar.

Indicaciones frágiles con contexto implícito. Ya se ha tratado. La versión de esto que más veo es "resume lo nuevo" — ¿nuevo comparado con qué? ¿Cuándo? El agente no lo sabe.

Se solapan desde una frecuencia mal calculada. Un trabajo configurado a every 1m que tarda 90 segundos en completarse crea una pregunta interesante. Hermes usa bloqueo basado en archivos en el tick del planificador para evitar que el mismo lote de trabajo pendiente se procese dos veces en paralelo, lo cual es bueno. Pero la pregunta más profunda es si realmente necesitas una resolución de 1 minuto. Normalmente no.

Envíos duplicados del prompt que piden entrega. Si tu prompt termina con send_message(...) al mismo destino al que el programador ya va a entregar, Hermes detecta el duplicado y se salta el segundo envío. Vale. Pero si has escrito send_message llamadas en cada prompt por reflejo, la intención del trabajo es más difícil de leer. Más limpio dejar la entrega al programador y dejar que el prompt se centre en la tarea.

Inyección de prompts a través de los datos que lee el trabajo. Si tu trabajo cron obtiene una página web y la resume, esa página puede en teoría contener instrucciones que intenten redirigir lo que hace el agente. Hermes escanea los prompts cron en busca de patrones de inyección de prompts en la creación y actualización, pero no desinfecta el contenido externo que el trabajo absorbe en tiempo de ejecución. Esta es la misma categoría de riesgo que OWASP describe como inyección indirecta de prompt en su LLM Top 10 — y vale la pena tenerla en cuenta para cualquier trabajo cron que ingiera entrada no confiable. No he entendido del todo cómo pensar en esto para trabajos personales de bajo riesgo, pero para cualquier cosa que toque credenciales o sistemas externos, importa.

! [imagen] (https://uploads.evomap.ai/blog/21e1f5db35140dec.png)

Patrones operativos que merece la pena usar

Algunas configuraciones a las que he vuelto:

• Informe diario a un horario fijo. 0 9 * * 1-5 con una habilidad que extrae los datos y un prompt autónomo que dice exactamente qué resumir.
• Comprobación periódica de salud. */15 * * * * — cada 15 minutos — ejecutando un pequeño script que envia ping a un endpoint y solo entrega un mensaje si algo va mal. El campo de script en un trabajo cron se ejecuta antes de cada turno de agente, y su stdout se convierte en contexto para el agente. Útil para patrones de detección de cambios donde no quieres un resultado ruidoso de 96 ejecuciones al día.
• Trabajos con múltiples habilidades. Adjuntar dos o tres habilidades permite que un trabajo combine una habilidad de recopilación de datos con una habilidad de análisis. El prompt cron se convierte en "usar ambas habilidades e informar."
• Trabajos con conocimiento de respaldo. Los trabajos cron heredan los proveedores de respaldo configurados y la rotación del pool de credenciales. Así que si un trabajo se ejecuta a las 3 de la mañana y el proveedor principal devuelve un error de límite de tasa, la ejecución puede enrutarse a un proveedor de respaldo en lugar de fallar todo el trabajo. Esta es una de esas funciones que no aprecié hasta que salvó una ejecución que de otro modo habría pasado por alto. La página interna de cron de Hermes es donde se describe con más detalle si quieres verificar exactamente cómo funciona la cadena de resolución.

Lo que me repito a mí mismo: un trabajo cron que se ejecuta vale más que uno cron que es elegante. Prompts aburridos, verbosos y autónomos. Horarios explícitos. Gateway instalado como servicio. Habilidades haciendo el trabajo duro. Esa combinación es lo que marca la diferencia entre "yo configuré esto" y "esto ha estado funcionando en silencio durante tres semanas y se me olvidó que existía."

! [imagen] (https://uploads.evomap.ai/blog/87a0ccdeadc4cbee.png)

Preguntas frecuentes

¿Por qué mi trabajo cron** no tiene acceso a mi historial de chats anteriores?**

Cada partida es una sesión de agente fresco por diseño. Sin historial, sin recuerdos. El prompt y cualquier habilidad adjunta son el único contexto que ve el agente.

¿Necesito llamar a send_message** en el prompt?**

No, y lo ideal sería que no lo hagas. El planificador entrega automáticamente la respuesta final del agente. Si tu prompt también send_message llama al mismo destino, Hermes detecta el duplicado y se salta el segundo envío.

Mi trabajo funciona pero nunca cancela el horario. ¿Qué pasa?

La mayoría de las veces el gateway no está funcionando. Prueba hermes cron status para comprobar el programador. Los trabajos cron solo se activan cuando el gateway está activo, o en modo CLI cuando hay una sesión activa.

¿Puede un trabajo cron** crear más empleos cron****?**

No. Las sesiones de ejecución cron tienen desactivado el conjunto de herramientas cronjob para evitar bucles de programación descontrolados.

¿Cuánto puede durar un trabajo cron**?**

El tiempo de espera por defecto es basado en inactividad, no en reloj de pared: un trabajo que hace activamente llamadas a herramientas o transmite tokens puede ejecutarse indefinidamente. Un trabajo inactivo durante más de HERMES_CRON_TIMEOUT (600 por defecto) se cancela.

Probablemente seguiré perfeccionando cómo escribo estos prompts. Cron es una de esas cosas donde la mayoría de lo que lo hace funcionar no se ve en el campo de horario: está en el prompt, en la habilidad y en si el sistema debajo realmente está funcionando. Vale la pena comprobarlo, de vez en cuando, que los tres sigan donde los dejaste.

Publicaciones anteriores:

• 👉 Si estás configurando varias tareas programadas, quizá quieras entender cómo afectan Hermes Cron Memory & Context Limits a tus trabajos cron.
• 👉 Si estás solucionando problemas de ejecuciones superpuestas o ejecuciones lentas, consulta esta guía sobre [Configuración segura de Hermes MCP para trabajos cron] (https://evomap.ai/blog/safe-mcp-hermes-agent).
• 👉 Para una profundización en cómo mejorar el comportamiento de los agentes con prompts e instrucciones claras:Cómo escribir habilidades efectivas para agentes de Hermes
• 👉 ¿Estás pensando en automatizar la monitorización en tiempo real? Esta guía te ayudará: Trabajos cron de revisión periódica de salud con Hermes
• 👉 ¿Necesitas optimizar la entrega de crons para obtener resultados estables? Lee más sobre Gestión de capacidades de agentes y acceso a herramientas