Google hat das Kontextfenster getötet.

Million-Token-Kontextfenster sollten der Cheat-Code für große Sprachmodelle sein. Anbieter werben um die Wette mit 128K, 200K, sogar 1M-Token-Eingaben, als ob schiere Kapazität zuverlässige Codier-Copiloten, autonome Agenten und vollständig durchsuchbare Wissensdatenbanken freischalten würde. Die Realität ist weniger cineastisch: Mehr Tokens bedeuten oft einfach nur langsamere, teurere und weiterhin verwirrte Modelle.

Die neuesten Forschungen von Google zur Kontextgestaltung entlarven einen Bluff. Das Unternehmen argumentiert, dass „mehr Tokens ins Spiel zu bringen, Zeit kauft, aber die Form der Kurve“ hinsichtlich Kosten, Latenz und Zuverlässigkeit nicht verändert. Mit einem 1-Million-Token-Fenster kann man die Komplexität kurzzeitig überholen, aber reale Arbeitslasten – RAG-Ergebnisse, Multi-Agent-Protokolle, Toolausgaben und Nutzerhistorie – werden schnell aufholen.

Drei harte Grenzen durchbrechen ständig die Strategie „einfach den Prompt ausfüllen“. Die erste ist die Kosten- und Latenzspirale: Jede zusätzliche 100.000 Tokens erhöht die Inferenzzeit und die Cloud-Kosten oft um das 2- bis 3-Fache in produktionsreifen Anwendungen. Die zweite ist „im Mittel verloren“, ein dokumentierter Effekt, bei dem Modelle entscheidende Anweisungen ignorieren, die in überladenen Prompts verborgen sind. Die dritte ist die Physik: Selbst Millionen-Tokens-Fenster laufen über, sobald man beginnt, Werkzeuge und Agenten über Stunden oder Tage zu verknüpfen.

Die Antwort von Google ist nicht „2 Millionen Token“, sondern eine architektonische Wende. Anstatt den Kontext als ein riesiges veränderbares Chatprotokoll zu betrachten, rahmt das Unternehmen ihn als eine kompilierte Sicht über ein reichhaltigeres, zustandsbehaftetes System. Rohdaten – Sitzungen, Erinnerungen, Artefakte – fungieren als Quellcode; eine Pipeline von Prozessoren kompiliert einen minimalen, aufgabenspezifischen Arbeitskontext für jeden Modellaufruf.

Dieser Wandel verwandelt den Kontext von einem brutalen Pufferproblem in ein Systemdesignproblem. Googles Agent Development Kit (ADK) integriert dies in einen vierlagigen Stapel: Arbeitskontext, Sitzung, Gedächtnis und Artefakte, wobei jede Schicht klare Verantwortlichkeiten und Lebenszyklen hat. Kontext hört auf, „alles, was ins Fenster passt“ zu sein, und wird zu einem expliziten Produkt von Code, Richtlinien und Bereichen.

Dieser Artikel erklärt, wie dieses Framework in der Praxis funktioniert. Mit dem Google Agent Development Kit (ADK) werden wir die Kontextarchitektur, die verschiedenen Kontextobjekte und Berechtigungen sowie einen realen Dokumenten-Recherche-Agenten analysieren, der zeigt, warum die Ära der Million-Tokens bereits vorbei ist.

Größere Kontextfenster versprechen Allwissenheit, liefern jedoch meistens nur einen Schock in Bezug auf die Kosten. Jedes zusätzliche 100.000 Token erfordert reale Dollar und Zeit, und die Produktionsteams spüren beides. Googles eigener Blog zur Kontextgestaltung beschreibt eine Kosten-/Latenzspirale: Mehr Tokens pro Anfrage, multipliziert mit Tausenden gleichzeitigen Nutzern, verwandelt "schöne Demo" schnell in "aus dem Budget gefallen".

Latenz skaliert genauso brutal. Diese Million-Token-Anfrage bedeutet langsamere Decodierung, längere Werkzeugketten und eine Benutzererfahrung, die sich von „Assistent“ zu „Ticketsystem“ verschiebt. In Multi-Agenten-Setups verbreitet sich jeder Agentenaufruf in mehr Modellaufrufe, sodass ein aufgeblähter Kontext eine gesamte Pipeline infiziert.

