Frederik von der Heyden

Posted on Aug 22

Das System, das sich selbst verbessert

#aiagents #architecture #devops #machinelearning

Was passiert, wenn KI-Systeme Erfahrung speichern

Vor vier Monaten hat mein System einen Fehler gemacht. Ein Agent hat beim Deployment vergessen, die Datenbank-Berechtigungen zu prüfen. Die App ging online. Ohne Rechte auf die Nutzertabelle. Login unmöglich.

Zwanzig Minuten Reparatur. Dann eine Regel. Zwei Wochen später hat das System diese Regel dreimal angewendet, dreimal einen Fehler verhindert. Am dritten Mal wurde die Regel dauerhaft übernommen. Jetzt ist sie Teil des Systems. Kein Mensch muss sich daran erinnern.

Das klingt einfach. Ist es nicht.

Das Problem mit Agenten-Erfahrung

Jeder, der ernsthaft mit KI-Agenten arbeitet, kennt das Muster: Du löst ein Problem. Der Agent macht etwas falsch. Du korrigierst ihn. Beim nächsten Durchlauf macht er denselben Fehler wieder.

Das liegt nicht daran, dass das Modell schlecht ist. Es liegt daran, dass der Kontext weg ist. Agenten-Erfahrung verschwindet nach jeder Session. Jeder neue Lauf beginnt bei null.

Das ist der Unterschied zwischen einem System, das lernt, und einem System, das nur ausführt.

Mein Crystallization-Loop ist meine Antwort darauf. Kein Finetuning. Kein Training. Kein Prompt-Engineering im klassischen Sinne. Stattdessen: Fehler werden zu Beobachtungen. Beobachtungen werden zu Regeln. Regeln werden zu Code.

Wie der Crystallization-Loop funktioniert

Die technische Grundstruktur ist überraschend schlicht. Es gibt drei Schichten:

Schicht 1: Beobachtung

Nach jedem Agenten-Lauf wird ein structured log geschrieben. Nicht nur Erfolg oder Fehler, sondern was genau passiert ist, an welchem Punkt, mit welchem Kontext.

# Beispiel-Struktur eines Observations-Log
{
  "timestamp": "2026-04-12T14:32:00Z",
  "agent": "deployment-agent",
  "checkpoint": "pre-deploy",
  "failure": "db_permissions_unchecked",
  "context": {
    "target_env": "production",
    "tables_accessed": ["users", "sessions"],
    "permissions_verified": false
  },
  "resolution_time_minutes": 20,
  "resolution": "manual_permissions_grant"
}

Schicht 2: Regelgenerierung

Ein separater Analyse-Agent läuft täglich. Er schaut sich alle Beobachtungen der letzten 30 Tage an und sucht nach Mustern. Wenn dasselbe Muster dreimal auftaucht, schlägt er eine Regel vor.

# Vereinfachtes Beispiel der Regelgenerierung
def crystallize_observation(observations: list[dict]) -> Rule | None:
    pattern = find_recurring_pattern(observations, min_occurrences=3)
    if not pattern:
        return None

    return Rule(
        trigger=pattern.trigger_condition,
        action=pattern.suggested_check,
        confidence=pattern.occurrence_count / len(observations),
        source="crystallization_loop",
        created_at=datetime.now()
    )

Schicht 3: Integration

Akzeptierte Regeln werden als Guard-Hooks in die Agent-Pipeline eingebunden. Kein separates System. Kein optionaler Check. Die Regel feuert automatisch, bevor der Agent die kritische Aktion ausführt.

Das Deployment-Berechtigungs-Beispiel sieht heute so aus:

# .claude/hooks/guards/db_permissions_guard.sh
# Kristallisiert am 2026-04-28 aus 3 Beobachtungen
check_table_permissions() {
    local tables=("$@")
    for table in "${tables[@]}"; do
        if ! psql -c "SELECT has_table_privilege(current_user, '$table', 'SELECT')" \
             | grep -q "t"; then
            echo "GUARD: Fehlende Berechtigung auf Tabelle $table"
            exit 1
        fi
    done
}

Was in vier Monaten entstanden ist

211 Regeln. 73 Learnings, die kein Mensch formuliert hat.

Das klingt beeindruckend. Ist aber auch das Ergebnis von systematischen Fehlern, die ich nicht vorhersehen konnte.

Ein paar Beispiele aus dem echten Betrieb:

Guard: Keine externen API-Calls ohne Rate-Limit-Check. Entstanden, weil ein Agent in drei Wochen viermal in API-Limits gelaufen ist. Jeweils zehn Minuten Debugging. Die Regel kostet heute zwei Millisekunden pro Lauf.

Guard: Kein File-Write ohne Backup-Pfad-Verifikation. Entstanden aus zwei Vorfällen, bei denen ein Schreibfehler Datei-Inkonsistenzen hinterlassen hat. Die Regel kostet nichts, verhindert aber Inkonsistenzen, die Stunden kosten würden.

Learning: Kontextuelle Fehlermeldungen sind dreimal effizienter als generische. Das war keine Beobachtung aus einem Fehler, sondern aus einem Vergleich: Zwei Agenten, dasselbe Problem, unterschiedliche Fehlermeldungen. Der mit kontextueller Meldung wurde dreimal schneller resolviert.

Das beschreibe ich ausführlich in "Läuft ohne mich", meinem Buch über Agenten-Systeme, die sich selbst organisieren.

Was das System nicht kann

Ehrlichkeit ist hier wichtig. Der Crystallization-Loop hat Grenzen.

Er kristallisiert Erfahrung aus Mustern. Er erkennt keine Einmal-Ereignisse. Ein schwerwiegender Fehler, der nur einmal auftritt, landet in den Logs, aber nicht automatisch in einer Regel. Das erfordert manuellen Eingriff.

Er ist auch kein Ersatz für gutes System-Design. Wenn die Grundarchitektur falsch ist, macht der Loop falsche Erfahrungen schneller wiederholbar, nicht besser. Garbage in, garbage out, nur mit mehr Automatisierung.

Und er hat einen blinden Fleck: Regeln, die sich gegenseitig beeinflussen. Mit 211 Guards prüfe ich mittlerweile monatlich manuell auf Konflikte. Noch ist es handhabbar. Bei 500 Regeln werde ich einen Meta-Guard brauchen.

Warum das kein Standardprodukt ist

Microsoft hat kein Äquivalent. Google auch nicht. Das liegt nicht an fehlendem Know-how. Es liegt daran, dass diese Art von Erfahrungsspeicherung zutiefst kontextspezifisch ist.

Meine 211 Regeln sind meine Regeln. Sie entstammen meinen Agenten, meinen Fehlern, meinem Stack. Sie auf ein generisches Produkt zu übertragen würde bedeuten, dass jeder Nutzer bei null anfängt, mit einem System, das noch keine Erfahrung hat.

Das ist das grundlegende Problem mit industriellen KI-Plattformen: Sie optimieren für den Durchschnitt. Crystallization-Loop optimiert für dich.

Ein Deployment-Check, der bei meinen Agenten dreimal aufgetaucht ist, taucht bei dir vielleicht nie auf. Dafür hast du andere Fehler, die du nur einmal machen willst.

Die praktische Frage: Wo anfangen?

Wenn du anfangen willst, dieses Prinzip umzusetzen, ohne ein vollständiges System aufzubauen, gibt es einen einfachen Einstieg:

Schreib jeden Agent-Fehler in ein strukturiertes Log. Nicht freier Text, sondern maschinenlesbare Felder.
Lies dieses Log wöchentlich. Suche nach Mustern, nicht nach Einzelvorfällen.
Schreib die erste Regel manuell, wenn du ein Muster findest.
Lass den Agenten die Regel beim nächsten Lauf anwenden.
Erst wenn du zehn manuelle Regeln hast, lohnt sich die Automatisierung des Prozesses.

Der Loop entsteht nicht durch Technologie. Er entsteht durch Disziplin. Die Technologie macht ihn skalierbar.

Wichtigste Erkenntnisse

Agenten-Erfahrung verschwindet nach jeder Session, es sei denn, du baust aktiv dagegen.
Drei Wiederholungen eines Fehlers sind das Signal für eine Regel, nicht einer.
Guards als automatisch feuernde Hooks sind robuster als Prompts, die den Agenten bitten, etwas zu prüfen.
Der Wert des Systems entsteht nicht im ersten Monat, sondern wenn Regel Nummer 50 einen Fehler verhindert, an den du dich längst nicht mehr erinnerst.
Manuelle Regeln zuerst, Automatisierung danach. Nicht umgekehrt.
Konflikte zwischen Regeln sind das größte Skalierungsproblem und müssen aktiv gemanagt werden.

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.

DEV Community