Intelligente Softwareagenten

Torsten Kwast, wi3113

Seminar Linux, WWW, Java und Internet
3. Grundlagen

5. Abschlußbemerkungen

4. Prinzipieller Aufbau / Implementierung

Übersicht

Anforderungen an Agenten
Eigenschaften der Umgebung
Agentenplattformen

Standardisierte Infrastruktur
Anforderungen an die Plattformen
Architektur von Multi-Agenten-Plattformen

Die Agentenkommunikationssprache KQML

Agent Communication Language (ACL)
KIF ("Knowledge Interchange Format")
KQML ("Knowledge Query and Manipulation Language")
Regeln der Kommunikation

Agentenarchitektur und -implementierung

Vorüberlegungen
Programmierung in RADL ("Recticular Agent Definition Language")

Anforderungen an Agenten

Bevor mit dem Design bzw. der Implementierung von Agenten begonnen werden kann, muß sich der Anwender erst einmal mit einigen Fragen auseinandersetzen. Das sind unter anderem:

Was soll der Agent leisten?

Welche Vorteile hat er gegenüber normalen Programmen (die möglicherweise den selben oder einen ähnlichen Zweck erfüllen)? Mit anderen Worten, warum sollte der Einsatz eines Agenten den Vorzug erhalten?

Welche Eigenschaften muß bzw. sollte er deshalb mindestens aufweisen?

In diesem Abschnitt sollen auf die letzte Frage konkrete Denkanstöße gegeben werden (und damit auch die ersten beiden Fragen zumindest teilweise mitbeantwortet werden).

Zu den elementaren Anforderungen zählt die Zuverlässigkeit (wie bei einem normalen Programm natürlich auch). Da jedoch Softwareagenten in der Regel komplexere Aufgaben übernehmen, haben mögliche Fehler natürlich auch viel größere negative Auswirkungen. Ein größtmögliches Maß an Zuverlässigkeit ist also unbedingt erforderlich.

Desweiteren muß ein Agent in der Lage sein, abstrakte Aufgabenstellungen zu verarbeiten, d.h. autonom zu handeln. Es ist ja gerade diese Tatsache, die dem Benutzer die meiste Arbeit abnimmt, da er nicht mehr Schritt für Schritt Instruktionen geben muß.

Dabei sollte er die Fähigkeit besitzen Probleme zu lösen, die

bis jetzt über den Möglichkeiten der Automatisierung lagen oder

bereits gelöst werden können, aber vom Agenten auf eine bessere Art und Weise (zum Beispiel schneller, effizienter, billiger, etc.)

Dinge wie Anpassungsfähigkeit, Einfachheit und Integrierbarkeit in bestehende Systeme zählen ebenso zu wünschenswerten Eigenschaften wie adaptives Verhalten des Agenten, d.h. aufgrund gemachter Erfahrungen seine Performance zu maximieren.

Eigenschaften der Umgebung

Weitere Überlegungen müssen hinsichtlich der Umgebung, in der der Agenten agieren soll, angestellt werden.

Ist die Umgebung zugänglich oder nicht zugänglich, d.h. kann sie vollständig erfaßt werden?

Ist sie deterministisch oder indeterministisch, d.h. sind bestimmte Informationen für den Agenten überhaupt verfügbar?

Muß der Agent vorausplanen, d.h. befindet er sich in einer episodischen Umgebung

In einer dynamischen Umwelt ist eine ständige Beobachtung notwendig, im Gegensatz zu einer statischen Umwelt.

Hat die Umgebung diskrete oder kontinuierliche Eigenschaften, d.h. ist die Menge der möglichen Eigenschaften endlich und sind die möglichen Handlungen beschränkt?

Agentenplattformen

Standardisierte Infrastruktur

Die Kommunikation zwischen Agenten, die Interoperation zwischen Agenten und System- und Anwendungssoftware sowie die Mobilität von Agenten erfordern eine standardisierte softwaretechnische Infrastruktur auf allen beteiligten Plattformen.
Die FIPA (Foundation of Physical Intelligent Agents) hat es sich zum Ziel gesetzt, die Infrastruktur zu definieren. Sie ist eine gemeinnützige Organisation, die 1996 von namhaften Firmen gegründet wurde und mittlerweile mehrere Standards, unter anderem

zum Agentenmanagement,
zur Agenten / Software - Interaktion und
zur Agentenkommunikation,

