Agentes y Sistemas Multiagente

Agentes y sistemas
multiagente
Antonio Moreno i Ribas
PID_00200714
© FUOC • PID_00200714 Agentes y sistemas multiagente
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
© FUOC • PID_00200714 Agentes y sistemas multiagente
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Agentes inteligentes.......................................................................... 7
1.1. Características de un agente ....................................................... 7
1.2. Agentes deliberativos frente a agentes reactivos ......................... 9
1.2.1. Agentes reactivos ........................................................... 9
1.2.2. Arquitecturas de sistemas reactivos ............................... 11
1.2.3. Agentes deliberativos ..................................................... 12
1.2.4. Arquitectura BDI ............................................................ 13
1.3. Tipos de agentes .......................................................................... 15
1.3.1. Agentes de interfaz ........................................................ 16
1.3.2. Agentes de información ................................................ 19
2. Sistemas multiagente........................................................................ 23
2.1. Ventajas de los sistemas multiagente ......................................... 23
2.2. Técnicas de comunicación .......................................................... 25
2.2.1. Sistemas de pizarra ........................................................ 25
2.2.2. Paso de mensajes ........................................................... 27
2.3. Foundation for Intelligent Physical Agents ................................ 28
2.3.1. Arquitectura de un sistema multiagente ....................... 28
2.3.2. Lenguaje de comunicación entre agentes ..................... 30
2.3.3. Protocolos de comunicación ......................................... 32
2.4. Ontologías ................................................................................... 35
2.4.1. Objetos ........................................................................... 35
2.4.2. Acciones ......................................................................... 38
2.5. Cooperación entre agentes ......................................................... 39
2.5.1. Planificación global parcial ........................................... 40
Resumen....................................................................................................... 43
Actividades.................................................................................................. 45
Ejercicios de autoevaluación.................................................................. 45
Solucionario................................................................................................ 47
Glosario........................................................................................................ 51
Bibliografía................................................................................................. 52
© FUOC • PID_00200714 5 Agentes y sistemas multiagente
Introducción
Actualmente el campo de los agentes autónomos inteligentes y los sistemas

multiagente es probablemente el más activo dentro de la inteligencia artificial,
con una gran vitalidad en los últimos diez años. En este módulo se hace una
breve introducción a los conceptos básicos de esta área.
En el primer tema se introduce el concepto de agente, y se explicitan las princi-

pales características del mismo (en especial, la autonomía, la capacidad de ra-
zonamiento y aprendizaje, y la posibilidad de comunicarse con otros agentes).
Se hace una gran división de los agentes en reactivos y deliberativos, según có-
mo reaccionan a los cambios en su entorno, y se dan las arquitecturas de estos
tipos de sistemas. También se explican con cierto detalle dos tipos concretos
de agentes de especial relevancia práctica: los agentes de interfaz y los agentes
de información. Estas clases de agentes se ilustran con ejemplos concretos.
Cuando un grupo de agentes se unen para resolver entre todos un problema

complejo, se habla de un sistema multiagente. Éste es el concepto central del
segundo tema de este módulo. Se verá que la característica más importante de
los agentes es su capacidad de comunicación. La explicación se ilustra con un
lenguaje concreto de comunicación entre agentes, llamado FIPA-ACL, y sus
protocolos de comunicación asociados. Se comenta la importancia de tener un
vocabulario común que los componentes de un sistema multiagente puedan
utilizar para entenderse, y se explican mecanismos de cooperación entre un
grupo de agentes heterogéneos.
Objetivos
Los principales objetivos de este módulo son:
1. Saber distinguir entre programas en los que simplemente se aplican técni-

cas de inteligencia artificial y agentes.
2. Conocer las diferencias entre los sistemas reactivos y los deliberativos, y sa-
ber en qué circunstancias hay que utilizar cada uno de estos sistemas.
3. Entender los fundamentos de los agentes de interfaz y los agentes de in-

formación.
4. Descubrir en qué tipo de problemas es apropiado utilizar un sistema mul-

tiagente.
5. Conocer los aspectos básicos de un estándar de comunicación entre agen-

tes concreto: arquitectura del sistema multiagente, lenguaje de comunica-
ción, protocolos de comunicación.
6. Entender la importancia de las ontologías en la comunicación dentro de

un sistema multiagente.
7. Conocer algunos mecanismos de cooperación entre los componentes de un

sistema multiagente.
1. Agentes inteligentes
En la evolución histórica de la inteligencia artificial podríamos definir tres Ved también

grandes etapas. La primera corresponde a los inicios de la disciplina (final de
Recordad los módulos "Resolu-
los años cincuenta y sesenta). En este periodo los científicos intentaban definir ción de problemas y búsque-
procedimientos generales de resolución de problemas, que fueran aplicables a da" y "Sistemas basados en el
conocimiento" de Inteligencia
cualquier dominio. La aportación más relevante fue el General problem solver artificial.
de Newell y Simon, en el que se proponía formalizar un problema como un

grafo, donde los nodos son las diferentes situaciones que podemos encontrar
dentro del dominio y los arcos son las acciones que podemos realizar para ir
de una situación a otra. Para encontrar una solución al problema, había que
buscar (de manera más o menos inteligente) un camino dentro del grafo que
llevara de la situación inicial a la situación objetivo. Pronto se vio que con esta
aproximación era difícil formalizar problemas de cierta envergadura, donde
hubiera que utilizar conocimiento complejo en dominios reales. Así, se pasó a
una segunda etapa (años setenta y ochenta), caracterizada por la aparición de
los sistemas basados en el conocimiento, o sistemas expertos. Estos sistemas están
pensados para comportarse con la misma eficacia (o más) que un experto hu-
mano en un dominio muy especializado. Se pueden distinguir tres módulos
básicos: la memoria de trabajo (donde están los datos iniciales del problema y
los datos intermedios que se van obteniendo), la base de conocimiento (donde
está representado todo el conocimiento de un dominio especializado) y el mo-
tor de inferencia (que es capaz de aplicar el conocimiento general a los datos
concretos de un problema para intentar solucionarlo). Desde los años noven-
ta, el paradigma que recibe más aceptación dentro de la inteligencia artificial
es el de los agentes inteligentes. Un conjunto de estas entidades puede trabajar
de manera coordinada en la resolución de un problema, y formar un sistema
multiagente. En este módulo estudiaremos la tecnología básica de agentes y
sistemas multiagente.
1.1. Características de un agente
Aunque una gran parte de los investigadores actuales en inteligencia artificial

(IA) afirman que su campo de trabajo es el de los agentes, es difícil encontrar
dos que coincidan en la definición de este término. Probablemente la más
aceptada es la siguiente, que es de Wooldridge:
"Un agente es un sistema computacional situado en un cierto entorno, que es capaz de

llevar a cabo acciones de manera autónoma y flexible sobre este entorno para intentar
alcanzar unos ciertos objetivos."
Normalmente, se suelen definir una serie de propiedades que deben tener los Nota
programas para que se los pueda considerar "agentes". Las más habituales son
Notad la importante diferencia
las siguientes: respecto a la "programación
orientada a objetos", ya que
un objeto no puede ignorar la
• Autonomía: un agente tiene que trabajar sin la intervención directa de hu- activación de sus métodos.
manos, y tiene que mantener el control sobre su estado interno y sus ac-
ciones (es decir, no se puede obligar a un agente a hacer una acción de-
terminada; en función de quién se lo pida, de su estado interno y de las
circunstancias externas, puede decidir si quiere llevar a cabo una acción
o no).
• Reactividad: un agente tiene que saber reaccionar de manera rápida y apro-

piada a los cambios que se produzcan en su entorno (es decir, no se puede
preprogramar a un agente diciendo qué debe hacer en cada posible estado,
ya que, en general, no podremos prever todos los cambios que se pueden
producir de manera dinámica a su alrededor).
• Capacidad de comunicación: un agente tiene que ser capaz de comunicarse

con otros agentes (o humanos). De esta manera, un conjunto de agentes se
podrán intercambiar información y coordinar sus acciones para resolver
problemas complejos.
• Continuidad temporal: será habitual que un agente sea un proceso que se

ejecuta de manera permanente (no como un programa normal, que eje-
cuta un conjunto de instrucciones para hacer un cómputo y termina).
• Movilidad: un agente móvil podrá pasar físicamente de un ordenador a otro Web recomendada
por una red electrónica, y continuar su ejecución en el nuevo entorno.
En esta asignatura no trata-
remos del tema de los agen-
• Proactividad: un agente tiene que tener capacidad de tomar la iniciativa, y tes móviles. El lector in-
teresado puede encontrar
ser capaz de llevar a cabo acciones que puedan ser útiles para alcanzar sus más información en http://
agent.cs.dartmouth.edu/tuto-
objetivos sin que se le haya pedido explícitamente que las haga.
rials.
• Planificación, razonamiento: para poder comportarse de manera inteligente

en un dominio dinámico y complejo, un agente tiene que ser capaz de ra-
zonar sobre el estado del entorno y sus posibles acciones, y elaborar planes
(secuencias de acciones) que le pueden ayudar a satisfacer sus objetivos.
• Aprendizaje: un agente tiene que ser capaz de utilizar técnicas de aprendi- Ved también
zaje automático para ir mejorando su eficiencia y aumentar el rango de
Recordad el módulo anterior
problemas que es capaz de resolver. de "Aprendizaje".
• Carácter: muchas veces es deseable que el agente tenga un comportamiento

externo lo más "humano" posible, de manera que el usuario pueda tener
cierta confianza en él. Nadie delegará tareas importantes a un agente si no
está seguro de que no dará información confidencial a una tercera persona
(por ejemplo, un agente comprador no tendría que dar la información de

la tarjeta de crédito del usuario a cualquiera que se la pida).
Hay que ser conscientes de que difícilmente podremos encontrar un progra-

ma que tenga todas estas características. Las que se consideran más importan-
tes son la capacidad de comunicación (con otros agentes o con humanos), la
autonomía, la reactividad y la proactividad. La continuidad temporal, el ca-
rácter y la movilidad se consideran propiedades menos relevantes a la hora
de definir el concepto de agente. Los aspectos de planificación, razonamiento
y aprendizaje son importantes para cualquier sistema que se tenga que com-
portar de manera inteligente, independientemente de si queremos catalogarlo
como agente o no.
1.2. Agentes deliberativos frente a agentes reactivos
Como acabamos de ver en el apartado anterior, la reactividad, o capacidad de

respuesta, es una propiedad importante de un agente inteligente. El agente tie-
ne que ser capaz de reaccionar de manera apropiada a las influencias externas,
a la información que le llegue y a los cambios que se produzcan en su entorno.
Dentro del concepto de entorno incluimos a otros agentes, usuarios humanos,

fuentes de información externa (p. ej., sensores), objetos físicos, incluso la
información que se puede obtener en Internet. Hay dos maneras básicas de
producir las respuestas y reacciones adecuadas a los cambios en el entorno,
que dan lugar a dos arquitecturas de agentes inteligentes: los sistemas reactivos
y los deliberativos.
1.2.1. Agentes reactivos
La idea básica del modelo reactivo es que se pueden desarrollar sistemas inte-
ligentes a partir de agentes muy simples, que no tienen modelos simbólicos
internos del entorno. El comportamiento inteligente del sistema aparece de
manera emergente a partir de las interacciones entre estos agentes básicos.
Ejemplo: una hormiga individual es una entidad sin ninguna inteligencia ni capacidad
de razonamiento. En cambio, una colonia de hormigas es un sistema altamente comple-
jo, estructurado y eficiente, con un comportamiento global bastante inteligente. Dentro
del hormiguero no hay ningún lugar donde se tenga un modelo de la colonia y sus alre-
dedores, ni nadie que planifique la actividad de cada hormiga. El comportamiento inte-
ligente emana de manera natural a partir de las interacciones simples entre las hormigas
individuales.
Las características básicas de un sistema reactivo son las siguientes:
• Dentro del sistema no se tiene una representación simbólica interna del en- Ved también
torno en el que está el agente (no se guarda ninguna representación del
Repasad el apartado 2.1 del
mundo en un conjunto de fórmulas de lógica de primer orden o en un módulo "Qué es la inteligencia
sistema basado en marcos). Recordad que la IA clásica está basada en la artificial" de la asignatura Inteli-
gencia artificial.
hipótesis del sistema de símbolos físicos, que afirma que se puede obtener un
comportamiento inteligente sólo en sistemas de procesamiento de símbo-

los. En los sistemas reactivos se rechaza esta idea, y se defiende que lo más
importante es tener vínculos directos con el mundo físico. El mundo es su
mejor modelo, y no hacen falta modelos computacionales ni representacio-
nes simbólicas sobre las cuales aplicar costosas técnicas de razonamiento
y planificación.
• Habitualmente, los datos se reciben directamente a partir de sensores, sin

