Une forme de négociation pour les systèmes multi-agents.

Une forme de négociation pour les
systèmes multi-agents.
Philippe Mathieu, Alain Taquet
Laboratoire d’Informatique Fondamentale de Lille
Upresa 8022 C.N.R.S., Université de Lille I
59655 Villeneuve d’Ascq Cedex.
Email : [email protected]
Tél : 03.20.43.45.04 Fax : 03.20.43.65.66
RÉSUMÉ. Nous présentons dans cet article une plate-forme générique permettant de prendre
en compte une forme de négociation. Cette plate-forme, réalisée sous forme d’une API Java,
permet de créer des agents intelligents capables de négocier entre eux à travers le réseau par
l’intermédiaire d’actes de langage. Nous définissons dans un premier temps le type de
négociation que nous prenons en compte, puis nous montrons comment représenter
l’ordonnancement des actes de langage par un graphe à base de règles de séquencement et
de backtracking. Ce graphe est ensuite parcouru et interprété à plusieurs niveaux
d’abstraction par des objets autonomes appelés micro-agents. Ces micro-agents s’associent
entre eux pour former des organisations indépendantes ayant chacune pour objectif de
résoudre une partie du problème. Le comportement global de l’agent au niveau
macroscopique provient de l’interaction entre ces organisations.
ABSTRACT. We present here a generic SMA framework whic is able to take into account a kind
of negociation. This framework, implemented as a JAVA API allows the user to create
intelligent agents able to negociate themself across the Internet by the way of speech acts. We
first define the kind of negociation we will use, then we show how to build an internal
representation of th speech acts order with a graph and sequencement rules and
backtracking. The graph is then used a several abstract levels by autonomous agents that we
call micro-agents. These micro-agents work in the same way to build independant
organizations which have their own objectives. Le global behaviour of the agent at the
macroscopic level provides from these organizations interactions.
: SMA, Agents, Négociation, renegociation, coordination, conflits, deadlocks,
actes de langage, règles de séquencement, contrat, ontologie, secrétaire virtuelle, ANTS .
MOTS-CLÉS
KEY WORDS:
SMA, Agents, Negotiation, renegotiation, coordination, conflicts, deadlocks,
speech acts, sequencement rules, contract, ontology, virtual secretary, ANTS.
Une forme de négociation pour les S.M.A.
1
1. Introduction
Depuis quelques années, les systèmes multi-agents (SMA) ont été étudiés selon
différentes approches. Que ce soit pour l’intelligence Artificielle Distribuée
[COH 90] [MEY 88] pour l’algorithmique distribuée [YOK 92] ou même pour la
robotique [BRO 86], les points d'études principaux ont été la communication et la
coopération entre les agents.
Si de nombreux environnements multi-agents ont pour objectif de faire coopérer
les agents en vue de la réalisation d'un but commun [MAT 95] Visiter Hoster
[SYC 89], d'autres systèmes en revanche utilisent des agents qui ont des intérêts
différents [KLE 91] [MEY 88] [ROS 96] comme dans les systèmes Baazar [SYC89]
et Kasbah de P Maes, ce qui nécessite une négociation entre eux. A l'instar d'une
négociation entre clients et fournisseurs qui utilisent des règles de négociation pour
converger vers une position médiane, les agents informatiques concurrentiels doivent
négocier avec leur environnement pour arriver à une position acceptée par tous.
La réalisation d'une société d'agents travaillant vers cet objectif pose de
nombreux problèmes. Ceux-ci interviennent lorsque l’agent doit choisir entre
plusieurs négociations concurrentes et/ou lorsque ces négociations conduisent à des
renégociations en cascade. Ces problèmes sont rendus plus difficiles encore par le
fait que les agents ont une connaissance incomplète de l’environnement et que cet
environnement évolue constamment. Par ailleurs l’utilité d’utiliser un agent au cours
des négociations est parfaitement justifié par l’explosion du nombre de messages
échangés entre les agents du fait de ce processus en cascade. Dans certains cas le
nombre de messages peut être en O(mn) si n est la profondeur du processus de
cascade et m le nombre d’agents impliqués dans une négociation..
Des environnements comme COOL, JAFMAS, AgentBuilder ont été proposés.
Toutefois, ceux-ci n’ont qu’une vue éloignée de la négociation et ne proposent pas
de système de renégociation automatique ni de mécanisme de gestion de conflit entre
négociations simultanées et ne prennent pas non plus en compte les deadlocks
pouvant survenir.
Pour prendre en compte ces différents points, nous proposons l’API ANTS qui
offre la possibilité de construire des agents négociant entre-eux des ressources
communes. Chaque agent est constitué de micro-agents créés dynamiquement en
fonction des besoins et qui se regroupent entre-eux pour résoudre une partie du
travail de l’agent global. Le processus de négociation entre les agents est modélisé
par un graphe à base de règles de séquencement et de backtracking. Le parcours de
ce graphe est ensuite interprété en fonction du rôle de l’agent dans la négociation
pour gérer les interactions entre négociations et éviter les deadlocks.
2. La négociation
Du point de vue de ANTS, le but d’une négociation est d’instancier un contrat,
formé d’un ensemble d’attributs, en fonction des préférences et choix de chacun des
agents impliqués. Nous distinguerons l’initiateur qui est l’agent qui propose le
contrat des autres agents appelés participants. L’initiateur dirige la négociation en
demandant des informations aux participants et en leur proposant des instanciations
partielles du contrat jusqu’à ce qu’il soit totalement instancié. Si cela est impossible
2
la négociation est annulée. Lorsque le contrat est pris, nous considérons qu’il est
possible de le modifier pour satisfaire d’autres contrats ce qui aboutit à des
renégociations en cascade et à un arbre de dépendance entre toutes ces négociations.
Définition : une négociation est un octuple (G,R,P,L,S,G,H,Ct) où :
1. G est l’ensemble des individus impliqués dans la négociation.
2. R est l’ensemble des ressources disponibles.
3. P est un ensemble de relations de préférences locales à chaque agent.
4. L est l’ensemble des actes de langage autorisés pour la négociation.
5. S est un ensemble de règles de séquencement.
6. G est un graphe dont les nœuds sont des règles de séquencement
7. H est l’histoire de la négociation
8. Ct est un contrat qui est l’objet de la négociation.
En outre, la mise en œuvre de la négociation entre agents doit respecter les
caractéristiques suivantes :
– Les intervenants doivent pouvoir être indifféremment humains ou logiques.
– Ils doivent tous utiliser le même langage pour communiquer.
– La communication doit être asynchrone et banalisée.
– Un agent ne doit pas avoir accès à la totalité de la connaissance des autres
agents.
– Si une proposition de contrat n'est pas acceptée, l'agent doit être capable de
modifier d'autres contrats et de négocier la modification de contrats des
autres interlocuteurs.
– Plusieurs négociations simultanées doivent être possibles.
– Certains contrats doivent être plus prioritaires que d'autres.
– Certains participants doivent être plus prioritaires que d'autres.
– L'humain peut commencer la négociation, laisser son agent continuer un
certain temps puis reprendre la négociation sans que les autres intervenants
ne se rendent compte du changement.
– Le système ne doit pas se bloquer.
La négociation doit donc être envisagée sous deux angles. Le premier aspect
consiste à définir les actes de langage communs à toute négociation et à proposer un
mécanisme qui permette de gérer leur séquencement cohérent. Ce premier niveau
d’interactions est appelé niveau macroscopique. Le deuxième aspect doit prendre en
compte les relations entre des négociations en cascade ou en conflit, ce sera le
niveau microscopique. Nous détaillons ces points de vue dans les paragraphes
suivants.
3. Le niveau macroscopique
La conception d’une conversation doit conduire à une coordination des actes de
langage échangés par les agents. Winograd et Flores ont représenté une conversation
sous forme d’automate, un acte de langage étant lié à une transition. Une
conversation est considérée comme un tout selon ce modèle et ceci amène quelques
remarques. Certains cycles de l’automate ont la même forme bien que les actes de
Une forme de négociation pour les S.M.A.
3
langages soient différents, par exemple le vote des agents. Peut-on représenter ces
cycles de manière générique en proposant des objets structurés ? Comment
représenter les relations entre négociations en particulier les liens de dépendances en
cas de renégociations en cascade ?
La notion d’automate suppose qu’une conversation soit dirigée par les actes de
langage, les transitions de l’automate sont donc naturellement associés aux actes de
langage. Cela revient à mettre en second plan les intentions des agents. Nous
proposons de mettre en avant ces intentions, les actes de langage devenant alors des
moyens de réalisation de ces intentions. L’accent est mis sur la logique de la
conversation et non sur les données échangées. Dans cette optique, Sycara [SYC 89]
introduit la notion de fragments de plans utilisables par les agents, Ferber [FER 95]
définit le formalisme Brick qui permet d’associer des réseaux de Petri pour
concevoir une conversation. Il y a donc naturellement besoin de composants
élémentaires et génériques représentant chacune des intentions des agents : une
demande d’information, le signalement d’un échec ou d’un succès se font toujours
de la même façon, de même un processus de vote est générique et n’a pas à être
redéfini à chaque nouvelle conversation ni même plusieurs fois dans la même
conversation. Nous appelons un tel composant une règle de séquencement. Une
négociation sera représentée par un graphe orienté ayant pour nœuds les règles de
séquencement.
Soit c un contrat formé d’un ensemble d’attributs ci de domaine Di. Notons < i | c
> l’attribut ci du contrat c et | ci > un contrat partiellement instancié tel que ∀j ≤ i < j
| ci > ∈ Dj et ∀j > i < j | ci > = ? ( ? représente un attribut non instancié).
L’application d’une règle de séquencement ri à | ci - 1 > a pour but de déterminer
l’ensemble des valeurs possibles de ci. L’initiateur effectue alors un choix Ci parmi
ces valeurs s’il y en a, sinon il backtrack pour revenir au dernier choix. Lorsque le
choix est fait, il y a activation de la règle ri + 1 au nouveau contrat | ci >. Nous
pouvons maintenant donner une définition de la négociation :
Définition : La négociation d’un contrat est une suite d’application de règles de
séquencement (r1 , … , rn ) et de choix (C1 , … , Cn ) tel que : ∀ i < i | Cn en … C1
e1 | c0 > ∈ Di
La figure 1 représente un graphe de séquencement correspondant à une
négociation. Les rectangles représentent des règles de séquencement prédéfinies
dans ANTS tandis que les ovales représentent des règles particulières à une
application, par exemple deux phases successives de vote correspondant à
l’instanciation de deux attributs d’un contrat. L'ordre d'évaluation est représenté sur
les arcs.
La conversation commence ici par l’activation de la règle start qui active la règle
accept (a1) avec un contrat initial. En cas de succès cette dernière active la règle
confirm, en cas d’échec il y a backtracking et activation de la règle X (a2) puis
activation de Y pour les instanciations de l’attribut négocié par X. La négociation
peut être annulée en cas de backtracking de la règle X, ce qui conduit à l’activation
de la règle annul (a3).
Dans les règles particulièresà une application, la règle X instancie une information i à
une valeur i1 parmi l'ensemble des choix possibles. La règle Y complète le contrat.
4
Start
a3
a2
X
a1
Y
annul
b2
b1
Restart
Accept
Confirm
Figure 1. Un graphe de séquencement
ANTS encapsule une règle de séquencement dans une méta-règle activée par un
méta-contrôleur et selon l’attitude de l’agent dans le processus de négociation, une
règle de séquencement doit définir une des deux interfaces suivantes :
public interface InterfaceInitiator{
public int activate();
public int receiveAnswer(KQMLMessage mess);
public Vector nextContracts();
}
public interface InterfaceParticipant{
public int receiveMessage(KQMLMessage mess);
public boolean canFilter(KQMLMessage mess);
public int validateNextMessage(KQMLMessage mess);
}
Les valeurs retournées indiquent l’état de la règle de séquencement active :
WAITING si l’initiateur attend des réponses, SUCCESS si un attribut a été instancié
ou FAILED si l’attribut ne peut pas être instancié. Dans le cas des règles prédéfinies
des valeurs particulières peuvent être également retournées : ACCEPT si un contrat
est accepté ou deux valeurs qui indiquent que l’on a atteint une règle terminale :
TERMINATESUCCESS et TERMINATEFAILED. La règle de confirmation d’un
contrat s’écrit donc de cette manière :
public class ConfirmRule extends SequencementRule
implements InterfaceInitiator, InterfaceParticipant{
public int activate() {
broadcastContract("confirm");
return TERMINATESUCCESS;
}
...
}
Une forme de négociation pour les S.M.A.
5
Le cas des règles de séquencement de type vote est rendu générique en utilisant
la notion de modèle. Les règles représentés en ovale sur la figure 1 représentent ce
modèle. Cela rend ces règles génériques et facilement réutilisables puisqu'il suffit
d'implémenter le modèle. L’initiateur doit implémenter un VoteModel et
l’initiateur comme les participants doivent implémenter un NegotiationModel
spécifiques à l’application.
La manière d’effectuer une négociation est définie par une ontologie qui
s’instancie en fonction d’un contrat:
public abstract class Ontologie{
public Ontologie(AgentNegotiator ag, Contract c) {
contract = c;
agentNegotiator = ag;
graph = getGraph();
name = getName();
}
public abstract Graph getGraph();
public abstract String getName();
. . .
}
L’agent peut alors négocier un contrat avec une ontologie particulière :
public void negotiate (String ont, Contract c) {
…
MicroAgent ma;
ma = new MicroAgent(id,this,ontologie(ont, c));
ma.setAttitude(new But(ma));
ma.negotiate(c);
}
Montrons maintenant comment à partir de l’interprétation de certains actes de
langage il est possible de gérer les interactions entre négociations.
4. Le niveau microscopique
Deux types d’interactions entre négociations sont à distinguer. Le premier type
appelé interactions horizontales est du au fait que la négociation principale peut
entraîner des renégociations en cascade. Le second type appelé interactions
verticales vient du fait que certaines négociations peuvent entrer en conflit. Nous
décrivons dans les paragraphes suivants les techniques mises en œuvre pour gérer ces
deux types d’interactions.
4.1. Les interactions horizontales
6
Remarquons tout d’abord que le déroulement d’une négociation ne dépend pas
de la raison pour laquelle elle a été engagée. Un agent A peut initier une négociation
N1. Cette négociation peut être bloquée par un contrat déjà pris sur les ressources
demandées par N1. Une autre négociation N2 est alors créée pour modifier le contrat
déjà pris. Dans les deux cas les négociations se feront suivant le même schéma, par
contre les effets seront différents. Le succès de la négociation induite ne doit pas
s’accompagner de la modification du contrat mais tous les agents impliqués dans ce
contrat doivent avertir A que la modification est possible. Inversement le succès de
A entraîne la validation de la modification induite. Nous devons donc distinguer la
manière de négocier et les effets de la négociation c’est à dire séparer le pourquoi du
comment. Cette distinction est prise en compte en définissant un deuxième niveau
d’abstraction constitué d’une trilogie MAC : modèle-attitude-contrôleur.
– Le méta-modèle est formé par l’ensemble des méta-règles, des négociations
induites et de la négociation qui l’a induite s’il s’agit d’une renégociation..
– Le méta-contrôleur active les différentes règles du contrôleur du métamodèle. Celles ci renvoient une valeur indiquant l’état de la négociation :
WAITING si la négociation n’est pas terminée, SUCCES ou FAILED
lorsque la négociation (d’un et un seul contrat) est terminée.
– La méta-attitude est un ensemble de méthodes qui définissent les actions à
effectuer en cas de succès ou d’échec d’une négociation ou d’une
renégociation ainsi que les actions à réaliser au démarrage de la négociation.
Définition : Un système MAC possède donc les caractéristiques suivantes :
– Il a un but : ce pourquoi la négociation a été engagée.
– Il est capable de raisonnement.
– Il a une attitude qui dépend du contexte de création.
– Il a une vue partielle de son environnement.
– Il est en relation avec d’autres systèmes MAC
Ces caractéristiques sont justement celles que doit posséder un agent. Nous
pouvons maintenant donner une définition d’un micro-agent : Dans le système
ANTS, un micro-agent est un système MAC.
Nous pouvons distinguer 6 attitudes :
But : l’agent veut négocier un contrat
Engagement : l’agent répond à une demande de contrat.
ButModification : l’agent veut modifier un contrat dont il est responsable.
ButDelegation : l’agent veut modifier un contrat pour le compte de quelqu’un
d’autre
5. EngagementModification : l’agent répond à une demande de modification de
contrat
6. EngagementDelegation : l’agent veut modifier un contrat dont il n’est pas
responsable.
1.
2.
3.
4.
Par la suite nous parlerons de l’attitude comme du micro-agent : nous dirons
qu’un But est un micro-agent ayant une attitude de type But.
Sur la figure 2 les droites horizontales représentent l'ensemble des ressources
existantes. Sous la droite on trouve le contrat déjà pris (1 seul par segment) et au
Une forme de négociation pour les S.M.A.
7
dessus se trouvent les contrats en cours de négociation (éventuellement plusieurs
superposés sans l'ordre de leur traitement futur, le plus bas étant celui traité en
premier). Chaque droite avec ses micro-agents représente la vue subjective du
monde par l'agent.
Lorsqu’un agent « négociateur » veut négocier un contrat, il crée un But et les
participants créent des Engagements. Des liens de dépendances existent donc entre le
But et les Engagements. Les Engagements doivent accepter pour que le But puisse
confirmer le contrat. Ces liens de dépendances sont des liens virtuels puisque les
micro-agents sont localisés chez des agents différents. Graphiquement (figure 2) ces
liens de dépendances seront représentés par des flèches en pointillés qui partent du
But vers les Engagements. Ces micro-agents peuvent à leur tour créer, chez l’agent
où ils se trouvent, des ButModification ou des EngagementDelegation pour modifier
des contrats déjà négociés. Les micro-agents créateurs dépendent alors des microagents qu’ils ont créés. Ce lien de dépendance est représenté explicitement (par des
flèches pleines) puisque les micro-agents créés et créateurs sont localisés chez le
même agent. Un ButModification va alors induire des Engagement-Modification
chez d’autres agents d’où des liens virtuels de type But / Engagement. Un
EngagementDelegation va induire chez le responsable un ButDelegation dont il
dépend, c’est un lien virtuel. Ce ButDelegation induit alors des
EngagementModification et ainsi de suite.
Un graphe virtuel, réparti sur tous les agents, constitué de liens réels ou virtuels
entre micro-agents est donc construit en réaction à la demande initiale de contrat.
Cette demande initiale est un But et il n’y a donc qu’un seul But dans un graphe de
dépendance. L’évolution de ce graphe se fait en trois temps : une phase d’extension
pour déterminer le plan global aux agents, une phase d’acceptation où chaque microagent avertit le micro-agent dont il dépend qu’il accepte la modification et une phase
de confirmation où chaque micro-agent confirme la modification au suivant.
Agent A
B1
Agent B
C2
Agent C
GD
6
GM
3
CM
4
GM
7
CM
8
CD
5
figure 2. La négociation d’un contrat avec renégociations induites
Par exemple, la figure 2 représente un graphe de dépendances (lignes
pointillées) entre trois agents A, B et C et les micro-agents correspondants .
8
L’agent A veut négocier un contrat avec B. A crée un But (B1) et B crée un
engagement (C2). Le But (B1) attend la réponse de l’engagement (C2).
B doit modifier un contrat déjà pris pour prendre (C2). B est responsable de ce
contrat pris avec C. Il crée donc un ButModification (GM). L'engagement (C2)
dépend alors de la réponse de (GM), ce qui est représenté par une flèche qui part de
(C2) et dirigée vers (GM). C crée un EngagementModification (CM). Le
ButModification (GM) ne dépend que de (CM).
C doit alors modifier un autre contrat pris avec A. C n’est pas responsable. Il crée
donc un EngagementDelegation (CD). Une flèche part de (CM) vers (CD) pour
indiquer que (CM) dépend de (CD). A crée un ButDelegation (GD).
L'EngagementDelegation (CD) dépend alors de (GD). A doit modifier un contrat
dont il est le responsable et crée un ButModification (GM). Comme pour (CM) et
(CD) une flèche relie (GD) et (GM). B crée un EngagementModification (CM). Le
ButModification (GM) dépend de (CM).
Les conflits sont inévitables lorsque plusieurs négociations sont engagées et si
nous nous sommes limités dans ce paragraphe aux conflits entre contrats déjà
négociés et les micro-agents, des conflits peuvent survenir entre micro-agents, ce
type d’interaction est appelé interaction verticale.
4.2. Les interactions verticales
Lorsque deux négociations différentes entrent en conflit, une seule des deux doit
continuer en fonction des préférences de l’utilisateur. Ce qui ne veut pas dire que
l’autre est en échec, elle ne le sera que si la première est validée. Nous dirons que le
micro-agent concerné par la négociation préférée capture l’autre, il est dit libre et
continue sa négociation. Un micro-agent peut être capturé par plusieurs micro-agents
et inversement, plusieurs micro-agents peuvent être capturés par un seul micro-agent.
Ce processus de capture est récursif et conduit à une structure de graphe à ne pas
confondre avec le graphe d’interactions. Ce graphe est modélisé par une surface et
un ensemble ordonné de fibres (figure 3). Lorsqu’un micro-agent active la règle
accept, il demande à un agent appelé environnement de l’insérer sur la surface qui
contient tous les micro-agents libres. Les micro-agents capturés sont placés sur la
fibre du dessous et ceci de manière récursive.
Nous avons introduit les notions de micro-agent, négociateur et environnement
afin de résoudre de manière séparée les interactions horizontales et verticales.
Puisque le graphe de dépendance d’une négociation est réparti chez plusieurs agents
ayant chacun attribué des priorités différentes, des interactions croisées peuvent se
produire.
Par manque de place, nous ne détaillerons pas ce type d’interaction. Notons
toutefois qu’il doit être évité car il conduit au blocage des négociations ou montre un
comportement irrationnel des agents. Le système Ants affecte une marque appelée
justification à chaque négociation pour éviter les interactions croisées.
Une forme de négociation pour les S.M.A.
9
Définition : une négociation est entièrement définie par
– Un contrat
– Un graphe de séquencement formé de règles de séquencement
– Un environnement constitué d’un monde (les contrats déjà négociés) et d’une
méthode calculant la priorité d’une négociation.
Micro-agent
communicateur
Interactions
horizontales
(coordination)
négociateur
Interactions
verticales (conflit)
environnement
Surface
fibres
Figure 3. Architecture de Ants
L’interprétation à de multiples niveaux du graphe de séquencement permet de
contrôler la négociation et de gérer de façon transparente au concepteur
d’application les conflits et les négociations en cascade. De plus une bibliothèque de
règles de séquencement permet de définir rapidement le graphe de séquencement.
Afin de valider notre système, montrons maintenant comment implémenter une
secrétaire virtuelle au dessus de la couche ANTS.
5. Une application : la secrétaire virtuelle
La secrétaire virtuelle a déjà été étudiée dans d’autres travaux [SEN 95] [JEN 95]
[KOZ 93] mais pas sous l’aspect négociation. Contrairement à Sen, nous ne nous
intéressons pas ici à montrer qu’une stratégie est meilleure qu’une autre mais au fait
que ANTS est suffisamment générique pour implémenter ces différentes stratégies.
Par ailleurs ANTS gère automatiquement les renégociations et les priorités entre
rendez-vous sans que le concepteur n’ait à l’écrire.
Le monde est ici l’agenda de la secrétaire. Les priorités pour les personnes, les
jours et les heures sont placées dans un fichier et sont modifiables par l’utilisateur au
moyen d’une interface. La priorité d’un rendez-vous est la plus grande des priorités
des participants. Les agents proposent une date de rendez-vous en choisissant le jour
puis l’heure qu’ils préfèrent. L’agent initiateur choisit alors la date préférée par
l’ensemble des agents. D’autres stratégies sont bien sûr possibles : par exemple les
agent peuvent vouloir proposer des dates sans avoir à voter le jour. Dans ce cas il n’y
10
aura qu’à définir un autre graphe de négociation. C’est aussi le cas si le concepteur
souhaite un modèle de type ContractNet.
Deux règles de séquencement spécifiques PJ (propose jour) et PH (propose
heure) sont définies comme sous classe de la classe VoteRule :
public class PJ extends VoteRule {
public void init() {
if(initiator()) voteModel = ontologie().voteModel();
negotiationModel = ontologie().negotiationModel(); }
public Contract nextContract(Object o) {
GregorianCalendar d;
d = (GregorianCalendar)((GregorianCalendar)o).clone();
Rdv rdv = (Rdv) contract.clone(); rdv.setDate(d); return rdv;
}
public String performative() {return "propose-jour";} …}
Les modèles negotiationModel et voteModel implémentent les méthodes
getChoice et makeChoice pour pouvoir proposer un jour ou une heure. N’étant pas
essentiels à la compréhension nous ne les détaillons pas. L’ontologie défini les
modèles et le graphe de la négociation qui est celui de la figure 2 où X est remplacé
par PJ et Y par PH.:
public class OntologieList extends Ontologie
implements InterfaceOntologieVote
{
public OntologieList(Secretary ag,Contract c) {
super(ag, c); negotiationModel = getNegotiationModel();
voteModel = getVoteModel(); }
public Graph getGraph() {
String start = "ants.lib.rules.StartRule"; . . .
Graph graph = new Graph(); graph.addRule(start);
graph.addRule(accept);
graph.addSuivant(start, accept); . . . return graph;} …}
Il reste à implémenter l’agent Secrétaire en relation avec un agent
Communicateur. Cet agent peut communiquer par Mail, par sockets ou être un agent
basé sur d’autres plates-formes comme MADKIT[FER 95] ou MAGIQUE [MAT 95]
public class Secretary extends AgentNegotiator {
SecretaryFrame frame;
public Secretary(String name, AgentCommunicator comm) {
super(name, comm); frame = new SecretaryFrame(this); }
public WorldModel setWorldModel () { return new Agenda(name()); }
public Ontologie ontologie(String ont, Contract c){
if (ont.equals("OntologieOne")) return new OntologieOne(this, c);
else return new OntologieList(this, c); }
public int priority(Contrat c) {. . .}
}
A titre indicatif
MADKIT [FER 95]:
nous montrons comment cette secrétaire fonctionne avec
Une forme de négociation pour les S.M.A.
11
public class MadkitCommunicator extends AgentCommunicator {
…
protected void activate() {
if (isGroup("Secretaries")) joinGroup("Secretaries");
else foundGroup("Secretaries");
requestRole("Secretaries",name); }
public void sendMessage(String nname, KQMLMessage m) {
sendMessage(getAgentsWithRole("Secretaries",nname)[0],m) ; }
}
Figure 4. Interface de la secrétaire virtuelle
Une interface permet de prendre des rendez-vous et de consulter son agenda
(figure 4). Le passage des messages s’effectue par mail, Le Communicateur lit toutes
les deux secondes le courrier pour déterminer si un mail a pour champ subject
« private_for_agenda ». Si oui le message est retiré et traité par la secrétaire.
Toutes les simulations réalisées en environnement hétérogène formé de stations
Unix, PC et MAC ont permis de vérifier la validité de notre modèle en vraie
grandeur. Un prototype du système peut être téléchargé à l’adresse
http://www.lifl.fr/SMAC rubrique ANTS.
6. Conclusion
Après avoir défini le type de négociation auquel nous faisons référence, nous
avons présenté dans cet article un modèle d’agents adaptés à cette forme de
12
négociation. Dans ce système nommé ANTS, les agents peuvent être humains ou
cognitifs ce qui est permis par l’utilisation d’actes de langage spécifiques.
La modélisation d’une négociation par un graphe de séquencement puis
l’interprétation de ce graphe à des niveaux d’abstraction successifs nous a permis de
modéliser le système Ants sous la forme de micro-agents en interactions entre eux et
avec un agent environnement. Le concepteur d’agents doit ici simplement définir un
graphe de séquencement et les règles spécifiques à une négociation particulière. Ants
gère de manière transparente le mécanisme de renégociation de contrats, les conflits
et les deadlocks pouvant survenir, contrairement à d’autres environnements comme
COOL, Jafmas et AgentBuilder. Par ailleurs la conception est facilitée par
l’utilisation d’une bibliothèque de règles génériques. Pour évaluer notre architecture,
nous l’avons appliquée à la secrétaire virtuelle en définissant plusieurs ontologies
possibles.
L’utilisation d’agents pour ce type de négociation est justifié par le nombre de
messages échangés : supposons que la négociation d’un contrat s’effectue toujours
avec m participants et que pour négocier un contrat C chaque participant soit amené
à renégocier un autre contrat, ceci à une profondeur n. Le nombre de nœuds de l’arbre
de dépendance sera alors égal à mn. D’autres aspects sont en cours d’intégration dans
le système Ants : les contraintes sont pour l’instant locales à chaque micro-agent
mais il est possible que des contrats soient liés et que la modification de l’un entraîne
la modification d’un autre (par exemple des rendez-vous le même jour). D’autre part,
la négociation d’un contrat c1 peut entraîner la renégociation d’autres contrats c2 et
c3. Ces derniers ainsi que leurs conséquences ne doivent pas entrer en conflit.
L’introduction de micro-agents superviseurs permet de prendre en compte ces
contraintes globales.
7. Bibliographie
[BRO 86] R.A. BROOKS. A robust layered control system for a mobile robot. IEEE Journal
of Robotics and Automation 2(1) : 14-23,1986
[COH 90] P.R. COHEN AND H.J. LEVESQUE. Intention is choice with commitment. Artificial
Intelligence, 42 : 213-261, 1990
[FER 95] J. FERBER. Les systemes multi-agents. Vers une intelligence collective. ISBN
272960572X. InterEditions.
[JEN 95] N. JENNINGS AND A. JACKSON. Agent-based Meeting Scheduling : A design and
Implementation, Electronic Letters, The Institute of Electronic Engineering, 31(5) : 350352, March 1995
[KLE 91] M. KLEIN. Supporting conflict resolution in cooperative design systems. IEEE
Transactions on System, Man, Cybernetics, 21(5) : 1379-1390, 1991.
[KOZ 93] R. KOZIEROK AND P. MAES. A learning Interface for Scheduling Meetings,
International Workshop on Intelligent User Interface, ACM, Orlando, Florida, January
1993
Une forme de négociation pour les S.M.A.
13
[LAN 92] LANDER S.E. AND LESSER. Negotiated Search ; Cooperative search among
heterogeneous expert agents. In AAAI-92 Workshop. Cooperation among heterogeneous
Intelligent Systems, 74-83.
[MAT 95] P.MATHIEU. Travail cooperatif et communication avancée. Actes des journées de
travail sur la notion de Multi-agents, 1995. Groupe Ganymède de la Région Nord-Pas de
Calais. Université des sciences et technologies de Lille. Publication n° 163
[MEY 88] MEYER R. A. CONRY, S.E. AND V.R. LESSER. Multistage negotiation in distributed
planning. In A. Bond and L.Gasser, editors, Reading In Distributed Artificial Intelligence,
pages 367-386. Morgan Kaufmann Publishers, Los Altos, CA, 1988
[ROS 96] J.S. ROSENSCHEIN AND G. ZLOTKIN. Mechanism for automated Negotiation in state
Oriented Domains. Journal of Artificial Intelligence Research. 5 : 163-238, 1996
[SEN 95] S. SEN. An automated distributed meeting scheduler, IEEE Expert, 1995
[SYC 89] K.R.SYCARA. Multiagent compromise via negotiation. In L. Gasser and M.N.
Huhns, editors, Distributed Artificial Intelligence, vol 2, pages 119-137. Morgan
Kaufmann Publishers, Los Altos, CA, 1989.
[YOK 92] YOKOO, DURFEE, ISHIDA, KUWABARA. Distributed constarint satisfaction for
formaliziong distributed problem solving. In Proocedings of the twelfth International
Conference on Distributed Computing Systems, Yokohama, Japan, June 1992