Observabilidad del agente AI para el tiempo de ejecución de las herramientas: verifique el efecto

Un tiempo de espera de la herramienta le dice que el que llamó dejó de esperar. ¿ Znot le dice si la herramienta realizó su efecto secundario? Para un agente de AI que puede enviar un mensaje, crear un boleto, reservar una ranura o cobrar una cuenta, tratar a timeout como failed puede convertir una falla ordinaria de la red en una acción duplicada en el mundo real. El defecto razonable es congelar los retos ciegos, mantener una identidad de operación estable y reconciliar el efecto previsto. Aceptar una de las tres respuestas: verificada aplicada, verificada no aplicada o indeterminada. Sólo la segunda respuesta puede introducir una decisión de retoma, y incluso entonces el contrato de proveedor debe apoyar una retoma con la misma identidad y los mismos parámetros inalterados. Este es un problema de observabilidad porque un veredicto saludable depende de la evidencia más allá del lapso de llamadas de la herramienta. El agente necesita un recibo por lo que pretendía, qué transporte devolvió, y lo que el sistema externo ahora contiene. Un tiempo fuera deja tres hechos diferentes Un agente suele registrar un hecho conveniente: la llamada a la herramienta aumentó un tiempo de espera. El expediente operativo útil tiene tres capas: 1. Intent la operación lógica exacta que el agente se comprometió a realizar. 2. Transport si el solicitante recibió una respuesta, rechazo o ninguna respuesta. 3. Effect si el sistema objetivo contiene el resultado previsto, no contiene ningún resultado o no se puede consultar con confianza. Esas capas pueden estar en desacuerdo. Una solicitud puede llegar al proveedor, crear el objeto y perder la respuesta en el camino de regreso. Puede fallar antes del envío. Puede devolver el éxito mientras que un paso sincrónico en el río abajo nunca produce el resultado prometido. Ninguno de esos casos se describe bien por un solo campo success: true false . El documentación avanzada de manejo de errores de Stripe hace explícita la ambigüedad: después de un error de red, el cliente no sabe si el servidor recibió la solicitud. Su recorrido recomendado reutiliza la misma clave de idempotencia y los mismos parámetros hasta que el cliente reciba un resultado definitivo. La misma página trata una respuesta de 500 como indeterminada porque una solicitud aún puede producir un efecto secundario visible para el usuario. AWS documenta una frontera relacionada en su Orientación de ejecución duradera. La repetición al menos una vez es segura para las operaciones impotentes; los efectos secundarios externos requieren una manipulación o un contrato de impotencia del lado del servicio. AWS también advierte que ninguna semántica por intento significa exactamente una vez para todo el flujo de trabajo. La conclusión práctica es más estrecha que add retries. Decidir primero si la operación es segura de repetir. Una lectura, un upsert con clave de un registro estable ID, y una llamada de proveedor con una clave de idempotencia documentada son diferentes al envío de una notificación de una sola toma a través de una API que no tiene contrato de deduplicación. Registrar un recibo de efecto antes de agregar retrasos Un recibo de efecto es un pequeño registro local creado antes del envío de . La respuesta del proveedor no es la única. Se correlaciona la intención cometida con pruebas posteriores: operation id identifica la acción lógica a través de los reinicios del proceso. request hash impide que un agente reutilice esa identidad para los parámetros cambiados. La clave de idempotency es separada porque no todos los proveedores la admiten, y los proveedores definen diferentes ventanas de retención y comportamiento de repetición. La sonda describe cómo se verificó el efecto; un punto final de la lista almacenada en caché es una evidencia más débil que una lectura directa por una referencia externa única. No almacenes secretos, cuerpos de correo, contenido de mensajes o argumentos completos de herramientas en este registro. Hash una intención canónica, redactada y retener sólo los campos necesarios para reconciliar el efecto. Si el proveedor acepta metadatos del cliente, adjunta el ID de operación estable allí para que una conexión web o lectura posterior pueda correlacionar un objeto incluso cuando la respuesta original desaparezca. El veredicto debe usar pruebas explícitas. El veredicto Pruebas La siguiente acción verified applied Un efecto de coincidencia o un recibo de proveedor de reproducción confiable No vuelva a intentarlo; continúe con la verificación de resultados verified not applied Una consulta autorizada demuestra cero efectos de coincidencia Consulte el contrato de proveedor antes de una nueva prueba limitada indeterminate La respuesta falta y no hay una verificación de efecto autorizada disponible. Esperad, reconciliad, o consultad a un hombre. No inventéis la certeza. duplicate effect Existen más de un efecto de coincidencia Detener los intentos de repetición y entrar en un camino de reparación de compensación o humana false success El transporte regresó con éxito pero el efecto prometido está ausente Tratar la carrera como insalubre aunque el comando se haya completado unsafe retry La misma intención se volvió a intentar bajo una nueva clave o cambió el hash de la solicitud Detener; el límite de deduplicación se ha roto Esta tabla separa la actividad del progreso útil. Otro intento es la actividad. Un solo efecto confirmado es el progreso. Una ventana legítima de reconciliación está esperando, mientras que las llaves nuevas repetidas sin recibo estable es una ejecución insegura. Ejecutar el clasificador de seis casos Construí un dispositivo NDJSON de seis casos para probar la regla. Incluye una respuesta perdida con un recibo del proveedor correspondiente, un tiempo de espera con evidencia no disponible, un proveedor que crea dos efectos a pesar de una clave repetida, una respuesta de éxito sin objeto resultante, un resultado de efecto cero autorizado y un retiro con clave cambiada. El clasificador central es deliberadamente pequeño: El sistema se resuelve a un caso en cada estado: Las seis afirmaciones esperadas pasan. El resultado más importante es la segunda línea, no el camino feliz: un tiempo sin un camino de lectura autorizado sigue siendo indeterminate . Un nuevo intento haría que el tablero estuviera más ocupado mientras que el estado del mundo real sería más difícil de recuperar. El dispositivo también atrapa un atajo tentador. Un recibo del proveedor es útil sólo cuando se une al hash de la solicitud original. Un recibo por una carga útil diferente no puede probar que el efecto previsto ocurrió. Del mismo modo, un transportador 200 no es la verificación de resultados; el caso ack without deliverable es false success porque el objeto externo está ausente. En la producción, ejecutar la reconciliación en un horario limitado. Busque por la clave de ID de operación estable o de idempotencia del proveedor, registre la actualidad de la evidencia y detenga después de un plazo fijo. Si el resultado permanece indefinido, dirija la decisión a alguien con autoridad sobre el sistema afectado. No permita que una política genérica retry de hasta tres veces cruce el límite de efectos secundarios. Cuando el contrato cese Un recibo de efecto reduce la ambigüedad; no crea una garantía de una sola vez. El proveedor puede caducar las claves de idempotencia, ignorarlas en algunos puntos finales, aceptar una solicitud antes de un fallo asincrónico interno o exponer un modelo de lectura que se queda atrás de la escritura. Una sonda también puede estar equivocada debido al almacenamiento en caché, permisos parciales o una búsqueda no única. Ponga esos límites al lado del veredicto: conservar la ventana y el ámbito de aplicación documentados del proveedor; utilizar la misma clave and la misma solicitud canónica durante una nueva prueba permitida; la confianza y la frescura de las sondas de etiquetado; distinguir un cero autorizado de no visible todavía; tiempo máximo de reconciliación y recuento de ensayos de nuevo; requerir la aprobación humana para acciones compensatorias o irreversibles; verificar el resultado previsto por el usuario después de que se confirme el efecto. Este patrón es especialmente valioso para los agentes de larga duración porque la recuperación del proceso a menudo pierde la respuesta de transporte mientras continúa el trabajo externo. Persistir en el recibo antes del envío le da a un agente reiniciado un lugar estable para reanudar la investigación. Debe reanudarse desde indeterminate , no desde probablemente fallido. Para la observabilidad del agente AI, la regla de funcionamiento es simple: un tiempo de espera es una observación de transporte, no un veredicto de efecto. Preservar la identidad de una operación, correlacionar el proveedor y la evidencia del lado de lectura, y negarse a llamar saludable la carrera hasta que se verifique el resultado externo previsto. La dirección del producto de Sidewisp incluye la salud de los resultados, las fallas de las herramientas, los retos, la evidencia y los límites de aprobación humana. Este artículo describe un patrón de funcionamiento, no un monitor enviado. Sidewisp se encuentra actualmente en versión preliminar privada. Generalmente no se envían recogidas de agentes de producción, adaptadores de tiempo de ejecución, monitoreo de recepción de efectos y recuperación. El sitio público y la biblioteca de artículos están en vivo, y los lectores pueden unirse al acceso temprano sin otorgar autoridad a Sidewisp sobre sus agentes.