Verifica archivos de oficina de agentes con un arnés de ida y vuelta de LibreOffice

Un agente devuelve un .docx, .xlsx o .pptx, y el modelo se detiene. El archivo aún debe abrirse, convertirse, editarse y preservar su contenido. Una pila de oficina local te ofrece una superficie repetible para esa verificación.

La caché codex-primary-runtime de la aplicación de escritorio OpenAI Codex contiene 1.7GB de componentes locales, incluidos binarios nativos de LibreOffice, una instalación de Python y una instalación de Node.js. El runtime de Codex incluye una carpeta de complementos de documentos con habilidades que instruyen a Codex sobre cómo localizar y usar los binarios incluidos. Ese diseño convierte la automatización de documentos en un pipeline que puedes inspeccionar.

OpenAI lanzó una versión de vista previa de la aplicación de escritorio ChatGPT para Linux que proporciona acceso a ChatGPT, ChatGPT Work y Codex. La vista previa para Linux describe ChatGPT Work como un modo para tareas extendidas, incluida la creación de documentos, hojas de cálculo, presentaciones e informes. ZDNET describe la aplicación de escritorio ChatGPT actualizada como la aplicación Codex con un modo ChatGPT Work.

La función de anotaciones de Codex de OpenAI se extiende a documentos, hojas de cálculo y diapositivas creados por el usuario, permitiendo seleccionar una porción y solicitar cambios. Si un usuario puede señalar una tabla y pedir una corrección, el archivo debe sobrevivir a esa corrección.

Una pila de oficina integrada convierte la salida en una superficie de prueba

Los modelos pueden producir archivos plausibles sin preservar las reglas internas que usan las aplicaciones de oficina: las tablas pueden perder sus cuadrículas, las fórmulas pueden almacenar referencias rotas y las diapositivas pueden romper los diseños.

La ida y vuelta obliga a que el archivo sea leído por un proceso diferente. Ese proceso no sabe qué pretendía el modelo. Solo sabe qué contiene el archivo. Ese es el estándar correcto para un artefacto compartido.

Usa la pila de oficina integrada para abrir, convertir y reguardar formatos de oficina comunes. Te da un segundo escritor que no produjo el archivo original. Si el archivo está malformado, el segundo escritor lo mostrará.

No confíes en la confianza del modelo. Un archivo generado puede parecer completo y aun así fallar cuando otra aplicación lo lee.

Ejecuta la ida y vuelta antes de confiar en el artefacto

Usa un arnés de ida y vuelta para agentes de documentos: genera, abre, convierte, edita, reexporta y verifica artefactos .docx, .xlsx, .pptx, .odt, .ods y .odp.

• Genera el archivo objetivo desde el flujo de trabajo del agente. Pasa cuando el archivo existe, el registro de la tarea registra el prompt y la ruta de salida es estable.
• Abre el archivo con la pila de oficina local. Se completa cuando la aplicación lo carga sin un prompt de reparación y el contenido visible coincide con la tarea.
• Conviértelo a un formato compatible. El paso tiene éxito cuando existe un segundo archivo y el registro de conversión registra los formatos de origen y destino.
• Edita una región pequeña y representativa. Estás listo cuando una celda de tabla, una fórmula, un título de diapositiva o un comentario cambia de la forma que la tarea requeriría.
• Reexporta el archivo editado. La exportación es válida cuando el archivo final se escribe en una ruta limpia y no aparecen advertencias ocultas.
• Verifica la estructura, las ediciones y las anotaciones. La prueba pasa cuando los encabezados, filas, hojas, diapositivas, comentarios y valores modificados esperados se reportan correctamente.

No te detengas en una conversión exitosa. Un archivo puede convertirse sin problemas y aun así perder fórmulas, comentarios o estructura de tabla. Revisa las partes que portan significado.

Registra el comando de conversión, el hash de entrada y el hash de salida. Un hash es una suma de verificación compacta del archivo. Si la misma entrada produce una salida diferente, el pipeline no es estable. Corrige el pipeline antes de confiar en las aserciones.

Mantén los datos de prueba pequeños. Un documento corto, una hoja de cálculo pequeña y una presentación breve son suficientes para exponer la mayoría de los problemas de formato. No construyas un corpus antes de tener un caso que falle.

Verifica las partes que se rompen primero

Empieza con la estructura que verá el usuario. Los encabezados, nombres de hojas, orden de diapositivas y bordes de tabla son baratos de verificar y costosos de pasar por alto.

Luego verifica las ediciones. La celda modificada debe contener el nuevo valor. El párrafo debe incluir la frase solicitada. La diapositiva debe mostrar el nuevo título.

Luego verifica las anotaciones. Los comentarios, cambios rastreados y notas de revisión deben sobrevivir a la ida y vuelta. Si el flujo de trabajo está diseñado para preservarlos, la prueba debe fallar cuando no lo hagan.

Haz que el arnés sea lo suficientemente económico para ejecutarlo con frecuencia

Ejecuta el arnés en el mismo entorno donde se ejecuta el agente. Si el agente usa una pila de oficina local, la prueba debe usar la misma pila. Una discrepancia puede ocultar un error que solo aparece en producción.

Almacena la salida esperada como archivo de referencia. Cuando el agente cambie, compara la nueva salida con la referencia. El diff debe mostrar solo el cambio previsto. Cualquier otra cosa es una regresión.

Falla la compilación cuando una anotación requerida desaparezca. Un comentario ausente puede ser más grave que una fuente cambiada. El usuario puede depender de la nota para entender la edición.

Ejecuta el arnés en cada cambio del agente que afecte la salida de documentos. Trata una ida y vuelta fallida como una compilación rota, no como un problema cosmético.