Architektur von KI-Assistenten: LLM, Speicher, Werkzeuge, Routing, Observability

Ein produktionsreifes KI-Assistentensystem ist nicht einfach „ein LLM mit einem Prompt“. Es handelt sich um ein System, das Absichten entgegennimmt, den Zustand verwaltet, entscheidet, wann Daten abgerufen oder Aktionen ausgeführt werden sollen, und genügend Laufzeitdetails bereitstellt, um Fehler zu debuggen.

Diese systemische Perspektive wird im AI Systems Cluster behandelt, wenn Assistenten über eine einzelne Modellaufruf-Instanz hinausgehen.

OpenAI beschreibt Agenten als Anwendungen, die planen, Tools aufrufen, zusammenarbeiten und genug Zustand für mehrschrittige Arbeiten beibehalten, während Anthropic dasselbe Problem als einen verwalteten Rahmen beschreibt, der Dateien, Befehle, Webzugriffe und Code sicher ausführen kann.

Die klarste Architektur unterteilt die Verantwortlichkeiten in fünf Schichten: LLM, Gedächtnis, Tooling, Routing und Observability. Diese Aufteilung entspricht den Fähigkeiten, die von den APIs der großen Anbieter, von MCP, von selbst gehosteten Laufzeiten wie vLLM und llama.cpp sowie von echten Assistensystemen wie OpenClaw und Hermes bereitgestellt werden.

Gedächtnis sollte als mehr als nur „längerer Kontext“ behandelt werden. Abrufsysteme verwandeln externes Wissen in explizites, nicht-parametrisches Gedächtnis — denselben Entwurfsraum, der in Retrieval-Augmented Generation (RAG) ausführlich behandelt wird — und sowohl Anthropics Kontextrichtlinien als auch die „Lost in the Middle“-Studie warnen davor, dass das bloße Stopfen mehr Tokens in den Kontext keine zuverlässige Erinnerung garantiert.

Die Nutzung von Tools ist eine Vertragsgrenze, keine Zauberei. OpenAI Function Calling, Anthropic Tool Use und MCP basieren alle auf demselben Muster: Das Modell emittiert eine strukturierte Anfrage, eine Laufzeit führt sie aus, und das Ergebnis fließt zurück in die Konversation. Wenn diese Grenze nachlässig ist, wird der Assistent nachlässig.

Meine Präferenz ist einfach: Beginnen Sie langweilig. Ein Orchestrierer, ein dauerhaftes Gedächtnispfad, ein Trace pro Anfrage und eine explizite Richtlinie für die Tool-Ausführung. Multi-Agenten-Graphen sind nützlich, aber erst nachdem Sie Ihre Single-Agenten-Fehlerfälle ohne Raten erklären können.

Was ein KI-Assistentensystem ist

Eine praktische Definition lautet: Ein KI-Assistentensystem ist eine Laufzeit, die Benutzerabsichten durch die Kombination einer Modell-Schnittstelle, Kontextzusammenstellung, Tool-Ausführung, Zustandsverwaltung und Telemetrie in eine Antwort oder Aktion umwandelt. Deshalb sind die nützlichen Dokumentationen nicht nur Modellkarten. Die nützlichen Dokumentationen sind API-Referenzen, Tool-Verträge, Abrufanleitungen, Routing-Dokumentationen und Tracing-Dokumentationen. OpenAIs Responses API bietet zustandsbehaftete Interaktionen, integrierte Tools und Function Calling. Anthropics Claude API bietet direkten Messages-Zugriff sowie Managed Agents. OpenClaw und Hermes gehen einen Schritt weiter und zeigen, was passiert, wenn man diese Fähigkeiten hinter persistenten Gateways, Kanälen, Sitzungen und Gedächtnis platziert.

Mit anderen Worten, ein Assistentensystem hat einen breiteren Vertrag als eine Chat-Vervollständigung. Ein guter interner Vertrag sieht etwa so aus:

AssistantRequest  = Benutzerabsicht + Identität + Sitzung + Anhänge + Richtlinie
AssistantResponse = Antwort + Aktionen + Zitate + Zustandsänderungen + Trace-ID

Dieser Vertrag ist wichtig, weil jede produktive Uneinigkeit letztendlich auf eine dieser Fragen zurückzuführen ist: Welcher Kontext war sichtbar, welches Tool wurde ausgeführt, welches Modell hat geantwortet, welches Gedächtnis wurde gelesen oder geschrieben und wo gibt der Trace an, dass das System Zeit verbracht hat. OpenTelemetry definiert Traces als den Weg einer Anfrage durch eine Anwendung, was genau die Abstraktion ist, die ernsthafte Assistenten brauchen. LangSmith und OpenLIT spezialisieren diese Idee dann für LLMs, Tools, Vektorspeicher und Agenten-Workflows.