Dann kommt Lost in the Middle. LLMs berücksichtigen große Aufforderungen nicht gleichmäßig; sie gewichten oft den Anfang und das Ende über und ignorieren leise das Zentrum. Der Blog von Google und nachfolgende Arbeiten zeigen, dass die Genauigkeit sinkt, wenn wichtige Fakten in der Mitte einer langen Sequenz begraben sind, selbst wenn das Modell technisch alles „sieht“.

Stellen Sie sich die Aufforderung eines Produktionsagenten nach ein paar Minuten Nutzung vor. Oben: eine neue Benutzerfrage. Unten: ein aktueller Toolfehler und eine Wiederholungsanweisung. Dazwischen: die tatsächliche Richtlinienbeschränkung oder kritische Systemanweisung. Das Modell optimiert fröhlich um die Ränder herum und halluziniert über das, was tatsächlich wichtig ist.

Echte Arbeitslasten verschärfen dies. Ein einzelner Durchgang kann umfassen: - 20–50 RAG-Passagen - 5–10 Protokolle von Werkzeugaufrufen - Dutzende vorheriger Chatnachrichten

Packen Sie all das in ein „1M-Token-fähiges“ Modell, und das Kontextfenster gerät nach einer Handvoll reichhaltiger Interaktionen immer noch ins Stocken. Sogar Google Agent Development Kit (ADK) Demos zeigen, wie schnell Artefakte, Speicher und Sitzungszustände explodieren würden, wenn Sie naiv alles in das Prompt streamen.

Harsh physikalische Grenzen beenden die Arbeit. Der Kontextlängenskala wächst sublinear mit Rechenleistung und Speicher; der Sprung von 128K auf 1M Tokens erfordert bereits exotische Infrastrukturen. Gehen Sie viel höher, und Sie kämpfen nicht nur mit cleverem Prompt-Design, sondern auch mit GPU-RAM, Bandbreite und Trainingsstabilität.

Diese sind keine Laborneugierigkeiten. Sie sind die Gründe, warum Produktionsteams heimlich Geschichte kürzen, RAG-Ergebnisse verkürzen und aggressiv zusammenfassen. Solange Kontext kein roher Stream mehr ist, sondern eine kompilierte Ansicht wird, werden große Agenten weiterhin in ihren eigenen Daten ertrinken.

Die neue Idee von Googles Kontext-Compiler reißt das alte mentale Modell eines Kontextfensters als endloses Chatprotokoll heraus. Anstatt eines veränderlichen Stream-Puffers wird der Kontext zu einer kompilierten Ansicht über einen viel reichhaltigeren Zustand: Sitzungen, Erinnerungen und Artefakte, die außerhalb eines einzelnen Prompts leben. Jeder Modellaufruf sieht nur einen sorgfältig konstruierten Ausschnitt, nicht die gesamte Heuhaufen.

Denke wie ein Compiler-Entwickler, nicht wie ein Prompt-Optimierer. Rohdaten der Interaktion werden zum Quellcode; eine Pipeline von Prozessoren fungiert als Compiler; der endgültige Prompt, der an Gemini gesendet wird, ist das optimierte ausführbare Programm. Googles eigener Blog, Architektur eines effizienten kontextbewussten Multi-Agenten-Frameworks für die Produktion, macht dies zu einem zwingenden Erfordernis für Agenten im Produktionsmaßstab, nicht zu einer netten Abstraktion.

Unter diesem Modell verschiebt sich die Aufgabe des Entwicklers von „Wie formuliere ich diesen Prompt?“ zu „Wie architektoniére ich die Pipeline, die Kontext aufbaut?“ Sie gestalten, wie Sitzungen strukturierte Ereignisse speichern, wie Erinnerungen langfristiges Wissen kodieren und wie Artefakte wie PDFs oder CSVs anhand von IDs referenziert werden, anstatt sie in das Fenster zu werfen. Sie hören auf, Mega-Prompts manuell zu kuratieren, und beginnen, Flows, Prozessoren und Bereiche zu definieren.

