Agentes temporales AI: Ejecución duradera separada de los agentes sanitarios

Temporal es una respuesta fuerte a un problema de agente duro: ¿Cómo mantener una ejecución de larga duración recuperable cuando los trabajadores se estrellan, los procesos se reanudan o una dependencia externa falla? ¿No es, por sí solo, una respuesta a una pregunta diferente: ¿Es el agente sano y produjo el resultado que el usuario pidió? El defecto seguro es usar el estado de flujo de trabajo temporal como evidencia de ejecución, luego agregar cuatro recibos de solicitud antes de asignar un veredicto de salud: 1. un recibo de progreso que muestre un hito significativo o un delta de salida; 2. un recibo de wait con el nombre del propietario, la fecha límite y la condición de continuación; 3. un recibo effect que resuelva si ha ocurrido una acción del lado de la herramienta; 4. un recibo de entrega que compruebe el artefacto o estado solicitado. Esa distinción es importante porque el propio Flujo de trabajo Documentación de ejecución de Temporal define a Running como capaz de progresar mientras progresa activamente en o espera algo . Por lo tanto, un flujo de trabajo abierto y verde no puede distinguir entre un trabajo productivo, una espera legítima de aprobación o un estancamiento silencioso. Asimismo, un flujo de trabajo Completed cerrado demuestra que su código ha alcanzado un camino de finalización; no demuestra automáticamente que una factura se haya enviado una vez, que una solicitud de retirada contenga los cambios previstos o que existe un informe en el destino prometido. Lo que demuestra Temporal y lo que no El modelo de ejecución duradero de Temporal proporciona a un agente AI valiosas garantías mecánicas. El estado del flujo de trabajo persiste a pesar del fracaso. Las comprobaciones de reproducción generaron comandos contra el historial de eventos. Las actividades aislan las llamadas propensas a fallas como las solicitudes LLM, el uso de herramientas y las API externas del código de orquestación determinista. La explicación oficial de agentes dinámicos AI en Temporal hace que este límite sea explícito: la orquestación del flujo de trabajo debe ser determinista, mientras que las decisiones y los resultados de las herramientas de LLM pueden permanecer no deterministas dentro de Actividades. Estas propiedades responden a varias preguntas operativas: ¿Puede el estado de orquestación registrado sobrevivir a un reinicio de los trabajadores? ¿Puede el flujo de trabajo reanudarse a partir de su historial registrado en lugar de recalcular cada decisión anterior de LLM? ¿Todavía se está intentando una actividad, terminada, fallida o completa? ¿Está el flujo de trabajo abierto, detenido, cancelado, completado, fallido, terminado o terminado? No responden a cuatro preguntas específicas del agente: ¿Se ha acercado el plan al objetivo del usuario, o el bucle simplemente está activo? ¿Es una pausa esperada, apropiada y reiniciada? ¿Se produjo un efecto secundario externo, especialmente después de una pausa o accidente de trabajo? ¿Existe el resultado final y satisface una verificación de aceptación determinista? Esto no es una crítica de Temporal. Es un límite de responsabilidad. El Implementación del agente AI de la comunidad temporal demuestra un bucle de agente, llamadas a herramientas, confirmación humana, señales, gestión de estado y pruebas dentro de un flujo de trabajo. Sus propias notas también recuerdan un largo historial de conversaciones, volver a intentar la visibilidad y las consideraciones de almacenamiento de producción. La semántica de las aplicaciones todavía pertenece a la aplicación. Pon cuatro recibos por encima del estado de flujo de trabajo Un recibo compacto puede ser mucho más pequeño que una transcripción. Debería exponer la evidencia, la frescura y la identidad sin subir las instrucciones, las cargas útiles de herramientas o los secretos. El recibo de progreso debe describir un hito de la solicitud, no sólo un timestamp de la frecuencia cardíaca. Documentos temporales Actividad Los latidos cardíacos como una forma para que un trabajador informe de la vitalidad y el progreso, preserve los detalles del progreso para un retiro y reciba la cancelación. Ese transporte es útil, pero la carga útil tiene que llevar un delta significativo: recuento de registros procesados, conjunto de fuentes verificado, ID de ramas completadas, digestión de artefactos u otra invariante específica de la tarea. Un agente puede emitir una nueva marca de tiempo para siempre mientras repite la misma llamada fallida. El recibo de espera evita que el error opuesto pague una pausa humana saludable en el circuito como un estancamiento. Requerir tres campos: owner : la persona o sistema capaz de resolver la dependencia; deadline : cuando la espera se vuelva tardía; resumeToken : la señal, actualización, identificación de aprobación u otra identidad que reanude el mismo trabajo. Faltando cualquiera de los tres hace que la espera sea operacionalmente incompleta. Esperar la aprobación sin un propietario es un trabajo abandonado. Un propietario sin fecha límite puede desaparecer indefinidamente. Un plazo sin identidad de currículum invita a una continuación duplicada o desviada. La recepción del efecto es necesaria porque las actividades pueden ser retomadas. El Guía de manejo de errores de Python de Temporal describe las actividades como al menos una vez y recomienda la idempotencia: un trabajador puede completar una acción externa y caer antes de que se complete el registro del servicio. Para un agente, los estados críticos son none , attempted , verified y unknown . Unknown no tiene permiso para volver a intentarlo. Conciliar primero la identificación de operación estable con el destino. El recibo de entrega cierra la brecha en el otro extremo. Debe vincular el flujo de trabajo y ejecutar la identidad a una verificación determinista: digesta de archivos, versión de base de datos, ID de recursos HTTP, compromiso fusionado, resultado de prueba o veredicto de aceptación estructurado. Un mensaje de lenguaje natural done es evidencia de una afirmación, no evidencia del resultado. Un experimento de seis casos El dispositivo inspectable utilizado para este artículo evalúa seis carreras con una regla determinista: El estado del flujo de trabajo por sí solo desmoronaría los cuatro primeros casos en RUNNING y los dos últimos en COMPLETED . Los recibos cambian la decisión del operador: El caso Pruebas decisivas Acción segura Trabajo reciente hito cambió ¡Dejela en paz! Esperando propietario, fecha límite, token de resurrección ruta o esperar hasta la fecha límite Estoy atrapado. no delta reciente y no espera válida Investigar, luego preparar una recuperación limitada Efecto incierto ID de operación estable no tiene veredicto de destino reconciliarse; no vuelva a intentarlo. Falso éxito Flujo de trabajo completado pero falta entregable reabrir el incidente Completos saludables finalización, efecto y entregable acuerdo cerrar con pruebas La regla es intencionalmente conservadora. No utiliza un juez LLM cuando haya un control determinista disponible. Preserva uncertain cuando las pruebas no están de acuerdo. También evita "fixar" cada pausa: una espera válida sigue siendo una espera, no un fracaso. Las pruebas operativas y las historias largas sin falso verde Temporal se encarga de la mecánica de la repetición, pero la aplicación todavía posee el presupuesto de la repetición y el límite de efectos. Para cada Actividad externa, lleve un ID de operación estable a lo largo de los intentos. Registrar el veredicto de impotencia del destino cuando esté disponible. Separar el fallo de transporte transitorio del fallo de entrada permanente, y detenerse cuando el plazo restante de ejecución no pueda acomodar otro intento más la reconciliación y la verificación de entrega. Para actividades largas, combine tres señales diferentes: Actividad pulso fresco: ¿se comunicó recientemente el trabajador? Fresqueza de la piedra angular: ¿ha cambiado el estado de aplicación útil? ¿Es todavía autorizado y capaz de terminar el nuevo ensayo? Un nuevo latido cardíaco con un hito inalterado puede ser un bucle. Un latido cardíaco obsoleto con reciente recibo de destino puede ser un fallo de notificación incierto. Una espera de retroceso exponencial puede ser saludable si su tiempo de vigilia y presupuesto son explícitos. Ningún sello de tiempo merece un veredicto verde. El crecimiento de la historia es otro límite. El documento de Flujo de trabajo Límites de ejecución duro de Historia de Eventos limita a 51,200 eventos o 50 MB, con advertencias en 10,240 eventos o 10 MB. No convierta esos valores datados en constantes universales; compruebe la documentación actual y su implementación. El patrón duradero es mantener los datos de conversación voluminosos fuera del historial de flujo de trabajo cuando sea apropiado, conservar las identidades e invariantes minimizadas por contenido, y usar Continuar como nuevo antes de que la presión del historial se convierta en una interrupción. Eso crea una división práctica del trabajo: Temporal preserva y reanuda el estado de orquestación. La aplicación de agente define hitos, espera propiedad, efecto reconciliación y verificaciones de aceptación. Una capa de salud frente al operador une ambos conjuntos de pruebas y muestra incertidumbre en lugar de inventar un veredicto. Mantenga la salud separada de la orquestación Para un agente Temporal AI, la ejecución duradera es la base, no el puntaje final de salud. La reproducción puede restaurar las decisiones grabadas después de un accidente. Los intentos de actividad pueden recuperar fallas transitorias. Las señales y las actualizaciones pueden llevar decisiones humanas. Ninguna de esas mecánicas debe extenderse a la afirmación de que el agente está progresando, que un efecto secundario ocurrió exactamente una vez, o que el resultado del usuario está presente. Comience con los cuatro recibos. Hacerlos pequeños, frescos y atados a workflowId , runId , y identidades de operación estables. Prueba los seis estados incómodos antes de la producción. Si su tablero no puede mostrar waiting , stuck , uncertain y false success por separado, está ocultando las decisiones que un operador realmente necesita tomar. La limitación es semántica: cada flujo de trabajo debe definir su propio hito significativo y control de entregabilidad. Un agente de verificación de origen y un agente de pago no pueden compartir el mismo predicado de aceptación. Cuando no exista una verificación determinista de los resultados, etiquete el juicio y su confianza; no lo convierta silenciosamente en hecho. Sidewisp se encuentra actualmente en versión preliminar privada. Su dirección de producto es una capa de salud de agente AI, pero un adaptador temporal de producción y colección de agente vivo de salud no se presentan aquí como capacidades enviadas. El movimiento útil a corto plazo es independiente de cualquier producto: mantener la evidencia de durabilidad de Temporal, agregar los cuatro recibos de solicitud y requerir que coincidan antes de llamar a un agente saludable.