Agentes

Un agente (ai.agent) describe cómo se comporta un compañero de IA. No es lo mismo que la cuenta de usuario de Odoo con la que puede ejecutarse.

Dos formas

Personaje de chat (sin usuario vinculado)

Ejemplo: Jarvis, el predeterminado incluido de serie.

  • Se utiliza cuando una persona abre el chat de IA.

  • Se ejecuta como el usuario que chatea (con sus permisos y su pertenencia a la política de IA).

  • Instrucción del sistema, las anulaciones de modelo y las capacidades determinan la sesión.

  • No requiere supervisor.

  • Restringido a grupos puede limitar quién puede invocar este personaje.

Compañero autónomo (usuario vinculado)

  • Usuario apunta a un res.users dedicado.

  • Se ejecuta con los permisos de ese usuario (como un empleado humano).

  • Supervisor es obligatorio: autoriza el trabajo y aprueba las propuestas de escritura.

  • Las reglas de canal deciden quién puede dirigirse al agente y con qué alcance de capacidades.

  • Aparece como is_ai_agent en el usuario (indicador de solo lectura).

Peligro

Vincular un usuario con privilegios amplios a un agente equivale a otorgar ese privilegio a un trabajador expuesto a la inyección de instrucciones. Cree siempre un usuario restringido para el agente. No utilice nunca el superusuario, usuarios de portal, ni las cuentas de Ajustes o de Administrador de IA.

Campos del formulario de agente

IA ‣ Configuración ‣ Comportamiento ‣ Agentes

Campo

Finalidad

Nombre

Nombre visible (por ejemplo, Asistente de soporte).

Activo

Los agentes inactivos no se ejecutan.

Modelo

Anulación de modelo opcional; de lo contrario, se usa el principal o los valores predeterminados.

Temperatura

Anulación del muestreo para los turnos propios de este agente; no se envía a los modelos que no la admiten.

Tokens máximos (0 = sin anulación)

0, el valor predeterminado, no envía ningún límite: se aplica el propio límite de salida del modelo. Un valor positivo limita las finalizaciones de este agente en su lugar; consulte la nota siguiente.

Instrucción del sistema

Se añade después de las capas de instrucciones globales.

Capacidades

Límite máximo de clases de herramientas para este agente.

Restringido a grupos

Quién puede invocarlo como personaje de chat.

Usuario

Usuario interno vinculado opcional (único).

Supervisor

Obligatorio si se ha definido un usuario; debe tener el permiso IA: Usuario.

Reglas de canal

Listas de permitidos por canal con denegación predeterminada.

Agente predeterminado

Marca el personaje que se usa de forma predeterminada en el chat.

Nota

Un límite solo surte efecto cuando el registro del modelo publica su propio límite de salida, y su comportamiento varía según el proveedor. Ambas reglas, y lo que ocurre al actualizar los agentes que ya tienen un valor asignado, se describen una sola vez en Límites de la respuesta generada.

Reglas de canal

IA ‣ Configuración ‣ Comportamiento ‣ Agentes → reglas de canal (o vistas dedicadas a las reglas de canal).

Canales:

  • Mensaje directo de Conversaciones

  • Mención @ en el chatter

  • Actividad (actividad asignada)

  • Asignación (por ejemplo, la persona asignada a una tarea de proyecto): crítico, sin esto no se podría distinguir a quien puede asignar una tarea de una restricción de Conversaciones

  • Correo electrónico / panel de chat de IA: reservado/integración progresiva; sigue aplicándose la denegación predeterminada

Campos de la regla:

  • Grupos permitidos / Usuarios permitidos: audiencia. Una audiencia vacía no coincide con nadie (no con todos).

  • Puede solicitar: la audiencia puede desencadenar una ejecución puntual.

  • Modo de alcance:

    • Permisos del agente ∩ permisos del solicitante (intersect, opción predeterminada): las clases de capacidades que ambos poseen. Los datos se siguen leyendo/escribiendo como el agente.

    • Todos los permisos del agente (agent_full): solo para audiencias de confianza.

Importante

intersect no significa «ejecutar como el solicitante». Solo restringe las clases de herramientas (lectura/escritura/web/…). La visibilidad de los registros sigue siendo la del agente. Incluya en la lista de permitidos únicamente a personas en las que confíe con todo lo que el agente pueda ver.