Das Google Agent Development Kit (ADK) integriert dies in seine APIs. Es bietet verschiedene Kontextschichten—Arbeitskontext, Sitzung, Gedächtnis, Artefakte—und zwingt Sie dazu, diese über explizite Prozessoren und Zustandspräfixe wie `app`, `user` und `temp` miteinander zu verbinden. Diese Trennung von Speicherung und Präsentation bedeutet, dass Sie Tausende von Ereignissen protokollieren können, während Sie gleichzeitig ein schlankes, zielgerichtetes Prompt unter 5.000 Tokens ausgeben.

Die Leistung kommt von Standardumfang. Jede Modellanruf erhält nur den minimalen Kontext, der für seine Aufgabe erforderlich ist, und wird vom Compiler-Pipeline just-in-time zusammengestellt. Wenn ein Agent mehr Informationen benötigt, ruft er Werkzeuge auf, um Artefakte abzurufen oder im Gedächtnis abzufragen, anstatt alles „nur für den Fall“ vorab zu laden.

Dieser kompaktierte Kontextansatz adressiert alle drei Schmerzpunkte gleichzeitig. Die Token-Zahlen sinken, wodurch Kosten und Latenz ebenfalls fallen. Das „Verlorensein in der Mitte“ verringert sich, da die Mitte größtenteils verschwindet – irrelevante Historie tritt nicht in den Arbeitskontext ein. Physikalische Kontextgrenzen hören auf, eine feste Obergrenze zu sein, und werden zu einem Optimierungsbudget, das du mit Code kontrollierst.

Kontextengineering beginnt mit einem klaren Bruch zwischen dem Ort, an dem Informationen gespeichert sind, und der Art und Weise, wie das Modell sie wahrnimmt. Googles Agent Development Kit (ADK) verankert dies in seinem ersten Prinzip: Speicherung von Präsentation trennen. Das klingt abstrakt, aber es ist der Unterschied zwischen einem System, das Sie weiterentwickeln können, und einem, das unter seiner eigenen Transkription zusammenbricht.

ADK zieht eine klare Linie zwischen der Sitzung und dem Arbeitskontext. Die Sitzung fungiert als das beständige, autoritative Hauptbuch: jede Benutzeranfrage, jede Werkzeugaufruf, jedes Werkzeugergebnis und jedes Systemereignis landen hier als strukturierter Zustand. Der Arbeitskontext ist ein wegwerfbares Snapshot, das für einen einzelnen LLM-Aufruf erstellt und anschließend verworfen wird.

Betrachten Sie die Sitzung als Ihre Datenbank und den Arbeitskontext als das Ergebnis einer SQL-Abfrage. Sie ändern niemals die Datenbank, um jeder Abfrage zu entsprechen; Sie ändern die Abfrage. Das gleiche Prinzip gilt hier: Sie behalten eine vollständige, nur hinzugefügte Sitzung und erstellen je nach Aufgabe, Modell oder Latenzbudget unterschiedliche Arbeitskontexte daraus.

Diese Trennung wird entscheidend, sobald sich Ihr Produkt ändert. Möchten Sie das Gemini 3 Pro gegen ein kleineres Modell tauschen oder von einem ausführlichen Chat-Stil-Prompt zu einem prägnanten Tool-Execution-Prompt wechseln? Sie aktualisieren die Prozessoren, die den Arbeitskontext erstellen, nicht das Sitzungsschema oder historische Daten. Frühere Interaktionen bleiben intakt, selbst wenn Sie radikal ändern, wie Sie sie dem Modell präsentieren.

Das Google Agent Development Kit (ADK) Dokumentation formalisiert dies mit verschiedenen Kontextobjekten und Zustandspräfixen. Sitzungsbasierter Zustand befindet sich unter langlebigen Präfixen wie `app` und `user`, während flüchtige, nur bei Aufrufen verwendete Daten unter `temp` abgespeichert werden. Nur der Arbeitskontext liest über diese Namensräume hinweg und erstellt eine minimierte Ansicht für den aktuellen Aufruf.

Praktische Auswirkungen zeigen sich schnell in Multi-Agenten-Systemen. Ein Agent könnte einen Arbeitskontext mit nur den letzten 3 Benutzerinteraktionen und einer Tool-Zusammenfassung sehen; ein anderer erhält vielleicht eine zusammengefasste Übersicht über eine Sitzung mit 200 Nachrichten plus RAG-Treffer. Beide stammen aus demselben zugrunde liegenden Protokoll, aber jeder Aufruf zahlt nur für die Token, die er tatsächlich benötigt.

