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 Sie die bloße Neugier überwinden — sobald Ihnen Speicherplatz, Abrufqualität, Routing-Entscheidungen oder Kostenbewusstsein wichtig werden — offenbart sich die Grenze dieser Einfachheit.

Dieses Cluster erkundet einen anderen Ansatz: die Behandlung des KI-Assistenten nicht als einzelne Modellaufrufe, sondern als koordiniertes System.

Diese Unterscheidung mag zunächst subtil wirken, verändert aber Ihre gesamte Denkweise über lokale KI.

KI-Systemorchestrierung mit lokalen LLMs, RAG und Speicherschichten

Was ist ein KI-System?

Ein KI-System ist mehr als ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung miteinander verbindet, um etwas zu bilden, das wie ein kohärenter Assistent funktioniert.

Ein Modell lokal auszuführen ist Infrastrukturarbeit. Die Gestaltung eines Assistenten um dieses Modell herum ist Systemarbeit.

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

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

Das Cluster „KI-Systeme" sitzt auf diesen Schichten auf. Es ersetzt sie nicht — es kombiniert sie.

Für eine übergreifende Übersicht, wie diese Schichten in produktionsreifen Assistenten zusammenpassen — LLM, Speicher, Werkzeuge, Routing und Beobachtbarkeit, mit OpenClaw und Hermes als Referenzsysteme — siehe KI-Assistenten-Architektur: LLM, Speicher, Werkzeuge, Routing, Beobachtbarkeit.

Sobald die Assistenten-Architektur solide ist, besteht der nächste Schritt darin, sie proaktiv zu gestalten. Polling-Agenten in KI-Assistenten: 11 Implementierungsmuster behandelt, wie Hintergrund-Polling-Worker, warteschlangenbasierte Ausführung, dauerhafte Workflows und semantische LLM-Evaluator einen reaktiven Assistenten in einen umwandeln, der auf eigene Initiative überwacht, entscheidet und handelt.

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

OpenClaw: Ein selbst gehostetes KI-Assistentensystem

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

Auf praktischer Ebene:

  • Verwendet lokale LLM-Laufzeitumgebungen wie Ollama oder vLLM
  • Integriert Abruf über indizierte Dokumente
  • Bewahrt Speicher über eine einzelne Sitzung hinaus
  • Führt Werkzeuge und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Operiert innerhalb von Hardwaregrenzen

Es ist nicht nur eine Hülle um ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung miteinander verbindet, um etwas zu bilden, das wie ein kohärenter Assistent funktioniert.

Einführung und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeitumgebung — durch Hinzufügen von Speicherbackends, Modellanbietern, Kommunikationskanälen, Web-Tools und Beobachtbarkeit. Skills erweitern das Agentenverhalten — indem sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beides zu kombinieren, geformt um die Person, die das System tatsächlich nutzt.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

Hermes Agent ist ein selbst gehosteter, modell-agnostischer Assistent, der sich auf persistente Operationen konzentriert: Er kann als lang lebender Prozess ausgeführt werden, Werkzeuge über konfigurierbare Backends ausführen und Workflows im Laufe der Zeit durch Speicher und wiederverwendbare Skills verbessern.

Auf praktischer Ebene ist Hermes nützlich, wenn Sie Folgendes möchten:

  • Ein Terminal-zuerst-Assistent, der auch in Messaging-Apps überbrücken kann
  • Anbieterflexibilität durch OpenAI-kompatible Endpunkte und Modellschaltung
  • Tool-Ausführungsgrenzen über lokale und sandbox-isierte Backends
  • Tages-zwei-Operationen mit Diagnosen, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen — jeweils mit eigener Konfiguration, Secrets, Speichern, Sitzungen, Skills und Status — was Profile zur eigentlichen Einheit der Produktionsverantwortung macht, nicht das individuelle 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 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 einen USB-C-Port für KI-Anwendungen. Der Aufbau von MCP-Servern ermöglicht es, KI-Assistenten mit benutzerdefinierten Integrationen für Dateien, Datenbanken, APIs und aufrufbare Werkzeuge zu erweitern, wobei ein einfaches JSON-RPC-basiertes Protokoll über stdio oder HTTP verwendet wird.

  • 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 — Protokollarchitektur, JSON-RPC-Nachrichtenstruktur, Funktionsverhandlung, offizielles Go-SDK und ein schrittweiser Tutorial für den Bau von MCP-Servern in Go
  • Bau von MCP-Servern in Python — praktischer Python-Implementierungsleitfaden, der Web-Suche und Scraping MCP-Server, stdio- und SSE-Transports sowie Claude-Desktop-Integration abdeckt

