Context Engineering für KI-Agenten: Was wirklich ins Context Window gehört

Inhaltsverzeichnis

Veröffentlicht im August 2026.

TL;DR: Context Engineering ist die Disziplin zu entscheiden, welche Tokens sich bei jedem Schritt einen Platz im Context Window eines Agenten verdienen — Systemanweisungen, Tool-Definitionen, abgerufene Daten und Gesprächsverlauf konkurrieren alle um denselben begrenzten Raum. Prompt Engineering fragt wie formuliere ich das; Context Engineering fragt was muss das Modell gerade jetzt wirklich wissen. Der Fehlermodus ist meistens nicht zu wenig Kontext — es ist zu viel: veralteter Verlauf, irrelevante Tool-Schemas und abgerufene Dokumente, die niemand angefragt hat, was alles das Signal verwässert und die Kosten treibt. Ich fahre ein festes Budget pro Kategorie, kürze den Verlauf vor der Identität und fasse zusammen, bevor ich abschneide.

Operator-Perspektive: Die Agenten, die am schwersten zu debuggen waren, scheiterten nicht, weil das Modell schwach war. Sie scheiterten, weil ich das Context Window zu einer Krimskrams-Schublade hatte werden lassen: sechs Tool-Schemas, die die Aufgabe nicht brauchte, ein Gesprächsverlauf, der 40 Runden von der ursprünglichen Anfrage abgedriftet war, ein abgerufenes Dokument, das technisch relevant und praktisch nutzlos war. Den Prompt zu reparieren half nicht. Zu reparieren, was vor dem Prompt stand, schon.

Prompt Engineering hat dir einen funktionierenden Agenten verschafft. Context Engineering ist das, was ihn am Laufen hält, sobald er echtes Volumen, echten Verlauf und echte Randfälle bewältigen muss — und es ist die Fähigkeit, in die ich inzwischen mehr Zeit investiere als in die Formulierung des Prompts.

Prompt Engineering und Context Engineering sind nicht derselbe Job

Ein Prompt ist eine Anweisung. Kontext ist alles, was das Modell sieht, wenn es auf diese Anweisung reagiert: der System-Prompt, die Tools, die es aufrufen kann, was auch immer du abgerufen oder nachgeschlagen hast, und wie viel vorherige Konversation oder Lauf-Historie du entschieden hast mitzuführen. Prompt Engineering optimiert die Formulierung des Ersten. Context Engineering optimiert die Zusammensetzung aller vier.

Diese Unterscheidung zählt in der Praxis, nicht nur im Vokabular. Wenn ich einen fein abgestimmten Prompt schreibe und dem Agenten fünf irrelevante Tool-Schemas und vierzig Runden veralteten Verlaufs mitgebe, spielt die Formulierung keine Rolle mehr — das Modell denkt über einen Kontext nach, der größtenteils Rauschen ist. Jeder meiner Agenten, der von „funktioniert in der Demo” zu „funktioniert um 3 Uhr morgens bei einer seltsamen Eingabe” gekommen ist, hat das geschafft, indem ich repariert habe, was im Fenster war — nicht indem ich die Anweisungen darin umformuliert habe.

Die vier Dinge, die um Platz konkurrieren

Bei jeder Runde kämpfen vier Kategorien um denselben begrenzten Raum:

1. Systemanweisungen — Identität, Regeln, Ausgabeformat. Siehe die fünf Schichten, die ich für System-Prompts nutze — das ist die einzige Kategorie, die nahezu fix bleiben sollte, weil sich Prompt Caching nur auszahlt, wenn sich der Präfix nicht bewegt.
2. Tool-Definitionen — die Schemas für jedes Tool, das der Agent diese Runde aufrufen könnte, ob er es braucht oder nicht.
3. Abgerufene Daten — alles, was aus einer Datenbank, einem Vector Store oder einem API-Aufruf gezogen wird: Gedächtnis, Dokumente, Kundendatensätze.
4. Gesprächs- oder Lauf-Historie — was in dieser Sitzung oder diesem Lauf bereits passiert ist.

Keine davon ist kostenlos. Jedes Token in jeder Kategorie ist ein Token, das das Modell gegen jedes andere abwägen muss, wenn es entscheidet, was als Nächstes zu tun ist, und jedes Token ist ein Token, das du bei jeder Anfrage bezahlst, die kein Cache-Treffer ist.

Der Fehler ist fast immer zu viel, nicht zu wenig

Wenn sich ein Agent daneben benimmt, ist der Instinkt, mehr Kontext hinzuzufügen — mehr Anweisungen, mehr Hintergrund, mehr Verlauf „nur für den Fall”. Meiner Erfahrung nach ist das öfter genau falsch herum.

Zu viele Tool-Schemas. Ich habe erlebt, wie ein Agent das falsche Tool aufrief — nicht weil das richtige fehlte, sondern weil es hinter sechs anderen vergraben war, die für diese Aufgabe nicht gebraucht wurden. Schicke nur die für den aktuellen Schritt relevanten Tools, nicht die ganze Werkzeugkiste bei jedem Aufruf. Eine Routing-Schicht, die entscheidet, welche Tool-Teilmenge freigegeben wird, ist billig zu bauen und zahlt sich schon beim ersten verhinderten Fehlaufruf aus.