Kontextfenster wuchsen früher durch String-Verkettung: Benutzer-Nachricht, Agenten-Antwort, Tool-Ausgabe und so weiter, bis die Rechnung explodiert. Das Google Agent Development Kit (ADK) entfernt das und ersetzt es durch explizite Transformationen: eine benannte, geordnete Pipeline, die den Rohzustand in einen funktionsfähigen Prompt kompiliert. Kontext hört auf, ein Textblob zu sein, und wird zu einem Build-Artefakt.

Anstelle von `prompt = history + docs + tools` definierst du Prozessoren wie `session_zusammenfassen`, `relevante_artefakte_auswählen`, `anweisungen_injektieren` und `tokens_budgetieren`. Jeder Schritt hat einen Namen, einen Vertrag und einen Platz in der Pipeline. Du kannst jede Phase protokollieren, die Ausgaben zwischen den Durchläufen vergleichen und Prozessoren austauschen, ohne den Rest des Systems zu berühren.

Der Kontext-Blog von Google und die ADK-Dokumente beschreiben dies als einen Fluss von Prozessoren, die vier Schichten des Zustands transformieren: Sitzung, Gedächtnis, Artefakte und Arbeitskontext. Ein Dokumenten-Recherche-Agent könnte beispielsweise: - Frühere Entscheidungen aus dem Gedächtnis abrufen - Kandidat-PDFs aus Artefakten bewerten - Zitate in eine 2.000-Token-Zusammenfassung komprimieren - Einen minimalistischen Prompt für Gemini 3 Pro erstellen.

Da Prozessoren explizit sind, können Teams sie unit-testen. Sie können überprüfen, dass `select_relevant_artifacts` niemals mehr als 5 Dokumente zieht oder dass `summarize_session` unter 1.000 Tokens bleibt. Das Debugging wird von „Warum hat das Modell halluziniert?“ zu „Welcher Prozessor hat die falschen Daten injiziert?“

Scoped by Default greift die andere Hälfte des Problems an: wer sieht was. Anstatt das gesamte Multi-Agent-Protokoll in jeden Toolaufruf zu werfen, leitet ADK minimale, rollenspezifische Kontexte über typisierte Kontextobjekte weiter. Tools, Callback-Funktionen und Anweisungsanbieter erhalten jeweils eine eingeschränkte Sicht.

Toolfunktionen erhalten einen ToolContext, der den Sitzungsstatus lesen und schreiben, Artefakte speichern oder laden und im Gedächtnis suchen kann. Rückrufhandler erhalten einen CallbackContext mit Status und Artefakten, jedoch ohne Gedächtnissuche, um seitliche Chaoswirkungen zu verhindern. Anweisungsanbieter sehen einen schreibgeschützten Kontext, sodass sie den Status beim Erstellen von Systemaufforderungen nicht heimlich verändern können.

Der kontextbezogene Rahmen verwandelt Multi-Agenten-Systeme in eine KI-Produktionslinie. Eine Phase liest Artefakte und erstellt eine strukturierte Zusammenfassung; eine andere Phase, mit einem engeren Fokus, verwandelt diese Zusammenfassung in benutzerfreundliche Prosa; eine dritte Phase protokolliert die Ergebnisse zurück im Gedächtnis. Kein einzelner Agent trägt die gesamte Historie von 50.000 Tokens mit sich.

Gemeinsam erzeugen explizite Transformationen und Scoped by Default Kontextflüsse, die unter Last vorhersehbar sind. Sie wissen genau, welche Prozessoren laufen, welchen Zustand sie beeinflussen können und wie viele Token sie ausgeben. Diese Disziplin macht ein Modell mit einer Million Token optional statt verpflichtend.

Kontextbewusste Agenten im Google Agent Development Kit (ADK) arbeiten auf einem vierstöckigen Stack, der Kontext als Produkt und nicht als Nebenprodukt betrachtet. Jede Schicht beantwortet eine andere Frage: was das Modell jetzt sieht, was tatsächlich passiert ist, was bestehen bleiben sollte und wo die schweren Ressourcen gespeichert sind.

