Architektur eines KI-Assistenten: LLM, Speicher, Tools, Routing, Observability

Ein produktionsreifes KI-Assistentensystem ist nicht einfach „ein LLM mit einem Prompt“. Es handelt sich um ein System, das Absichten akzeptiert, Zustände verwaltet, entscheidet, wann es Informationen abrufen oder Aktionen ausführen soll, und genügend Runtime-Details offenlegt, um Fehler zu debuggen.

Diese systemorientierte Perspektive untersucht der AI Systems Cluster dann, wenn Assistenten über eine einzelne Modellaufruf-Instanz hinausgehen.

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

Die sauberste Architektur teilt die Verantwortlichkeiten in fünf Schichten auf: LLM, Memory (Speicher), Tooling (Werkzeuge), Routing (Weiterleitung) und Observability (Beobachtbarkeit). Diese Aufteilung entspricht den Fähigkeiten, die von den APIs großer Anbieter, von MCP, von selbst gehosteten Runtimes wie vLLM und llama.cpp sowie von echten Assistenzsystemen wie OpenClaw und Hermes bereitgestellt werden.

Der Speicher sollte als mehr als nur „längerer Kontext“ behandelt werden. Abrufsysteme (Retrieval Systems) verwandeln externes Wissen in explizites nicht-parametrisches Gedächtnis — denselben Gestaltungsbereich, der ausführlich in Retrieval-Augmented Generation (RAG) 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 keinen zuverlässigen Abruf garantiert.

Die Nutzung von Tools ist eine Vertragsgrenze, kein Zauber. OpenAIs Function Calling, Anthropics Tool Use und MCP basieren alle auf demselben Muster: Das Modell gibt eine strukturierte Anfrage aus, eine Runtime führt sie aus, und das Ergebnis fließt zurück in die Konversation. Wenn diese Grenze ungenau ist, wird auch der Assistent ungenau.

Meine Voreinstellung ist einfach: Beginnen Sie langweilig. Ein Orchestrierer, ein dauerhafter Speicherpfad, ein Trace pro Anfrage und eine explizite Richtlinie für die Tool-Ausführung. Multi-Agent-Graphen sind nützlich, aber erst dann, wenn Sie Ihre Single-Agent-Fehlerfälle ohne Raten erklären können.

Was ein KI-Assistentensystem ist

Eine praktische Definition lautet: Ein KI-Assistentensystem ist eine Runtime, die Nutzerabsichten in eine Antwort oder Aktion umwandelt, indem sie eine Modell-Schnittstelle, Kontextzusammenstellung, Tool-Ausführung, Statusverwaltung und Telemetrie kombiniert. Deshalb sind die nützlichen Dokumentationen nicht nur Modell-Karten. Die nützlichen Dokumentationen sind API-Referenzen, Tool-Verträge, Abruf-Leitfäden, 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 Speicher platziert.

Mit anderen Worten: Ein Assistenzsystem hat einen breiteren Vertrag als eine Chat-Completion. Ein guter interner Vertrag sieht in etwa so aus:

AssistantRequest  = user intent + identity + session + attachments + policy
AssistantResponse = answer + actions + citations + state changes + trace id

Dieser Vertrag ist wichtig, weil jede Produktionsdiskussion schließlich auf eine dieser Fragen hinausläuft: Welcher Kontext war sichtbar, welches Tool wurde ausgeführt, welches Modell hat geantwortet, welcher Speicher wurde gelesen oder geschrieben und wo sagt der Trace, dass das System Zeit verbracht hat. OpenTelemetry definiert Traces als den Pfad 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 Agent-Workflows.

Kernkomponenten und Schnittstellen

Die nachfolgende Komponentenaufteilung ist diejenige, die ich als am haltbarsten empfinde. Sie stimmt auch am besten mit den offiziellen APIs und den Open-Source-Runtimes überein, die Menschen tatsächlich betreiben.

Die obige Tabelle leitet sich von den offiziellen Provider-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: Den aktuellen Arbeitskontext verbrauchen, entweder eine finale Antwort oder eine strukturierte Aktionsanfrage ausgeben und genügend Metadaten zurückgeben, um Wiederholungen und Tracing zu unterstützen. OpenAIs Responses API ist explizit für zustandsbehaftete Interaktionen sowie integrierte Tools und Function Calling ausgelegt. Anthropics Messages API stellt dieselbe Kernschleife über tool_use-Blöcke und tool_result-Rückgaben bereit, während Managed Agents Ihnen einen gehosteten Rahmen bietet, wenn Sie die Schleife nicht selbst aufbauen möchten. Selbst gehostete Runtimes wie vLLM und llama.cpp sind wichtig, weil sie vertraute Provider-ähnliche Schnittstellen beibehalten, während sie Ihnen ermöglichen, die Inferenz in Ihrer eigenen Umgebung zu platzieren.

