Agentes Inteligentes e
Sistemas Multi-agente
(UE11) Plataformas de Construção de
Agentes
Questões

O que são ferramentas para construção de agentes?
 Que tipos de agentes e que tipos de ferramentas
existem?
 Que tipo de sistemas (aplicações) posso construir
usando as referidas ferramentas?
Aplicações de Agentes (1/3)
1. Automação de processos
2. Aplicações Internet
 Comércio electrónico
o
•

Procura de informação distribuída


ao invés de concentrar a procura num só site, distribui agentes
pela rede para efectuarem a procura
Assistente Pessoal
o

agentes podem percorrer a rede e negociar em nome de quem
os enviou
agentes servem de vendedores de bens em serviços de
comércio electrónico
assistentes podem efectuar tarefas na rede em nome de seus
criadores
Negociação Segura
o
agentes podem mover-se para sites seguros com a finalidade de
negociar
Aplicações de Agentes (2/3)
Telecomunicações e Redes
 Serviços de Telecomunicações via Rede
o

agentes podem reconfigurar uma rede de
telecomunicações de forma dinâmica, mantendo-a
coesa
Simulações de serviços
o
agentes podem servir para a simulação de redes de
serviços
Aplicações de Workflow e Groupware
o
agentes móveis podem cooperar em nome de coparticipantes de um grupo de trabalho
Aplicações de Agentes (3/3)
Jogos
•
Os agentes controlam os personagens em jogos de
computador, sendo autónomos (e não scriptados)
Cinema
•
agentes podem controlar personagens de jogos (ex.
Senhor dos Aneis)
Aplicações de simulação de sociedades
•
agentes permitem simular multidões, sociedades de
animais (vida artificial), organizações, etc.
Ensino Assistido por computador
•
os agentes podem servir para criar personagens
para apoiar os alunos em sistemas de ensino
assistido, em particular à distância.
Plataformas de Agentes
1. Plataformas de agentes generalistas:
o
o
Plataformas que suportam e ajudam a criação de agentes
inteligentes, fornecendo uma estrutura que facilita a sua
implementação.
Plataformas genéricas para serem usadas em diversos
tipos de aplicações.
2. Plataformas de agentes específicas:
1. Agentes móveis: Ferramentas que suportam e ajudam a
criação de agentes móveis, fornecendo uma estrutura que
facilita a sua implementação (Ex. Aglets).
2. Agentes de interface: Plataformas que suportam a
criação de agentes de interface (ex. Microsoft Agent).
3. Agentes para jogos: Plataformas que permitem a criação
de agentes em ambientes de jogos (ou mesmo para jogos
especificos: ex. Bots do Unreal).
O que são Plataformas de Agentes?

Software para ajudar a criação de agentes e
sua infraestrutura, usado para o
desenvolvimento de aplicações baseadas em
agentes.
Estrutura Abstracta de uma Plataforma:
M. Luck
Agent Architecture
interaction
Agent
interaction
Environment
Agent
interaction
Agent
High level services (e.g. Agent communication language, middle agents,
coordination)
Low-level services (e.g. Discovery, message massing)
Agent building software
(e.g. Graphical environment)
Management services
(e.g. Visualization)
Ferramenta Abstracta

O primeiro passo é a separação entre os agents e a sua ligação com o
ambiente da comunicação e comunicação entre eles.

Assim, para cada ferramenta é necessário saber como é que um agente
é definido e construído, sendo que ele tem que perceber o ambiente e
agir de forma a modificar esse mesmo ambiente.

Alem disso há que considerar a forma como os agentes vão interagir
entre eles, e que mecanismos a ferramentas propociona para essa
comunicação se efectuar.

Finalmente há que considerar todo o tipo de ferramentas auxiliares
ajudam a construção dos agentes.
Standards: FIPA
Estrutura da Especificação da
Arquitectura Abstracta
Aplicações baseadas em
Agentes
Sistema de Comunicações
do Agente
Sistema de Gestão do
Agente
Sistema de Transporte de
Mensagens do Agente
Arquitectura
Abstracta
Estrutura da Especificação da
Arquitectura Abstracta

