KI-Systeme: Selbst gehostete Assistenten, RAG und lokale Infrastruktur

Inhaltsverzeichnis

Die meisten lokalen KI-Setups beginnen mit einem Modell und einer Laufzeitumgebung.

Sie laden ein quantisiertes Modell herunter, starten es über Ollama oder eine andere Laufzeitumgebung und beginnen mit der Prompt-Eingabe. Für Experimente ist das mehr als ausreichend. Doch sobald Sie über reine Neugier hinausgehen – sobald Ihnen Speicher, Abrufqualität, Routing-Entscheidungen oder Kostenbewusstsein wichtig werden –, zeigen sich die Grenzen dieser Einfachheit.

Dieser Cluster erforscht einen anderen Ansatz: Die Behandlung des KI-Assistenten nicht als einzelne Modellaufrufe, sondern als koordiniertes System.

Diese Unterscheidung mag auf den ersten Blick subtil erscheinen, aber sie verändert die Art und Weise, wie man über lokale KI denkt, grundlegend.

Orchestrierung von KI-Systemen mit lokalen LLMs, RAG und Memory-Schichten

Was ist ein KI-System?

Ein KI-System ist mehr als nur ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung zu etwas verbindet, das sich wie ein kohärenter Assistent verhält.

Das lokale Ausführen eines Modells ist Infrastrukturarbeit. Das Design eines Assistenten um dieses Modell herum ist Systemarbeit.

Wenn Sie unsere umfassenderen Leitfäden zu folgenden Themen erkundet haben:

Sie wissen bereits, dass Inferenz nur eine Schicht des Stacks ist.

Der KI-Systeme-Cluster baut auf diesen Schichten auf. Er ersetzt sie nicht – er kombiniert sie.

Für eine übergreifende Übersicht darüber, wie diese Schichten in Produktionsassistenten zusammenwirken – LLM, Speicher, Werkzeuge, Routing und Observierbarkeit, mit OpenClaw und Hermes als Referenzsystemen – sehen Sie Architektur von KI-Assistenten: LLM, Speicher, Werkzeuge, Routing, Observierbarkeit.

OpenClaw: Ein selbst gehostetes KI-Assistentensystem

OpenClaw ist ein quelloffener, selbst gehosteter KI-Assistent, der darauf ausgelegt ist, über Messaging-Plattformen hinweg zu operieren und dabei auf lokaler Infrastruktur zu laufen.

Auf praktischer Ebene:

  • Nutzt lokale LLM-Laufzeiten wie Ollama oder vLLM
  • Integriert den Abruf über indizierte Dokumente
  • Verwaltet Speicher jenseits einer einzelnen Sitzung
  • Führt Werkzeuge und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Operiert innerhalb von Hardwarebeschränkungen

Es ist nicht nur eine Hülle um ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und_execution zu etwas verbindet, das sich wie ein kohärenter Assistent verhält.

Einstieg und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeit – durch Hinzufügen von Memory-Backends, Modellprovidern, Kommunikationskanälen, Web-Tools und Observierbarkeit. Skills erweitern das Agentenverhalten – indem sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beides zu kombinieren, geformt nach den tatsächlichen Nutzern des Systems.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

Hermes Agent ist ein selbst gehosteter, modellagnostischer Assistent, der sich auf persistente Operationen konzentriert: Er kann als langlebiger Prozess laufen, Werkzeuge über konfigurierbare Backends ausführen und Workflows über Zeit durch Speicher und wiederverwendbare Skills verbessern.

Auf praktischer Ebene ist Hermes nützlich, wenn Sie wollen:

  • Einen terminalorientierten Assistenten, der auch in Messaging-Apps überbrücken kann
  • Provider-Flexibilität durch OpenAI-kompatible Endpunkte und Modellschaltung
  • Tool-Ausführungsgrenzen via lokaler und gesandwörterter Backends
  • Tages-zwei-Operationen mit Diagnosen, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen – jedes mit eigener Konfiguration, Secrets, Erinnerungen, Sessions, Skills und Status – wodurch Profile die echte Einheit der Produktionsverantwortung sind, nicht der einzelne Skill.

Persistente Kenntnisse und Speicher

Einige Probleme werden nicht allein durch ein größeres Kontextfenster gelöst – sie benötigen persistente Kenntnisse (Graphen, Ingestion-Pipelines) und Agenten-Speicher-Plugins (Honcho, Mem0, Hindsight und ähnliche Backends), die in Assistenten wie Hermes oder OpenClaw integriert sind.

MCP: Model Context Protocol Server

Das Model Context Protocol (MCP) ist ein offener Standard, der von Anthropic eingeführt wurde, um KI-Sprachmodelle mit externen Datenquellen, Werkzeugen und Systemen zu verbinden. Es löst das N×M-Integrationsproblem, indem es eine universelle Schnittstelle bereitstellt – denken Sie daran als USB-C-Anschluss für KI-Anwendungen. Das Erstellen von MCP-Servern ermöglicht es Ihnen, KI-Assistenten mit benutzerdefinierten Integrationen für Dateien, Datenbanken, APIs und aufrufbare Tools zu erweitern, wobei ein einfaches JSON-RPC-basiertes Protokoll über Stdio oder HTTP verwendet wird.

  • MCP-Server in Go – Protokollarchitektur, JSON-RPC-Nachrichtenstruktur, Fähigkeitsverhandlung, offizielles Go-SDK und ein Schritt-für-Schritt-Tutorial zum Erstellen von MCP-Servern in Go
  • Erstellen von MCP-Servern in Python – Praktischer Python-Implementierungsleitfaden, der Websuche und Scraping-MCP-Server, Stdio- und SSE-Transports sowie die Claude Desktop-Integration abdeckt

