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 reicht das völlig aus. Aber sobald man über reine Neugier hinausblickt – sobald einem Speicherplatz, Abfragesqualität, Routing-Entscheidungen oder Kostentragung wichtig werden – zeigt sich, wo die Grenzen dieser Einfachkeit liegen.

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

Diese Unterscheidung mag zunächst subtil wirken, ändert aber vollständig, wie man über lokale KI nachdenkt.

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

Was ist ein KI-System?

Ein KI-System ist mehr als nur ein Modell. Es ist eine Orchestrierungsebene, die Inferenz, Abruf, Speicher und Ausführung so verbindet, dass etwas entsteht, 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 Anleitungen zu folgenden Themen bereits erkundet haben:

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

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

Für einen übergreifenden Plan, wie diese Ebenen in produktionsreifen Assistenten zusammenpassen — LLM, Speicher, Werkzeugausstattung, Routing und Observability, mit OpenClaw und Hermes als Referenzsysteme — siehe 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 behandelt, wie Hintergrund-Polling-Worker, wahlbasierte Ausführung, dauerhafte Workflows und semantische LLM-Evaluatoren 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 Koordinationsmusters alles: Latenz, Fehlertoleranz, Kosten und Debuggbarkeit. Multi-Agent-Orchestrierungsmuster: Eine praktische Anleitung behandelt die sechs kanonischen Muster — Orchestrator-Worker, sequentielle Pipeline, Fan-out, hierarchisch, Schwarm und Mesh — mit spezifischen Fehlermodi und einem Entscheidungsrahmen zur Auswahl der richtigen Architektur.

OpenClaw: Ein self-gehostetes KI-Assistenten-System

OpenClaw ist ein Open-Source-, self-gehosteter KI-Assistent, der so konzipiert ist, dass er über verschiedene Messaging-Plattformen hinweg arbeitet, während er auf lokaler Infrastruktur läuft.

Auf praktischer Ebene:

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

Es ist nicht einfach nur ein Wrapper um ein Modell. Es ist eine Orchestrierungsebene, die Inferenz, Abruf, Speicher und Ausführung so verbindet, dass etwas entsteht, das sich wie ein kohärenter Assistent verhält.

Erste Schritte und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeitumgebung — indem sie Speicher-Backends, Modell-Provider, Kommunikationskanäle, Web-Tools und Observability hinzufügen. Skills erweitern das Agenten-Verhalten — indem 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 self-gehosteter, modell-agnostischer Assistent, der sich auf persistente Operation konzentriert: Er kann als langlebiger Prozess laufen, Tools über konfigurierbare Backends ausführen und Workflows über die Zeit durch Speicher und wiederverwendbare Skills verbessern.

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

  • Einen terminal-basierten Assistenten, der auch Brücken zu Messaging-Apps schlagen kann
  • Provider- Flexibilität durch OpenAI-kompatible Endpunkte und Modellwechsel
  • Tool-Ausführungsgrenzen durch lokale und sandboxierte Backends
  • Tageszwei-Operationen mit Diagnostics, 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 Produktionsverantwortlichkeit macht, nicht den einzelnen Skill.

Persistentes Wissen und Speicher

Manche Probleme werden nicht allein durch ein größeres Kontextfenster gelöst — sie benötigen persistentes Wissen (Graphen, Ingestionspipelines) 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 einen USB-C-Port für KI-Anwendungen. Das Bauen 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 für die Frage, wann Skills verwendet, wann MCP Server gebaut werden sollen und wie das Thin-Server-Muster beides kombiniert
  • MCP Server in Go — Protokollarchitektur, JSON-RPC-Nachrichtenstruktur, Funktionsverhandlung, offizielle Go SDK und ein Schritt-für-Schritt-Tutorial zum Bauen von MCP Servern in Go
  • MCP Server in Python bauen — praktische Python-Implementierungsanleitung, die Websuche- 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 bereitgestellten KI-Agentensystemen. Während MCP einen Agenten mit Tools verbindet, verbindet A2A Agenten mit anderen Agenten — indem 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, mit verschiedenen Frameworks gebaut oder als separate Dienste bereitgestellt werden, die interoperabel sein müssen.

