El informe de pruebas puede estar listo antes de que abras Open WebUI

El lunes a las 8:30, un desarrollador abre los resultados de las pruebas nocturnas. Hay tres tareas en rojo. La primera perdió la conexión con la base de datos de pruebas, la segunda tuvo un tiempo de espera intermitente y la tercera falló en una aserción de código cambiado el viernes. Clasificarlas lleva más tiempo que leer los avisos rojos. Una ejecución periódica de un agente podría dejar en el chat un informe breve con la aserción fallida y el fragmento del registro arriba.

Open WebUI, una interfaz de chat que puedes alojar para modelos y herramientas de IA, añadió agentes de programación a las automatizaciones programadas en la versión 0.13.3. GitHub fecha la versión el 8 de noviembre de 2026 a las 23:48 UTC. Una automatización puede guardar un terminal, un directorio de trabajo y un agente disponible en él, y entregar el resultado en un chat. El horario puede iniciar una tarea con un entorno concreto, lo que hace viable el informe matinal. Notas de Open WebUI v0.13.3

La primera tarea que merece programarse es un informe que una persona pueda comprobar en pocos minutos. Usa la automatización para reunir pruebas y deja la decisión siguiente a quien responde por el proyecto. Cuando el informe sea útil y repetible, tendrás una referencia para decidir si concedes otro permiso.

La automatización recuerda dónde trabaja el agente

Las automatizaciones de Open WebUI ya admitían peticiones recurrentes. Una ejecución inicia un chat a través del flujo normal de generación, por lo que pueden influir los ajustes del modelo, herramientas, filtros y memoria aplicable. La versión 0.13.3 añade una forma de elegir un agente de programación detectado en un terminal. Con un terminal seleccionado, el selector muestra las combinaciones en formato agente/modelo. Cambiar terminal o carpeta puede cambiar la oferta. Antes de iniciar, Open WebUI verifica que sigan disponibles el terminal y el agente guardados. Si falta alguno, la ejecución falla y su propietario puede consultar el registro. Documentación de automatizaciones de Open WebUI

El planificador inicia un chat con los ajustes de ejecución guardados. Ilustración original de Telli.sh basada en las notas de Open WebUI v0.13.3.

El directorio de trabajo responde a una pregunta corriente con consecuencias costosas. ¿Qué copia debe leer el agente si dos proyectos tienen nombres parecidos, o si hay una rama de funciones y otra de lanzamiento en disco? Una ruta explícita inicia el trabajo donde querías y da al revisor una referencia. Sigue siendo el directorio inicial. Los permisos de lectura y escritura, los archivos accesibles, las variables de entorno, la red y el agente determinan qué más puede alcanzar la ejecución.

Los resultados tienen un destino definido. Las automatizaciones con agentes de programación envían la salida al chat. Las notas las distinguen de las automatizaciones de modelos ordinarios, que pueden usar canales como destino. Un historial y un chat bastan para que una persona revise el informe. Un equipo que quiere un aviso compartido aún debe decidir qué comparte, dónde y quién puede ver el registro. Una tarea fallida debe tener también un responsable que sepa dónde mirar. Notas de Open WebUI v0.13.3

Da a la primera tarea entradas pequeñas que puedas inspeccionar

Para el informe del lunes, empieza con copias del resumen nocturno, el identificador de commit generado automáticamente y unos pocos registros de error. Un exportador de artefactos de integración continua o una copia manual en una carpeta desechable dan entradas estables al agente. Cada archivo debe permitir atribuir un fallo a una tarea y un commit. Quita secretos evidentes y registros ajenos antes de copiarlos. El informe funciona mejor si la entrada tiene un nombre convencional y una marca de tiempo verificable sin pedir al agente que deduzca cuál es la última.

Pide tres resultados separados en una respuesta. El primero es una lista breve de fallos que merecen atención. El segundo recoge los fallos de entorno o pendientes de aclarar. El tercero incluye un enlace o ruta a la evidencia de cada punto. Usa un formato compacto para cotejarlo con la vista original de integración continua. Si una prueba aparece en seis ejecuciones de la matriz y la tarea crea seis incidencias iguales, ha convertido una lectura breve en una revisión mayor.

Una petición útil explica qué debe conservar la salida. Este ejemplo usa datos de prueba con el commit y un resumen exportado. La carpeta y los archivos son ilustrativos.

Lee el resumen exportado de pruebas y los fragmentos de fallos relacionados en la carpeta asignada. Empieza con el ID de ejecución, el commit y la marca de tiempo de la entrada. Agrupa los fallos repetidos de la matriz. Por cada fallo distinto, indica el nombre de la prueba, el fragmento útil más corto y la ruta de origen. Distingue fallos explícitos de causas posibles. Si falta el resumen, está obsoleto o incompleto, explica qué entrada falta y detente. Deja los archivos como los encontraste.

Estas instrucciones reducen la ambigüedad. El terminal también necesita permisos acordes. Si la tarea solo lee archivos, dale una vista de solo lectura o una copia desechable sin credenciales del repositorio. Una prueba fallida puede imprimir texto arbitrario de un archivo fuente, una dependencia o un dato de prueba. Ese texto es evidencia y se registra como tal. Esto importa especialmente si la ejecución empieza antes de que se despierte su responsable.

La misma preparación puede servir para otra tarea periódica. Una persona responsable de ingeniería puede dar al agente un inventario de dependencias fechado y un catálogo de avisos obtenido por separado, y pedir coincidencias de versiones con las citas pertinentes. Lo útil es una lista de revisión con paquete, versión y fuente exactos. Un escáner de confianza puede seguir haciendo las coincidencias deterministas. Quien revisa puede determinar si la dependencia está en una ruta alcanzable. Mantener los archivos estables permite reproducir el informe si la explicación cambia.