ningún tipo de estructura compleja. No hay un manejo de datos simbóli-
cos, como en la IA clásica. Como el mundo siempre es el actual, y se van
recogiendo los cambios en tiempo real mediante sensores, no se puede te-
ner el problema de trabajar con un modelo antiguo o desfasado, que no
se corresponda con la realidad.
• El comportamiento está basado en reglas simples, que reciben un estímulo

del entorno y determinan la respuesta que se tiene que dar.
• Los sistemas reactivos presentan una funcionalidad emergente. Los agentes

son simples, y su interacción también lo es; a pesar de eso, a partir de estas
interacciones aparecen patrones complejos de comportamiento, cuando
se considera el conjunto de agentes globalmente. No está especificado, a
priori, el comportamiento del conjunto de agentes.
• Cada agente está formado por una colección de módulos que operan de
manera autónoma y son responsables de diferentes tareas (p. ej., recibir
información de sensores, controlar la actividad motora del agente, hacer
cómputos simples sobre los datos recibidos). Hay una comunicación mí-
nima, y de bajo nivel, entre los módulos. No hay ningún modelo global
del sistema en ninguno de los agentes, ni ningún módulo planificador ni
director de la actividad de un agente o del sistema.
Con estas características se pretende conseguir que los sistemas reactivos ex-
hiban una serie de propiedades interesantes:
a) Robustez, tolerancia a fallos.
Como no hay nadie encargado de planificar las actividades del sistema, la falta
o el fallo de alguno de los agentes del sistema no tendría que tener consecuen-
cias demasiado importantes.
b) Flexibilidad, adaptabilidad.
Los sistemas reactivos, como están guiados por reglas simples que se aplican
sobre los valores de los sensores, están pensados para adaptarse fácilmente a
los cambios dinámicos en su entorno. Por contra, los sistemas basados en el
conocimiento tradicionales sólo funcionan en un dominio concreto, y su ren-

dimiento desciende espectacularmente cuando se tienen que enfrentar a pro-
blemas ligeramente diferentes de los esperados por el diseñador del sistema.
c) Tiempo rápido de respuesta.
Como no hay ningún modelo del mundo, no se pueden llevar a cabo tareas
de razonamiento costosas o de planificación de secuencias de acciones. Sólo
hay que ejecutar la regla que trate el estado actual del mundo. Los sistemas
reactivos confían en que la mayor parte de la actividad diaria es rutinaria,
repetitiva, y no requiere mucho razonamiento.
Los sistemas reactivos también reciben ciertas críticas:
• Tienen una aplicabilidad muy limitada, a juegos y simulaciones simples.
• No tienen capacidad de planificación a medio plazo. Hay que notar que

este aspecto no tiene por qué ser malo; por ejemplo, puede ser muy com-
plicado intentar planificar una secuencia de acciones si sólo tenemos in-
formación parcial del entorno o si es muy dinámico.
• Es difícil validar este tipo de sistemas. El comportamiento que aparece en

una ejecución puede ser diferente del comportamiento en otra ejecución,
en función de cómo han interactuado los agentes con el entorno.
• No es obvio cómo se tienen que diseñar estos sistemas para que emerja el
comportamiento global esperado.
• El diseñador tiene que pensar en todas las reglas necesarias para reaccionar
ante los datos que llegan del entorno. Hay que anticipar todas las situa-
ciones posibles futuras y la manera de actuar delante de cada una.
1.2.2. Arquitecturas de sistemas reactivos
La arquitectura más básica posible es simplemente tener un conjunto de reglas

(situación, acción). La regla se activa cuando el estado del entorno se corres-
ponde con la situación descrita en las condiciones de la regla, y entonces se
ejecuta la acción asociada. En este tipo de reglas la condición de activación
puede ser una combinación más o menos compleja de elementos internos al
agente (el estado de una variable interna, p. ej., el estado de la batería de un
robot, o su posición actual) y elementos externos (valores de sensores, p. ej.,
un sensor que se activa cuando hay un objeto delante del robot a una distancia
inferior a un metro).
Brooks, del MIT, definió una arquitectura reactiva más compleja, conocida co- Nota
mo la arquitectura de subsunción. En este sistema, un agente está formado por
Notad que las tareas de cada
un conjunto de módulos. Cada uno de los módulos se encarga de hacer una ta- módulo dependen del domi-
rea específica (p. ej., evitar obstáculos o mover un objeto). Cada módulo mo- nio, mientras que el motor de
inferencia de un sistema basa-
nitoriza continuamente su entorno para detectar la aparición de ciertos tipos do en el conocimiento era in-
dependiente del dominio de
de situaciones y poder iniciar una reacción directa (p. ej., cuando se interpone aplicación.
un objeto delante del robot se puede activar el módulo de evitar obstáculos,
que determinará la acción que se tiene que hacer para no chocar con el objeto).
Los módulos se colocan en diferentes niveles, que trabajan de manera asíncro-

na. Todos los módulos reciben los datos recogidos por los sensores (puros, no
analizados y representados de manera simbólica), y todos pueden modificar
el entorno mediante acciones. Esto se llama una arquitectura horizontal. En
la figura 1 se puede ver un esquema básico de la arquitectura.
Figura 1. Arquitectura de subsunción de Brooks
Los módulos de los niveles más bajos se encargan de tareas primitivas simples,
mientras que los módulos de los niveles más altos implementan patrones de
comportamiento más complejos. Puede haber una comunicación (muy limi-
tada y simple) entre dos módulos consecutivos. Cada módulo puede monito-
rizar las entradas y salidas del módulo inferior; eso permite que los módulos
superiores subsuman el comportamiento de los módulos inferiores (de ahí el
nombre de la arquitectura).
Podríamos implementar un agente robótico simple con la arquitectura de subsunción.

El módulo del nivel 0 se encargaría simplemente de evitar el choque con obstáculos. El
del nivel 1 estaría dedicado a ejecutar acciones que le permitan ir moviéndose por el
entorno de manera más o menos aleatoria. Como este nivel incorporaría las capacidades
del anterior, el robot se movería sin chocar con otros robots. En un nivel superior podría
haber un módulo encargado de explorar el entorno, detectar objetos lejanos e ir hacia
ellos; para eso utilizaría la capacidad de movimiento (sin choque) del módulo anterior.
1.2.3. Agentes deliberativos
Los agentes deliberativos están arraigados a la tradición clásica de los sistemas

basados en el conocimiento de la IA. Estos sistemas tienen una base de cono-
cimiento, donde almacenan un modelo simbólico explícito del entorno, y un
motor de inferencia, capaz de hacer procesos de razonamiento lógico sobre la
información del dominio. Estos dos elementos se toman como la base a partir
de la cual se puede llegar a obtener un comportamiento inteligente. Estos sis-
temas son los más habituales, y su capacidad de inferencia y planificación les
permite abordar problemas de gran dificultad en dominios complejos. A pesar
de eso, presentan una serie de inconvenientes que no tienen los reactivos:
• Hay que ir actualizando la representación del mundo, para no hacer razo-

namientos o elaborar planes sobre un modelo que ya no se corresponde
totalmente con la realidad. Eso puede ser muy problemático en dominios
que sean muy dinámicos y variables.
• Hay que llegar a un compromiso entre la expresividad del lenguaje de repre- Ved también
sentación y la eficiencia de los procesos de razonamiento y planificación.
Repasad estos conceptos bási-
Por ejemplo, la lógica de primer orden es un lenguaje de representación de cos de la asignatura Lógica.
conocimiento bastante potente, pero no se puede decidir saber si una fór-
mula es una consecuencia lógica de un conjunto de fórmulas. En cambio,
la lógica proposicional es un mecanismo de representación mucho más
débil pero tiene mecanismos de razonamiento rápidos, completos y fáci-
les de implementar, como la resolución. Además, hay que tener en cuenta
que la tarea de planificar la secuencia de acciones que se tienen que hacer
para alcanzar un determinado objetivo se convierte en casi intratable en
dominios complejos reales.
1.2.4. Arquitectura BDI
(1)
El modelo más utilizado para hablar de agentes deliberativos es conocido co- BDI es el acrónimo en inglés de
1 beliefs-desires-intentions (creen-
mo arquitectura BDI . En este modelo, el estado interno del agente tiene tres cias-deseos-intenciones).
componentes básicos: las creencias, los deseos y las intenciones. A estos elemen-
tos básicos podemos añadir los importantes conceptos de objetivos y planes
(ved la figura 2).
• Creencias: conocimiento que tiene el agente sobre su entorno. Sería pare-

cido al concepto de base de conocimiento en los sistemas tradicionales,
pero más complejo porque podemos tener creencias sobre otros agentes.
• Deseos: son las situaciones futuras a las cuales el agente quiere llegar. Pue-
den ser irrealizables (si el agente no tiene la capacidad o los recursos nece-
sarios para llegar) o, incluso, contradictorios (un agente puede tener deseos
incompatibles entre sí). Los deseos dependen de las creencias del agente.
• Objetivos: subconjunto de los deseos sobre los cuales el agente puede actuar
para intentar cumplirlos. Para un agente ya no sería razonable tener obje-
tivos contradictorios. Conforman el procesamiento potencial del agente,
porque representan las alternativas que se tienen que considerar en un
cierto momento.
• Intenciones: subconjunto de los objetivos seleccionado por el agente para

intentar ser alcanzado. Normalmente provienen de una priorización de
los objetivos.
• Planes: secuencias de acciones que el agente ejecuta para llevar a cabo sus
intenciones.
Figura 2. Elementos básicos del modelo creencias-deseos-intenciones
La figura 3 presenta el aspecto de la arquitectura interna de un agente delibe-

rativo basado en el modelo BDI:
Figura 3. Arquitectura BDI
El módulo de interfaz recibe los datos del entorno (medidas de sensores, infor-
mación recibida de otros agentes). El receptor recoge estos datos y actualiza las
creencias del agente (su base de conocimientos que contiene el modelo sim-
bólico explícito del mundo). El módulo de razonamiento genera los deseos,
objetivos e intenciones del agente a partir de los que ya tenía y del estado ac-
tual de las creencias. El planificador recoge las intenciones y las combina en
un plan global consistente. En este proceso dinámico, los planes se adaptan
según las intenciones que se generan (el planificador controla las dependen-
cias entre las intenciones nuevas y los planes previos). El planificador de tareas
(scheduler) recibe los planes (secuencias de acciones) y decide su orden de eje-
cución concreto (p. ej., es posible la ejecución de dos acciones a la vez). Una
de sus tareas principales es controlar que los recursos necesarios estén dispo-
nibles en el momento previsto para cada acción. Finalmente, el ejecutor es
quien realmente lleva a cabo cada acción y monitoriza el resultado esperado.
El principal inconveniente de los agentes deliberativos es el coste computacio-

nal de este ciclo de trabajo. Si alguna de estas fases (especialmente la decisión
de las intenciones y la planificación de las acciones más adecuadas) tarda mu-
cho tiempo, puede ser que el mundo haya cambiado antes de poder ejecutar
las acciones y que ya no sean las más apropiadas para alcanzar los propósitos
del agente. La planificación clásica suele ser muy ineficiente, porque se bus-
can habitualmente soluciones completas y óptimas, que cuesta encontrar. En
cambio, muchas veces una reacción rápida, como la que producen las reglas
estímulo-respuesta de los sistemas reactivos, puede generar un comportamien-
to que, aunque no siempre sea el óptimo, puede ser preferible en entornos
dinámicos.
Eso provoca la aparición de agentes híbridos, que combinan una parte

reactiva (para reaccionar rápidamente ante estímulos que provocan si-
tuaciones de alarma) y un componente deliberativo (para poder hacer
razonamientos y planificaciones más complejos y alcanzar objetivos a
más largo plazo). Todos los agentes que trataremos en el resto del mó-
dulo se pueden considerar sistemas deliberativos.
1.3. Tipos de agentes
De manera parecida a cómo sucede con la definición del término agente, no

hay un consenso en una tipificación de estas entidades en clases. En el resto
del módulo nos concentraremos en el estudio de tres grandes tipos de agentes,
identificados habitualmente en la literatura:
• Agentes de interfaz.
• Agentes de información.
• Agentes colaborativos.
Las dos primeras categorías se estudiarán a continuación, y los agentes cola-

borativos se explicarán en el segundo tema de este módulo, dedicado a los
sistemas multiagente. Esta clasificación no es exhaustiva ni excluyente, ya que
podemos tener agentes que pertenecen, en mayor o menor grado, a varias de
estas categorías. Muchas veces tendremos sistemas heterogéneos, compuestos
por agentes de diferentes tipos.
1.3.1. Agentes de interfaz
Un agente de interfaz se puede entender como el "asistente personal" de un usua-