Arquitectura Abstracta: é a responsável por todas as
entidades abstractas necessárias para o
desenvolvimento de sistemas baseados em agentes.
Faz a distinção entre as entidades que são facilmente
representadas de uma forma abstracta (como por
exemplo o FIPA ACL) dos elementos que não são
genéricos a todos os sistemas de agentes (como a
mobilidade do agente ou o sistema de gestão do
mesmo)
 Na prática, a Arquitectura Abstracta da FIPA é a parcela
comum a todas as plataformas de agentes que a
implementam e que são compatíveis com as suas
especificações, como é o caso do FIPA-OS, JADE e
ZEUS
 Sistema de Transporte de Mensagens do Agente: é o
responsável pela entrega e pela representação de
mensagens no seio de ambientes e redes heterogéneas
com diferentes protocolos de transporte
Especificação da
Arquitectura Abstracta
Agente A
Plataforma de
Agentes
Message Transport Service
(MTS)
Mensagem ACL sobre MTS
Message Transport Protocol
(MTP)
Message Transport Service
(MTS)
Agente B
Plataforma de
Agentes
Especificação da
Arquitectura Abstracta

Sistema de Gestão do Agente: providencia a
framework dentro da qual os agentes FIPA existem e
operam. Estabelece o modelo lógico de referência
para a criação, registo, localização, comunicação,
migração e eliminação de agentes
Especificação da
Arquitectura Abstracta
Aplicação de
Agentes
Aplicação
Plataforma de Agentes
Agente
Sistema de
Gestão de
Agentes
(White Pages)
Message Transport Service
(MTS)
Message Transport Service
(MTS)
Plataforma de Agentes
Directory
Facilitator
(DF)
(Yellow Pages)
Especificação da
Arquitectura Abstracta


Sistema de Comunicações do Agente: a comunicação
entre agentes FIPA é baseada num modelo que
assenta basicamente na grande qualidade semântica
das mensagens, ou seja, toda a comunicação
encontra-se pré-definida e enriquecida
semânticamente para que seja bem entendida por
todos os agentes
A base da comunicação entre agentes FIPA é
conseguida atrabés do uso de actos comunicativos ou
performativas, como request, inform ou refuse,
independentes do conteúdo global da mensagem em
si
Plataformas Generalistas: que seguem o
modelo da FIPA

Jade (vai ser dada na aula prática)
 Zeus
 FIPA-OS
Zeus



Desenvolvido pela British
Telecommunications Labs
Plataforma para construção de
aplicações com agentes
colaborativos (Open Source)
Ambiente para o
desenvolvimento de
collaborative agents:
o
Agentes que
colaboram entre si para
atingirem um
determinado objectivo
Zeus: Objectivos


Manipulação directa:
• Programação visual
• “Pick & Choose”
Tecnologia standard:
• JAVA, TCP/IP, FIPA ACL...
Agentes Colaborativos

Questões chave:
• Descoberta da informação
- descobrir a existência, localização, capacidades e papéis
de outros agentes
•
Comunicação
- usar uma linguagem comum
•
Ontologias
- usar um vocabulário comum para conceitos iguais
•
Coordenação entre agentes
• Integração com sistemas existentes
Componentes do Tool-Kit
Agent Component Library


Os agentes desenvolvidos em Zeus deverão ser
deliberativos, assim raciocinando explicitamente
sobre os objectivos e acções a executar.
Para tal, a Zeus fornece um conjunto de componentes
para serem usados na construção de agentes:
•
•
•
•
•
Agentes de suporte
Mecanismo de comunicação
Motor de coordenação
Planeador genérico
Interface com sistemas externos
Agentes de Suporte



Resolvem o problema da descoberta de informação:
• Servidor de nomes + Facilitador
Constituem a infraestrutura da sociedade de agentes
ZEUS oferece uma biblioteca de relações
organizacionais pré-definidas:
• superior
• subordinado
• co-trabalhador
•
...
Mecanismo de Comunição

Resolve o problema da linguagem comum:
• Mensagens FIPA-ACL
• Comunicação ponto-a-ponto sobre sockets TCP/IP
Motor de Coordenação1

Resolve o problema da coordenação entre agentes:
• recebe objectivos
• invoca o planeador
• localiza os agentes produtores dos recursos
necessários
• solicita os seus serviços
• atribui tarefas
Motor de Coordenação2

