KI-Agenten: Architektur und Implementierung in Python

Wie KI-Agenten gebaut werden: Architektur, ReAct und praktische Umsetzung in Python

KI-Agenten sind nicht nur 'intelligente Chatbots'; sie sind autonome Systeme, die in der Lage sind, zu planen, Werkzeuge auszuwählen, externe Anfragen zu stellen und ihre Aktionen in Echtzeit anzupassen. Im Gegensatz zu RAG, das lediglich Kontext vor der Generierung bereitstellt, steuert ein Agent den gesamten Aufgabenlösungszyklus – von der Zielanalyse bis zum Endergebnis mit Selbstüberprüfung. Dies stellt für Entwickler eine grundlegend neue Stufe der Automatisierung dar, insbesondere in Szenarien, die mehrstufige Interaktionen mit APIs, Code, Datenbanken oder externen Diensten erfordern.

Warum RAG für komplexe Aufgaben unzureichend ist

RAG adressiert ein spezifisches Problem – die Aktualisierung von Wissen durch externe Quellen. Doch es ist statisch: Das Modell erhält einen Satz von Fragmenten und generiert nur einmal eine Antwort. Es gibt keinen Mechanismus, um bei irrelevanten Ergebnissen erneut nachzufragen, keine Bewertung der Zuverlässigkeit der Zwischenergebnisse und keine Neuplanung. In realen Arbeitsabläufen ist dies entscheidend:

• Bei der Analyse technischer Dokumentation müssen Sie möglicherweise nacheinander Links folgen, Code aus verschiedenen Dateien extrahieren und validieren;
• Bei der Erstellung eines Berichts auf Basis von Excel-Daten müssen Sie zunächst die Tabelle lesen, dann Kennzahlen bestimmen, diese berechnen und erst danach das Ergebnis formatieren;
• Bei der Automatisierung von CI/CD müssen Sie Fehlerprotokolle interpretieren, Diagnosen durchführen, Korrekturen anwenden und das Ergebnis bestätigen.

All diese Szenarien gehen über die Einmalgenerierung hinaus. Genau hier ist eine dynamische Architektur – also ein Agent – erforderlich.

Schlüsselkomponenten eines modernen KI-Agenten

Ein Agent ist kein Monolith; er ist ein koordiniertes System aus miteinander verbundenen Modulen. Jede Komponente erfüllt eine klar definierte Funktion und kann ersetzt oder erweitert werden, ohne die gesamte Logik neu schreiben zu müssen.

LLM als Entscheidungskern

Das Modell generiert nicht direkt die endgültige Antwort; vielmehr fungiert es als 'Gehirn': Es formuliert einen Plan, wählt Werkzeuge aus, interpretiert die Ergebnisse von Aufrufen und entscheidet über den nächsten Schritt. Seine Rolle ist strategisches Management, nicht Textproduktion.

Werkzeuge als Schnittstelle zur Umgebung

Dies sind alle externen Fähigkeiten: HTTP-Anfragen an REST-APIs, Ausführung von Python-Code in einer Sandbox, Lesen/Schreiben von Dateien, Ausführen von SQL-Abfragen, Aufruf von CLI-Tools. Ein Werkzeug muss eine klare Beschreibung (Docstring), typisierte Argumente und Fehlerbehandlung besitzen – nur dann kann das LLM es sicher nutzen.

Speicher: Kurzzeit- und Langzeitgedächtnis

Das Kurzzeitgedächtnis besteht aus dem aktuellen Dialogkontext und Zwischenergebnissen (z. B. der ID einer erstellten Ressource). Das Langzeitgedächtnis umfasst vektorbasierte Wissensbasen, zwischengespeicherte Antworten und historische Benutzersitzungsdaten. Es ermöglicht dem Agenten, Kontext zwischen Aufrufen zu 'erinnern' und aus Erfahrungen zu lernen.

Planer und Fehlerkontrolleur

Der Planer zerlegt das Ziel in Schritte, verfolgt den Fortschritt und verhindert Schleifen. Der Fehlerkontrolleur überprüft die Gültigkeit von Werkzeugergebnissen, gleicht Fakten mit Quellen ab und initiiert Nachversuche, wenn etwas schiefgeht. Ohne diese Komponenten ist der Agent instabil und unberechenbar.

ReAct: Ein transparentes Verhaltensmuster für LLMs

ReAct (Reason + Act + Observe) ist kein Framework – es ist eine Verhaltensvorlage, die einen klaren Agenten-Arbeitszyklus definiert. Sie macht das interne Denken des Modells sichtbar und kontrollierbar:

• Reason – das Modell analysiert den aktuellen Zustand, formuliert eine Hypothese über die nächste Aktion und erklärt, warum sie notwendig ist;
• Act – das Modell ruft ein Werkzeug mit spezifischen Argumenten auf;
• Observe – das Modell erhält das Ergebnis des Aufrufs und bewertet dessen Anwendbarkeit für die Aufgabe.

Dieser Zyklus wiederholt sich, bis das Ziel erreicht ist. Zum Beispiel, wenn nach Informationen zur Bibliotheks-Kompatibilität mit Python 3.12 gesucht wird, 'reasons' das Modell zunächst, dass es PyPI und GitHub prüfen muss; dann 'acts' es, indem es get_pypi_info('requests') aufruft; nachdem es das Ergebnis 'observed' hat, entscheidet es, ob es den Quellcode des Repositories analysieren soll.