rio humano, como un secretario eficiente que colabora con el usuario en al-
guna tarea y le ayuda en su entorno de trabajo. Un caso habitual es que den
asistencia proactiva a un usuario que está utilizando (o aprendiendo a utilizar)
una aplicación. El agente observa continuamente las acciones del usuario en la
utilización de la aplicación, y sugiere maneras más eficientes de hacer alguna
tarea o ayuda al usuario cuando no sabe hacer alguna acción.
Figura 4. Funcionamiento de un agente de interfaz
Los agentes de interfaz habitualmente no tienen un nivel muy elevado

de razonamiento y planificación, ni suelen cooperar con otros agentes.
Sus propiedades principales son la autonomía, el aprendizaje y la proac-
tividad.
La autonomía les permite ir haciendo acciones (p. ej., de monitorización de la

actividad del usuario) sin que se le tenga que pedir explícitamente. El aprendi-
zaje está normalmente basado en las valoraciones (positivas o negativas) que
hace el usuario de las sugerencias que le va presentando el agente o en ins-
trucciones explícitas. La proactividad hace que el agente intente anticiparse a
las necesidades del usuario, por ejemplo, haciendo alguna sugerencia antes de
que el usuario pida ayuda.
Letizia
A causa del gran crecimiento anual en el número de páginas web, la búsqueda Nota
de información en Internet cada vez es más compleja. La manera habitual de
Si buscamos información sobre
buscar algún dato concreto es ir a un buscador, hacer una consulta explícita y "interface agents", obtenemos
examinar los resultados obtenidos. El problema es que estos buscadores, mu- el número siguiente de resulta-
dos: AllTheWeb (6.210), Goo-
chas veces, devuelven miles de páginas, y la mayoría no tienen exactamente gle (9.120), Lycos (11.325),
Yahoo! (15.800).
la información que se busca.
Para ayudar en esta tarea de búsqueda de información, el año 1995 Lieber- Web complementaria
mann desarrolló en el MIT un agente de interfaz llamado Letizia. El propósito
Podéis leer una explica-
de este agente es ayudar a un usuario cuando navega por Internet, y establece ción más detallada de Leti-
zia en la página web http://
una colaboración entre el usuario (que sabe exactamente qué está buscando y lieber.www.media.mit.edu/
si una página es adecuada o no) y el agente (que puede examinar el contenido people/lieber/Lieberary/Leti-
zia/Letizia-Intro.html
de las páginas a mucha más velocidad que el usuario). Letizia monitoriza el
comportamiento del usuario cuando navega por Internet, va observando sus
acciones y saca conclusiones a partir de éstas. De esta manera puede deducir
progresivamente los intereses del usuario. Algunos razonamientos que puede
hacer Letizia son del estilo siguiente:
• Si el usuario guarda una dirección de interés (un bookmark) en una página,

indica explícitamente que le interesa su contenido.
• Si el usuario sigue un enlace (un link), es que tiene un interés potencial

en el contenido de aquella página. En cambio, si vuelve atrás desde una
página es que la información que ha encontrado no le ha interesado.
• Si un usuario sigue un enlace que está en el medio de una página, eso nos
indica que no le han interesado los enlaces que había antes.
• Si el usuario está mucho tiempo en una página (con respecto a su longi-

tud), o vuelve repetidamente a la misma página, probablemente contiene
información relevante para él.
• Si el usuario hace una búsqueda explícita en un buscador, las palabras que Nota
da indican el tipo de información que busca.
Es interesante ver que Letizia
construye el perfil del usuario
Haciendo este tipo de razonamientos, Letizia se puede dar cuenta de qué pá- sin que éste deba gastar tiem-
po en explicarle sus preferen-
ginas son interesantes para el usuario. Mirando el contenido de estas páginas, cias explícitamente.
puede averiguar cuáles son las palabras que se repiten con más frecuencia, y
así ir descubriendo los intereses del usuario (p. ej., si en un porcentaje elevado
de las páginas que visita el usuario aparece la palabra tenis, parece claro que
el usuario es un aficionado a este deporte; si en muchas de las páginas de las
que vuelve atrás inmediatamente aparece la palabra gato, seguramente no está
muy interesado en estos animales). De esta manera, el agente va construyen-

do un perfil del usuario, que puede ir variando dinámicamente en el tiempo, a
medida que va recogiendo más información.
Después Letizia puede usar la información sobre las preferencias del usuario Recorrido en anchura
para ayudarlo cuando utiliza un navegador. Mientras el usuario lee una pági-
Este recorrido en anchura tra-
na, el agente va haciendo un recorrido en anchura de las páginas accesibles si- ta las páginas más cercanas a
guiendo los enlaces de la página actual. Si se examina el contenido de estas la página actual, y compensa
la manera habitual de navegar
páginas, el agente puede dar indicaciones al usuario de cuáles son los enla- por Internet, que es un recorri-
do en profundidad.
ces de la página actual que no llevan a ninguna página (enlaces muertos, muy
abundantes), cuáles son los que llevan a páginas que no parecen interesantes
y, sobre todo, cuáles son los que llevan a páginas potencialmente útiles para
el usuario (páginas en las que aparecen las palabras que coinciden con los in-
tereses del usuario).
Jasper
Siguiendo ideas parecidas a las de Letizia, en British Telecom desarrollaron

más o menos al mismo tiempo un sistema llamado Jasper. El objetivo de este
sistema es ayudar a los usuarios de un grupo de trabajo a buscar información
relevante en su trabajo y compartirla con otros compañeros. En este sistema
cada usuario tiene un agente asociado. Este agente se encarga de dos cosas:
1) Guardar información de los documentos que el usuario considera intere-

santes.
El usuario indica explícitamente cuáles son estos documentos. Para cada uno
se guardan, entre otras cosas, las palabras clave, su URL, el nombre del usuario,
un comentario y la fecha.
2) Ir construyendo un perfil del usuario, identificando progresivamente sus

áreas de interés.
Este perfil se puede construir a partir de la información de los documentos

guardados por el usuario. De manera similar a Letizia, se utiliza la técnica de
contar la frecuencia de aparición de las palabras para identificar los temas cen-
trales del documento.
Cuando un usuario guarda la información de un documento, lo primero que

hace el agente es analizar el documento para actualizar el perfil del usuario con
las palabras que aparecen más a menudo. A continuación, el agente examina
los perfiles de los otros compañeros del grupo de trabajo, para ver si a alguno
también le puede interesar aquella información. Hay una puntuación asociada
a la pareja (documento, perfil), calculada como el número de palabras clave
del perfil dividido por el número de palabras clave del perfil que aparecen en
el documento. Si hay usuarios potencialmente interesados en el documento

(es decir, con una puntuación alta), se les envía un mensaje electrónico con
sus datos principales.
Jasper introduce un mecanismo para poder gestionar diferentes tipos de intere-

ses de un usuario. Cada agente analiza las palabras que aparecen en los docu-
mentos relevantes para su usuario y las agrupa en clases, según una medida de
semejanza que se calcula mirando cuántas veces coinciden en el mismo docu-
mento las mismas palabras. Por ejemplo, para un usuario se podrían identifi-
car los intereses siguientes ([tenis, USOpen, Corretja], [cine, Scorsese, Pfeiffer,
Woody], [agentes, IA, reactividad]). De esta manera, la información de las pre-
ferencias es mucho más útil, al estar estructurada en diferentes categorías que
se pueden tratar de manera independiente.
Agrupación de palabras
La función de semejanza entre dos palabras que se utiliza en Jasper es ésta:
Semejanza(p1, p2) = (2 × ndocs([p1,p2])) / (ndocs([p1]) + ndocs([p2]))
donde ndocs(cp) es el número de documentos en los que aparecen todas las palabras del
conjunto cp.
En Jasper también hay un componente proactivo, porque el agente asociado a

un usuario puede buscar información en Internet que coincida con sus prefe-
rencias, sin que él lo pida explícitamente. Para esta tarea se pueden utilizar
las clases identificadas con el procedimiento de agrupación que acabamos de
ver. Siguiendo el ejemplo anterior, el agente podría buscar páginas web donde
aparezcan referencias a las palabras tenis, USOpen y Corretja.
1.3.2. Agentes de información
Actualmente disponemos de muchos lugares donde podemos buscar informa-

ción: bases de datos, archivos, diferentes almacenes de información, miles de
millones de páginas web, etc. Además, podemos utilizar información de dife-
rentes tipos (p. ej., texto, imágenes, gráficos, sonidos, vídeo). Estos aspectos
hacen que cada vez sea más difícil manejar toda esta gran cantidad de infor-
mación heterogénea, y que sea muy interesante el hecho de disponer de agen-
tes de información que nos ayuden a soportar esta complejidad.
Klusch apunta la siguiente definición de agente de información:
"Un agente de información es una entidad computacional de software autónoma (un

agente inteligente) que tiene acceso a fuentes de información múltiples, heterogéneas y
geográficamente distribuidas, y que, de manera proactiva, adquiere, mantiene y maneja
el acceso a información relevante para el usuario."
Klusch comenta que, para poder hacer este trabajo, un agente de información
tiene que ser capaz de hacer las actividades siguientes:
• Adquisición y utilización de la información.

El agente tiene que dar un acceso transparente a una o varias fuentes de

información. Tiene que monitorizar estas fuentes de información, extraer
información, analizarla, filtrar la que sea relevante, y actualizar el conoci-
miento. La adquisición de información podría tomar formas muy diversas:
la lectura de una página web, una consulta sobre una base de datos o la
compra por Internet de un artículo científico aparecido en una revista.
• Síntesis de la información y presentación al usuario.

El agente tiene que ser capaz de fusionar los datos recogidos de fuentes
heterogéneas (por ejemplo, sin repetir un mismo dato obtenido de varias
fuentes) y dar una visión unificada de toda la información relevante para
el usuario.
• Soporte inteligente al usuario.

El agente se tiene que adaptar dinámicamente a los cambios en las nece-
sidades de información del usuario (por ejemplo, manteniendo un perfil
de los intereses del mismo que se vaya actualizando periódicamente).
Amalthaea
Comentaremos como ejemplo ilustrativo del uso de agentes de información

el sistema Amalthaea. Su arquitectura se muestra en la figura 5:
Figura 5. Arquitectura del sistema Amalthaea
En este sistema hay dos tipos básicos de agentes de información:

(2)
• Agentes de filtrado de información2 En inglés, information filtering
agents.
Estos agentes se encargan de la tarea de personalización, es decir, modeli-
zar, monitorizar y adaptarse a los intereses del usuario. Cada uno de estos
agentes está interesado en documentos que contienen unas ciertas pala-
bras clave (p. ej., uno de estos agentes puede estar interesado en las pala-
bras [montaña, excursión, escalada, Pirineos, Alpes]).
(3)
• Agentes de descubrimiento de información3 En inglés, information discovery
agents.
Estos agentes son los responsables de recoger la información de las fuentes
de información4 disponibles. Cada uno tiene dos parámetros: la fuente (4)
En inglés, information sources.
de información que utiliza y el número de palabras clave que tiene que
utilizar (p. ej., uno de estos agentes se podría encargar de hacer consultas
en el buscador Google utilizando tres palabras clave).
El funcionamiento del sistema es el siguiente:
• Los agentes de filtrado de información envían solicitudes de búsqueda de

información (relacionadas con las palabras clave que les interesan) a los
agentes de descubrimiento.
• Cada agente de descubrimiento selecciona alguna de estas solicitudes, te-

niendo en cuenta el éxito que haya tenido con cada agente de filtrado
otras veces.
• Los agentes de descubrimiento acceden a su fuente de conocimiento aso-

ciada y extraen la información pertinente (p. ej., páginas web donde apa-
recen las palabras mencionadas en la solicitud seleccionada).
• Los agentes de descubrimiento envían los documentos obtenidos a los

agentes de filtrado. Cada agente de filtrado examina estos documentos y
se queda con los mejores (los que se adecuan más a sus intereses).
• Los agentes de filtrado están agrupados en clases (clusters), que agrupan a

los agentes que tienen intereses similares. Los agentes que pertenecen a
una clase juntan sus mejores documentos y los envían al usuario.
• El usuario puntúa los documentos que ha recibido, en función de si se Nota

ajustan o no a sus necesidades. También puede mencionar explícitamente
Esta información que da el
palabras clave de los documentos en las que tiene un interés especial. usuario es la realimentación
mencionada en la figura 5.
• Se utiliza la puntuación dada por el usuario para saber cuáles son los agen-
tes de filtrado que han dejado pasar documentos interesantes y cuáles son
los agentes de descubrimiento que habían encontrado estos documentos. Ved también
Entonces, se utilizan técnicas de algoritmos genéticos para generar una nue-
Podéis ver el apartado 7 "Algo-
va población de agentes de filtrado y una nueva población de agentes de ritmos genéticos" del módu-
descubrimiento. Concretamente, se seleccionan los agentes con más éxi- lo "Resolución de problemas y
búsqueda" de Inteligencia arti-
to y se combinan utilizando los operadores genéticos de cruce doble y de ficial.
mutación.
Actividad
Intentad hacer las actividades 1, 2, 3 y 4 de este módulo, y el ejercicio de autoevaluación 1.

