Meine Architektur der KI-Agenten: Wie ich zuverlässige Systeme baue

Hallo zusammen, hier ist Alex von agntai.net! Heute möchte ich über etwas sprechen, das mir schon seit einer Weile im Kopf herumgeht, insbesondere angesichts der Tatsache, dass immer mehr „KI-Agenten“-Projekte hier und da auftauchen, oft mit… interessanten Ergebnissen. Wir werden die Architektur von zuverlässigen KI-Agenten erkunden und uns dabei speziell darauf konzentrieren, wie man sie so konzipiert, dass sie tatsächlich das tun, was Sie wollen, und zwar konsistent, ohne in den gefürchteten „Halluzinationskreis“ zu geraten oder stillschweigend zu scheitern.

Ich erinnere mich an eine Situation vor etwa anderthalb Jahren, als ich einem Freund half, einen Agenten für eine einfache Kundenservicetätigkeit zu prototypisieren. Die Idee war, dass der Agent eingehende E-Mails liest, sie zusammenfasst, kategorisiert und dann einen Antwortentwurf vorschlägt. Schien simpel, oder? Wir haben ihn mit einer recht standardmäßigen LLM-als-Gehirn-Konfiguration, einigen Tools zum Zugriff auf E-Mails und einer Wissensdatenbank aufgebaut. In den ersten Tagen war es glorreich. Es fühlte sich wie Magie an. Dann begann er langsam aber sicher, sich… abzuwenden. Er kategorisierte eine dringende Beschwerde als einfache Anfrage und halluciniert schlimmer noch, Details, die in der E-Mail nicht vorhanden waren, was zu sehr ungeschickten Antwortentwürfen führte. Das Problem lag nicht im LLM selbst – es war die Art und Weise, wie wir den Agenten rund um es strukturiert hatten. Wir hatten keine Sicherheitsvorkehrungen, Rückkopplungsschleifen und eine klare Trennung der Anliegen, die einen Agenten wirklich zuverlässig machen.

Diese Erfahrung, zusammen mit mehreren anderen seither, hat wirklich den Punkt unterstrichen: Es genügt nicht, ein LLM in einen Agentenrahmen zu stecken. Sie benötigen Architektur. Sie benötigen Designprinzipien. Lassen Sie uns also darüber sprechen, wie man KI-Agenten aufbaut, denen Sie tatsächlich vertrauen können.

Das Problem mit „Nur ein LLM“

Bevor wir in das Gute eintauchen, geben wir schnell einen Überblick über die Gründe, warum es eine fragile Grundlage sein kann, sich ausschließlich auf ein großes Sprachmodell für die grundlegende Logik eines Agenten zu verlassen. LLMs sind großartige Muster-Equalizer und Textgeneratoren, aber sie fehlen an inhärentem Zustand, langfristigem Gedächtnis über ihr Kontextfenster hinaus und an solide Verständnis der realen Welt. Sie können:

• Halluzinieren: Fakten, Details oder ganze Szenarien erfinden, die nicht wahr sind.
• Abweichen: Das ursprüngliche Ziel aus den Augen verlieren über eine lange Kette von Interaktionen hinweg.
• Persistenz missen: Frühere Schritte oder Entscheidungen vergessen, es sei denn, sie werden ausdrücklich im Prompt erwähnt.
• Effizient sein: Einfache und deterministische Aufgaben mithilfe komplexer Argumentation durchführen, während ein einfacher Funktionsaufruf ausreichen würde.
• Schwierigkeiten mit komplexer mehrstufiger Argumentation haben: Obwohl sie es tun können, ist es oft zuverlässiger für ein LLM, komplexe Probleme in kleinere, handhabbare Schritte zu zerlegen.

Der Kundenservice-Agent meines Freundes fiel auf beinahe all diese Probleme herein. Wir forderten das LLM auf, zu viele Dinge zur gleichen Zeit zu tun, ohne genug Struktur, um sein Denken zu leiten oder seine Fehler zu korrigieren.

Bestandteile einer zuverlässigen Agentenarchitektur

Mein bevorzugter Ansatz zur Erstellung solider KI-Agenten besteht darin, das Problem in separate und handhabbare Komponenten zu zerlegen. Denken Sie daran wie bei traditioneller Softwareentwicklung: Sie bauen keine gesamte Anwendung in einer einzigen riesigen Funktion. Sie modularisieren. Sie erstellen Dienste. Sie definieren klare Schnittstellen. Dieselben Prinzipien gelten hier.

