Am Ende des letzten Teils lief VectorSearch auf eigener Hardware, aber am zentralen Zugang vorbei: Der Redakteur sprach den Dienst direkt an, ohne dass eine Stelle prüfte, wer was darf. Dieser Teil holt das nach. Er erklärt, was ein Gateway leistet, warum die Wahl auf LiteLLM fiel und wie sich der Zugang so absichern lässt, dass nicht jeder Schlüssel alles öffnet.
Was ein Gateway leistet
Bisher war der Zugang eine 1:1-Verdrahtung: Ein Client, hier die Umgebung des Redakteurs, kennt einen Dienst und spricht ihn direkt an. Das funktioniert, solange es bei einem Client und einem Dienst bleibt. Ein Gateway schaltet stattdessen eine zentrale Stelle davor, vergleichbar mit einem Empfang. Alle Anfragen laufen dort auf, und dort wird geprüft, wer welche Werkzeuge nutzen darf. Dahinter können beliebig viele Dienste hängen, ohne dass jeder Client jeden einzeln kennen muss. Mit dem MCP-Werkzeug aus Teil 5 spricht bisher nur eine KI, das Gateway macht den Weg für weitere frei.
Warum LiteLLM? Der Wert im Überblick
Ursprünglich war eine eigene Umgebung nur für das Gateway vorgesehen. Der Gedanke: Fällt ein Dienst aus, soll er nicht die Verbindung zu den anderen mitreißen. Am Ende habe ich mich anders entschieden, weil LiteLLM mehrere Aufgaben an einer Stelle bündelt, die sonst einzeln zu bauen wären:
- Ein Zugang für Modelle und Werkzeuge: Über denselben zentralen Punkt laufen die Anfragen an Sprachmodelle verschiedener Anbieter und der Zugriff auf die Werkzeuge. Was hinter dem Modell steckt, lässt sich austauschen, ohne die Anbindung neu zu bauen.
- Zugriffsrechte an einer Stelle: Schlüssel und Teams bestimmen, welche KI welche Werkzeuge sieht. Ein neuer Client bekommt einen eigenen Schlüssel statt einer neuen Verdrahtung.
- Übersetzung der Werkzeugformate: Die Anbieter beschreiben Werkzeuge unterschiedlich, etwa Claudes "Tool Use" und OpenAIs "Function Calling". LiteLLM übersetzt automatisch, sodass dasselbe Werkzeug für verschiedene KIs funktioniert, ohne dass ich für jede eine eigene Anbindung baue.
- Ein Dienst weniger: Gateway und Modell-Router sind derselbe Dienst, es gibt weniger zu betreiben und zu pflegen.
Der Preis ist ein zentraler Punkt: Fällt LiteLLM aus, sind Routing und Werkzeugzugriff gleichzeitig weg. Das habe ich bewusst akzeptiert. Als Minimalabsicherung dienen vollständige Sicherungen aller drei Second-Brain-Container, damit sich ein funktionierender Stand jederzeit wiederherstellen lässt.
Der Aufbau
LiteLLM läuft in einer eigenen, schlanken Container-Umgebung mit einer eigenen Datenbank. Sie ist nötig, damit einmal registrierte Werkzeuge einen Neustart überleben. Dann folgten drei Schritte:
- Registrieren: Das VectorSearch-Werkzeug wurde als angeschlossener Dienst eingetragen. Der Gesundheitscheck meldete "healthy".
- Ein eigenes Team anlegen: Das Team darf gezielt auf genau diesen einen Dienst zugreifen und nicht pauschal auf alles, was das Gateway kennt.
- Einen eigenen Schlüssel erzeugen: Er gehört dem Team und erbt dessen Rechte.
Das Prinzip heißt Scoping, also Einschränkung auf einen Geltungsbereich. Der Schlüssel funktioniert wie ein Zimmerschlüssel, kein Generalschlüssel. Eine Einschränkung gibt es: LiteLLM steuert Rechte nur je Dienst, nicht je einzelnem Werkzeug. Da alle Werkzeuge hier ausschließlich lesen, spielt das keine Rolle. Bei künftigen Schreib-Werkzeugen wird es relevant.
Eine kleine Stolperfalle
Der naheliegende Name für den Dienst war homelab-knowledge, identisch zum Werkzeugnamen. Das Gateway lehnte ihn ab, denn Namen dürfen keine Bindestriche enthalten. Mit einem Unterstrich klappte die Registrierung sofort.
Das Ergebnis
Ein Test über den eingeschränkten Schlüssel zeigte das Werkzeug in der Liste und lieferte bei einem Aufruf echte, nach Relevanz sortierte Treffer aus dem Wiki. Das funktioniert unabhängig von der bestehenden Direktanbindung des Redakteurs, die ich bewusst unverändert gelassen habe. Sie bleibt als Rückfallweg erhalten. Schlüssel und Hauptschlüssel liegen ausschließlich auf dem Gateway-Dienst, nicht im Wiki.
Der eigentliche Hebel: das Regelwerk als Werkzeug
Der größere Nutzen liegt nicht bei der Suche allein. Als zweiten Dienst habe ich das Regelwerk des Second Brains hinter das Gateway gehängt: die fünf Rollen mit ihren Arbeitsanweisungen. Ein einziges Werkzeug liefert zu einer Rolle die vollständige Anweisung als Text zurück. Ein ausführbarer Ablauf wäre der falsche Zuschnitt gewesen. Die Rollen sind mehrstufige, urteilsbasierte Abläufe mit Freigabefragen an mich, keine einfachen Funktionen, und ein Werkzeug kann so etwas nicht selbst durchführen. Also übernimmt die aufrufende KI die Rolle in ihrer eigenen Sitzung mit ihren eigenen Werkzeugen. Der Zugriff ist lesend und auf den Ordner mit den Anweisungen begrenzt, nicht auf das ganze Wiki, und läuft über dieselbe Team-Beschränkung wie die Suche. Ein Test bestätigte, dass alle fünf Rollen korrekt ankommen, auch über das Gateway mit dem eingeschränkten Schlüssel.
Damit lässt sich eine KI direkt an das Regelwerk anschließen, statt dass jede Sitzung die Regeln neu erklärt bekommt oder aus verstreuten Dateien liest. Gedacht ist es vor allem für KIs, die keinen direkten Zugriff auf die Dateien des Wikis haben. Technisch kann jede angeschlossene KI dieselben Rollen und dieselbe Suche über denselben Zugang verwenden. Das ist ein Nebeneffekt des Aufbaus, kein eigenes Ziel. Wie schon im Beitrag zur Werkzeugunabhängigkeit beschrieben, steht die Arbeit am Second Brain im Vordergrund. Dass sich Werkzeuge austauschen lassen, ist ein willkommener Nebeneffekt und jetzt produktiv umgesetzt.
Grenzen der Glättung
Auch ein Gateway macht nicht alle KIs gleich. LiteLLM vereinheitlicht die Hülle, nicht das Verhalten dahinter. Funktionen wie tieferes Nachdenken oder das Zwischenspeichern langer Anweisungen arbeiten bei den Anbietern unterschiedlich. Eine Anweisung, die ein bestimmtes Modellverhalten voraussetzt, läuft daher nur mit dem passenden Anbieter. Für die Rollen bedeutet das: Sie sollten nicht von Sonderfunktionen eines einzelnen Modells abhängen. Außerdem stellt das Gateway nur sicher, dass ein Aufruf richtig ankommt, wenn er stattfindet. Dass eine KI ein verfügbares Werkzeug tatsächlich nutzt, statt eine Antwort zu erfinden, garantiert es nicht. Dafür gibt es eine Strategie, umgesetzt ist sie noch nicht.
Fazit
Aus der 1:1-Verdrahtung ist zum ersten Mal eine echte Facade geworden: eine zentrale Stelle, die Zugriffe prüft, statt jedem Schlüssel alles zu öffnen. Der Gewinn zeigt sich, sobald eine zweite KI oder ein weiteres Werkzeug dazukommt. Dann genügt eine Registrierung statt einer neuen Verdrahtung, und die KI arbeitet mit denselben Rollen und derselben Suche.
Ausblick
Nach zwei Umzügen und dem Gateway steht im nächsten Teil eine förmliche Entscheidung an: ob die Retrieval-Schicht nach den bisherigen Bewährungsproben produktiv bleibt. Direkt danach rücken zwei fertige, sehr beliebte Werkzeuge in den Blick, die als Alternative zum Eigenbau im Raum stehen.