So erstellen Sie einen KI-Agenten für Unternehmen: Der vollständige Leitfaden von Null bis zur Produktion

TL;DR – Der Enterprise Agent Blueprint 2026 Ein Demo-Agent ist ein Eingabeaufforderungs- und Suchtool. Ein Produktions-Agent besteht aus 4 Schichten: Speicher/Status → Abruf (RAG / RAG Graph / Knowledge Graph) → Tools (Lesen vs. Schreiben mit menschlicher Zustimmung) → Orchestrierung (LangGraph-Schleife mit begrenztem Wiederholungsversuch + Auswertung). RAG, RAG Graph und Knowledge Graph sind keine separaten Produkte – es handelt sich um drei Abruftools innerhalb eines Agenten, die pro Frage weitergeleitet werden. Erstellungsreihenfolge: einfaches RAG → RAG-Graph-Schleife → Wissensgraph (nur für Beziehungsfragen) → Gated Actions → Bewertung/Beobachtbarkeit – keine vollständige Autonomie am ersten Tag. Stack 2026: LangGraph + Qdrant/Weaviate/pgvector + BGE-M3 + Neo4j + LangMem/Graphiti. Schnelle Definition (für Featured Snippet) Ein Unternehmens-KI-Agent ist eine Denkschleife (Denken → Über Tools handeln → Beobachten → Entscheiden), die auf 4 Ebenen aufgebaut ist: 1) Speicher und Zustand (AgentState), 2) Abruf (RAG / RAG Graph / Knowledge Graph), 3) Tools (typisierte Schemata, Schreibaktionen erfordern menschliche Zustimmung), 4) Orchestrierung (LangGraph Zustandsgraph mit MAX_ITERATIONS + is this actually done? Prüfpunkt). Unternehmensbereitschaft = Datenresidenz + Auswertung + Beobachtbarkeit + Kosten – vom ersten Tag an konzipiert.

Warum das im Jahr 2026 wichtig ist: Die Rückholung ist der Agentenfehler Nr. 1 – nicht das LLM. Teams, die ein „größeres Modell“ anstelle einer besseren Abrufarchitektur liefern, liefern fragile Agenten. Dieser lebende Leitfaden (zuletzt überprüft im August 2026) verbindet unseren RAG Graph und Knowledge Graph und taucht tief in ein Zero-to-Enterprise-System mit Code-Skelett, Open-Source-GitHub-Stack pro Ebene und einer Build-Reihenfolge ein Vermeiden Sie es, für Komplexität zu zahlen, die Sie nicht verdient haben.

---

Inhaltsverzeichnis

• Teil 1: Was „Agent“ eigentlich bedeutet

• Teil 2: Die vier Schichten, die jeder echte Agent braucht

• Teil 3: Schicht 1 – Speicher und Zustand

• Teil 4: Schicht 2 – Abruf (Was der Agent tatsächlich weiß)

• Teil 5: Ebene 3 – Tools (Was der Agent tatsächlich tun kann)

• Teil 6: Ebene 4 – Orchestrierung (der eigentliche Arbeitsablauf)

• Teil 7: Den gesamten Agenten zusammensetzen

• Teil 8: Unternehmensspezifische Bedenken

• Teil 9: Der Open-Source-Stack, der jeder Ebene zugeordnet ist

• Teil 10: Eine realistische Baureihenfolge

• Teil 11: Pre-Launch-Checkliste

• Glossar

• Quellen und weiterführende Literatur

• Wichtige Erkenntnisse

---

Der erste „Agent“ der meisten Menschen ist ein Chatbot mit einer Systemeingabeaufforderung und Zugriff auf ein Suchtool. Es funktioniert in einer Demo. Es zerfällt in dem Moment, in dem jemand etwas fragt, das mehr als einen Schritt erfordert, oder in dem Moment, in dem es eine Entscheidung treffen muss, anstatt nur eine Frage zu beantworten.Ein Agent, der tatsächlich funktioniert – also ein Agent, dem man vertrauen kann, dass er in einem Unternehmen arbeitet, auf echten Daten basiert und echte Entscheidungen trifft –, ist eine völlig andere Art von System. In diesem Leitfaden wird ein System von Grund auf erstellt und dabei alles verwendet, was eine echte Unternehmensbereitstellung tatsächlich benötigt: nicht nur ein LLM mit einer Eingabeaufforderung, sondern auch Speicher, Tools, Abruf, Überprüfung und das Urteilsvermögen, um zu erkennen, wenn etwas nicht bekannt ist.

Am Ende handelt es sich bei den RAG-, RAG-Graph- und Knowledge Graph-Konzepten, die Sie vielleicht bereits kennen, nicht mehr um drei separate Systeme, sondern um drei Tools in der Toolbox eines Agenten, und Sie wissen genau, wann der Agent nach welchem ​​greifen sollte. Kurz gesagt: Ein Produktionsagent besteht aus vier Ebenen – Speicher/Status, Abruf, Tools und Orchestrierung – und nicht aus einer Eingabeaufforderung mit angehängtem Suchtool. RAG, RAG Graph und Knowledge Graph befinden sich alle in der Abrufschicht und werden auf der Grundlage der gestellten Frage ausgewählt und nicht pauschal übernommen. Schreibaktionen erfordern die Zustimmung des Menschen; ein explizites „Ist das tatsächlich gemacht?“ Checkpoint verhindert sowohl vorzeitiges Stoppen als auch Endlosschleifen; und die Bereitschaft des Unternehmens (Datenspeicherung, Auswertung, Beobachtbarkeit, Kosten) muss vom ersten Tag an geplant werden und darf nicht nach einem Vorfall nachgerüstet werden. Dieser Leitfaden behandelt die gesamte Architektur, ein funktionierendes Code-Skelett, einen Open-Source-Stack für jede Ebene und eine Build-Reihenfolge, die eine zusätzliche Komplexität vermeidet, bevor sie überhaupt erreicht wird.

