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

Ein AI-Assistent für den produktiven Einsatz ist nicht einfach „ein LLM mit einem Prompt“. Er ist ein System, das Absichten akzeptiert, Zustand verwaltet, entscheidet, wann abgerufen oder gehandelt werden soll, und genügend Runtime-Details offenlegt, um Fehler zu analysieren.

Diese systemorientierte Sichtweise ist es, die der AI-Systems-Cluster erkundet, wenn Assistenten über eine einzelne Modell-Aufrufkette hinausgehen.

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

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

Memory sollte als mehr als „längerer Kontext“ betrachtet werden. Retrieval-Systeme verwandeln externes Wissen in explizites nicht-parametrisches Memory – denselben Entwurfsraum, der in Retrieval-Augmented Generation (RAG) eingehend behandelt wird – und sowohl Anthropics Context Guidance als auch das „Lost in the Middle“-Paper warnen davor, dass das bloße Stopfen mehr Tokens in den Kontext keinen zuverlässigen Recall garantiert.

Die Tool-Nutzung ist eine Vertragsgrenze, keine Magie. OpenAI Function Calling, Anthropic Tool Use und MCP verlassen sich alle auf dasselbe 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 nachlässig ist, wird der Assistent nachlässig.

Meine Voreinstellung ist einfach: Beginnen Sie langweilig. Ein Orchestrierer, ein dauerhafter Memory-Pfad, 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 erklären können, ohne zu raten.

Was ein AI-Assistenzsystem ist

Eine praktische Definition ist diese: Ein AI-Assistenzsystem ist eine Runtime, die Benutzerabsicht in eine Antwort oder Aktion umwandelt, indem sie eine Modell-Schnittstelle, Kontextzusammenstellung, Tool-Ausführung, Zustandsverwaltung und Telemetrie kombiniert. Deshalb sind die nützlichen Dokumente nicht nur Model Cards. Die nützlichen Dokumente sind API-Referenzen, Tool-Verträge, Retrieval-Leitfäden, Routing-Dokumente und Tracing-Dokumente. OpenAIs Responses API offenlegt zustandsbehaftete Interaktionen, integrierte Tools und Function Calling. Anthropics Claude API offenlegt 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, Sessions und Memory platziert.

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

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

Dieser Vertrag ist wichtig, weil jede produktive Uneinigkeit schließlich auf eine dieser Fragen hinausläuft: Welcher Kontext war sichtbar, welches Tool wurde ausgeführt, welches Modell hat geantwortet, welches Memory wurde gelesen oder geschrieben und wo sagt der Trace, 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 benötigen. LangSmith und OpenLIT spezialisieren diese Idee dann für LLMs, Tools, Vektorspeicher und Agent-Workflows.

Kernkomponenten und Schnittstellen

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

Die obige Tabelle leitet sich von den offiziellen Anbieter-Schnittstellen, MCP, Vektordatenbank-Dokumenten und den Runtime-Dokumenten 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 ausgeben und genügend Metadaten zurückgeben, um Retries und Tracing zu unterstützen. OpenAIs Responses API ist explizit für zustandsbehaftete Interaktionen plus integrierte Tools und Function Calling ausgelegt. Anthropics Messages API offenlegt dieselbe Kernschleife durch tool_use-Blöcke und tool_result-Rückgaben, während Managed Agents Ihnen einen gehosteten Rahmen gibt, wenn Sie die Schleife nicht selbst bauen möchten. Selbst gehostete Runtimes wie vLLM und llama.cpp sind wichtig, weil sie vertraute anbieterähnliche Schnittstellen beibehalten, während sie Ihnen erlauben, Inferenz in Ihrer eigenen Umgebung zu platzieren.

Die Memory-Schicht sollte mental in drei Kategorien unterteilt werden: Working Memory, dauerhaftes symbolisches Memory und durchsuchbares semantisches Memory. OpenAI Embeddings geben Vektoren zurück, die indiziert und durchsucht werden können; OpenAI Retrieval und File Search lagern semantische und Keyword-Suche dann auf Vektorspeicher auf. 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ügen eine nützliche Erinnerung hinzu, dass nicht alles Memory in einen Vektorspeicher gehört: Dateibasierte Notizen, überprüfte Promotionen und sessionspezifische Snapshots sind oft das ehrlichere Design. Memory Systems in AI Assistants kartiert das cross-framework Modell; Hermes Agent Memory System zerlegt begrenztes Kernmemory und eingefrorene Session-Snapshots in einem Produkt.

