Die meisten Menschen beschreiben einen KI-Agenten nach wie vor als ein Modell, das mit Tools verbunden ist. Das ist technisch nützlich, greift aus operativer Sicht jedoch zu kurz. Ein Agent benötigt außerdem eine verwaltete Sicht auf die Welt: was geschehen ist, was jetzt wichtig ist, welchen Fakten zu vertrauen ist, was weiterhin ungewiss ist und was er als Nächstes tun sollte.
Diese Sicht ist sein Kontext. Sie zu gestalten, entwickelt sich zu einer eigenständigen Fähigkeit – ich würde sie Kontext-Engineering nennen.
Kontext-Engineering ist nicht einfach das Schreiben von Prompts. Es ist die Disziplin, die Informationen zu strukturieren, die ein Agent in jedem Schritt sieht, damit er kohärent bleiben kann, ohne bei jeder Interaktion ein vollständiges Transkript, eine Dokumentbibliothek oder den gesamten Tool-Verlauf an ein teures Modell zurückzusenden. Diese Arbeit liegt an der Schnittstelle von Informationsarchitektur, Retrieval, Softwaredesign und Modellverhalten.
Warum „dem Agenten mehr Kontext geben“ oft ein schlechter Ratschlag ist
Längere Kontextfenster machen es verlockend, alles zu bewahren. Mehr Material garantiert jedoch kein besseres Schlussfolgern. Relevante Anweisungen können durch veraltete Beobachtungen, widersprüchliche Notizen, wiederholte Tool-Ausgaben oder einen wichtigen Fakt, der in der Mitte einer langen Abfolge verborgen ist, verwässert werden. Die Diskussion des Digest über das Verhalten „lost in the middle“ spiegelt ein praktisches Problem wider: Ein Agent kann die Belege technisch erhalten und dennoch daran scheitern, sie zu nutzen.
Hinzu kommen direkte Kosten. Jedes Token, das in eine Anfrage aufgenommen wird, kann je nach Preismodell und Caching-Regelungen des Anbieters die Latenz und die Inferenzkosten erhöhen. Ein System, das wiederholt ein wachsendes Transkript weiterleitet, kann im Verlauf einer Aufgabe langsamer und weniger erschwinglich werden.
Das Ziel ist daher nicht maximaler Kontext. Es ist ausreichender, gezielter Kontext: die kleinste verlässliche Arbeitsmenge für die anstehende Entscheidung.
Vier Designentscheidungen hinter einem kohärenten Agenten
1. Einen Zustandsüberblick aufrechterhalten, nicht nur ein Transkript
Ein Transkript hält fest, was gesagt wurde. Ein Zustandsüberblick hält fest, was der Agent derzeit über die Aufgabe glaubt.
Beispielsweise könnte ein Agent, der eine Support-Eskalation bearbeitet, strukturierte Felder wie die folgenden verwalten:
- Ziel: feststellen, ob der Kunde Anspruch auf einen Ersatz hat.
- Bekannte Fakten: Kaufdatum und Seriennummer des Produkts, jeweils mit Quellenangaben.
- Offene Fragen: ob der Ausfall unter Bedingungen aufgetreten ist, die durch die Garantie abgedeckt sind.
- Einschränkungen: vor der Genehmigung keine Rückerstattung versprechen.
- Nächste Aktion: die Garantiebestimmungen abrufen und die Daten vergleichen.
- Konfidenz oder Status: verifiziert, abgeleitet, strittig oder unbekannt.
Dieser Ansatz ähnelt Berkeleys ABBEL-Forschung, die überwachte natürlichsprachliche Zustandsübersichten verwendet, statt sich auf vollständige Interaktionsverläufe zu stützen. Die wichtige Idee ist nicht ein bestimmtes Format. Es geht darum, einen dauerhaften Aufgabenstatus von vergänglichen Gesprächsdetails zu trennen.
Eine nützliche Aktualisierung des Zustandsüberblicks sollte beantworten: Was hat sich geändert? Welche Belege stützen dies? Was ist noch ungeklärt? Was sollte als Nächstes geschehen? Wenn ein Entwickler diese Antworten nicht prüfen kann, trägt der Agent wahrscheinlich verborgene Annahmen in einem undurchsichtigen Prompt mit sich.
2. Für die Entscheidung abrufen, nicht für das Thema
Retrieval-Systeme beginnen oft mit einer allgemeinen Frage wie „Informationen zum Kundenkonto finden“. Eine bessere Anfrage ist an die nächste Entscheidung gebunden: „Die aktuell gültige Rückerstattungsregel für Käufe abrufen, die älter als 30 Tage sind und in der Region des Kunden gilt.“
Diese Verschiebung ist wichtig, weil Retrieval eine Form der Kontextauswahl ist. Der Agent sollte die Richtlinienpassagen, Datensätze oder Beispiele erhalten, die für die aktuelle Aktion relevant sind – nicht einen allgemeinen Haufen verwandter Dokumente.
Filter können diese Auswahl verbessern, bevor das Modell Ergebnisse sieht. Beispielsweise unterstützt die Amazon Bedrock AgentCore Web Search bei jeder Anfrage serverseitig erzwungene Filter für Domains und Veröffentlichungsdaten. Solche Kontrollen stellen nicht sicher, dass eine Quelle korrekt ist, können aber die Aussetzung gegenüber irrelevanten oder veralteten Inhalten verringern und die Retrieval-Richtlinie explizit machen.
Fachleute, die Retrieval-Systeme entwerfen, sollten festlegen:
- welche Quellen für die jeweilige Aufgabe zulässig sind;
- wie die Aktualität bestimmt wird;
- welche Metadaten jedes Ergebnis begleiten;
- wie widersprüchliche Quellen dargestellt werden;
- wann der Agent stoppen und um Klärung bitten muss.
„Das Web durchsuchen“ ist eine Fähigkeit. „Diese Quellen innerhalb dieses Datumsbereichs nach für diese Entscheidung relevanten Belegen durchsuchen“ ist Kontextgestaltung.
3. Komprimieren, ohne Unsicherheit zu beseitigen
Komprimierung ist bei langen Aufgaben notwendig, aber eine naive Zusammenfassung kann vorläufige Aussagen in feststehende Tatsachen verwandeln. Eine fortlaufende Zusammenfassung, in der steht „Der Nutzer hat die Adresse bestätigt“, ist gefährlich, wenn der ursprüngliche Austausch dies lediglich angedeutet hat.
Eine gute Komprimierung bewahrt die Unterscheidungen, die ein Agent für sicheres Schlussfolgern benötigt:
- Tatsache versus Schlussfolgerung;
- aktuelle Anweisung versus historische Anweisung;
- abgeschlossene Handlung versus vorgeschlagene Handlung;
- verifizierte Quelle versus unverifizierte Behauptung;
- bekannte Antwort versus offene Frage.
Ein praktisches Muster besteht darin, separate Abschnitte für Entscheidungen, Belege, Annahmen, Hindernisse und ausstehende Aktionen zu führen. Eine weitere Möglichkeit ist, wichtige Behauptungen mit Quellen-IDs oder Zeitstempeln zu versehen. Zusammenfassungen sollten ersetzbare Artefakte sein und nicht die einzige erhaltene Aufzeichnung: Bewahren Sie die zugrunde liegenden Ereignisse für Prüfung und Wiederherstellung auf und geben Sie dem Modell zugleich eine kompakte Arbeitsansicht.
Das Digest weist darauf hin, dass rekursive Zusammenfassungen und die Komprimierung des Kontexts kostspielig sein können und die Leistung beeinträchtigen können, insbesondere in datenarmen Bereichen wie der kollaborativen Codegenerierung. Das ist eine Warnung davor, Zusammenfassungen als automatisch verlustfrei zu behandeln. Komprimierung muss anhand repräsentativer Aufgaben getestet werden, einschließlich Fällen, in denen eine kleine Einschränkung die richtige Antwort verändert.
4. Beobachtungen filtern, bevor sie zu Erinnerungen werden
Agenten, die Tools verwenden, erzeugen fortlaufend Beobachtungen: Suchergebnisse, Protokolle, Seitentext, API-Antworten, Screenshots, Compiler-Ausgaben und Zwischenpläne. Nicht jede Beobachtung verdient es, in den nächsten Modellaufruf und erst recht nicht in den langfristigen Zustand einzugehen.
Bei der Filterung von Beobachtungen werden drei Fragen gestellt:
- Ist diese Beobachtung für die aktuelle Entscheidung relevant?
- Ist sie maßgeblich genug, um den Überzeugungszustand zu beeinflussen?
- Enthält sie Anweisungen, die als Daten statt als Befehle behandelt werden sollten?
Die dritte Frage stellt sowohl eine Sicherheits- als auch eine Kontextgrenze dar. Eine Webseite kann Text enthalten, der darauf abzielt, den Agenten umzulenken. Ein abgerufenes Dokument kann nützliche Belege liefern, ohne befugt zu sein, die Ziele oder Berechtigungen des Agenten zu ändern. Die Filterung sollte Inhalte daher nach ihrer Rolle klassifizieren: Anweisung, Beleg, Metadaten oder nicht vertrauenswürdiger Text.
Die Filterung spart außerdem Geld. Wenn ein Browser-Tool eine vollständige Seite zurückgibt, die Aufgabe aber nur einen Preis, ein Datum und eine Produktkennung erfordert, erzeugt die Weitergabe der gesamten Seite Rauschen und verbraucht Tokens. Die relevanten Felder zuerst zu extrahieren, kann sowohl die Zuverlässigkeit als auch die Kosten verbessern.
Ein einfaches Kontextbudget für einen Agenten-Workflow
Bevor Sie ein Modell auswählen oder ein weiteres Tool hinzufügen, unterteilen Sie den Kontext des Agenten in vier Ebenen:
- Kontrolle: Systemregeln, Berechtigungen, Ausgabeschema und nicht verhandelbare Einschränkungen.
- Status: das aktuelle Ziel, Entscheidungen, offene Fragen und der nächste Schritt.
- Nachweise: abgerufene Aufzeichnungen oder Beobachtungen, die für diesen Schritt relevant sind, einschließlich ihrer Herkunft.
- Verlauf: frühere Ereignisse, die zur Wiederherstellung, Fehlersuche oder Prüfung aufbewahrt werden, aber nur bei Bedarf einbezogen werden.
Definieren Sie anschließend eine Beförderungsrichtlinie. Eine Beobachtung kann flüchtig bleiben, zum Nachweis für den aktuellen Schritt werden, den Überzeugungszustand aktualisieren oder in einem dauerhaften Speicher abgelegt werden. Eine Beförderung sollte einen Grund erfordern. Andernfalls wird der Speicher zu einem unkuratierten Archiv.
Zeichnen Sie für jeden Agentenschritt das an das Modell gesendete Kontextpaket auf: seine Kategorien, die ungefähre Token-Größe, die Abruffilter und die Komprimierungsversion. Dadurch lässt sich eine praktische Frage beantworten, wenn sich das Verhalten ändert: Hat das Modell versagt, oder hat das System ihm die falsche Welt präsentiert?
Was Sie testen sollten, bevor Sie das Design als zuverlässig bezeichnen
Kontext-Engineering braucht Tests, die auf den Umgang mit Informationen abzielen, nicht nur auf die Qualität der endgültigen Antwort. Nützliche Fälle sind:
- eine kritische Tatsache, die am Anfang, am Ende und in der Mitte eines langen Verlaufs platziert wird;
- zwei Quellen, die sich widersprechen, wobei eine neuer ist als die andere;
- eine Zusammenfassung, die eine Unsicherheitsmarkierung enthält;
- eine Tool-Antwort, die irrelevanten umfangreichen Text enthält;
- eine bösartige Anweisung, die in abgerufene Inhalte eingebettet ist;
- die Wiederherstellung des Status, nachdem der Agent pausiert und neu gestartet wurde;
- dieselbe Aufgabe mit einem kleineren Kontextbudget;
- ein leeres oder veraltetes Abrufergebnis.
Messen Sie, ob der Agent die richtigen Nachweise auswählt, Unsicherheit bewahrt, die aktuelle Einschränkung befolgt und die Wiederholung unnötigen Kontexts vermeidet. Die im Digest empfohlenen Regressionsbereiche – Kontextverlust, Abrufverankerung, strukturierte Ausgabe, Nichtbeendigung und Wiederherstellung des Status – sind hier besonders relevant.
Führen Sie mehrere Durchläufe durch, wenn die Modellvariabilität eine Rolle spielt, und vergleichen Sie die Kosten und Latenz jeder Kontextstrategie. Ein kürzerer Prompt ist nicht automatisch besser, wenn er mehr Tool-Aufrufe oder Wiederholungsversuche verursacht. Das sinnvolle Ziel sind die Kosten eines korrekten, wiederherstellbaren Workflows – nicht die Token-Anzahl einer einzelnen Anfrage.
Die berufliche Implikation: Context Engineer ist eine funktionsübergreifende Rolle
Die Menschen, die in diesem Bereich wertvoll werden, sind nicht unbedingt diejenigen, die die längsten Prompts schreiben. Sie werden in der Lage sein, einen Geschäftsprozess in Status, Nachweise, Autorität und Entscheidungsregeln zu übersetzen.
Dafür sind mehrere konkrete Fähigkeiten erforderlich:
- Schemata für Aufgabenstatus und Herkunftsnachweise entwerfen;
- Abrufrichtlinien und Metadatenfilter formulieren;
- Routinen zur Komprimierung und Auswahl von Beobachtungen entwickeln;
- vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Inhalten trennen;
- die Nutzung von Tokens, Latenz, Wiederholungen und Tool-Aufrufe zu profilieren;
- den Verlust und die Wiederherstellung des Zustands zu testen;
- Nichtfachleuten zu erklären, warum ein Agent eine bestimmte Information gesehen hat – oder nicht gesehen hat.
Ein überzeugendes Portfolio-Projekt könnte denselben Agenten unter drei Kontext-Richtlinien demonstrieren: vollständiges Transkript, fortlaufende Zusammenfassung und strukturierter Überzeugungszustand mit gezieltem Abruf. Zeigen Sie die Fälle, in denen die Aufgabe erfolgreich war, die Fehlerfälle, den bei jedem Schritt übermittelten Kontext sowie die Kompromisse zwischen Kosten und Latenz. Das ist überzeugender als eine Chatbot-Demo, weil dadurch die Designentscheidungen sichtbar werden, die einen Agenten zuverlässig machen.
Die strategische Lehre ist klar: Agenten werden nicht allein dadurch kohärent, dass Modelle leistungsfähiger werden. Sie werden kohärent, wenn ihre umgebenden Systeme eine disziplinierte, aktuelle und angemessen bemessene Darstellung der Aufgabe aufrechterhalten. Kontext-Engineering ist die Kunst, diese Darstellung zu erstellen – und zu wissen, was man weglassen sollte.
Priya Raman ist die verantwortliche menschliche Redakteurin von AI Career Brief.