2. Sistemas multiagente
Probablemente la característica más importante de un agente inteligente es su

capacidad para comunicarse con otros agentes. Esta propiedad hace que un
agente pueda realizar actividades como pasar información a otro, preguntar
un dato a otro agente o pedir ayuda a otros agentes para resolver un problema.
En un nivel todavía más complejo, los agentes pueden coordinar sus activida-
des, cooperar en beneficio mutuo, discutir un plan de acción o negociar las
condiciones de un contrato.
En este tema entenderemos por sistema multiagente un conjunto de agentes au-

tónomos inteligentes que se comunican para resolver un problema de manera
conjunta. Cuando los componentes de este tipo de sistemas quieren cooperar
en la resolución del problema, se habla de un conjunto de agentes colaborativos.
Hay que hacer notar que, cuando se habla de sistemas multiagente en la bi-
bliografía, en general no se asume que los componentes del sistema tengan
que ser necesariamente colaborativos. De hecho, podemos tener muchas si-
tuaciones en las que los agentes compitan entre sí por unos ciertos recursos (p.
ej., varios agentes que intentan comprar un objeto en una subasta electrónica).
2.1. Ventajas de los sistemas multiagente
Abordar la resolución de un problema mediante un sistema multiagente puede Nota

darnos propiedades interesantes como las siguientes:
Algunas de estas propiedades
son características generales
• Conocimiento especializado: no hace falta que haya un agente que tenga del campo de la IA distribuida,
y no son específicas de la utili-
todo el conocimiento necesario para resolver un problema complejo. Cada zación de agentes.
uno de los agentes del sistema puede estar especializado en solucionar una
parte específica del problema, y sólo precisa el conocimiento necesario
para esta parte.
• Distribución: se pueden tratar de manera natural problemas en los que los

datos o el conocimiento están geográficamente distribuidos en diferentes
lugares (p. ej., cada agente podría ser un robot que está explorando una
cierta área, o un sensor de una industria, o un departamento de una em-
presa).
(5)
• Reutilización: cuando se implementa un sistema multiagente, se pueden Agentizar quiere decir transfor-
mar un sistema informático en un
aprovechar sistemas informáticos construidos previamente (p. ej., un sis-
agente, de manera que se pueda
tema experto o una base de datos). La manera más habitual de agentizar
5 incorporar dentro un sistema mul-
tiagente.
un sistema ya existente es construir una envoltura6, que sepa traducir ex-
presiones entre el lenguaje de comunicación entre agentes y las entradas (6)
En inglés, wrapper.
y salidas del sistema. Por ejemplo, se puede hacer una envoltura de una
base de datos, que sepa transformar consultas escritas en un lenguaje de
comunicación entre agentes en consultas sobre la base de datos en SQL, y
después vuelva a traducir la respuesta de la base de datos al lenguaje que
entiendan los agentes.
• Valor añadido: un conjunto de agentes pueden resolver, de manera coope-

rativa, problemas más complejos de los que podría solucionar cada uno
de ellos por separado.
• Eficiencia: como los agentes se pueden ejecutar en varios ordenadores, pue-

den estar trabajando todos en paralelo y así resolver un problema de una
manera mucho más rápida que si lo hiciera un solo algoritmo centralizado.
• Fiabilidad, robustez ante fallos: en una aproximación centralizada, si se es-

tropea el ordenador donde se ejecuta el programa ya no se puede hacer
nada. En cambio, en un sistema multiagente, si falla alguno de los agentes,
los otros componentes del sistema se pueden dar cuenta de este hecho y
dinámicamente se repartirán el trabajo que tenía que hacer (imaginando
que tenemos varios agentes que saben resolver un mismo tipo de proble-
mas).
• Flexibilidad: en un sistema multiagente, las tareas se pueden ir repartiendo

de manera dinámica entre los agentes, según sus capacidades, los recursos
disponibles y el trabajo acumulado que tengan. Se pueden ir incorporando
o eliminando agentes del sistema en tiempo de ejecución.
• Modularidad: es más fácil diseñar e implementar un conjunto de compo-

nentes individuales, especializado en tareas más o menos limitadas, y ha-
cer que se comuniquen los datos necesarios para coordinar sus tareas, que
intentar hacer un gran sistema monolítico que se tenga que enfrentar a
un problema complejo.
• Globalización: si se siguen unas normas estándar de alcance mundial cuan- Ved también
do se implementan los agentes, éstos serán capaces de comunicarse con
En el apartado 2.3 se comen-
cualquier otro agente que siga las mismas convenciones y coordinarse en- tan las normas estándar pro-
tre sí (p. ej., podemos hacer un agente comprador de libros que se entienda puestas por una organización
llamada FIPA.
con el agente vendedor de una librería electrónica americana).
Teniendo en cuenta estas características, se puede ver que los sistemas multi-
agente serán aplicables a:
• Dominios donde el problema que se tenga que solucionar se pueda des-

componer en subproblemas que se puedan ir resolviendo de manera rela-
tivamente independiente.
• Dominios donde el conocimiento necesario para resolver el problema esté

distribuido en diferentes sistemas, o localizado geográficamente en lugares
diferentes.
• Dominios donde haya una serie de entidades autónomas que se tengan

que comunicar, cooperar, negociar y coordinarse entre sí para atacar un
problema complejo.
2.2. Técnicas de comunicación
La manera más simple de comunicación entre objetos dentro de un sistema

computacional es la llamada a funciones. En la programación estructurada
utilizando tipos abstractos de datos, para "comunicarse" con un objeto de un
tipo lo que se hace es llamar a una función de aquel tipo (p. ej., si tenemos
una variable p del tipo pila, podremos llamar a la función cima(p) para pedir
la cima de la pila). En el caso de la programación orientada a objetos, lo que
hacemos es llamar a un método del objeto (en el ejemplo anterior, haríamos
p.cima para llamar al método cima de la variable p). En el caso de los sistemas
multiagente, las técnicas de comunicación son más sofisticadas, y respetan
la autonomía de los agentes (notad que, en los ejemplos anteriores, no hay
ninguna manera para que p se niegue a dar la información del objeto que tiene
en su cima). Las dos técnicas que veremos a continuación son los sistemas de
pizarra y el paso de mensajes.
2.2.1. Sistemas de pizarra
(7)
Los sistemas de pizarra7 son un tipo de comunicación que es tradicional dentro En inglés, blackboard systems.
de la inteligencia artificial distribuida, y proviene de la metáfora de la pizarra

clásica utilizada en una aula, donde el profesor va escribiendo datos y todos
los alumnos los pueden ver. La arquitectura de este tipo de sistemas se muestra
en la figura 6.
Figura 6. Arquitectura de un sistema de pizarra
La idea básica es que hay una estructura de datos centralizada, llamada piza-
rra, que proporciona a todos los agentes de un sistema multiagente una área
común de trabajo en la que pueden intercambiar datos, información o cono-
cimiento de cualquier tipo. Como se puede ver en la figura, los agentes no se
comunican directamente entre sí; todo el paso de información entre los dife-
rentes agentes se hace mediante la pizarra común. Todos los agentes pueden
acceder a la pizarra cuando quieran para escribir datos o para leer todo lo que
hayan escrito los otros agentes del sistema (aunque habitualmente primero
un agente se tiene que registrar en un lugar concreto para recibir autorización
para acceder a la pizarra).
En la pizarra puede haber todo tipo de información que sea útil para que
los componentes del sistema puedan resolver de manera cooperativa un
problema. Los dos tipos de información básicos que podemos obtener
en una pizarra son tareas y resultados.
Por ejemplo, puede haber datos concretos del problema a resolver, información sobre
el estado de resolución de una parte del problema por parte de un agente, resultados
intermedios, la tarea actual de cada agente, las tareas que quedan pendientes de hacer,
un anuncio del tipo de problemas que sabe resolver un agente concreto, etc.
Las ventajas principales de esta arquitectura son la simplicidad del paso de in-
formación entre todos los componentes del sistema, la flexibilidad que permi-
te este mecanismo para poder implementar diferentes tipos de algoritmos de
cooperación y coordinación, y la independencia con respecto a la arquitectura
de los agentes. A pesar de estas interesantes propiedades, la manera de funcio-
nar de este tipo de sistemas presenta una serie de problemas importantes:
• Un agente puede estar interesado en un cierto tipo de información con-

creto, y tiene que ir leyendo todo lo que se va introduciendo en la pizarra
para encontrar los datos que necesita.
• Para resolver este problema, a veces se divide la pizarra en distintas zonas

con diferentes tipos de datos, y un agente se puede registrar para acceder
sólo a las zonas que le interesen. También se pueden tener diferentes pi-
zarras en un mismo sistema multiagente.
• Nadie avisa a los agentes cuando otros agentes escriben algo en la pizarra.
Por lo tanto, hace falta que todos los agentes vayan revisando periódica-
mente la estructura para ver si alguien ha introducido un nuevo dato que
les interese. Eso puede provocar que el acceso a la pizarra se convierta en
el cuello de botella del sistema, si muchos agentes intentan acceder a ella
muy a menudo.
• Al estar toda la estructura centralizada en la pizarra, un fallo en el siste-

ma informático donde se encuentra detiene todo el funcionamiento del
sistema.
En los sistemas de pizarra más desarrollados se introducen dos agentes en el

sistema: un moderador y un distribuidor.
• El moderador centraliza la gestión de las tareas. Inicialmente, pone en la

pizarra la descripción de las tareas que se tienen que resolver. Los otros
agentes leen esta información y, si están interesados en hacer alguna, lo
comunican añadiendo un registro (que se llama registro de activación de
fuente de conocimiento) en una base de datos. El moderador verifica en esta
base de datos qué agentes se ofrecen para aceptar las tareas, y asigna los
problemas pendientes a los agentes más adecuados. Esta asignación tam-
bién se comunica mediante la pizarra, de manera que todos los agentes
sepan quién tiene que hacer cada tarea.
(8)
• El distribuidor8 es un agente encargado de avisar a los demás agentes regis- En inglés, dispatcher.
trados en una pizarra de los cambios que se producen y que les puedan
interesar. Con el uso de este agente no hace falta que todos los agentes
estén continuamente monitorizando el estado de la pizarra.
2.2.2. Paso de mensajes
El tipo de comunicación entre agentes más habitual dentro de un sistema mul-

tiagente es el paso de mensajes. Cuando un agente A se quiere comunicar con
un agente B, le envía directamente un mensaje con la información oportuna
(podéis ver la figura 7). A es el emisor del mensaje y B es el receptor. El mensaje
sólo es legible por el receptor, no es accesible por ningún otro agente del sis-
tema. Este tipo de comunicación es bastante flexible, ya que permite imple-
mentar estructuras de coordinación complejas (los mensajes se pueden utilizar
para establecer mecanismos de comunicación y cooperación siguiendo proto-
colos predefinidos).
Figura 7. Paso directo de un mensaje
Podemos estar pasando información, haciendo una pregunta, pidiendo que el Nota
receptor haga una determinada acción, haciendo una propuesta al receptor,
Un mensaje no es un simple
aceptando o rechazando una propuesta que el receptor nos ha enviado antes, paso de datos de un agente a
etc. Un lenguaje de comunicación entre agentes lo bastante expresivo tiene otro. El agente emisor puede
tener diferentes intenciones a
que permitir la posibilidad de enviar mensajes de diferentes tipos, de manera la hora de enviar un mensaje,
similares a las que tenemos los
que se puedan representar las posibles intenciones del emisor. humanos cuando decimos una
frase a alguien.
2.3. Foundation for Intelligent Physical Agents

Ved también
9
La FIPA es una organización sin ánimo de lucro que se dedica a la definición
En el apartado siguiente vere-
de un conjunto de normas estándar que se tienen que cumplir a la hora de mos un lenguaje de comunica-
ción entre agentes concreto,
desarrollar agentes. La intención es que cualquier agente sea capaz de comuni- llamado FIPA-ACL, que permi-
carse con cualquier otro agente, independientemente del lenguaje de progra- te representar diferentes inten-
ciones del emisor.
mación que se ha utilizado, el entorno de programación donde se ha desarro-
llado, el sistema operativo sobre el cual se ha diseñado, etc. El objetivo final de
(9)
FIPA es la sigla de Foundation for
estas normas es favorecer la interoperabilidad de los agentes. Las sugerencias
Intelligent Physical Agents. Podéis
de esta organización se están convirtiendo en los últimos años en un estándar encontrar información detallada de
las recomendaciones de la FIPA en
de facto en el ámbito mundial. Veremos los puntos principales de diferentes www.fipa.org.
aspectos definidos por la FIPA: arquitectura del sistema multiagente, lenguaje de
comunicación entre agentes y protocolos de comunicación entre agentes.
2.3.1. Arquitectura de un sistema multiagente
LA FIPA propone que los sistemas multiagente tengan la estructura siguiente:

Figura 8. Arquitectura FIPA de un sistema multiagente
(10)
El elemento principal de esta arquitectura es la plataforma de agentes (agent En inglés, message transport sys-
tem.
platform), que proporciona la infraestructura básica sobre la cual se pueden
crear y ejecutar los agentes. Una plataforma puede contener un número inde-
terminado de agentes, y puede estar situada en un único ordenador o distri-
buida entre diferentes ordenadores. De la misma manera, en un único orde-
nador podemos tener diferentes plataformas. Un agente se puede comunicar
con otros programas (p. ej., puede acceder a una base de datos), con agentes
de la misma plataforma o con agentes de otras plataformas. En este último
10
caso, hay que utilizar un sistema de transporte de mensajes que se ocupe de
este tipo de comunicación; este sistema hace que, para el implementador de
los agentes, sea transparente el hecho de si el receptor de un mensaje está o
no en la misma plataforma o en el mismo ordenador.
En la figura anterior se puede ver que toda plataforma de agentes tiene que
contener dos agentes especiales que ayudan a gestionarla:
(11)
• Facilitador de directorio11(DF): es un agente que proporciona un servicio de En inglés, directory facilitator.
páginas amarillas dentro del sistema, porque conoce los servicios que pue-
den ofrecer los diferentes agentes del SMA (los agentes tienen que regis-
trarse en el DF para hacer publicidad de sus servicios). Este agente es espe-
cialmente importante, ya que consultar su información es la única mane-
ra que tiene un agente del sistema de saber qué otros agentes de un tipo
concreto hay en el sistema en un momento determinado.
(12)
• Sistema de gestión de agente12 (AMS): es el agente que controla el acceso y En inglés, agent management
system.
uso de la plataforma. Almacena las direcciones de los agentes y ofrece un
servicio de páginas blancas.
2.3.2. Lenguaje de comunicación entre agentes
(13)
La FIPA ha definido un lenguaje estándar de comunicación entre agentes, lla- En inglés, FIPA agent communi-
13 cation language.
mado FIPA-ACL . Según esta propuesta, en un mensaje aparecen una serie de
parámetros, los más importantes de los cuales son los siguientes:
• Performative: tipo de acción comunicativa que se hace con el mensaje (en- Ved también
viar datos, hacer una propuesta, hacer una pregunta, etc.).
Podéis ver el apartado 2.3.3,
en el que se comentan algunos
• Sender: emisor del mensaje. protocolos de comunicación
definidos por la FIPA, y el apar-
tado 2.4, en el que se comenta
el tema de las ontologías.
• Receiver: receptor del mensaje. Puede ser un agente o un conjunto de agen-
tes.
• Content: contenido del mensaje.
• Language: lenguaje utilizado para representar el contenido del mensaje.
• Ontology: ontología utilizada para representar el contenido del mensaje.
• Protocol: protocolo de comunicación seguido en la conversación actual.
• In-reply-to: identificador del mensaje al que contestamos.
• Reply-with: identificador con el que se tiene que responder al mensaje.
• Reply-by: fecha límite que se da para contestar al mensaje.
• Conversation-id: identificador de la conversación a la que pertenece el men-

saje.
Una conversación es un intercambio de un conjunto de mensajes sobre un mis-

mo tema entre dos o más agentes. Un agente puede estar involucrado en varias
conversaciones al mismo tiempo.
La FIPA define un conjunto de performativas bastante amplio, que permite

representar diferentes intenciones que puede tener el emisor cuando envía un
mensaje. Los tipos de mensajes utilizados más habitualmente son éstos:
• Query: el emisor hace una pregunta al receptor.

• Request: el emisor pide al receptor que haga una acción determinada.
(14)
• CFP (call for proposals14): el emisor pide al receptor una propuesta para ha- En español, solicitud de pro-
puestas.
cer una acción (por ejemplo, un agente comprador pregunta a un agente
vendedor bajo qué condiciones vende un producto concreto).
• Propose: el emisor envía una propuesta al receptor.
• Accept-proposal: el emisor acepta una propuesta que le ha enviado antes el

receptor.
• Reject-proposal: el emisor no acepta una propuesta que le había enviado el

receptor.
• Agree: el emisor envía una confirmación al receptor (por ejemplo, acepta

hacer una acción pedida previamente por el otro agente).
• Refuse: el emisor rehúsa hacer alguna acción pedida antes por el receptor.
• Inform: el emisor envía unos datos al receptor.
• Not-understood: el emisor indica que no ha entendido un mensaje que le

ha enviado el receptor.
• Failure: el emisor indica al receptor que ha habido algún error cuando es-
taba intentando hacer una acción que le había pedido.
• Cancel: el emisor cancela una petición que había hecho anteriormente al