1. Der Orchestrator: Das Gehirn (aber nicht das einzige)

Der Orchestrator ist die zentrale Kontrolleinheit. Seine Hauptaufgabe ist es, das Ziel des Benutzers zu verstehen, es in Unteraufgaben zu zerlegen, zu entscheiden, welche Tools oder Module verwendet werden sollen, diese auszuführen und dann die Ergebnisse zu synthetisieren. Hier befindet sich oft Ihr LLM, aber seine Rolle betrifft mehr die Planung und das Denken auf hoher Ebene, nicht die Ausführung jedes einzelnen Schrittes.

Warum ihn trennen? Indem Sie dem LLM die Rolle des Orchestrators geben, bitten Sie es, das zu tun, was es am besten kann: die Absicht zu verstehen, zu planen und zu synthetisieren. Sie bitten es *nicht*, deterministische Berechnungen durchzuführen, langfristiges Gedächtnis zu speichern oder spezifische Fakten aus einer Datenbank abzurufen – das sind Aufgaben für andere Komponenten.

2. Gedächtnismodul: Jenseits des Kontextfensters

LLMs haben begrenzte Kontextfenster. Selbst mit den riesigen, die wir heute sehen, sind sie nicht unendlich. Für Agenten, die über längere Zeiträume hinweg arbeiten müssen, um sich an frühere Interaktionen zu erinnern oder auf eine wachsende Wissensdatenbank zuzugreifen, benötigen Sie ein dediziertes Gedächtnissystem.

• Kurzzeitgedächtnis (Arbeitsgedächtnis): Speichert die sofortige Gesprächshistorie, den derzeitigen Status der Aufgabe und Zwischenresultate. Eine einfache Liste von Nachrichten oder ein strukturiertes JSON-Objekt funktioniert oft gut.
• Langzeitgedächtnis (Wissensdatenbank): Hier speichert der Agent Fakten, Vorlieben, frühere erfolgreiche Pläne, Benutzerprofile oder domänenspezifische Informationen. Dies umfasst oft Vektordatenbanken (für semantische Suche), traditionelle relationale Datenbanken oder einfaches Dateispeicherung.

Als der Agent meines Freundes anfing, frühere Interaktionen oder Details aus früheren E-Mails zu vergessen, lag das daran, dass wir ein Gedächtnismodul nicht richtig implementiert hatten. Das LLM versuchte, sich alles zu merken, was einfach nicht nachhaltig ist.

3. Werkzeug-/Aktionsausführer: Die Hände und Füße

Dieses Modul ist verantwortlich für die Ausführung externer Funktionen, APIs oder benutzerdefinierten Codes. Das sind die „Werkzeuge“, die Ihr Agent verwendet, um mit der Welt zu interagieren. Beispiele sind:

• Eine Datenbank abfragen
• Eine externe API aufrufen (zum Beispiel einen Wetterdienst, CRM)
• Eine E-Mail senden
• Eine Berechnung durchführen
• Auf ein Dateisystem zugreifen

Der Orchestrator entscheidet, *welches* Werkzeug verwendet werden soll und *welche Argumente* übergeben werden sollen, aber der Werkzeugausführer führt tatsächlich die Aktion aus. Diese Trennung ist entscheidend für die Zuverlässigkeit und Sicherheit. Sie möchten nicht, dass Ihr LLM direkt willkürlich Code ausführt.

4. Wahrnehmungs-/Eingabemodul: Die Augen und Ohren

Dieses Modul verwaltet alle eingehenden Daten – Anfragen von Benutzern, Sensordaten, Systemereignisse, E-Mails usw. Seine Rolle besteht darin, diese Daten vorzubehandeln, möglicherweise Schlüsselinformationen zu extrahieren und sie im strukturierten und verständlichen Format an den Orchestrator zu übermitteln. Dies kann Folgendes umfassen:

• Natürliche Sprachverarbeitung (NLU) für Benutzeranfragen.
• Analyse strukturierter Daten (JSON, XML).
• Bilder oder Audio verarbeiten (falls zutreffend).

5. Ausgabe-/Aktionsmodul: Die Stimme

Im Gegensatz dazu befasst sich dieses Modul damit, wie der Agent kommuniziert oder handelt. Es nimmt die interne Entscheidung des Agenten oder die generierte Antwort und formatiert sie für die Außenwelt. Dies könnte beinhalten, eine Antwort in natürlicher Sprache zu generieren, eine Datenbank zu aktualisieren, eine Benachrichtigung zu senden oder ein anderes System auszulösen.