Was KI-Systeme unterscheidet

Mehrere Eigenschaften machen KI-Systeme näheres Untersuchen wert.

Modell-Routing als Designentscheidung

Die meisten lokalen Setups standardisieren auf ein Modell. KI-Systeme unterstützen die bewusste Auswahl von Modellen.

Das führt zu Fragen:

  • Sollten kleine Anfragen kleinere Modelle verwenden?
  • Wann rechtfertigt Reasoning ein größeres Kontextfenster?
  • Wie hoch ist der Kostendifferenz pro 1.000 Tokens?

Diese Fragen verbinden sich direkt mit den in dem LLM-Leistungsleitfaden diskutierten Leistungskompromissen und den in dem LLM-Hosting-Leitfaden umrissenen Infrastruktur-Entscheidungen.

KI-Systeme machen diese Entscheidungen sichtbar, anstatt sie zu verstecken.

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren Dokumentabruf, aber nicht als simplen “embedden und suchen”-Schritt.

Sie berücksichtigen:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybrid-Suche (BM25 + Vektor) kann reinem Dense-Retrieval überlegen sein
  • Reranking verbessert die Relevanz auf Kosten der Latenz
  • Indexierungsstrategie beeinflusst den Speicherverbrauch

Diese Themen stimmen mit den tieferen architektonischen Überlegungen überein, die in dem RAG-Tutorial diskutiert werden.

Der Unterschied besteht darin, dass KI-Systeme den Abruf in einen lebendigen Assistenten einbetten, anstatt ihn als isolierte Demo zu präsentieren.

Speicher als Infrastruktur

Stateless LLMs vergessen zwischen den Sessions alles.

KI-Systeme führen persistente Speicherschichten ein. Das wirft sofort Designfragen auf:

  • Was sollte langfristig gespeichert werden?
  • Wann sollte Kontext zusammengefasst werden?
  • Wie verhindert man Token-Explosion?
  • Wie indiziert man Speicher effizient?

Diese Fragen überschneiden sich direkt mit Datenebenen-Überlegungen aus dem Dateninfrastruktur-Leitfaden. Für Hermes Agent speziell – begrenzter 2-Datei-Speicher, Prefix-Caching, externe Plugins – beginnen Sie mit Hermes Agent Memory-System und dem Cross-Framework-Vergleich Agenten-Speicher-Provider im Vergleich. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Knowledge-Layer-Leitfäden auf.

Speicher hört auf, ein Feature zu sein, und wird zu einem Speicherproblem.

Observierbarkeit ist keine Option

Die meisten lokalen KI-Experimente hören bei “es antwortet” auf.

KI-Systeme ermöglichen es, zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardwareauslastung
  • Throughput-Muster

Dies verbindet sich natürlich mit den Überwachungsprinzipien, die in dem Observierbarkeit-Leitfaden beschrieben werden.

Wenn KI auf Hardware läuft, sollte sie messbar sein wie jede andere Arbeitslast.

Wie es sich anfühlt, sie zu nutzen

Von außen mag ein KI-System immer noch wie eine Chat-Schnittstelle aussehen.

Unter der Oberfläche passiert mehr.

Wenn Sie es bitten, einen lokal gespeicherten technischen Bericht zusammenzufassen:

  1. Es ruft relevante Dokumentsegmente ab.
  2. Es wählt ein geeignetes Modell aus.
  3. Es generiert eine Antwort.
  4. Es zeichnet Token-Nutzung und Latenz auf.
  5. Es aktualisiert den persistenten Speicher, falls erforderlich.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist geschichtet.

Dieses geschichtete Verhalten unterscheidet ein System von einer Demo.

Wo KI-Systeme im Stack passen

Der KI-Systeme-Cluster sitzt an der Schnittstelle mehrerer Infrastrukturschichten:

  • LLM-Hosting: Die Laufzeitschicht, in der Modelle ausgeführt werden (Ollama, vLLM, llama.cpp)
  • RAG: Die Abrufschicht, die Kontext und Grounding bereitstellt
  • Leistung: Die Messschicht, die Latenz und Throughput verfolgt
  • Observierbarkeit: Die Überwachungsschicht, die Metriken und Kostentracking bereitstellt
  • Dateninfrastruktur: Die Speicherschicht, die Speicher und Indizierung handhabt

Das Verständnis dieser Unterscheidung ist nützlich. Das selbst Ausführen macht den Unterschied klarer.

Für eine minimale lokale Installation mit OpenClaw sehen Sie den OpenClaw Quickstart-Leitfaden, der eine Docker-basierte Einrichtung unter Verwendung entweder eines lokalen Ollama-Modells oder einer cloud-basierten Claude-Konfiguration durchläuft.

Wenn Ihr Setup von Claude abhängt, klärt diese Richtliniänderung für Agenten-Tools auf, warum API-Abrechnung jetzt für dritte OpenClaw-Workflows erforderlich ist.

Verwandte Ressourcen

MCP-Server:

KI-Assistenten-Leitfäden:

Infrastrukturschichten:

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.