receptor.
Veamos un ejemplo de un mensaje:
(REQUEST
:sender (agent-identifier :name agpersonal@pc0:1099/JADE)
:receiver (set ((agent-identifier :name restauranteArcs@pc0:1099/
JADE))
:content
((action (agent-identifier :name cliente1@pc0:1099/JADE :addresses )
(reserva-mesa 5
(fecha-reserva :minuto 30 :hora 22 :día 24 :mes 9 :año 2001)
(info-usuario :nombre "Alberto Ríos" :teléfono "677869656" )
)))
:reply-with Req1001620481740
:language FIPA-SL
:ontology onto-restaurantes
:protocol fipa-request
:conversation-id Req1001620481740
)
El emisor es el agente agpersonal, que sería el agente personal del usuario Alberto Ríos,
y el receptor es el agente restauranteArcs, que sería el agente asociado a un restaurante.
En este mensaje, el emisor pide (request) al agente del restaurante que ejecute la acción
reserva-mesa, para reservar una mesa para cinco personas, a las diez y media del 24-9-2001,
a nombre de Alberto Ríos. El lenguaje utilizado para escribir el campo content es FIPA-SL
(FIPA semantic language), que es un lenguaje propuesto por la FIPA para representar el
contenido de los mensajes. En la ontología onto-restaurantes estarían definidos aspectos
como los parámetros necesarios para la acción reserva-mesa, o los campos que tiene que
tener un objeto del tipo fecha o del tipo info-usuario (el tema de las ontologías se trata
más detalladamente en el apartado 2.4).
2.3.3. Protocolos de comunicación
Entre dos o más agentes se puede establecer un intercambio de una secuencia

de mensajes de cualquiera de los tipos que acabamos de ver, dentro de una
conversación. En la práctica se ha visto que en muchas ocasiones la secuencia
de mensajes necesaria para alcanzar un objetivo determinado siempre es la
misma. Eso ha hecho que se definan protocolos de comunicación.
Un protocolo de comunicación de mensajes define la secuencia de mensajes

que se tienen que intercambiar un conjunto de agentes para una acción
comunicativa concreta.
La FIPA ha definido diversos protocolos estándar. Cuando un agente inicia

uno de estos protocolos, lo indica en el campo Protocol del mensaje. De esta
manera, el receptor del mensaje sabe qué tipo de respuesta está esperando
aquel agente. Eso facilita la implementación de los agentes porque se limita el
número de tipos de mensajes posibles que un agente espera recibir.
Los tres protocolos más utilizados habitualmente son el FIPA-Query, el FI-

PA-Request y el FIPA-Contract Net.
FIPA-Query
El protocolo FIPA-Query se utiliza cuando un agente quiere preguntar un dato

a otro. Lo podemos representar esquemáticamente de la manera siguiente:
Figura 9. Protocolo FIPA-Query
En este protocolo, un agente envía una pregunta (un mensaje del tipo query)
a otro. Este agente, si sigue el protocolo, sólo puede dar una de estas cuatro
respuestas: not-understood (si no ha entendido la pregunta, p. ej., si no conoce
la ontología que se utiliza), refuse (si no quiere contestar la pregunta, p. ej., si
el agente que la hace no está autorizado a pedir aquella información), failure
(si no puede contestar la pregunta, p. ej., porque ha habido algún error en el
acceso a una base de datos donde estaba la respuesta) o inform (con la respuesta
a la pregunta).
FIPA-Request
Este protocolo se utiliza cuando un agente quiere pedir a otro que haga una
acción determinada. Tiene el aspecto siguiente:
Figura 10. Protocolo FIPA-Request
En este protocolo, un agente envía un mensaje del tipo request a otro, pidién-
dole que ejecute una cierta acción. El agente receptor puede contestar not-un-
derstood (si no entiende el mensaje), refuse (si se niega a hacer aquel servicio) o
agree (si está de acuerdo en hacer aquella tarea). En este último caso el agente
intentará hacer la acción, y enviará un segundo mensaje que puede ser de ti-
po failure (si, por alguna razón, no ha podido completar la tarea pedida) o de
tipo inform (indicando simplemente que ya ha hecho la acción o, si es el caso,
dando algún resultado concreto de esta ejecución).
FIPA-Contract Net
(15)
El FIPA-Contract Net15 es un protocolo más complejo, en el cual se coordinan En castellano, red de contratos
las actividades de diferentes agentes. Se utiliza cuando un agente determinado

necesita un cierto servicio, y hay otros agentes que están dispuestos a ofrecer
aquel servicio, con unas condiciones determinadas.
Por ejemplo: tenemos un agente que quiere comprar un libro en alguna librería electró-
nica. Lo que haría es preguntar en todas las librerías electrónicas que le interesen en qué
condiciones venden el libro. Algunas librerías pueden contestar que no tienen aquel libro
disponible. Las que sí que lo tienen darán diferentes precios según diferentes condicio-
nes: tipo de edición (bolsillo, tapa dura, segunda mano, de lujo con ilustraciones), tiempo
de entrega (inmediato, días, semanas, meses), coste del envío (nacional/internacional,
normal / urgente / con mensajero). El agente comprador tiene que decidir, ante las con-
diciones de cada una de las librerías, en cuál quiere comprar el libro. Tiene que comunicar
a esta librería que acepta sus condiciones y a las otras que no les comprará el libro.
El intercambio de mensajes definido en el protocolo FIPA-Contract Net es éste:
Figura 11. Protocolo FIPA-Contract Net
En primer lugar, el agente que inicia el protocolo envía un call-for-proposals,

dando la acción que se tiene que hacer (la venta de un libro) y, si quiere, algu-
nas precondiciones (p. ej., el usuario ya podría decir que sólo quiere comprar
el libro en edición de bolsillo). Los agentes que reciben este mensaje pueden
contestar not-understood (si no entienden el mensaje), refuse (si no quieren ha-
cer ninguna propuesta, p. ej., si no disponen del libro pedido) o haciendo una
propuesta con la sentencia ejecutiva propose, dando las condiciones de la venta.
El agente que ha enviado el cfp espera hasta un cierto tiempo límite la llega-
da de respuestas. Cuando ha recibido todas las respuestas o ya ha pasado este
tiempo límite, evalúa las propuestas y acepta una (con un accept-proposal) y
declina las otras (con mensajes del tipo reject-proposal). Finalmente, el agente
que ha sido seleccionado hace la acción acordada y contesta o bien con un
failure (si, por alguna razón, finalmente no ha podido hacer aquella acción) o
bien con un inform, indicando el éxito en la realización de la tarea. Si el agente
que pide el servicio quiere cancelar su petición, puede enviar un mensaje del
tipo cancel al agente con quien había acordado el servicio antes de que éste
acabe de llevarlo a cabo.
2.4. Ontologías
Para que dos agentes se puedan comunicar y coordinar sus acciones, hace falta
que se puedan entender. Eso significa que el agente receptor y el agente emisor
tienen que compartir una ontología común.
Una ontología proporciona una conceptualización de un dominio de tra-

bajo. Habitualmente incluye información sobre las clases de objetos que
hay en el dominio, sus atributos o las acciones que pueden hacer los
agentes del sistema.
Para ver un ejemplo, supondremos que queremos hacer un sistema multiagen-

te en el que los usuarios, mediante sus agentes personales, puedan hacer con-
sultas sobre las características de los restaurantes de una ciudad y puedan hacer
reservas de mesas en estos restaurantes. Cada restaurante estaría encapsulado
por un agente diferente.
Como hemos apuntado antes, para que los agentes se puedan comunicar sin
ambigüedades necesitan compartir un mismo lenguaje y ontología. La onto-
logía define el vocabulario y las acciones que, mediante un acto comunicativo
de tipo request, se pueden solicitar a un agente.
2.4.1. Objetos
Los objetos que aparezcan en la ontología nos definirán el tipo de información

del que podemos hablar en el contenido de un mensaje. En este caso, la pieza
fundamental de la ontología sería el objeto restaurante, que contiene toda la
información que podremos solicitar de un restaurante.
Restaurante Ved también
:info-contacto cinfo Información de contacto Podéis ver la similitud de esta

definición con los marcos que
:precios restaurante-precios Precios estudiasteis en el apartado 3.4
de Inteligencia artificial, "Siste-
mas con representación estruc-
:tiene_menu_noche Boolean Indica que el restaurante sirve turada".
menús para cenar
:capacidad Long Capacidad
:tiene_aparcamiento Boolean Indica que el restaurante dis-

pone de aparcamiento
:tiene_zona_fumadores Boolean Indica que el restaurante dis-

pone de una zonapara fuma-
dores
Restaurante
:tarjetas_admitidas Set of String El conjunto de tarjetasque

acepta el restaurante
:comentarios String Un campo de formato libre
:especialidades Set of String El conjunto de especialidades-

del restaurante
:nombre String El identificador del agenteque

gestiona el restaurante
:carta restaurante-carta La carta
Con esta definición del objeto restaurante, se indica de qué características del
restaurante podrán hablar los agentes y qué otras no nos interesan (p. ej., no
guardamos en ningún sitio si el restaurante tiene aire acondicionado o un jar-
dín infantil). Hemos definido el nombre y el tipo de cada uno de los atributos
que componen este objeto. En algunos casos, en un atributo se puede guardar
un conjunto (set) de valores (p. ej., un conjunto de cadenas de caracteres que
denotan las especialidades culinarias del restaurante). El objeto es una repre-
sentación estructurada, ya que algunos de los atributos tienen un tipo com-
plejo y no predefinido (p. ej., el atributo carta es del tipo restaurante-carta).
A continuación se definen los tipos auxiliares de objeto utilizados en la defi-

nición del objeto restaurante. En el objeto cinfo encontramos la información
de contacto aplicable a cualquier tipo de establecimiento.
cinfo
:nombre String El nombre del establecimiento
:direccion_postal direccion La dirección del restaurante
:telefono String El número de teléfono
:fax String El número de fax
:otros String Un campo de formato libre
El objeto dirección contiene la dirección postal de cualquier edificio.
dirección
:pais String El país
:codigo_postal String El código postal
:ciudad String La ciudad
:calle String La calle
En el objeto restaurante-precios tenemos los precios del menú y de la carta.

restaurante-precios
:precio_menu Long El precio del menú
:precio_carta Long El precio de la carta
En el objeto restaurante-carta se almacena la descripción completa de la carta

del restaurante. Los platos de la carta se dividen en cuatro categorías: entrantes,
primeros, segundos y postres.
restaurante-carta
:entrantes Set of plato Los entrantes
:primeros primeros Objeto que clasificalos prime-

ros platos
:segundos segundos Objeto que clasificalos segun-

dos platos
:postres Set of plato Los postres
El plato es la pieza mínima del menú. Para cada plato tenemos el nombre y
el precio.
plato
:nombre String El nombre del plato
:precio Long Su precio
El objeto primeros clasifica los primeros platos en cinco categorías: pastas, so-
pas, verduras, legumbres y arroz. Estas subdivisiones nos permitirán trabajar
con estas partes de la carta de manera individual.
primeros
:pastas Set of plato Todos los platos de pasta
:sopas Set of plato Todos los platos de sopa
:legumbres Set of plato Todos los platos de legumbres
:verduras Set of plato Todos los platos de verduras
:arroz Set of plato Todos los platos de arroz
Finalmente, el objeto segundos clasifica los segundos platos en cinco categorías:

huevos, pescados, marisco, carnes y aves. Estas subdivisiones nos permitirán
obtener estas partes de la carta de manera individual.
segundos
:huevos Set of plato Todos los platos de huevos

segundos
:pescados Set of plato Todos los platos de pescado
:marisco Set of plato Todos los platos de marisco
:carnes Set of plato Todos los platos de carne
:aves Set of plato Todos los platos de aves
2.4.2. Acciones
Los agentes de tipo restaurante tendrían que ser capaces de recibir (y atender de Ved también
manera adecuada) solicitudes de reserva de mesas. Así, tienen que ofrecer un
Este mensaje ya se ha mostra-
servicio que llamaremos reserva-mesa. Cuando un agente personal le pide a un do en el apartado 2.3.2.
agente restaurante este servicio, le tendrá que pasar algunos parámetros (p. ej.,
el día de la reserva, o el número de comensales). Para pedir el servicio, el agente
personal enviaría un request al agente restaurante, pidiéndole la ejecución de
la acción reserva-mesa. Esta acción estaría definida así:
reserva-mesa
:personas Long Número de personas
:fecha-reserva fecha Día y hora en que se quiere

hacer la reserva
:info-usuario usuario El solicitante
El objeto fecha tendría esta estructura:
fecha
:minuto Long Minuto
:hora Long Hora
:dia Long Día
:mes Long Mes
:año Long Año
La información de un usuario sería simplemente su nombre y su teléfono:
Info-usuario
:nombre String El nombre con el que el clien-

te hace la reserva
:telefono String Su número de teléfono

La ejecución de las acciones no siempre comportará los resultados que se espe-

raban. La ontología nos tiene que proporcionar una serie de objetos median-
te los cuales podamos expresar condiciones de error. Se debe decir que, para
expresar el éxito en la ejecución de una acción, el lenguaje FIPA-SL ya propor-
ciona la primitiva done. Sólo habrá que definir, pues, los posibles objetos de
error a la hora de hacer una reserva; podrían ser éstos:
• demasiada-gente: informa sobre la negativa, por parte del restaurante, de

reservar mesa para un grupo tan grande de personas.
• lleno: nos avisa de que el restaurante aquel día y a aquella hora está lleno.
• no-posible: el restaurante no reserva mesa para aquel día, tanto si es porque

es un día especial o porque, simplemente, hace fiesta.
• no-reserva: el restaurante nunca reserva mesas, al menos por vía telemá-

tica.
• demasiado-lejos: la fecha solicitada excede los días de antelación que el

restaurante considera máximos para poder hacer la reserva.
• error: objeto que servirá para indicar cualquier otra condición de error.
2.5. Cooperación entre agentes
La capacidad de comunicación entre los componentes de un sistema multi-

agente hace que puedan llevar a cabo tareas complejas de coordinación, ne-
gociación y cooperación.
Franklin propone dividir los sistemas multiagente en independientes o coopera- Ved también
tivos, según el estilo de cooperación que utilicen. Los primeros estarían forma-
Un ejemplo de sistemas con
dos por agentes independientes, que perseguirían de manera individual sus cooperación emergente serían
objetivos. Dentro de este tipo de sistemas podríamos distinguir entre los dis- los sistemas reactivos vistos en
el apartado 1.2.1.
cretos (donde no hay relación entre los objetivos de los agentes y, por lo tanto,
no hay ningún mecanismo de cooperación) y los que presentan cooperación
emergente. En estos sistemas cada agente tiene su objetivo, pero el conjunto
global da la impresión externa de estar formado por un conjunto de unidades
colaborativas.
Los sistemas multiagente cooperativos son aquéllos en los que se utilizan

mecanismos de cooperación. La cooperación se puede conseguir con pa-
so de mensajes o sin comunicación entre los agentes. En este último caso,
la cooperación se establece de manera indirecta, mediante el entorno.
Cada agente observa el entorno y ve los efectos de las acciones de los
otros agentes, y adecua su actividad de manera apropiada.
Cuando la coordinación se hace a partir de una comunicación explícita con

mensajes, Franklin distingue entre los sistemas deliberativos y los negociadores.
En los deliberativos hay una planificación común a todo el sistema y un acuer-

do entre todos los agentes sobre la metodología que se tiene que utilizar para
resolver un problema. En el subapartado siguiente veremos un ejemplo de este
tipo de cooperación, llamado planificación global parcial. En los sistemas nego-
ciadores, los agentes negocian entre sí de manera dinámica la distribución de
las tareas y subtareas en las que se divide el problema. La técnica más utilizada
en este caso es la planificación mediante el protocolo Contract Net, visto en
el subapartado 2.3.3.
2.5.1. Planificación global parcial
La planificación global parcial (PGP, partial global planning) es un mecanismo

flexible que permite que los diferentes componentes de un sistema multiagen-
te coordinen sus actividades para intentar resolver de manera distribuida y lo
más eficiente posible un problema común. En esta técnica cada agente es capaz
de obtener información sobre el estado actual y los objetivos alcanzados por
los otros agentes, y puede utilizar esta información para optimizar su trabajo.
En el proceso de planificación global parcial se pueden definir cuatro fases:
1) Creación de los planes locales de cada agente
Cada agente hace su plan local para resolver las tareas que tenga asignadas.
Estos planes se tienen que hacer de manera que se puedan adaptar dinámica-
mente en el futuro, dependiendo de la información que vayan obteniendo
otros agentes. Para conseguir esta flexibilidad habitualmente se tienen los pla-
nes en dos niveles de detalle: en alto nivel, con la estructura general de los
pasos más importantes que se tienen que hacer para solucionar el problema,
y en bajo nivel, con información detallada para cada subproblema concreto.
2) Intercambio de planes
Los agentes del sistema intercambian sus planes locales. Cada agente tiene que
tener conocimiento sobre la estructura jerárquica del sistema multiagente, de
manera que pueda determinar cuál es el papel de cada agente en la resolución
del problema y saber qué información tiene que enviar a qué agente (normal-
mente no hay que enviar todo el plan local a todos los otros agentes).
3) Creación de los planes globales parciales
Una vez que cada agente ha recibido los planes parciales locales de los otros
agentes, los tiene que combinar en un plan global parcial. El trabajo principal
es el de comprobar si hay dependencias entre la información recibida y sus
planes. Los componentes del plan global parcial son éstos:
• Objetivos: información básica del plan global parcial. Es el objetivo final

del plan global.
• Mapa de actividades: estructura que incluye las tareas de los otros agentes
(estado actual, detalles, resultado esperado, recursos necesarios, etc.).
• Grafo de construcción de la solución: información sobre cómo se tienen que

comunicar los agentes para poder construir la solución al problema global
cuando se vayan resolviendo los subproblemas.
• Estado: otra información relevante para el plan global parcial (p. ej., refe-
rencias a los planes recibidos por otros agentes).
4) Modificación de los planes globales parciales
Cada agente tiene un módulo planificador especializado para analizar toda la

información que le ha llegado y ver si hay diversos agentes que trabajan en un
mismo objetivo. El planificador incluye este conocimiento en el mapa de acti-
vidades del plan, donde también indica previsiones sobre el comportamiento
futuro y los resultados esperados de los otros agentes.
A partir del plan local actual y el mapa de actividades, se genera un nuevo plan
local (optimizado utilizando el conocimiento actual del sistema) y se mejora
el grafo de construcción de la solución (introduciendo detalles concretos de
cuando se tienen que enviar planes específicos a otros agentes del sistema).
La principal ventaja de este mecanismo de planificación es su flexibilidad y

adaptabilidad para resolver de manera distribuida problemas en entornos di-
námicos. También llevará a resoluciones eficientes del problema, ya que si
diversos agentes trabajan en subproblemas similares o idénticos, lo acabarán
viendo en sus planes globales parciales, y se reasignarán las tareas apropiada-
mente para no repetir el mismo trabajo diversas veces.
Entre los inconvenientes podemos destacar el coste que comporta el hecho

de que el cambio del plan de un agente tenga que ser comunicado a otros
agentes para que reajusten su planificación (p. ej., porque esperaban un cierto
resultado que ya no les llegará). Habitualmente se suelen comunicar sólo los
cambios más importantes, y se intentan tolerar y arreglar las inconsistencias
que puedan aparecer.
Actividad
Haced los ejercicios de autoevaluación 2 y 3 de este módulo, y las actividades 5 y 6.

Resumen
Un agente es un programa que se comporta de manera autónoma, reactiva,

proactiva e inteligente, y utiliza mecanismos de representación del conoci-
miento y técnicas de razonamiento y planificación propias de la inteligencia
artificial. Los agentes más habituales son los deliberativos, que siguen las ten-
dencias clásicas de la IA. Hay tipos específicos de agentes de especial interés,
como los agentes de interfaz (que construyen un perfil del usuario para po-
der colaborar de manera efectiva) y los agentes de información (que ayudan
a gestionar el acceso al conocimiento disponible en fuentes de información
heterogéneas, como Internet).
La utilidad principal de los agentes aparece cuando se une un grupo en un