6. Reflexion/Rückkopplungsschleife: Der Selbstkorrekturmechanismus

Das ist ohne Zweifel die am meisten vernachlässigte, aber kritische Komponente zum Aufbau wirklich zuverlässiger Agenten. Nachdem eine Aktion ausgeführt oder eine Aufgabe abgeschlossen wurde, muss der Agent seine Leistung bewerten. Hat die Aktion das gewünschte Ziel erreicht? War die Antwort präzise? Dieses Feedback kann dann genutzt werden, um:

• Zukünftige Pläne zu verfeinern.
• Das Langzeitgedächtnis zu aktualisieren (zum Beispiel: „Dieser Plan hat gut für die Aufgabe X funktioniert“).
• Eine neue Anpassung auszulösen, falls etwas schiefgegangen ist.
• Sogar den Prompt oder das Modell des Orchestrators im Laufe der Zeit zu verfeinern.

Ohne das wird Ihr Agent weiterhin die gleichen Fehler machen. Wir haben dem Kundenservice-Agenten meines Freundes eine grundlegende Reflexionsstufe hinzugefügt, bei der er nach dem Verfassen einer E-Mail fragte: „Deckt dieser Entwurf alle Punkte der ursprünglichen E-Mail ab? Ist der Ton angemessen? Gibt es Fakten, die ich überprüfen sollte?“ Diese einfache Selbstkritik, geleitet durch einen spezifischen LLM-Prompt, hat die Anzahl der Fehler erheblich reduziert.

Alles zusammenfügen: Ein praktisches Beispiel

Skizzieren wir eine vereinfachte Architektur für einen Agenten, der mir hilft, meinen persönlichen Kalender zu verwalten. Mein Ziel: “Finde ein 30-minütiges Zeitfenster in der nächsten Woche, um über das Projekt X mit Sarah zu sprechen, und vermeide Montage sowie nach 15:00 Uhr am Dienstag.”

So würden die Komponenten interagieren:

1. Wahrnehmung/Eingabe: Mein Sprach- oder Textbefehl ( “Finde ein 30-minütiges Zeitfenster…”) wird empfangen.
2. Orchestrator (LLM):
   • Empfängt den analysierten Input.
   • Unterteilt das Ziel:
     • Identifiziere die Teilnehmer (Sarah).
     • Identifiziere die Dauer (30 Minuten).
     • Identifiziere den Zeitraum (nächste Woche).
     • Identifiziere die Einschränkungen (keine Montage, nicht nach 15:00 Uhr am Dienstag).
   • Plant:
     • Schritt 1: Erhalte Sarahs Kalender.
     • Schritt 2: Erhalte meinen Kalender.
     • Schritt 3: Finde überlappende freie Zeitfenster unter Berücksichtigung der Einschränkungen.
     • Schritt 4: Schlage einen Termin vor.
3. Werkzeugausführer:
   • Der Orchestrator ruft ein Werkzeug `get_calendar_events` für Sarah auf.
   • Der Orchestrator ruft ein Werkzeug `get_calendar_events` für mich auf.
   • Der Orchestrator ruft ein Werkzeug `find_free_slots` mit den Parametern (duration, start_date, end_date, my_events, sarah_events, constraints) auf.
4. Speichermodul: (Implizit von den Werkzeugen für die Kalenderdaten und vom Orchestrator zur Erinnerung an die Einschränkungen und Zwischenergebnisse verwendet).
5. Orchestrator (LLM):
   • Erhält die Liste der vorgeschlagenen Zeitfenster vom Werkzeug `find_free_slots`.
   • Synthetisiert einen Vorschlag in natürlicher Sprache: “Wie wäre es mit Mittwoch, dem 20. März um 10:00 Uhr für 30 Minuten mit Sarah?”
6. Ausgabe/Aktion: Präsentiert den Vorschlag.
7. Reflexion/Rückmeldung: (Optional, aber nützlich) Nachdem ich bestätigt oder abgelehnt habe, könnte der Agent reflektieren:
   • Wenn bestätigt: „Dieser Plan hat gut funktioniert. Vergessen Sie nicht, die Zeitfenster zu Beginn der Woche zu priorisieren.“ (In langfristigem Gedächtnis speichern).
   • Wenn abgelehnt: „Warum wurde es abgelehnt? Wurde eine Einschränkung übersehen? War die vorgeschlagene Uhrzeit unangenehm?“ (Eine Neuplanung auslösen oder den Vorschlag verfeinern).

