SKILL.md — AgentSpeak(L) & BDI-Agentenarchitektur
Wenn autonome Entitäten wahrnehmen, deliberieren und handeln müssen, während sie konkurrierende Ziele managen und auf Ereignisse reagieren, ohne laufende Arbeiten abzubrechen.
Entscheidungspunkte
Primäre Architekturauswahl
WENN System nur Ereignisreaktion ohne persistente Ziele benötigt
→ Verwende reaktives/Regelsystem (BDI ist übertrieben)
SONST WENN System Planung in statischer Umgebung ohne Unterbrechungen benötigt
→ Verwende klassischen Planer
SONST WENN System sowohl Reaktivität ALS AUCH Zielpersistenz in dynamischer Umgebung benötigt
→ Verwende BDI-Architektur
Aufruftabelle für Selektionsfunktionen
| Situation | Funktion | Entscheidungskriterien |
|---|---|---|
| Neues Ereignis trifft ein | SE (Ereignisauswahl) | Priorität, Dringlichkeit, Ressourcenbeschränkungen |
| Ereignis benötigt Plan | SO (Optionsauswahl) | Kontextbedingungen, Planerfolgshistorie, Risikotoleranz |
| Mehrere aktive Intentionen | SI (Intentionsauswahl) | Fristen, Ressourcenzuteilung, Fairness-Policy |
| Planfehler tritt auf | SO dann SI | Fehlerbehandlungsplan finden, dann Intentionen neu planen |
Entscheidungsbaum zur Planfehlerbehandlung
Plan P schlägt bei Ausführung von Aktion A fehl:
WENN Fehlerbehandlungsplan für diesen Fehlertyp existiert
→ Fehlerereignis posten, SO wählt Wiederherstellungsplan aus
→ Mit modifiziertem Intentionsstack fortfahren
SONST WENN alternative Pläne für dasselbe auslösende Ereignis existieren
→ Zum Ereignis zurückkehren, SO den nächsten anwendbaren Plan ausprobieren lassen
→ Fehlgeschlagenen Plan von der Auswahl ausschließen
SONST WENN keine Alternativen verfügbar
→ Fehler im Intentionsstack nach oben weiterreichen
→ WENN Elternplan existiert → Fehlerereignis auf Elternebene auslösen
→ SONST Intention vollständig verwerfen
Auswirkungsbewertung von Überzeugungsaktualisierungen
Neue Überzeugung B trifft ein:
WENN B bestehenden Überzeugungen widerspricht
→ Überzeugungsrevisionsprotokoll ausführen
→ Alle aktiven Intentionen auf Verletzungen von Kontextbedingungen prüfen
→ WENN Kontext nicht mehr gilt → Intention aussetzen (nicht verwerfen)
SONST WENN B neue anwendbare Pläne ermöglicht
→ Ereigniswarteschlange auf ruhende Ereignisse prüfen, für die jetzt Pläne anwendbar sind
→ Mit SE neu priorisieren
SONST WENN B ausstehende Zielbedingungen erfüllt
→ Erfüllung markieren, zugehörige Intentionen bereinigen
→ Erfüllungsereignis für Planbereinigung posten
Fehlermodi
1. Plan-Thrashing
Symptome: Der Agent wechselt schnell zwischen Plänen, ohne Fortschritte zu machen; dasselbe Ereignis löst wiederholt verschiedene Pläne aus. Erkennungsregel: Wenn dasselbe Ereignis >3 Mal in N Ausführungszyklen mit jeweils unterschiedlichen Planauswahlen verarbeitet wird, liegt Plan-Thrashing vor. Ursache: Die SO-Funktion (Optionsauswahl) ist nicht-deterministisch oder die Kontextbedingungen sind zu schwach/überlappend. Behebung: SO explizit nach Priorität ordnen; Kontextbedingungen stärken, sodass sie sich gegenseitig ausschließen; Planerfolgs-/Fehlerhistorie zu den Auswahlkriterien hinzufügen.
2. Stale-Belief-Paralyse
Symptome: Der Agent wählt Pläne basierend auf einem veralteten Weltmodell aus; Pläne schlagen sofort aufgrund falscher Annahmen über die Umgebung fehl. Erkennungsregel: Wenn die Planfehlerrate >50% beträgt und die Fehler auf Kontextbedingungsverletzungen zur Ausführungszeit (nicht zur Planungszeit) zurückzuführen sind, liegen veraltete Überzeugungen vor. Ursache: Die Aktualisierungsfrequenz der Überzeugungen ist im Verhältnis zur Änderungsrate der Umgebung zu niedrig; die Überzeugungsrevision wird nicht an die Kontextprüfungen der Intentionen weitergegeben. Behebung: Wahrnehmungsfrequenz erhöhen; Zeitstempel für Überzeugungsveralterung hinzufügen; Intentionen aussetzen, wenn ihre Kontextbedingungen ungültig werden.
3. Unendliche Intentionsschleifen
Symptome: Der Agent erstellt Intentionen, die Ereignisse posten, die wiederum weitere Intentionen für dasselbe Ziel erzeugen; der Intentionsstack wächst unbegrenzt. Erkennungsregel: Wenn die Tiefe des Intentionsstacks monoton über die Zeit zunimmt, ohne dass entsprechende Zielerreichungen erfolgen, liegen Intentionsschleifen vor. Ursache: Pläne erzeugen Unterziele, die letztendlich zum ursprünglichen Ziel zurückführen, ohne Abbruchbedingungen. Behebung: Erkennung von Zielerreichung in Kontextbedingungen hinzufügen; Intentionssubsumtion implementieren (doppelte Intentionen zusammenführen); maximale Rekursionstiefe begrenzen.
4. Anti-Pattern „Policy-in-Plans“
Symptome: Dieselben Ereignisse lösen basierend auf Bedingungen innerhalb von Plankörpern unterschiedliches Verhalten aus; die Agenten-Policy ist verstreut und schwer zu ändern.
Erkennungsregel: Wenn Plankörper Prioritäts-/Dringlichkeitsbedingungen enthalten (if high_priority then X else Y), ist die Policy am falschen Ort.
Ursache: Die Rationalität des Agenten ist in der Planlogik anstatt in den Selektionsfunktionen kodiert.
Behebung: Die gesamte Prioritäts-/Policy-Logik in die SE/SO/SI-Funktionen verschieben; Pläne policy-neutral und nur kontextsensitiv machen.
5. Einzel-Intentions-Engpass
Symptome: Der Agent kann keine Unterbrechungen verarbeiten; dringende Ereignisse warten, während der Agent langlaufende Aufgaben abschließt; keine Parallelität. Erkennungsregel: Wenn der Agent zu jeder Zeit höchstens eine aktive Intention hat, liegt ein Einzel-Intentions-Engpass vor. Ursache: Die SI-Funktion (Intentionsplanung) implementiert keine echte Parallelität; sie behandelt Intentionen als exklusiv statt parallel. Behebung: Mehrere aktive Intentionen zulassen; präemptive Planung in SI implementieren; Pläne als unterbrechbare Sequenzen entwerfen.
Durchgearbeitete Beispiele
Beispiel 1: Multi-Agenten-Aufgabenzuteilung mit Plankonflikten
Szenario: Zwei Agenten (A1, A2) koordinieren sich, um deliver(package, destination) zu erreichen. Beide haben Pläne, aber unterschiedliche Fähigkeiten.
Ausgangszustand:
- A1 Überzeugungen:
location(A1, warehouse),can_carry(A1, small_items),location(package, warehouse) - A2 Überzeugungen:
location(A2, depot),can_carry(A2, any),has_vehicle(A2) - Gemeinsame Überzeugung:
size(package, large),destination(customer_site)
Ereignis: +!deliver(package, customer_site) an beide Agenten gepostet
Entscheidungsprozess:
-
A1 Planauswahl (SO):
- Plan P1:
+!deliver(X,Y) : can_carry(A1,small_items) & size(X,small) <- pickup(X); transport(X,Y) - Kontextbedingung schlägt fehl:
size(package,large)widersprichtsize(X,small) - Keine anwendbaren Pläne → postet
plan_failure(deliver, no_capability)
- Plan P1:
-
A2 Planauswahl (SO):
- Plan P2:
+!deliver(X,Y) : can_carry(A2,any) & has_vehicle(A2) <- pickup(X); drive(X,Y); dropoff(X) - Kontextbedingung erfüllt → P2 ausgewählt
- Erstellt Intention I1:
[pickup(package), drive(package,customer_site), dropoff(package)]
- Plan P2:
-
A1 Überzeugungsaktualisierung:
- Erhält Nachricht:
attempting(A2, deliver, package) - Aktualisiert Überzeugungen:
+delegated(deliver, package, A2) - Verwirft fehlgeschlagene Intention
- Erhält Nachricht:
Anfängerfehler: Beide Agenten würden versuchen, die Lieferung durchzuführen, was zu Ressourcenkonflikten führt. Experteneinblick: Koordination erfolgt durch gemeinsame Überzeugungen und Kontextbedingungen von Plänen, nicht durch fest kodiertes Agentenwissen.
Beispiel 2: Interrupt-Behandlung mit Intentionsüberprüfung
Szenario: Agent führt eine langlaufende Datenverarbeitungsaufgabe aus und erhält einen dringenden Sicherheitsalarm.
Ausgangszustand:
- Aktive Intention I1:
[process_batch(data1), process_batch(data2), generate_report()] - Aktuelle Ausführung: mitten in
process_batch(data1)(dauert noch 10 Minuten)
Ereignis: +security_alert(intrusion_detected, server_3)
Entscheidungsprozess:
-
Ereignisauswahl (SE):
- SE Prioritäten: security_events > routine_processing
security_alertwird gegenüber Fortsetzung von I1 ausgewählt
-
Planauswahl (SO):
- Plan P3:
+security_alert(Type,Location) : has_admin_access <- isolate_system(Location); notify_team(Type) - Kontextbedingung erfüllt → P3 ausgewählt
- Erstellt Intention I2:
[isolate_system(server_3), notify_team(intrusion_detected)]
- Plan P3:
-
Intentionsplanung (SI):
- Aktuelle Intentionen: I1 (ausgesetzt bei
process_batch(data1)), I2 (neu, dringend) - SI-Policy: Sicherheitsintentionen verdrängen Verarbeitungsintentionen
- Wählt I2 zur Ausführung aus
- Aktuelle Intentionen: I1 (ausgesetzt bei
-
Ausführung:
- Führt
isolate_system(server_3)sofort aus - Führt
notify_team(intrusion_detected)aus - I2 abgeschlossen, wird aus der Intentionsmenge entfernt
- Führt
-
Wiederaufnahme:
- Nur I1 bleibt:
[process_batch(data1), process_batch(data2), generate_report()] - Nimmt
process_batch(data1)ab dem Aussetzungspunkt wieder auf
- Nur I1 bleibt:
Anfängerfehler: Würde entweder den Sicherheitsalarm ignorieren oder die Verarbeitungsaufgabe vollständig abbrechen. Experteneinblick: Die Intentionsaussetzung bewahrt Fortschritte und ermöglicht gleichzeitig reaktionsfähiges Verhalten. Die SI-Scheduling-Policy ist explizit und konfigurierbar.
Qualitätsprüfungen
- Die Agentenarchitektur verfügt über explizite SE-, SO- und SI-Selektionsfunktionen mit dokumentierten Policys
- Jeder Plan hat ein genau definiertes auslösendes Ereignis und eine Kontextbedingung, die anhand der aktuellen Überzeugungen ausgewertet werden kann
- Die Planbibliothek enthält Fehlerbehandlungspläne für jeden Hauptplantyp (nicht nur Erfolgspfade)
- Der Überzeugungsaktualisierungsmechanismus kann widersprüchliche Informationen verarbeiten und Änderungen an aktive Intentionen weitergeben
- Mehrere Intentionen können gleichzeitig aktiv sein, mit klaren Regeln für Planung/Verdrängung
- Die Ereigniswarteschlangenverarbeitung ist priorisiert (nicht FIFO) mit expliziter Prioritätszuweisung
- Planfehler lösen Ereignisse aus, keine Systemabstürze oder stillen Fehlschläge
- Kontextbedingungen schließen sich gegenseitig aus ODER die Planauswahl ist explizit geordnet, um Nichtdeterminismus zu vermeiden
- Der Agent kann seine Aktionen erklären, indem er den Intentionsstack und die auslösenden Ereignisse offenlegt
- Die Systemleistung verschlechtert sich unter hoher Ereignislast allmählich (keine Endlosschleifen oder Stapelüberläufe)
NICHT-FÜR-Grenzen
NICHT FÜR: Einfache regelbasierte Systeme, bei denen alles Verhalten reaktiv ist (keine persistenten Ziele) → STATTDESSEN VERWENDEN: Einfache Regelmaschine oder Ereignis-Aktions-System
NICHT FÜR: Statische Planungsprobleme, bei denen sich die Umgebung während der Ausführung nicht ändert
→ STATTDESSEN VERWENDEN: Klassische Planer (A*, STRIPS, HTN)
NICHT FÜR: Echtzeitsysteme, die garantierte Antwortzeiten oder harte Fristen erfordern → STATTDESSEN VERWENDEN: Echtzeit-Planungssysteme mit Zeitanalyse
NICHT FÜR: Systeme, bei denen die gesamte Koordination von einem zentralen Controller übernommen werden kann → STATTDESSEN VERWENDEN: Workflow-Orchestrierung oder zentrale Aufgabenwarteschlange
NICHT FÜR: Reine Datentransformationspipelines ohne autonome Entscheidungsfindung → STATTDESSEN VERWENDEN: ETL-Tools, Stream-Processing-Frameworks
NICHT FÜR: Anwendungen, die maschinelles Lernen oder statistische Inferenz als primäre Fähigkeit erfordern → STATTDESSEN VERWENDEN: ML-Frameworks mit BDI als Koordinationsschicht, falls erforderlich