sistema multiagente. En estos casos, si disponen de un lenguaje de comunica-
ción estándar y una ontología común, se pueden comunicar entre sí para po-
der compartir información, hacer negociaciones, coordinar sus actividades y
cooperar en la resolución distribuida de problemas que no estarían al alcance
de ninguno de los agentes del sistema de manera individual.
Actividades
1. Dentro del campo de la ingeniería del software, se pasó de la programación estructurada a
la programación orientada a objetos. En los últimos años se ha evolucionado hacia una progra-
mación orientada a agentes. Reflexionad sobre las semejanzas y diferencias que hay entre un
objeto y un agente (algunos puntos concretos donde se puede concentrar la comparación son
éstos: autonomía ante el entorno, proactividad, capacidad de comunicación, control del es-
tado interno).
2. Imaginad que queréis construir una librería electrónica, al estilo de la librería Amazon.
Pensad qué información podríais extraer de la navegación del usuario dentro de vuestro sis-
tema para poder construir un perfil que permita personalizar la interacción de la librería con
el usuario lo máximo posible. ¿Qué atributos almacenaríais en el perfil del usuario? ¿Cómo
obtendríais los valores de estos atributos a partir de la observación de la actividad del usuario?
¿Qué tipo de acciones podría emprender el agente de interfaz de vuestra librería de manera
proactiva?
3. Demostrad que la función de semejanza entre palabras utilizada por el sistema Jasper re-
torna un número real en el intervalo [0, 1]. Identificad en qué casos se obtendrían los valores
0 y 1.
4. Comentad cómo se pueden utilizar los métodos de inteligencia artificial que hemos visto
antes de este módulo (búsqueda, representación del conocimiento, sistemas basados en el
conocimiento, razonamiento aproximado, aprendizaje automático) cuando se implementa
un agente (por ejemplo, a qué módulos de la arquitectura BDI se podrían aplicar estas técni-
cas). Comentad también las relaciones que podáis encontrar entre el uso de estos mecanis-
mos y las propiedades que tiene que tener un agente (por ejemplo, probablemente será más
reactivo ante un entorno dinámico un agente que utilice técnicas de aprendizaje automático
para ir captando las características variables del entorno que uno que siempre se comporte
siguiendo un algoritmo fijo).
5. Reflexionad sobre las semejanzas y diferencias que hay entre la inteligencia artificial dis-
tribuida clásica (solucionar un problema con técnicas de inteligencia artificial con módulos
que se están ejecutando en diferentes máquinas) y los sistemas multiagente.
6. En los sistemas multiagente cooperativos con negociación, ¿cómo se puede utilizar el pro-
tocolo Contract Net para resolver un problema complejo de manera distribuida entre dife-
rentes agentes, si cada uno sabe resolver sólo una parte del problema y hay que utilizar re-
cursos compartidos dinámicamente por todos los agentes del sistema?
Ejercicios de autoevaluación
1. Asistente de lector de correo electrónico.
Pensad en el tipo de razonamiento que podría hacer un agente de interfaz que quisiera ave-
riguar los intereses de un usuario a partir del análisis de la interacción del usuario con su
lector de correo electrónico. Dad algunas reglas de inferencia que pudiera utilizar este agente
(del estilo de las que se han utilizado para el sistema Letizia). ¿Qué tipo de acciones podría
hacer este asistente de correo de manera proactiva?
2. Sistema multiagente de gestión de personal médico.
Se quiere diseñar un sistema multiagente que sirva para gestionar los quirófanos y los equi-
pos médicos encargados de hacer operaciones en un hospital. En el hospital hay una serie
de quirófanos disponibles. Cuando se tiene que hacer una operación en alguno, hay que
hacer una reserva previamente para que todo el mundo sepa que el quirófano estará ocupa-
do durante aquellas horas. En el hospital trabajan médicos, anestesistas y enfermeras. Cada
médico tiene una única especialidad, y sólo puede hacer operaciones asociadas con aquella
especialidad. Las enfermeras y anestesistas pueden participar en cualquier operación. Cada
tipo de operación tiene una duración diferente, y requiere un cierto número de médicos,
enfermeras y anestesistas. Cada médico tiene unas determinadas horas de la semana ocupa-
das en consultas, y no puede operar en aquellos momentos. Desde su ordenador personal,
el médico tiene que poder indicar si estará fuera del hospital en algún momento (p. ej., si
va a un congreso médico en el extranjero). Cada enfermera y anestesista tiene un horario
concreto de trabajo, marcado en su contrato. Un anestesista sólo puede participar en una
operación cada día. El sistema multiagente tiene que tener un agente encargado de guiar la
coordinación. Este agente recibirá un mensaje indicando el tipo de operación que tiene que
hacer y un intervalo horario en el que se tiene que llevar a cabo. El sistema tiene que intentar
encontrar un quirófano disponible dentro del intervalo dado, y un conjunto de personas
(médicos, anestesistas y enfermeras) que puedan hacer la operación en aquel momento. Si
es posible encontrar el quirófano y el personal, el coordinador general retornará como re-

sultado un mensaje con el quirófano reservado, los nombres de las personas que harán la
operación, y su hora de inicio y final. En este caso, hace falta reservar el quirófano y avisar
a las personas que intervendrán en la operación para que sepan que se les ha asignado este
trabajo. El sistema tendría que intentar repartir las operaciones de la manera más equitativa
posible entre los médicos de cada especialidad. Hay que evitar que un médico tenga que estar
más de ocho horas seguidas operando. Si no es posible dar un resultado positivo, el sistema
tiene que indicar la razón (p. ej., no hay ningún quirófano disponible, o no hay bastantes
médicos especializados en el área de la operación libres en el intervalo dado).
Hay que concretar estos puntos:
• Diseño del sistema multiagente, indicando los tipos de agentes que hay en el sistema, la
cantidad de cada tipo de agentes y el conocimiento que tendría cada uno de ellos.
• Datos que tendría el directory facilitator.
• Descripción del funcionamiento del sistema, que indique el flujo de mensajes entre los
diferentes agentes.
3. Ontología de cines
Se quiere implementar un sistema multiagente que proporcione información sobre las pe-
lículas que se pueden ver en los cines de una determinada comarca. Habrá un agente que
encapsula la información de cada cine, y el agente personal del usuario hará consultas a es-
tos agentes para encontrar la información que necesite. Diseñad una ontología que defina
el tipo de objetos que podrán utilizar los agentes usuarios y los cines en su comunicación.
Esta ontología tiene que permitir hablar de características de los cines (p. ej., si tienen acceso
para minusválidos, o si disponen de zona de aparcamiento) y de las películas que se ofrecen
(p. ej., para poder preguntar si hacen películas de ciencia-ficción o películas protagonizadas
por Michelle Pfeiffer).
Solucionario
1. Un agente de interfaz que hiciera las funciones de asistente de lector de correo electrónico
podría hacer razonamientos sobre la actividad del usuario cuando lee el correo. Algunos datos
con los que podría trabajar son éstos:
• Contenido de los mensajes enviados y recibidos.

• Tratamiento dado por el usuario a cada mensaje recibido (leído en pocos segundos /
leído en diversos minutos / no leído / mantenido / borrado / clasificado en una carpeta
–folder– / /contestado en un tiempo breve).
• Direcciones electrónicas que el usuario guarda en su lista de direcciones.
• Listas de direcciones que el usuario agrupa bajo un nombre común.
• Direcciones de los mensajes enviados y recibidos.
• Temas (subjects) de los mensajes enviados y recibidos.
A partir del análisis de estos datos, el agente podría extraer mucha información con la que
construir el perfil del usuario. Algunas reglas que podría seguir (¡se pueden pensar muchas
otras!) son éstas:
• Las palabras que se repiten con más frecuencia en el contenido y en el tema de los men-
sajes enviados señalan temas de interés del usuario.
• Los mensajes recibidos que son leídos en breves segundos y borrados no interesan mucho
al usuario.
• Los mensajes que son borrados sin leer son de procedencia desconocida o de un tema
que claramente no interesa al usuario.
• Los mensajes que se envían a una lista de direcciones (o a direcciones que forman parte
de una misma lista) deben tener un contenido relativo a un área específica de interés
del usuario.
• El usuario tiene un interés especial en los mensajes recibidos de personas que pertenecen
a su lista de direcciones.
• Los mensajes que el usuario contesta muy rápidamente son de temas que tienen una
relevancia especial para él.
Una de las tareas que podría hacer el agente es la de analizar el contenido y los subjects
de los mensajes enviados y de los mensajes leídos con más atención por el usuario, para
identificar los temas que le interesan y construir el perfil (utilizando técnicas como las que
se han apuntado en la descripción de Letizia y Jasper).
Algunas acciones concretas que podría hacer el agente asistente de lector de correo de manera
automática y proactiva, sin instrucciones explícitas del usuario, son éstas (¡también se pueden
pensar otras!):
• Clasificar los mensajes recibidos en los directorios más convenientes, en función del te-
ma, contenido y/o remitente.
Por ejemplo, el agente puede aprender que todos los mensajes que tengan en el tema la
palabra journal se tienen que poner en el directorio "revistas de investigación", y todos
los mensajes que provienen de la dirección jefe-departamento@empresa.com se tienen que
poner en el directorio "departamento".
• Borrar los mensajes que provienen de sitios poco fiables, o tratan de un tema que no
interesa al usuario, o tienen ficheros adjuntos susceptibles de contener virus.
Por ejemplo, el agente se podría dar cuenta de que el usuario borra sin leer todos los
mensajes en cuyo tema aparece la palabra Viagra, y podría hacer esta tarea automática-
mente. Podría pasar lo mismo con todos los mensajes que tengan añadido un fichero
con extensión .exe.
• Avisar inmediatamente al usuario cuando le llega un mensaje que puede ser de especial
relevancia.
Por ejemplo, el asistente se puede dar cuenta de que el usuario contesta rápidamente
todos los mensajes con la palabra urgente en el tema, o los que le llegan de la dirección
jefe-departamento@empresa.com, y le puede avisar rápidamente cuando llega un mensaje
de estas características.
• Ordenar los mensajes recibidos por orden de importancia.
El agente puede leer el tema y el contenido de los mensajes recibidos, y comparar las
palabras clave de las preferencias del usuario con ellos, para ver en qué mensajes aparecen
estas palabras y en cuáles no. Así, se podría definir una función que, dado un mensaje
y un perfil de usuario, determinara el interés potencial del usuario en aquel mensaje.
La valoración dada por esta función se podría utilizar para ordenar los mensajes por la
prioridad (así, el usuario no tendría que perder el tiempo pasando por treinta mensajes
irrelevantes antes de llegar a un mensaje que le interesa).
2. El sistema multiagente pedido podría tener esta estructura:

Los agentes que tenemos en este sistema son los siguientes:
• CG: coordinador general.

• CQ: coordinador de quirófanos (cada Qi es un agente asociado a un quirófano).
• CEM: coordinador del equipo médico.
• CD: coordinador de médicos (cada Di es un agente asociado a un médico).
• CE: coordinador de enfermeras (cada Ei es un agente asociado a una enfermera).
• CA: coordinador de anestesistas (cada Ai es un agente asociado a un anestesista).
Figura 12
Los agentes asociados a quirófanos, médicos, enfermeras y anestesistas se encargan de man-

tener los horarios de uno de estos elementos. El agente asociado a un médico se ejecutaría
en su ordenador personal, y tendría una interfaz gráfica que permitiría al médico introducir
y modificar sus horas de consulta y las horas en las que no está disponible, y consultar las
horas en las que tiene alguna operación asignada.
Los agentes asociados a quirófanos, enfermeras y anestesistas probablemente se ejecutarían

en un único ordenador del hospital, al que todo el mundo tendría acceso para comprobar el
estado de reservas de los quirófanos y las operaciones asignadas a cada persona.
Cada agente de tipo E o A conoce el horario de trabajo de su persona asociada, especificado

en su contrato. Cada agente de tipo D conoce la especialidad de su médico asignado.
Como se ve en la figura 12, tendríamos seis agentes coordinadores, más el mismo número
de agentes que quirófanos, médicos, enfermeras y anestesistas hubiera en el hospital.
En el directory facilitator estarían registrados todos los médicos, quirófanos, anestesistas y

enfermeras dados de alta en el sistema. Los agentes que pertenecen a la estructura jerárquica
de coordinación no se tendrían que registrar, porque ésta es una estructura fija.
El funcionamento del sistema sería éste:
• CG recibe un mensaje con el tipo de operación y el intervalo horario en el que se tiene

que llevar a cabo (op, hora_inicio, hora_fin). CG tiene que saber cuál es la duración de
cada tipo de operación (d).
• CG envía a CQ el intervalo horario y la duración de la operación, y a CEM el tipo de
operación, su duración y el intervalo horario. CEM tiene que saber cuántos médicos,
enfermeras y anestesistas hacen falta para cada tipo de operación.
• De manera paralela se van llevando a cabo estos procesos:
– CQ pide a DF qué agentes de tipo quirófano (Q) hay en el sistema, y les pregunta
a todos ellos qué intervalos de la duración de la operación tienen libres dentro del
horario (p. ej., qué grupos de tres horas tienen disponibles entre las diez y las diecisiete
horas). Cada quirófano le responde con los posibles horarios en los que se podría
hacer la operación.
– CEM pasa a CD el tipo de operación, su duración y el intervalo horario. CD tiene que
saber cuál es la especialidad médica asociada a cada tipo de operación. CD pregunta al
DF cuáles son los agentes de tipo médico de la especialidad necesaria, y les pregunta
qué intervalos de la duración de la operación tienen disponibles dentro del intervalo
horario dado. Cada uno de estos agentes de tipo médico (D) da su disponibilidad
(teniendo en cuenta las horas de consulta, las horas ya ocupadas y que no se dan
intervalos que puedan hacer que el médico tenga que estar operando más de ocho
horas seguidas). En la respuesta también se comunica el número de operaciones que
el médico ya ha hecho durante el último mes.
– CEM comunica a CE y a CA la duración de la operación y el intervalo horario. Ca-