Una configuración breve muestra dónde está el trabajo

Open WebUI documenta un interruptor global de Automations y un permiso separado para usuarios sin administración. Confirma que tu instancia ejecuta v0.13.3 o una versión posterior compatible, que la función está activa y que la cuenta tiene acceso. El terminal debe estar conectado y permitido en el contexto de automatización. Puede aparecer en el editor de modelos y estar excluido de las tareas por su configuración de contexto. Eso puede explicar que funcione en el chat normal y falle en su horario. Automatizaciones de Open WebUI · Conexión de Open Terminal

1. Prepara datos de prueba. Pon una ejecución satisfactoria, un fallo representativo y un manifiesto con commit y hora en un espacio temporal. Limita el tamaño y deja fuera claves de producción, configuración de nube y archivos personales.
2. Abre Automations y crea una tarea. Usa los campos de título, petición, modelo y horario. En el editor, elige terminal, introduce el directorio de trabajo exacto y selecciona el agente previsto. Espera a que el entorno muestre los agentes de esa carpeta.
3. Ejecuta la tarea una vez desde el editor. Abre el chat y el registro resultantes. Comprueba commit, archivos, eliminación de duplicados y permisos. Contrasta con el artefacto original y verifica que el árbol de código sigue limpio.
4. Prueba un caso negativo. Quita el manifiesto de unos datos de prueba separados o usa una entrada deliberadamente antigua. El informe debe mostrar la evidencia ausente. Comprueba que un terminal no disponible para automatizaciones figure como ejecución fallida en el historial.
5. Fija el horario recurrente y revisa los primeros resultados. Compara el horario con el fin de la exportación de integración continua. Si arranca pronto y lee el resultado de ayer, el problema es de horario aunque parezca actual. Pausa la tarea si cambia el formato de entrada o los informes empiezan a desviarse.

Trata los datos de prueba y la petición como una pareja. Si renombras la carpeta, cambias la convención de ramas o mueves una prueba a otra batería, actualiza los datos junto con la ejecución. Así la tarea conserva la evidencia que usa para agrupar resultados. Cuando alguien actualice la petición, guarda el ejemplo anterior y compara ambas salidas con la misma entrada. Mejorar el manifiesto suele ser la corrección más barata, en especial si dos tareas deben ponerse de acuerdo sobre qué ejecución es la última.

Elegir un terminal implica delimitar sus permisos

Una interfaz alojada por ti puede conectarse a modelos o agentes de otro proveedor. Revisa el proveedor del agente seleccionado, los datos que recibe y las credenciales que puede usar. Una copia en un contenedor o espacio desechable permite limitar lo que hace la tarea. El directorio inicial por sí solo sirve de poco si el usuario puede acceder al resto del equipo o el agente dispone de credenciales de escritura en el repositorio. La documentación describe opciones separadas de uso del terminal, incluido el contexto de automatización. Eso permite acotar la exposición antes del inicio. Conexión de terminales en Open WebUI

Un informe de solo lectura separa sus pruebas, permisos de ejecución y decisión de revisión. Ilustración original de Telli.sh.

El ahorro es el tiempo que pasa entre abrir resultados y saber dónde mirar. Un comando fiable puede hacer buena parte del trabajo. Haz que produzca el ID y el estado de la ejecución y deja al agente explicar los fallos de distintos tipos de salida. Ese reparto ayuda al investigar un problema. Puedes comparar el ID con el manifiesto y saber si la entrada está equivocada antes de probar otro agente.

Incluye el coste en la misma comprobación. Las tareas programadas pueden consumir uso de pago si el agente llama a un modelo facturado. Los registros largos elevan la entrada y los fallos repetidos pueden generar análisis repetidos. Mide primero cuánta revisión útil obtienes con un fragmento acotado y un horario limitado. Si todas las ejecuciones procesan los mismos archivos grandes, usa un paso determinista barato para registrar si algo cambió. Un horario diario es fácil de presupuestar cuando conoces el límite máximo de entrada por ejecución.

Para un equipo pequeño, la responsabilidad importa tanto como el terminal. Según la documentación, una automatización pertenece a quien la creó y es privada para esa persona. Un informe personal puede quedarse allí. Una aprobación de lanzamiento usada por varias personas necesita un proceso visible de intercambio y relevo. El historial puede ayudar a alguien a investigar un fallo. Una comprobación compartida de integración continua mantiene visible la decisión para el equipo que publica. Controles de acceso de automatizaciones

El informe matinal se gana su sitio durante la revisión

Después de la primera semana, mira los informes que alguien abrió. Comprueba el enlace o fragmento de cada punto urgente y cuenta cuántas veces el resumen omitió un fallo, repitió uno conocido o citó el commit equivocado. Pregunta si ayudó a encontrar la siguiente prueba que revisar. Esas observaciones dicen más que el número de respuestas automáticas.

Si sigue siendo útil, añade un nuevo tipo de evidencia de un archivo en un archivo. Da al terminal un destino estable, limita las credenciales y haz que los cambios de código o infraestructura pasen por la revisión habitual. La mejor señal es un informe matinal que inspira confianza para actuar y que puedes comprobar deprisa si algo no encaja.

Fuentes

• Notas de Open WebUI v0.13.3
• Configuración, permisos e historial de automatizaciones
• Conexiones y contextos de terminal de Open WebUI

---

Para guardar las conversaciones y decisiones de tu trabajo en un registro en el que puedas buscar, crea una cuenta de Telli.sh.