verabschiedet hat.
Der FIPA-Vorschlag zur Infrastruktur einer Agentenplattform, auf der alle Agenten laufen, sieht folgendermaßen aus:

Infrastruktur nach FIPA

Dabei sind die einzelnen Komponenten wie folgt zu verstehen.

Agentenplattform (AP)	stellt die Infrastruktur dar, die notwendig ist, um Agenten laufen zu lassen. Dazu zählen die Hardware, d.h. der Computer selbst (eine Agentenplattform kann auch mehrere Computer umfassen), das Betriebssystem, Anwendungssoftware, die Agenten und die folgenden Komponenten.
Agenten-Management-System (AMS)	von ihm darf es nur eins pro Agentenplattform geben. Das AMS ist zuständig für: die Verwaltung der Agentennamen, die Zustellung von Nachrichten und die Bereitstellung eines Sicherheitsdienstes.
Facilitator	(to facilitate = erleichtern) ist ein Agent, der eine Art "Gelbe Seiten" für das System darstellt. Er hat hinterlegt, welche Dienste von welchen Agenten, die auch auf der Agentenplattform laufen, bereitgestellt werden. Jeder Agent kann also hier anfragen, ob es einen anderen Agenten gibt, der bestimmte Aufgabe lösen kann.
Agent Communication Channel (ACC)	ist der Standardweg zur Kommunikation zwischen den Agentenplattformen. Jeder Agent einer Plattform hat Zugriff auf den ACC.

Der AP-interne Nachrichtentransport wird von FIPA nicht näher spezifiziert.

Anforderungen an die Plattformen

Mit Hinblick auf die mobilen Agenten ist es natürlich erforderlich, daß auf allen beteiligten Systemen einheitliche (standardisierte), portable Agentenplattformen installiert sind, die dem Agenten bestimmte Operationen, wie zum Beispiel die Möglichkeit des eigenhändigen Verschickens auf einen anderen Rechner, zur Verfügung stellen.
Im Zusammenhang mit dem Thema Sicherheit gibt es einige weitere Eigenschaften, die eine Agentenplattform besitzen sollte:

sie muß fehlerhafte Agenten beenden können,
um damit Schutz vor ungewollten Zugriffen des Agenten auf bestimmte Ressourcen zu bieten.
Desweiteren sollte sie in der Lage sein, bösartige Angriffe abzuwehren und
den Code des Agenten vor Ausspähung und Manipulation zu schützen

Leider existieren zur Zeit noch keine ausgereiften Lösungen, um diese Sicherheitsmechanismen wirkungsvoll zu implementieren.

Architektur von Multi-Agenten-Plattformen

In einem Multi-Agenten System gibt es zwei Möglichkeiten für die Agenten miteinander zu kommunizieren. Entweder sie kommunizieren direkt miteinander, d.h. sie übernehmen auch die Koordination des Datenaustausches oder sie tun dies mit Hilfe einer unterstützender Komponente.
Nun ist die direkte Kommunikation in einem System mit wenigen Agenten kein großes Problem. Sobald die Anzahl der Agenten jedoch ansteigt, steigt auch überproportional die Komplexität des Systems. Ein weiterer Nachteil ist, daß bei allen Agenten der Programmcode zur Organisation der Kommunikation implementiert sein muß.
Diese Probleme können gelöst werden, indem die Agenten in sogenannten Verbundsystemen (federated systems) organisiert werden. Hier bietet es sich natürlich an, die Agenten einer Plattform in einem System zu organisieren:

Architektur von Multi-Agenten-Systemen

In so einem System erfolgt die Kommunikation ausschließlich über bestimmte Agenten (Facilitators), die die Organisation und Synchronisation übernehmen. Auch die Agenten innerhalb eines Verbundsystems kommunizieren nicht mehr direkt miteinander, sondern ebenfalls mit Hilfe des Facilitators.

Die Agentenkommunikationssprache KQML

Agent Communication Language (ACL)

Damit Agenten überhaupt miteinander kommunizieren können, müssen drei fundamentale Komponenten existieren:

eine gemeinsame Sprache,
ein gemeinsames Verständnis des ausgetauschten Wissens und
überhaupt die Fähigkeit auszutauschen, was in 1. und 2. beeinhaltet ist.