Beachten Sie, dass das LLM die komplexen Berechnungen des Kalenders nicht selbst durchführt. Es delegiert an spezialisierte Werkzeuge. Dies macht den Agenten viel zuverlässiger und effizienter.

Ein Kleines Beispiel für Code (Python-Pseudocode)

Hier ist eine vereinfachte Übersicht, wie ein Orchestrator Werkzeuge aufrufen könnte. Stellen Sie sich vor, wir haben ein `ToolRegistry`, das Funktionen enthält.

class CalendarAgent:
 def __init__(self, llm_client, tool_registry):
 self.llm_client = llm_client
 self.tool_registry = tool_registry
 self.memory = [] # Einfache Liste für das kurzfristige Gedächtnis

 def process_request(self, user_query):
 # Füge die Benutzeranfrage zum Gedächtnis hinzu
 self.memory.append({"role": "user", "content": user_query})

 # Schritt 1: Der Orchestrator plant die nächste Aktion
 plan_prompt = f"""
 Sie sind ein nützlicher Kalenderassistent. Ihr Ziel ist es, Meeting-Zeitfenster zu finden.
 Angesichts der Benutzeranfrage und des Gesprächsverlaufs:
 {self.memory}

 Was ist der nächste logische Schritt?
 Optionen:
 1. CALL_TOOL(tool_name, arguments_json) - zum Beispiel, CALL_TOOL("get_calendar_events", {{"user": "alex"}})
 2. RESPOND(message) - Dem Benutzer antworten.
 3. AWAIT_USER_INPUT() - Nach weiteren Informationen fragen.

 Ihre Antwort sollte *ausschließlich* eine der obigen Optionen sein.
 """
 orchestrator_response = self.llm_client.generate(plan_prompt)

 if "CALL_TOOL" in orchestrator_response:
 tool_call_str = orchestrator_response.split("CALL_TOOL(")[1].split(")")[0]
 tool_name, args_json = eval(tool_call_str) # Seien Sie vorsichtig mit eval in echten Systemen!
 
 # Schritt 2: Führen Sie das Werkzeug aus
 if tool_name in self.tool_registry:
 tool_function = self.tool_registry[tool_name]
 tool_result = tool_function(**args_json)
 self.memory.append({"role": "tool_output", "content": str(tool_result)})
 
 # Nach der Ausführung des Werkzeugs erneut orchestrieren
 return self.process_request(f"Werkzeug {tool_name} hat zurückgegeben: {tool_result}. Was ist der nächste Schritt?")
 else:
 self.memory.append({"role": "system", "content": f"Fehler: Werkzeug {tool_name} nicht gefunden."})
 return self.process_request("Ich habe einen Fehler mit einem Werkzeug festgestellt. Bitte versuchen Sie es erneut.")

 elif "RESPOND" in orchestrator_response:
 response_message = orchestrator_response.split("RESPOND(")[1].split(")")[0]
 self.memory.append({"role": "assistant", "content": response_message})
 return response_message
 
 # ... Verarbeiten Sie AWAIT_USER_INPUT und andere Fälle
 
# Beispiel eines Werkzeugs
def get_calendar_events(user_name, start_date, end_date):
 # In einem echten System würde dies eine Kalender-API aufrufen
 print(f"Suche nach Ereignissen für {user_name} vom {start_date} bis {end_date}...")
 if user_name == "alex":
 return [{"event": "Teammeeting", "time": "2026-03-17 09:00"}]
 elif user_name == "sarah":
 return [{"event": "Kundenmeeting", "time": "2026-03-18 14:00"}]
 return []

# Vereinfachter Moq LLM-Client
class MockLLM:
 def generate(self, prompt):
 # Hier würde ein echter Aufruf an das LLM stattfinden.
 # Zur Demonstration werden wir eine einfache Antwort codieren.
 if "get Sarah's calendar" in prompt:
 return 'CALL_TOOL("get_calendar_events", {"user": "sarah", "start_date": "next_week", "end_date": "next_week_end"})'
 elif "get Alex's calendar" in prompt:
 return 'CALL_TOOL("get_calendar_events", {"user": "alex", "start_date": "next_week", "end_date": "next_week_end"})'
 elif "Tool get_calendar_events returned" in prompt:
 return 'RESPOND("Ich habe beide Kalender zusammengetragen. Ich suche jetzt nach einem passenden Zeitfenster...")' # Tatsächlich würde hier ein weiterer Werkzeugaufruf stattfinden, um ein Zeitfenster zu finden
 return 'RESPOND("Ich weiß nicht, wie ich fortfahren soll.")'


