Agent Replay Runtime
Ejecución durable de herramientas con registro de eventos, claves de idempotencia y recuperación tras interrupciones reales del proceso. Incluye trazas de efectos y casos sin reintento automático.
Problema y utilidad para agentes
Una herramienta puede confirmar un efecto justo antes de que muera el proceso que la llamó. Reintentar a ciegas puede duplicarlo. El runtime registra la solicitud antes de ejecutarla y conserva el resultado antes de avanzar.
Permite separar las decisiones de un agente de la recuperación de sus acciones. Recibe un plan JSON finito, reconstruye el estado desde eventos y distingue una operación completada de una operación cuyo resultado sigue siendo incierto.
Arquitectura
- Plan y adaptadores fijados. El plan declara pasos únicos, argumentos JSON, identidad de cada adaptador y soporte de idempotencia. Reutilizar un identificador con un plan o adaptador distinto produce un rechazo.
- Registro durable. SQLite con WAL y synchronous FULL guarda cada transición. Un bloqueo de archivo mantenido por el proceso permite un solo escritor por base. El replay valida el historial sin invocar herramientas.
- Efectos separados. Un segundo almacén SQLite representa la herramienta. Su operación idempotente guarda el efecto y el recibo en una misma transacción; la operación de control no deduplica.
- Recuperación según contrato. Una solicitud pendiente conserva su clave. El adaptador idempotente puede recibirla otra vez. Sin ese contrato, la ejecución se detiene y exige una conciliación respaldada por evidencia externa.
Qué demuestra
- Modelado de estados y recuperación de acciones mediante un historial de eventos validado.
- Separación entre el registro del agente, el efecto externo y el contrato de idempotencia de la herramienta.
- Reproducción de la ventana entre efecto y confirmación, con trazas de procesos interrumpidos y un control que duplica el efecto.
Resultados publicados
El informe publicado por el autor contiene seis interrupciones fijas: tres puntos de corte por cada tipo de adaptador. Incluye un control sin interrupción y una referencia que reintenta sin deduplicar.
El proceso padre espera una señal de checkpoint y termina al hijo. Luego arranca un trabajador nuevo y consulta el almacén de efectos independiente. En el registro local se usó SIGKILL, Python 3.11.13, SQLite 3.50.4 y un Intel Xeon W-3223 con 48 GiB de RAM. Los trabajadores se ejecutaron en serie.
Efectos después de la recuperación
| Caso | Efectos finales | Resultado |
|---|---|---|
| Idempotente: después de solicitud | 1 | Reanudado con la misma clave |
| Idempotente: después de efecto | 1 | Recibo existente recuperado |
| Idempotente: después de confirmación | 1 | Resultado guardado reconstruido |
| Sin idempotencia: después de solicitud | 0 | Detenido, sin resolver |
| Sin idempotencia: después de efecto | 1 | Detenido y conciliado con el ledger |
| Sin idempotencia: después de confirmación | 1 | Resultado guardado reconstruido |
| Referencia: reintento a ciegas | 2 | Efecto duplicado |
| Control sin interrupción | 1 | Completado |
Los tres casos idempotentes terminaron con un solo efecto. El caso no idempotente interrumpido antes del efecto quedó pendiente con cero efectos: detenerse fue el resultado esperado. Esto no establece una garantía universal de exactly-once ni una tasa estadística de fiabilidad.
La conciliación del caso posterior al efecto se hizo mediante inspección automatizada del ledger de la prueba. No fue una revisión humana. El informe conserva eventos anteriores y posteriores, recibos, códigos de terminación y hashes del código. Matriz de interrupciones y trazas.
Reproducir
Python 3.11 o posterior, sin dependencias de ejecución, modelos, credenciales ni APIs pagas. El informe enlazado usa Python 3.11.13.
El primer comando comprueba la evidencia guardada. La segunda ejecución crea una matriz nueva terminando procesos propios. Sus rutas temporales, fechas y códigos de terminación pueden variar por plataforma. Los archivos de salida contienen solo fixtures sintéticos.
Verificar el informe guardado
git clone https://github.com/lucioduran/agent-replay-runtime.git
cd agent-replay-runtime
git checkout 8dbc49ef4b154cc738698714749ad133fa2c6855
python -m experiments.verify results/crash-matrix.jsonReproducir las interrupciones
python -m experiments.reproduce --output work/crash-matrix.json
python -m experiments.verify work/crash-matrix.jsonAlcance y límites
- La deduplicación depende de que la herramienta guarde atómicamente clave, efecto y recibo, y conserve ese recibo. Declarar idempotent no verifica ese contrato.
- Se probaron interrupciones de procesos locales. No cortes de energía, particiones de red, proveedores remotos, vencimiento de recibos ni restauraciones divergentes de bases.
- El plan es secuencial y finito. No hay planificación con modelos, bifurcaciones dinámicas, compensación, backoff ni coordinación entre hosts.
- Una herramienta colgada bloquea el escritor. El historial no tiene límite y la validación repetida puede volver cuadrático el trabajo en ejecuciones largas. No se midió throughput.
- La cadena de hashes detecta cambios accidentales, no reescrituras maliciosas. Una conciliación registra la afirmación del operador; el runtime no puede comprobar la verdad del sistema externo.
Fuentes y revisión
Los valores de esta ficha provienen del informe enlazado. No son una medición en vivo. El informe conserva la revisión ejecutada; la revisión consultada incluye la publicación posterior de ese informe.
- Revisión consultada:
8dbc49ef4b154cc738698714749ad133fa2c6855 - Revisión registrada por el experimento:
753a57995f6eb8a89659bed5d06acfd4d167f847 - Fecha del informe (UTC):
- Código del runtime SHA-256:
f1ad8eaaaa0a6f907c187b7b7c626a5cda99baba90f170a7d2e01425d206a1e7