Flujo de entrada (simplificado)

  1. Un mensaje, una asignación o una actividad se dirige al agente.

  2. Si el solicitante está prohibido → se rechaza (sin LLM).

  3. Se resuelve la regla de canal (denegación predeterminada) → de lo contrario, se rechaza y se registra una infracción/amonestación.

  4. Se encola la solicitud entrante; la tarea cron la procesa al activarse.

  5. El triaje opcional solo puede reducir la autoridad, nunca ampliarla.

  6. Se crea la tarea/ejecución dentro del alcance del supervisor; se ejecuta como el usuario del agente con el límite de capacidades ya establecido.

  7. Las escrituras siguen el Modo de escritura de esa tarea (de forma predeterminada: propuestas pendientes para el supervisor; consulte Modo de escritura de la tarea (solo ejecuciones de agente)).

  8. El agente publica notas o borradores en el hilo como tal; el texto del cliente nunca se convierte en una concesión de privilegios silenciosa.

Tareas y ejecuciones

Menús operativos (IA: Usuario, con alcance de supervisor):

  • IA ‣ Agentes ‣ Tareas: tareas permanentes y programadas.

  • IA ‣ Agentes ‣ Elementos de trabajo: cola por registro que se procesa en ejecuciones secundarias aisladas (consulte Elementos de trabajo por registro).

  • IA ‣ Agentes ‣ Ejecuciones: registro de ejecución y pasos.

Los supervisores los utilizan para ver qué intentó hacer el agente, qué herramientas se ejecutaron y qué propuestas están pendientes.

Elementos de trabajo por registro

Una tarea permanente que procesa muchos documentos (facturas de proveedor y similares) no debe cargar todos los adjuntos en una sola conversación: la ventana de contexto del modelo se llena y un solo error del proveedor cancela todo el lote.

Añada dos textos a la tarea:

  • Instrucción: el explorador. Busca los ID candidatos, llama a queue_work_items y se detiene. No lea archivos PDF aquí.

  • Instrucción del elemento de trabajo: la hija. Marcadores de posición {model} y {id}. Cada registro en cola la ejecuta en una conversación nueva. Si está vacía, se usa una instrucción genérica para un solo registro que igualmente prohíbe volver a encolar.

La acción programada IA: procesar elementos de trabajo del agente (cada minuto) inicia como máximo ocho elementos pendientes por ciclo, siempre dentro del mismo presupuesto de envío que las demás tareas programadas. Las ejecuciones secundarias dejan vacío el campo Ejecución principal; ese campo marca una repetición de aprobación, no una ramificación, y no cuentan para el límite diario ni para el disyuntor de la tarea.

queue_work_items requiere la capacidad de escritura. Solo funciona en una ejecución de tarea permanente (no en una ejecución de bandeja de entrada ni en una secundaria), y solo encola registros que el agente puede leer. Los ID que sigan pendientes o en ejecución se omiten; los elementos hechos o fallidos se pueden volver a encolar. Como máximo 200 ID por llamada.

Modo de escritura de la tarea (solo ejecuciones de agente)

Cada tarea tiene un Modo de escritura. Se aplica únicamente a las ejecuciones de agente enviadas para esa tarea, no al chat interactivo (el chat usa el ajuste global en IA ‣ Configuración ‣ Ajustes).

Valor

Efecto en las ejecuciones de esa tarea

Requerir siempre confirmación (confirm, opción predeterminada)

Cada creación, escritura, eliminación o adjunto de archivo se convierte en un ai.pending.write para el supervisor.

Crear automáticamente, confirmar actualizaciones (hybrid)

Las creaciones se aplican de inmediato; las actualizaciones, eliminaciones y adjuntos de archivo siguen necesitando aprobación.

Aplicar de inmediato (auto)

Las modificaciones permitidas se aplican al instante con los permisos del usuario del agente y dentro del límite de capacidades de la ejecución.

El parámetro global ai.write_mode nunca anula una tarea: un administrador no puede pasar todos los agentes desatendidos a automático con un solo ajuste. hybrid y auto son adhesiones deliberadas por tarea para trabajos de confianza y bajo riesgo; por ejemplo, una tarea permanente de cuentas por pagar que rellena facturas de proveedor en borrador y cuya habilidad nunca contabiliza facturas. Prefiera confirm siempre que una ejecución pueda contabilizar, pagar, eliminar o tocar datos de cara al cliente.

Al crear una propuesta, la plataforma también coloca una actividad pendiente (y normalmente una nota en el chatter) en el registro de negocio de destino, cuando existe (por ejemplo, la factura de proveedor que se está actualizando), o en la tarea del agente si se trata de una creación que aún no tiene ID. Confirmar y cancelar siguen estando en IA ‣ Propuestas de escritura; la actividad es solo un aviso en la bandeja de iconos para que el supervisor llegue a la factura o al contacto, no solo a la lista abstracta de propuestas. El formulario de propuestas de escritura tiene Abrir registro para el mismo salto. La actividad se cierra cuando la propuesta se aplica, se cancela o caduca.

Truco