ZEUS oferece uma biblioteca de estratégias de
coordenação pré-definidas:
• Master-slave
• Contract net
• Vickery auction
• Dutch auction
•
English auction
•
...
Interface com Sistemas Externos


A Zeus foi criada para interligar com aplicações
existentes...
Resolve o problema da integração com sistemas
existentes
• Motor de Coordenação pode utilizar API’s externas
(BD’s, ...)
• ZeusExternal interface class + modelo interno por
eventos
- integrar código externo com o agente
- verificar os eventos que ocorrem
- reagir a determinados eventos
Agente ZEUS Genérico
Sofware de auxílio à construção de Agentes
 The Agent Building Tools :
 Providencia uma ambiente de desenvolvimento
integrado através do qual os agentes são gerados e
especificados
 Providencia um conjunto de editores que guiam os
programadores através dos vários estádios da
metodologia de desenvolvimento de agentes do Zeus:
o Ontology Editor para definir os conceitos
o Agent Definition Editor para descrever os agentes logicamente
o Task Description Editor para descrever os atributos das tarefas
o Organisation Editor para definir as relações entre os agentes
o Co-ordination Editor para seleccionar o conjunto de protocolos de
coordenação com os quais os agentes devem ser equipados
Ontology Editor para
definir os conceitos
Editor de
Ontologias
Agent Definition Panel
para descrever os
agentes logicamente
Editor de
Definição
do Agente
Editor de Tarefas para
descrever os
atributos das tarefas
Editor de
Descrição
de Tarefas
Organisation
Editor para
definir as
relações entre
os agentes
Editor de
Organização
Co-ordination Editor
para seleccionar o
conjunto de
protocolos de
coordenação com os
quais os agentes
devem ser equipados
Editor de
Coordenação
Ferramentas de Visualização
 The Visualisation Tools :
 Ambiente de runtime que permite efectuar a
observação e o debug das aplicações
 Recolhe informação sobre a actividade dos agentes,
interpreta-a e mostra os resultados em tempo real
 Solução para o difícil e crescente problema da
análise e debug de sistemas multi-agent, onde os
dados, informação de controlo e processos activos
encontram-se distribuídos
Visualizador de Sociedades
Relatórios
Estatística
Visualizador de Agentes
Metodologia de Desenho
Comentários Finais (ZEUS)

Plataforma ZEUS permite:
• Configurar um conjunto de agentes com
funcionalidades e comportamentos distintos
• Organizar os agentes utilizando relações
organizacionais oferecidas pela plataforma
• Equipar cada agente com mecanismos de
comunicação e coordenação
• Definir para cada agente código específico
• Gerar automaticamente os executáveis
FIPA-OS



A plataforma FIPA-OS foi a primeira implementação Open
Source da FIPA
Iniciada em Agosto de 1999
Tipos de agentes básicos suportados:
- Reactivo: reage a mensagens ACL provenientes
de outros agentes no ambiente
- Proactivo: o agente consegue decidir quando
deve iniciar a interacção com outros agentes
(só para objectivos simples, como registar-se
num servidor de registo!)
- Social: reactivo e proactivo
- Autónomo: cada agente possui várias threads
de controlo
FIPA-OS
FIPA-OS : aspectos genéricos

Qualquer plataforma FIPA contém:
- Directory Facilitator (DF): Tipo de agentes que
fornecem o serviço de “páginas amerelas” a outros
agentes (localização de serviços e serviços de
registo)
- Agent Management System (AMS): gere o ciclo de
vida de um agente na plataforma, enquanto
providencia serviços de “páginas brancas” a outros
agentes (localização de agentes, nomes e serviços
de controlo de acessos)
- Message Transport Service (MTS):
- MTP (Message Transport Protocol) numa determinada
plataforma (varios protocolos)
- ACC (Agent Communication Channel) para
comunicar entre plataformas
FIPA-OS- os agentes
Componentes
específicos do
FIPA-OS
FIPA-OS