Letzte Überprüfung: August 2026. Dieser Leitfaden dient als lebendige Referenz – die Architekturprinzipien sind stabil; Der Open-Source-Stack-Abschnitt (Teil 9) ist der Teil, der im Zuge der Weiterentwicklung der Tools am wahrscheinlichsten aktualisiert werden muss.

---

Teil 1: Was „Agent“ tatsächlich bedeutet (und was nicht)

Bevor Sie etwas aufbauen, sollten Sie sich über ein Wort im Klaren sein, das häufig verwendet wird.

Ein Chatbot mit Systemaufforderung beantwortet Fragen. Du fragst, es antwortet, das Gespräch ist beendet. Es hat keine Erinnerung an Entscheidungen, keine Fähigkeit, mehrstufige Maßnahmen zu ergreifen und keine Möglichkeit zu überprüfen, ob die eigene Antwort tatsächlich richtig war.

Ein Agent macht etwas ganz anderes: Er kann entscheiden, was zu tun ist, Aktionen mithilfe von Werkzeugen ergreifen, die Ergebnisse dieser Aktionen beobachten und basierend auf dem, was er gerade gelernt hat, entscheiden, was als nächstes zu tun ist – in einer Schleife, bis die Aufgabe tatsächlich abgeschlossen ist, und nicht nur, bis sie eine plausibel klingende Antwort erzeugt.

Task
  ↓
Think: what does this need?
  ↓
Act: use a tool
  ↓
Observe: what came back?
  ↓
Think again: is this enough?  ──No──→ Act again
  ↓ Yes
Respond

Diese Schleife – oft als Argumentationsschleife oder formeller als Muster wie ReAct (Reason + Act) bezeichnet – ist die eigentliche Definition eines Agenten. Bei allem anderen in diesem Leitfaden geht es darum, diese Schleife zuverlässig, sicher und nützlich genug zu machen, um sie bei echter Arbeit anvertrauen zu können.

Warum „Unternehmensebene“ die Anforderungen ändert

Ein Wochenend-Agentenprojekt muss einmal für Sie in einer Demo funktionieren. Ein Unternehmensagent muss:

• Arbeiten Sie korrekt an Fragen, die Sie noch nie gesehen haben, nicht nur an denen, die Sie getestet haben.

• Sicher und sichtbar scheitern, statt selbstbewusst eine falsche Antwort zu geben.

• Respektieren Sie Datengrenzen – wer was sehen kann und wo die Daten gespeichert werden dürfen.

• Seien Sie debuggbar, wenn etwas schief geht, auch Wochen nachdem es schief gelaufen ist.

• Umgang mit Unordnung in der realen Welt: unvollständige Informationen, mehrdeutige Anfragen, widersprüchliche Quellen.

In jedem Abschnitt weiter unten geht es speziell um diese fünf Anforderungen, nicht nur um „einen Agenten, der reagiert“.

---

Teil 2: Die vier Ebenen, die jeder echte Agent braucht

Wenn Sie die spezifischen Technologieoptionen weglassen, besteht jeder Agent in Produktionsqualität aus vier übereinander gestapelten Schichten.

┌─────────────────────────────────────┐
│   4. Orchestration (the workflow)    │
├─────────────────────────────────────┤
│   3. Tools (what it can DO)          │
├─────────────────────────────────────┤
│   2. Retrieval (what it KNOWS)       │
├─────────────────────────────────────┤
│   1. Memory & State (what it        │
│      REMEMBERS)                      │
└─────────────────────────────────────┘

Wir bauen dies von unten nach oben auf, da jede Schicht von der darunter liegenden Schicht abhängt.

---

Teil 3: Schicht 1 – Speicher und Zustand

Ein Agent ohne Gedächtnis leitet bei jedem einzelnen Schritt alles von Grund auf neu ab, was langsam und teuer ist und den Überblick darüber verliert, was er bereits vor drei Schritten herausgefunden hat. Echte Agenten tragen den Staat.

Zwei verschiedene Arten von Erinnerungen, und sie lassen sich leicht zusammenführenKurzzeitgedächtnis (Arbeitsgedächtnis) ist der Zustand der aktuellen Aufgabe – was gefragt wurde, was versucht wurde, was bisher gefunden wurde, was noch fehlt. Dies bleibt nur für die Dauer einer Aufgabe bestehen und verschwindet, wenn sie erledigt ist.

Das Langzeitgedächtnis bleibt über mehrere Sitzungen hinweg vollständig bestehen – Fakten, an die sich der Agent über einen Benutzer, ein Projekt oder eine Kundenbeziehung Tage oder Monate später erinnern sollte.

Auf Codeebene wird dies normalerweise als Statusobjekt implementiert, das zwischen jedem Schritt des Agenten-Workflows übergeben und dabei aktualisiert wird:

AgentState:
  original_task: "..."
  steps_taken: [...]
  evidence_gathered: [...]
  tools_called: [...]
  current_confidence: "sufficient" | "insufficient"

Dieses Zustandsobjekt ist das Rückgrat, an das alles andere angehängt ist. Jeder Tool-Aufruf liest daraus und schreibt darauf zurück. Ohne sie hat ein Agent keine Möglichkeit zu wissen, dass er bereits etwas versucht hat, oder auf einer Teilantwort aufzubauen, anstatt von vorne zu beginnen.

---

Teil 4: Ebene 2 – Abruf (Was der Agent tatsächlich weiß)

Hier hören die früheren Deep Dives zu RAG, RAG Graph und Knowledge Graphs auf, separate Blogbeiträge zu sein, sondern werden zu Komponenten, aus denen Sie auswählen, basierend auf der Art von Wissen, auf die Ihr Agent zugreifen muss.

Nicht jeder Agent braucht alle drei

Dies ist der häufigste Fehler bei der Entwicklung von Agenten: Sie greifen auf die fortschrittlichste verfügbare Abrufarchitektur zurück und nicht auf die, die die eigentliche Aufgabe benötigt.

