Mantener el estado del agente entre reinicios: puntos de control y pruebas de recuperación

Un reinicio es una falla que puedes programar

La pasarela hermes-agent descrita en el issue 7181 puede dejar al usuario viendo «Still working... (iteration 43/90)» y luego recibir ningún error, resumen ni ruta de reanudación tras un reinicio. La misma pasarela descarta la tarea activa cuando se reinicia durante una tarea. En producción, los reinicios son rutinarios. El trabajo del operador es hacer que el agente reanude el trabajo pendiente sin repetir pasos ya completados.

El ciclo de vida de desarrollo de agentes de LangChain tiene cuatro etapas: Build, Test, Deploy y Monitor. En ese ciclo, la ejecución duradera significa que un agente guarda puntos de control de su progreso y reanuda en lugar de perder trabajo cuando algo falla. LangGraph ofrece un runtime para sistemas agénticos, con soporte para ramificación, bucles, pausas, reanudaciones y persistencia de estado a lo largo del tiempo. AgentRewind, un marco de recuperación en runtime, guarda puntos de control coincidentes tanto del contexto del agente como del entorno controlado, de modo que un agente pueda retroceder y continuar desde ese punto. Las tareas largas abarcan llamadas a herramientas, escrituras externas y decisiones que deben sobrevivir al límite del proceso.

El estado duradero del agente incluye la tarea, el contexto, el entorno y los efectos secundarios ya comprometidos. Si falta alguno, el agente puede reanudar con un contexto incompleto y efectos secundarios incorrectos.

Guarda puntos de control de la tarea, no solo de la transcripción

• Define el estado de la tarea. Enumera cada campo que debe sobrevivir a un reinicio: objetivo, paso actual, salidas de herramientas, acciones pendientes, restricciones del usuario, presupuesto, fecha límite y claves de idempotencia. El resultado debe ser un esquema que puedas serializar, comparar y restaurar sin conjeturas.
• Guarda puntos de control del contexto y el entorno. Guarda el contexto del modelo, el estado de las herramientas, los recursos externos y el entorno exacto necesario para continuar. La instantánea debe ser restaurable sin reconstruir el estado externo. El error común es guardar la transcripción y asumir que el estado externo también está guardado. Una llamada a herramienta, una fila de base de datos, un archivo o un mensaje aún pueden perderse.
• Persiste los pasos pendientes. Almacena las acciones inacabadas fuera de la memoria del proceso, con estado, reglas de reintentos y una forma de marcarlas como completadas. Sabrás que está hecho cuando una cola de próximas acciones sobreviva a un kill.
• Prueba la reanudación tras un kill o reinicio. Detén el proceso en puntos de control conocidos, luego inícialo de nuevo y verifica que el agente reanuda desde el punto guardado. Usa tareas largas donde el progreso parcial importe. MettleBench es un benchmark que mide la finalización de tareas y el progreso parcial en trabajo de ingeniería de largo horizonte. La prueba debe fallar si el agente reinicia desde el principio.
• Verifica que no haya trabajo duplicado ni omitido. Tras la reanudación, compara los efectos secundarios: sin envíos duplicados, sin archivos faltantes, sin pagos repetidos y sin validaciones omitidas. Una verificación exitosa produce un informe de recuperación que lista el punto de control, el paso reanudado y los efectos externos verificados.

Demuestra la recuperación antes de confiar en ella

La recuperación de agentes en producción es una prueba que puedes automatizar. Crea un escenario reproducible que cubra el reinicio que debes sobrevivir: despliegue programado, crash, agotamiento de memoria, recarga de configuración y drenaje de nodo. Para cada escenario, registra el punto de control antes de la detención, la señal del proceso, el retraso del reinicio y la primera acción tras la reanudación. Luego compara el resultado con el estado esperado de la tarea.

No pruebes solo el camino feliz. Un reinicio puede caer entre una llamada al modelo y una llamada a herramienta, entre una llamada a herramienta y una escritura, o entre una escritura y una confirmación. Tu punto de control debe hacer explícito ese límite. Si el agente no puede decir en qué lado del límite se encuentra, no puede reanudar de forma segura.

Usa un benchmark cuando la tarea sea lo suficientemente larga como para importar, pero tu propia prueba de falla debe usar tus herramientas, tus datos y tu disparador de reinicio. Debe fallar de forma clara cuando el agente repite un efecto secundario u omite un paso requerido.

Mantén la ruta de recuperación visible. Tras el reinicio, el agente debe reanudar, informar el punto de control guardado o solicitar una continuación segura.

Haz que la prueba forme parte de la puerta de despliegue. Una prueba de punto de control fallida detiene el despliegue. Un informe de recuperación que muestra trabajo duplicado detiene la liberación. Un agente que no puede demostrar dónde se quedó no recibe tráfico de producción.