KI-Agenten — Patterns und Fallstricke

KI-Agenten — Patterns und Fallstricke

KI-Agenten — Systeme, die LLMs nutzen, um autonom zu denken, zu planen und zu handeln — haben sich von einer Forschungskuriosität zur Produktionsrealität entwickelt. Aber zuverlässige Agenten zu bauen ist deutlich schwieriger, als einen Chatbot zu erstellen. Agenten führen Schleifen, Verzweigungslogik, externe Tool-Aufrufe und sich kumulierende Fehlerraten ein, die ausser Kontrolle geraten können.

Dieser Beitrag behandelt die wichtigsten Architektur-Patterns für KI-Agenten, die Fallstricke, die die meisten Teams erwischen, und praktische Strategien für Agenten, die tatsächlich in Produktion funktionieren.

Was macht einen Agenten zum Agenten?

Ein Chatbot nimmt Input und erzeugt Output. Ein Agent nimmt Input, entscheidet, was zu tun ist, führt Aktionen aus, beobachtet Ergebnisse und iteriert, bis ein Ziel erreicht ist. Der entscheidende Unterschied ist die Aktionsschleife: Der Agent kann externe Tools aufrufen, die Ergebnisse inspizieren und seine Strategie anpassen.

Eine minimale Agenten-Schleife sieht so aus:

async function agentLoop(task: string, tools: Tool[], maxSteps = 10) {
  const messages: Message[] = [
    { role: "system", content: SYSTEM_PROMPT },
    { role: "user", content: task },
  ];

  for (let step = 0; step < maxSteps; step++) {
    const response = await llm.chat(messages, { tools });

    if (response.finishReason === "stop") {
      return response.content; // Agent ist fertig
    }

    // Tool-Aufrufe ausführen
    for (const toolCall of response.toolCalls) {
      const result = await executeTool(toolCall);
      messages.push(
        { role: "assistant", content: null, toolCalls: [toolCall] },
        { role: "tool", content: result, toolCallId: toolCall.id }
      );
    }
  }

  throw new Error("Agent hat maximale Schrittanzahl überschritten");
}

Das ist das Fundament. Alles andere ist Verfeinerung.

Das ReAct-Pattern

ReAct (Reasoning + Acting) ist das am weitesten verbreitete Agenten-Pattern. Das LLM wechselt zwischen Reasoning (nachdenken, was zu tun ist) und Acting (ein Tool aufrufen). Jeder Schritt erzeugt einen expliziten Gedanken vor der Aktion.

Die Reasoning-Spur macht den Entscheidungsprozess des Agenten transparent und debugbar. In der Praxis implementiert man ReAct, indem man den System-Prompt so strukturiert, dass er schrittweises Denken hervorruft:

Du bist ein Agent, der Aufgaben Schritt für Schritt löst.
Für jeden Schritt:
1. DENKEN: Analysiere die aktuelle Situation und entscheide den nächsten Schritt
2. HANDELN: Rufe das passende Tool auf
3. BEOBACHTEN: Prüfe das Tool-Ergebnis
4. Wiederhole, bis die Aufgabe abgeschlossen ist

ReAct funktioniert gut für Aufgaben mit 3–8 Schritten. Darüber hinaus werden Context-Window-Druck und kumulative Fehler problematisch.

Tool-Design: Der entscheidende Faktor

Die Qualität eines Agenten hängt mehr vom Tool-Design ab als vom Prompt Engineering. Gut designte Tools machen dem Agenten die Arbeit leicht; schlecht designte führen zu Verwirrung, Fehlern und Endlosschleifen.

Prinzipien für gutes Tool-Design:

1. Klare, eindeutige Namen: searchDocumentsByDate ist besser als search
2. Fokussierter Scope: Jedes Tool sollte eine Sache gut machen
3. Informative Fehlermeldungen: Fehler zurückgeben, die dem Agenten bei der Wiederherstellung helfen
4. Input-Validierung: Parameter vor der Ausführung validieren und klare Fehler bei ungültigen Inputs zurückgeben
5. Idempotent wo möglich: Wenn der Agent einen Tool-Call wiederholt, sollte das keine doppelten Seiteneffekte verursachen

Multi-Agent-Systeme

Bei komplexen Aufgaben stossen einzelne Agenten oft an Grenzen. Multi-Agent-Architekturen verteilen die Arbeit auf spezialisierte Agenten, die zusammenarbeiten:

Orchestrator-Worker-Pattern: Ein Planungs-Agent zerlegt die Aufgabe und delegiert Teilaufgaben an spezialisierte Worker-Agenten. Der Orchestrator synthetisiert die Ergebnisse.

Pipeline-Pattern: Agenten werden sequenziell verkettet, wobei der Output eines Agenten zum Input des nächsten wird. Gut für Workflows mit klar definierten Phasen.

Debatte-Pattern: Mehrere Agenten schlagen Lösungen vor und kritisieren sich gegenseitig. Nützlich für Aufgaben, bei denen diverse Perspektiven die Qualität verbessern.