Wenn Ihr Agent ...	Greifen Sie nach...
Beantworten Sie Fragen aus einem Dokumentensatz, Passage für Passage	Einfacher Lappen
Beantworten Sie mehrteilige oder vergleichende Fragen über viele Dokumente hinweg	Ein RAG-Diagramm
Beantworten Sie Beziehungsfragen („welche“, „wie viele“, „verfolgen Sie die Verbindung“)	Ein Knowledge Graph, auch als Werkzeug bezeichnet
Alle oben genannten Punkte, abhängig von der Frage	Ein RAG-Graph, der sowohl einen Vektorspeicher als auch einen Wissensgraphen aufrufen kann

Deep Dives verlinkt: Einfacher RAG- und RAG-Graph-Workflow (Zerlegung, Beweisvalidierung, Wiederholung) → Innerhalb eines RAG-Graphen: Wie KI-Systeme lernen, ihre eigene Arbeit zu überprüfen · Beziehungsdurchquerung und Entitätsauflösung → Wissensgraphen erklärt: Wie KI lernt, die zu verbinden Punkte · Vollständige Taxonomie → RAG, RAG Graph und Knowledge Graph nicht mehr verwirren

Die Abrufschicht ist nicht „der Agent“. Es ist eines der Tools des Agenten – dasjenige, das speziell für die Antwort „Was weiß ich eigentlich darüber?“ verantwortlich ist. Alles aus den früheren Leitfäden – Chunking, Einbettungen, Entitätsauflösung, Beweisvalidierung – befindet sich in dieser einen Ebene.

Agent's Retrieval Tool
        ↓
  Question Analysis
        ↓
   ┌────┴────┐
   ↓         ↓
Vector    Knowledge
Search      Graph
   ↓         ↓
   └────┬────┘
        ↓
  Evidence Validation
        ↓
   Grounded Facts

Dieser ganze Block – alles, was in den früheren RAG Graph- und Knowledge Graph-Anleitungen behandelt wurde – ist aus Sicht des Agenten ein einziger Toolaufruf. Der Agent muss nicht wissen, wie der Abruf intern funktioniert; Es muss nur wissen, dass es diesem Tool eine Frage stellen kann und fundierte Fakten zurückbekommt, oder ein ehrliches „Nicht genügend Beweise gefunden“.

---

Teil 5: Ebene 3 – Tools (Was der Agent tatsächlich tun kann)

Retrieval beantwortet Fragen. Tools ergreifen Maßnahmen. Ein Enterprise-Agent, der nur Fragen beantworten kann, ist immer noch nur ein intelligenteres Suchfeld. Der Schritt, der daraus etwas macht, das „für Sie funktioniert“, besteht darin, ihm die Möglichkeit zu geben, tatsächlich Dinge zu tun – eine E-Mail zu senden, ein Ticket zu erstellen, eine Live-Datenbank abzufragen, eine interne API aufzurufen, einen Datensatz zu aktualisieren.

Entwerfen von Tools, die ein Agent tatsächlich gut nutzen kann

Für jedes Tool müssen drei Dinge klar definiert sein, sonst wird der Agent es missbrauchen:

• Eine genaue Beschreibung dessen genau, was es tut und wann es verwendet werden soll – vage Beschreibungen führen dazu, dass ein Agent das falsche Tool oder das richtige Tool mit falschen Eingaben aufruft.

• Ein enges, gut typisiertes Eingabeschema – der Agent sollte nie raten müssen, welches Format ein Tool erwartet.

• Eine vorhersehbare, strukturierte Ausgabe – wenn ein Tool manchmal Text und manchmal JSON zurückgibt und manchmal stillschweigend fehlschlägt, kann der Agent seine Ausgabe im nächsten Schritt nicht zuverlässig verwenden.

Der entscheidende Unterschied: Lese-Tools vs. Schreib-ToolsDies ist insbesondere für Unternehmensbereitstellungen von enormer Bedeutung:

• Lese-/Abruftools (Wissensdatenbank durchsuchen, einen Datensatz nachschlagen, Status überprüfen) sind im Allgemeinen sicher, sodass ein Agent frei anrufen kann – es hat keine realen Konsequenzen, wenn er jemanden unnötig anruft.

• Schreib-/Aktionstools (E-Mail senden, einen Datensatz löschen, eine Anfrage genehmigen, Geld ausgeben) benötigen vor der Ausführung einen Human-in-the-Loop-Kontrollpunkt, insbesondere zu Beginn der Lebensdauer einer Bereitstellung. Der Agent schlägt die Aktion vor; ein Mensch bestätigt es; Erst dann wird es ausgeführt.

Agent decides: "I should send this email"
        ↓
  Draft prepared, NOT sent
        ↓
  Human reviews
        ↓
  ┌─────┴─────┐
  ↓           ↓
Approve     Reject
  ↓           ↓
Sent      Agent revises

Diese einzelne Designentscheidung ist oft der Unterschied zwischen einem Agententeam, das tatsächlich der Produktion vertraut, und einem Team, das nach dem ersten peinlichen Fehler abgeschaltet wird.

---

Teil 6: Ebene 4 – Orchestrierung (der eigentliche Arbeitsablauf)

Dies ist die Ebene, die Gedächtnis, Abruf und Werkzeuge in der Argumentationsschleife aus Teil 1 miteinander verbindet – und es handelt sich um genau dieselbe Kategorie wie das RAG-Diagramm von früher, nur angewendet auf eine umfassendere Aufgabe als „eine Frage beantworten“. Dies wird am häufigsten mit einem diagrammbasierten Workflow-Framework erstellt (LangGraph ist hier die Standardwahl), da das Verhalten eines echten Agenten keine gerade Linie ist – es verzweigt, schleift und ändert sich basierend auf dem, was er bei jedem Schritt lernt.

Task Received
      ↓
Understand & Plan
      ↓
   ┌──┴───────────────┐
   ↓                  ↓
Need info?         Need action?
   ↓                  ↓
Call retrieval     Call a tool
   ↓                  ↓
   └────────┬─────────┘
            ↓
    Evaluate progress
            ↓
   Task actually done?
      /              No            Yes
    ↓              ↓
  Loop back     Respond

Warum der Bewertungsschritt nicht optional ist