Veralteter Gesprächsverlauf. Ein Support-Agent, der 60 Runden Verlauf aus drei unabhängigen, längst vergangenen Vorfällen mitschleppt, „erinnert sich” nicht an den Kunden — er verwässert die aktuelle Anfrage mit irrelevantem Rauschen und handelt gelegentlich nach etwas, das nicht mehr zutrifft. Das ist genau der Fehlermodus, den episodisches Gedächtnis mit einem begrenzten Fenster verhindern soll — und es lohnt sich zu prüfen, ob dein Fenster wirklich begrenzt ist oder still und leise unbegrenzt gewachsen ist.

Abgerufene Dokumente, die niemand angefragt hat. Eine semantische Suche, die die Top-10-„ähnlichsten” Chunks statt der Top-2-relevanten zurückgibt, begräbt die Antwort unter plausibel aussehender Ablenkung. Mehr abgerufener Kontext ist nicht mehr Signal — ab einem gewissen Punkt ist es aktiv schlechter, weil das Modell härter arbeiten muss, um den Teil zu finden, der zählt.

Defensiv wiederholte Anweisungen. Das sehe ich in Prompts, die dieselbe Regel viermal unterschiedlich wiederholen, weil eine frühere Version des Agenten sie einmal ignoriert hat. Das ist ein Signal, dass die Regel weiter vorne im Prompt platziert oder strukturell erzwungen werden musste (eine Einschränkung im Tool-Schema, ein Validierungsschritt) — kein Signal, den Kontext mit Wiederholung aufzufüllen.

Das Budget, das ich tatsächlich fahre

Über 30+ Produktionsagenten hinweg lege ich ein explizites Token-Budget pro Kategorie fest, bevor ich den Agenten baue — nicht erst, nachdem er sich daneben zu benehmen beginnt:

Die Reihenfolge dieser letzten Spalte ist das eigentliche Entscheidungsraster: zuerst der Verlauf, dann die Breite der Suche, dann der Tool-Umfang, und Systemanweisungen zuletzt. Verlauf lässt sich am billigsten komprimieren, ohne die Korrektheit zu verlieren — eine Zwei-Satz-Zusammenfassung von „was in den Runden 1-30 passiert ist” trägt meist denselben operativen Wert wie das vollständige Transkript. Systemanweisungen zu kürzen ist am gefährlichsten, weil dort das eigentliche Verhalten des Agenten steckt.

Erst zusammenfassen, dann abschneiden

Truncation — einfach die ältesten Runden fallen zu lassen — ist die grobe Version davon. Das funktioniert, bis die verworfene Runde genau die eine Tatsache enthielt, die der Agent brauchte. Das bessere Muster ist Compaction: Bevor du Rohverlauf verwirfst, ihn in eine kurze strukturierte Zusammenfassung kollabieren lassen, die die Entscheidungen und Fakten festhält, und diese Zusammenfassung dauerhaft behalten, selbst nachdem die Rohrunden verschwunden sind.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 Sätze: was entschieden, gelöst oder noch offen ist
  keyFacts: Record<string, string>; // stabile Fakten, die es wert sind, wörtlich behalten zu werden
  turnCount: number; // wie viele Rohrunden dieses Digest ersetzt
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // Ein billiges Modell zum Zusammenfassen reicht für diesen Schritt fast immer aus
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

Das ist dasselbe Prinzip wie ein Eval-Harness, der jeden Produktionsfehler in einen permanenten Testfall verwandelt (siehe der Eval-Harness, den ich zum Ausliefern von KI-Agenten nutze): Verwirf Informationen nicht, komprimiere sie in eine Form, die billig zu behalten und trotzdem nützlich ist. Die Rohrunden sind wegwerfbar. Die Fakten darin normalerweise nicht.

Retrieval: weniger, relevantere Ergebnisse schlagen mehr Ergebnisse

Dieselbe Disziplin gilt für alles, was aus einem Vector Store oder einer Datenbank gezogen wird. Es ist verlockend, großzügig abzurufen — Top-10, Top-20 — nach der Theorie, dass mehr Kontext nicht schaden kann. Kann es aber. Jeder irrelevante Chunk ist ein Chunk, den das Modell lesen, abwägen und verwerfen muss, und ein groß genug angehäufter Stapel von Beinahe-Treffern kann den einen Chunk überwiegen, der die Frage tatsächlich beantwortet.

Mein Standard ist, mit einem kleinen k (2-4) zu beginnen und es nur zu erweitern, wenn ich mit echten Fällen zeigen kann, dass die Antwort bei dieser Breite tatsächlich fehlt — nicht, weil sich ein weiteres Netz sicherer anfühlt. Wenn die Retrieval-Qualität inkonsistent ist, liegt die Lösung meist in einer besseren Query oder einem Re-Ranking-Schritt, nicht in einem größeren k.

Zurück zu Kosten und Korrektheit