Der Vorteil von ReAct liegt in Reproduzierbarkeit und Debuggbarkeit. Jeder Schritt wird protokolliert: Plan → Aufruf → Ergebnis → neue Entscheidung. Dies ist entscheidend für Produktionssysteme, in denen Auditing und Tracing erforderlich sind.

Multi-Agenten-Systeme: Skalierung durch Spezialisierung

Ein einziger universeller Agent stößt schnell an seine Komplexitätsgrenze. Multi-Agenten-Systeme (MAS) lösen dieses Problem, indem sie Rollen aufteilen. Statt eines Monoliths gibt es ein Team spezialisierter Agenten, die von einem Orchestrierer koordiniert werden.

Typische Rollen in MAS sind:

• Planner – zerlegt das Ziel, bestimmt die Reihenfolge der Teilaufgaben und weist sie den Ausführern zu;
• Researcher – arbeitet mit externen Quellen: APIs, Dokumentation, Datenbanken;
• Executor – führt Code aus, modifiziert Dateien, wendet Konfigurationen an;
• Validator – überprüft Ergebnisse auf Richtigkeit, Einhaltung von Anforderungen und Sicherheit.

Der Koordinator sammelt die Ergebnisse, löst Konflikte und formt die endgültige Antwort. Dieser Ansatz bietet drei wichtige Vorteile:

• Parallelität: Mehrere Agenten können unabhängige Teilaufgaben gleichzeitig bearbeiten;
• Erhöhte Zuverlässigkeit: Der Validator fängt Fehler auf, die der Executor möglicherweise übersieht;
• Vereinfachtes Debugging: Ein Ausfall in einer Rolle lähmt nicht das gesamte System.

Doch MAS erfordert ein gut durchdachtes Interaktionsprotokoll und Schutz vor zyklischen Abhängigkeiten – etwa wenn der Researcher Daten vom Validator anfordert, der Validator jedoch auf Bestätigung des Researchers wartet.

Praxis: Ein minimaler Assistenz-Agent auf LangChain

Lassen Sie uns einen einfachen, aber voll funktionsfähigen Agenten bauen, der Wetterdaten abrufen, Veranstaltungen finden und E-Mails versenden kann. Ziel ist es, zu zeigen, wie die Komponenten zu einem einheitlichen System zusammenkommen, statt eine produktionsreife Lösung zu entwickeln.

Initialisierung des Modells und der Umgebung

Wir verwenden Qwen 3.5 (9B) via Ollama – ein Modell, das leistungsstark genug für Agentenaufgaben ist und klein genug, um in Google Colab zu laufen. Die Verbindung ist standardmäßig:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="qwen3.5:9b",
    base_url="http://localhost:11434/v1",
    api_key="ollama",
    temperature=0.3,
)

Definition von Werkzeugen

Jedes Werkzeug ist eine Python-Funktion, die mit @tool dekoriert ist, inklusive klarer Docstring und typisierter Argumente. Zum Beispiel get_weather:

@tool
def get_weather(city: str) -> str:
    """Gibt das aktuelle Wetter in der angegebenen Stadt zurück.
Akzeptiert den Stadtnamen auf Russisch oder Englisch."""
    # ... Implementierung unter Verwendung der Open-Meteo-API
    return f"{name}: {weather['temperature_2m']}°C, {desc}, Wind {weather['wind_speed_10m']} km/h"

Es ist wichtig, dass die Funktion Netzwerkfehler, nicht existierende Städte und ungültige Wettercodes behandelt – sonst erhält der Agent unstrukturierten Text statt der erwarteten Antwort.

Benutzerprompt und Kontext

Der Prompt definiert die Rolle, die Einschränkungen und den Ton der Antwort. Für einen technischen Agenten ist es entscheidend, explizit festzulegen:

• Welche Werkzeuge verfügbar sind und wann sie eingesetzt werden sollen;
• Was im Fehlerfall zu tun ist (erneuter Versuch, Rückfrage beim Nutzer oder Ablehnung);
• Wie das Endergebnis formatiert werden soll (z. B. nur JSON, ohne Erklärungen).

USER_CONTEXT enthält personalisierte Daten – Name, Präferenzen, Interaktionshistorie. Dadurch kann der Agent Ton und Detailgrad individuell anpassen.

Was wichtig ist

• Ein KI-Agent ist kein LLM mit erweitertem Prompt; er ist ein architektonisch komplexes System mit einer klaren Aufgabenteilung zwischen den Komponenten.
• ReAct ist nicht nur eine 'Funktion' – es ist ein notwendiges Muster, um Transparenz, Debuggbarkeit und Sicherheit in der Produktion zu gewährleisten.
• Werkzeuge müssen typisiert, dokumentiert und fehlertolerant sein – sonst verliert der Agent die Kontrolle über die Ausführung.
• Multi-Agenten-Systeme sind nicht wegen des Trends gerechtfertigt; sie sind nötig, um Komplexität zu skalieren: Ein einzelner Agent kann Dutzende von Werkzeugen und Quellen nicht zuverlässig managen.
• Produktionsagenten benötigen Tracing-Mechanismen, Protokollierung jedes Schritts im Zyklus und strenge Validierung von Ein- und Ausgangsdaten.

— Editorial Team