Genau wie der Beweisvalidierungsschritt in einem RAG-Diagramm benötigt ein Unternehmensagent einen expliziten Prüfpunkt, der fragt: Ist die Aufgabe tatsächlich abgeschlossen, oder sieht sie nur erledigt aus? Ohne dies verfügen Agenten über einen gut dokumentierten Fehlermodus, bei dem sie den Erfolg vorzeitig verkünden – sie stoppen nach einem Teilergebnis, weil sie nichts gezwungen hat, ihre eigene Arbeit zu überprüfen.

Hier kommt es auch auf begrenzte Wiederholungsversuche an. Ein Agent, der in einer unproduktiven Schleife feststeckt und ständig dasselbe Tool mit leicht unterschiedlichen Eingaben aufruft, ist ein echter und häufiger Fehlermodus. Jede Schleife benötigt eine maximale Iterationsanzahl und einen definierten Fallback: Wenn der Agent die Aufgabe nach N Versuchen nicht abschließen kann, sollte er dies deutlich sagen, anstatt entweder eine ewige Schleife zu durchlaufen oder ein Ergebnis zu erfinden, um der Schleife zu entkommen.

So sieht das als tatsächlicher Code aus

Das obige Diagramm wird direkt auf eine LangGraph-Zustandsmaschine abgebildet. Dies ist ein minimales Grundgerüst – echte Produktionsknoten würden Ihre tatsächlichen Abruf- und Werkzeugfunktionen aufrufen, aber die Form unten ist das gesamte Muster:

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END
class AgentState(TypedDict):
    task: str
    steps_taken: list
    evidence: list
    iterations: int
    done: bool
MAX_ITERATIONS = 5
def plan(state: AgentState) -> AgentState:
    # LLM decides: retrieve more info, call a tool, or respond
    ...
    return state
def retrieve(state: AgentState) -> AgentState:
    # Calls the retrieval layer (RAG / RAG Graph / Knowledge Graph tool)
    ...
    return state
def call_tool(state: AgentState) -> AgentState:
    # Write actions pause here for human approval before executing
    ...
    return state
def evaluate(state: AgentState) -> AgentState:
    # The "is this actually done?" checkpoint from above
    state["iterations"] += 1
    ...
    return state
def route_after_evaluate(state: AgentState) -> Literal["plan", "respond"]:
    if state["done"] or state["iterations"] >= MAX_ITERATIONS:
        return "respond"
    return "plan"  # loop back — bounded by MAX_ITERATIONS
graph = StateGraph(AgentState)
graph.add_node("plan", plan)
graph.add_node("retrieve", retrieve)
graph.add_node("call_tool", call_tool)
graph.add_node("evaluate", evaluate)
graph.add_node("respond", lambda s: s)
graph.set_entry_point("plan")
graph.add_edge("plan", "retrieve")
graph.add_edge("plan", "call_tool")
graph.add_edge("retrieve", "evaluate")
graph.add_edge("call_tool", "evaluate")
graph.add_conditional_edges("evaluate", route_after_evaluate, {
    "plan": "plan",
    "respond": "respond",
})
graph.add_edge("respond", END)
agent = graph.compile()

Musterverknüpfung: Dieses LangGraph-Skelett spiegelt den RAG Graph-Workflow (Validierung + begrenzter Wiederholungsversuch) wider – dasselbe Diagrammmuster, breiteres Toolset.

Die beiden Details, die Sie beim Erstellen der echten Version nicht überspringen sollten: MAX_ITERATIONS ist das, was „Schleife bis fertig“ in „Schleife bis fertig oder bis es ehrlich ist, nicht fertig zu sein“ umwandelt – versenden Sie niemals eine Schleife ohne dies. Und call_tool ist der Ort, an dem der menschliche Genehmigungskontrollpunkt aus Teil 5 für jede Schreibaktion hingehört – in LangGraph wird dies normalerweise mit einem Interrupt implementiert, der das Diagramm anhält und auf eine externe Bestätigung wartet, bevor der Knoten abgeschlossen wird.

---

Teil 7: Den gesamten Agenten zusammensetzen

Hier ist die vollständige Architektur, alle vier Schichten in einem System zusammengefasst:

                    ┌─────────────────────┐
                    │   Incoming Task      │
                    └──────────┬───────────┘
                               ↓
                    ┌─────────────────────┐
                    │  ORCHESTRATION        │
                    │  (plan, loop, decide)  │
                    └──────────┬───────────┘
                               ↓
              ┌────────────────┼────────────────┐
              ↓                                  ↓
   ┌─────────────────────┐          ┌──────────────────────┐
   │   RETRIEVAL LAYER     │          │      TOOLS LAYER       │
   │  ┌─────┐  ┌────────┐ │          │  Read tools (free)     │
   │  │ RAG │  │Knowledge│ │          │  Write tools (needs    │
   │  │     │  │  Graph  │ │          │  human approval)       │
   │  └─────┘  └────────┘ │          └──────────────────────┘
   └─────────────────────┘
              ↓                                  ↓
              └────────────────┬─────────────────┘
                               ↓
                    ┌─────────────────────┐
                    │  STATE / MEMORY       │
                    │  (tracks everything    │
                    │   across the whole      │
                    │   task)                 │
                    └──────────┬───────────┘
                               ↓
                    ┌─────────────────────┐
                    │  Task complete?        │
                    │  No → loop back         │
                    │  Yes → respond          │
                    └─────────────────────┘

Beachten Sie, was dieses Diagramm tatsächlich zeigt: Der RAG-Graph und der Knowledge Graph aus den früheren Leitfäden stellen nicht das gesamte System dar – sie sind eine Box in einem größeren. Der Agent ist die Orchestrierungsebene um sie herum und entscheidet, wann das Abrufen überhaupt der richtige Schritt ist und wann stattdessen eine Aktion ausgeführt werden muss.

---

Teil 8: Die unternehmensspezifischen Bedenken, die niemand in Tutorials äußert

Hier hören die meisten Agenten-Tutorials auf und die meisten realen Bereitstellungen leben oder sterben.