Die zentrale Herausforderung bei Multi-Agent-Systemen ist die Koordination. Wie teilen Agenten Kontext? Wie geht man mit widersprüchlichen Outputs um? Wie verhindert man eine Kostenexplosion, wenn Agenten rekursiv Sub-Agenten spawnen?

Meine Empfehlung: Mit einem einzelnen Agenten starten. Erst zu Multi-Agent wechseln, wenn man klar unterschiedliche Rollen identifizieren kann, die verschiedene Fähigkeiten oder Context-Windows erfordern.

Guardrails und Sicherheit

Agenten, die autonom in der realen Welt agieren, brauchen Einschränkungen. Ohne Guardrails können Agenten:

• Unbegrenzt Geld für API-Calls ausgeben
• Destruktive Operationen ausführen (Daten löschen, E-Mails versenden)
• In Endlosschleifen geraten, die Tokens verbrennen
• Tool-Namen oder Parameter halluzinieren, die nicht existieren
• Sensible Informationen über Tool-Aufrufe preisgeben

Essentielle Guardrails:

interface AgentConfig {
  maxSteps: number;           // Hard Limit für Reasoning-Schritte
  maxTokenBudget: number;     // Maximum Tokens über alle LLM-Calls
  allowedTools: string[];     // Whitelist erlaubter Tools
  requireConfirmation: string[]; // Tools, die menschliche Freigabe brauchen
  timeoutMs: number;          // Wall-Clock-Timeout
}

Für kritische Operationen einen Human-in-the-Loop-Ansatz implementieren, bei dem der Agent pausiert und vor der Ausführung sensibler Aktionen um Bestätigung bittet.

Die fünf Fallstricke, die garantiert zuschlagen

1. Die Endlosschleife. Der Agent hängt in einem Zyklus fest — ruft dasselbe Tool mit denselben Parametern auf oder wechselt zwischen zwei Tools, ohne Fortschritt zu machen. Die Lösung: Schleifenerkennung implementieren, die kürzliche Tool-Calls verfolgt und bei Wiederholungen abbricht.

2. Halluzinierte Tool-Aufrufe. Das LLM erfindet Tool-Namen oder Parameter, die nicht existieren. Das passiert häufiger bei kleineren Modellen und mehrdeutigen Tool-Definitionen. Die Lösung: Strikte Validierung jedes Tool-Calls gegen das Schema vor der Ausführung.

3. Context-Window-Überlauf. Lang laufende Agenten akkumulieren Nachrichten, bis sie das Context Window überschreiten. Die Lösung: Sliding-Window- oder Zusammenfassungsstrategie implementieren, die frühere Gesprächshistorie komprimiert.

4. Kostenexplosion. Ein Agent, der 50 Schritte mit GPT-4-Klasse-Modellen ausführt, kann mehrere Dollar pro Aufruf kosten. Multipliziert mit Tausenden von Nutzern ergibt das ein Budgetproblem. Die Lösung: Harte Token-Budgets setzen, günstigere Modelle für einfache Reasoning-Schritte nutzen und Tool-Ergebnisse aggressiv cachen.

5. Ungenügende Fehlerbehandlung. Wenn ein Tool-Call fehlschlägt, weiss der Agent oft nicht, wie er sich elegant erholen soll. Die Lösung: Tools so designen, dass sie strukturierte Fehler mit Wiederherstellungsvorschlägen zurückgeben, und Fehlerbehandlungshinweise in den System-Prompt aufnehmen.

Praktische Ratschläge für Produktions-Agenten

1. Alles loggen. Jeden LLM-Call, jeden Tool-Call, jeden Entscheidungspunkt. Man braucht diese Logs für Debugging, Optimierung und Kosten-Tracking.

2. Mit deterministischen Fallbacks starten. Wenn der Agent ein Problem nicht in N Schritten lösen kann, auf einen deterministischen Code-Pfad zurückfallen oder an einen Menschen eskalieren.

3. Mit adversarialen Inputs testen. Nutzer werden den Agenten bitten, Dinge zu tun, die man nie erwartet hätte. Eine Test-Suite mit Randfällen, mehrdeutigen Anfragen und absichtlich verwirrenden Inputs aufbauen.

4. Kosten pro Aufgabe monitoren. Median und p95 der Kosten pro Agenten-Aufruf tracken. Alarme für Anomalien setzen.

5. Prompts und Tools versionieren. Sie wie Code behandeln — Versionskontrolle, Code-Review, gestützte Rollouts.

Fazit

KI-Agenten stellen einen echten Sprung in den Möglichkeiten von Softwaresystemen dar. Aber sie führen auch eine neue Kategorie von Fehlermodi ein, auf die klassisches Software-Engineering nicht vorbereitet. Die Teams, die mit Agenten erfolgreich sind, behandeln sie als Engineering-Systeme — mit Tests, Monitoring, Guardrails und gesunder Skepsis — statt als magische Black Boxes.

Inkrementell bauen, unerbittlich messen und immer einen Fallback-Plan haben.