Die Memory-Schicht sollte mental in drei Kategorien 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 Keyword-Suche zusätzlich zu Vektorspeichern. Pinecone, Weaviate, pgvector und Milvus repräsentieren vier gängige Speicherformen: vollständig verwaltet, Open-Source-Vektor-Nativ, Postgres-Nativ und verteilte Vektordatenbank. Hermes und OpenClaw liefern eine nützliche Erinnerung, dass nicht alles Gedächtnis in einen Vektorspeicher gehört: dateibasierte Notizen, überprüfte Promotionen und sitzungsbasierte Snapshots sind oft das ehrlichere Design — Muster, die in Hermes Agent Memory System für begrenztes Kerngedächtnis und eingefrorene Sitzungssnapshots aufgebrochen werden.

Die Tooling-Schicht ist der Ort, an dem ein Assistent aufhört, nur ein Zusammenfasser zu sein, und beginnt, Software zu sein. OpenAI Function Calling behandelt Tools als schemadefinierte Funktionalität, die das Modell entscheiden kann, ob es sie aufruft. Anthropic sagt dasselbe expliziter: Tool Use ist ein Vertrag zwischen Ihrer Anwendung und dem Modell, und das Modell führt niemals etwas eigenständig aus. MCP verallgemeinert diesen Vertrag zu einem Client-Server-Protokoll, bei dem Hosts mit einem oder mehreren Servern verbunden sind, die Tools, Prompts und Ressourcen offenlegen — dieselbe Grenze, die schrittweise in MCP Server in Go beschrieben wird. LangChain und LlamaIndex passen sich hier gut als Orchestrierungs-Bibliotheken an: LangChain konzentriert sich auf eine vorgefertigte Agenten-Architektur und Integrationen, während LlamaIndex sich auf kontexterweiterten Datenzugriff, Query-Engines und Workflows konzentriert.

Die Routing-Schicht existiert, weil „welches Modell?“ nie die einzige Frage ist. Sie brauchen auch Antworten auf „welcher Provider-Pfad, welcher Tenant, welches Budget, welche Latenzklasse und welches Fallback?“. LiteLLM ist nützlich, weil seine offiziellen Dokumentationen erfrischend konkret sind: gewichtete Auswahl, least-busy, latenzbasiertes, kostengestütztes Routing und begrenzte Failovers sind alle erstklassige Muster. OpenClaw erweitert das Routing nach oben in Kanal- und Agenten-Isolation, während Hermes es nach unten in Modell-Slots 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 aus, er wählt eine Ausführungsbahn.

Die Observability-Schicht ist das, was verhindert, dass Architektur in Folklore umschlägt. 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 bietet Ihnen OpenTelemetry-native AI-Beobachtbarkeit mit Zero-Code- und manuellen Instrumentierungsoptionen, einschließlich Unterstützung für LLMs, Agent-Frameworks, Vektordatenbanken und GPUs. Für Produktionsmetriken, Traces und SLO-Muster über Inferenz- und Agent-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 nur Vibes.

Erfassen, anreichern, antworten

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

sequenceDiagram
    participant U as User or Channel
    participant G as Gateway or UI
    participant R as Router
    participant M as Memory and Retrieval
    participant L as LLM
    participant T as Tools or MCP
    participant O as Observability

    U->>G: message, file, or command
    G->>O: start root trace
    G->>R: request + identity + session + policy
    R->>M: load session state and retrieve context
    M-->>R: notes, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: answer or tool call
    alt tool call
        R->>T: execute tool or MCP action
        T-->>R: tool result
        R->>L: tool result + updated context
        L-->>R: final answer
    end
    R->>M: persist session changes and memory candidates
    R->>O: spans, metrics, eval events
    G-->>U: response

Der Schritt des Erfassens ist in der Regel wichtiger, als er aussieht. OpenClaw und Hermes stellen beide ein persistierendes Gateway vor den Assistenten, weil Ingress nicht nur Texteingabe ist. Es umfasst Kanalmetadaten, Identitäten, Autorisierung, Sitzungsgrenzen, Direktnachrichten, Gruppen, Cron-Ticks und Delivery-Semantik. Wenn Sie diese Schicht überspringen und sich auf eine rohe Chat-Widget-Abstraktion verlassen, werden Sie sie am Ende trotzdem als ad-hoc Middleware nachrüsten.

Der Schritt des Anreicherns ist der Ort, an dem reife Systeme von Spielzeug-Demos abweichen. OpenAI Retrieval und File Search machen Retrieval durch Vektorspeicher und Suchaufrufe explizit. LlamaIndex formalisiert dasselbe Muster durch Datenkonnektoren, Indizes, Query-Engines und Workflows. Hermes geht noch weiter, indem er das Modellportfolio in Haupt- und Hilfs-Slots aufteilt und Arbeiten wie Kompression, Zusammenfassung und Routing an kleinere oder spezialisierte Modelle auslagert. Das ist ein Designmuster, das sich zu stehlen lohnt: Verwenden Sie Ihre teuersten Modell-Tokens nicht für Hausarbeit.