Kernkomponenten und Schnittstellen

Die unten dargestellte Komponentenaufteilung ist diejenige, die ich als am haltbarsten empfinde. Sie ist auch diejenige, die am besten mit den offiziellen APIs und den Open-Source-Laufzeiten übereinstimmt, die Menschen tatsächlich betreiben.

Die obige Tabelle leitet sich von den offiziellen Anbieter-Schnittstellen, MCP, Vektordatenbank-Dokumentationen und den Runtime-Dokumentationen für vLLM, llama.cpp, OpenClaw und Hermes ab.

Die LLM-Schicht sollte drei Dinge gut machen: Einen aktuellen Arbeitskontext verbrauchen, entweder eine finale Antwort oder eine strukturierte Aktionsanfrage emittieren und genügend Metadaten zurückgeben, um Wiederholungen und Tracing zu unterstützen. OpenAIs Responses API ist explizit für zustandsbehaftete Interaktionen plus integrierte Tools und Function Calling entwickelt. Anthropics Messages API stellt dieselbe Kernschleife durch tool_use-Blöcke und tool_result-Rückgaben zur Verfügung, während Managed Agents Ihnen einen gehosteten Rahmen bietet, wenn Sie die Schleife nicht selbst bauen möchten. Selbst gehostete Laufzeiten wie vLLM und llama.cpp sind wichtig, weil sie vertraute anbieterähnliche Schnittstellen beibehalten, während sie Ihnen ermöglichen, Inferenz in Ihrer eigenen Umgebung zu platzieren.

Die Gedächtnisschicht sollte mental in drei Bereiche unterteilt werden: Arbeitsgedächtnis, dauerhaftes symbolisches Gedächtnis und durchsuchbares semantisches Gedächtnis. OpenAI-Embeddings geben Vektoren zurück, die indiziert und durchsucht werden können; OpenAI Retrieval und File Search legen semantische und Stichwortsuche auf Vektorspeicher. Pinecone, Weaviate, pgvector und Milvus repräsentieren vier gängige Speicherformen: Voll verwaltet, Open-Source-Vektor-Nativ, Postgres-Nativ und verteilte Vektordatenbank. Hermes und OpenClaw füllen eine nützliche Erinnerung hinzu, dass nicht alle Gedächtnisinhalte in einen Vektorspeicher gehören: Datei-basierte Notizen, überprüfte Promotionen und sitzungsbezogene Snapshots sind oft das ehrlichere Design. Memory Systems in AI Assistants kartiert das Cross-Framework-Modell; Hermes Agent Memory System zerlegt begrenztes Kerngedächtnis und eingefrorene Sitzungssnapshots in einem Produkt.

Die Tooling-Schicht ist der Ort, an dem ein Assistent aufhört, ein Zusammenfasser zu sein, und beginnt, Software zu sein. OpenAI Function Calling behandelt Tools als schema-definierte Funktionalität, die das Modell entscheiden kann, aufzurufen. Anthropic sagt dasselbe expliziter: Tool Use ist ein Vertrag zwischen Ihrer Anwendung und dem Modell, und das Modell führt niemals etwas auf eigene Faust aus. MCP verallgemeinert diesen Vertrag zu einem Client-Server-Protokoll, bei dem Hosts sich mit einem oder mehreren Servern verbinden, die Tools, Prompts und Ressourcen freilegen — dieselbe Grenze, die Schritt für Schritt in MCP Server in Go beschrieben wird. LangChain und LlamaIndex sitzen bequem hier als Orchestrierungsbibliotheken: LangChain konzentriert sich auf eine vorgefertigte Agentenarchitektur und Integrationen, während LlamaIndex sich auf kontextaugmentierten Datenzugriff, Query-Engines und Workflows konzentriert.

Die Routing-Schicht existiert, weil „welches Modell?“ nie die einzige Frage ist. Sie brauchen auch „welchen Anbieterpfad, welchen Tenant, welches Budget, welche Latenzklasse und welchen Fallback?“. LiteLLM ist nützlich, weil seine offiziellen Dokumentationen erfrischend konkret sind: Gewichtete Auswahl, wenig beschäftigt, latenzbasiert, kostenbasiertes Routing und begrenzte Failovers sind alle erstklassige Muster. OpenClaw erweitert das Routing nach oben in Kanal- und Agenten-Isolierung, während Hermes es nach unten in Modellslots für Haupt- und Hilfsarbeiten wie Zusammenfassung, Kontextkompression und MCP-Tool-Routing erweitert. Das ist das richtige mentale Modell: Der Router wählt mehr als ein Modell, er wählt eine Ausführungsbahn.

