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 dem Prompting. Für Experimente ist das mehr als ausreichend. Aber sobald Sie über reine Neugier hinausgehen – sobald Ihnen Speicher, Abrufqualität, Routing-Entscheidungen oder Kostenbewusstsein wichtig sind –, zeigen sich die Grenzen dieser Einfachheit.

Dieser Cluster erkundet einen anderen Ansatz: den KI-Assistenten nicht als einzelne Modellaufrufe zu behandeln, sondern als koordiniertes System.

Diese Unterscheidung mag anfangs subtil erscheinen, sie verändert jedoch grundlegend, wie man über lokale KI denkt.

KI-System-Orchestrierung mit lokalen LLMs, RAG und Speicherschichten

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 verbindet, um etwas zu schaffen, das sich wie ein kohärenter Assistent verhält.

Ein Modell lokal auszuführen ist Infrastrukturarbeit. Einen Assistenten um dieses Modell herum zu gestalten, ist Systemarbeit.

Wenn Sie unsere umfassenderen Guides zu folgenden Themen erkundet haben:

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

Der KI-System-Cluster sitzt auf diesen Schichten. Er ersetzt sie nicht – er kombiniert sie.

Für eine querliegende Übersicht, wie diese Schichten in produktionsreifen Assistenten zusammenwirken – LLM, Speicher, Tools, Routing und Observability, mit OpenClaw und Hermes als Referenzsystemen –, sehen Sie KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Observability.

Sobald die Architektur des Assistenten solide ist, besteht der nächste Schritt darin, ihn proaktiv zu machen. Polling-Agenten in KI-Assistenten: 11 Implementierungsmuster beschreibt, wie Hintergrund-Polling-Worker, wettenschlangenbasierte Ausführung, dauerhafte Workflows und semantische LLM-Evaluatoren einen reaktiven Assistenten in einen verwandeln, der selbstständig überwacht, entscheidet und handelt.

Wenn ein einzelner Assistent nicht ausreicht und mehrere Agenten koordinieren müssen, bestimmt die Wahl des Koordinationsmusters alles: Latenz, Fehlertoleranz, Kosten und Debuggbarkeit. Multi-Agent-Orchestrierungsmuster: Ein praktischer Leitfaden behandelt die sechs kanonischen Muster – Orchestrator-Worker, sequenzielle Pipeline, Fan-out, hierarchisch, Schwarm und Mesh – mit spezifischen Ausfallmodi und einem Entscheidungsrahmen für die richtige Architektur.

OpenClaw: Ein selbstgehostetes KI-Assistenten-System

OpenClaw ist ein Open-Source, selbstgehosteter KI-Assistent, der entwickelt wurde, um über Messaging-Plattformen hinweg zu arbeiten, während er auf lokaler Infrastruktur läuft.

Auf praktischer Ebene:

  • Nutzt lokale LLM-Laufzeitumgebungen wie Ollama oder vLLM
  • Integriert den Abruf über indizierte Dokumente
  • Pflegt Speicher über eine einzelne Sitzung hinaus
  • Führt Tools 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 Ausführung verbindet, um etwas zu schaffen, das sich wie ein kohärenter Assistent verhält.

Einstieg und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeitumgebung – sie fügen Speicher-Backends, Modellprovider, Kommunikationskanäle, Web-Tools und Observability hinzu. Skills erweitern das Agentenverhalten – sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beide zu kombinieren, geformt um die Personen, die das System tatsächlich verwenden.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

Hermes Agent ist ein selbstgehosteter, modellagnostischer Assistent, der auf persistenter Operation fokussiert ist: Er kann als langlebiger Prozess laufen, Tools über konfigurierbare Backends ausführen und Workflows über Zeit durch Speicher und wiederverwendbare Skills verbessern.

