Konfiguration, Zustand, Speicherung, Aufforderung: Kontextengineering in LangGraph

Entwickler, die LangChain oder LangGraph verwenden, stoßen früher oder später auf Begriffe wie Config, State, Store und Context Engineering. Es ist verlockend anzunehmen, dass „Context“ nur die neueste Prompt-Zeichenkette bedeutet. Diese Annahme gilt jedoch nicht, sobald die Anwendungen wachsen.

Die Qualität eines KI-Produkts hängt weniger allein von der Marke des Modells ab als vielmehr davon, wie sorgfältig Informationen ausgewählt, gespeichert und dem Modell präsentiert werden. LangChain und LangGraph bieten das notwendige Vokabular sowie Mechanismen dafür – und diese Konzepte lassen sich problemlos auf herkömmliches Softwareengineering übertragen.

Was der Context eines LLM tatsächlich umfasst

Oft hört man den Begriff „Context“ und stellt sich dabei einen einzelnen Benutzungssatz wie „Erklären Sie React Hooks“ vor. Reale Anwendungen benötigen jedoch auch Konversationen, Präferenzen, abgerufte Dokumente, Tool-Ausgaben, Authentifizierungsmetadaten sowie Laufzeit-Einstellungen. Zusammen bilden diese Elemente den Context, der zu präzisen Antworten führt.

                    LLM
                     ▲
                     │
        ┌────────────┴────────────┐
        │                         │
   User Message             Additional Context
                                │
         ┌──────────────┬──────────────┬──────────────┐
         │              │              │
   Conversation     User Info     Retrieved Docs
      History

Die Anfrage ist nur eine Schicht in diesem Stack.

Warum Management wichtig ist

Eine Support-Frage wie „Wo befindet sich die neueste Bestellung?“ erfordert die Benutzeridentität, frühere Anfragen, aktuelle Bestellungen, Richtlinien sowie Informationen zur Lieferung. Wenn all das bei jeder Anfrage in eine einzige riesige Anfrage zusammengefasst wird, entstehen enorme, teure und schwer zu debuggende Texte. Context Engineering ist die Disziplin, bei der entschieden wird, was das Modell sieht, woher die Informationen stammen, wann sie verfügbar sind und wie lange sie gelten – einschließlich Geheimnisse, die das Modell auf keinen Fall sehen darf.

Vier Arten von Kontext

1. Config (unveränderlicher Laufzeitkontext)

Config sind Anfragedatenmetadaten, die während des Laufs des Agents nicht ändern: Benutzer-ID, Tenant, Plan, Lokalisation, Zeitzone, Feature-Flags, Authentifizierung. Sie werden über LangChain’s reserviertes configurable-Objekt übergeben:

await agent.invoke(
  {
    messages: [
      {
        role: "user",
        content: "Show my recent orders."
      }
    ]
  },
  {
    configurable: {
      userId: "123",
      tenantId: "companyA",
      plan: "premium"
    }
  }
);

Tools können sie sicher lesen:

const getOrders = tool(async (_, config) => {
    const userId = config.configurable.userId;

    return database.orders.find({
        userId
    });
});

Der Benutzer gibt niemals eine ID ein; das Tool holt sie aus der Laufzeitkonfiguration ab.

2. Zustand (Arbeitsspeicher)

Der Zustand ist der RAM während des Laufs: Nachrichten, Tool-Ausgaben, heruntergeladene Dokumente, Zwischennotizen, Zusammenfassungen. Im Gegensatz zur Konfiguration ändert sich der Zustand, während die Knoten ausgeführt werden.

User asks question

↓Search tool runs↓Results added to State↓Model reasons↓Final answer generated

Graphenknoten lesen und schreiben in den Zustand, sodass für die Zusammenarbeit keine globalen Variablen erforderlich sind.

3. Speicher (Langzeitgedächtnis)

Der Zustand wird beendet, wenn der Lauf endet. Der Speicher hingegen bleibt über Gespräche hinweg bestehen: Präferenzen, Profile, frühere Interaktionen, bevorzugte Technologien, Schreibton. Beispiel: Ein Benutzer erwähnt die Erstellung von React-Apps; eine Woche später kann eine Frage zur Zustandsverwaltung bereits zu reakt-freundlichen Optionen führen, ohne dass erneut gefragt werden muss.

4. Prompt-Kontext

Irgendwann verschmelzen die Beiträge von Config, State und Store zu dem endgültigen Modellprompt: der neueste Benutzertext, das gekürzte Verlaufsmaterial, die abgerufenen Dokumente, die Ergebnisse der Tools sowie die gespeicherten Präferenzen. Denken Sie daran: der Prompt ist das Ergebnis der Kontextverwaltung, nicht der gesamte Kontext.

Warum nicht alles in den Prompt aufnehmen?

