AgentSpeak(L) y Arquitectura BDI

SKILL.md — AgentSpeak(L) y Arquitectura BDI

Cuando las entidades autónomas deben percibir, deliberar y actuar mientras gestionan metas en competencia y responden a eventos sin abandonar el trabajo en curso.

---

Puntos de Decisión

Selección de Arquitectura Principal

SI el sistema solo necesita reacción a eventos sin metas persistentes
  → Usar sistema reactivo/de reglas (BDI es excesivo)
SINO SI el sistema necesita planificación en entorno estático sin interrupciones
  → Usar planificador clásico
SINO SI el sistema necesita tanto reactividad COMO persistencia de metas en entorno dinámico
  → Usar arquitectura BDI

Tabla de Invocación de Funciones de Selección

Situación	Función Usada	Criterios de Decisión
Nuevo evento llega	SE (Selección de Eventos)	Prioridad, urgencia, restricciones de recursos
Evento necesita plan	SO (Selección de Opciones)	Guardas de contexto, historial de éxito del plan, tolerancia al riesgo
Múltiples intenciones activas	SI (Selección de Intenciones)	Plazos, asignación de recursos, política de equidad
Fallo de plan ocurre	SO luego SI	Encontrar plan de manejo de fallo, luego reprogramar intenciones

Árbol de Decisión para Recuperación de Fallos de Plan

El plan P falla al ejecutar la acción A:
SI existe un plan de manejo de fallo para este tipo de fallo
  → Publicar evento de fallo, dejar que SO seleccione el plan de recuperación
  → Continuar con la pila de intenciones modificada
SINO SI existen planes alternativos para el mismo evento desencadenante
  → Retroceder al evento, dejar que SO intente el siguiente plan aplicable
  → Eliminar el plan fallido de la consideración
SINO no hay alternativas disponibles
  → Propagar el fallo hacia arriba en la pila de intenciones
  → SI existe un plan padre → desencadenar evento de fallo a nivel del padre
  → SINO abandonar la intención por completo

Evaluación del Impacto de Actualización de Creencias

Llega una nueva creencia B:
SI B contradice creencias existentes
  → Ejecutar protocolo de revisión de creencias
  → Verificar todas las intenciones activas por violaciones de guardas de contexto
  → SI el contexto ya no se cumple → suspender la intención (no abandonar)
SINO SI B habilita nuevos planes aplicables
  → Verificar la cola de eventos en busca de eventos inactivos que ahora tengan planes aplicables
  → Repriorizar usando SE
SINO SI B satisface condiciones de meta pendientes
  → Marcar logro, limpiar intenciones relacionadas
  → Publicar evento de logro para limpieza de planes

---

Modos de Fallo

1. Thrashing de Planes

Síntomas: El agente cicla rápidamente entre planes sin progresar; el mismo evento desencadena diferentes planes repetidamente. Regla de Detección: Si el mismo evento se procesa >3 veces en N ciclos de ejecución con diferentes selecciones de plan cada vez, tienes thrashing de planes. Causa Raíz: La función SO (selección de opciones) es no determinista o las guardas de contexto son demasiado débiles/superpuestas. Solución: Hacer que SO esté explícitamente ordenado por prioridad; fortalecer las guardas de contexto para que sean mutuamente excluyentes; agregar historial de éxito/fallo de planes a los criterios de selección.

2. Parálisis por Creencias Obsoletas

Síntomas: El agente selecciona planes basados en un modelo del mundo desactualizado; los planes fallan inmediatamente debido a suposiciones falsas sobre el entorno. Regla de Detección: Si la tasa de fallo de planes >50% y los fallos se deben a violaciones de guardas de contexto en tiempo de ejecución (no en tiempo de planificación), tienes creencias obsoletas. Causa Raíz: La frecuencia de actualización de creencias es demasiado baja en relación con la tasa de cambio del entorno; la revisión de creencias no se propaga a las comprobaciones de contexto de las intenciones. Solución: Aumentar la frecuencia de percepción; agregar marcas de tiempo de obsolescencia de creencias; suspender intenciones cuando sus guardas de contexto se vuelvan inválidas.

3. Bucles Infinitos de Intenciones

