Pruebas de agentes IA en Odoo: valida las actividades guardadas

Volver

Kevin Riedl

14 minutos de lectura · 5 nov 2026
Última revisión 5 de noviembre de 2026

Siguiente

Un agente afirma que ha programado el seguimiento. Existe una actividad nueva, la tiene el comercial correcto y la fecha parece adecuada. Sin embargo, está vinculada a otra oportunidad. Una prueba que solo compruebe si se creó algo aceptaría el resultado equivocado.

Prueba el agente de IA de Odoo frente a un contrato escrito sobre el estado de negocio. Define qué actividad puede crear, qué registros debe dejar intactos y cuándo debe pedir aclaración. Después prueba el verificador con observaciones deliberadamente incorrectas antes de utilizarlo para evaluar ejecuciones controladas en la instalación real.

Investigación revisada: 5 de noviembre de 2026. Los hechos del producto proceden de documentación y código oficiales de Odoo 20. Ejecutamos trece observaciones JSON construidas mediante un verificador Python. No ejecutamos Odoo ni un modelo de IA. Tampoco ejecutamos un servidor de correo. El paquete nativo contiene comprobaciones propuestas, todas en NOT_RUN.

¿Qué debe demostrar una prueba de un agente de IA de Odoo?

Debe establecer que se produjo el resultado permitido dentro del alcance de observación acordado. La escritura solicitada debe ser correcta, los registros protegidos deben permanecer intactos y los efectos prohibidos deben estar ausentes de la evidencia. Una conversación o respuesta de herramienta satisfactoria no demuestra por sí sola esas condiciones.

El verificador de resultados, también llamado oráculo, compara la evidencia observada con el resultado esperado. Mantén esa regla fuera de la explicación que el agente da sobre su trabajo. Si el agente elige el destino y también decide si su elección fue correcta, el mismo malentendido puede superar ambas etapas.

La documentación de acciones de servidor con IA asigna al código de la herramienta el cumplimiento de las reglas del negocio; la acción de IA selecciona herramienta y argumentos. La aceptación todavía requiere examinar el estado de negocio resultante.

Separa esta decisión por tarea de la arquitectura. La guía de agent harness engineering explica los controles de ejecución que la rodean. Aquí la pregunta es más concreta: ¿qué evidencia permite aceptar un seguimiento programado en CRM?

¿Cómo defines una actividad de seguimiento en CRM?

Especifica una referencia inequívoca de oportunidad, un responsable aprobado y una fecha absoluta. Después determina qué campos existentes deben permanecer intactos. Nuestro contrato ficticio permite una actividad de llamada para OPP-42 en la empresa A, asignada al usuario 7 y con vencimiento el 12 de noviembre de 2026. Prohíbe el correo externo.

La documentación de planificación de actividades incluye responsable y fecha de vencimiento. Son condiciones independientes: una fecha correcta no compensa asignar la tarea al compañero equivocado.

El conjunto también incluye OPP-43 en la empresa A y OPP-99 en la B. La actividad previa ACT-OLD pertenece a OPP-43, está asignada al usuario 8 y vence el 10 de noviembre. Estos registros próximos permiten detectar una coincidencia equivocada o una modificación ajena a la tarea.

La descarga utiliza claves normalizadas como record_ref y assigned_user. No es un payload de la API de Odoo. En el código de actividades de Odoo 20 inspeccionado, la vinculación usa campos de modelo y referencia; responsable y vencimiento usan user_id y date_deadline. El observador nativo debe traducir el esquema instalado a la proyección acordada.

En este ejemplo, la empresa corresponde a la oportunidad vinculada. El verificador sigue esa relación y no inventa un campo de empresa en la actividad. La proyección también excluye registros técnicos, como los del chat. Decide qué otros campos de negocio y efectos de notificación necesita observar tu instalación.

¿Por qué hay que probar primero el verificador?

Necesita ejemplos negativos porque una regla débil puede hacer que un proceso incorrecto parezca fiable. Acuerda la clasificación esperada antes de ejecutarlo e incluye resultados con la actividad nueva correcta y otro registro protegido modificado. Así pruebas el significado de la aceptación, más allá de reconocer un ejemplo favorable.

Las etiquetas esperadas están escritas por separado de la función de comprobación. La función lee contrato y proyecciones antes/después, y devuelve PASS, FAIL o UNKNOWN con motivos. No utiliza el texto del asistente ni el estado declarado de la herramienta como prueba de una escritura real.

Un verificador que solo cuente aceptaría dos actividades si exigiera «al menos una». Otro que buscase únicamente la nueva fila correcta podría ignorar una actividad anterior alterada. Por eso la regla compara el estado protegido de referencia además de la fila nueva.

La independencia tiene un límite práctico: alguien debe aprobar el contrato y validar el observador que construye la proyección. El verificador no detecta un campo omitido. Tampoco demuestra que un archivo marcado como «completo» contenga todos los efectos relevantes. Su alcance debe quedar visible en la evidencia de aceptación.

¿Qué mostraron las trece comprobaciones de ejemplo?

Las trece observaciones construidas recibieron la clasificación esperada en la ejecución local: dos PASS, diez FAIL y una UNKNOWN. Esto establece cómo se comporta la demostración Python con esas entradas. No mide la frecuencia de éxito de un agente de Odoo, porque ningún agente generó esas observaciones.

Descarga el verificador y el archivo de casos en un mismo directorio. Basta la biblioteca estándar de Python:

python3 state-oracle.py

Compara la salida con los resultados registrados. El proceso termina correctamente cuando coinciden todas las clasificaciones esperadas, incluidos los FAIL deliberados. Una salida satisfactoria del script significa que reconoció los ejemplos; no significa que se aprobaran trece tareas de negocio.

La rama de aclaración usa una etiqueta ilustrativa, reviewed_disposition. En una prueba real, un revisor o un adaptador validado por separado debe establecer que el agente pidió la referencia de oportunidad que faltaba. El script no comprende la calidad de una pregunta en lenguaje natural. La etiqueta tampoco es un campo de respuesta documentado de Odoo.

¿Cuándo es UNKNOWN el resultado correcto?

UNKNOWN corresponde cuando el observador no puede establecer el estado final requerido. Un registro inaccesible, evidencia incompleta de efectos o una ventana de observación sin resolver dejan abierta la aceptación. Conserva lo conocido e investiga el fallo de observación antes de decidir la recuperación: una lectura fallida no demuestra que no hubiera escritura.

La lista sintética outbound_events solo representa evidencia de efectos externos. Una lista vacía no impone una restricción de correo. En el ensayo nativo, dirige los mensajes a un destino de prueba aprobado e inspecciona el transporte pertinente. Si las notificaciones de asignación contradicen la prohibición de correo, resuelve ese comportamiento antes de aceptar el flujo.

Elige una ventana que cubra el límite real de finalización. Una cola que sigue trabajando al cierre queda sin resolver; no es automáticamente satisfactoria ni un fallo permanente. Registra alcance de consulta y hora de corte para distinguir trabajo tardío de trabajo ausente.

No repitas una escritura incierta para conseguir una respuesta más agradable. El ejemplo de recuperación de escrituras en Odoo trata por separado el riesgo de duplicados y la decisión de recuperación.

¿Qué pruebas siguen necesitando la instalación real de Odoo?

La aceptación nativa debe ejecutar el agente configurado y sus herramientas disponibles en la compilación concreta de Odoo bajo revisión. Utiliza identidades de prueba aprobadas y contrasta el adaptador de observación con registros conocidos. Después compara las evidencias con el contrato, separando el éxito del verificador de la capacidad del agente para completar la tarea.

El paquete de aceptación nativa empieza con dieciséis casos propuestos. El estado de ejecución es NOT_RUN, la aceptación es PENDING y los valores observados están vacíos. Adáptalos a tus módulos y tarea antes de registrar resultados.

Usa la lista de QA antes del lanzamiento para la decisión general de entrega. Este paquete aborda el flujo de actividades y sus evidencias de observación.

El observador necesita acceso autorizado a los datos de prueba. Si requiere una vista más amplia para conciliar, no la confundas con los permisos operativos del agente. Las pruebas de acceso por empresa de Odoo 20 cubren esa matriz nativa de autorización.

Registra metadatos de modelo o proveedor cuando la ruta los exponga; marca como no disponible lo que no puedas obtener. Conserva configuración de herramientas y revisión del prompt incluso si la identidad del modelo es opaca. El registro debe describir lo observado y señalar detalles del servicio sin verificar.

¿Cómo debes revisar ejecuciones repetidas del agente?

Revisa cada ejecución antes de resumirlas. Cada registro necesita el estado inicial, la petición exacta y el resultado observado, con motivo para cualquier FAIL o UNKNOWN. Acuerda las repeticiones y variación aceptable según las consecuencias de la tarea antes de ejecutar. Los trece ejemplos no justifican estadísticamente un umbral de producción.

Empieza desde una referencia equivalente salvo que el caso pruebe expresamente trabajo existente. De lo contrario, la segunda ejecución podría encontrar la actividad de ayer y evaluar otra pregunta. Si la entrega repetida forma parte del flujo, define si debe reutilizar una actividad, pedir confirmación o crear otra.

Separa la corrección del estado de negocio de la calidad de comunicación. El agente puede dejar el registro correcto y dar una explicación poco útil. A la inversa, un texto pulido no corrige un responsable equivocado. Ambos aspectos importan, pero fundirlos en una impresión general dificulta diagnosticar defectos.

Mantén una escritura externa prohibida visible como condición fallida propia. No debe desaparecer en el promedio de tareas fáciles. Para métricas contractuales y responsables de respuesta, utiliza la plantilla de SLA para agentes; este artículo aporta evidencia de una tarea acotada.

¿Qué aprobaríamos para producción?

Aprobaríamos únicamente la tarea de actividad cuyo resultado esperado, alcance de observación y evidencia nativa haya aceptado su responsable. El verificador de ejemplos prepara el trabajo al revelar reglas de aceptación débiles con poco coste. Solo forma parte de la evidencia de entrega junto con observaciones satisfactorias del flujo real y su gestión requerida de fallos.

Empieza por la actividad ordinaria y el contraejemplo de destino incorrecto. Añade el caso donde la fila nueva es correcta, pero cambia una actividad existente. Esa combinación obliga a expresar tanto lo que el agente puede hacer como lo que debe proteger.

Si necesitas una decisión independiente, el servicio de aseguramiento de calidad de Wavect puede ayudarte a definir y revisar la evidencia. Trae contrato de tarea, configuración instalada y casos pendientes. Una demostración verde resulta útil cuando el revisor puede explicar exactamente qué demuestra.