Convierte un agente en un servicio, no en un terminal olvidado.

Empaqueta el worker

Usa un entorno de ejecución compatible, dependencias fijadas y un gestor de servicios o un contenedor. Configura límites de reinicio y un usuario de servicio dedicado. Mantén las credenciales privadas del proveedor en una configuración protegida fuera de los archivos públicos de la aplicación.

Guarda el progreso antes de que las acciones importen

Usa una cola o base de datos duradera para las tareas. Asigna un identificador de operación único, registra las solicitudes externas y concilia los resultados inciertos. Un reinicio no debería enviar un segundo correo, crear un segundo pedido ni cobrar dos veces.

Añade observabilidad útil

Supervise la finalización de las tareas, la antigüedad de la cola, la tasa de errores y el coste en lugar de comprobar solo si existe un proceso. Mantenga los registros lo bastante pequeños para revisarlos y oculte los tokens, prompts y documentos que no necesiten conservarse.

Establece un límite claro

Limita el gasto del modelo, la concurrencia del navegador, el tiempo de ejecución y el número de reintentos. Mantén un interruptor de pausa fácil y una vía de revisión humana para acciones con consecuencias. Un trabajador más pequeño y bien observado es más fácil de confiar que uno sin restricciones.

Usa un supervisor y una programación deliberada

Systemd y Docker son formas habituales de hacer que un proceso sobreviva a la desconexión de la terminal. Para un servicio de systemd, Type=exec puede informar de un fallo de ejecución de forma más directa que un simple lanzamiento en segundo plano, y Restart=on-failure puede reiniciar los fallos con una política acotada. Los trabajos programados deben evitar ejecuciones superpuestas. Mantenga explícitos el directorio de trabajo, el usuario del servicio y el entorno. El ejemplo supone que el usuario koala-agent, el entorno virtual, el módulo worker y el archivo de entorno privado ya existen; adáptalos antes de instalar una unidad.

• Usa una cuenta de servicio dedicada
• Establezca un retraso de reinicio y un límite de fallos
• Verifica el estado del trabajo anterior antes de iniciar una ejecución programada

[Unit]
Description=Example agent worker
After=network-online.target

[Service]
Type=exec
User=koala-agent
WorkingDirectory=/opt/koala-agent
EnvironmentFile=/etc/koala-agent.env
ExecStart=/opt/koala-agent/.venv/bin/python -m worker
Restart=on-failure
RestartSec=10
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Documentación oficial: Semántica del servicio systemd

Establece un presupuesto diario y un límite de duplicados

Asigna al worker un número máximo de solicitudes, un límite de gasto y un tiempo de espera de ejecución. Usa un registro de idempotencia duradero para las acciones que afectan al mundo exterior. Un clic exitoso en el navegador puede ocurrir antes de que el proceso reciba una respuesta; inspecciona el estado externo antes de intentarlo de nuevo. Los montajes de secretos de Docker Compose pueden mantener un secreto fuera de la imagen, pero los permisos y la aplicación consumidora aún requieren revisión.

Documentación oficial: Secretos de Docker Compose

Asigna a una tarea periódica una política de recuperación explícita

Usa un servicio de larga duración para un trabajador de cola persistente y un servicio oneshot activado por temporizador para una tarea programada acotada. Con un temporizador de calendario de systemd, Persistent=true puede activar una activación perdida tras un tiempo de inactividad; no recrea todo un historial de negocio pendiente. Decide si esa recuperación es deseable. RandomizedDelaySec puede distribuir los inicios, mientras que un lease a nivel de aplicación evita que dos réplicas procesen el mismo trabajo programado.

• Registra la zona horaria prevista e inspecciona las próximas horas de ejecución antes de activar la programación.
• Mantén el plazo de ejecución de la tarea más corto que un intervalo que no debe solaparse, o usa un lease duradero con expiración y propiedad.
• Haga que la tarea seleccione el trabajo pendiente a partir del estado almacenado en lugar de suponer que se ejecutó cada evento de temporizador anterior.
• Comprueba la versión de systemd instalada antes de usar una directiva del manual más reciente.

# Read-only checks after creating your own matching units.
systemctl list-timers --all
systemctl status koala-agent.service
journalctl -u koala-agent.service --since today --no-pager

Documentación oficial: systemd: programación de temporizadores

Distingue un bucle de fallos de un trabajador bloqueado

Una política de reinicio puede recuperar un proceso fallido, pero repetir una credencial no válida o una migración rota cada pocos segundos hace que el fallo sea más ruidoso. Acota los inicios del servicio y alerta ante fallos repetidos. Un proceso activo también puede quedarse bloqueado: mide la antigüedad del trabajo más antiguo y de la última operación completada. Prueba una interrupción de API, un disco vacío y una parada del proceso con trabajos desechables, y luego verifica que el estado duradero evita acciones externas duplicadas.

• Establezca un presupuesto de proveedor y un tiempo de espera de solicitud en la aplicación, así como un límite de CPU/memoria en el entorno de ejecución.
• Los contenedores Docker no tienen un límite de memoria útil específico de la carga de trabajo solo por ser contenedores; configura y prueba los límites de forma deliberada.
• Guarde un secreto fuera de la imagen y del árbol público, y luego compruebe que los registros de fallos y los diagnósticos lo ocultan.
• Mantén una vía de parada manual y exige la revisión adecuada para gastos, escrituras en producción o mensajes externos.

Documentación oficial: systemd: supervisión de servicios · Docker: restricciones de recursos de contenedores