Datenspeicherort und Ort der VerarbeitungFür regulierte Branchen (Recht, Gesundheitswesen, Finanzen) oder alle Organisationen, die der DSGVO unterliegen, ist der Ort, an dem die einzelnen Ebenen ausgeführt werden, ebenso wichtig wie ihre Funktionsweise. Das Selbsthosten der Abrufschicht – das Ausführen Ihres eigenen Einbettungsmodells, Ihrer eigenen Vektordatenbank, Ihres eigenen fein abgestimmten Extraktionsmodells, Ihrer eigenen Neo4j-Instanz auf einer von Ihnen kontrollierten Infrastruktur – bedeutet, dass Kundendaten zu keinem Zeitpunkt Ihre Grenzen verlassen. Dies ist eine echte architektonische Entscheidung, kein nachträglicher Einfall: Sie entscheidet darüber, ob Sie bestimmte Kunden überhaupt bedienen können.

Bewertung – woher wissen Sie, dass es tatsächlich funktioniert?

Ein Agent, der in Gelegenheitstests „zu funktionieren scheint“, und ein Agent, der ordnungsgemäß bewertet wurde, weisen sehr unterschiedliche Grade der Vertrauenswürdigkeit auf. Ein echtes Bewertungsset bedeutet:

• Eine kuratierte Sammlung realistischer Aufgaben mit bekanntermaßen korrekten Ergebnissen, mit denen der Agent bevor jede sinnvolle Änderung ausgeliefert wird.

• Verfolgen Sie nicht nur „hat es die richtige Antwort bekommen“, sondern auch „hat es richtig erkannt, wann es nicht genügend Informationen hatte“ – ein Agent, der nie „Ich weiß nicht“ sagt, ist nicht kompetenter, sondern weniger ehrlich.

• Führen Sie diesen Evaluierungssatz regelmäßig und nicht nur einmal beim Start aus, da kleine Änderungen an einer Eingabeaufforderung oder einem Tool das Verhalten an anderer Stelle stillschweigend beeinträchtigen können.

Beobachtbarkeit – was passiert, wenn um 2 Uhr morgens etwas schief geht

Siehe: Vollständige Einrichtung von Ablaufverfolgung/Bewertungen/Drift in LLM Observability in Production – die Disziplin, die stille Qualitätsabweichungen auffängt, bei denen Dashboards grün bleiben.

Jeder Zustandsübergang, jeder Tool-Aufruf, jeder Abruf und jeder Entscheidungspunkt müssen so protokolliert werden, dass ein Mensch sie im Nachhinein rekonstruieren kann. Das ist der Unterschied zwischen „Der Agent hat einen Fehler gemacht und wir können genau sehen, warum“ und „Der Agent hat einen Fehler gemacht und wir haben keine Ahnung, was passiert ist.“ Ein nur anfügbares, abspielbares Protokoll aller Schritte, die ein Agent bei einer bestimmten Aufgabe unternommen hat – nicht nur der endgültigen Antwort – ist auf Unternehmensebene kein nettes Extra; Es ist das, was das System überhaupt debuggbar macht.

Kosten, bei tatsächlichem Nutzungsvolumen

Ein Agent, der mehrere Tools pro Aufgabe wiederholt, erneut versucht und aufruft, kann weit mehr LLM-Anrufe pro Benutzeranfrage tätigen als ein einfacher Chatbot. Bevor Sie eine umfassende Bereitstellung durchführen, messen Sie tatsächlich Folgendes: Wie viele LLM-Aufrufe dauert eine typische Aufgabe Ende-zu-Ende? Was kostet das bei erwartetem Nutzungsvolumen? Dies ist derselbe Durchsatz- und Kostengedanke, der beim Aufbau der Extraktionspipeline des Wissensgraphen von Bedeutung ist: Kennen Sie Ihre tatsächlichen Zahlen, bevor Sie skalieren, nicht danach.

---

Teil 9: Der Open-Source-Stack, zugeordnet zu jeder Ebene

Alles darüber ist Architektur. Dieser Abschnitt ist die eigentliche Toolbox – echte, selbsthostbare Open-Source-Optionen für jede der vier Schichten, daher ist dies nicht mehr theoretisch.

Orchestrierungsebene

LangGraph ist die Standardauswahl für genau den in Teil 6 beschriebenen Verzweigungs-, Schleifen- und Zustandsbehafteten Workflow – es handelt sich um ein graphbasiertes Orchestrierungsframework, das speziell für dieses Muster entwickelt wurde, und nicht um einen allgemeinen Agenten-Wrapper. Wissenswerte Alternativen: CrewAI (rollenbasierte Multi-Agenten-Teams, schnellere Prototypenerstellung, weniger feinkörnige Kontrolle über die Verzweigungslogik) und AutoGen (Microsofts Multi-Agenten-Konversationsframework). Für die meisten Einzelagenten-Unternehmensworkflows mit echter Verzweigungs- und Wiederholungslogik ist LangGraph nach wie vor die direkteste Lösung.

Retrieval-Ebene – VektorsucheFür die selbstgehostete Vektorsuche ist Qdrant ein leistungsstarker, betrieblich effizienter Ausgangspunkt für selbstgehostete Bereitstellungen mit einem einzelnen Knoten – eine einzelne Binärdatei, geringe Abfragelatenz und eine saubere API, weshalb sie wiederholt in Compliance-empfindlichen Bereitstellungen angezeigt wird, bei denen Einbettungen innerhalb eines sicheren Perimeters mit einem lokal bereitgestellten Modell generiert werden, sodass keine Daten zurückbleiben das Gebäude in jedem Stadium. Weaviate ist die stärkste Alternative, wenn Sie hybride Such- und Reranking-Module in die Datenbank selbst und nicht als separate Dienste integrieren möchten, und Milvus ist insbesondere im Milliarden-Vektor-Maßstab eine Überlegung wert. Wenn Sie PostgreSQL bereits verwenden, behält pgvector die Einbettungen in derselben Datenbank wie der Rest Ihrer Daten bei und tauscht dabei etwas Rohleistung gegen Transaktionskonsistenz und ein weniger zu betreibendes System ein.

