Eigener KI-Agent im Selbstbau, Teil 2: Open WebUI anbinden und eigene RAG-Agenten bauen

Das ist Teil 2 der Serie Dein eigener KI-Agent im Selbstbau. In Teil 1 haben wir Hermes als Docker-Container mit OpenRouter ans Laufen gebracht und über Telegram aufs Handy geholt. Jetzt geben wir ihm eine richtige Weboberfläche im Browser und bauen darin abgeschottete Wissens-Agenten für einzelne Themen.

Dein Agent kann schon mehr, als du denkst

Bevor wir loslegen, lohnt ein kurzer Blick darauf, was dein Agent aus Teil 1 schon kann. Er lernt dazu und merkt sich, was dir wichtig ist, und er liest auch Dokumente, die du ihm schickst. Schick ihm in Telegram einfach ein PDF und frag, was drinsteht. Er lädt sich das passende Werkzeug eigenständig nach, liest die Datei und fasst sie dir zusammen. Sobald du die Werkzeug-Nutzung einmal dauerhaft erlaubt hast, läuft das von da an reibungslos.

Das läuft ohne jede zusätzliche Einrichtung und kommt schon nah an das, was sich viele von einem KI-Assistenten wünschen. Eine klare Grenze hat es trotzdem. Der Agent liest das Dokument im Moment und merkt sich die Kernpunkte, doch eine dauerhafte, durchsuchbare Wissensbasis aus vielen Dokumenten, auf die er in jedem Kanal zugreift, ist damit noch nicht gebaut. Diese Stufe heben wir uns für später in der Serie auf.

In diesem Teil geht es um etwas, das im Alltag mindestens so nützlich ist: abgeschottete Wissens-Agenten, die zuverlässig aus einem festen Satz Dokumente antworten, etwa ein Support-Bot zu deinem Produkt oder ein Projekt-Assistent zu einer Ausschreibung. Dafür ist Open WebUI mit seiner Wissensbasis gemacht. Diese Wissens-Agenten leben allerdings nur in der Weboberfläche und tauchen im Telegram-Chat nicht auf. Warum das so ist und wann sich welcher Typ lohnt, erkläre ich weiter unten.

Am Ende dieses Teils läuft Open WebUI im Browser, und du hast deinen ersten abgeschotteten Wissens-Agenten gebaut, der gezielt aus deinen Unterlagen antwortet. Den Aufbau machen wir so, dass später mehrere Nutzer sauber dazukommen, ohne dass du etwas umbaust. Rechne mit etwa einer Stunde.

Was am Ende läuft

Open WebUI spricht mit dem API-Server, den Hermes schon eingebaut hat. Den Weg zum Modell bei OpenRouter übernimmt weiterhin Hermes selbst. So bekommst du in der Weboberfläche denselben Agenten mit all seinen Werkzeugen, den du in Teil 1 gebaut hast, nur eben im Browser statt im Telegram-Chat. Darauf baust du dann deinen Wissens-Agenten, der gezielt aus einem festen Satz Dokumente antwortet.

Schritt 1: Den geteilten Schlüssel anlegen

Open WebUI und Hermes reden über einen gemeinsamen geheimen Schlüssel: Hermes’ API-Server (den wir in Schritt 2 einschalten) verlangt ihn, Open WebUI schickt ihn mit. Diesen Schlüssel gibt es noch nicht. In Teil 1 haben wir in ~/.hermes/.env nur OpenRouter und Telegram eingerichtet, einen API-Server gab es dort nicht. Wir erzeugen ihn also jetzt frisch und legen ihn genau einmal ab, und zwar dort, wo solche Stack-Geheimnisse hingehören: in eine .env neben der Compose, die wir nicht ins Git geben.

Leg sie im Projektordner ~/ki-heimserver an, den du in Teil 1 für die docker-compose.yml angelegt hast:

cd ~/ki-heimserver
echo "HERMES_API_KEY=$(openssl rand -hex 32)" > .env
chmod 600 .env
Kopieren