Ganz oben sitzt der Arbeitskontext. Dies ist die straffe, temporäre Nutzlast, die ADK für einen einzelnen Modellaufruf kompiliert und an Gemini sendet: ausgewählte Nachrichten, Werkzeugausgaben, Ausschnitte aus dem Gedächtnis und einige Artefaktverweise. ADK verwirft ihn sofort nach dem Aufruf, sodass nichts im Arbeitskontext von sich aus autoritativ ist.

Darunter befindet sich die Sitzung, das lang laufende, kanonische Protokoll einer Interaktion. Jede Benutzer-Nachricht, jede Modellantwort, jeder Tool-Aufruf und jedes Tool-Ergebnis landen hier als strukturiertes Ereignisobjekt, nicht als flüchtiges Transkript. Wenn ADK einen funktionierenden Kontext wiederherstellt, befragt es diese Sitzungstimeline und wendet Prozessoren an, die Ereignisse für die aktuelle Aufgabe filtern, zusammenfassen oder neu verketten.

Längerfristiges Wissen wandert in den Speicher. Der Speicher enthält Benutzerpräferenzen (Tonfall, Sprachen, Benachrichtigungsgewohnheiten), dauerhafte Fakten (unternehmenspolitische Vorgaben, Produktspezifikationen) und destillierte Entscheidungen, die über einen einzelnen Chat hinaus Bestand haben sollten. ADK erschließt dies über Speicher-Such-APIs, sodass ein Agent nur die 3–10 relevanten Elemente abrufen kann, anstatt 10.000 Tokens der Historie abzuspielen.

Artefakte lösen das Problem der „großen Datei im Prompt“. Artefakte sind große binäre oder Textobjekte – PDFs, CSVs, Bilder, Audiodateien – die einmal gespeichert und über stabile Namen oder IDs adressiert werden, anstatt in den Prompt eingefügt zu werden. Werkzeuge lesen und schreiben Artefakte, und der Arbeitskontext enthält nur leichte Referenzen sowie extrahierte Inhalte, wenn dies notwendig ist.

Zusammen bilden diese vier Schichten eine Kontextpipeline, kein Monolith. Ein Dokumentenforschungsagent könnte beispielsweise: die Sitzung lesen, um die neueste Benutzerfrage zu finden, das Gedächtnis nach früheren Entscheidungen durchsuchen, ein PDF-Dokument anhand der ID laden und dann einen funktionierenden Kontext mit nur wenigen relevanten Absätzen und Zitaten zusammenstellen. Die Kosten und die Latenz steigen mit diesem kompilierten Ausschnitt, nicht mit dem Rohdatenbestand.

Die eigenen Richtlinien von Google fordern die Teams dazu auf, diese Schichten als erstklassige Designoberflächen zu betrachten. Die ADK-Kontextdokumentation erläutert, wie Arbeitskontext, Sitzung, Speicher und Artefakte auf konkrete Typen, Berechtigungen und Prozessoren abgebildet werden, damit Multi-Agenten-Systeme schnell, kostengünstig und stabil bleiben, während die Arbeitslasten wachsen.

Der Zustand lässt eine KI hartnäckig wirken, anstatt wie ein Goldfisch, und das Google Agent Development Kit (ADK) integriert das direkt in seine Kontext-API mit einem täuschend einfachen Präfixsystem. Anstatt den Agenten eine amorphe Masse von „Gedächtnis“ zu übergeben, teilt das ADK den Zustand in temp:, user: und app: Namensräume auf, die sich klar darauf beziehen, wie echte Software tatsächlich funktioniert.

temp: Beginnen Sie mit temp:, dem Notizblock. Alles, was Sie unter `temp:` schreiben, bleibt für eine einzige Verwendung bestehen und verschwindet dann. Ein Tool kann ein analysiertes CSV unter `temp:parsed_doc` speichern, ein anderes Tool kann es 200 ms später lesen, und sobald der Agent antwortet, löscht ADK es—kein Risiko, die langfristige Historie mit vorübergehendem Müll zu verunreinigen.

Steige auf ein höheres Niveau und user: wird zum tatsächlichen Gedächtnis des Agenten für eine Person. Schlüssel wie `user:reading_level`, `user:last_projects` oder `user:blocked_sources` bleiben über Sitzungen hinweg bestehen, solange du ADK mit einem Datenspeicher verbindest. Ein in der Demo integrierter Forschungsassistent kann sich merken, welche Artikel ein Benutzer letzte Woche bereits zusammengefasst hat, und vermeiden, diese erneut abzurufen oder zu erklären.