El límite de denegación estricta bloquea las herramientas de IA sin procesar en todos los modelos de la plataforma ai.*. Por eso los agentes no pueden «gestionar» su propia cola de aprobación ni la configuración de IA mediante herramientas, y no deben intentarlo. Los avisos de la plataforma y las actividades de revisión impulsadas por habilidades en documentos de negocio usan rutas controladas; indique a los agentes que no inventen llamadas de herramienta de configuración de IA, o acumularán rechazos y amonestaciones.

La fila del registro de una ejecución solo se vuelve visible para otros usuarios cuando el intento ha terminado o se ha detenido a la espera de aprobación: la fila se escribe y finaliza dentro de la propia transacción del proceso, por lo que no se confirma nada mientras el agente sigue trabajando. Por eso la lista de ejecuciones muestra el trabajo ya completado, no una vista en directo de lo que se está ejecutando en ese momento.

Las ejecuciones fallidas tienen un Tipo de fallo en el formulario de la ejecución que indica de qué tipo de fallo se trata; consulte Supervisión para conocer los valores que conviene vigilar.

Detener una ejecución

Abra la ejecución y use Solicitar cancelación. El botón aparece mientras la ejecución está en estado En ejecución o Esperando aprobación, y solo el supervisor del agente o un administrador de IA pueden solicitarla.

Importante

Este botón no es un control general para «detener el agente ahora», debido al comportamiento del registro descrito antes: una ejecución que se está ejecutando con normalidad todavía no tiene fila, así que no hay nada que abrir. En la práctica se usa en una ejecución detenida en Esperando aprobación, o en una que quedó en estado En ejecución por un incidente anterior del servidor. Para evitar de antemano un trabajo no deseado, mantenga el valor de Segundos límite de la tarea lo bastante corto para que una ejecución termine por sí sola, y desmarque Activo en la tarea para que no se vuelva a enviar.

Cancelar una ejecución detenida en Esperando aprobación retira sus propuestas de escritura abiertas y después cierra la ejecución: como Hecho si ya se había aplicado alguna propuesta de esa ejecución, o como Fallido con Tipo de fallo waiting_approval_empty si no se aprobó ninguna de sus propuestas.

Cancelar una ejecución que realmente sigue en curso es cooperativo, nunca inmediato. La solicitud se lee al inicio de cada ronda con el proveedor y de nuevo antes de cada llamada a una herramienta, por lo que solo surte efecto una vez terminado el intercambio ya en curso; cuente hasta unos dos minutos con los valores predeterminados de fábrica, y nunca en mitad de una llamada al proveedor. Esa ejecución se cierra entonces como Fallido con Tipo de fallo cancelled; no existe un estado Cancelado independiente. Los pasos que sí llegó a ejecutar permanecen en la pestaña Pasos, la respuesta de la ejecución registra la cancelación en lugar de una respuesta parcial, y las propuestas de escritura que ya había abierto se cancelan con ella, de modo que no queda nada por aprobar. Una cancelación es neutra para la desactivación automática de la tarea: no cuenta como fallo ni interrumpe una racha existente.

Nota

Si no queda ningún proceso que atienda la solicitud, el botón responde Nada en curso que cancelar en lugar de confirmar. No hay ningún fallo; lo más probable es que la ejecución ya haya terminado o que su proceso haya muerto, pero ningún proceso verá la solicitud y la ejecución no se detendrá por ese motivo. Actualice el registro para ver su estado real; la ejecución de un proceso muerto la cierra el recolector de ejecuciones atascadas descrito a continuación.

Ejecuciones cuyo proceso ha muerto

Si se mata el proceso del servidor que gestiona una ejecución (reinicio, falta de memoria, terminación forzada), no queda nadie para terminarla. Una acción programada, IA: recolectar ejecuciones de agente atascadas, se ejecuta cada 15 minutos y las cierra: la ejecución se registra como Fallido con Tipo de fallo reaped_stuck, se publica una nota en la tarea y las propuestas de escritura que aún dependían de ella caducan para que no se pueda aprobar nada en nombre de una ejecución muerta. Si el fallo se llevó también la fila del registro, la tarea de mantenimiento reconstruye una a partir del registro que dejó el envío, siempre que ese registro se hubiera llegado a escribir; una terminación lo bastante temprana como para impedir incluso eso no deja nada a partir de lo cual reconstruir.

No espere ese cierre en 15 minutos. La ejecución tiene que superar su propio límite de tiempo más un período de gracia (10 minutos de forma predeterminada; consulte Configuración) antes de que una pasada la toque, y las pasadas están separadas 15 minutos, así que el peor caso ronda la media hora. Cada pasada cierra como máximo 200 ejecuciones, empezando por las más antiguas; una acumulación grande tras una tormenta de reinicios se va drenando en las pasadas siguientes.

