KI-Systeme: Self-Hosted 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 man über die reine Neugier hinausgeht – sobald einem Speicherplatz, Abfragequalität, Routing-Entscheidungen oder Kostenbewusstsein wichtig sind – beginnt die Einfachheit, ihre Grenzen zu zeigen.

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

Diese Unterscheidung mag zunächst subtil erscheinen, aber sie verändert, wie man über lokale KI denkt, grundlegend.

KI-System-Orchestrierung mit lokalen LLMs, RAG und Speicher-Ebenen

Was ist ein KI-System?

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

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

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

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

Der KI-Systeme-Cluster befindet sich oberhalb dieser Ebenen. Er ersetzt sie nicht – er kombiniert sie.

Für einen querschnittsübergreifenden Plan, wie diese Ebenen in produktiven Assistenten zusammenpassen — LLM, Speicher, Tooling, Routing und Observability, mit OpenClaw und Hermes als Referenzsysteme — siehe KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Observability.

Sobald die Assistenten-Architektur solide ist, besteht der nächste Schritt darin, sie proaktiv zu machen. Polling-Agenten in KI-Assistenten: 11 Implementierungsmuster deckt ab, wie Hintergrund-Polling-Worker, warteschlangenbasierte Ausführung, dauerhafte Workflows und semantische LLM-Bewerter einen reaktiven Assistenten in einen verwandeln, der selbstständig beobachtet, entscheidet und handelt.

Wenn ein einzelner Assistent nicht ausreicht und mehrere Agenten koordiniert werden müssen, bestimmt die Wahl des Koordinierungsmusters alles: Latenz, Fehlertoleranz, Kosten und Debuggbarkeit. Multi-Agent-Orchestrierungsmuster: Ein praktischer Leitfaden behandelt die sechs kanonischen Muster — Orchestrator-Worker, sequentielle Pipeline, Fan-out, hierarchisch, Schwarm und Mesh — mit spezifischen Fehlerszenarien und einem Entscheidungsrahmen für die Wahl der richtigen Architektur.

OpenClaw: Ein selbst gehostetes KI-Assistenten-System

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

In praktischer Hinsicht:

  • Nutzt lokale LLM-Laufzeitumgebungen wie Ollama oder vLLM
  • Integriert den Abruf über indizierte Dokumente
  • Wartet Speicher über eine einzelne Sitzung hinaus
  • Führt Tools und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Operiert innerhalb von Hardware-Grenzen

Es ist nicht nur eine Hülle um ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung in 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-Laufzeitumgebung — durch Hinzufügen von Speicher-Backends, Modell-Anbietern, Kommunikationskanälen, Web-Tools und Observability. Skills erweitern das Agenten-Verhalten — sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beides zu kombinieren, geformt um diejenigen, die das System tatsächlich nutzen.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

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

In praktischer Hinsicht ist Hermes nützlich, wenn Sie Folgendes wünschen:

  • Einen terminalbasierten Assistenten, der auch in Messaging-Apps überbrücken kann
  • Anbieterflexibilität durch OpenAI-kompatible Endpunkte und Modellwechsel
  • Tool-Ausführungsgrenzen über lokale und sandboxed Backends
  • Tag-zwei-Operationen mit Diagnosen, Logs und Konfigurations-Hygiene

Hermes-Profile sind vollständig isolierte Umgebungen — jeweils mit eigener Konfiguration, Secrets, Speichern, Sitzungen, Skills und Zuständen — was Profile zur echten Einheit der Produktionsverantwortung macht, nicht die einzelne Skill.

Persistentes Wissen und Speicher

Manche Probleme werden nicht allein durch ein größeres Kontextfenster gelöst — sie benötigen persistentes Wissen (Graphen, Ingestion-Pipelines) und Agenten-Speicher-Plugins (Honcho, Mem0, Hindsight und ähnliche Backends), die in Assistenten wie Hermes oder OpenClaw eingebunden werden.

MCP: Model Context Protocol Server

Das Model Context Protocol (MCP) ist ein offener Standard, eingeführt von Anthropic, 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 wie einen USB-C-Port für KI-Anwendungen. Das Erstellen von MCP-Servern ermöglicht es, 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.

  • Agent Skills vs MCP Server: Entscheidungsrahmen — praktischer Entscheidungsrahmen dafür, wann man Skills verwendet, wann man MCP-Server baut und wie das Thin-Server-Muster beides kombiniert
  • MCP Server in Go — Protokoll-Architektur, JSON-RPC-Nachrichtenstruktur, Fähigkeitennegotiation, offizielles Go-SDK und ein Schritt-für-Schritt-Tutorial zum Bau von MCP-Servern in Go
  • MCP Server in Python bauen — praktischer Python-Implementierungsleitfaden, der Websuche- und Scraping-MCP-Server, stdio- und SSE-Transports und Claude-Desktop-Integration abdeckt

