Kapitel 4

Kernkompetenz: Entwicklung von AI Agents

Machen Sie sich die Designprinzipien von AI Agents, Multi-Agent-Orchestrierungsmuster und ereignisgesteuerte Architektur zu eigen, um AI-Agent-Systeme aufzubauen, die autonom zusammenarbeiten und effizient ausführen können.

Agent-Designprinzipien

Das Design der Agents folgt Kernprinzipien, um die Effizienz, Wartbarkeit und Skalierbarkeit des Agent-Systems sicherzustellen.

Prinzip der Einzelverantwortung

Jeder Agent konzentriert sich auf eine bestimmte Aufgabe, mit klar definierten Verantwortlichkeiten:

  • Verantwortungsgrenzen: die Eingaben, Ausgaben und die Verarbeitungslogik des Agenten klar definieren
  • Kopplung vermeiden: Agenten sind nicht direkt voneinander abhängig und kommunizieren über Schnittstellen
  • Einfach zu testen: Einzelverantwortung erleichtert das Schreiben von Unit-Tests
  • Leicht zu warten: Die Änderung eines Agenten hat keine Auswirkungen auf andere Agenten

Beispiel: Der Code-Review-Agent ist nur für die Code-Überprüfung zuständig, nicht für die Code-Generierung oder das Deployment.

Prinzip der Komponierbarkeit

Agenten können kombiniert werden, um leistungsfähigere Fähigkeiten zu bilden:

  • Standard-Schnittstelle: Ein einheitliches Eingabe- und Ausgabeformat definieren
  • Lose Kopplung: Agenten kommunizieren über Nachrichten und rufen sich nicht direkt auf
  • Austauschbar: Agents mit derselben Schnittstelle können sich gegenseitig ersetzen
  • Skalierbar:Neue Agenten lassen sich leicht zum System hinzufügen

Beispiel:Architekt-Agent + Coding-Agent + Test-Agent können kombiniert werden, um den vollständigen Entwicklungsprozess abzuschließen.

Grundsätze der Beobachtbarkeit

Das Verhalten des Agents ist nachverfolgbar und überwachbar:

  • Protokollierung:den Entscheidungsprozess und die Ausführungsergebnisse des Agenten protokollieren
  • Statusüberwachung: den Laufstatus des Agenten in Echtzeit überwachen
  • Leistungsmetriken: Die Ausführungszeit und Ressourcennutzung des Agents verfolgen
  • Fehlerverfolgung:Agent-Fehler aufzeichnen und verfolgen

Beispiel:Verwenden Sie strukturierte Protokolle, um jeden Entscheidungsschritt des Agenten aufzuzeichnen und so Debugging und Optimierung zu erleichtern.

Prinzipien der Fehlerbehandlung

Agents müssen Fehlerzustände elegant behandeln:

  • Fehlerbehebung:Automatischer Wiederholungsversuch oder Fallback-Verarbeitung
  • Graceful Degradation: Bei Fehlschlag eine Ersatzlösung bereitstellen
  • Fehlerausbreitung: Fehler an den übergeordneten Agenten oder den Benutzer melden
  • Status-Rollback: Bei einem Fehler in einen sicheren Zustand zurückrollen

Beispiel:Wenn der API-Aufruf fehlschlägt, versucht der Agent automatisch dreimal erneut; schlägt es weiterhin fehl, werden zwischengespeicherte Daten verwendet oder ein Fehler zurückgegeben.

Tiefgehende Überlegungen zu Designprinzipien

Warum ist das Single-Responsibility-Prinzip notwendig?: Die Einzelverantwortung macht Agenten leichter verständlich, testbar und wartbar. Wenn sich Anforderungen ändern, muss nur der betreffende Agent angepasst werden, ohne andere Agenten zu beeinflussen. Das entspricht den SOLID-Prinzipien der Softwareentwicklung.

Warum ist Komponierbarkeit notwendig?:Komponierbarkeit verleiht Agent-Systemen Flexibilität. Durch die Kombination verschiedener Agents lassen sich verschiedenste komplexe Systeme aufbauen. Dies ähnelt der Unix-Philosophie: „Mache eine Sache, und mache sie gut“.

Warum ist Observability notwendig?: Der Entscheidungsprozess von KI-Agenten ist eine „Black Box“; Observability hilft uns, das Verhalten von Agenten zu verstehen und Probleme sowie Optimierungspotenziale zu erkennen. Das ist entscheidend für Debugging, Monitoring und Optimierung.

Warum ist Fehlerbehandlung notwendig?: KI-Agenten arbeiten in unsicheren Umgebungen, daher sind Ausfälle unvermeidlich. Ein eleganter Fehlerumgang gewährleistet Systemstabilität und Zuverlässigkeit und verhindert, dass ein Single Point of Failure das gesamte System zum Absturz bringt.