Die Tooling-Schicht ist der Ort, an dem ein Assistent aufhört, ein Summarizer zu sein, und beginnt, Software zu sein. OpenAI Function Calling behandelt Tools als schemadefinierte 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 selbst aus. MCP generalisiert 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 in MCP Server in Go Schritt für Schritt beschrieben wird. LangChain und LlamaIndex sitzen hier bequem als Orchestrierungsbibliotheken: LangChain konzentriert sich auf eine vorgefertigte Agent-Architektur 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 Provider-Pfad, welchen Tenant, welches Budget, welche Latenzklasse und welchen Fallback?“. LiteLLM ist nützlich, weil seine offiziellen Dokumente erfrischend konkret sind: Weighted pick, least-busy, latenzbasiertes, kostengesteuertes Routing und begrenzte Failovers sind alle First-Class-Patterns. OpenClaw erweitert Routing nach oben in Kanal- und Agent-Isolierung, während Hermes es nach unten in Model-Slots für Haupt- und Nebenarbeiten wie Summarisierung, Kontextkomprimierung 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 übergeht. OpenTelemetry gibt Ihnen die Trace-Abstraktion. LangSmith gibt Ihnen End-to-End-Sichtbarkeit über LLM-Anwendungsschritte und unterstützt Cloud-, Hybrid- und Self-Hosted-Bereitstellungsformen. OpenLIT gibt Ihnen OpenTelemetry-native AI-Observability mit Zero-Code- und manuellen Instrumentierungsoptionen, einschließlich Unterstützung für LLMs, Agent-Frameworks, Vektordatenbanken und GPUs. Für produktionsreife Metriken, Traces und SLO-Patterns ü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 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.

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 Erfassen-Schritt ist meist wichtiger, als er aussieht. OpenClaw und Hermes stellen beide ein persistentes Gateway vor den Assistenten, weil Ingress nicht nur Texteingabe ist. Es beinhaltet Kanal-Metadaten, Identitäten, Autorisierung, Session-Grenzen, Direktnachrichten, Gruppen, Cron-Ticks und Liefersemantik. Wenn Sie diese Schicht überspringen und sich auf eine rohe Chat-Widget-Abstraktion verlassen, werden Sie sie später sowieso 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 Retrieval explizit durch Vektorspeicher und Suchaufrufe. LlamaIndex formalisiert dasselbe Muster durch Data Connectors, Indizes, Query-Engines und Workflows. Hermes geht weiter, indem es das Modell-Portfolio in Haupt- und Neben-Slots aufteilt und Arbeiten wie Komprimierung, Summarisierung und Routing an kleinere oder spezialisierte Modelle auslagert. Das ist ein Entwurfmuster, das es wert ist, gestohlen zu werden: Verwenden Sie Ihre teuersten Modell-Tokens nicht für 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 benötigt, gibt es eine strukturierte Anfrage aus. Anthropics Tool-Use-Vertrag und OpenAIs Function-Calling-Leitfaden machen dies explizit. Der Grund, warum dies architektonisch wichtig ist, ist, dass Outputs nun 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 Session injiziert, um Prefix-Cache-Performance zu erhalten, was bedeutet, dass neue Schreibvorgänge nicht automatisch im aktuellen Session-Prompt erscheinen. OpenClaws Dreaming-System fördert nur überprüfte, fundierte Kandidaten in MEMORY.md, und es ist opt-in und nicht immer aktiv. Die praktische Lektion ist, dass Memory selten wirklich read-after-write über jede Schicht hinweg ist. Sie müssen für gestaffelte Sichtbarkeit entwerfen.

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 langlebiges System mit Gateways, Sessions, Tools, Memory und mehreren Modell-Backends.

Diese Zuordnung basiert auf den offiziellen OpenClaw- und Hermes-Dokumenten und Repos. OpenClaw dokumentiert eine Gateway-Architektur, Multi-Agent-Routing, benutzerdefinierte und selbst gehostete Provider-Unterstützung einschließlich vLLM und Ollama, optionales aktives Memory und Dreaming-basierte Promotion. Hermes dokumentiert ein Messaging-Gateway, einen zentralen AIAgent-Loop, Haupt- und Neben-Model-Slots, eingebautes Memory und native MCP-Integration.

