5 Lektionen: Model Routing, Knowledge Graph, RAG-Pipeline und wöchentliche Synthese.
Guards, Self-Healing und Self-Learning beantworten die Frage „Wie halte ich dieses System sicher und verbesserungsfähig." Keine davon beantwortet eine ebenso praktische Frage: Woher weiß das System genug über sich selbst, um über sich selbst nachzudenken?
Ein Agent innerhalb eines einzelnen Repositorys kann dessen Struktur im Kontextfenster halten. Ein Agent über 23 Repositorys hinweg kann das nicht. Und ein Mensch über 23 Repositorys hinweg auch nicht. 16.756 Vault-Dateien gesammelter Notizen speichern ist nutzlos, wenn der Abruf der relevanten Datei länger dauert als die Antwort einfach neu abzuleiten.
Die Intelligenzschicht umfasst vier Säulen: Model Routing, Knowledge Graph, RAG-Pipeline und wöchentliche Synthese. Zusammen ermöglichen sie dem Betrieb, über seinen eigenen Zustand nachzudenken, statt blind Aufgaben auszuführen.
Kernprinzip: Guards machen die Leitplanken klüger. Die Intelligenzschicht macht den Betreiber klüger. Ein menschlicher Betreiber mit 23 Repos und 16.756 Notizen braucht Werkzeuge, um überhaupt zu wissen, was er selbst bereits weiß.
Keine der vier Schichten (Guards, Self-Healing, Self-Learning, Intelligenz) leistet isoliert etwas Nützliches. Guards ohne den Knowledge Graph sind blind für den Blast Radius. Self-Healing ohne Guards ist rücksichtslos. Self-Learning ohne zuverlässigen Abruf sammelt Notizen, die niemand findet, wenn sie gebraucht werden. Im laufenden System sind sie ein Stack: die Ausgabe jeder Schicht speist die Eingabe der nächsten.
Alles auf einem Modell laufen lassen, egal wie leistungsfähig, ist teuer und fragil. Teuer, weil ein Frontier-Reasoning-Modell Overkill ist, um ein Support-Ticket zu klassifizieren. Fragil, weil ein einziger Anbieter, der nicht verfügbar ist, den gesamten Betrieb lahmlegt.
Das Produktionssystem umfasst 5 Anbieter über 6 Leistungsstufen, aufgelöst durch ein einziges Router-Skript. Lokale Ollama-Modelle erledigen alles, was lokal laufen kann: Embeddings, Klassifikation, nächtliche Scans, günstige Analysen. Cloud-Modelle (Claude, OpenAI, Gemini, Mistral) sind für denkintensive Arbeit und Inhaltserstellung reserviert.
Die praktische Dividende: Das Kostenprofil wird durch die Routing-Disziplin geprägt, nicht durch das Gesamtvolumen. Die überwältigende Mehrheit der Operationen läuft lokal mit Grenzkosten nahe null. Die Cloud-Tiers verursachen die echten Ausgaben, aber weil sie auf Urteilsentscheidungen konzentriert sind, skalieren die Kosten mit dem Schwierigkeitsgrad, nicht mit dem Volumen.
Kernprinzip: Kein einzelner Anbieter darf zum zentralen Ausfallrisiko werden. Wenn ein Cloud-Anbieter ausfällt, hält die lokale Stufe die Routinearbeit am Laufen. Wenn ein lokales Modell für eine Ermessensentscheidung nicht reicht, wechselt der Router zur Cloud.
#!/bin/bash # Tier anfordern, nicht Modell hartkodieren ROUTE_JSON=$(/opt/scripts/model-router.sh --json standard) PROVIDER=$(printf '%s' "$ROUTE_JSON" | jq -er '.provider') MODEL_ID=$(printf '%s' "$ROUTE_JSON" | jq -er '.model_id') # Validierung: kein eval, kein blindes Vertrauen if [ -z "$PROVIDER" ] || [ -z "$MODEL_ID" ]; then echo "FEHLER: Router lieferte ungültige Antwort" >&2 exit 1 fi # Jetzt mit Provider und Model arbeiten echo "Routing zu: $PROVIDER / $MODEL_ID"
16.756 Vault-Dateien werden von einer lokalen RAG-Pipeline nutzbar gemacht. Embeddings lokal generiert, für schnelle semantische Suche indiziert. Eine neue Session zu einem zuvor berührten Thema muss den Kontext nicht von Grund auf neu ableiten.
Der hybride Ansatz kombiniert TF-IDF-Keyword-Matching mit Embedding-basierter semantischer Suche. Die beiden fangen verschiedene Fehlermodi ab: Keyword-Matching findet exakte Begriffsabgleiche, selbst bei ungewöhnlicher Formulierung. Embedding-Suche findet konzeptionell verwandte Notizen, selbst ohne ein einziges gemeinsames Wort. Keines allein ist zuverlässig genug. Zusammen decken sie gegenseitig ihre blinden Flecken ab.
Warum lokal statt Cloud-Embedding-API? Dasselbe Prinzip wie beim Model Routing. Embeddings sind hochvolumig mit geringem Urteilsbedarf, genau die Art von Arbeit, die auf lokale Infrastruktur gehört.
Kernprinzip: Die RAG-Pipeline ruft relevanten früheren Kontext ab, garantiert aber nicht, dass er noch korrekt ist. Deshalb existiert die Staleness-Prüfung (aus der Self-Learning-Kette) neben ihr, nicht statt ihr. Abruf ohne Gültigkeitsprüfung ist gefährlicher als gar kein Abruf.
# Schritt 1: Keyword-Suche (schnell, präzise bei exakten Begriffen) keyword_results=$(grep -rl "self-healing" /opt/obsidian-vault/ | head -20) # Schritt 2: Semantische Suche (fängt verwandte Konzepte) semantic_results=$(/opt/scripts/memory-query.sh "Wie repariert sich das System nachts?") # Schritt 3: Ergebnisse zusammenführen, Duplikate entfernen # Hybrid-Score: keyword_match * 0.4 + semantic_similarity * 0.6 # Schritt 4: Gültigkeitsprüfung # Für jedes Ergebnis: Stimmt der Inhalt noch mit dem aktuellen Code überein?
ollama pull nomic-embed-text)7 MCP-Server bilden Brücken zwischen Reasoning-Schicht und realer Infrastruktur: Datenbankzugriff, Deployment-Status, Vault-Operationen, Knowledge Graph, Browser-Automatisierung, Routing und Policy. Dazu kommen 85 Autonomie-Skripte für einzelne Jobs und 92 Skills, die wiederholbare Prozeduren verpacken.
Der Knowledge Graph erstellt eine strukturelle Karte von Code, Abhängigkeiten und Beziehungen über jedes Repository hinweg. Eine Frage wie „Was nutzt diese Funktion?" oder „Was bricht, wenn ich dieses Schema ändere?" bekommt eine konkrete Antwort, statt eine manuelle Suche über ein Dutzend Codebasen zu erfordern.
Am wichtigsten genau in den Momenten, die Guards schützen sollen: direkt vor einer strukturellen Änderung. Du musst wissen, was von dem abhängt, was du gleich anfassen wirst. Vor dem Anfassen, nicht nachdem etwas Nachgelagertes bricht.
Ein zweites Modell einsetzen, um die Ausgabe des ersten herauszufordern. Guards fangen Aktionen ab, die einem bekannten schlechten Muster entsprechen. Aber ein fehlerhaftes Reasoning, das zu einer technisch wohlgeformten, Guard-konformen Aktion führt, schlüpft direkt durch. Ein zweites Modell von einem anderen Anbieter fängt eine andere Fehlerklasse: nicht „Ist diese Aktion erlaubt?" sondern „Ist das die richtige Entscheidung?"
Kernprinzip: 92 Skills. Nicht 92 Features. 92 Prozeduren, die das System zuverlässig genug gelernt hat, um als wiederverwendbare Einheiten verpackt zu werden. Die meisten entstanden, nachdem dieselbe Aufgabe oft genug manuell erledigt wurde.
graphify build oder einem einfachen DOT-Graph)Der „Professor" ist ein wöchentlicher Prozess, der Guards, Cron-Jobs, Memory, Modellnutzung und Vorfallsmuster betrachtet. Statt nur zu berichten, was passiert ist, schlägt er vor, was sich ändern sollte. Ein Statusbericht sagt dir, ob das System letzte Woche funktioniert hat. Eine Reifegradeinschätzung fragt, ob das System in seiner aktuellen Form noch die richtige Gestalt für seine aktuellen Aufgaben hat.
Das vollständige Inventar: 7 MCP-Server, 85 Autonomie-Skripte, 92 Skills. Nichts davon existiert als monolithischer Service. Jedes Stück hat einen schmalen, definierten Job und übergibt sauber an das nächste.
Der Knowledge Graph zeigt strukturelle Beziehungen (was importiert was, was hängt von was ab), keine geschäftlichen Absichten. Die RAG-Pipeline ruft relevanten Kontext ab, garantiert aber nicht Korrektheit. Die wöchentliche Synthese ist nur so gut wie die Signale, die sie füttern. Ein blinder Fleck im Logging wird zum blinden Fleck des Professors.
Kernprinzip: Der Router entscheidet nicht, was wichtig ist. Er führt eine Entscheidung aus, die ein Mensch einmal getroffen hat, bewusst, und so kodiert hat, dass sie nicht bei jedem Aufruf von Grund auf neu getroffen werden muss. Die Intelligenz liegt in der Festlegung, nicht im Routing.
# Professor-Synthese: Wöchentlicher Ablauf 1. GUARD-ANALYSE - Welche Guards haben diese Woche am häufigsten gefeuert? - Gibt es neue Muster, die noch kein Guard abdeckt? - Welche Guards haben seit >30 Tagen nicht gefeuert (veraltet?) 2. CRON-GESUNDHEIT - Welche Cron-Jobs sind diese Woche fehlgeschlagen? - Gibt es Jobs, deren Laufzeit deutlich gestiegen ist? 3. MEMORY-ZUSTAND - Wie viele neue Learnings diese Woche? - Wie viele Beförderungskandidaten (Score>=4, Runs>=3)? - Wie viele veraltete Einträge markiert? 4. MODELLNUTZUNG - Cloud vs. lokal Verhältnis (Ziel: >80% lokal) - Kosten pro Tier diese Woche 5. EMPFEHLUNG - Top-3 Verbesserungen für nächste Woche - Jede mit konkretem nächsten Schritt
Modul 3 abgeschlossen
Du hast jetzt: Model Routing verstanden, eine RAG-Pipeline gebaut, den Knowledge Graph eingerichtet und die wöchentliche Synthese gestartet.
Weiter mit Modul 4: Multi-Agent-Orchestrierung