Das Standardisierungsprojekt KSE ("Knowledge Sharing Effort") hat die Komponenten einer Agenten-Kommunikations-Sprache (ACL = Agent Communication Language) definiert. Das Projekt wurde als Verbund amerikanischer Universitäten, mit dem Ziel der Erstellung eines Konzeptes bzw. Standards zum Austausch von Informationen zwischen wissensbasierten Systemen, gegründet.
Die vorgeschlagene ACL besteht aus drei Teilen - dem Vokabular, einer "inneren" Sprache KIF und einer "äußeren" Sprache KQML. Eine ACL-Nachricht ist also ein KQML-Ausdruck, in dem die Argumente als KIF-Terme aus Wörtern des Vokabulars gebildet werden.

KIF ("Knowledge Interchange Format")

KIF repränsentiert die syntaktischen Aspekte von ACL. Ahand einiger Beispiele sollen die Möglichkeiten von KIF aufgezeigt werden.

Zunächst bietet KIF natürlich eine Möglichkeit, um einfache Daten auszudrücken. Im folgenden Beispiel wird ein Gehaltstupel einer Personaldatenbank kodiert (das erste Argument ist die Versicherungsnummer, das zweite die Abteilung, in der der Mitarbeiter arbeitet und das dritte das Gehalt des Mitarbeiters):


    (salary 015-46-3946 sale 42000)

Um auszudrücken, daß die Fläche von Raum 1 größer ist als die Fläche von Raum 2, kann zum Beispiel der folgende Ausdruck verwendet werden:


    (> (* (width room1) (length room1)) (* (width room2) (length room2)))

Kompliziertere Ausdrücke können mit Hilfe von logischen Operatoren, die alle in KIF implementiert sind, konstruiert werden. Das nächste Beispiel bringt zum Ausdruck, daß jede reelle Zahl (x) mit einer geraden Zahl (n) potentiert eine positive Zahl ergibt:


    (=> (and (real-number ?x) (even-number ?n)) (> (expt ?x ?n) 0))

Symbole, die mit einem Fragezeichen beginnen, werden als Variablen interpretiert.

Ein weitere Möglichkeit von KIF ist, daß es Wissen über Wissen kodieren kann, indem ' - Operatoren verwendet werden. Wenn zum Beispiel Agent Joe daran interessiert ist, etwas über das Gehalt eines Mitarbeiters zu erfahren, kann er das folgendermaßen tun:


    (interested joe ´(salary ,?x ,?y ,?z))

Die Kommas vor den Variablen bedeuten, daß die Variablennamen nicht wörtlich zu verstehen sind (da Agent Joe ja nicht weiß, mit welchen tatsächlichen Namen die einzelnen Felder in der Datenbank abgelegt sind).

KIF kann auch dazu benutzt werden, um Prozeduren zu beschreiben, d.h. anderen Agenten Skripte zu übermitteln. Das folgende Beispiel sorgt dafür, daß "Hallo"in einer einzelnen Zeile ausgegeben wird:


    (progn (fresh-line)

           (print "Hallo")

           (fresh-line))

KQML ("Knowledge Query and Manipulation Language")

KQML selbst besteht aus drei Schichten: der Inhaltsschicht, der Nachrichtenschicht und der Kommunikationsschicht.
In der Inhaltsschicht ist der eigentliche Inhalt der Nachricht untergebracht. Ein Vorteil von KQML ist, daß es sich nicht darum kümmert, welches Format der Inhalt hat, d.h. Nachrichten können sowohl im ASCII-Format als auch im Binär- oder anderen Formaten kodiert sein.
Die Kommunikationsschicht enthählt die Kommunikationsparameter, wie zum die Daten des Absenders, die Daten des Empfängers usw.
In der Nachrichtenschicht schließlich wird die Nachricht selbst kodiert. Diese Schicht stellt den Kern von KQML dar und bestimmt, welche Interaktionen mit einem KQML-sprechenden Agenten möglich sind. Zu einer der Hauptaufgaben des Nachrichten-Layers zählt die Überlieferung eines sogenannten Sprechaktes, auch als Performative (to perform = durchführen) bezeichnet. Desweiteren ist die Angabe optionaler Argumente möglich, wie zum Beispiel der Name der Sprache, in der der Nachrichteninhalt kodiert ist.