•
Agent Shell: para além dos componentes mandatórios presentes no
Modelo de Referência da FIPA, a distribuição da FIPA-OS inclui um
template vazio de um agente denominado Agent Shell.
Através deste template podemos produzir os nossos agentes para
inter-operarem na FIPA-OS
Agent Management Service (AMS) (genérico): É um agente que faz o
papel de Serviço e é usado para controlar os ciclos de vida dos outros
agentes.
O agente registado informa o AMS sobre alterações significativas no
seu ciclo de vida e deixa o AMS controlar esse mesmo ciclo.
No caso de um agente rebelde que não se deixe controlar pelo AMS,
este invoca directamente operações do agente pela sua API
FIPA-OS



Task Manager: Cada tarefa de cada agente é uma tarefa distinta (ambiente
multi-tarefa)
As mensagens são redireccionadas automaticamente para o estado correcto
É possível interagir dentro da mesma tarefa
FIPA-OS




Parse Factory: sempre que um agente recebe uma
mensagem, o Parse Factory descobre em que linguagem
a mensagem vem escrita e carrega dinamicamente o
parser respectivo para que a conversão se faça sem
sobressaltos
A vantagem mais notória é a transparência com que se
pode encarar as mensagens, dando total atenção à
componente semântica destas
Uma vez que o parsing é feito automaticamente, para o
agente é como se estivesse a comunicar na mesma
linguagem! Não há necessidade de codificação sintática!
Só o conteúdo semântico interessa ao agente
FIPA-OS


Conversation Manager: Trata de todo o tráfego de conversas (não trata
mensagens individuais)
Simplifica a implementação das conversas, senão teríamos de associar
sempre a identificação das conversas à mensagem antes do agente enviar a
mesma
FIPA-OS


Comunicações: Remote Method Invocation (RMI) usado em comunicação no
interior da mesma plataforma (intra-plataforma)
IIOP com Voyager e SunIDL para comunicação para plataformas diferentes!
(inter-plataforma)
FIPA-OS:
Exemplo
Agência A
Plataforma
móvel
Agência B
JADE
Java Agent DEvelopment Framework




Desenvolvido pelo CSELT da Universidade de Parma –
Itália e actualmente distribuído pela TILab (Telecom
Italia Labs)
Framework para o desenvolvimento de aplicações
baseadas em agentes de acordo com as especificações
FIPA para sistemas multi-agent
Pode ser visto como um middle-ware de agentes que
implementa uma plataforma de agentes e um framework
de desenvolvimento
Está conforme a FIPA 97/2000
Agentes em JADE



Não define nenhuma arquitectura de agentes para os agentes
(de forma diferente da Zeus)
A propriedade de autonomia é interpretada como a
implementação dos agentes como objectos activos (que têm a
sua própria thread de execução).
Os agentes comunicam assíncronamente através de
mensagens.
JADE: comunicação



Toda a comunicação entre agentes é efectuada através
da troca de mensagens
Mensagens são representadas através da linguagem
FIPA ACL
Lida com todos os aspectos que não fazem parte do
agente em si e que são independentes das aplicações,
tais como:
o Transporte de mensagens
o
o
Codificação e parsing
Ciclo de Vida dos agentes
JADE
Mais informação nas aulas práticas!!!!
JACK


JACK Intelligent Agents™, is an environment for building,
running and integrating commercial-grade multi-agent
systems using a component-based approach. JACK is based
upon the company's Research and Development work on
software agent technologies.
Its framework supplies a high performance, lightweight
implementation of the BDI architecture,and can be easily
extended to support different agent models or specific
application requirements.
JACK Features
JACK Intelligent Agents is a new concept — an environment for
building, running and integrating commercial Java-based multiagent software using a component-based approach. It incorporates
significant advances in Agent Research and Software Engineering
and provides the core architecture and infrastructure for developing
and running software agents in distributed applications.
Overview of JACK Architecture
Components
Of
JACK
JACK Agent language