Síntomas: El agente crea intenciones que publican eventos que crean más intenciones para la misma meta; la pila de intenciones crece sin límite. Regla de Detección: Si la profundidad de la pila de intenciones aumenta monótonamente con el tiempo sin logros de meta correspondientes, tienes bucles de intenciones. Causa Raíz: Los planes crean submetas que eventualmente llevan de vuelta a la meta original sin condiciones de terminación. Solución: Agregar detección de logros en las guardas de contexto; implementar subsumción de intenciones (fusionar intenciones duplicadas); agregar límites máximos de profundidad de recursión.

4. Antipatrón de Política en Planes

Síntomas: Mismos eventos desencadenan diferentes comportamientos basados en condicionales dentro de los cuerpos de los planes; la política del agente está dispersa y es difícil de cambiar. Regla de Detección: Si los cuerpos de los planes contienen condicionales de prioridad/urgencia (if alta_prioridad then X else Y), la política está en el lugar equivocado. Causa Raíz: La racionalidad del agente está codificada en la lógica del plan en lugar de en las funciones de selección. Solución: Mover toda la lógica de prioridad/política a las funciones SE/SO/SI; hacer que los planes sean neutrales en cuanto a política y solo sensibles al contexto.

5. Cuello de Botella de Intención Única

Síntomas: El agente no puede manejar interrupciones; los eventos urgentes esperan mientras el agente completa tareas de larga duración; no hay concurrencia. Regla de Detección: Si el agente tiene como máximo una intención activa en cualquier momento, tienes cuello de botella de intención única. Causa Raíz: La función SI (programación de intenciones) no implementa verdadera concurrencia; trata las intenciones como exclusivas en lugar de concurrentes. Solución: Permitir múltiples intenciones activas; implementar programación preventiva en SI; diseñar planes como secuencias interrumpibles.

---

Ejemplos Trabajados

Ejemplo 1: Asignación de Tareas Multi-Agente con Conflictos de Planes

Escenario: Dos agentes (A1, A2) coordinan para lograr entregar(paquete, destino). Ambos tienen planes pero diferentes capacidades.

Estado Inicial:

• Creencias de A1: ubicacion(A1, almacen), puede_cargar(A1, objetos_pequenos), ubicacion(paquete, almacen)
• Creencias de A2: ubicacion(A2, deposito), puede_cargar(A2, cualquier), tiene_vehiculo(A2)
• Creencia compartida: tamano(paquete, grande), destino(sitio_cliente)

Evento: +!entregar(paquete, sitio_cliente) publicado para ambos agentes

Proceso de Decisión:

1. Selección de Plan de A1 (SO):

   • Plan P1: +!entregar(X,Y) : puede_cargar(A1,objetos_pequenos) & tamano(X,pequeno) <- recoger(X); transportar(X,Y)
   • Guarda de contexto falla: tamano(paquete, grande) contradice tamano(X, pequeno)
   • No hay planes aplicables → publica fallo_plan(entregar, sin_capacidad)

2. Selección de Plan de A2 (SO):

   • Plan P2: +!entregar(X,Y) : puede_cargar(A2,cualquier) & tiene_vehiculo(A2) <- recoger(X); conducir(X,Y); dejar(X)
   • Guarda de contexto tiene éxito → P2 seleccionado
   • Crea intención I1: [recoger(paquete), conducir(paquete,sitio_cliente), dejar(paquete)]

3. Actualización de Creencias de A1:

   • Recibe mensaje: intentando(A2, entregar, paquete)
   • Actualiza creencias: +delegado(entregar, paquete, A2)
   • Abandona la intención fallida

Error de Novato: Ambos agentes intentarían la entrega, creando conflictos de recursos. Perspectiva Experta: La coordinación ocurre a través del intercambio de creencias y las guardas de contexto de los planes, no mediante conocimiento del agente codificado.

Ejemplo 2: Manejo de Interrupciones con Reconsideración de Intenciones

Escenario: Agente que ejecuta una tarea de procesamiento de datos de larga duración recibe una alerta de seguridad urgente.

Estado Inicial:

• Intención activa I1: [procesar_lote(datos1), procesar_lote(datos2), generar_reporte()]
• Ejecución actual: en medio de procesar_lote(datos1) (tomará 10 minutos más)

Evento: +alerta_seguridad(intrusion_detectada, servidor_3)

Proceso de Decisión:

1. Selección de Eventos (SE):

   • Prioridades de SE: eventos_de_seguridad > procesamiento_rutinario
   • alerta_seguridad seleccionada sobre continuar con I1

2. Selección de Plan (SO):

   • Plan P3: +alerta_seguridad(Tipo,Ubicacion) : tiene_acceso_admin <- aislar_sistema(Ubicacion); notificar_equipo(Tipo)
   • Guarda de contexto satisfecha → P3 seleccionado
   • Crea intención I2: [aislar_sistema(servidor_3), notificar_equipo(intrusion_detectada)]

3. Programación de Intenciones (SI):

   • Intenciones actuales: I1 (suspendida en procesar_lote(datos1)), I2 (nueva, urgente)
   • Política de SI: las intenciones de seguridad se adelantan a las intenciones de procesamiento
   • Selecciona I2 para ejecución

4. Ejecución:

   • Ejecuta aislar_sistema(servidor_3) inmediatamente
   • Ejecuta notificar_equipo(intrusion_detectada)
   • I2 completa, se elimina del conjunto de intenciones

5. Reanudación:

   • Solo queda I1: [procesar_lote(datos1), procesar_lote(datos2), generar_reporte()]
   • Reanuda procesar_lote(datos1) desde el punto de suspensión

Error de Novato: Ignoraría la alerta de seguridad o abandonaría la tarea de procesamiento por completo. Perspectiva Experta: La suspensión de intenciones preserva el progreso mientras permite un comportamiento receptivo. La política de programación SI es explícita y configurable.

---

Puertas de Calidad

• La arquitectura del agente tiene funciones de selección SE, SO, SI explícitas con políticas documentadas
• Cada plan tiene un evento desencadenante y una guarda de contexto bien definidos que pueden evaluarse frente a las creencias actuales
• La biblioteca de planes incluye planes de manejo de fallos para cada tipo de plan principal (no solo caminos de éxito)
• El mecanismo de actualización de creencias puede manejar información contradictoria y propagar cambios a las intenciones activas
• Múltiples intenciones pueden estar activas concurrentemente con reglas claras de programación/prelación
• El procesamiento de la cola de eventos está priorizado (no FIFO) con asignación explícita de prioridad
• El fallo de un plan desencadena eventos en lugar de fallos del sistema o fallos silenciosos
• Las guardas de contexto son mutuamente excluyentes O la selección de planes está explícitamente ordenada para evitar no determinismo
• El agente puede explicar sus acciones exponiendo la pila de intenciones y los eventos desencadenantes
• El rendimiento del sistema se degrada correctamente bajo alta carga de eventos (sin bucles infinitos ni desbordamiento de pila)

---

Límites NO-APROPIADO

NO APROPIADO PARA: Sistemas simples basados en reglas donde todo el comportamiento es reactivo (sin metas persistentes) → USAR EN SU LUGAR: Motor de reglas básico o sistema evento-acción

NO APROPIADO PARA: Problemas de planificación estática donde el entorno no cambia durante la ejecución → USAR EN SU LUGAR: Planificadores clásicos (A*, STRIPS, HTN)

NO APROPIADO PARA: Sistemas en tiempo real que requieren tiempos de respuesta garantizados o plazos estrictos → USAR EN SU LUGAR: Sistemas de programación en tiempo real con análisis de temporización

NO APROPIADO PARA: Sistemas donde toda la coordinación puede ser manejada por un controlador central → USAR EN SU LUGAR: Orquestación de flujos de trabajo o cola de tareas centralizada

NO APROPIADO PARA: Tuberías de transformación de datos puras sin toma de decisiones autónoma → USAR EN SU LUGAR: Herramientas ETL, marcos de procesamiento de flujos

NO APROPIADO PARA: Aplicaciones que requieren aprendizaje automático o inferencia estadística como capacidad principal → USAR EN SU LUGAR: Marcos de ML con BDI como capa de coordinación si es necesario