Resumen Técnico: Continuación de la Ejecución en Tiempo de Ejecución tras Fallos en Flujos de Trabajo de Agentes Parcialmente Ejecutados

1. Planteamiento del Problema

Los agentes de Modelos de Lenguaje Extensos (LLM) interactúan cada vez más con el mundo modificando estados externos duraderos mediante herramientas (por ejemplo, editando archivos, actualizando bases de datos, enviando mensajes). Cuando ocurre un fallo después de que se ha materializado un efecto, ya sea debido a un error del modelo, un fallo de la herramienta o una inyección de prompts maliciosa, los mecanismos de recuperación estándar enfrentan una brecha semántica crítica.

Los enfoques existentes suelen abordar partes del ciclo de vida: la autorización en tiempo de ejecución decide si un efecto propuesto puede ejecutarse; el diagnóstico y la replanificación sugieren qué intentar a continuación; y los sistemas de procedencia registran qué sucedió. Sin embargo, ninguno de estos mecanismos por sí solo define cómo una ejecución parcialmente ejecutada debe reingresar de forma segura a su estado de tarea canónico. Específicamente, tras un fallo, no está claro:

1. ¿Qué prefijo de ejecución sigue siendo digno de confianza?
2. ¿Qué obligaciones obligatorias siguen abiertas?
3. ¿Qué evidencia se requiere para justificar el progreso ulterior sin repetir operaciones irreversibles o aceptar supuestos inválidos?

Replay (reproducir) una trayectoria conlleva el riesgo de repetir efectos secundarios irreversibles, mientras que continuar desde el último mensaje del modelo conlleva el riesgo de arrastrar supuestos inválidos. El artículo identifica la unidad semántica faltante como la transición post-fallo desde un estado de ejecución confiable hacia el siguiente estado de tarea admisible.

2. Metodología: AgentMirror

Los autores instancian un mecanismo de tiempo de ejecución llamado AgentMirror para resolver el problema de la continuación post-fallo. La filosofía central es tratar la recuperación no como otra propuesta del modelo, sino como una transición de estado restringida sobre un historial de ejecución autenticado.

2.1 Conceptos Centrales

• Frontera Confiable ($F$): Un compromiso autenticado en tiempo de ejecución de un prefijo ejecutado. Se reconstruye a partir de un libro de contabilidad de eventos comprometidos, no es seleccionado por el modelo. Representa el punto "seguro" hasta el cual el sistema confía en el historial.
• Obligaciones Residuales: Derivadas de un contrato de tarea canónico ($K$), estas son las obligaciones obligatorias que permanecen después de la frontera confiable. El contrato define dependencias, objetivos y la evidencia esperada.
• Contexto de Recuperación ($C_F$): Una proyección del estado confiable (frontera, obligaciones abiertas, eventos invalidados, presupuesto) proporcionada al modelo de caja negra. Crucialmente, este contexto es no-autorizador; guía la generación de propuestas pero no otorga permiso para ejecutar.
• Recibos de Tiempo de Ejecución ($\rho$): Evidencia autoritativa emitida después de la ejecución. Un recibo solo es válido si es fresco, está vinculado a la frontera/ejecución actual y coincide de forma única con una obligación abierta.

2.2 El Ciclo de Vida de la Transición

El mecanismo impone una separación estricta de responsabilidades a través de cuatro etapas (ilustradas en la Figura 1 del artículo):

1. Propuesta: La integración externa presenta una acción candidata normalizada ($a$) basada en el contexto de recuperación.
2. Admisión Ordinaria: El candidato debe pasar las comprobaciones de autorización estándar ($Auth$) antes de la ejecución. El contexto de recuperación no elude esto.
3. Ejecución y Evidencia: La herramienta ejecuta el efecto. Si tiene éxito, un emisor confiable produce un recibo ($\rho$).
4. Actualización del Estado Canónico: El componente de transición actualiza el estado canónico ($S$) solo si:
   • El recibo es válido, fresco y está vinculado a la frontera actual.
   • El recibo coincide de forma única con exactamente una obligación abierta (Comprobación de Instancia Única/Singleton Check).
   • Todos los predecesores de esa obligación han sido satisfechos.

Si alguna condición falla (por ejemplo, el recibo es obsoleto, coincide con múltiples obligaciones o es de una frontera diferente), el sistema toma la rama de identidad: el estado canónico permanece sin cambios. Esto evita la "progresión inválida" incluso si ocurrió un efecto externo; el sistema simplemente no lo reconoce como un paso válido en la tarea canónica.

2.3 Garantías Formales

El artículo formaliza el ciclo de vida como una relación de transición. Demuestra que, bajo el supuesto de un contrato confiable y componentes de tiempo de ejecución confiables (libro de contabilidad, emisor, admisión), el sistema garantiza:

• Progresión Admisible: El estado avanza solo si el efecto fue autorizado, materializado y respaldado por evidencia fresca y vinculada.
• No Sustituibilidad: Las condiciones (admisión, evidencia de ejecución, validez del recibo, vinculación a la frontera, coincidencia de instancia única) son distintas. Eliminar cualquiera de estas condiciones admite una clase específica de progresión inválida (por ejemplo, eliminar la vinculación a la frontera permite evidencia de distintos prefijos; eliminar la coincidencia de instancia única permite cierres ambiguos).

3. Contribuciones Principales

El artículo realiza tres contribuciones primarias:

1. Semántica de Transición de Estado Post-Fallo: Un modelo formal centrado en una frontera establecida en tiempo de ejecución, obligaciones residuales, contexto de recuperación no-autorizador y progresión basada en evidencia.
2. Separación de Preocupaciones Tipada: Una distinción clara entre guía (contexto de recuperación), autoridad (admisión), evidencia de ejecución (recibos) y corrección de la tarea. El artículo proporciona "testigos de eliminación de condiciones" demostrando por qué estas condiciones no pueden sustituirse entre sí.
3. Mapeo de Tiempo de Ejecución y Alcance de Evaluación: Un marco para evaluar flujos de trabajo de agentes de caja negra que separa la utilidad de la tarea, el éxito del ataque, la utilidad segura y las transiciones inválidas. Define métricas específicas para RQ1 (Seguridad/Utilidad), RQ2 (Generalidad) y RQ3 (Atribución de Condiciones).

4. Alcance de la Evaluación y Resultados

El artículo describe una estrategia de evaluación utilizando el benchmark AgentDojo, que proporciona entornos de herramientas con estado y oráculos de tareas externos.

• RQ1 (Efectividad de la Recuperación Segura Global): Mide si AgentMirror recupera las tareas sin efectos no autorizados y si mejora las tasas de finalización en comparación con líneas base como "Sin Recuperación" o "Reintento Básico". Las métricas incluyen Utilidad, Tasa de Éxito de Ataque (ASR) y Utilidad Segura.
• RQ2 (Generalidad): Prueba la efectividad en diferentes aplicaciones de AgentDojo, familias de fallos y modelos de caja negra. Evalúa si el mecanismo sigue siendo efectivo independientemente del modelo específico o del adaptador de proveedor utilizado debajo del límite de la propuesta normalizada.
• RQ3 (Atribución de Condiciones): Utiliza estudios de ablación para eliminar condiciones específicas de transición o propiedad (por ejemplo, eliminar la admisión ordinaria, debilitar la frescura del recibo). El objetivo es mostrar que cada condición eliminada admite una clase distinta de progresión inválida, validando la necesidad del conjunto completo de restricciones.

Nota: El artículo presenta la metodología y el diseño de la evaluación, pero no reporta resultados numéricos específicos (por ejemplo, "95% de tasa de éxito") en el texto proporcionado. El enfoque está en la corrección semántica y las garantías teóricas del modelo de transición.

5. Significancia y Reivindicaciones

El artículo afirma abordar una "transición faltante" en la literatura de seguridad de agentes. Mientras que los trabajos previos cubren controles pre-fallo, monitoreo in-fallo o registros post-efecto, AgentMirror especifica la transición relativa al contrato que los conecta tras una ejecución parcial.

• Garantía Relativa al Contrato: El sistema garantiza la consistencia interna relativa al contrato de la tarea. No pretende la corrección global de la tarea si el propio contrato es defectuoso (por ejemplo, si omite una obligación), pero asegura que el estado de tiempo de ejecución avance solo cuando se cumplen los requisitos de evidencia del contrato.
• Defensa contra la Confusión de Autoridad: Una contribución clave es evitar que los "metadatos de recuperación" se confundan con "autoridad de ejecución". El contexto de recuperación guía al modelo pero no puede emitir credenciales ni eludir la admisión.
• Modestia sobre las Limitaciones: Los autores son explícitos sobre las limitaciones:
  • La garantía es relativa a un contrato confiable; un contrato erróneo conduce a un estado de tarea consistente pero incorrecto.
  • No existe una garantía de vitalidad (liveness) incondicional; si ninguna propuesta pasa la admisión o coincide con una obligación, el sistema detiene el progreso.
  • No maneja efectos externos irreversibles que carezcan de mecanismos de idempotencia o compensación fuera de la transición canónica.
  • El parsing de los proveedores y la corrección de los adaptadores siguen siendo preocupaciones externas.

En resumen, AgentMirror proporciona un marco semántico riguroso para reanudar flujos de trabajo de agentes de caja negra tras fallos, asegurando que la progresión del estado sea impulsada por evidencia autenticada y un estricto cumplimiento del contrato, en lugar de la confianza del modelo o planes de recuperación no verificados.