Für Einbettungen werden selbsthostbare Modelle wie BGE-M3 oder nomic-embed-text lokal über Ollama oder sentence-transformers ausgeführt, sodass keine API-Kosten pro Aufruf anfallen oder dass Daten Ihre Infrastruktur verlassen – direkt relevant, wenn die Datenresidenz eine zwingende Anforderung ist.

Für das Reranking ist BGE-reranker (offene Gewichtungen, selbsthostbar) die standardmäßige Open-Source-Cross-Encoder-Wahl; Cohere Rerank ist die entsprechende verwaltete Option, wenn Selbsthosting nicht erforderlich ist.

Retrieval-Ebene – Aufbau eines Wissensgraphen

Hier sind die Werkzeuge am schnellsten ausgereift. Ein paar wirklich unterschiedliche Optionen, nicht nur konkurrierende Marken mit der gleichen Idee:

• Das GraphRAG-Ökosystem von Neo4j (das neo4j-graphrag-python-Paket plus der LLM Knowledge Graph Builder) ist der Erstanbieterpfad, wenn Sie sich bereits für Neo4j als Ihre Diagrammdatenbank entschieden haben – es übernimmt Chunking, Entitäts-/Beziehungsextraktion und Laden in einer Pipeline, mit einer Referenz-Benutzeroberfläche zur Visualisierung dessen, was extrahiert wurde.

• LightRAG ist eine leichtere Alternative, die Dokumente aufteilt, ein LLM zum Extrahieren von Entitäten und Beziehungen verwendet, das Diagramm erstellt und Diagrammdurchquerung mit Vektorabruf automatisch kombiniert. Insbesondere in Ihrem Fall unterstützt es Open-Source-Modelle für jeden Schritt, sodass die Extraktion vollständig auf der lokalen Infrastruktur ausgeführt werden kann, um sensible Daten vor Ort zu behalten, und ab März 2026 unterstützt es Neo4j, MongoDB, PostgreSQL und OpenSearch als Speicher-Backends.

• Microsoft GraphRAG ist die umfangreichere, eher akademisch fundierte Option – besser geeignet für die Erstellung von Zusammenfassungen auf Community-Ebene über große Diagramme, aber es muss das gesamte Diagramm neu gruppieren, wenn neue Daten eintreffen, was wichtig ist, wenn Sie häufige inkrementelle Aktualisierungen anstelle regelmäßiger vollständiger Neuerstellungen durchführen.

Speziell für die Extraktionsqualität: Ein unabhängiges Benchmarking zu domänenspezifischen Überlegungen ergab eine echte Streuung der Konstruktionskosten und der Qualität zwischen diesen Tools – LightRAG und GraphRAG zeigten beide im Vergleich zu Methoden wie HippoRAG oder G-Retriever hohe Token-Kosten für die Graphenerstellung, daher lohnt es sich, einen Pilotversuch mit einer realen Stichprobe Ihrer Dokumente durchzuführen, bevor Sie sich auf ein vollständiges Dokument festlegen, genau wie in Teil 3 des Knowledge Graph-Leitfadens beschrieben.

Speicherschicht

Diese Kategorie ist wirklich in verschiedene Tools unterteilt, je nachdem, was „Speicher“ für Ihren Agenten bedeuten muss – es lohnt sich, nicht auf das Tool zu setzen, über das am meisten gesprochen wird, da sie unterschiedliche Probleme lösen:

• LangMem ist die natürliche erste Wahl, wenn Ihre Orchestrierung bereits LangGraph ist – die Integration ist ein Erstanbieter-SDK und kein Drittanbieter-Plugin, sodass keine neue Infrastruktur oder Anbieterbeziehung hinzugefügt wird. Der Nachteil besteht in einer echten Ökosystembindung und einem engeren Funktionsumfang als bei den unten aufgeführten eigenständigen Optionen.- Mem0 ist die am weitesten verbreitete eigenständige Option, die Vektor-, Diagramm- und Schlüsselwertspeicherung mit automatischer Speicherextraktion kombiniert – eine sinnvolle Standardeinstellung für allgemeine Zwecke, wenn Sie möchten, dass sich ein Agent Benutzerpräferenzen und Fakten über Sitzungen hinweg ohne tiefe zeitliche Überlegungen merkt.

• Graphiti (erstellt vom Zep-Team) ist die richtige Wahl, insbesondere wenn sich Fakten im Laufe der Zeit wirklich ändern und die Geschichte wichtig ist – jede Kante trägt ein Gültigkeitsintervall, sodass Fakten wie die Rolle einer Person, die sich im Laufe der Zeit von einem Unternehmen zum anderen ändert, korrekt behandelt werden. Dabei handelt es sich um eine Funktion, die sich deutlich von den anderen Optionen unterscheidet, und nicht nur um eine Variante derselben Sache.

• Cognee positioniert sich als modularere, graphnative Speicher-Engine – zusammensetzbare Pipelines für die Aufnahme und Abfrage von Speicher, mit Unterstützung für mehrere Graph-Backends. Eine Prüfung lohnt sich, wenn Sie statt eines festen Schemas mehr architektonische Kontrolle über die Struktur des Speichers wünschen.

• Letta (ehemals MemGPT) eignet sich am besten für lang laufende Agenten, die eine explizite Speicherschichtung im Betriebssystemstil benötigen – sie entscheidet, was im aktiven Kontext bleibt und was in den längerfristigen Speicher verschoben wird, anstatt den Speicher als einen flachen Speicher zu behandeln.

Für Ihre spezifische Situation – selbstgehostet, DSGVO-orientiert, bereits LangGraph-nativ – ist der praktische Ausgangspunkt LangMem für das Kurzzeit-/Arbeitsgedächtnis (da es bereits nativ in Ihrer Orchestrierungsebene ist) plus Graphiti oder Cognee für das Langzeitgedächtnis, wenn die Anwendungsfälle Ihrer Kunden Fakten beinhalten, die sich im Laufe der Zeit ändern (Vertragsänderungen, Fallstatusaktualisierungen, sich entwickelnde Kundenbeziehungen) – beide sind vollständig Open Source und Selbsthostbar, keine Cloud-Abhängigkeit erforderlich.

