Reanudabilidad del agente, explicada: sesiones, turnos, pausas y reconexiones en TrueForge

La reanudación de un agente no es una operación única. Los sistemas en producción deben distinguir entre reconectar un flujo, continuar un flujo de trabajo pausado y recuperar un efecto secundario externo incierto.

«Reanudar» oculta tres problemas de recuperación distintos

Los agentes de larga ejecución fallan en más puntos que una API convencional de solicitud-respuesta. Un navegador puede desconectarse mientras el servidor sigue trabajando. Un flujo de trabajo puede detenerse intencionadamente porque una persona, una herramienta del lado del cliente o un flujo OAuth deben proporcionar información. Una API de nivel inferior puede agotar el tiempo de espera tras confirmar una mutación. Las tres situaciones pueden describirse como «reanudar», pero requieren estados, evidencias y reglas de seguridad diferentes.

La primera es la recuperación del transporte: reconectarse a un flujo que sigue activo sin duplicar eventos. La segunda es la continuación del flujo de trabajo: crear una nueva unidad de trabajo que responda a una pausa registrada. La tercera es la recuperación de efectos: determinar si una operación externa se confirmó antes de decidir si se debe reintentar, compensar o detener. Tratar esto como un mecanismo único crea el tipo de error de fiabilidad más peligroso: aquel que parece funcionar correctamente mientras repite o salta una acción del mundo real.

Las tres ramas terminan deliberadamente en acciones diferentes. Una secuencia de flujo repara la observación, una referencia de acción requerida continúa el flujo de trabajo y un ID de operación permite la conciliación; sustituir un identificador por otro crea duplicados o falsas finalizaciones.

Comience por la jerarquía de TrueForge

TrueForge documenta una jerarquía de Agente → Sesión → Turno → Evento → Delta. Un agente es una definición reutilizable. Una sesión representa un problema o conversación y persiste a través de los turnos. Un turno es un ciclo de solicitud y ejecución que se ejecuta hasta que termina o se pausa. Los eventos describen lo que sucedió durante ese turno. Algunos eventos de mensaje producen deltas mientras se transmiten; los listados de eventos persistidos devuelven el evento combinado en lugar de cada fragmento en vivo.

Esta jerarquía es importante porque cada capa responde a una pregunta de recuperación diferente. La definición del agente establece el modelo configurado, las instrucciones, las herramientas y los límites. La sesión proporciona una continuidad conversacional duradera. El turno proporciona un límite de ejecución con un estado terminal. Los eventos exponen la evidencia ordenada necesaria para reconstruir la vista del cliente. Los deltas optimizan la experiencia en vivo, pero no son hechos comerciales duraderos independientes.

TrueForge permite que solo un turno se ejecute en una sesión a la vez. Los turnos se encadenan automáticamente, por lo que la aplicación no tiene que reenviar el historial completo en cada solicitud. Crear un nuevo turno mientras otro sigue en ejecución cancela el turno activo. Ese comportamiento es útil, pero significa que una interfaz de usuario no debe traducir cada clic impaciente en un nuevo turno sin una decisión de producto explícita.

La reconexión de transporte no es la continuación del flujo de trabajo

Un turno en vivo utiliza un flujo de eventos enviados por el servidor (Server-Sent Events). Cada elemento transmitido lleva un identificador de secuencia que el cliente puede conservar. Si la conexión se interrumpe, el cliente puede volver a suscribirse después del último número de secuencia procesado. El servidor puede entonces reproducir eventos posteriores del mismo turno en ejecución. Un cliente correcto almacena los eventos por ID de evento y combina los deltas en su evento de mensaje base, de modo que la retransmisión no duplica la salida visible.

Eso es la reconexión de transporte. El turno original no se ha pausado por una decisión comercial; solo se interrumpió la conexión de red. El servidor puede seguir ejecutándose mientras el cliente está ausente. Por lo tanto, una interfaz de usuario que se reconecta pregunta: «¿Qué eventos de este turno existente no he renderizado?». No debería crear otro turno ni volver a emitir la instrucción original del usuario.

Una vez que un turno ha finalizado, sus eventos persistidos pueden leerse de nuevo para reconstruir el historial consolidado. Eso es reproducción de evidencia, no reejecución del modelo y las herramientas. La distinción es importante para el análisis de incidentes: la misma secuencia almacenada debería producir la misma vista reconstruida, pero un intento de ejecutar la tarea de nuevo puede encontrar diferentes modelos, herramientas, credenciales y estados externos.

La figura separa la jerarquía duradera de la mecánica de entrega. Los deltas pertenecen al flujo en vivo y se combinan en eventos base, mientras que las sesiones, los turnos encadenados, los estados terminales y los eventos persistidos proporcionan el registro consolidado utilizado tras una reconexión o reinicio.

Las pausas son estados de ejecución explícitos

Un turno puede terminar con acciones requeridas en lugar de una respuesta final. TrueForge documenta tres casos importantes: una herramienta cerrada necesita aprobación, una herramienta del lado del cliente necesita una respuesta o un servidor MCP necesita autorización. El estado terminal del turno identifica los elementos pendientes. La aplicación los satisface creando un nuevo turno que contenga la aprobación, la respuesta de la herramienta o la continuación de la autenticación correspondientes.

Esto es una continuación del flujo de trabajo, no una reconexión de flujo. El turno pausado ya está resuelto. El siguiente turno preserva la continuidad causal al hacer referencia a la acción pendiente y al encadenarse al historial de la sesión. Un solo turno puede mostrar más de un elemento pendiente, incluidas las pausas de hilos de subagentes paralelos, por lo que los clientes deben recopilar el conjunto completo de acciones requeridas en lugar de asumir que solo hay una.

Para las pausas de aprobación y respuesta, el evento de origen vincula el elemento pendiente al mensaje del modelo que propuso la llamada a la herramienta. Ese enlace permite a la aplicación mostrar al revisor el nombre de la herramienta y los argumentos que crearon el punto de control. También es la base para verificar que la continuación responda a la llamada prevista y no a una visualmente similar.

Establecer un contrato de reanudabilidad

‍