A2A: Agent-to-Agent-Protokoll

Das Agent2Agent-Protokoll (A2A) ist ein offener Standard für die Kommunikation zwischen unabhängig部署ierten KI-Agentensystemen. Während MCP einen Agenten mit Werkzeugen verbindet, verbindet A2A Agenten mit anderen Agenten — was es ihnen ermöglicht, sich gegenseitig ü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 besessen werden, mit verschiedenen Frameworks gebaut werden oder als separate Dienste deployed sind, die interoperieren müssen.

Was KI-Systeme unterscheidet

Mehrere Eigenschaften machen es wert, KI-Systeme genauer zu betrachten.

Modell-Routing als Designentscheidung

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

Daraus ergeben sich Fragen:

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

Diese Fragen sind direkt mit den Leistungs-Trade-offs verbunden, die im Leitfaden zur LLM-Leistung besprochen werden, und mit den Infrastruktur-Entscheidungen, die im Leitfaden zum LLM-Hosting dargelegt sind.

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

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren Dokumentabruf, aber nicht als einen simplen „embed and search"-Schritt.

Sie erkennen an:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybride Suche (BM25 + Vektor) kann reine dichte Abruf schlagen
  • Reranking verbessert Relevanz auf Kosten der Latenz
  • Indexierungsstrategie beeinflusst Speicherverbrauch

Diese Themen stimmen mit den tieferen Architektur-Überlegungen überein, die im RAG-Tutorial besprochen werden.

Der Unterschied ist, dass KI-Systeme Abruf in einen lebendigen Assistenten einbetten, anstatt ihn als isoliertes 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 indexiert man Speicher effizient?

Diese Fragen schneiden sich direkt mit den Daten-Schicht-Überlegungen aus dem Leitfaden zur Dateninfrastruktur. Für Hermes Agent speziell — begrenzter zwei-Datei-Speicher, Prefix-Caching, externe Plugins — beginnen Sie mit Hermes Agent Speichersystem und dem cross-Framework-Vergleich Vergleich der Agenten-Speicheranbieter. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Wissensschicht-Leitfäden auf.

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

Beobachtbarkeit ist nicht optional

Die meisten lokalen KI-Experimente stoppen bei „es reagiert".

KI-Systeme machen es möglich zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardware-Auslastung
  • Durchsatzmuster

Dies verbindet sich natürlich mit den Überwachungsprinzipien, die im Leitfaden zur Beobachtbarkeit beschrieben sind.

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

Wie es sich anfühlt, ein KI-System zu verwenden

Von außen kann 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.
  3. Es generiert eine Antwort.
  4. Es protokolliert Token-Nutzung und Latenz.
  5. Es aktualisiert den persistenten Speicher, wenn notwendig.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist schichtig.

Dieses schichtige Verhalten ist es, was ein System von einem Demo unterscheidet.

Wo KI-Systeme im Stack einzuordnen sind

Das Cluster „KI-Systeme" sitzt an der Kreuzung 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
  • Beobachtbarkeit: Die Überwachungsschicht, die Metriken und Kostenverfolgung bereitstellt
  • Dateninfrastruktur: Die Speicherschicht, die Speicher und Indexierung behandelt

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

Für eine minimale lokale Installation mit OpenClaw, siehe den OpenClaw Quickstart-Leitfaden, der durch ein Docker-basiertes Setup führt, das entweder ein lokales Ollama-Modell oder eine cloudbasierte Claude-Konfiguration verwendet.

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

Verwandte Ressourcen

A2A: Agent-to-Agent-Protokoll:

MCP-Server:

KI-Assistenten-Leitfäden:

Infrastrukturschichten:

Abonnieren

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