Esa misma acción programada también libera las ejecuciones detenidas en Esperando aprobación que ya no tienen ninguna propuesta abierta; por ejemplo, cuando la última propuesta caducó mientras el supervisor aún la estaba confirmando; de modo que esa ejecución no se queda con un recordatorio de actividad para una propuesta que ya no existe.

Truco

Cada intento de envío lleva un Token de envío, que se muestra en el formulario de la ejecución. Es la clave que vincula una ejecución con el registro efímero escrito al iniciarse, que es lo que buscan tanto el recolector como Solicitar cancelación; por eso es también el valor que hay que citar al correlacionar una ejecución con el registro del servidor.

Comprobación de la instrucción antes de la ejecución

Las ejecuciones programadas y las de Ejecutar ahora ejecutan directamente la instrucción permanente de la tarea. Marque Triaje al enviar en una tarea para ejecutar la misma comprobación de la etapa 1 que recibe un agente al que se dirigen desde el chat. La comprobación solo puede restringir lo que la tarea ya concede; nunca amplía nada.

Tenga en cuenta lo siguiente antes de habilitarlo:

  • supone una llamada adicional al modelo por ejecución (tiempo y tokens), y el planificador reserva unos 30 segundos de su propio presupuesto de ciclo para esa llamada. Por eso una tarea cuyo valor de Segundos límite ya esté cerca del límite de tiempo del proceso puede omitirse en lugar de enviarse;

  • la comprobación tiene su propio límite corto de 15 segundos y falla de forma cerrada: un modelo de triaje lento, inalcanzable o que responde fuera del esquema cuenta como un rechazo;

  • un rechazo significa que el agente nunca llega a iniciarse. La ejecución se registra como Fallido con Tipo de fallo triage_denied, se publica una nota en la tarea y se crea una actividad Pendiente para el supervisor, de modo que ningún rechazo pasa desapercibido;

  • los rechazos cuentan para la desactivación automática de la tarea. La tarea se archiva cuando cinco ejecuciones consecutivas han fallado y la racha tiene más de siete días, y se notifica a su supervisor. Como un fallo de triaje es un rechazo, una interrupción prolongada del proveedor puede archivar una tarea que nunca estuvo mal configurada; por eso la opción es por tarea y está desactivada de forma predeterminada;

  • lo que decide la comprobación se registra en la ejecución como Veredicto del triaje, en la pestaña Instantánea, y queda vacío en todas las ejecuciones de una tarea que no se haya adherido a esta opción. Es telemetría, no un límite: la restricción que describe ya está fijada en las Capacidades permitidas de la ejecución, que es lo que consulta el control de acceso.

El interruptor general para el triaje de la etapa 1, tanto para dirigirse al agente como para esta comprobación previa a la ejecución, es el parámetro del sistema ai.triage_enabled, en Ajustes ‣ Técnico ‣ Parámetros ‣ Parámetros del sistema (que requiere el modo desarrollador).

Etapas del proyecto AI Ops

El módulo incluye una categoría de proyecto IA, una plantilla de proyecto Agente de IA y un paquete de etapas compartido:

Bandeja de entrada → Revisión → Listo → En curso → En espera → Hecho / Cancelado

Uso sugerido:

  • los hallazgos de auditoría automatizados llegan a la bandeja de entrada sin persona asignada;

  • los gerentes los refinan en Revisión;

  • asignar el usuario del agente solo desde Listo;

  • Esperando la intervención o aprobación humana;

  • nunca aplicar automáticamente habilidades/políticas de una auditoría sin intervención humana.

Paquete de Asistente de Soporte

Se incluye el agente Asistente de Soporte, inactivo de forma predeterminada, con capacidades de consulta y lectura (ask+read) y reglas de canal cuyas audiencias están vacías hasta que las configure. Actívelo de la siguiente forma:

  1. Cree un usuario interno con permisos limitados (lectura de atención al cliente/proyecto según sea necesario).

  2. Vincúlelo al agente y defina un supervisor.

  3. Complete las audiencias del canal (grupos/usuarios que pueden enviar mensajes directos, asignar o mencionar con @).

  4. Active la opción Activo.

  5. Ajuste las reglas de acceso de la IA para los modelos de tickets.

Restricciones de identidad (resumen)

Al vincular, el módulo rechaza usuarios de agente que sean:

  • superusuario (uid 1);

  • de tipo compartido/portal;

  • Administrador de Ajustes/sistema;

  • Administrador de IA;

  • que posean claves API (riesgo de inicio de sesión no interactivo).

Estas comprobaciones se realizan en el momento de guardar el formulario del agente; no «ascienda» al usuario más tarde desde el menú Usuarios.

A continuación: recetas prácticas en Recetas de agente.