Die Observability-Schicht ist das, was verhindert, dass Architektur in Folklore umgewandelt wird. OpenTelemetry gibt Ihnen die Trace-Abstraktion. LangSmith gibt Ihnen End-to-End-Sichtbarkeit über LLM-Anwendungsschritte und unterstützt Cloud-, Hybrid- und Self-Hosted-Deployments. OpenLIT gibt Ihnen OpenTelemetry-native KI-Observierbarkeit mit Zero-Code- und manueller Instrumentierungsoptionen, einschließlich Unterstützung für LLMs, Agentenframeworks, Vektordatenbanken und GPUs. Für Produktionsmetriken, Traces und SLO-Muster über Inferenz- und Agenten-Workflows hinweg, siehe Observability for LLM Systems. Wenn Ihr Assistent keinen Trace pro Anfrage, keinen Span pro Modellaufruf und keine Ereignisgeschichte für die Tool-Ausführung hat, haben Sie noch keine echte Architektur. Sie haben Vibes.

Erfassen, anreichern, antworten

Die Sequenz, die in echten Systemen immer wieder auftaucht, ist Erfassen -> Anreichern -> Antworten -> Aufzeichnen. Verschiedene Frameworks wickeln es unterschiedlich ein, aber der Fluss ist stabil genug, um als Rückgrat behandelt zu werden.

Der Erfassen-Schritt ist meist wichtiger, als er aussieht. OpenClaw und Hermes setzen beide ein persistentes Gateway vor den Assistenten, weil Ingress nicht nur Texteingabe ist. Es umfasst Kanalmetadaten, Identitäten, Autorisierung, Sitzungsgrenzen, Direktnachrichten, Gruppen, Cron-Ticks und Liefersemantik. Wenn Sie diese Schicht überspringen und auf eine rohe Chat-Widget-Abstraktion verlassen, werden Sie sie irgendwann als ad-hoc-Middleware nachrüsten.

Der Anreichern-Schritt ist der Ort, an dem reife Systeme von Spielzeug-Demos abweichen. OpenAI Retrieval und File Search machen Abruf durch Vektorspeicher und Suchaufrufe explizit. LlamaIndex formalisiert dasselbe Muster durch Datenconnectoren, Indizes, Query-Engines und Workflows. Hermes geht weiter, indem er die Modelllandschaft in Haupt- und Hilfsslots aufteilt und Arbeiten wie Kompression, Zusammenfassung und Routing an kleinere oder spezialisierte Modelle outsourct. Das ist ein Entwurfmuster, das man stehlen sollte: Verbringen Sie nicht Ihre teuersten Modelltokens mit Chores.

Der Antworten-Schritt ist nicht „Text generieren“. Es ist „den aktuellen Loop schließen“. Wenn das Modell direkt antworten kann, tut es das. Wenn es ein Tool braucht, emittiert es eine strukturierte Anfrage. Anthropics Tool-Use-Vertrag und OpenAIs Function-Calling-Guide machen dies explizit. Der Grund, warum dies architektonisch wichtig ist, ist, dass Outputs jetzt sowohl Sprache als auch Kontrollfluss enthalten. Ihr Response-Objekt ist teilweise Prosa und teilweise Runtime-Plan.

Der Aufzeichnen-Schritt ist der Ort, an dem Konsistenzsemantiken auftauchen. Pinecone trennt Schreib- und Lesepfade und verarbeitet Schreibvorgänge nach dauerhafter Bestätigung. Hermes Memory wird als eingefrorener Snapshot pro Sitzung injiziert, um Prefix-Cache-Performance zu erhalten, was bedeutet, dass neue Schreibvorgänge nicht automatisch im aktuellen Sitzungsprompt erscheinen. OpenClaws Dreaming-System promotet nur überprüfte, groundierte Kandidaten in MEMORY.md, und es ist opt-in und nicht immer aktiv. Die praktische Lektion ist, dass Gedächtnis selten wirklich read-after-write über jede Schicht hinweg ist. Sie müssen für gestaffelte Sichtbarkeit designen.

OpenClaw und Hermes als Referenzsysteme

OpenClaw und Hermes sind nützliche Referenzfälle, weil sie nicht nur Wrapper um eine Anbieter-API sind. Beide präsentieren einen Assistenten als langlebiges System mit Gateways, Sitzungen, Tools, Gedächtnis und mehreren Modellbackends.