Eine ehrliche Warnung, bevor Sie etwas auswählen

Einige Frameworks sind Open-Core-Frameworks mit erweiterten Funktionen – insbesondere Knowledge-Graph-Funktionen –, die hinter kostenpflichtigen Stufen verborgen sind. Überprüfen Sie daher, was tatsächlich in der Lizenz enthalten ist, unter der Sie sich selbst hosten möchten, bevor Sie Architekturentscheidungen für ein bestimmtes Tool treffen. Dies ist eine Fünf-Minuten-Prüfung, die einen späteren Neuaufbau erspart.

---

Teil 10: Eine realistische Baureihenfolge

Hier ist die Reihenfolge, die tatsächlich funktioniert: von einem funktionierenden Prototyp zu etwas, das für Unternehmen geeignet ist, ohne zu früh unnötige Komplexität aufzubauen.

1. Beginnen Sie mit einem einzigen Tool und ohne Schleife. Nur Abrufen, einfaches RAG, Beantworten von Fragen aus Dokumenten. Machen Sie dies wirklich zuverlässig, bevor Sie etwas anderes hinzufügen. 2. Fügen Sie die Argumentationsschleife hinzu, aber behalten Sie sie für schreibgeschützte Tools bei. Lassen Sie den Agenten entscheiden, wann er abruft und ob er genug hat – das ist das RAG-Graph-Muster von früher, und es lohnt sich, es alleine zu beherrschen, bevor Sie Aktionstools hinzufügen. 3. Fügen Sie einen Wissensgraphen als Abruftool hinzu (Neo4j + GraphRAG / LightRAG), erst wenn Sie echte Fragen beobachtet haben, die der einfache Abruf strukturell nicht beantworten kann – siehe Build-Blueprint in Knowledge Graphs Erklärt – Beziehungsfragen, nicht nur Nachschlagefragen. 4. Fügen Sie Schreib-/Aktionstools hinzu, die der menschlichen Zustimmung unterliegen. Lassen Sie den Agenten nicht selbstständig Folgemaßnahmen ergreifen, bis Sie in den früheren Phasen echtes Vertrauen in sein Urteilsvermögen aufgebaut haben. 5. Fügen Sie Auswertung und Beobachtbarkeit hinzu, bevor Sie die Nutzung skalieren – nicht, nachdem etwas schief gelaufen ist. Dies ist die Phase, die die meisten Teams überspringen und die darüber entscheidet, ob Probleme frühzeitig erkannt werden oder von einem verärgerten Kunden entdeckt werden. 6. Erwägen Sie nur dann vollständige Autonomie für Schreibaktionen und nur für die spezifischen, engen Aktionskategorien, bei denen die Kosten eines Fehlers wirklich gering sind.

---

Teil 11: Checkliste vor dem StartEine komprimierte, praktische Checkliste – verwenden Sie diese, um einen Agenten zu prüfen, bevor er echten Benutzern präsentiert, und nicht nur als Lesezusammenfassung.

Architektur

• [ ] Jedes Tool verfügt über eine genaue Beschreibung, ein eng typisiertes Eingabeschema und eine vorhersehbare strukturierte Ausgabe.

• [ ] Lesetools und Schreibtools werden im Code explizit getrennt, nicht nur in der Dokumentation.

• [ ] Jedes Schreib-/Aktionstool erfordert vor der Ausführung eine menschliche Genehmigung.

• [ ] Die Orchestrierungsschleife hat eine feste maximale Iterationsanzahl mit einer definierten, ehrlichen Fallback-Antwort.

• [ ] Es gibt ein explizites „Ist diese Aufgabe tatsächlich abgeschlossen?“ Knoten – Der Agent behandelt „eine Ausgabe erzeugt“ niemals als gleichbedeutend mit „die Aufgabe gelöst“.

Abruf

• [ ] Sie haben bestätigt, welches Retrieval-Tool (Vektorsuche, Wissensgraph oder beides) tatsächlich zu den tatsächlichen Fragen Ihrer Benutzer passt, basierend auf der beobachteten Nutzung und nicht auf Annahmen.

• [ ] Die Validierung von Beweisen erfolgt als eigenständiger Schritt vor der Generierung; Der Agent kann sagen: „Nicht genügend Informationen“, anstatt immer zu antworten.

• [ ] Wenn Sie einen Wissensgraphen verwenden, wurde die Entitätsauflösung an einer realen Stichprobe Ihrer Daten getestet, nicht nur am Extraktionsschritt.

Bereitschaft für Unternehmen

• [ ] Sie wissen genau, wo sich die Daten jeder Ebene befinden und ob dies Ihren tatsächlichen Compliance-Anforderungen entspricht (nicht nur „selbst gehostet klingt konform“).

• [ ] Es existiert ein echter Bewertungssatz – realistische Aufgaben mit bekanntermaßen korrekten Ergebnissen – und wird erneut ausgeführt, bevor jede bedeutungsvolle Änderung erfolgt.

• [ ] Jeder Zustandsübergang, jeder Werkzeugaufruf und jeder Abruf wird auf eine Weise protokolliert, die ein Mensch Wochen später nachvollziehen kann.

• [ ] Sie haben die tatsächlichen LLM-Anrufe pro Aufgabe gemessen und die tatsächlichen Kosten bei erwartetem Nutzungsvolumen prognostiziert – nicht geschätzt.

• [ ] Die Lizenzen wurden für jedes Framework in Ihrem Stack überprüft, insbesondere für Speicher- und Grafiktools, bei denen erweiterte Funktionen manchmal sogar in „Open-Source“-Projekten kostenpflichtig sind.

---

Glossar

Agent – Ein System, das entscheidet, was zu tun ist, Maßnahmen über Tools ergreift, Ergebnisse beobachtet und in einer Schleife entscheidet, was als nächstes zu tun ist, anstatt eine Antwort auf eine Eingabe zu produzieren.