Kontextfenster sind begrenzt. Zusätzliche Token erhöhen Kosten und Latenzzeit. Authentifizierungstoken sowie API-Schlüssel dürfen auf keinen Fall vom Modell sichtbar sein. Die Trennung der Laufzeitkonfiguration von dem an das Modell gerichteten Text ist daher ein Sicherheits- und Kostenvorteil, keine Pedanterie.

Übertragung auf die Softwareentwicklung

Config ähnelt einstellungen, die auf eine Anfrage bezogen sind. State entspricht dem Arbeitsspeicher pro Anfrage. Store gleicht einer Datenbank oder einem Profildienst. Die Erstellung von Prompts ähnelt der Darstellung eines Views aus mehreren Datenquellen. Auf diese Weise zu denken hilft Backend-Entwicklern, LangGraph ohne es als fremdartige KI-Magie zu betrachten, anzunehmen.

Praktische Gewohnheiten

• Halten Sie Config klein und typisiert.
• Schreiben Sie State-Reducer/Node, die leicht getestet werden können.
• Betrachten Sie Schreibvorgänge in Store als beabsichtigte Produktereignisse und nicht als zufällige Nebeneffekte.
• Protokollieren Sie, welche Schichten zu jedem Prompt beigetragen haben, um Fehlersuche zu erleichtern.
• Ziehen Sie es vor, Daten über Abruf- und Store-Suchen zu erhalten, anstatt ganze Historien einzufügen.

Teams, die diese Schichten explizit verwalten, liefern Assistenten, die günstiger, sicherer und leichter erklärbar sind, wenn um 2 Uhr morgens etwas schiefgeht.

Muster, die in LangGraph-Anwendungen auftauchen

Viele Graphen beginnen mit einem Router-Node, der vor der Auswahl eines Zweigs Config (Mietnehmer, Lokalisation) sowie State (letzte Benutzerabsicht) überprüft. Retrieval-Node schreiben Dokumente in den State; Generation-Node lesen den State und greifen niemals direkt auf die Rohauthentifizierungsgeheimnisse aus Config zu, außer über Tool-Wrapper. Memory-Node entscheiden, ob eine Präferenz nach erfolgreichem Schritt in den Store geschrieben werden sollte.

Incoming Request

Checkpointing (sofern aktiviert) speichert den State zwischen den Schritten, damit langlaufende Agenten fortgesetzt werden können. Das unterscheidet sich vom Store: Checkpoints bieten Schritt-spezifische Beständigkeit; der Store dient als Produktmerkmals-Speicher über mehrere Sitzungen hinweg.

↓Middleware↓Load Memory↓Update State↓Generate Prompt↓Call LLM

Beim Debuggen einer fehlerhaften Antwort sollte man prüfen, in welcher Schicht ein Fehler aufgetreten ist. Falsche Benutzer-ID? Config. Verlorenes Tool-Ergebnis? State. Vergessene Präferenz? Store. Überdimensionierte Tokens? Prompt-Assembly. Diese Klassifizierung verwandelt vage Berichte wie „Das Modell hat halluziniert“ in handlungsrelevante Tickets.

User
↓Agent.invoke()↓Config
(User ID, Tenant ID)↓Middleware↓State
(Chat History)↓Retriever
(Knowledge Base)↓Store
(Long-Term Memory)↓Prompt↓LLM↓Final Response

Context Engineering dreht sich daher weniger um raffinierte Prompt-Formulierungen und mehr um einen disziplinierten Datenfluss – dieselbe Fähigkeit, die dafür sorgt, dass gewöhnliche Web-Backends wartbar bleiben. LangChain und LangGraph geben den Speicherbereichen einfach Namen, damit KI-Funktionen nicht alles in einen einzigen String packen.

Anti-Muster, die man vermeiden sollte

Das Hineinwerfen des gesamten Chat-Logs in jeden Prompt „für alle Fälle“ kostet Geld und lenkt die Aufmerksamkeit ab. Das Hineinlegen von API-Schlüsseln in System-Prompts „aus Bequemlichkeit“ schafft Risiken durch Datenabfluss. Die Verwendung von Store als Ablage für vorübergehende Tools verschmutzt zukünftige Sitzungen. Wenn jedes Node die Config während des Laufs ändert, wird die Unveränderbarkeit zerstört, auf der die Tools beruhen.

Verwenden Sie explizite Schemata für den State, überwachte Schreibwege für den Store sowie Prompt-Vorlagen, die nur die benötigten Felder zulassen. Messen Sie den Tokenverbrauch pro Schicht. Überprüfen Sie die Protokolle wöchentlich, bis das Team vorhersagen kann, welcher Knoten welche Tokens hinzufügt.

Durch diese Gewohnheiten werden Config, State, Store und Prompt Context keine leeren Begriffe mehr, sondern zum Betriebssystem des Agents – eine unauffällige Infrastruktur, die das Modell intelligenter erscheinen lässt, als es allein wäre.