Diese Zuordnung basiert auf den offiziellen OpenClaw- und Hermes-Dokumentationen und Repositories. OpenClaw dokumentiert eine Gateway-Architektur, Multi-Agent-Routing, benutzerdefinierten und selbst gehosteten Provider-Support, einschließlich vLLM und Ollama, optionales aktives Gedächtnis und Dreaming-basierte Promotion. Hermes dokumentiert ein Messaging-Gateway, eine zentrale AIAgent-Schleife, Haupt- und Hilfsslots, integriertes Gedächtnis und native MCP-Integration.

Meine leicht opinionierte Lesart ist, dass beide Systeme dasselbe architektonische Argument in verschiedenen Akzenten machen. OpenClaw ist stark gateway-first. Hermes ist stark agent-loop-first. Aber beide lehnen die flache Idee ab, dass ein Assistent nur „Prompt plus Modell“ ist. Sie modellieren Kanäle, Identitäten, Gedächtnissemantiken, Tool-Oberflächen und Backend-Heterogenität als erstklassige Belange. Das ist genau das, was eine Produktionsarchitektur tun sollte.

Ein praktischer Hybrid-Stack, inspiriert von beiden Systemen, sieht so aus:

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Dieser Stack ist ein durchdachtes Deployment-Muster und kein von einem Anbieter vorgegebenes Blueprint. Es funktioniert, weil die offiziellen Schnittflächen übereinstimmen: OpenAI und Anthropic bieten tool-orientierte APIs, vLLM und llama.cpp emulieren anbieterähnliche Endpunkte, Ollama handhabt lokale Modelle und Embeddings, MCP standardisiert externe Tools, LiteLLM handhabt Routing und Failover, und OpenTelemetry-kompatible Plattformen können den gesamten Pfad tracken.

Muster, Tabellen und Tradeoffs

Es gibt einige wiederkehrende Assistentenmuster, die namentlich erwähnt werden sollten. Ein Managed Assistant hält die meiste Laufzeit innerhalb der Anbieter-APIs. Ein Retrieval-first Assistant behandelt Gedächtnis und Suche als den Hauptunterschied. Ein Tool-first Assistant verhält sich mehr wie ein Operator als wie ein Chatbot. Ein Gateway Assistant priorisiertAlways-on-Zugriff durch Messaging-Oberflächen. Ein Specialist Mesh zerlegt Arbeit in mehrere Agenten oder Routen. Offizielle Dokumentationen von OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw und Hermes unterstützen Versionen dieser Muster, auch wenn sie sie anders benennen.

Das Specialist-Mesh-Muster wächst zu einer eigenen Ingenieursdisziplin, wenn die Agentenanzahl steigt. Für die sechs kanonischen Koordinationsmuster — Orchestrator-Worker, sequentieller Pipeline, Fan-out, hierarchisch, Swarm und Mesh — mit spezifischen Fehlermodi und einem Produktionsentscheidungsframework, siehe Multi-Agent Orchestration Patterns.

Diese Mustertabelle ist eine Synthese aus den Anbieterdokumentationen, Frameworkdokumentationen und Referenzsystemen und kein Anspruch eines einzelnen Anbieters.

Tabellenhinweise: OpenAI gehostete File Search ist ein verwaltetes Tool, Anthropic bietet einen verwalteten Rahmen, Pinecone ist ein verwalteter Vektordienst, während vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith self-hosted und OpenLIT alle selbst verwalteten oder hybriden Betrieb in unterschiedlichem Maße unterstützen.

Tabellenhinweise: Pinecone dokumentiert eine verwaltete Control Plane und regionale Data Planes. Weaviate dokumentiert Vektor- und umgekehrte Indizes mit mehreren Vektorindextypen. pgvector fügt exakte und approximative Nearest-Neighbor-Suche zu Postgres hinzu. Milvus positioniert sich als Open-Source-High-Performance, skalierbare Vektordatenbank, mit Zilliz Cloud als verwalteter Option.

Tabellenhinweise: OpenAI dokumentiert Responses als seine fortschrittliche Schnittstelle für zustandsbehaftete Antworten und integrierte Tools. Anthropic dokumentiert die Messages API und den Tool-Use-Vertrag separat von Managed Agents. vLLM exponiert einen OpenAI-kompatiblen Server plus Anthropic Messages API Support. Ollama dokumentiert lokale Embedding- und Modell-Workflows. llama.cpp dokumentiert OpenAI-kompatible Chat-, Response- und Embedding-Routen, plus Anthropic-kompatible Chat-Vervollständigungen.