Context Engineering ist nicht nur ein Qualitätsproblem — es ist der größte einzelne Hebel darauf, was der Betrieb eines Agenten kostet, weil bei den meisten Agenten-Workloads Input-Tokens weit stärker berechnet werden als Output-Tokens. Ein aufgeblähtes Context Window ist eine aufgeblähte Rechnung, bevor es je ein Verhaltensbug ist. Falls du dir die Kostenmathematik für die Wahl zwischen Modellstufen noch nicht angesehen hast: Das Kontextbudget, das du fährst, ändert diese Mathematik direkt — ein kleinerer, gut abgegrenzter Kontext macht ein günstigeres Modell für mehr deiner Aufgaben tragfähig, weil das Modell nicht gebeten wird, eine Nadel in einem unnötig großen Heuhaufen zu finden.

Jeder Agent, den ich betreibe, läuft auf Claude, und die Entscheidung über die Modellstufe ergibt erst Sinn, wenn das Kontextbudget feststeht — Kosten über einen aufgeblähten, unbegrenzten Kontext zu vergleichen, sagt dir nichts darüber, was die Aufgabe tatsächlich braucht.

Und weil das Ändern dessen, was im Context Window steht, das Verhalten genauso stark verändert wie das Ändern des Prompts, durchläuft jede Kontextänderung dasselbe Gate wie eine Prompt-Änderung: gegen das Eval-Set aus echten Produktionsfehlern laufen lassen, bevor sie live geht. Verlauf zu kürzen oder die Breite einer Suche zu verengen ist genau die Art von „offensichtlich sicherer” Änderung, die still einen Randfall regressieren lässt, wenn du nicht prüfst.

Das Fazit des Operators

Context Engineering bedeutet, bei jeder Runde zu entscheiden, was sich einen Platz in einem begrenzten Fenster verdient — und der Standardfehler ist, zu viel einzuschließen, nicht zu wenig. Halte Systemanweisungen stabil und als Letztes zu kürzen. Begrenze Tool-Definitionen auf den aktuellen Schritt. Rufe eng ab und erweitere nur mit Belegen. Fasse Verlauf in Zusammenfassungen zusammen, bevor du ihn verwirfst, und kürze zuerst die ältesten Rohrunden. Überprüfe dann jede Änderung gegen deine Evals, denn Kontextänderungen verändern das Verhalten genau wie Prompt-Änderungen — es ist nur leichter, so zu tun, als wäre das nicht so.

FAQ

Was ist Context Engineering für KI-Agenten?

Es ist die Disziplin zu entscheiden, welche Tokens — Systemanweisungen, Tool-Definitionen, abgerufene Daten und Gesprächsverlauf — bei jedem Schritt in das Context Window eines Agenten gelangen, im Gegensatz zu Prompt Engineering, bei dem es darum geht, wie eine einzelne Anweisung formuliert ist. Es zählt am meisten in der Produktion, wo alle vier Kategorien bei jeder Anfrage um denselben begrenzten Raum konkurrieren.

Ist Context Engineering etwas anderes als Prompt Engineering?

Ja. Prompt Engineering optimiert die Formulierung einer Anweisung. Context Engineering optimiert alles andere, was das Modell neben dieser Anweisung sieht — welche Tools freigegeben sind, was abgerufen wurde und wie viel Verlauf mitgeführt wird. Ein gut formulierter Prompt scheitert trotzdem, wenn er von irrelevanten Tool-Schemas oder veraltetem Verlauf umgeben ist.

Wie viel Gesprächsverlauf sollte ein KI-Agent behalten?

Weniger, als man denkt. Ein begrenztes gleitendes Fenster (10-20 aktuelle Runden ist typisch) plus eine zusammengefasste Übersicht von allem Älteren übertrifft meist ein vollständiges Rohtranskript, weil es Rauschen entfernt, ohne die wichtigen Fakten zu verlieren. Fasse zusammen, bevor du Verlauf verwirfst, schneide ihn nicht einfach ab.

Bedeutet ein größeres Context Window, dass ich weniger Context Engineering brauche?

Nein — es entfernt die harte technische Obergrenze, aber nicht das Kosten- oder Rauschproblem. Ein größeres Fenster macht Nachlässigkeit billiger, aber jedes irrelevante Token verwässert weiterhin das Signal, über das das Modell nachdenken muss, und kostet weiterhin Geld bei jeder Anfrage, die kein Cache-Treffer ist. Die Disziplin zählt bei 200K Tokens genauso wie bei 8K.

Verwandt: Wie man KI-Agenten-System-Prompts schreibt, die in der Produktion nicht scheitern · Wie man einem KI-Agenten Gedächtnis gibt · Prompt Caching: Senke deine Claude-Kosten, ohne das Modell zu wechseln · Der Eval-Harness, den ich zum Ausliefern von KI-Agenten nutze

Brauchen Sie Hilfe bei der Gestaltung von Kontext und Gedächtnis für Ihren Agenten? Kontaktieren Sie mich — ich entwerfe Produktionsagentensysteme für Operator-Teams.