Hey zusammen, Alex hier von agntai.net. Es ist der 17. März 2026, und ich habe mit einem bestimmten Problem im Agentendesign zu kämpfen, das viele von euch vielleicht auch antrefft. Wir alle versuchen, intelligentere, autonomere KI-Agenten zu entwickeln, oder? Aber sobald man beginnt, echte Weltkomplexität einzuführen, zerfallen die sauber getrennten „Wahrnehmung-Kognition-Handlung“-Schleifen oft zu einer chaotischen Ansammlung bedingter Logik.
Ich spreche über die Herausforderung, Agenten zu bauen, die ihren internen „Denkprozess“ wirklich an den unmittelbaren Kontext anpassen können, ohne ihre gesamte Architektur für jede neue Aufgabe neu gestalten zu müssen. Besonders habe ich erkundet, wie wir über statische, vordefinierte Denkmuster hinausgehen können, hin zu etwas Dynamischem und Emergentem – was ich „Fluid Reasoning Architectures“ nenne.
Das Problem mit festen Denk-Pipelines
Denken wir an einen typischen KI-Agenten, der beispielsweise eine komplexe Datenpipeline verwaltet. Ihr hättet vielleicht ein Modul, das die Systemgesundheit überwacht, ein weiteres, das die Datenqualität analysiert, und ein drittes, das Korrekturmaßnahmen auslöst. Zunächst legt man einen Fluss fest: Wenn die Systemgesundheit gut ist UND die Datenqualität schlecht, dann priorisiere die Datenreinigung. Wenn die Systemgesundheit schlecht ist, dann priorisiere die Systemwiederherstellung und betrachte erst dann die Datenqualität.
Das funktioniert eine Weile gut. Aber dann kommt eine neue Anforderung: Manchmal, selbst wenn die Datenqualität schlecht ist, wenn ein kritischer, hochpriorisierter Bericht in 5 Minuten fällig ist, muss der Agent *vorübergehend* Datenqualitätsprobleme ignorieren, das aktuelle Batch durchpushen und es zur späteren Überprüfung kennzeichnen. Oder vielleicht muss der Agent einen Diagnoselauf *bevor* er eine Handlung entscheidet, wenn die Fehlermeldung mehrdeutig ist.
Plötzlich vermehren sich eure sauberen if-else-Anweisungen. Ihr fügt Flags hinzu, führt neue Zustände ein, und euer Denkmodul wird zu einem brüchigen, schwer wartbaren Wesen. Ich war schon dort. Mein letzter Versuch mit einem „smarten Finanzanalyst-Agenten“ endete mit einem Entscheidungsbaum, der nach drei Monaten Iterationen weniger wie ein Baum und mehr wie ein dorniger Busch aussah. Es war ein Albtraum, ihn zu debuggen, und sein Verhalten in neuen Situationen vorherzusagen wurde zu einem Glücksspiel.
Das Kernproblem, wie ich es sehe, ist, dass wir die Denkkomponenten unserer Agenten oft als feste Pipelines oder Zustandsmaschinen entwerfen. Diese sind ausgezeichnet für gut definierte, vorhersagbare Umgebungen. Aber die Realität erfordert Flexibilität. Der „beste“ Denkansatz oder die „richtige“ Abfolge von Operationen sind nicht immer statisch. Sie hängen vom Ziel, der aktuellen Umgebung, verfügbaren Werkzeugen und sogar dem internen Zustand des Agenten ab (z.B. sein Vertrauen in die aktuellen Daten).
Einführung von Fluid Reasoning Architectures: Ein metakognitiver Ansatz
Meine Erkundung der Fluid Reasoning Architectures ist ein Versuch, dies anzugehen. Die Idee ist, dem Agenten eine höherwertige Fähigkeit zu geben, *seine Denkstrategie auszuwählen*, anstatt einfach eine vordefinierte auszuführen. Es geht darum, eine metakognitive Schicht zu schaffen, die dynamisch den geeignetsten Denkweg basierend auf dem unmittelbaren Kontext zusammenstellen oder auswählen kann.
Es geht nicht darum, strukturiertes Denken vollständig abzulehnen. Es geht darum, diese Strukturen modular zu gestalten und eine „Regisseur“-Komponente zuzulassen, die sie orchestriert. Stellen Sie sich das wie einen Koch vor, der eine Speisekammer voller Zutaten (verschiedene Denkmodule) und ein Rezeptbuch (potenzielle Denkflüsse) hat, aber auch die Erfahrung und Intuition, diese auf neue Weise zu kombinieren oder bestehende Rezepte basierend auf dem, was verfügbar ist und was der Kunde möchte, anzupassen.
Die Kernkomponenten, mit denen ich experimentiere:
-
Denkprimitive (RPs): Dies sind eure atomaren Einheiten des Denkens oder der Verarbeitung. Sie könnten alles sein, von „Datenqualität analysieren“ (ein ML-Modellaufruf), „Systemgesundheit überprüfen“ (API-Aufruf), „Hypothesen generieren“ (LLM-Anfrage), „Risiko bewerten“ (regelbasierendes System), „Ablauf von Aktionen planen“ (Planungsmodul) oder „Wissensdatenbank durchsuchen.“ Jedes RP ist eine eigenständige, isolierte Fähigkeit.
-
Kontextuelle Hinweise: Dies sind die Eingaben, die die metakognitive Schicht informieren. Sie umfassen das aktuelle Ziel des Agenten, Umweltbeobachtungen, den internen Zustand (z.B. Vertrauenswerte, Ressourcenverfügbarkeit) und sogar historische Leistungsdaten.
-
Strategieauswähler (Die Fluidität-Engine): Dies ist das Gehirn des Betriebs. Basierend auf den kontextuellen Hinweisen entscheidet es, *welche* RPs aktiviert werden sollen und *in welcher Reihenfolge* (oder parallel), um das aktuelle Ziel zu erreichen. Dieser Selektor selbst kann ein LLM, eine erlernte Strategie (RL) oder sogar ein anspruchsvolles regelbasiertes System für einfachere Fälle sein.
-
Dynamisches Ausführungsdiagramm: Anstelle einer festen Pipeline generiert der Strategieauswähler ein sofort generiertes Ausführungsdiagramm von RPs. Dieses Diagramm bestimmt den Fluss von Informationen und Kontrolle zwischen den Primitiven.
Ein praktisches Beispiel: Der „Adaptive Content Moderator“
Lasst es uns konkret machen. Stellen Sie sich einen KI-Agenten vor, der benutzergenerierte Inhalte für eine Social-Media-Plattform moderiert. Eine feste Pipeline könnte so aussehen:
- Überprüfen auf explizite Bilder (RP1).
- Text auf Hassrede analysieren (RP2).
- Falls eines gefunden wird, zur menschlichen Überprüfung kennzeichnen.
Das ist zu simpel. Was ist, wenn der Inhalt satirisch ist? Was ist, wenn es sich um einen Nachrichtenbericht handelt, der sensibles Vokabular zu Bildungszwecken verwendet? Was ist, wenn die Plattform einen Anstieg von Spam erlebt und die Priorität auf Geschwindigkeit statt auf differenzierter Überprüfung verschoben wird?
Mit einer Fluid Reasoning Architecture könnte der Moderatoren-Agent diese RPs haben:
RP_Image_Nudity_Detector(image_data)RP_Text_Sentiment_Analyzer(text_data)RP_HateSpeech_Classifier(text_data)RP_Contextual_Nonsense_Detector(text_data, image_data)– das könnte eine anspruchsvollere LLM-Anfrage seinRP_Historical_User_Behavior_Checker(user_id)RP_Platform_Policy_Consultant(content_type, detected_issues)RP_Urgency_Assessor(platform_metrics, current_queue_size)RP_Generate_Review_Summary(all_findings)RP_Auto_Archive(content_id)RP_Flag_Human_Review(content_id, summary)
Der Strategieauswähler, vielleicht ein fein abgestimmtes LLM, würde Eingaben wie diese erhalten:
Content_Type: "Image with Caption"User_Trust_Score: 0.85Current_Platform_Alert_Level: "Normal"Queue_Size: "Low"
Basierend auf diesen Hinweisen könnte das LLM eine Denkstrategie entscheiden:
# Strategie 1: Standardüberprüfung (niedrige Dringlichkeit, hoher Vertrauensbenutzer)
If Content_Type == "Image with Caption":
results_image = RP_Image_Nudity_Detector(image_data)
results_text_sentiment = RP_Text_Sentiment_Analyzer(text_data)
results_text_hate = RP_HateSpeech_Classifier(text_data)
if results_image.is_explicit or results_text_hate.is_hate:
summary = RP_Generate_Review_Summary(results_image, results_text_sentiment, results_text_hate)
RP_Flag_Human_Review(content_id, summary)
else:
RP_Auto_Archive(content_id)
# Strategie 2: Beschleunigte Überprüfung (hohe Dringlichkeit, niedriger Vertrauensbenutzer)
If Current_Platform_Alert_Level == "High_Spam_Alert" and User_Trust_Score < 0.3:
results_text_sentiment = RP_Text_Sentiment_Analyzer(text_data) # Schnelle Überprüfung
results_user_behavior = RP_Historical_User_Behavior_Checker(user_id)
if results_text_sentiment.is_negative or results_user_behavior.has_prior_violations:
RP_Auto_Archive(content_id) # Aggressives Archivieren
else:
summary = RP_Generate_Review_Summary(results_text_sentiment, results_user_behavior)
RP_Flag_Human_Review(content_id, summary) # Oder ein leichteres Auto-Archivieren basierend auf Schwellenwert
Der tatsächliche Code würde keine if-else-Anweisungen *innerhalb* des Strategieauswälzers enthalten. Stattdessen würde der Selektor einen Plan ausgeben – eine Abfolge von RP-Aufrufen und deren Abhängigkeiten –, den eine Ausführungsengine dann durchführt. Die „if“-Bedingungen oben sind das, was der Strategieauswähler *bewertet*, um einen Plan zu entscheiden.
Hier ist ein vereinfachter konzeptioneller Ausschnitt, wie der Strategieauswähler funktionieren könnte:
class StrategySelector:
def __init__(self, llm_model, rp_registry):
self.llm = llm_model
self.rp_registry = rp_registry # Wörterbuch der verfügbaren RPs
def select_strategy(self, context: dict) -> list[tuple[str, dict]]:
"""
Erzeugt eine Folge von RP-Aufrufen basierend auf dem gegebenen Kontext.
Gibt eine Liste von (RP_name, args_for_RP) Tupeln zurück.
"""
prompt = self._build_prompt_from_context(context)
# Die Rolle des LLM: einen strukturierten Plan auszugeben, nicht ihn auszuführen
# Beispiel Ausgabe:
# {
# "plan": [
# {"rp": "RP_Image_Nudity_Detector", "inputs": ["image_data"]},
# {"rp": "RP_Text_Sentiment_Analyzer", "inputs": ["text_data"]},
# {"rp": "RP_HateSpeech_Classifier", "inputs": ["text_data"]},
# {"rp": "Conditional_Check", "condition": "output_of_RP_Image_Nudity_Detector.is_explicit or output_of_RP_HateSpeech_Classifier.is_hate", "then": "RP_Flag_Human_Review", "else": "RP_Auto_Archive"}
# ]
# }
# Das ist vereinfacht; ein reales System müsste solide Parsing- und Ausführungslogik für diese Bedingungsschritte haben.
raw_plan_json = self.llm.generate(prompt, temperature=0.2)
parsed_plan = self._parse_llm_plan(raw_plan_json)
return parsed_plan
def _build_prompt_from_context(self, context: dict) -> str:
# Hier passiert die Magie – das Problem für das LLM framen
available_rps = ", ".join(self.rp_registry.keys())
prompt_template = f"""
Du bist ein KI-Strategie-Selektor. Dein Ziel ist es, die am besten geeignete Folge von Reasoning Primitives (RPs) zu bestimmen, um ein Stück Inhalt zu verarbeiten, gegeben den folgenden Kontext.
Verfügbare RPs: {available_rps}
Aktueller Kontext:
{json.dumps(context, indent=2)}
Basierend auf diesem Kontext gebe ein JSON-Array aus, das den optimalen Plan darstellt. Jedes Element im Array sollte ein Objekt mit einem 'rp'-Schlüssel (dem RP-Namen) und einem 'inputs'-Schlüssel (einer Liste von Eingabedaten-Schlüsseln) sein. Du kannst auch 'condition'-Objekte für bedingte Logik einfügen.
Beispiel für einen einfachen Fall:
[
{{"rp": "RP_Image_Nudity_Detector", "inputs": ["image_data"]}},
{{"rp": "RP_Text_Sentiment_Analyzer", "inputs": ["text_data"]}}
]
Jetzt formuliere den Plan für den gegebenen Kontext:
"""
return prompt_template
# Beispielverwendung (konzeptionell)
# rp_registry = {
# "RP_Image_Nudity_Detector": ImageNudityDetector(),
# "RP_Text_Sentiment_Analyzer": TextSentimentAnalyzer(),
# # ... andere RPs
# }
# strategy_selector = StrategySelector(my_llm_agent, rp_registry)
# context = {
# "Content_Type": "Bild mit Bildunterschrift",
# "User_Trust_Score": 0.85,
# "Current_Platform_Alert_Level": "Normal",
# "Queue_Size": "Niedrig",
# "image_data": ,
# "text_data": "Dies ist eine Bildunterschrift des Nutzers."
# }
#
# plan = strategy_selector.select_strategy(context)
# # Ein Ausführungs-Engine würde dann diesen Plan nehmen und die RPs ausführen,
# # indem es Ausgaben als Eingaben an nachfolgende RPs wie im Plan definiert übergibt.
Der Schlüssel ist, dass der Strategie-Selektor nicht die Logik enthält, *wie* man Nacktheit oder Sentiment analysiert. Er weiß nur, *wann* er diese Werkzeuge verwenden soll. Und seine eigene „Logik“ (wenn es sich um ein LLM handelt) dreht sich darum, die richtige Folge zusammenzustellen, nicht die grundlegenden Aufgaben auszuführen.
Mein Weg mit Fluidem Denken
Ich habe vor etwa sechs Monaten angefangen, mit dieser Idee zu spielen, nach einer besonders frustrierenden Debugging-Session. Die anfänglichen Versuche waren sehr anfällig. Ich habe versucht, einen einfachen Regel-Engine für den Strategie-Selektor zu verwenden, aber er stieß schnell auf dieselben Skalierungsprobleme wie meine ursprünglichen festen Pipelines. Die „Regeln zur Auswahl von Regeln“ wurden zu komplex.
Dann habe ich zu einem kleinen, fein abgestimmten LLM für den Selektor gewechselt. Dies war ein bedeutender Wandel. Die Fähigkeit des LLM, nuancierte Kontexte zu interpretieren (wie „Current_Platform_Alert_Level: High_Spam_Alert“) und eine kohärente Abfolge von Schritten zu generieren, war überraschend gut. Ich habe es mit Beispielen verschiedener Szenarien und der gewünschten Denkwege trainiert und es im Grunde gelehrt, „darüber nachzudenken, wie man denkt“.
Eine Herausforderung, auf die ich gestoßen bin, war die Gewährleistung, dass die Ausgaben des LLM immer analysierbar und ausführbar sind. Ich musste ein sehr strenges JSON-Schema für die Plan-Ausgabe entwerfen und solide Validierungs- und Wiederholungsmechanismen implementieren. Manchmal halluzinierte das LLM ein RP, das nicht existierte, oder schlug eine unlogische Folge vor. Hier kam gutes Prompt-Engineering und sorgfältige Feinabstimmung ins Spiel.
Ein weiterer Vorteil, den ich gesehen habe, ist die Erklärbarkeit des Agents. Da der Strategie-Selektor einen „Plan“ vor der Ausführung ausgibt, kann man diesen Plan inspizieren. Man kann fragen, *warum* er diese Folge von RPs gewählt hat, basierend auf dem Kontext, möglicherweise sogar ein anderes LLM verwenden, um die Logik des Selektors basierend auf seinem internen Zustand oder Prompt zu interpretiert. Das macht das Debugging und die Prüfung viel einfacher, als zu versuchen, einen komplexen, geschachtelten bedingten Logikblock zu entwirren.
Umsetzbare Erkenntnisse für Ihre Agenten-Designs
Wenn Sie Agenten entwickeln und die Grenzen fixierter Argumentation erreichen, hier sind einige Punkte, die Sie beachten sollten:
-
Modularisieren Sie Ihre Argumentation: Zerlegen Sie komplexe Argumentationsschritte in atomare, unabhängige „Reasoning Primitives“. Jedes RP sollte klare Eingaben und Ausgaben haben und eine Sache gut machen (z. B. „Sentiment klassifizieren“, „Benutzerprofil abrufen“, „Zusammenfassung generieren“).
-
Identifizieren Sie kontextuelle Hinweise: Welche Informationen ändern wirklich, wie Ihr Agent ein Problem angehen sollte? Ist es Dringlichkeit, Benutzervertrauen, Datenzuverlässigkeit, Ressourcenverfügbarkeit oder der spezifische Typ der Anfrage? Definieren Sie diese ausdrücklich als Eingaben für Ihren höherstufigen Strategie-Selektor.
-
Experimentieren Sie mit einem Strategie-Selektor:
- Für einfachere Fälle könnte ein regelbasiertes System oder ein Entscheidungsbaum für den Selektor ausreichen.
- Für dynamischere und nuanciertere Entscheidungsfindung ist ein kleines, fein abgestimmtes LLM eine leistungsstarke Option. Betrachten Sie es als einen „Meta-Denker“, der Ihre anderen Module orchestriert. Fordern Sie es auf, strukturierte Pläne auszugeben (z. B. JSON).
-
Bauen Sie eine solide Ausführungs-Engine: Ihre Ausführungs-Engine muss den vom Strategie-Selektor erzeugten Plan übernehmen und die RPs tatsächlich ausführen. Dies beinhaltet die Verwaltung von Abhängigkeiten zwischen RPs (z. B. RP2 benötigt die Ausgabe von RP1), Fehlerbehandlung und gegebenenfalls die Implementierung von Wiederholungslogik.
-
Fokussieren Sie sich auf Erklärbarkeit: Der explizite Plan, der vom Selektor erzeugt wurde, bietet eine eingebaute Prüfspur. Nutzen Sie dies, um zu verstehen, warum Ihr Agent einen bestimmten Weg gewählt hat, was für Debugging und Vertrauen von unschätzbarem Wert ist.
Der Weg zu wirklich adaptiven KI-Agenten ist fortlaufend, aber ich glaube, dass Fluide Denkarchitekturen einen überzeugenden Weg bieten, der es unseren Agenten erlaubt, nicht nur Probleme zu lösen, sondern intelligent zu entscheiden, *wie* man sie löst. Probieren Sie es aus und lassen Sie mich Ihre Erfahrungen wissen!
Verwandte Artikel
- Ollama: KI-Modelle lokal auf Ihrem Computer ausführen
- KI-Agenten Skalierung und Ressourcenmanagement
- KI-Agent Infrastruktur Sicherheitsleitfaden
🕒 Published: