Die vier Schichten Architektur für deterministische KI-Agenten

Die Leistungsfähigkeit von AI-gestützten Systemen steigt, wenn nur die Entscheider (LLM) stochastisch agieren, während alle durchführbaren Aktionen deterministisch programmiert und über strukturierte Funktionen ausgeführt werden.

Key Takeaway

Die Leistungsfähigkeit von AI-gestützten Systemen steigt, wenn nur die Entscheider (LLM) stochastisch agieren, während alle durchführbaren Aktionen deterministisch programmiert und über strukturierte Funktionen ausgeführt werden.

Summary

• Master Prompt vs. Deterministischer Ansatz – Der häufige „Master Prompt“-Ansatz („You are a helpful assistant“) führt zu einem allgegenwärtigen Agenten, der zu viele Aufgaben gleichzeitig übernimmt und dadurch Fehlerhäufigkeit sowie Halluzinationen steigen.
• Operationstypen – *Löseprobleme* (z. B. File‑Search, Test‑Ausführung, Build‑Validierung, YAML‑Parsing) – reliably implementierbar und deterministisch. *Unsolveprobleme* (z. B. Ursachenanalyse bei Kubernetes‑Pod‑Fehlern, Kontext‑Verständnis) – erfordern kontextuelle Entscheidungen, die das LLM übernehmen muss.
• Vier‑Schichten‑Architektur – 1. Router (Layer 1) – Identifiziert Aufgaben (z. B. “debug diese auth service”) und leitet sie an den passenden Fachagenten weiter, verhindert Kontextverschmutzung. 2. Agent (Layer 2) – Repräsentiert Fachwissen (z. B. Go‑Programmierer: Idiome, Projektarchitektur, Anti‑Pattern) und vermittelt die nötigen Informationen, aber nicht die Vorgehensweise. 3. Skill (Layer 3) – Definiert ein deterministisches Verfahren (z. B. Systematischer Debug‑Workflow: Reproduzieren → Isolieren → Identifizieren → Verifizieren) und erzwingt deren Einhaltung. 4. Deterministische Programme (Layer 4) – Binden spezifische, deterministische Tools ein (z. B. ripgrep‑Wrapper, read_file(), strukturierte Kubectl‑Funktionen) – die LLM greift nicht direkt auf die Umgebung zu.
• Praktisches Beispiel: Fehlenden Kubernetes‑Pod debuggen – 1. Router klassifiziert als „Kubernetes‑Debug“ → Leitet an Kubernetes‑Engineer‑Agent mit „systematischer Debug‑Skill“. 2. Agent lädt K8s‑Domain‑Wissen (Zustände, Ereignisse, Logs). 3. Skill führt Schritt‑für‑Schritt‑Debug‑Prozess durch; das LLM darf nicht vorzeitig diagnostizieren. 4. Deterministische Funktionen sammeln strukturierte Daten (z. B. get_pod_description(), get_pod_events(), get_container_logs()). 5. LLM nutzt diese Daten, um die Ursache (z. B. ImagePullBackOff durch abgelaufenes Registry‑Secret) zu ziehen.
• Grundprinzip: „Alles, was deterministisch ist, sollte programmiert sein“ – LLM wird nur für Entscheidungen benötigt, die über reine Programmierung hinausgehen (Interpretation, Diagnose, Verknüpfung verschiedener Kontexte). Durch deterministic Tools wird Fehlertoleranz erhöht, Halluzinationen reduziert und die Wiederholbarkeit des Systems verbessert.

Weiterführende Links

• The /do Router – Details zur Router‑Implementierung.
• GraphBit‑Artikel zu deterministischen Tools und Validated Execution Graphs (2025).

Schlussbetrachtung

Die neuen Konzepte (Router → Agent → Skill → Programme) bilden eine klare Trennung zwischen fachlichem Wissen, methodischer Vorgehensweise und programmatischer Ausführung. Das Ziel ist, die „magnitude‑9‑Earthquake“ (disruptive Technologie) nicht zu vernachlässigen, sondern die Kontrolle durch deterministische Programmierung zu übernehmen, während das LLM als flexible Entscheidungsinstanz verbleibt.

Related queries:

Was ist der Unterschied zwischen Master Prompt und dem vier Schichten Ansatz?
Wie kann der Systematic Debug Skill in anderen Kontexten eingesetzt werden?
Welche Programm wrappers wurden für die Kubernetes‑Funktionalität beschrieben?

Quelle: Everything that can be deterministic should be my Claude code setup