¿Cómo conserva el abastecimiento de eventos un registro de auditoría de las decisiones de los agentes de IA?
El abastecimiento de eventos conserva un registro de auditoría de los agentes de IA al registrar cada decisión aceptada y cada cambio de estado como un evento ordenado, en lugar de sobrescribir un único estado actual mutable.
En un servidor doméstico, esto hace que la automatización de varios pasos pueda reconstruirse: un operador puede rastrear la propuesta, la aprobación, la llamada a la herramienta, el fallo, el reintento, la compensación y el estado final una vez terminado el flujo de trabajo.
El abastecimiento de eventos almacena los cambios de estado como registro principal
El abastecimiento de eventos registra cada cambio de estado aceptado como un evento, en lugar de tratar la última fila mutable como la única fuente de verdad. El estado actual se deriva del historial ordenado.
Martin Fowler define el abastecimiento de eventos como el almacenamiento de cada cambio en el estado de una aplicación en forma de una secuencia de eventos. El historial conserva cómo llegó el sistema a un estado. Martin Fowler define el abastecimiento de eventos a partir del almacenamiento de los cambios de estado como una secuencia de eventos, lo que refleja la idea de registro principal utilizada en Martin Fowler sobre el abastecimiento de eventos.
Para un agente de IA doméstico, ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed y CompensationCompleted pueden permanecer como hechos independientes, en lugar de comprimirse en un único campo de estado.
Cada decisión del agente se convierte en un hecho ordenado por tiempo
Un evento debe describir algo que ya ocurrió y contener suficiente contexto para interpretarlo posteriormente: ID del flujo de trabajo, herramienta, hash de los parámetros, resultado de la política, resultado de la decisión y marcas de tiempo cuando corresponda.
Fowler señala que, con el abastecimiento de eventos, el almacén de eventos se convierte en la principal fuente de verdad y el estado puede reconstruirse mediante reproducción. Esa secuencia ordenada crea una ruta de auditoría causal. Microsoft Azure describe un almacén de eventos de solo anexado en el que los eventos representan cambios en el estado de la aplicación, lo que respalda los hechos de decisión ordenados por tiempo en el patrón de abastecimiento de eventos de Azure.
El objeto de auditoría útil es el artefacto observable de la decisión, no el razonamiento oculto privado: qué acción se propuso, qué política la evaluó, qué resultado se obtuvo y qué efecto secundario ocurrió realmente.
Las proyecciones convierten el registro de eventos en vistas actuales
Reproducir todo el historial para cada pantalla o solicitud del agente sería ineficiente.
Los sistemas basados en eventos crean proyecciones como el estado actual del flujo de trabajo, las aprobaciones pendientes o los fallos recientes.
El abastecimiento de eventos puede reconstruir el estado actual de la aplicación a partir de los eventos registrados. Por tanto, una proyección puede reconstruirse si cambia su lógica o su base de datos. La orientación de AWS describe cómo derivar el estado actual a partir de eventos persistidos, e ilustra cómo las proyecciones pueden crear vistas de lectura sin reemplazar el historial subyacente en la orientación de AWS sobre el abastecimiento de eventos.
En un servidor pequeño, las instantáneas pueden acortar el tiempo de reproducción mientras los eventos siguen siendo la fuente autoritativa. La instantánea es un atajo de rendimiento; la secuencia de eventos es el historial.
Los ID de correlación vinculan el trabajo de varios pasos en un único historial de decisiones
Una solicitud puede activar la recuperación de información, la planificación, la aprobación, varias llamadas a herramientas, reintentos y compensaciones.
Un ID de correlación agrupa esos eventos en una operación coherente.
Esto es distinto de simplemente almacenar los registros en otro lugar. El aislamiento externo de los registros de auditoría de ZimaSpace explica cómo las pruebas sobreviven al compromiso de la aplicación; el abastecimiento de eventos explica cómo el propio estado del flujo de trabajo se convierte en un historial ordenado. Kurrent hace hincapié en los flujos de eventos ordenados y los identificadores, lo que permite correlacionar pasos relacionados en un único historial de decisiones rastreable en los conceptos de abastecimiento de eventos de Kurrent.
Ambos enfoques pueden combinarse: los registros de eventos impulsan la reproducción operativa, mientras que copias orientadas al anexado se exportan a un límite de registro independiente para conservar mejor las pruebas.
Las correcciones añaden nuevos eventos en lugar de reescribir el historial
Si posteriormente se descubre que una decisión del agente era incorrecta, un diseño basado en eventos registra un evento compensatorio o correctivo, en lugar de editar el evento original hasta hacerlo desaparecer.
La discusión de Fowler sobre la bitemporalidad ilustra la idea más amplia de que el historial de los registros puede mantenerse como solo anexado incluso cuando nuevos conocimientos corrigen suposiciones anteriores. Marten conserva los eventos como un historial de solo anexado y reconstruye el estado del agregado a partir de ellos, lo que ilustra por qué las correcciones pueden añadirse en lugar de reescribir silenciosamente hechos anteriores en la documentación del almacén de eventos de Marten.
Esto resulta útil cuando cambian las políticas o las instrucciones. Un operador puede ver que una acción se aceptó conforme a una versión de la política y posteriormente se revirtió, en lugar de ver únicamente el estado final corregido.
El abastecimiento de eventos no hace que las pruebas sean automáticamente a prueba de manipulaciones
Un historial de eventos solo es tan fiable como los controles que rodean la creación, el almacenamiento, el acceso, los relojes y la eliminación de eventos.
Un proceso al que se permita reescribir el almacén aún puede destruir su propio historial.
Fowler destaca las ventajas para la auditoría y las consultas históricas cuando el registro de eventos sigue siendo el almacén de información autoritativo. La durabilidad y los controles de anexado siguen siendo cuestiones operativas independientes. Investigaciones recientes aplican historiales de eventos estructurados y de solo anexado a la actividad de agentes autónomos, pero también dejan claro que la lógica de aplicación de solo anexado no equivale a un almacenamiento a prueba de manipulaciones; consulta el abastecimiento de eventos para agentes autónomos.
El diseño de agentes que prioriza las herramientas de solo lectura de ZimaSpace reduce las acciones peligrosas antes de que ocurran; el abastecimiento de eventos conserva las decisiones y acciones que realmente tuvieron lugar.
Productos recomendados
Centro de Tecnología e IA
Más para leer
Estado de ejecución frente a estado persistente en Home Assistant: ¿qué debe sobrevivir al reinicio?
Home Assistant no conserva todos los valores en tiempo real; la configuración, los registros, los estados restaurados seleccionados, el historial y los datos de...
¿Cómo autentica Home Assistant las sesiones locales y remotas?
Las sesiones locales y remotas de Home Assistant utilizan el mismo modelo de identidad del servidor; el acceso remoto cambia la ruta y el...
¿Por qué pueden volverse lentas las consultas del historial de Home Assistant a medida que crecen los datos del grabador?
El crecimiento del grabador puede aumentar el costo de las consultas del historial cuando el rango solicitado abarca más filas, aumentan los fallos de...