Zwei kleine Begleitdateien halten das sauber und sicher. Eine .gitignore, damit die echte .env nie aus Versehen im Git landet:

echo ".env" > .gitignore
Kopieren

Und eine .env.example, die ohne echte Werte dokumentiert, welche Variablen nötig sind (die darf ins Git):

cat > .env.example <<'EOF'
# Geteiltes Token für die Verbindung Hermes-API-Server <-> Open WebUI
# erzeugen mit: openssl rand -hex 32
HERMES_API_KEY=
EOF
Kopieren

Damit liegt das eine Geheimnis genau einmal in ~/ki-heimserver/.env, und die Compose im nächsten Schritt zieht es über ${HERMES_API_KEY}, ohne dass der Wert je im teilbaren YAML steht.

Schritt 2: API-Server aktivieren und Open WebUI hinzufügen

Jetzt erweiterst du die docker-compose.yml aus Teil 1. Der hermes-Dienst bekommt einen environment-Block, der den API-Server einschaltet, und Open WebUI kommt als zweiter Dienst dazu. Der Schlüssel steht in beiden nur als ${HERMES_API_KEY}, also nirgends im Klartext. Öffne ~/ki-heimserver/docker-compose.yml und ersetz den Inhalt durch das hier:

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    container_name: hermes
    restart: unless-stopped
    command: ["gateway", "run"]
    environment:
      - API_SERVER_ENABLED=true
      - API_SERVER_HOST=0.0.0.0
      - API_SERVER_PORT=8642
      - API_SERVER_KEY=${HERMES_API_KEY}
    volumes:
      - ~/.hermes:/opt/data

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OPENAI_API_BASE_URL=http://hermes:8642/v1
      - OPENAI_API_KEY=${HERMES_API_KEY}
      - ENABLE_OLLAMA_API=false
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - hermes

volumes:
  open-webui:
Kopieren

Kurz erklärt:

• API_SERVER_ENABLED / HOST / PORT schalten den eingebauten API-Server von Hermes ein. API_SERVER_HOST=0.0.0.0 ist der entscheidende Punkt: Standardmäßig lauscht der Server nur auf 127.0.0.1, also nur im Hermes-Container. Mit 0.0.0.0 ist er auch vom Open-WebUI-Container aus erreichbar. Diese drei sind nicht geheim und stehen deshalb als Klartext da.
• API_SERVER_KEY=${HERMES_API_KEY} (Hermes-Seite) und OPENAI_API_KEY=${HERMES_API_KEY} (Open-WebUI-Seite) ziehen denselben Schlüssel aus deiner .env. Hermes verlangt das Token, Open WebUI schickt es mit, beide bekommen es aus einer Quelle.
• OPENAI_API_BASE_URL=http://hermes:8642/v1 ist der Kern der Verbindung. Die zwei Container liegen im selben Compose-Netz und finden sich über den Servicenamen, der Hermes-Container heißt schlicht hermes. Das /v1 am Ende ist Pflicht, sonst findet Open WebUI kein Modell. (Die offizielle Hermes-Doku nutzt hier host.docker.internal, aber das gilt nur, wenn Hermes direkt am Host läuft. Bei uns läuft es als Container, deshalb der Servicename.)
• ENABLE_OLLAMA_API=false blendet das leere Ollama-Backend aus, das sonst die Modellauswahl zumüllt.
• Port 3000:8080 macht die Oberfläche im Browser erreichbar. Den API-Server-Port 8642 geben wir bewusst nicht nach außen frei, Open WebUI erreicht Hermes intern über das Compose-Netz.

Schritt 3: Hochfahren und verbinden

cd ~/ki-heimserver
docker compose up -d
docker compose logs -f open-webui
Kopieren