Auf praktischer Ebene ist Hermes nützlich, wenn Sie folgendes wünschen:

  • Einen terminalbasierten Assistenten, der auch in Messaging-Apps integrierbar ist
  • Provider-Flexibilität durch OpenAI-kompatible Endpunkte und Modellwechsel
  • Tool-Ausführungsgrenzen via lokalen und sandboxierten Backends
  • Day-Two-Operationen mit Diagnosen, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen – jedes mit eigener Konfiguration, Secrets, Speichern, Sitzungen, Skills und Status –, was Profile zur echten Einheit der Produktionsverantwortung macht, nicht den einzelnen 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 eingebunden 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, Tools 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, unter Verwendung eines einfachen JSON-RPC-basierten Protokolls über stdio oder HTTP.

  • 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
  • MCP-Server in Python erstellen – praktischer Python-Implementierungsleitfaden, der Websuche und Scraping-MCP-Server, stdio- und SSE-Transporte sowie Claude Desktop-Integration abdeckt

A2A: Agent-to-Agent Protocol

Das Agent2Agent Protocol (A2A) ist ein offener Standard für die Kommunikation zwischen unabhängig deployeden KI-Agenten-Systemen. Während MCP einen Agenten mit Tools verbindet, verbindet A2A Agenten mit anderen Agenten – was es ihnen ermöglicht, sich über Agent Cards zu entdecken, Aufgaben und Nachrichten auszutauschen, Fortschritt zu streamen und typisierte Artefakte zurückzugeben. A2A ist für Systeme konzipiert, in denen Agenten von verschiedenen Teams geführt werden, mit verschiedenen Frameworks gebaut oder als separate Services deployed werden, die interoperabel sein müssen.

Was KI-Systeme unterscheidet

Mehrere Charakteristiken 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?
  • Was ist der Kostenunterschied pro 1.000 Token?

Diese Fragen verbinden sich direkt mit den Leistungszielkonflikten, die in dem LLM-Leistungsleitfaden diskutiert werden, und den Infrastruktur-Entscheidungen, die in dem LLM-Hosting-Leitfaden umrissen sind.

KI-Systeme bringen diese Entscheidungen an die Oberfläche, anstatt sie zu verstecken.

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren Dokumentabruf, aber nicht als simplen “embed and search”-Schritt.

Sie erkennen an:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybrid Search (BM25 + Vektor) kann reinen Dense Retrieval übertreffen
  • Reranking verbessert Relevanz auf Kosten der Latenz
  • Indexierungsstrategie beeinfligt Speicherverbrauch

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

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

Speicher als Infrastruktur

Stateless LLMs vergessen alles zwischen Sitzungen.

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 Datenlayer-Überlegungen aus dem Dateninfrastruktur-Leitfaden. Für Hermes Agent spezifisch – begrenzter zwei-Datei-Speicher, Prefix-Caching, externe Plugins – beginnen Sie mit Hermes Agent Speichersystem und dem Cross-Framework-Vergleich Agenten-Speicher-Provider im Vergleich. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Knowledge-Layer-Leitfäden.

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

Observability ist keine Option

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

KI-Systeme machen es möglich zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardwareauslastung
  • Durchsatzmuster

Dies verbindet sich natürlich mit den Monitoring-Prinzipien, die in dem Observability-Leitfaden beschrieben sind.

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

Wie es sich anfühlt, sie zu verwenden

Von außen mag ein KI-System immer noch nach einer 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 persistenten Speicher, falls nötig.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist geschichtet.

Dieses geschichtete Verhalten ist es, was ein System von einer Demo unterscheidet.

Wo KI-Systeme im Stack passen

Der KI-System-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 Durchsatz verfolgt
  • Observability: Die Monitoring-Schicht, die Metriken und Kostentracking bereitstellt
  • Dateninfrastruktur: Die Speicherschicht, die Speicher und Indizierung handhabt

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

Für eine minimale lokale Installation mit OpenClaw sehen Sie den OpenClaw Schnellstart-Leitfaden, der eine Docker-basierte Einrichtung unter Verwendung eines lokalen Ollama-Modells oder einer cloudbasierten Claude-Konfiguration durchgeht.

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

Verwandte Ressourcen

A2A: Agent-to-Agent Protocol:

MCP-Server:

KI-Assistenten-Leitfäden:

Infrastrukturschichten:

Abonnieren

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