Orchestrierungsebene – Die Workflow-Logik (üblicherweise in LangGraph integriert), die Verzweigungen, Schleifen und Wiederholungen für die Aufgabe eines Agenten regelt.

Abrufschicht – Der Teil eines Agenten, der für die Antwort „Was weiß ich eigentlich darüber“ verantwortlich ist, typischerweise bestehend aus RAG, einem RAG-Diagramm und/oder einem Wissensdiagramm.

RAG (Retrieval-Augmented Generation) – Abrufen relevanter Texte über eine Ähnlichkeitssuche und Übergabe an ein Sprachmodell zur Beantwortung in einem einzigen linearen Durchgang.

RAG Graph – Eine LangGraph-Workflow-Ebene, die um die RAG-Komponenten gewickelt ist und Zerlegung, parallelen Abruf, Beweisvalidierung und Wiederholungsversuche hinzufügt – wodurch die Zuverlässigkeit bei mehrteiligen Fragen verbessert wird, ohne die zugrunde liegenden Einbettungen, Neubewertung oder Generierung zu verbessern.

Wissensgraph – Ein Neo4j-Datenspeicher von Entitäten (Knoten) und expliziten, typisierten Beziehungen (Kanten) zwischen ihnen, abgefragt durch Durchquerung und nicht durch Ähnlichkeit.

Entitätsauflösung – Der Prozess des Erkennens, dass sich verschiedene Erwähnungen („Fall A“, „Fall Nr. A-2019“) auf dieselbe reale Entität beziehen, sodass Fakten darüber aus verschiedenen Dokumenten in einem Knoten verbunden werden, anstatt getrennt zu bleiben.

Beweisvalidierung – Ein expliziter Prüfpunkt, der vor der Generierung beurteilt, ob die abgerufenen Informationen tatsächlich zur Beantwortung einer Frage ausreichen.

Human-in-the-Loop – Ein Entwurfsmuster, bei dem ein Agent eine Aktion vorschlägt, ein Mensch diese jedoch genehmigen muss, bevor sie ausgeführt wird. Es wird für jede Aktion mit Konsequenzen für die reale Welt verwendet.

Arbeitsgedächtnis (Kurzzeitgedächtnis) – Zustand, der nur für die Dauer einer Aufgabe bestehen bleibt: was wurde versucht, was wurde gefunden, was fehlt noch.

Langzeitgedächtnis – Zustand, der über mehrere Sitzungen hinweg bestehen bleibt – Fakten über einen Benutzer, ein Projekt oder eine Beziehung, an die man sich Tage oder Monate später erinnert.

---

Quellen und weiterführende LiteraturDieser Leitfaden basiert auf der aktuellen Werkzeugdokumentation und unabhängigem Benchmarking (Stand August 2026):

– Neo4j GraphRAG Ecosystem Tools – offizielle Dokumentation zur graphbasierten, abrufgestützten Generierung – Neo4j GraphRAG für Python (GitHub) – Erstanbieter-Python-Bibliothek für Neo4j-gestütztes GraphRAG

• LightRAG-Übersicht – leichtes, graphbasiertes RAG mit Open-Source-Modellunterstützung in der gesamten Pipeline

• GraphRAG-Bench – Benchmark zum Vergleich der Kosten und Qualität der Diagrammerstellung mit GraphRAG, LightRAG, HippoRAG und anderen Methoden

– Beste Open-Source-Vektordatenbanken 2026 – Vergleich von Milvus, Qdrant, Weaviate, Chroma, pgvector und anderen – Self-Hosted Vector Database Rankings 2026 – Compliance-fokussierte selbstgehostete Bereitstellungsanalyse – AI Agent Memory Frameworks im Vergleich 2026 – Vergleich von Mem0, Zep/Graphiti, LangMem, Letta und anderen – AI Agent Memory Tools & Alternatives 2026 – praktische Auswahlhilfen und Lizenzhinweise für alle Speicher-Frameworks – Open Source Graph RAG Tools 2026 – direkter Vergleich von Graphiti, Cognee, LightRAG und GraphRAG nach Anwendungsfall

Begleitstücke in dieser Reihe: Stop Confusing RAG, RAG Graph, and Knowledge Graph (Architekturvergleich), Inside a RAG Graph: How AI Systems Learn to Check Their Own Work und Knowledge Graphs Explained: How AI Learns to Connect the Punkte.

---

Wichtige Erkenntnisse

• Ein Agent wird durch eine Schleife definiert – denken, handeln, beobachten, erneut entscheiden – und nicht dadurch, dass ein LLM Fragen mit einer Systemaufforderung beantwortet.

• Jeder echte Agent besteht aus vier Schichten: Speicher/Zustand, Abruf, Tools und Orchestrierung – und die Konzepte RAG, RAG Graph und Knowledge Graph befinden sich alle innerhalb der Abrufebene und nicht als Gesamtsystem.

• Lesetools sind grundsätzlich frei aufrufbar; Schreibtools, die reale Aktionen ausführen, benötigen einen Human-in-the-Loop-Kontrollpunkt, insbesondere zu Beginn der Bereitstellung.

• Ein explizites „Ist diese Aufgabe tatsächlich erledigt?“ Der Checkpoint mit begrenzten Wiederholungsversuchen verhindert, dass ein Agent zu früh beendet wird oder sich für immer in einer Schleife befindet.

• Unternehmenstauglichkeit ist keine Funktion, die man am Ende hinzufügt – Datenresidenz, Auswertung, Beobachtbarkeit und Kosten müssen von Anfang an geplant werden und dürfen nicht nachträglich eingebaut werden, wenn etwas kaputt geht.

• Erstellen Sie in der richtigen Reihenfolge: Zuerst den Abruf, dann die Argumentationsschleife, dann den Wissensgraphen, wenn Sie tatsächlich Beziehungsabfragen benötigen, dann gesteuerte Aktionen, dann Auswertung und Beobachtbarkeit – vor, nicht nach der Skalierungsnutzung.