Diese Tradeoff-Matrix ist eine architektonische Inferenz aus den offiziellen Dokumentationen, kein Anbieter-Benchmark. Die Konsistenzzeile ist wichtiger, als viele Blogposts zugeben: Pinecone trennt Schreib- und Lesepfade, Hermes friert Gedächtnis in Session-Start-Prompts ein, und OpenClaw promotet dauerhaftes Gedächtnis durch gestaffelte Überprüfung. Das bedeutet, dass „Gedächtnis aktualisiert“ und „Gedächtnis sichtbar für die aktuelle Antwort“ oft unterschiedliche Wahrheiten sind.

Fehlermodi und Minderungen

Die meisten Assistenten scheitern nicht, weil das Basismodell „schlecht“ ist. Sie scheitern, weil das umgebende System das Modell anlügt, ihm den richtigen Kontext vorenthält, Tools driftieren lässt oder Debugging unmöglich macht.

Die Evidenzbasis für diese Tabelle ist breit, aber konsistent. Anthropics Tool-Docs machen klar, dass Tool Use eine Vertragsgrenze ist. OpenAI Guardrails beinhaltet Halluzinationserkennung gegen eine Referenzdatenbank via File Search. SelfCheckGPT zeigt, dass Selbstkonsistenz über Samples hinweg helfen kann, nicht unterstützte Behauptungen zu erkennen. Die „Lost in the Middle“-Ergebnisse und Anthropics Kontextrichtlinien verstärken dieselbe operationale Lektion: Mehr Tokens entfernen nicht die Notwendigkeit der Kontextkuratierung.

Die bevorzugte Minderungsarchitektur könnte langweilig und repetitiv sein: Trace jede Anfrage, versioniere Prompts, evaluiere Abruf unabhängig, halte Tools idempotent und führe Regression-Evals durch, bevor Sie Routen oder Gedächtnisrichtlinien ändern. OpenAIs Evals-Docs und Repo sind blunt darüber, warum: Ohne Evals ist es hart und zeitaufwändig zu verstehen, wie Modell- oder Prompt-Änderungen Ihren Use Case beeinflussen. Das gilt genauso für Router und Abruf wie für Prompts.

Weiteres Lesen

Wenn Sie tiefer einsteigen möchten, sind dies die nützlichsten Primärquellen, die offen bleiben sollten, während Sie eine Assistentenarchitektur designen oder überprüfen.

• OpenAI: Responses Overview, Function Calling, Using Tools, Retrieval, File Search, Evals und MCP für entfernte Tool-Server.

• Anthropic: API Overview, Tool Use, den Tool-Use-Vertrag, Managed Agents, Context Windows und den MCP Connector.

• MCP selbst: Die Architecture Overview und Specification sind direkt lesenswert, weil sie Hosts, Clients, Server, Tools, Prompts, Ressourcen, Transports und Capability Negotiation sauber erklären. Für einen praktischen Vergleich von MCP mit dem Agent2Agent-Protokoll und wann ein Multi-Agent-System beide Schichten braucht, siehe A2A vs MCP: Do AI Agents Really Need Both Protocols? und für die A2A-Konzepte selbst — Agent Cards, Task Lifecycle, Messages, Parts und Artifacts — siehe What Is the A2A Protocol? Agent Cards and Tasks Explained.

• Hintergrund- und proaktive Assistenten: Die Tooling-Schicht ist nur ein Teil davon, wie Assistenten handeln. Für wie man einen Assistenten wachen, entscheiden und selbstständig handeln lässt — Scheduler, queue-basierte Worker, Claim-Protokolle, dauerhafte Workflows und semantisches Polling — siehe Polling Agents in AI Assistants: 11 Implementation Patterns.

• A2A-Protokoll und Adoption: Sobald Agenten unabhängig deployed sind und über Ownership-Grenzen hinweg zusammenarbeiten müssen, wird A2A relevant. Für eine praktische 2026-Ansicht davon, wo A2A tatsächlich Traktion hat, die Sicherheitsfragen, die es aufwirft, und einem Entscheidungsframework für wann man es adoptiert, siehe Google A2A Protocol in 2026: Adoption, Hype, and Reality. Wenn diese Agenten langlaufende Tasks statt einzelner Chat-Turns austauschen, deckt A2A Streaming and Async Tasks for Long-Running Agent Workflows SSE, Push und input_required-Design an der Protokollgrenze ab.

• Frameworks und Routing: LangChain Overview, LlamaIndex Context-Augmentation-Docs, LiteLLM Routing-Docs, LangSmith Observability-Docs.

• Selbst gehostete Laufzeiten und Assistentensysteme: vLLM, llama.cpp Server, Ollama Embeddings, OpenClaw Docs und Repo, Hermes Docs und Repo.

• Storage und Observability: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Forschungsarbeiten: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle und SelfCheckGPT.