The most important part of JACK is the JACK Agent
language.
JACK Agent Language is a programming language
that extends Java with agent-oriented concepts such
as Agents, Capabilities, Events, Plans, Agent
Knowledge Bases (Databases), Resource and
Concurrency Management.
This language has three main extensions to pure JAVA
language, and the current version supports the BDI
model and SimpleTeam, an extension to support teambased reasoning.
JACK Agent language’s 3 main extensions to
Java(1)
1. A
set of syntactical additions to its host language:
a small number of keywords for the identification of the
main components of an agent (such as agent, plan and
event);
a set of statements for the declaration of attributes and
other characteristics of the components (for instance,
the information contained in beliefs or carried by
events). All attributes are strongly typed;
a set of statements for the definition of static
relationships(for instance, which plans can be adopted
to react to a certain event);
a set of statements for the manipulation of an agent's
state(for instance, additions of new goals or sub-goals
to be achieved, changes of beliefs, interaction with
other agents).
JACK Agent language’s 3 main
extensions to Java(2)





A compiler that converts the syntactic additions described above into
pure Java classes and statements that can be loaded with, and be
called by, other Java code. The compiler also partially transforms the
code of plans in order to obtain the correct semantics of the BDI
architecture.
A set of classes (called the kernel) provides the required run-time
support to the generated code. This includes:
automatic management of concurrency among tasks being pursued
in parallel (Intentions in the BDI terminology);
default behaviour of the agent in reaction to events, failure of actions
and tasks, and so on; and
native lightweight, high performance communications infrastructure
for multi-agent applications.
Most important concepts in JACK Agent
Language(1)
The Agent class:
embodies the
functionality
associated with
a JACK
intelligent agent
agent AgentType extends Agent {implements interface}
{
#{private,agent,global} data Type Name (arglist);
#handles event EventType;
#uses plan PlanType;
#posts event EventType reference;
#has capability CapabilityType reference;
//data members (Java data structures)
:
//Constructor method
AgentType(arglist)
{
super("agent name");
:
}
//Java methods that implement agent functionality
:
}
Most important concepts in JACK Agent
Language(2)
event EventType extends Event
{
// Any members required as part of the event structure.
// Any declarations required to give the agent access to data or
// beliefsets within the enclosing agent or capability.
#uses data DataType data_name;
// Any #posted when declarations required so that the event
// will be posted automatically when certain belief states arise.
#posted when { condition }
// Declarations specifying how the event is posted within an agent.
// You can have as many posting methods as you require.
#posted as postingMethodName(parameter list)
{
// method body
}
}
The Event class:
the originators
of all activity
within JACK
Normal Event
BDI Event
Most important concepts in JACK Agent
Language(3)
The Plan class:
describes a
sequence of
actions that an
agent can take
when an event
occurs
plan PlanType extends Plan
{
#handles event EventType eventref;
#posts event EventType eventref2;
#sends event MessageEventType eventref3;
#uses interface InterfaceName ref;
#reasoning method pass(){
// Post-processing and clean up steps when the plan has
// succeeded
}
#reasoning method fail(){
// Post-processing and clean up steps when the plan has failed
}
static boolean relevant (EventType eventref){
}
context(){
}
body(){
}
}
Most important concepts in JACK Agent
Language(4)
The Capability class: represent functional aspects of an agent that
can be plugged in as required
capability CapabilityType extends Capability [implements Interface]
{
// JACK Agent Language declarations specifying the functionality
// associated with the capability.
#handles external {event} EventType;
#posts event EventType {reference};
#posts external event EventType {reference};
#private data Type name({args});
#exports data Type name({args});
#imports data Type name();
#uses plan PlanType;
#has capability CapabilityType reference;
// other data members and method definitions
}
Most important concepts in JACK Agent
Language(5)
The BeliefSet class: the maintenance of agent beliefs,which are central
to the notion of BDI
beliefset RelationName extends ClosedWorld
{
#key field FieldType FieldName;
#value field FieldType FieldName;
#posts event EventType ref;
#indexed query queryName( parameter list);
#function query ReturnType queryName(parameter list) { method body}
public void addfact(Tuple t,BeliefState is){}// called when a belief is added
public void newfact(Tuple t,BeliefState is,BeliefState was){}// called when a new belief is added
public void delfact(Tuple t,BeliefState was){}// called when a belief is removed
public void endfact(Tuple t,BeliefState was,BeliefState is){}// called when a belief is removed
public void modfact(Tuple t,BeliefState is,Tuple knocked,Tuple negated){}// called when a belief is
modified
public void moddb(){}// catch-all
}
A simple example
public capability PaintRequesting extends
Capability {
public agent Part extends Agent {
#posts event PaintRequest ev;
#handles external event PaintRequest ;
#has capability PaintRequesting paintreqesting_cap;
#uses plan SendPaintCommand;
public void submitPaintRequest(String robot, String colour)
#sends event Paint;
{
}
postEventAndWait(ev.request(robot,colour));
}
public plan SendPaintCommand extends Plan {
}
#handles event PaintRequest preqev;
public event Finished extends BDIMessageEvent {
#sends event Paint ev;
#posted as
body() {
finished(String c){
Paint q = ev.paint(preqev.colour);
}
@send(preqev.robot,q);
}
@wait_for(q.replied());
public event PaintRequest extends BDIGoalEvent {
Finished response = (Finished) q.getReply();
…
}
}
}
public agent Robot extends Agent {
public capability Painting extends Capability {
#has capability Painting painting_cap;
#handles external event Paint ;
#posts event Paint pp;
#sends event Finished;
}
#uses plan PaintSpecifiedNewColour;
#uses plan PaintAnyColour;
public event Paint extends BDIMessageEvent {
}
#set behavior Recover repost;
#posted as
paint(String c) {
public plan PaintSpecifiedNewColour extends Plan {
#handles event Paint ev;
…
#sends event Finished fev;
}
#uses interface Robot self;
}
static boolean relevant(Paint pp){…}
body() {
public plan PaintAnyColour extends Plan {
#handles event Paint ev;
self.setColour(ev.colour);
#sends event Finished fev;
@sleep(5);
#uses interface Robot self;
@reply(ev,fev.finished(self.paintColour));
}
body() {
}
}
}
public class Program {
public static void main( String args[] )
{
Robot robot1 = new Robot("robot23");
(1)Send Event:
PaintRequest
Part Agent
Part part1 = new Part("part1");
Part part2 = new Part("part2");
Part part3 = new Part("part3");
Part part4 = new Part("part4");
System.out.println("test with red");
(2)Use Plan:
SendPaintCommand
(5)Reply Event:
Finished
(3)Send Event: Paint
part1.submitPaintRequest("robot23","red");
System.out.println("test with no specified colour (null)");
part2.submitPaintRequest("robot23",null);
Robot Agent
System.out.println("test with white");
part3.submitPaintRequest("robot23","white");
System.out.println("test with white again");
part4.submitPaintRequest("robot23","white");
}
}
(4)Select Plan:
PaintSpecifiedNewColour
Using JACK