docker compose up -d startet Open WebUI und zieht den Hermes-Container neu hoch, weil er jetzt den neuen environment-Block hat. So kommt der API-Server gleich mit, ein extra Neustart ist nicht nötig. Wichtig ist nur, dass du den Befehl aus ~/ki-heimserver heraus startest, denn von dort liest Docker Compose die .env mit deinem HERMES_API_KEY.

Der erste Start dauert einen Moment: Open WebUI lädt beim allerersten Hochfahren ein Embedding-Modell von etwa 150 MB herunter, das braucht 15 bis 30 Sekunden. Warte, bis in den Logs Ruhe einkehrt und eine Zeile wie Uvicorn running on http://0.0.0.0:8080 steht, dann beendest du das Mitlesen mit Ctrl+C.

Prüf kurz, ob der API-Server in Hermes wirklich antwortet, am einfachsten direkt über seinen Health-Endpunkt:

docker compose exec hermes curl -s http://localhost:8642/health; echo
Kopieren

✅ Checkpoint: Du bekommst {"status": "ok", "platform": "hermes-agent"} zurück. Damit ist der Agent erreichbar und für Open WebUI ansprechbar.

Den laufenden Stack siehst du auch in Docker Desktop unter Containers: die Gruppe ki-heimserver mit hermes und open-webui, beide grün. An den Ports erkennst du unsere Aufteilung. open-webui hat den veröffentlichten Port 3000:8080, hermes dagegen gar keinen, der Agent ist also nur intern im Compose-Netz erreichbar. (Der neo4j darüber gehört zu einem anderen Projekt und ist für unser Setup nicht relevant.)

Schritt 4: Open WebUI im Browser, der erste Chat

Öffne http://localhost:3000 am Mac mini. Von einem anderen Gerät im selben Netz, etwa deinem Laptop, geht es über die lokale IP des Mac mini, also http://<ip-des-mac-mini>:3000.

Beim ersten Aufruf begrüßt dich Open WebUI mit einem Willkommensbildschirm. Klick auf Loslegen und leg dein Konto an. Der erste Account wird automatisch Administrator, vergib also bewusst dein eigenes. Die E-Mail ist dabei nur deine Login-Kennung, Open WebUI verschickt von sich aus keine Mails. Eine echte Adresse macht dich für spätere E-Mail-Funktionen zukunftssicher, für rein lokal reicht aber auch etwas wie admin@local. Danach landest du im Chat, und oben in der Modellauswahl taucht dein Agent auf, beim Standard-Profil heißt er hermes-agent.

Stell ihm ruhig eine Frage, die aktuelle Informationen braucht, zum Beispiel „Was waren die letzten Updates von Open WebUI?". Du siehst live, wie der Agent mitdenkt, im Web recherchiert und dann antwortet, oft mit erstaunlich frischen Daten. Es ist derselbe Agent wie in Telegram, nur mit mehr Platz und Verlauf. Seinen Werkzeugkasten (eigene Skills, dedizierte Websuche über SearXNG, Browser) bauen wir in einem späteren Teil weiter aus.

Taucht kein Modell auf? Gib Hermes nach dem Start kurz Zeit und lad die Seite neu. Bleibt es leer, liegt es fast immer am fehlenden /v1 in der URL oder an einem Schlüssel, der nicht übereinstimmt. Mehr dazu unten in den Fallstricken.

✅ Checkpoint: Du chattest im Browser mit deinem eigenen Agenten, und er nutzt Werkzeuge. Jetzt bauen wir darauf deinen ersten Wissens-Agenten.

Schritt 5: Eine Wissensbasis mit deinen Dokumenten

Öffne in Open WebUI links die Seitenleiste und geh auf Arbeitsbereich. Oben in der Leiste wechselst du auf Wissen und legst mit dem + einen neuen Wissensspeicher an.

Im Formular „Wissensspeicher erstellen" gibst du einen Namen (Feld Woran arbeiten Sie?) und eine kurze Beschreibung (Was möchten Sie erreichen?), zum Beispiel „Meine Projekte" oder „Angebote 2026". Die Sichtbarkeit steht schon auf Privat, also nur für dich. Damit hast du gleich die Grundlage für die getrennten Wissensräume später. Mit Wissen erstellen ist der Speicher angelegt.