da uno de estos coordinadores pide a DF los datos de los agentes subordinados (los
agentes de tipo enfermera –E– y anestesista –A–), y les envían la duración y el inter-
valo para que cada uno conteste su disponibilidad de aquel número de horas en el
intervalo de tiempo dado. En sus respuestas, estos agentes tienen en cuenta el horario
de trabajo del personal y, en el caso de los anestesistas, si ya tienen alguna operación
asignada para aquel día.
• CD, CE y CA envían los resultados obtenidos a CEM. Este agente, como sabe cuántos
médicos, enfermeras y anestesistas hacen falta, analiza todas las posibilidades recibidas
para ver si hay algún intervalo de la duración de la operación en el que estén disponibles
todas las personas necesarias. Si es así, envía todas las posibilidades a CG. Si no es así,
envía un mensaje a CG indicándole que no es posible montar un equipo médico com-
pleto para hacer la operación en el intervalo dado (en este mensaje se puede indicar si
faltan médicos, o faltan anestesistas, o faltan enfermeras, o simplemente no encajan los
horarios libres del personal).
• Por otra parte, CQ también habrá enviado a CG los huecos disponibles en los horarios
de quirófanos para hacer la operación (o un mensaje indicando que no hay ningún qui-
rófano disponible el tiempo suficiente en el intervalo dado, si es el caso).
• En este punto, CG ya ha recibido las posibilidades de CEM y CQ. Entonces CG intenta
encontrar un momento en que encaje la disponibilidad de un quirófano libre con la
posibilidad de montar un equipo médico. Si eso no es posible (o CEM y/o CQ ya no
habían podido encontrar ningún hueco), CG retornaría un mensaje de error e indicaría
que no se ha podido completar la gestión de la operación, y por qué razón (carece de
quirófano, de personal, o no se han podido coordinar entre sí).
• Si CG encuentra diversas opciones, puede utilizar el número de operaciones hechas por
cada médico en el último mes para asignar la operación al médico que lleve menos.
Después de escoger una opción, la comunicará a CEM y CQ. CEM la transmitirá a CD,
CE y CA. Finalmente, CQ, CD, CE y CA avisarán a los agentes asignados que han sido
escogidos para hacer la operación, y al resto les notificarán que no han sido escogidos.
3. En la ontología pedida tenemos que definir los objetos necesarios para que los agentes
puedan intercambiar información de cines, salas y películas. El elemento básico de la onto-
logía será el objeto de tipo cine, que tendrá la información que queremos utilizar de cada
cine. Este objeto podría estar definido de la manera siguiente:
cine
:info-contacto cinfo Información de contacto
:precios cine-precios Precios
:num_salas Long Número de salas
:tiene_aparcamiento Boolean Indica que el cine dispone de

aparcamiento
:tiene_bar Boolean Indica que el cine dispone de

bar
:salas Set of Sala Las salas del cine
:dia_espectador String Día del espectador
:nombre String El identificador del agenteque

gestiona el cine
:acceso_minusvalidos Boolean Indica que el cine tiene acceso

para minusválidos
La información de contacto sería el mismo objeto que se ha utilizado en el subapartado 2.4.1

para dar la información de un restaurante. Los distintos precios de la entrada al cine estarían
en un objeto del tipo cine-precios:
cine-precios
:precio_laborable Long El precio de la entrada normal
:precio_festivo Long El precio de los días festivos
:precio_dia_espectador Long El precio del díadel especta-

dor
:precio_reducido Long El precio para jubiladosy estu-

diantes
En un objeto del tipo sala podríamos guardar los datos siguientes:
sala
:numero Long Identificador de la sala
:films Set of pelicula Películas que se ofrecenen la

sala
:capacidad Long Número de plazas de la sala
Para cada película se podría considerar esta información:
película
:titulo string Título de la película
:idioma string Idioma de exhibiciónde la pe-

lícula
:protagonistas Set of string Nombres de los protagonistas
:duracion Long Duración de la película
:sesiones Set of exhibicion Horas de exhibición
:tipo Set of strings Tipo de película
:director string Director de la película
En un objeto del tipo exhibición guardaríamos en qué momento se exhibe la película:
exhibición
:dia_semana String Día de la semana
:hora Long Hora de inicio
:minutos Long Minutos de inicio

Glosario
agente m Entidad de software que se comporta de manera inteligente en un cierto entorno
para intentar alcanzar un cierto conjunto de objetivos. Idealmente, tendría que ser autóno-
mo, reactivo, proactivo y con capacidad de razonamiento, planificación y aprendizaje.
agente deliberativo m Agente que mantiene una representación interna simbólica del
mundo que lo rodea, y que razona sobre este modelo para planificar las acciones que tiene
que llevar a cabo para alcanzar los objetivos.
agente de información m Agente que tiene acceso a múltiples fuentes de conocimiento

heterogéneas y distribuidas y se encarga, habitualmente de manera proactiva, de recoger,
analizar y presentar la información que sea interesante para el usuario.
agente de interfaz m Agente que colabora con un usuario humano y le ayuda en la

resolución de una tarea o en la utilización de una aplicación.
agente reactivo m Agente que no guarda ninguna representación explícita del mundo, y
que tiene un comportamiento guiado por reglas simples del tipo estímulo => respuesta.
arquitectura BDI f Modelo de los agentes deliberativos basado en los conceptos de creen-
cias, deseos e intenciones.
arquitectura de pizarra f Arquitectura distribuida en la que toda la información entre

los agentes se comunica mediante una única estructura centralizada global.
directory facilitator m Agente obligatorio en todo sistema multiagente, según el modelo

de arquitectura propuesto por la FIPA. Hace un trabajo de páginas amarillas, ya que sabe
cuáles son las tareas que puede hacer cada agente del sistema.
sigla DF
DF m Véase directory facilitator.
Foundation for Intelligent Physical Agents f Organización sin ánimo de lucro que se
ocupa de definir estándares asociados a la tecnología de los sistemas multiagente (p. ej., un
lenguaje de comunicación entre agentes).
sigla FIPA
FIPA f Véase Foundation for Intelligent Physical Agents.
ontología f Vocabulario que define los conceptos básicos que se quieren considerar en un
cierto dominio. Puede incluir clases de objetos, sus atributos o las acciones que se pueden
hacer en el dominio.
performativa f Tipo de mensaje que envía un agente a otro. Indica la intención del emisor
del mensaje (p. ej., hacer una pregunta o pedir que el receptor haga una acción).
protocolo m Secuencia de mensajes predeterminada que tienen que seguir dos agentes o
más que mantienen una conversación, encaminada a hacer una acción concreta (p. ej., pedir
la ejecución de un servicio).
sistema multiagente m Conjunto de agentes que se comunican entre sí para coordinar

las tareas y poder resolver de manera distribuida problemas complejos.
Bibliografía
Bibliografía básica
Weiss, G. (ed.) (1999). Multiagent Systems: a modern approach to Distributed Artificial Intelli-
gence. Cambridge, Massachusetts: MIT Press. En especial el capítulo 1 de este libro, Intelligent
Agents (M. Wooldridge).
Wooldridge, M. (2002). An Introduction to Multiagent Systems. Chichester: John Wiley &

Sons.
Bibliografía complementaria
Brenner, W.; Zarnekow, R.; Wittig, H. (1998). Intelligent Software Agents. Berlín: Springer.
Doran, J.; Franklin, S.; Jennings, N.; Norman, T. (1996). On cooperation in multi-
agent systems. First UK workshop on foundations of multiagent systems. Warwich: Michael Luck.
Disponible en la página web http://www.ecs.soton.ac.uk/~nrj/download-files/FOMAS-PA-
NEL-KER.ps.
Klusch, M. (2001). "Information Agent Technology for the Internet: a Survey". Data and
Knowledge Engineering (vol. 36, núm. 3, pág. 337-372). Amsterdam: Elsevier science B.V.
Moukas, A.; Maes, P. (1998). "Amalthaea: an evolving multiagent information filtering

and discovery mechanism for the WWW". Autonomous Agents and Multiagent Systems (vol. 1,
pág. 59-88). Dordrecht: Kluwer Academia Publisher.
Nwana, H. S.; Ndumu, D. T. (1997). "An Introduction to Agent Technology".En: Softwa-

re Agents and Soft Computing, Lecture Notes in Artificial Intelligence 1198 (pág. 3-26). Berlín:
Springer.
Wooldridge, M.; Jennings, N. (1995). "Intelligent Agents: Theory and Practice". Knowled-
ge Engineering Review (vol. 10, núm. 2, pág. 115-152). Cambridge, Reino Unido: Cambridge
University Press.

Agentes y Sistemas Multiagente

Cargado por

Copyright:

Formatos disponibles

Agentes y Sistemas Multiagente

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Agentes y Sistemas Multiagente

Cargado por

Copyright:

Formatos disponibles

Agentes y sistemas

Actualmente el campo de los agentes autónomos inteligentes y los sistemas

En el primer tema se introduce el concepto de agente, y se explicitan las princi-

Cuando un grupo de agentes se unen para resolver entre todos un problema

Los principales objetivos de este módulo son:

1. Saber distinguir entre programas en los que simplemente se aplican técni-

3. Entender los fundamentos de los agentes de interfaz y los agentes de in-

4. Descubrir en qué tipo de problemas es apropiado utilizar un sistema mul-

5. Conocer los aspectos básicos de un estándar de comunicación entre agen-

6. Entender la importancia de las ontologías en la comunicación dentro de

7. Conocer algunos mecanismos de cooperación entre los componentes de un

En la evolución histórica de la inteligencia artificial podríamos definir tres Ved también

de Newell y Simon, en el que se proponía formalizar un problema como un

1.1. Características de un agente

Aunque una gran parte de los investigadores actuales en inteligencia artificial

"Un agente es un sistema computacional situado en un cierto entorno, que es capaz de

• Reactividad: un agente tiene que saber reaccionar de manera rápida y apro-

• Capacidad de comunicación: un agente tiene que ser capaz de comunicarse

• Continuidad temporal: será habitual que un agente sea un proceso que se

• Planificación, razonamiento: para poder comportarse de manera inteligente

• Carácter: muchas veces es deseable que el agente tenga un comportamiento

(por ejemplo, un agente comprador no tendría que dar la información de

Hay que ser conscientes de que difícilmente podremos encontrar un progra-

1.2. Agentes deliberativos frente a agentes reactivos

Como acabamos de ver en el apartado anterior, la reactividad, o capacidad de

Dentro del concepto de entorno incluimos a otros agentes, usuarios humanos,

1.2.1. Agentes reactivos

Las características básicas de un sistema reactivo son las siguientes:

comportamiento inteligente sólo en sistemas de procesamiento de símbo-

• Habitualmente, los datos se reciben directamente a partir de sensores, sin

• El comportamiento está basado en reglas simples, que reciben un estímulo

• Los sistemas reactivos presentan una funcionalidad emergente. Los agentes

a) Robustez, tolerancia a fallos.

conocimiento tradicionales sólo funcionan en un dominio concreto, y su ren-

c) Tiempo rápido de respuesta.

Los sistemas reactivos también reciben ciertas críticas:

• Tienen una aplicabilidad muy limitada, a juegos y simulaciones simples.

• No tienen capacidad de planificación a medio plazo. Hay que notar que

• Es difícil validar este tipo de sistemas. El comportamiento que aparece en

1.2.2. Arquitecturas de sistemas reactivos

La arquitectura más básica posible es simplemente tener un conjunto de reglas

Los módulos se colocan en diferentes niveles, que trabajan de manera asíncro-

Figura 1. Arquitectura de subsunción de Brooks

Podríamos implementar un agente robótico simple con la arquitectura de subsunción.

1.2.3. Agentes deliberativos

Los agentes deliberativos están arraigados a la tradición clásica de los sistemas

• Hay que ir actualizando la representación del mundo, para no hacer razo-

1.2.4. Arquitectura BDI

• Creencias: conocimiento que tiene el agente sobre su entorno. Sería pare-

• Intenciones: subconjunto de los objetivos seleccionado por el agente para

Figura 2. Elementos básicos del modelo creencias-deseos-intenciones

La figura 3 presenta el aspecto de la arquitectura interna de un agente delibe-

Figura 3. Arquitectura BDI

El principal inconveniente de los agentes deliberativos es el coste computacio-

Eso provoca la aparición de agentes híbridos, que combinan una parte

1.3. Tipos de agentes

De manera parecida a cómo sucede con la definición del término agente, no

Las dos primeras categorías se estudiarán a continuación, y los agentes cola-

1.3.1. Agentes de interfaz