KI-Agenten-Design
Kernphilosophie
Agenten sind keine Magie – sie sind Systeme mit Eingaben, Ausgaben, Gedächtnis, Werkzeugen und Entscheidungslogik. Entwerfen Sie sie mit der gleichen Strenge wie jede Produktionssoftware. Jeder Agent sollte einen klaren Zweck, definierte Grenzen und explizite Fehlermodi haben.
Prinzipien des Agentendesigns
1. Absicht vor der Handlung klären
Ein Agent muss klärende Fragen stellen, wenn die Absicht des Benutzers mehrdeutig ist – bevor er eine irreversible Aktion ausführt. Verwenden Sie dieses Muster:
- Ist das Ziel klar? Wenn nicht, stellen Sie eine gezielte Frage.
- Sind die Randbedingungen bekannt? (Umfang, Ausgabeformat, Datenquellen)
- Wie sieht Erfolg aus?
2. Spezifikation vor Code
Bevor Sie Agentenlogik schreiben, erstellen Sie eine Spezifikation oder eine Aufgabenlistendatei:
- Rolle und Verantwortlichkeiten des Agenten definieren
- Alle Werkzeuge auflisten, auf die er Zugriff benötigt
- Eingabe-/Ausgabeverträge definieren
- Fehlermodi und Rückfallverhalten identifizieren
- Dann den Code schreiben
3. Einzelverantwortung
Jeder Agent sollte eine Sache gut machen. Bevorzugen Sie ein Team spezialisierter Agenten gegenüber einem Allzweck-Agenten.
Orchestrierungsmuster
| Muster | Wann verwenden | Beschreibung |
|---|---|---|
| Sequentiell | Lineare Pipelines | Agenten verketten in fester Reihenfolge (Entwurf → Prüfung → Veröffentlichung) |
| Supervisor | Komplexe Multi-Modul-Aufgaben | Leitagent leitet an spezialisierte Arbeiter weiter |
| ReAct | Autonome Problemlösung | Kombiniert Denken (Thought) + Handeln (Tool Use) |
| Gruppenchat | Kollaborative Aufgaben | Multi-Agenten-Kommunikation mit menschlicher Aufsicht |
| DAG | Zustandsbehaftete Workflows | Gerichteter azyklischer Graph für zyklische, zustandsbehaftete Orchestrierung |
Framework-Auswahl-Leitfaden
| Framework | Am besten geeignet für | Status |
|---|---|---|
| LangGraph | Komplexe zustandsbehaftete Agenten, zyklische Workflows, Multi-Agenten-Orchestrierung, produktionsreif | ✅ Aktiv – GA Mai 2025 |
| LangChain | Einfache RAG-Pipelines, lineare Workflows, schnelle Prototypen | ✅ Aktiv – Für RAG verwenden, nicht für Agenten |
| CrewAI | Rollenbasierte Multi-Agenten-Teams ("Manager", "Forscher", "Schreiber") | ✅ Aktiv |
| Microsoft Agent Framework | Unternehmensagenten im Azure-Ökosystem – ersetzt AutoGen + Semantic Kernel | ✅ Aktiv – Public Preview Okt. 2025, GA voraussichtlich Q1 2026 |
| AutoGen | Legacy – funktioniert noch, aber keine neuen Funktionen | ⚠️ Wartungsmodus seit Okt. 2025 |
| Custom (MCP) | Leichte, portable, interoperable Agentenwerkzeuge über offenen Standard | ✅ Aktiv |
LangChain vs LangGraph – Wann verwenden
Das LangChain-Team empfiehlt jetzt explizit diese Aufteilung:
- LangGraph → für Agenten: zustandsbehaftet, zyklisch, Multi-Agenten, langlaufende Aufgaben
- LangChain → für RAG und lineare Pipelines: einfache Dokumenten-Q&A, schrittweise Transformationen
LangGraph ist auf LangChain aufgebaut – Sie können beide zusammen verwenden, beginnen Sie mit LangChain und wechseln Sie zu LangGraph, wenn Sie mehr Kontrolle benötigen.
RAG-Pipeline-Design
Standard-RAG-Ablauf
Benutzeranfrage → Anfrage einbetten → Vektorsuche → Chunks abrufen → Prompt anreichern → LLM → Antwort
Chunking-Strategie (Best Practice für 2026)
- Verwenden Sie semantisches Chunking – nach Bedeutung trennen, nicht nach Zeichenanzahl
- Chunk-Größe: 256–512 Token für Genauigkeit; 1024 für narrative Inhalte
- Immer Metadaten einfügen: Quelle, Seite, Abschnitt, Zeitstempel
Hybridsuche (Empfohlen)
Kombinieren Sie dichte Vektoren (semantisch) + sparse Vektoren (Schlüsselwörter) für beste Abrufqualität:
Endgültige Punktzahl = α × Dichte Punktzahl + (1 - α) × Sparse Punktzahl
Auswahl der Vektordatenbank
| DB | Am besten geeignet für |
|---|---|
| pgvector | Vorhandener PostgreSQL-Stack, einfache Anwendungsfälle |
| Pinecone | Managed, Produktionsmaßstab, minimaler Betriebsaufwand |
| Weaviate | Multimodal, Hybridsuche integriert |
| Milvus | Hohe Leistung, selbst gehostet, großer Maßstab |
| Chroma | Lokale Entwicklung, Prototyping |
Gedächtnisarchitektur für Agenten
| Typ | Beschreibung | Implementierung |
|---|---|---|
| Im Kontext | Aktuelles Gesprächsfenster | Chatverlaufs-Array |
| Extern kurzfristig | Sitzungsbezogenes Gedächtnis | Redis / In-Memory-Speicher |
| Extern langfristig | Dauerhaft über Sitzungen hinweg | Vektordatenbank + Metadaten |
| Episodisch | Zusammengefasste vergangene Interaktionen | Zusammenfassungskette → Vektorspeicher |
Kontextverfall-Warnung: Lange Kontextfenster verschlechtern die Agentenqualität im Laufe der Zeit. Implementieren Sie alle N Schritte einen Zusammenfassungsschritt, um die Relevanz zu erhalten.
Werkzeugnutzung & Funktionsaufruf
Werkzeugdefinitionsmuster
Jedes Werkzeug benötigt:
name: beschreibender_werkzeugname
beschreibung: Wann dieses Werkzeug verwendet wird und was es tut (explizit sein)
parameter:
- name: parameter_name
typ: zeichenkette
beschreibung: Was dieser Parameter erwartet
erforderlich: wahr
Best Practices für die Werkzeugnutzung
- Werkzeuge sollten nach Möglichkeit idempotent sein
- Werkzeugausgaben immer validieren, bevor sie an den nächsten Schritt weitergegeben werden
- Timeouts und Wiederholungen für externe Werkzeugaufrufe implementieren
- Alle Werkzeugaufrufe zu Debugging-Zwecken protokollieren
Kommunikationsmuster für Agenten
Protokoll zur Absichtsklärung
Wenn ein Agent eine mehrdeutige Anfrage erhält:
- Die Mehrdeutigkeit identifizieren – was genau ist unklar?
- Eine Frage stellen – die wichtigste, nicht alle davon
- Einen Standard vorschlagen – „Ich gehe von X aus, es sei denn, Sie sagen mir etwas anderes“
- Vor irreversiblen Aktionen bestätigen – immer vor dem Löschen, Veröffentlichen oder Senden fragen
Fortschrittsberichterstattung
Bei langlaufenden Aufgaben sollte der Agent Folgendes melden:
[Schritt 1/4] Dokumente abrufen... ✓
[Schritt 2/4] Chunken und Einbetten... ✓
[Schritt 3/4] Vektorspeicher abfragen...
Fehlerkommunikation
✗ Werkzeug fehlgeschlagen: [werkzeugname]
Grund: [spezifischer Fehler]
Rückfall: [was ich stattdessen mache]
MCP (Model Context Protocol)
MCP ist der offene Standard zur Verbindung von Agenten mit externen Werkzeugen und Datenquellen. Verwenden Sie ihn beim Erstellen von portablen, interoperablen Agentenwerkzeugen.
MCP-Serverstruktur
mein-mcp-server/
├── server.py (oder index.ts)
├── tools/
│ └── mein_werkzeug.py
└── README.md
Wann MCP vs. direkte Integration verwenden
- Verwenden Sie MCP, wenn das Werkzeug über mehrere Agenten/Plattformen hinweg wiederverwendbar sein muss
- Verwenden Sie direkte Integration für projektspezifische, einmalige Werkzeugimplementierungen
Siehe Skill mcp-builder für detaillierte Anleitung zur MCP-Serverimplementierung.
Sicherheit & Gefahrenabwehr
- Erlauben Sie niemals Agenten, willkürlichen Code ohne Sandboxing auszuführen
- Implementieren Sie Ratenbegrenzung für alle LLM-API-Aufrufe
- Validieren und bereinigen Sie alle Eingaben, bevor Sie sie an Werkzeuge übergeben
- Protokollieren Sie alle Agentenentscheidungen zur Prüfbarkeit
- Implementieren Sie Schutzmechanismen, um außer Kontrolle geratende Token-Kosten oder rekursive Schleifen zu verhindern
- Verwenden Sie System-Prompt-Injection-Schutz – trennen Sie Benutzereingaben durch klare Trennzeichen von Systemanweisungen
Robustes Agentendesign (Selbstheilung)
Agenten versagen in der Produktion. Entwerfen Sie von Anfang an für die Wiederherstellung.
Validierungs- und Wiederholungsschleife (LoopAgent-Muster)
Ausgabe erzeugen → Ausgabe validieren → Wenn ungültig: Feedback + erneut generieren
Maximale Iterationen: 3 ← Schutzschalter zur Verhinderung von Endlosschleifen
Planen–Validieren–Ausführen–Beobachten–Neuplanen
PLANEN: Plan erstellen, Durchführbarkeit vor dem Handeln prüfen
AUSFÜHREN: Aktion durchführen
BEOBACHTEN: Erfolgreich? Ausgaben prüfen, Tests durchführen
NEU PLANEN: Wenn die Beobachtung einen Fehler zeigt → anpassen und wiederholen
STOPP: Wenn maximale Wiederholungen erreicht → Fehler klar melden, um Hilfe bitten
Agenten-Fallback-Hierarchie
Primäransatz schlägt fehl → Alternativansatz versuchen
Alternative schlägt fehl → Klärung vom Entwickler anfordern
Keine Klärung → Sichere Standardaktion oder anmutiger Stopp
Ausgabevalidierung vor der Präsentation
- Tests/Lint für generierten Code ausführen, bevor er präsentiert wird
- Überprüfen, ob das Ausgabeformat den Anforderungen entspricht
- Einen separaten Validierungsschritt (anderes Modell oder Prompt) verwenden, um die Generatorausgabe zu prüfen
- Nie ungeprüfte Ausgabe als erledigt präsentieren
Schutzschalter für Agenten
Legen Sie harte Grenzen fest, um außer Kontrolle geratendes Verhalten zu verhindern:
- Maximale Anzahl von Werkzeugaufrufiterationen pro Aufgabe (z.B. 10)
- Maximaler Token-Verbrauch pro Sitzung
- Maximale Wiederholungen pro fehlschlagendem Schritt (z.B. 3)
- Timeout pro Werkzeugaufruf
Siehe Skill self-healing-mindset für die vollständige Resilienz-Philosophie und Codemuster.