A2A: Agent-to-Agent Protocol

Das Agent2Agent-Protokoll (A2A) ist ein offener Standard für die Kommunikation zwischen unabhängig deployed KI-Agentensystemen. Während MCP einen Agenten mit Tools verbindet, verbindet A2A Agenten mit anderen Agenten — indem sie sich gegenseitig via Agent Cards entdecken, Aufgaben und Nachrichten austauschen, Fortschritt streamen und typisierte Artefakte zurückgeben. A2A ist für Systeme konzipiert, in denen Agenten von verschiedenen Teams besessen sind, mit verschiedenen Frameworks gebaut wurden oder als separate Dienste deployed sind, die interoperabel sein müssen.

Was KI-Systeme unterscheidet

Mehrere Eigenschaften machen KI-Systeme eine genauere Untersuchung wert.

Modell-Routing als Designentscheidung

Die meisten lokalen Setups verwenden standardmäßig ein Modell. KI-Systeme unterstützen die bewusste Auswahl von Modellen.

Daraus ergeben sich Fragen:

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

Diese Fragen verbinden sich direkt mit den Leistungs-Trade-offs, die in dem LLM-Leistungsleitfaden diskutiert werden, und den Infrastruktur-Entscheidungen, die in dem LLM-Hosting-Leitfaden skizziert 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 „einbetten und suchen“-Schritt.

Sie erkennen an:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybrid-Suche (BM25 + Vektor) kann reine dichte Retrieval übertreffen
  • Reranking verbessert Relevanz auf Kosten der Latenz
  • Indizierungsstrategie beeinflusst Speicherbedarf

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

Der Unterschied ist, dass KI-Systeme 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 Speicherebenen 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 schneiden sich direkt mit den Datenlayers-Überlegungen aus dem Daten-Infrastruktur-Leitfaden. Für Hermes Agent speziell — begrenzter 2-Datei-Speicher, Prefix-Caching, externe Plugins — beginnen Sie mit Hermes Agent Memory-System und dem frameworkübergreifenden Vergleich Agenten-Speicher-Provider im Vergleich. Automatische Erfassung und Reflexion können auch die eigene Inferenz eines Modells in zukünftige „Beweise“ verwandeln — siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten für das Fehlerszenario und Mnemosyne für Hermes Agent für eine konservative, lokale Implementierung. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Wissenslayer-Leitfäden.

Speicher hört auf, eine Funktion zu sein, und wird zu einem Speicherproblem.

Observability ist nicht optional

Die meisten lokalen KI-Experimente enden bei „es antwortet“.

KI-Systeme machen es möglich zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardware-Auslastung
  • Durchsatz-Muster

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

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

Wie sich die Nutzung anfühlt

Von außen mag ein KI-System immer noch wie eine Chat-Oberfläche 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.
  3. Es generiert eine Antwort.
  4. Es protokolliert Token-Nutzung und Latenz.
  5. Es aktualisiert persistenten Speicher, falls erforderlich.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist geschichtet.

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

Wo KI-Systeme im Stack einordnen

Der KI-Systeme-Cluster befindet sich an der Schnittstelle mehrerer Infrastrukturschichten:

  • LLM-Hosting: Die Laufzeitschicht, in der Modelle ausgeführt werden (Ollama, vLLM, llama.cpp)
  • RAG: Die Abfrageschicht, die Kontext und Grundierung bereitstellt
  • Leistung: Die Messschicht, die Latenz und Durchsatz verfolgt
  • Observability: Die Überwachungsschicht, die Metriken und Kostenerfassung bereitstellt
  • Daten-Infrastruktur: Die Speicherschicht, die Speicher und Indizierung behandelt

Das Verständnis dieser Unterscheidung ist nützlich. Es selbst auszuführen macht den Unterschied deutlicher.

Für eine minimale lokale Installation mit OpenClaw siehe den OpenClaw Quickstart-Leitfaden, der eine Docker-basierte Einrichtung mit entweder einem lokalen Ollama-Modell oder einer cloud-basierten Claude-Konfiguration durchläuft.

Wenn Ihr Setup von Claude abhängt, diese Richtänderung für Agent-Tools klärt, warum API-Abrechnung jetzt für OpenClaw-Workflows von Drittanbietern 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.