Oben sitzt app:, der globale Zustand für die gesamte Bereitstellung. Feature-Flags (`app:enable_vision`), systemweite Ratenlimits oder Referenzen auf gemeinsam genutzte Einbettungsindizes befinden sich hier. Jede Agenteninstanz und jeder Benutzer kann diese Werte lesen, sodass Sie eine Konfiguration einmal ändern können und das Verhalten in Hunderte von gleichzeitigen Sitzungen beobachten können.

Zusammen ergeben diese drei Präfixe eine konkrete Zustands-Hierarchie, ohne ein maßgeschneidertes Framework zu erfinden. Sie erhalten: - temp: für per-Runde Verdrahtung zwischen Werkzeugen - user: für speicher pro Identität - app: für benutzerübergreifende Konfiguration

Diese Hierarchie kodiert direkt die Designprinzipien von ADK. Trennung von Speicherung und Präsentation: Der Zustand lebt unter `temp:`, `user:` oder `app:`, während der Arbeitskontext eine compilierte Teilmenge dieser Schlüssel ist. Explizite Transformationen: Werkzeuge und Prozessoren lesen und schreiben spezifische Präfixe, anstatt einen riesigen Prompt zu verändern. Standardmäßig eingeschränkt: `temp:` wird niemals über einen Durchgang hinaus geleakt, `user:` wird niemals versehentlich global und `app:` verwandelt sich niemals stillschweigend in benutzerspezifisches Verhalten.

Das Google Agent Development Kit (ADK) verwandelt all diese Konzeptionstheorien in einen funktionierenden Forschungsbot. Die Demo von Yeyu Lab erstellt einen Dokumentenassistenten, der Dateien durchsuchen, öffnen und analysieren kann, ohne jemals ganze PDFs in den Prompt zu laden. Stattdessen sammelt es genau den notwendigen Kontext für jeden Aufruf von Gemini 1.5 oder Gemini 2.0.

Zentral im Design steht ein On-Demand-Lade-Muster. Das Tool `list_documents` gibt nur leichte Metadaten zurück: Dokumenten-IDs, Titel, eventuell Byte-Größen und Zeitstempel. Das Modell sieht eine kompakte Tabelle von Optionen, nicht 200 Seiten Rohtext.

Wenn der Benutzer etwas wie „den Quartalsbericht analysieren“ auswählt, ruft der Agent `analyze_document` auf. Dieses Tool zieht die gesamte Datei aus dem Artefakte-Speicher, führt Chunking oder Zusammenfassung durch und zeigt dann die destillierten Ergebnisse dem Modell an. Das LLM erhält niemals das Originaldokument direkt; es erhält nur die bearbeiteten Teile, die es angefordert hat.

Werkzeuge koordinieren sich über den `temp:` Zustand anstelle von Payloads, die über die Verbindung gezogen werden. `list_documents` schreibt `temp.current_doc_id = "report_q2_2024"`; `analyze_document` liest denselben Schlüssel und weiß genau, welches Artefakt geladen werden soll. Keine Base64-Blobs, keine 50.000-Token-JSONs, die zwischen den Werkzeugen hin- und hergeschickt werden.

Der `temp:`-Bereich lebt für eine einzelne Invocation, was den Arbeitskontext minimal hält. Ein typischer Durchgang könnte die Nutzeranfrage, einen kurzen Systemprompt, eine kompakte Dokumentenliste und eine `current_doc_id`-Zeichenkette umfassen und dennoch wie ein reichhaltiger, mehrstufiger Workflow wirken. Das Google Agent Development Kit (ADK) kümmert sich um die technischen Details, sodass sich das Modell auf das Denken konzentrieren kann.

Langfristiges Verhalten hängt vom `user:` Zustand ab. Wenn jemand sagt: „Ich bevorzuge kurze Zusammenfassungen“, schreibt ein Tool oder Callback `user.summary_style = "brief"`. Zukünftige Aufrufe – morgen, nächste Woche, auf einem anderen Gerät – können diesen Schlüssel lesen und automatisch 3-Satz-Zusammenfassungen anstelle von 3-seitigen Ausführungen erstellen.