Meine leicht opinionierte Lektüre ist, dass beide Systeme dasselbe architektonische Argument in unterschiedlichen Akzenten machen. OpenClaw ist stark Gateway-first. Hermes ist stark Agent-Loop-first. Aber beide lehnen die flache Idee ab, dass ein Assistent einfach „Prompt plus Modell“ ist. Sie modellieren Kanäle, Identitäten, Memory-Semantik, Tool-Oberflächen und Backend-Heterogenität als First-Class-Aspekte. Das ist genau das, was eine produktionsreife Architektur 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 begründetes Deployment-Pattern und keine vom Vendor vorgegebene Blaupause. Es funktioniert, weil die offiziellen Schnittstellen übereinstimmen: OpenAI und Anthropic offenlegen 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 ganzen Pfad tracken.

Patterns, Tabellen und Tradeoffs

Es gibt einige wiederkehrende Assistenz-Patterns, die es wert sind, benannt zu werden. Ein Managed Assistant hält die meiste Runtime innerhalb von Provider-APIs. Ein Retrieval-first Assistant behandelt Memory und Suche als Hauptunterscheidungsmerkmal. Ein Tool-first Assistant verhält sich eher wie ein Operator als wie ein Chatbot. Ein Gateway Assistant priorisiert den Always-on-Zugriff durch Messaging-Oberflächen. Ein Specialist Mesh zerlegt Arbeit in mehrere Agenten oder Routen. Offizielle Dokumente von OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw und Hermes unterstützen alle Versionen dieser Patterns, auch wenn sie sie anders benennen.

Diese Pattern-Tabelle ist eine Synthese aus Provider-Dokumenten, Framework-Dokumenten und Referenzsystemen und kein Anspruch eines einzelnen Vendors.

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 Hybrid-Betrieb in unterschiedlichem Maße unterstützen.

Tabellenhinweise: Pinecone dokumentiert eine verwaltete Control Plane und regionale Data Planes. Weaviate dokumentiert Vektor- und Inverted-Indexes mit mehreren Vektor-Index-Typen. pgvector fügt exakte und approximative Nearest-Neighbour-Suche zu Postgres hinzu. Milvus positioniert sich als Open-Source-Hochleistungs-, skalierbare Vektordatenbank, mit Zilliz Cloud als verwalteter Option.

Tabellenhinweise: OpenAI dokumentiert Responses als seine fortgeschrittene Schnittstelle für zustandsbehaftete Responses und integrierte Tools. Anthropic dokumentiert die Messages API und den Tool-Use-Vertrag separat von Managed Agents. vLLM offenlegt 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 Dokumenten, kein Vendor-Benchmark. Die Konsistenzzeile ist wichtiger, als viele Blog-Posts zugeben: Pinecone trennt Schreib- und Lesepfade, Hermes friert Memory in Session-Start-Prompts ein, und OpenClaw fördert dauerhaftes Memory durch gestaffelte Überprüfung. Das bedeutet, dass „Memory aktualisiert“ und „Memory für die aktuelle Antwort sichtbar“ oft unterschiedliche Wahrheiten sind.

Fehlermodi und Minderungen

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

Die Evidenzbasis für diese Tabelle ist breit, aber konsistent. Anthropics Tool-Doks machen klar, dass Tool Use eine Vertragsgrenze ist. OpenAI Guardrails beinhaltet Halluzinationserkennung gegen eine Referenz-Wissensdatenbank via File Search. SelfCheckGPT zeigt, dass Selbstkonsistenz über Samples hinweg helfen kann, nicht unterstützte Ansprüche zu erkennen. Die „Lost in the Middle“-Ergebnisse und Anthropics Context Guidance verstärken beide dieselbe operationale Lektion: Mehr Tokens entfernen nicht die Notwendigkeit für Kontext-Kuration.

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 aus, bevor Sie Routen oder Memory-Richtlinien ändern. OpenAIs Evals-Doks und Repo sind direkt darüber, warum: Ohne Evals ist es schwer 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 gehen möchten, sind dies die nützlichsten Primärquellen, die Sie offen halten sollten, während Sie eine Assistenzarchitektur entwerfen oder überprüfen.

• 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-Doks, LiteLLM Routing-Doks, LangSmith Observability-Doks.

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

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

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