NAME
context-engineering-agents — Kontext-Engineering: die Arbeit vor der Eingabeaufforderung
SYNOPSIS
cat context-engineering-agents.md
DESCRIPTION
Das Wort der Stunde in der kleinen Welt der KI-Agenten ist Kontext-Engineering.
Es scheint, als ob ein weiteres Label erfunden wurde, um etwas zu verkaufen, was wir bereits getan haben. Teilweise ist es so. Allerdings setzt sich die Bezeichnung, wie so oft, durch, weil sie einem echten Schmerz einen Namen gibt.
Der Schmerz liegt darin: Modelle scheitern nicht, nur weil sie „nicht denken“. Sie scheitern oft daran, dass wir sie mit dem falschen Raum zur Arbeit schicken.
Wir geben ihnen alte Anweisungen. Wir verstecken wichtige Dateien vor ihm. Wir geben ihnen zu lange Dokumente und sagen nicht, worauf es ankommt. Wir zeigen ihnen Protokolle ohne Priorität. Wir geben ihnen zehn Werkzeuge, ohne zu erklären, wann sie sie verwenden sollen. Dann wundern wir uns, wenn sich der Agent bewegt wie ein aufgewachter Mensch in einer unbekannten Wohnung.
Die Eingabeaufforderung ist der Satz, den Sie dazu sagen. Der Kontext ist die Welt, die Sie um ihn herum vorbereiten.
Vom Prompt Engineering zum Context Engineering
Prompt Engineering wurde oft als Schreiben betrachtet. Wählen Sie die richtigen Wörter, fragen Sie richtig, fügen Sie Beispiele hinzu und geben Sie das Format an.
Context engineering is closer to architecture.
Sie fragen nicht nur „Wie formuliere ich die Anfrage?“. Es fragt:
- Welche Informationen werden wirklich benötigt?
- Was sind Geräusche?
- Was muss im laufenden Betrieb wiederhergestellt werden?
- Was ist zu beachten?
- welche Werkzeuge sollen freigelegt werden?
- Welche Anweisungen sind stabil und welche hängen von der Aufgabe ab?
- Wie mache ich dem Agenten klar, was maßgeblich ist?
Es ist eine subtile, aber große Veränderung. Denn wenn Sie mit Agenten arbeiten, ist der Kontext kein statischer Block. Es ändert sich bei jedem Schritt.
Der Agent öffnet eine Datei, lernt etwas, führt einen Test durch, erhält einen Fehler, aktualisiert den Plan, ruft ein Tool auf, entdeckt eine Abhängigkeit. Mit jeder Runde muss er entscheiden, was er mitnimmt und was er weglässt.
Das ist Ingenieurskunst.
Der Kontext ist keine Mülldeponie
Vorlagen mit großen Kontextfenstern haben uns in Versuchung geführt: Werfen wir einfach alles rein.
Es ist verständlich. Wenn ich eine Million Token habe, warum sollte ich mich entscheiden?
Denn selbst wenn man alles hineinstecken kann, heißt das nicht, dass alles hilft. Tatsächlich hat Lärm seinen Preis. Es kostet Token, es kostet Aufmerksamkeit, es kostet Latenz, es kostet Qualität. Ein Model kann sich genau wie wir in irrelevanten Details verlieren, wenn wir zwanzig Tabs öffnen und uns nicht mehr erinnern, warum.
Guter Kontext hat eine Hierarchie:
- Systemanweisungen und -richtlinien;
- spezifisches Ziel;
- aktueller Status;
- relevant data;
- Einschränkungen;
- verfügbare Werkzeuge;
- Verfolgen Sie die bereits getroffenen Entscheidungen.
Es besteht keine Notwendigkeit, alles auf der gleichen Ebene zu behandeln. Ein Benutzerbefehl ist mehr wert als eine alte Notiz. Ein nicht bestandener Test ist heute mehr wert als eine ästhetische Präferenz von vor drei Monaten. Eine Sicherheitsrichtlinie ist mehr wert als eine Produktionsabkürzung.
Context Engineering bedeutet auch, Gewichtungen anzugeben, nicht nur Daten.
Gedächtnis: Erinnere dich weniger, erinnere dich besser
Das Gedächtnis von Agenten ist eines der heikelsten Themen.
As a user, you want the agent to know you. Sie möchten, dass er sich an den Ton, den Plan, die Konventionen und die bereits beschlossenen Dinge erinnert. Als Ingenieur wissen Sie, dass jede dauerhafte Erinnerung auch ein Risiko darstellt: Sie kann falsch, alt, zu persönlich, zu allgemein und nicht überprüfbar sein.
Ein nützliches Gedächtnis sollte mindestens drei Eigenschaften haben:
- Herkunft: Woher kommen diese Informationen?
- Datum: Wann war es wahr?
- Zweck: Für welche Art von Aufgabe soll es verwendet werden?
Ohne diese drei Dinge wird die Erinnerung zum Aberglauben.
Ich stelle mir das Agentengedächtnis gerne als ein Arbeitsbuch vor, nicht als einen magischen Geist. Es gibt vorübergehende Notizen, bestätigte Entscheidungen, Stilpräferenzen, technische Einschränkungen und Links zu Quellen. Manche Dinge verfallen. Einige müssen neu geschrieben werden. Einige müssen eliminiert werden, weil der Agent sie falsch verstanden hat.
Ein gutes System muss diese Wartung normal machen. Nicht heroisch.
Retrieval und Werkzeuge sind nicht dasselbe
Wenn wir über Kontext sprechen, landen wir oft sofort bei RAG. Einbettung, Vektordatenbank, Chunking, Reranking.
Alles nützlich. Aber das Abrufen ist nur eine Möglichkeit, Informationen in das Modell zu bringen. Er ist nicht der Einzige.
Ein Agent kann Kontext abrufen, indem er Dateien liest, eine API abfragt, einen MCP-Server anruft, einen Browser öffnet, Tests durchführt, Slack durchsucht, sich ein Dashboard ansieht und den Menschen befragt.
Der interessante Teil besteht darin, zu entscheiden, welche Route wann genutzt werden soll.
Wenn der Agent eine historische Frage beantworten muss, reicht möglicherweise das bloße Abrufen aus. Wenn er einen Fehler beheben muss, muss er echten Code lesen. Wenn er verstehen möchte, warum eine Bereitstellung fehlschlägt, muss er sich neue Protokolle ansehen. Wenn Sie einem Kunden schreiben müssen, müssen Sie den Ton, den Verlauf und den Status des Tickets abrufen. Wenn er bei der Produktion tätig werden muss, muss er um Erlaubnis bitten.
Kontext ist keine Datenbank. Es ist ein Workflow.
Der gute Agent weiß auch, wie man ignoriert
Ein Zeichen der Reife von Agenten wird die Fähigkeit sein zu sagen: „Ich brauche diese Informationen nicht.“
Es scheint trivial, aber es ist sehr schwierig. Viele Agentensysteme akkumulieren. Jeder Werkzeugaufruf fügt Text hinzu. Jeder Fehler bleibt im Puffer. Jede gelesene Datei fügt dem Stapel hinzu. Letztendlich hat das Modell eine sehr lange Geschichte und keine Karte.
Komprimierung ist erforderlich. Eine Zwischensynthese ist erforderlich. Es muss strukturiert werden.
Nicht „das ist alles, was passiert ist“, sondern:
- Ziel noch gültig;
- aktuelle Hypothese;
- Dateien bereits überprüft;
- getroffene Entscheidungen;
- offene Risiken;
- nächste Aktion.
Dadurch wird der Agent weniger theatralisch und hilfsbereiter. Nicht weil er schlauer wirkt, sondern weil er mit einem aufgeräumten Schreibtisch arbeitet.
Kontext-Engineering für Teams, nicht für Prompt-Artists
Der Grund, warum mich dieses Thema interessiert, ist, dass es die Verantwortung vom Einzelnen auf das System verlagert.
Beim Prompt Engineering gewinnt oft derjenige, der am besten mit dem Modell sprechen kann. Beim Context Engineering gewinnt das Team, das seine Arbeit am besten organisiert: Dokumentation, Konventionen, Probleme, Protokolle, Tests, Eigentum, Benennung, Quellen.
Ein sauberes Repository wird zu einem besseren Kontext. Ein gut geschriebenes Problem wird zu besserem Treibstoff. Ein aktualisiertes Runbook erspart Token und Ärger. Ein klares Changelog reduziert Halluzinationen.
Das sind gute und etwas unangenehme Neuigkeiten. Schön, weil es gute Praktiken belohnt. Unbequem, weil man nicht alles mit einer cleveren Eingabeaufforderung lösen kann.
Die Agenten verstärken die Hygiene des Systems, das sie vorfinden.
Wie ich es morgen anwenden würde
Wenn ich Context Engineering in ein reales Projekt einführen würde, würde ich mit kleinen Dingen beginnen:
- eine kurze und gepflegte Projektanweisungsdatei;
- gute Beispiele für erwartete Ergebnisse;
- eine Liste der verfügbaren Tools und Fälle, in denen sie verwendet werden können;
- Architekturentscheidungen zitierfähig verfasst;
- Problem mit minimalem obligatorischem Kontext;
- einfach abzurufende Protokolle und Tests;
- persistentes, vom Menschen modifizierbares Gedächtnis.
Dann würde ich eine einfache Sache messen: Wie oft muss der Agent um Klarstellung bitten oder geht in die falsche Richtung?
Wenn es öfter vorkommt, würde ich nicht gleich ein größeres Modell nachrüsten. Ich würde mir den Kontext ansehen.
Meine Lektüre
Context Engineering ist ein etwas aufgeblähtes Wort, ja. Aber das Konzept ist solide.
Es erinnert uns daran, dass die Intelligenz eines Agenten nicht nur im Modell steckt. Es liegt in der Umgebung, die wir für ihn vorbereiten: was er sieht, woran er sich erinnert, was er tun kann, was ihm verboten ist, welche Quellen er als wahr erkennt.
Der menschliche Teil ist dieser: Den Kontext gut vorzubereiten ist eine Form der Fürsorge. Es geht darum, dem Agenten, aber auch dem Team zu sagen: „Ich möchte nicht, dass Sie raten, ich möchte, dass Sie das haben, was Sie brauchen.“
Weniger Magie. Saubereres Zimmer. Agenten brauchen es genauso wie wir.
Quellen
METADATA
- date: 2026-06-30
- reading: 7 min
- author: Filippo Spinella
- tags: AI, Agents, Prompting, Developer Tools