KI-Systeme: Self-Hosted-Assistenten, RAG und lokale Infrastruktur

Inhaltsverzeichnis

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

Sie laden ein quantisiertes Modell herunter, starten es über Ollama oder eine andere Runtime und beginnen mit dem Prompting. Für Experimente ist das mehr als ausreichend. Sobald Sie jedoch über reines Interesse hinausgehen – sobald Ihnen Speicher, Abfragequalität, Routing-Entscheidungen oder Kostensensibilität wichtig werden – zeigt die Einfachheit ihre Grenzen.

Diese Gruppe erkundet einen anderen Ansatz: den KI-Assistenten nicht als einzelne Modellaufruf, sondern als ein koordiniertes System zu betrachten.

Diese Unterscheidung mag zunächst dezent wirken, aber sie verändert Ihre Sichtweise auf lokale KI vollständig.

KI-System-Orchestrierung mit lokalen LLMs, RAG und Memory-Layern

Was ist ein KI-System?

Ein KI-System ist mehr als ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abfrage, Speicher und Ausführung zu 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 gestalten, ist Systemarbeit.

Wenn Sie unsere umfassenderen Guides erkundet haben zu:

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

Die KI-Systeme-Gruppe sitzt auf diesen Schichten. Sie ersetzt sie nicht – sie kombiniert sie.

Für eine übergreifende Karte, wie diese Schichten in produktionsreifen Assistenten zusammenpassen – LLM, Speicher, Tooling, Routing und Beobachtbarkeit, mit OpenClaw und Hermes als Referenzsystemen – siehe KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Beobachtbarkeit.

Sobald die Assistenten-Architektur solide ist, ist der nächste Schritt, sie proaktiv zu machen. Abfrage-Agenten in KI-Assistenten: 11 Implementierungsmuster behandelt, wie Hintergrund-Abfrage-Worker, warteschlangenbasierte Ausführung, dauerhafte Workflows und semantische LLM-Evaluator einen reaktiven Assistenten in einen verwandeln, der eigenständig beobachtet, entscheidet und handelt.

Wenn ein einzelner Assistent nicht ausreicht und mehrere Agenten koordinieren müssen, bestimmt die Wahl des Koordinierungsmusters alles: Latenz, Fehlertoleranz, Kosten und Debuggbarkeit. Multi-Agent-Orchestrierungsmuster: Ein praktischer Leitfaden deckt die sechs kanonischen Muster ab – Orchestrator-Worker, sequentielle Pipeline, Fan-out, hierarchisch, Swarm und Mesh – mit spezifischen Fehlermodi und einem Entscheidungsfähigkeit, um die richtige Architektur auszuwählen.

Bevor man mehr Autonomie hinzufügt, ist es sinnvoll zu fragen, welche Entscheidungen die Agenten überhaupt treffen dürfen. Entscheidungs-LLMs: Wann ein Modell entscheiden sollte – und wann nicht trennt die Urteilsfähigkeit des Modells von der Autorität des Systems: fünf Entscheidungsrollen, Routing jeder Entscheidung zur kleinsten kompetenten Stufe und die Entscheidungs-Speicher, Invarianten und Blast-Radius-Gates, die eine Modellsentscheidung nachträglich prüfbar machen.

OpenClaw: Ein selbst gehostetes KI-Assistenten-System

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

Auf praktischer Ebene:

  • Verwendet lokale LLM-Runtimes wie Ollama oder vLLM
  • Integriert Abfragen über indizierte Dokumente
  • Erhält Speicher über eine einzelne Sitzung hinaus
  • Führt Tools und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Operiert innerhalb von Hardware-Beschränkungen

Es ist nicht nur ein Wrapper um ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abfrage, Speicher und Ausführung zu etwas verbindet, das sich wie ein kohärenter Assistent verhält.

Erste Schritte und Architektur:

Kontext und Analyse:

Erweitern und Konfigurieren von OpenClaw:

Plugins erweitern die OpenClaw-Runtime – durch Hinzufügen von Speicher-Backends, Modell-Providern, Kommunikationskanälen, Web-Tools und Beobachtbarkeit. Skills erweitern das Agentenverhalten – indem sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beide zu kombinieren, geformt um diejenigen, die das System tatsächlich nutzen.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

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

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

  • Einen Terminal-First-Assistenten, der auch in Messaging-Apps überbrücken kann
  • Provider-Flexibilität durch OpenAI-kompatible Endpunkte und Modellwechsel
  • Tool-Ausführungsgrenzen über lokale und sandboxierte Backends
  • Day-two-Operationen mit Diagnosen, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen – jeweils mit ihrer eigenen Konfiguration, Secrets, Speichern, Sitzungen, Skills und Zuständen – was Profile zur eigentlichen Einheit der Produktionsverantwortlichkeit macht, nicht den einzelnen Skill.

Persistentes Wissen und Speicher

