Memoria del agente Pydantic AI: Auditar el historial antes de la reproducción

La memoria del agente Pydantic AI está lista para reproducirse solo cuando pasan seis comprobaciones independientes: los mensajes pasan de ida y vuelta a través del serializador compatible, el historial proviene de una fuente autorizada del lado del servidor, el mensaje requerido del sistema sobrevive, las llamadas a herramientas y los resultados permanecen operativamente honestos, cada mensaje pertenece a la conversación prevista y la aplicación tiene un recibo para el resultado esperado. Una carga útil JSON válida solo prueba la primera verificación. Esa distinción es importante porque Pydantic AI repara deliberadamente algunos historiales de proveedores no válidos. Una llamada de herramienta cancelada puede convertirse en una devolución interrumpida válida para el proveedor. Se puede eliminar el resultado de una herramienta huérfana. Esas reparaciones ayudan a que la solicitud del siguiente modelo tenga éxito, pero no prueban que la herramienta abandonada esté terminada ni que exista la entrega del usuario. Trate la serialización como la primera puerta, no como el veredicto Oficial de Pydantic Mensajes y documentación del historial de chat. recomienda ModelMessagesTypeAdapter para almacenar y cargar el historial de ModelMessage . Conserva los campos de mensaje que se ajustan al esquema del adaptador, mientras que un recorrido de ida y vuelta JSON normaliza los valores que no tienen representación nativa de JSON. Ese es el límite de persistencia correcto. No es una verificación del estado de la aplicación. Para que la diferencia sea mensurable, ejecuté siete historiales sin contenido en Pydantic AI 2.21.0. Cada historial se serializó con ModelMessagesTypeAdapter.dump json , se recargó con validate json , se normalizó y se utilizó hash. Luego, los casos pasaron por verificaciones separadas para verificar la pronta continuidad, el emparejamiento de herramientas, el alcance de la conversación, la confianza y un recibo de resultado proporcionado por la aplicación. Los siete viajes de ida y vuelta normalizados de JSON coincidieron. Sólo el caso de control estaba listo para reproducirse: Caso JSON ida y vuelta veredicto operativo Historial completo más recibo de resultados. Igual READY Falta el mensaje del sistema Igual SYSTEM PROMPT GAP Llamada de herramienta interrumpida Igual INTERRUPTED TOOL Resultado de herramienta huérfana Igual ORPHAN RESULT REMOVED ID de conversación mixtos Igual SCOPE DRIFT Respuesta modelo sin recibo de resultado Igual MISSING OUTCOME RECEIPT Historial proporcionado por el cliente Igual UNTRUSTED HISTORY El resultado no es un argumento en contra del adaptador. Muestra por qué un archivo con esquema válido y un estado de agente saludable son afirmaciones diferentes. El valor predeterminado razonable es conservar la salida exacta del adaptador, conservar un identificador de conversación estable y mantener un registro de resultados separado. No combine los mensajes en pares de contenido/función ad hoc si necesita metadatos de herramientas, límites de ejecución, indicaciones del sistema o anotaciones de aplicaciones para sobrevivir. Una ruta de persistencia mínima se ve así: Después de cargar, ejecute las otras puertas antes de pasar el resultado a message history . Auditar la continuidad del prompt y el alcance de la conversación. El contrato de historial de Pydantic AI contiene un valor predeterminado sutil: cuando message history no está vacío, el marco supone que el historial ya contiene un mensaje del sistema. No genera uno nuevo para esa ejecución. La documentación apunta a ReinjectSystemPrompt cuando una base de datos, una interfaz o una ruta de compactación no completan el mensaje. Eso significa que "los mensajes de usuario antiguos están presentes" es insuficiente. Un trabajo de persistencia puede retener cada turno de chat y aun así eliminar la instrucción que definió la autoridad del agente o el contrato de salida. Registre el contrato inmediato como un identificador no secreto, no como una copia de instrucciones confidenciales en un flujo de salud. Por ejemplo: En el momento de la reproducción, verifique que el historial cargado contenga la forma solicitada requerida por esa revisión. Si su aplicación utiliza intencionalmente instrucciones dinámicas en lugar de indicaciones persistentes del sistema, verifique ese contrato explícitamente en lugar de tratar la ausencia como automáticamente no saludable. La identidad de la conversación necesita su propia prueba. Los mensajes Pydantic AI actuales pueden transportar tanto run id como conversation id . Una nueva ejecución debe recibir un nuevo ID de ejecución, mientras que el ID de la conversación correlaciona los turnos. La fuente de la versión 2.21.0 documenta e implementa reglas de resolución separadas para los dos identificadores. Una puerta de repetición práctica debería rechazar o poner en cuarentena un historial cuando: aparece más de un ID de conversación no nulo sin una decisión de fusión explícita; el inquilino o usuario solicitado no es propietario de la conversación; el historial se cargó en un contexto de autorización y se reprodujo en otro; una persona que llama intenta reutilizar una ID de ejecución anterior como si fuera la clave de conversación; Se pretendía realizar una bifurcación, pero la aplicación conservó la identidad de la conversación original. Estas son decisiones de alcance. No se pueden recuperar del texto del mensaje de forma segura y un modelo no debería adjudicarlos. Inspeccionar el historial de herramientas reparadas sin considerarlo completo Los proveedores de modelos generalmente rechazan el resultado de una herramienta sin una llamada coincidente o una llamada cuyo resultado requerido nunca aparece. El comportamiento actual de limpieza del historial de Pydantic AI hace que el historial de herramientas ejecutado localmente sea válido para el proveedor antes de una solicitud. El fuente 2.21.0 fijada en la versión muestra el orden: 1. eliminar resultados de herramientas regulares huérfanos; 2. sintetizar resultados interrumpidos para llamadas de herramientas regulares pendientes cuando la reparación es apropiada; 3. fusionar mensajes consecutivos compatibles después de que el emparejamiento sea válido. Los retornos sintetizados están marcados en metadatos con pydantic ai synthesized tool return y utilizan el resultado neutral interrupted . En la repetición controlada, el caso interrumpido obtuvo una devolución marcada. El caso huérfano perdió su inigualable retorno. Ambas historias resultantes fueron más fáciles de aceptar para el proveedor. Ninguno de los dos se convirtió en evidencia de que se hubiera producido el efecto externo de la herramienta. Utilice el marcador como señal de incidente: No reintente automáticamente cada llamada interrumpida. Un tiempo de espera puede ocurrir después de un efecto externo irreversible pero antes de que su resultado llegue a la historia. El siguiente paso limitado es consultar el destino con una clave de idempotencia segura o un identificador comercial. Vuelva a intentarlo solo cuando el destino demuestre que el efecto está ausente y que sea seguro repetir la operación. La eliminación de huérfanos también merece un recibo. Si un historial cargado contenía un resultado que la limpieza eliminó posteriormente, conserve un evento de auditoría sin contenido con el ID de la conversación, el ID de llamada de la herramienta con hash, el tiempo observado y la clase de reparación. No conserve los argumentos o resultados sin procesar de la herramienta a menos que el incidente realmente los requiera. El experimento utilizó el símbolo privado clean message history de Pydantic AI para reproducir exactamente la tubería documentada. Esa importación es apropiada para un dispositivo de diagnóstico fijado, no para el código de la aplicación. Los API privados pueden cambiar sin garantías de compatibilidad. Las comprobaciones de producción deben utilizar tipos de mensajes admitidos, metadatos documentados, recibos de aplicaciones y pruebas vinculadas a la versión que se está implementando. Mantenga el historial del cliente fuera del límite de autoridad La documentación de Pydantic es explícita sobre el historial proporcionado por el cliente: las superficies de los agentes del lado del servidor no tienen estado, por lo que un cliente que puede enviar el historial puede fabricar llamadas a herramientas, resultados de herramientas, indicaciones del sistema o aprobaciones. sanitize messages delimita varias formas inseguras, pero la desinfección no establece que el historial enviado sea verdadero. Trate la posesión de una transcripción JSON y la autoridad para reanudar el trabajo como hechos separados. El servidor debe autenticar a la persona que llama, autorizar la conversación, construir el conjunto de herramientas permitido a partir de la identidad del lado del servidor y revalidar los efectos de alto riesgo dentro de la función de la herramienta. Si una ejecución pausada es importante, consérvela en el servidor y reanúdela desde el estado de propiedad del servidor. No acepte la afirmación de un navegador de que se produjo una aprobación simplemente porque un mensaje con forma de aprobación lo valida. Este es un límite de confianza documentado, no un informe de vulnerabilidad. La falla operativa es una aplicación que trata un historial que no es de confianza como un registro de autoridad. Una regla de precedencia compacta evita que una verificación plausible de nivel inferior oculte una falla más importante: El orden es deliberado. No tiene ningún valor diagnosticar una entrega faltante a partir de un historial que la persona que llama nunca pudo reanudar. Requerir un recibo de resultados después de que pase el historial La puerta final pertenece a la aplicación, no al marco del historial del modelo. Defina el efecto esperado antes de la ejecución. Para un agente de codificación, podría ser una confirmación que contenga un cambio específico además de pasar pruebas. Para un agente de soporte, podría ser una actualización del ticket visible a través del ticket API. Para un informe programado, podría ser un objeto inmutable en el destino esperado con el intervalo de informe correcto. Almacene un recibo de contenido minimizado: El recibo debe provenir de la lectura determinista más sólida disponible. Un modelo que dice "hecho" es evidencia de actividad. Una devolución de herramienta que diga "aceptado" es evidencia de transporte. Una nueva lectura de destino que muestre la revisión prevista es la prueba del resultado. Esto también maneja la espera legítima. Si el agente está en pausa para la aprobación humana, el estado correcto no es MISSING OUTCOME RECEIPT ; es un registro de espera con propietario, decisión necesaria, fecha límite y token de currículum. Solo clasifique la ejecución como bloqueada cuando la ventana de progreso esperado se cierre sin una espera o un resultado válido. La repetición de siete casos tiene un límite estrecho: prueba estados de falla del historial de mensajes seleccionados bajo Pydantic AI 2.21.0, no todos los proveedores, herramientas integradas, adaptadores de interfaz de usuario o productos de memoria a largo plazo. Vuelva a ejecutar el dispositivo cuando actualice el marco, cambie la serialización, agregue un adaptador de interfaz o modifique la ejecución de la herramienta. El modelo de salud previsto por Sidewisp incluye persistencia del contexto, accesibilidad de herramientas, progreso útil y verificación de resultados. Sidewisp se encuentra actualmente en versión preliminar privada. La recopilación de estado del agente de producción y un adaptador Pydantic AI generalmente no se envían, por lo que esta guía es una regla operativa independiente en lugar de una afirmación de que Sidewisp ya realiza la auditoría. Por lo tanto, la decisión de repetición es sencilla: use ModelMessagesTypeAdapter para mayor durabilidad, luego requiera autoridad, continuidad del prompt, emparejamiento honesto de herramientas, alcance de la conversación y un recibo de resultado externo. El historial válido del proveedor es una prueba útil. No es lo mismo que un agente sano.