Über das + rechts öffnest du das Menü mit allem, was hineinkommen kann: Dateien hochladen (PDF, Word, Markdown, Text, Tabellen), einen ganzen Ordner hochladen, einen Ordner synchronisieren, eine Webseite hinzufügen oder Textinhalt direkt einfügen. Besonders praktisch ist die Webseite: Open WebUI holt die Seite selbst und legt ihren Inhalt als Textdokument ab, du musst nichts herunterladen.

Für dieses Beispiel habe ich zwei Dinge eingebracht: ein eigenes Dokument (hier eine ServasBot-Referenz als PDF) und die Webseite servasbot.at. Open WebUI zerlegt beide, legt die Einbettungen an, also die durchsuchbare Form, und danach stehen beide als Wissensdokumente in der Sammlung.

Fallstrick: Das Anlegen der Einbettungen läuft im Hintergrund. Lädst du viele Dateien auf einmal hoch, rutscht schon mal eine durch. Bei größeren Mengen lieber in kleineren Schüben hochladen und warten, bis jedes Dokument fertig verarbeitet ist.

Schritt 6: Dein RAG-Agent, ein eigenes Modell mit Wissensbasis

Kurz vorweg, was so ein Modell in Open WebUI überhaupt ist. Gemeint ist eine gespeicherte Voreinstellung (ein Wrapper) auf einem Basismodell, die unter einem Namen ein Basismodell, einen System-Prompt, eine Wissensbasis und ein paar Werkzeuge bündelt. Ein zweites KI-Modell ist es also nicht. Im Dropdown sieht es aus wie ein eigenes Modell, dahinter läuft aber derselbe Agent. Deshalb hängen wir die Wissensbasis an ein eigenes Modell statt global ans Basismodell. Das ist eine bewusste Entscheidung für die spätere Mehrnutzer-Trennung, denn so laufen viele Wrapper auf demselben Agenten, jeder mit eigenem Wissen.

Im Arbeitsbereich wechselst du oben auf Modelle und legst mit dem + ein neues an. Dann füllst du aus:

• Modellname: ein sprechender Name, zum Beispiel „ServasBot-Test".
• Basismodell (Von): wähl hermes-agent, also den Agenten aus Teil 1.
• System-Prompt: deine Anweisung, etwa „Antworte knapp und direkt, stütz dich auf meinen Wissensspeicher und sag offen, wenn du etwas nicht weißt."
• Wissen: auf Wissensspeicher auswählen klicken und deinen Speicher (hier „Servasbot") zuweisen.

Weiter unten findest du Fähigkeiten, Standardfunktionen und Eingebaute Werkzeuge (Websuche, Code-Interpreter, Wissensspeicher und so weiter). Für den Anfang lässt du die Voreinstellungen. Mit Speichern & Erstellen ist dein eigenes Modell fertig. Über Zugriff oben steht es schon auf Privat, nur du siehst es, du musst hier also nichts umstellen. Zusammen mit dem ebenfalls privaten Wissensspeicher aus Schritt 5 ist genau das die Grundlage für getrennte Wissensräume.

Fertig ist dein erster abgeschotteter Wissens-Agent, ein RAG-Agent auf deinem festen Dokumentensatz. Ab jetzt zieht dieses Modell bei passenden Fragen automatisch aus deinen Dokumenten. Alternativ kannst du eine Wissensbasis im Chat auch spontan mit # referenzieren.

Schritt 7: Den Agenten ausprobieren

Zum Ausprobieren wählst du oben im Modell-Dropdown dein neues Modell Servasbot-Test aus. Daneben findest du in der Liste weiterhin den hermes-agent selbst, mit dem du jederzeit auch ohne Wissensbasis chatten kannst.

Nun stellst du eine Frage, deren Antwort in deinen Dokumenten steht. Der Agent holt sich die passende Stelle aus der Wissensbasis und formuliert seine Antwort daraus. Unter der Antwort erscheint ein Hinweis auf 1 Quelle, und die einzelnen Aussagen sind mit dem Quelldokument verlinkt, sodass du auf einen Blick erkennst, woher die Antwort stammt. Gerade diese Nachvollziehbarkeit macht einen solchen Agenten für Support und Beratung besonders wertvoll.

Wo dieses Wissen lebt, und wo nicht

Bevor du dich darauf verlässt, solltest du einen Punkt kennen. Die Wissensbasis und der Wissens-Agent, die du gerade gebaut hast, leben in Open WebUI, also in der Weboberfläche. Im Telegram-Chat mit demselben Agenten sind sie nicht da. Das ist bewusst so gebaut, denn dadurch entstehen gezielt abgeschottete Agenten für einzelne Themen oder Kunden, deren Wissen sauber getrennt bleibt und nur dort auftaucht, wo du es haben willst. Für Support- und Projekt-Agenten ist das ideal, etwa ein Bot, der ausschließlich aus dem Handbuch eines Produkts antwortet.

Es ist allerdings nicht das eine persönliche Gedächtnis, das dich überall begleitet. Dein Agent aus Teil 1 lernt und merkt sich Dinge schon in jedem Kanal, und ein Dokument, das du ihm schickst, liest er auch. Eine dauerhafte, durchsuchbare Wissensbasis aus vielen Dokumenten, die in Telegram genauso verfügbar ist wie im Web, bauen wir aber erst in einer späteren Stufe der Serie. Als Faustregel: Abgeschottetes Themen-Wissen, das verlässlich sitzt, baust du als Wissens-Agent im Web. Den persönlichen Alltagsassistenten nutzt du über Telegram und das Web, und er wächst über sein Gedächtnis mit.

Nebenbei hast du damit schon die Grundlage für mehrere Nutzer gelegt. Die Wissensbasis hängt an einem eigenen, privaten Modell statt global am Basismodell, also bekommt später einfach jede Person ihren eigenen Wissens-Agenten mit ihren eigenen Dokumenten. Und der Hermes-Container kann pro Person einen eigenen Agenten mit eigenem Gedächtnis führen, sogenannte Profile, alles im selben Container ohne Neuaufbau. Wie daraus eine saubere Trennung für Familie oder Firma wird, inklusive des Punkts, der über „taugt für die Firma" oder „wird peinlich" entscheidet, ist später ein eigenes Thema.

Häufige Fallstricke

Die Serie im Überblick

• Teil 1: Den Agenten als Docker-Container starten und per Telegram aufs Handy holen. Er lernt und merkt sich Dinge von Anfang an.
• Teil 2 (hier): Open WebUI als Oberfläche anbinden und abgeschottete RAG-Agenten für Support und Projekte bauen.

Was noch kommt (ungefähre Reihenfolge, kann sich noch ändern):

• Der Agent wird proaktiv: eigene Fähigkeiten, E-Mail und automatische Aufgaben wie ein Morgenbriefing.
• Mehrere Nutzer sauber getrennt, jede Person mit eigenem Wissensraum und eigenem Gedächtnis.
• Websuche, die du selbst hostest.
• Sprache: einfach reinsprechen statt tippen, der Agent versteht dich (und antwortet vielleicht auch gesprochen).
• Bilder vom Agenten generieren lassen.
• Eigene lokale Modelle, ganz ohne Cloud.
• Ein echtes Wissensgedächtnis: deine Dokumente dauerhaft und durchsuchbar, in jedem Kanal.
• Produktionsbetrieb: sicherer Fernzugriff per HTTPS, Datenbank und Backups.

Wenn du so ein Setup für deine Firma aufsetzen oder die Mehrbenutzer-Trennung sauber aufziehen willst, kannst du mich bei Fragen jederzeit kontaktieren.