Multi-Agenten-Orchestrierung

Mehrere Agenten, die zusammenarbeiten, um komplexe Aufgaben zu erledigen, erfordern geeignete Orchestrierungsmuster und Kommunikationsmechanismen.

Architekturmuster

Sequenziell

Agenten werden der Reihe nach ausgeführt, wobei die Ausgabe des vorherigen Agenten als Eingabe für den nächsten Agenten dient

A → B → C

Anwendungsszenarien: Aufgaben mit einer klaren Reihenfolge, z. B. Anforderungsanalyse → Design → Codierung → Test

Parallel(parallel)

Mehrere Agenten parallel ausführen und anschließend die Ergebnisse zusammenfassen

A ─┐
B ─┼→ Zusammenfassung
C ─┘

Anwendungsszenarien:eigenständige Aufgaben, z. B. den Code in mehreren Dateien gleichzeitig überprüfen

Hierarchical (hierarchisch)

Der Hauptagent koordiniert Unteragenten und bildet eine hierarchische Struktur

Hauptagent
├─ Agent A
├─ Agent B
└─ Agent C

Anwendungsszenarien:Komplexe Aufgaben aufteilen, z. B.: ein Projektmanager-Agent, der mehrere Entwickler-Agenten koordiniert

Kommunikationsmechanismus

Event Bus (Event Bus)

  • Publish-Subscribe: Ein Agent veröffentlicht Ereignisse, und andere Agenten abonnieren die Ereignisse, an denen sie interessiert sind
  • Entkopplung: Agenten hängen nicht direkt voneinander ab; sie kommunizieren über Ereignisse
  • Skalierbarkeit: Neue Agenten und Ereignistypen lassen sich leicht hinzufügen
  • Anwendungsszenarien: Systeme, die Echtzeitreaktionen erfordern, z. B.: Benachrichtigungen über Codeänderungen, Benachrichtigungen über abgeschlossene Aufgaben

Nachrichtenwarteschlange (Message Queue)

  • Asynchrone Verarbeitung:Der Agent verarbeitet Nachrichten asynchron und blockiert nicht
  • Zuverlässigkeit:Nachrichtenpersistenz, damit nichts verloren geht
  • Lastverteilung:Mehrere Agents können dieselbe Warteschlange konsumieren
  • Anwendungsszenarien:Aufgaben, die eine zuverlässige Verarbeitung erfordern, wie z. B. die stapelweise Datenverarbeitung und lang laufende Aufgaben

Geteilter Zustand (Shared State)

  • Zustandssynchronisierung: Agenten tauschen Informationen über einen gemeinsamen Status aus
  • Konsistenz: gleichzeitigen Zugriff und Zustands-Synchronisierung behandeln
  • Anwendungsszenarien: Szenarien, die gemeinsam genutzte Daten erfordern, wie z. B. eine gemeinsame Wissensdatenbank oder gemeinsame Konfiguration

Koordinationsstrategie

Orchestration (Orchestrierung)

  • • Ein zentraler Orchestrator steuert den gesamten Ablauf
  • • Der Orchestrator kennt den Status aller Agenten
  • • Prozesse werden zentral verwaltet und sind dadurch leicht zu überwachen
  • • Geeignet für: komplexe Prozesse, Szenarien mit strenger Kontrolle

Choreography (Choreografie)

  • • Agents arbeiten autonom zusammen, ohne zentralen Koordinator
  • • Agent reagiert autonom über Ereignisse
  • • Das System ist flexibler, aber die Überwachung ist schwieriger
  • • Geeignet für: einfache Abläufe, Szenarien, die Flexibilität erfordern

Praxisbeispiel: Code-Review-Agent-System

Systemarchitektur

Haupt-Koordinierungs-Agent (Orchestrator)
├─ Codeanalyse-Agent (analysiert die Codestruktur)
├─ Sicherheitsprüfungs-Agent (prüft Sicherheitslücken)
├─ Leistungsanalyse-Agent (analysiert Leistungsprobleme)
└─ Berichtserstellungs-Agent (erstellt Prüfberichte)

Workflow

  1. 1. Der Hauptkoordinationsagent erhält die Anfrage zur Codeüberprüfung
  2. 2. Drei Analyse-Agenten parallel starten (Codeanalyse, Sicherheitsprüfung, Leistungsanalyse)
  3. 3. Jeder Agent schließt die Analyse ab und sendet die Ergebnisse an den Event-Bus
  4. 4. Der Berichtserstellungs-Agent abonniert Ereignisse und erstellt Berichte aus aggregierten Ergebnissen
  5. 5. Der Hauptkoordinations-Agent gibt den Prüfbericht zurück