Der Schritt des Antwortens 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, gibt es eine strukturierte Anfrage aus. Anthropics Tool-Use-Vertrag und OpenAIs Function-Calling-Leitfaden machen dies explizit. Der Grund, warum das architektonisch wichtig ist, liegt darin, dass Outputs nun sowohl Sprache als auch Steuerungsfluss enthalten. Ihr Response-Objekt ist zum Teil Prosa und zum Teil Runtime-Plan.

Der Schritt des Aufzeichnens ist der Ort, an dem Konsistenzsemantik auftaucht. 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-Leistung zu erhalten, was bedeutet, dass neue Schreibvorgänge nicht automatisch im aktuellen Sitzungsprompt erscheinen. OpenClaws Dreaming-System fördert nur überprüfte, begründete Kandidaten in MEMORY.md, und es ist opt-in und nicht immer aktiv. Die praktische Lektion ist, dass Speicher 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 Wraps um eine Provider-API sind. Beide präsentieren einen Assistenten als ein lang laufendes System mit Gateways, Sitzungen, Tools, Speicher und mehreren Modell-Backends.

Diese Zuordnung basiert auf den offiziellen OpenClaw- und Hermes-Dokumentationen und Repos. OpenClaw dokumentiert eine Gateway-Architektur, Multi-Agent-Routing, Unterstützung für benutzerdefinierte und selbst gehostete Provider einschließlich vLLM und Ollama, optionalen aktiven Speicher und Dreaming-basierte Promotion. Hermes dokumentiert ein Messaging-Gateway, eine zentrale AIAgent-Schleife, Haupt- und Hilfs-Modell-Slots, integrierten Speicher und native MCP-Integration.

Meine leicht opinionierte Lesart ist, dass beide Systeme das gleiche 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, Speichersemantik, Tool-Oberflächen und Backend-Heterogenität als erstklassige Anliegen. 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 vom Hersteller vorgeschriebenes Blueprint. Es funktioniert, weil die offiziellen Schnittstellen übereinstimmen: OpenAI und Anthropic bieten tool-orientierte APIs, vLLM und llama.cpp emulieren Provider-ä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 es wert sind, benannt zu werden. Ein verwaltetes Assistentensystem behält den Großteil der Runtime innerhalb von Provider-APIs. Ein Retrieval-first-Assistent behandelt Speicher und Suche als Hauptunterscheidungsmerkmal. Ein Tool-first-Assistent verhält sich eher wie ein Operator als wie ein Chatbot. Ein Gateway-Assistent priorisiert den immer verfügbaren Zugriff über Messaging-Oberflächen. Ein Spezialisten-Mesh zerlegt die 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 unterschiedlich benennen.

Diese Mustertabelle ist eine Synthese aus den Provider-Dokumentationen, Framework-Dokumentationen und Referenzsystemen und keine Behauptung 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 selbst gehostet 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 invertierte Indizes mit mehreren Vektor-Index-Typen. pgvector fügt Postgres exakte und approximative Nearest-Neighbor-Suche hinzu. Milvus positioniert sich als Open-Source, hochperformante, skalierbare Vektordatenbank, mit Zilliz Cloud als verwalteter Option.

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

Diese Tradeoff-Matrix ist eine architektonische Inferenz aus den offiziellen Dokumentationen, kein Vendor-Benchmark. Die Konsistenzzeile ist wichtiger, als viele Blog-Posts zugeben: Pinecone trennt Schreib- und Lesepfade, Hermes friert Speicher in Sitzungsstart-Prompts ein, und OpenClaw fördert dauerhaften Speicher durch gestaffelte Überprüfung. Das bedeutet, dass „Speicher aktualisiert“ und „Speicher 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, es 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-Dokumente machen klar, dass Tool Use eine Vertragsgrenze ist. OpenAI Guardrails umfasst Halluzinations-Erkennung gegen eine Referenz-Wissensdatenbank 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 Minderungs-Stack könnte langweilig und repetitiv sein: Tracken Sie jede Anfrage, versionieren Sie Prompts, evaluieren Sie Retrieval unabhängig, halten Sie Tools idempotent und führen Sie Regression-Evals durch, bevor Sie Routen oder Speicher-Richtlinien ändern. OpenAIs Evals-Dokumente und Repo sind blunt darüber, warum: Ohne Evals ist es schwierig und zeitaufwändig zu verstehen, wie Modell- oder Prompt-Änderungen Ihren Use Case beeinflussen. Das gilt genauso für Router und Retrieval wie für Prompts.

Weiterführende Literatur

Wenn Sie tiefer einsteigen möchten, sind dies die nützlichsten Primärquellen, die Sie beim Entwurf oder Review einer Assistenten-Architektur offen halten sollten.

• OpenAI: Responses Overview, Function Calling, Using Tools, Retrieval, File Search, Evals und MCP für Remote-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 es wert, direkt gelesen zu werden, weil sie Hosts, Clients, Server, Tools, Prompts, Ressourcen, Transports und Capability-Negotiation sauber erklären.

• Frameworks und Routing: LangChain Overview, LlamaIndex Kontext-Augmentations-Dokumente, LiteLLM Routing-Dokumente, LangSmith Observability-Dokumente.

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

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

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