Das Format einer KQML-Nachricht sieht also folgendermaßen aus:


    (ask-one

         : sender joe

         : content (PRICE IBM ?price)

         : receiver stock-server

         : reply-with ibm-stock

         : language LPROLOG

Im vorstehenden Beispiel möchte Agent Joe wissen, wieviel eine Aktie von IBM kostet (die Anfrage ist in einer PROLOG-Sprache formuliert).
Der Nachrichteninhalt ist der Wert des Schlüsselwortes :content. Die Werte von :reply-with, :sender und :receiver stellen die Kommunikationsschicht dar. Der Performative und :language formen die Nachrichtenschicht.

In den nächsten Beispielen werde ich der Übersichtlichkeit halber nur noch den Performative sowie den eigentlichen Inhalt, der im folgenden in KIF kodiert sein wird, angeben.

Der nachstehende Ausdruck zeigt eine der einfachsten KQML-Nachrichten (mit der Aussage, daß 3 größer ist als 2):


    A an B: (tell (> 3 2))

Das folgende Beispiel zeigt einen Dialog zwischen zwei Agenten. Agent A bittet Agent B etwas auf der Standardausgabe auszugeben. Agent B bestätigt die Ausführung.


    A an B: (perform (print "Hallo"))

    B an A: (reply done)

Im nachfolgenden Dialog beantwortet Agent B eine Frage von Agent A (nämlich ob Raum 1 größer ist als Raum 2):


    A an B: (ask-if (> (size room1) (size room2)))

    B an A: (reply true)

Im abschließenden Beispiel bittet Agent A darum, bei einer Positionsveränderung eines Schiffes mit den neuen Koordinaten versorgt zu werden. Nach drei übermittelten Koordinaten ist Agent A nicht mehr an den Informationen interessiert.


    A an B: (subscribe (position ,?s ,?x ,?y))

    B an A: (tell (position ship1 8 10))

    B an A: (tell (position ship1 8 46))

    B an A: (tell (position ship1 8 64))

    A an B: (unsubscribe (position ,?s ,?x ,?y))

Zusätzlich zu den hier vorgestellten einfachen Ausdrücken, unterstützt KQML unter anderem auch verzögerte und bedingte Operationen, Anfragen nach Angeboten etc.
Beim Design der Sprache wurde darauf geachtet die Anzahl der vordefinierten Performatives klein zu halten, um die Implementierung in verschiedenen Agenten bzw. Agentenplattformen zu erleichtern. Es muß jedoch festgehalten werden, daß diese festgelegte Menge nicht vollständig implementiert sein muß bzw. auch erweitert werden kann. Ein KQML-Agent kann zum Beispiel nur drei oder vier dieser Performatives bearbeiten. Im Gegensatz dazu können Agenten auch mehr als die Standard-Performatives benutzen, wenn sie sich über ihre Interpretation einig sind. Allerdings muß ein Agent, der reservierte Performatives verwendet, diese in ihrer vorgegebenen Bedeutung implementieren.
Die nachstehende Tabelle gibt einen Überblick über die Standard-Performatives:

Kategorie	Name
grundlegende Anfragen	evaluate, ask-if, ask-about, ask-one, ask-all
Anfragen mit mehreren Antworten	stream-about, stream-all, eos
Antworten	reply, sorry
mehrere Antworten	standby, ready, next, rest, discard
Informationen	tell, achieve, cancel, untell, unachieve
Fähigkeiten	advertise, subscribe, monitor, import, export
Netzwerke	register, unregister, forward, broadcast, route

An dieser Stelle soll noch ein Beispiel zu den bereits unter Agentenplattformen - Standardisierte Infrastruktur aufgeführten Facilitators, den "Gelben Seiten" gegeben werden.

Ausgangspunkt ist die folgende Situation: Agent A möchte wissen, ob ein Satz X wahr ist und Agent B hat X in seiner Wissenbasis. Außerdem ist ein Facilitator-Agent F vorhanden. Sollte A bekannt sein, daß B existiert und das nötige Wissen besitzt, dann kann er eine Punkt-zu-Punkt-Verbindung zu B herstellen, um von B eine Antwort zu bekommen. Dieser Fall soll hier nicht betrachtet werden.
B hat F irgendwann mitgeteilt, daß er in der Lage ist auf den Satz X eine Antwort zu geben (1). A wendet sich nun F, damit dieser einen Agenten findet, der seine Frage beantworten kann (2). Da F bekannt ist, daß B dieses Wissen besitzt, leitet er die Frage weiter an B (3). B antwortet F (4) und F leitet die Antwort weiter an A (5). (Andere Möglichkeiten des Ablaufs sind natürlich denkbar, zum Beispiel, daß B seine Antwort direkt an A schickt.)
Das untenstehende Bild verdeutlicht noch einmal den Ablauf:

Damit solche Vorgänge reibungslos funktionieren, muß jeder Agent dem Facilitator beim Start seine Existenz bekanntmachen und ihm außerdem (zumindest teilweise) mitteilen, welches Wissen er besitzt.

Regeln der Kommunikation

Damit eine vernünftige Kommunikation zwischen Agenten zustande kommt, ist es erforderlich, daß bei den Agenten überhaupt ein allgemeines Interesse am gegenseitigen Helfen besteht. Außerdem sollten sich die Agenten an die folgenden Regeln halten:

Agenten müssen immer die Wahrheit sagen,
ein Agent darf einen anderen Agenten nicht zwingen einen Dienst zu erfüllen, wenn dieser nicht vorher seine Bereitschaft dazu erklärt hat und
ein Agent ist an seine Zusage, einen bestimmten Dienst auf Anfrage zu erfüllen, gebunden.

Auch hier gilt, daß ein Schutz vor böswilligen Agenten, die sich zum Beispiel nicht an das Wahrheitsgebot halten, eigentlich nicht gegeben ist. Sollte ein Verstoß gegen eine der oben genannten Regeln erfolgen und auch festgestellt werden, so muß die Agentenplattform dafür sorgen, daß dieser Agent unverzüglich beendet wird.

Agentenarchitektur und -implementierung

Vorüberlegungen

Beim Entwickeln von Agentenbasierten Applikation gibt es zwei Dinge zu beachten:

Die Details der Handlungen, die ein Agent zur Problemlösung ausführt, können erst zur Laufzeit bestimmt werden. Denn das individuelle Verhalten wird reguliert zwischen dem internen Status des Agenten und externen Einflüssen.
Weil das Verhalten des Agenten nicht einmalig zur Design-Zeit festgelegt werden kann, ist auch das Verhalten des ganzen Systems erst zur Laufzeit ersichtlich.

Wie sieht nun der grundlegende Aufbau eines Agenten aus? Aus dem bisher gesagten ergibt sich folgendes Architekturskelett:


    
      speicher <- aktualisiere_speicher(speicher, wahrnehmung)
      handlung <- waehle_beste_handlung(speicher)
      speicher <- aktualisiere_speicher(speicher, handlung)

Es gibt also zwei grundlegende Komponenten, die bei allen Agenten - selbst sehr einfachen - vorhanden sind. Das sind die Informationen (Überzeugungen) des Agenten und (von außen) eintreffende Ereignisse.
Die Informationen werden in einer Wissensbasis gespeichert und stellen die Sicht des Agenten über den aktuellen Stand der Dinge dar. Softwaretechnisch können die Informationen wie folgt erfaßt werden:

durch Variablen / Werte-Paare:	`MyName = 'Joe'`
durch logische Aussagen:	`I_am('Joe')`

Die eingehenden Nachrichten können als getypte Nachrichten zusammen mit den Senderdaten in einem FIFO-Puffer gespeichert werden.
Die beiden Komponenten (Informationszustand und Wahrnehmungszustand) bilden bereits die Grundlage für reaktives Verhalten des Agenten. Die Reaktionen werden durch die Wahrnehmung von Ereignissen ausgelöst und erfolgen in Abhägigkeit vom Informationszustand.
Die Reaktionsmuster können prozedural, zum Beispiel durch konditionale Befehle, oder deklarativ, zum Beispiel in Form von Reaktionsregeln, kodiert werden.

Programmierung in RADL ("Recticular Agent Definition Language")

Grundsätzlich können Agenten in jeder beliebigen Programmiersprache geschrieben werden. Besonders geeignet sind natürlich objektorientierte Sprachen, da Agenten ebenso wie Objekte Zustände verwalten. Darüberhinaus gibt es Sprachen, die extra für die Agentenprogrammierung entwickelt wurden.
Eine dieser Sprachen wurde Ende der 70er Jahre von Shoham entworfen: AGENT-0. Das Konzept dieser Sprache basiert auf seinem mentalistischen Modell eines Agenten. Die Sprache wurde inzwischen von verschiedenen Personen und Firmen weiterentwickelt. Eine dieser Firmen ist die Reticular Systems, Inc., die die von ihre weiterentwickelte Sprache RADL (Reticular Agent Definition Language) genannt hat.
Folgende Idee steckt dahinter: die mentalen Zustände des Agenten (Überzeugungen, Absichten, Verpflichtungen) werden aufgrund vorgegebener Verhaltensregeln verändert. Die daraus resultierenden Handlungen des Agenten können entweder privater oder kommunikativer Natur sein. Unter privaten Handlungen werden diejenigen verstanden, die die Umwelt des Agenten verändern. Kommunikative Handlungen dagegen betreffen den Nachrichtenaustausch mit anderen Agenten. Eine Verhaltensregel hat folgenden Aufbau:


    NAME Regelname

    WHEN

       Nachrichtenbedingungen(s)

    IF

       Wissensbedingungen(s)

    THEN

       private Handlungen(s)

       Wissensänderung(s)

       kommunikative Handlungen(s)

Tritt ein Ereignis ein, so überprüft der Agent die Bedingungen der eingehenden Nachricht im WHEN-Teil der Verhaltensregel. Sollte eine Reaktion seitens des Agenten erfoderlich sein, muß er erst nachsehen, ob dies auch mit seinem aktuellen Wissen und Fähigkeiten vereinbar ist (IF-Teil). Erst dann kann die Reaktion des Agenten erfolgen.

An dieser Stelle soll ein zusammenfassendes Beispiel gegeben werden. Es wird eine der Verhaltensregeln eines Auto-Agenten aufgeführt. In dieser Regel wird das Verhalten des Agenten an einer roten Ampel beschrieben:


    NAME "Greenlight Move Forward Rule"

    WHEN

       ?KQMLMessage.Performative EQUALS TELL

       ?KQMLMessage.Sender EQUALS "stoplight-agent"

       ?KQMLMessage.Content EQUALS String

    IF

       ?KQMLMessage.Content EQUALS "stoplight-green"

       currentMotion.Status EQUALS stoppedAtRedLight

       currentLocation EQUALS nextIntersection

       NOT (currentLocation EQUALS destination)

       FOR_ALL (?BlockIntersection,

               
      NOT (?BlockedIntersection.Location EQUALS currentLocation))

    THEN

       DO (Go(trafficSpeed))

       DO ($nextIntersection =

          
      getNextIntersection(currentLocation, currentMotion.Direction))

       ASSERT (SET_VALUE_OF currentMotion.Status TO moving)

       ASSERT (SET_VALUE_OF nextIntersection TO $nextIntersection)

       SEND (performative = REPLY,

            
      receiver = "stoplight-agent",

            
      content = "acknowledged",

            
      in-reply-to = ?KQMLMessage.Reply-with)

Der Name der Regel ist "Greenlight Move Forward Rule". Im WHEN-Teil werden zunächst die Bedingungen der eingegangenen Nachricht überprüft. Die Nachricht muß eine Aussage enthalten, die vom Ampel-Agenten kommt und als Inhalt einen ASCII-String enthält. Dann werden im IF-Teil die Bedingungen der Wissenbasis des Agenten überprüft. Die Ampel muß nun auf Grün geschaltet sein, der Agent muß an einer roten Ampel warten, die auf seinem Weg liegt. Der Agent darf seinen Zielort noch nicht erreicht haben und die Kreuzung darf auch nicht blockiert sein. Wenn alle diese Bedingungen erfüllt sind, kann der Agent handeln. In seinen privaten Handlungen setzt er sich in Bewegung und holt die Koordinaten der nächsten Kreuzung (nicht zu verwechseln: die Variable $nextIntersection und das Objekt nextIntersection). Danach aktualisiert er seine Wissensbasis, d.h. er setzt seinen Status auf Fahren und lädt die Kreuzungskoordinaten. Zum Schluß (als kommunikative Handlung) schickt er dem Ampel-Agenten eine Bestätigung.

Die folgende Abbildung verdeutlicht noch einmal die Zusammenhänge, die sich im Lebenslauf eines Agenten ergeben:

Seminar Linux, WWW, Java und Internet
3. Grundlagen

Intelligente Softwareagenten

5. Abschlußbemerkungen