Was KI-Systeme unterscheidet

Mehrere Merkmale machen KI-Systeme einen genaueren Blick wert.

Modell-Routing als Designentscheidung

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

Das stellt Fragen auf:

  • Sollten kleine Anfragen kleinere Modelle verwenden?
  • Wann rechtfertigt das Schließen ein größeres Kontextfenster?
  • Was ist der Kostenuunterschied pro 1.000 Token?

Diese Fragen hängen direkt mit den Leistungs-Trade-offs zusammen, die im LLM-Leistungs-Guide diskutiert und den Infrastruktur-Entscheidungen, die im LLM-Hosting-Guide skizziert werden.

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

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren Dokumentenabruf, aber nicht als schlichten „embed and search“-Schritt.

Sie erkennen an:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybride Suche (BM25 + Vektor) kann reinen dichten Abruf übertreffen
  • Reranking verbessert Relevanz auf Kosten der Latenz
  • Indexierungsstrategie beeinflusst Speichernutzung

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

Der Unterschied besteht darin, dass KI-Systeme Abruf in einen lebendigen Assistenten einbetten, statt ihn als isolierte Demo zu präsentieren. Deep Research nimmt diese Idee am weitesten: anstelle eines einzigen Abrufdurchlaufs plant das System, verzweigt, prüft nach und iteriert, bis die Beweise ausreichen. Self-Hosted Deep Research Systeme: 12 Tools im Vergleich geht zwölf self-gehostete Systeme durch — rekursive Forschungsbaum, Planner-plus-Subagent-Designs und Evidence-Gap-Schleifen unter ihnen — und wie jedes von ihnen Abruf in einen adaptiven Forschungsschleife verwandelt.

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 indexiert man Speicher effizient?

Diese Fragen kreuzen sich direkt mit den Datenlagengedanken aus dem Dateninfrastruktur-Guide. Für Hermes Agent speziell — begrenzter Zwei-Datei-Speicher, Prefix-Caching, externe Plugins — beginnen Sie mit Hermes Agent Speichersystem und dem ü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 den Fehlermodus und Mnemosyne für Hermes Agent für eine konservative, lokale Implementierung. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Wissenslagenguides.

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

Observability ist nicht optional

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

KI-Systeme ermöglichen es, zu beobachten:

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

Dies hängt natürlich mit den Überwachungsgedanken zusammen, die in der Observability-Anleitung beschrieben sind.

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

Wie es sich anfühlt, es zu benutzen

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 technischen Bericht zusammenzufassen, der lokal gespeichert ist:

  1. Es ruft relevante Dokumentsegmente ab.
  2. Es wählt ein geeignetes Modell.
  3. Es erzeugt eine Antwort.
  4. Es protokolliert Token-Nutzung und Latenz.
  5. Es aktualisiert den persistenten Speicher, wenn 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 einpassen

Das KI-Systeme-Cluster sitzt an der Schnittstelle mehrerer Infrastruktur-Ebenen:

  • LLM-Hosting: Die Laufzeit-Ebene, auf der Modelle ausgeführt werden (Ollama, vLLM, llama.cpp)
  • RAG: Die Abruf-Ebene, die Kontext und Grounding bereitstellt
  • Leistung: Die Mess-Ebene, die Latenz und Durchsatz nachverfolgt
  • Observability: Die Überwachungsebene, die Metriken und Kostenverfolgung bereitstellt
  • Dateninfrastruktur: Die Speicher-Ebene, die Speicher und Indizierung behandelt

Diesen Unterschied zu verstehen ist nützlich. Selbst es auszuführen macht den Unterschied klarer.

Für eine minimale lokale Installation mit OpenClaw, siehe die [OpenClaw Schnellstart-Anleitung](https://www.glukhov.org/de/ai-systems/openclaw/quickstart/, die einen Docker-basierten Setup-Durchlauf behandelt, der entweder ein lokales Ollama-Modell oder eine cloud-basierte Claude-Konfiguration verwendet.

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

Verwandte Ressourcen

A2A: Agent-to-Agent Protocol:

MCP-Server:

Vergleiche:

KI-Assistenten-Anleitungen:

Infrastruktur-Ebenen:

Abonnieren

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