Präferenzen können sich anhäufen, ohne die Eingabeaufforderungen aufzublähen. Sie könnten folgendes verfolgen: - `user.domain_focus = "Finanzen"` - `user.citation_format = "APA"` - `user.summary_style = "kurz"`

Jede Invocation kompilieren nur die relevanten Teilmengen in den Arbeitskontext. Niemand spielt ein 200-Wendungen-Chatprotokoll erneut ab, nur um sich daran zu erinnern, dass der Benutzer Aufzählungspunkte hasst.

Intelligenz in diesem Agenten stammt von effizientem Werkzeuggebrauch, nicht von einem riesigen Kontextfenster. Das Modell gibt präzise Werkzeugaufrufe aus, wechselt zwischen `temp:` und `user:`-Zuständen und greift nur bei Bedarf auf Artefakte zu. Das Google Agent Development Kit (ADK) tötet effektiv die Vorstellung, man müsse jedes Mal seine gesamte Historie neu lesen, nur um intelligent zu wirken.

Prompt Engineering bedeutete einst clevere Zaubersprüche und fragile Hacks. Context Engineering, wie es im Kontextblog von Google und im Google Agent Development Kit (ADK) formuliert wird, erhebt diese Rolle zu etwas, das näher an Architektur von verteilten Systemen für Sprachmodelle heranreicht.

Anstatt sich auf einen einzigen Mega-Prompt zu konzentrieren, entwerfen Entwickler jetzt Pipelines: wie Sitzungen, Zustände, Erinnerungen und Artefakte durch Prozessoren in einen kompilierten Arbeitskontext fließen. Der vierstufige Stapel von ADK – Arbeitskontext, Sitzungsprotokoll, Langzeitgedächtnis und externe Artefakte – verwandelt „Was steht im Prompt?“ in „Welches System hat diese Ansicht produziert und warum?“

Dieser Wandel kennzeichnet eine deutliche Reifung der KI-Entwicklung. Sie definieren: - Welche Daten wo gespeichert sind - Welche Transformationen wann durchgeführt werden - Welcher Agent oder welches Tool welchen Umfang sieht

Das Verhalten hört auf, magisch zu erscheinen, und beginnt, überprüfbar zu wirken.

Die Zuverlässigkeit steigt, da jeder Kontextabschnitt ein explizites Rezept hat. Wenn ein Agent halluziniert, untersuchen Sie die Prozessoren und Präfixe, die seine Sichtweise aufgebaut haben, und nicht einen 40.000-Token großen Blob. Die Zustandspräfixe von ADK (`app`, `user`, `temp`) und die kontextabhängigen Bereiche (Tool, Callback, Invocation) geben Ihnen Hebel, um Fehler zu reproduzieren, Tests zu schreiben und über Ausfallmodi nachzudenken.

Die Vorhersehbarkeit verbessert sich, da Agenten nicht mehr gesamte Historien herunterladen. Sie fordern Artefakte über IDs an, durchsuchen den Speicher mit kontrollierten Abfragen und schreiben in eingeschränkte Zustandssegmente. Auch die Kosten sinken: Sie streamen nur den minimalen kompilierten Kontext pro Aufruf, anstatt wochenlange Protokolle in ein Millionen-Token-Fenster abzuspielen.

Für Teams, die auf Produktion abzielen, sieht dies wie ein Blueprint für Multi-Agenten-Backends aus. Ein Agent orchestriert, Spezialagenten verwalten Werkzeuge und Erinnerungen, und das Kontextszenario von ADK stellt sicher, dass jeder Aufruf genau die erforderlichen Informationen sieht. Die eigenen Dokumente von Google, einschließlich Einführung in den Gesprächs-Kontext: Sitzung, Zustand und Erinnerung, lesen sich weniger wie Tipps für Eingabeaufforderungen und mehr wie ein Leitfaden für API-Design.

Context Engineering, wie es im Google Agent Development Kit (ADK) umgesetzt ist, verwandelt LLM-Anwendungen in Systeme, die Sie entwerfen, und nicht in Zauber, die Sie anpassen. Das ist die Voraussetzung für ernsthafte, regulierte Multi-Agenten-Einsätze.