tool_registry = {
 "get_calendar_events": get_calendar_events
 # ... andere Werkzeuge wie find_free_slots, create_event, usw.
}

agent = CalendarAgent(MockLLM(), tool_registry)
# print(agent.process_request("Finde ein 30-minütiges Zeitfenster in der nächsten Woche, um über das Projekt X mit Sarah zu sprechen."))

Dieser Code ist eine *sehr* starke Vereinfachung, zeigt jedoch die Hauptidee: Der Orchestrator entscheidet, welches Werkzeug aufgerufen wird, und das Werkzeugverzeichnis führt es aus. Der Speicher verfolgt, was bisher passiert ist. Diese explizite Struktur gibt Ihnen die Kontrolle.

Praktische Lehren

Was bedeutet das also für Sie, wenn Sie Ihren nächsten KI-Agenten aufbauen?

1. Bitten Sie Ihr LLM nicht, alles alleine zu machen: Behandeln Sie Ihr LLM als eine leistungsstarke Denkmaschine und Schnittstelle in natürlicher Sprache, nicht als Datenbank, Rechner oder Langzeitgedächtnis. Delegieren Sie deterministische Aufgaben an spezialisierte Funktionen und Systeme.
2. Modularisieren Sie gnadenlos: Zerlegen Sie Ihren Agenten in getrennte Komponenten mit einer einzigen Verantwortung: Orchestrator, Gedächtnis, Werkzeuge, Wahrnehmung, Ausgabe und vor allem Reflexion. Dies erleichtert das Debugging, die Skalierung und die Verbesserung einzelner Teile.
3. Implementieren Sie starke Gedächtnissysteme: Über das Kontextfenster des LLM hinaus benötigen Sie ein kurzfristiges Gedächtnis (aktiv) und ein langfristiges Gedächtnis (Wissensdatenbank). Vektor-Datenbanken sind hervorragend für die semantische Suche im langfristigen Gedächtnis, aber vergessen Sie nicht traditionelle Datenbanken für strukturierte Daten.
4. Priorisieren Sie die Entwicklung von Werkzeugen: Die Qualität und Vielfalt Ihrer Werkzeuge beeinflussen direkt die Fähigkeiten Ihres Agenten. Stellen Sie sicher, dass Ihre Werkzeuge zuverlässig, gut dokumentiert und für den Orchestrator einfach aufzurufen sind, mit klaren Ein-/Ausgabeschemata.
5. Integrieren Sie Selbstkorrektur: Eine starke Reflexions- oder Feedbackschleife ist unverzichtbar für zuverlässige Agenten. Lassen Sie Ihren Agenten seine eigenen Leistungen bewerten und aus Erfolgen und Misserfolgen lernen. Dies kann so einfach sein wie eine strukturierte Eingabe zur Selbstkritik oder komplexeres verstärktes Lernen basierend auf menschlichem Feedback.
6. Setzen Sie auf Iteration und Nachverfolgung: Die Entwicklung von Agenten ist ein iterativer Prozess. Setzen Sie ihn ein, überwachen Sie sein Verhalten in realen Szenarien, sammeln Sie Daten über Fehler und Erfolge und nutzen Sie diese, um Ihre Eingaben, Werkzeuge und die gesamte Architektur zu verfeinern.
7. Berücksichtigen Sie Sicherheitsmaßnahmen und Schutzvorrichtungen: Besonders wenn Agenten mit externen Systemen interagieren, implementieren Sie eine strenge Validierung der Eingaben für die Werkzeuge, eine Ratenbegrenzung und menschliche Eingriffe für kritische Entscheidungen.

Zuverlässige KI-Agenten zu bauen, ist keine Frage, das perfekte LLM zu finden; es geht darum, ein System um dieses LLM zu konstruieren, das die Struktur, die Informationen und die Kontrolle bereitstellt, die benötigt werden, um konsistent und sicher zu funktionieren. Es ist die Anwendung guter Prinzipien der Softwarearchitektur auf ein neues Paradigma. Wenn Sie das tun, werden Sie über die Phase „magisch, aber fragil“ hinauskommen und wirklich nützliche und vertrauenswürdige Agenten bauen.

Das ist alles von mir für heute. Legen Sie los und bauen Sie solide Agenten! Teilen Sie mir Ihre Gedanken oder Erfahrungen in den Kommentaren unten mit.

🕒 Published: March 30, 2026