Based on JACK platform?
Adopt the concepts in JACK Agent language?
Agent
has
Capability
handle
send
Event
post
Event
use
Plan
use
Plan
data
member
BeliefSet
Resumo: JACK





Suporta a construção de agentes através de uma linguagem: “JACK
Agent Language”
A JACK Agent Language adopta conceitos de uma arquitectura BDI
A classe base “Agent” é central na liguagem JACK, e através dela
definem-se as crenças, os planos os eventos internos e externos
importantes para o agente, bem como as suas capacidades.
Os agentes seleccionam as acções que querem fazer usando um gestor
de tarefas (interno e que é dado pela plataforma).
As crenças dos agentes representam o que o agente acredita acerca do
mundo.
The benefits of JACK(1)



Based on JAVA runtime environment, supporting strong typing,
version control, and high performance
Modular approach for AI researcher: most components of the
framework can be tuned and tailored.
For engineers:
-rapid application development
-mental attitudes of BDI architecture
-distributed system development
-integration with legacy system
Conclusões
Notas finais:
Embora futuramente os agentes poderão ser bastante úteis para os
utilizadores humanos, realizando tarefas em nome desses utilizadores (e.g.
compras online, pesquisa de informação, pagamento de contas, etc.)...
 ainda
não há uma plataforma de facto que seja a
melhor e mais usada no mercado.
 As
plataformas existentes são ainda bastante
limitadas.

Por outro lado... os agentes não são os “salvadores da pátria”. Apenas são
apropriados na implementação de um certo tipo de aplicações (agentbased applications). Noutros domínios outras tecnologias serão mais
apropriadas