Technische Umsetzung

  • • Einen Event-Bus (Redis Pub/Sub) für die Agentenkommunikation verwenden
  • • Eine Message Queue (RabbitMQ) verwenden, um langlaufende Analyseaufgaben zu verarbeiten
  • • Gemeinsamen Status (Redis) verwenden, um Analyseergebnisse zu speichern
  • • Wiederholungsmechanismus und Fehlerbehandlung implementieren

Ereignisgesteuerte Architektur

Eine ereignisgesteuerte Architektur macht Agent-Systeme flexibler und reaktionsfähiger und eignet sich daher für den Aufbau komplexer verteilter Systeme.

Ereignisdesign

Ereignistyp

  • Befehlsereignisse:den Agenten dazu veranlassen, eine Aktion auszuführen, z. B. :code-review-requested
  • Statusereignisse: Agent-Zustandsänderungen benachrichtigen, z. B.:task-completed
  • Datenereignisse: Daten übergeben, z. B.:code-changed
  • Fehlerereignis: Benachrichtigungsfehler, z. B.:agent-failed

Ereignisdaten

{ "type": "code-review-requested", "timestamp": "2025-01-27T10:00:00Z", "source": "git-webhook", "data": { "repository": "my-repo", "pullRequest": 123, "files": ["src/app.ts", "src/utils.ts"], "author": "developer" }, "metadata": { "priority": "high", "deadline": "2025-01-28T10:00:00Z" } }

Ereignisstrom

Ereignisse fließen durch das System und lösen Reaktionen mehrerer Agents aus. Beim Entwurf von Ereignisflüssen müssen Ereignisreihenfolge, Duplikaterkennung, Ereigniswiederholung und mehr berücksichtigt werden.

Ereignisverarbeitung

Synchron vs. asynchron

Synchrone Verarbeitung
  • • Sofort antworten und auf das Ergebnis warten
  • • Geeignet für: schnelle Aktionen, sofortiges Feedback erforderlich
  • • Nachteile: blockierend, beeinträchtigt die Leistung
Asynchrone Verarbeitung
  • • Sofort zurückkehren und im Hintergrund verarbeiten
  • • Geeignet für: lang andauernde Vorgänge, kein unmittelbares Feedback erforderlich
  • • Vorteile: nicht blockierend, gute Leistung

Wiederholungsmechanismus

  • Exponentielles Backoff: Wiederholungsintervalle schrittweise erhöhen, um eine Überlastung des Systems zu vermeiden
  • Maximale Anzahl an Wiederholungsversuchen:Unendliche Wiederholungen vermeiden
  • Dead-Letter-Queue: Fehlgeschlagene Nachrichten in die Dead-Letter-Queue legen und manuell verarbeiten
  • Idempotenz: Sicherstellen, dass die doppelte Verarbeitung keine Nebenwirkungen erzeugt

Praxisfall: automatisiertes Deployment-Agent-System

Ereignisfluss-Design

git-push → code-changed → build-requested →
build-completed → test-requested → test-completed →
deploy-requested → deploy-completed → notify-completed

Agent-Design

  • Einen Agenten erstellen:auf das build-requested-Ereignis lauschen und den Build ausführen
  • Test-Agent: Auf das test-requested-Ereignis hören und Tests ausführen
  • Agent bereitstellen: Das deploy-requested-Ereignis überwachen und das Deployment ausführen
  • Benachrichtigungs-Agent:auf das Ereignis deploy-completed hören und eine Benachrichtigung senden

Fehlerbehandlung

  • • Build fehlgeschlagen: automatisch 3-mal erneut versuchen; wenn es weiterhin fehlschlägt, den Entwickler benachrichtigen
  • • Testfehler: Bereitstellung blockieren, Entwickler benachrichtigen
  • • Bereitstellungsfehler: automatisches Rollback, Benachrichtigung des Betriebsteams

Lernergebnisse

Nach Abschluss dieses Kapitels werden Sie:

  • 1Die Kernprinzipien des Agent-Designs verstehen (Single Responsibility, Komponierbarkeit, Beobachtbarkeit, Fehlerbehandlung) und wissen, wie man hochwertige Agents entwirft
  • 2Die Architekturmodelle der Multi-Agent-Zusammenarbeit (Sequential, Parallel, Hierarchical) beherrschen und das passende Orchestrierungsmodell auswählen können
  • 3Die Entwurfsprinzipien einer ereignisgesteuerten Architektur verstehen und Ereignistypen, Ereignisflüsse sowie Ereignisverarbeitungsmechanismen entwerfen können
  • 4In der Lage sein, Multi-Agenten-Systeme zu entwerfen und zu implementieren, einschließlich Kommunikationsmechanismen, Koordinationsstrategien und Fehlerbehandlung
  • 5Fähig sein, Agentensysteme zu analysieren und zu optimieren sowie Leistungsengpässe und Verbesserungspotenziale zu erkennen