Bereit, das wirklich auszuprobieren? Beginne damit, das Google Agent Development Kit (ADK) zu installieren, dir einen Gemini API-Schlüssel zu besorgen und den Artikel über Kontext-Engineering im Google Developers Blog zu lesen: Architektur eines effizienten kontextbewussten Multi-Agenten-Frameworks für die Produktion. Dieser Beitrag definiert den vierstufigen Stack—arbeitskontext, Sitzung, Gedächtnis, Artefakte—und die drei Prinzipien, die dein Code widerspiegeln sollte.

Gehe als Nächstes direkt zur offiziellen ADK-Kontextdokumentation unter google.github.io/adk-docs/context. Konzentriere dich darauf, wie `InvocationContext`, `ToolContext` und `CallbackContext` den Zugriff auf Sitzung, Speicher und Artefakte steuern und wie die Präfixe `app:`, `user:` und `temp:` den skalierten Zustand implementieren. Betrachte diese APIs als deine Systemgrenze, nicht nur als Hilfsklassen.

Laden Sie dann die Demo von Yeyu Lab von GitHub herunter: context_demo. Führen Sie den Dokumentenassistenten aus, beobachten Sie, wie Artefakte gespeichert und durch IDs referenziert werden, anstatt sie in die Aufforderungen zu drängen, und verfolgen Sie, wie Werkzeuge den Zustand über Präfixe lesen/schreiben, anstatt Daten in freiem Text zu verstecken. Dies ist Ihre Referenzimplementierung für einen kontextbewussten Multi-Agenten-Workflow.

Für ein erstes Projekt, refaktorieren Sie eine bestehende RAG-App, um diesem Muster zu entsprechen. Ersetzen Sie Ihre „alles in den Prompt stopfen“-Logik durch:

• 1Ein Sitzungsprotokoll strukturierter Ereignisse
• 2Artefaktlagerung für PDFs, CSVs und lange Dokumente
• 3Gedächtnissuche statt das gleiche Wissen erneut zu senden.
• 4`temp:` Zustand zum Übertragen von Zwischenresultaten zwischen Werkzeugen

Sie optimieren nicht nur Eingabeaufforderungen; Sie entwerfen verteilte Systeme, die zufällig in natürlicher Sprache kommunizieren. Entwickler, die den Kontext als kompilierten Blick internalisieren – und die um Zustand, Artefakte und explizite Transformationen herum architektonisch arbeiten – werden die sein, die produktionsbereite KI ausliefern, während alle anderen weiterhin einem größeren Kontextfenster nachjagen.

Was ist Kontextengineering?

Context Engineering ist ein neues architektonisches Muster von Google für KI-Agenten. Es betrachtet den Kontext nicht als einen einzigen Textstrom, sondern als eine „kompilierte Ansicht“, die aus verschiedenen Datenquellen wie Sitzungsverlauf, Gedächtnis und externen Dateien erstellt wird, optimiert für jeden spezifischen Modellaufruf.

Warum sind große Kontextfenster ein Problem für KI-Agenten?

Obwohl sie scheinbar leistungsstark sind, führen große Kontextfenster zu einer Spirale hoher Kosten und langsamer Latenz. Sie haben auch das Problem des „Übersehens in der Mitte“, bei dem Modelle Schwierigkeiten haben, relevante Informationen in einem Meer von Lärm zu finden, was letztendlich die Skalierbarkeit und Zuverlässigkeit einschränkt.

Wie setzt Googles Agent Development Kit (ADK) diese Ideen um?

ADK bietet ein Framework mit integrierten Bausteinen für Context Engineering. Es trennt den persistenten Speicher (Sitzung, Speicher, Artefakte) vom temporären "Arbeitskontext", der an das LLM gesendet wird, und verwendet Werkzeuge sowie das Management von Zuständen, um nur das Notwendige zur richtigen Zeit zu laden.

Ersetzt Context Engineering die Retrieval-Augmented Generation (RAG)?

Es ergänzt und verfeinert es. RAG bezieht sich auf das Abrufen von Daten; Kontextengineering befasst sich damit, wie diese abgerufenen Daten (und alle anderen Kontexte) strukturiert, verwaltet und dem Modell präsentiert werden. Es bietet ein robusteres, skalierbares System für RAG-Workflows.