Einige Probleme werden nicht allein durch ein größeres Kontextfenster gelöst – sie brauchen persistentes Wissen (Graphen, Ingestions-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 – stellen Sie es sich wie einen USB-C-Port für KI-Anwendungen vor. Der Aufbau 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.

  • Agent Skills vs. MCP Server: Entscheidungsfähigkeit — praktische Entscheidungsfähigkeit dafür, wann man Skills verwendet, wann man MCP-Server baut und wie das Thin-Server-Muster beide kombiniert
  • MCP Server in Go — Protokollarchitektur, JSON-RPC-Nachrichtenstruktur, Fähigkeitsverhandlung, offizielles Go-SDK und ein Tutorial Schritt für Schritt zum Bau von MCP-Servern in Go
  • Aufbau von MCP-Servern in Python — praktischer Python-Implementierungsleitfaden, der Web-Suche und Scraping MCP-Server, stdio- und SSE-Transports und Claude-Desktop-Integration abdeckt

A2A: Agent-to-Agent Protocol

Das Agent2Agent Protocol (A2A) ist ein offener Standard für die Kommunikation zwischen unabhängig deployed KI-Agenten-Systemen. Während MCP einen Agent mit Tools verbindet, verbindet A2A Agenten mit anderen Agenten – und lässt sie sich gegenseitig über 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 werden, mit verschiedenen Frameworks gebaut werden oder als separate Dienste deployed werden, die miteinander interoperieren müssen.

Was KI-Systeme unterscheidet

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

Modell-Routing als Designentscheidung

Die meisten lokalen Setups standardmäßig 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 groß ist der Kostenunterschied pro 1.000 Tokens?

Diese Fragen hängen direkt mit den Leistungstradeoffs zusammen, die in dem LLM-Leistungsleitfaden diskutiert werden, und mit den Infrastruktur-Entscheidungen, die in dem LLM-Hosting-Leitfaden umrissen sind.

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

Abfrage wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren Dokument-Abfrage, aber nicht als schlichten „Embed und such“-Schritt.

Sie erkennen an:

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

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

Der Unterschied ist, dass KI-Systeme Abfrage in einen lebenden Assistenten einbetten, anstatt sie als isolierte Demo darzustellen. Deep Research nimmt diese Idee am weitesten: anstatt eines Abfragedurchlaufs plant das System, verzweigt, prüft nach und iteriert, bis die Beweise ausreichen. Selbst gehostete Deep-Research-Systeme: 12 Tools im Vergleich geht durch zwölf selbst gehostete Systeme – rekursive Forschungsbäume, Planner-plus-Subagent-Designs und Evidence-Gap-Schleifen – und wie jedes Abfrage in einen adaptiven Forschungsschleife verwandelt.

Speicher als Infrastruktur

Stateless-LLMs vergessen alles zwischen den Sitzungen.

KI-Systeme führen persistente Speicher-Ebenen 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 kreuzen sich direkt mit den Daten-Schicht-Überlegungen aus dem Daten-Infrastruktur-Leitfaden. 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 von Agenten-Speicher-Providern. Automatische Erfassung und Reflexion können auch die eigene Inferenz eines Modells in zukünftigen „Beweis“ verwandeln – siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten für den Fehlermodus und Mnemosyne für Hermes Agent für eine konservative, lokale Implementierung. Der KI-Systeme-Speicher-Hub listet verwandte Cognee- und Wissen-Schicht-Leitfäden.

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

Beobachtbarkeit ist nicht optional

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

KI-Systeme machen es möglich zu beobachten:

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

Dies verbindet sich natürlich mit den Überwachungsprinzipien, die in dem Beobachtbarkeitsleitfaden beschrieben sind.

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

Wie es sich anfühlt, es zu nutzen

Von außen kann 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 zeichnet Token-Nutzung und Latenz auf.
  5. Es aktualisiert persistenten Speicher, wenn nötig.

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 einpassen

Die KI-Systeme-Gruppe sitzt an der Schnittstelle mehrerer Infrastruktur-Ebenen:

  • LLM-Hosting: Die Runtime-Ebene, in der Modelle ausgeführt werden (Ollama, vLLM, llama.cpp)
  • RAG: Die Abfrage-Ebene, die Kontext und Grounding bereitstellt
  • Leistung: Die Mess-Ebene, die Latenz und Durchsatz trackt
  • Beobachtbarkeit: Die Überwachungsebene, die Metriken und Kosten-Tracking bereitstellt
  • Daten-Infrastruktur: Die Speicher-Ebene, die Speicher und Indexierung behandelt

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

Für eine minimale lokale Installation mit OpenClaw, siehe den OpenClaw-Schnellstart-Leitfaden, der durch ein Docker-basiertes Setup geht, das entweder ein lokales Ollama-Modell oder eine Cloud-basierte Claude-Konfiguration verwendet.

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

Verwandte Ressourcen

A2A: Agent-to-Agent Protocol:

MCP-Server:

Vergleiche:

KI-Assistenten-Leitfäden:

Infrastruktur-Ebenen:

Abonnieren

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