Vier Schichten des Context Engineerings für KI-Agenten in der Produktion: Wie Deep Insight sie in funktionierendem Code anwendet

Wenn KI-Agenten in der Produktion Aufgaben wie Datenanalyse und Berichterstellung übernehmen, kann das Kontextmanagement zu einem großen Engpass werden. Ein Fenster von 200K Token klingt großzügig, bis eine reale Aufgabe den Großteil davon innerhalb von Minuten verbraucht. Datenanalyse und Berichterstellung führen dazu, dass der Agent mitten in der Ausführung scheitert, an Genauigkeit verliert oder die Kosten in die Höhe treibt. Es gibt bereits eine Fülle veröffentlichter Anleitungen zu diesem Thema, aber die einzelnen Techniken sind leichter zu lesen als anzuwenden. Zusammen angewendet machen sie einen messbaren Unterschied: In der von diesem Beitrag durchlaufenen Referenzimplementierung reduziert ein einzelnes Write-and-Execute-Tool die Token, die jedes Skript zum Kontext hinzufügt, um etwa 95 Prozent, und das Laden von Skills auf Anfrage verkleinert den System-Prompt um etwa 97 Prozent.

Diese Serie ordnet diese Anleitungen in Praktiken, die Sie direkt anwenden können. Die Engineering-Beiträge von Anthropic zusammen mit Funktionen, die in das Strands Agents SDK integriert sind, konvergieren in vier Schichten des Context Engineerings: Kontext auf Architekturebene isolieren, ihn durch Prompts steuern, ihn an das Dateisystem auslagern und ihn mit unabhängigen Agenten und Schutzmaßnahmen verifizieren. In diesem Beitrag (Teil 2) erfahren Sie, wie jede Schicht funktioniert und wie sie in funktionierendem Code aussieht. Wir haben diese Techniken angewendet in Deep Insight, einer Open-Source-Multi-Agenten-Datenanalyse-Lösung auf Basis des Strands Agents SDK und Amazon Bedrock AgentCore, die durchgehend als Referenzimplementierung dient.

Beitragsserie

• Teil 1: 5 Herausforderungen in Multi-Agenten-Systemen in der Produktion und wie Deep Insight sie gelöst hat.
• Teil 2: Vier Schichten des Context Engineerings für KI-Agenten in der Produktion: Wie Deep Insight sie in funktionierendem Code anwendet.
• Teil 3: Harness-Engineering in der Praxis: Deep Insight von der Entwicklung in die Produktion überführen. (Bald verfügbar!)

Der erste Beitrag definierte fünf zentrale Herausforderungen, die Multi-Agenten-Systeme in der Produktion lösen müssen. Er stellte vor, wie Strands Agents SDK, Amazon Bedrock und Bedrock AgentCore, sowie AWS Fargate jeweils verschiedene Ebenen des Problems adressieren, mit Codebeispielen. Dieser zweite Beitrag greift die vier Schichten des Context-Engineering-Praxis auf, die auf dieser Architektur aufsetzen, und zeigt jede davon implementiert. Der dritte Beitrag führt Sie durch die Bereitstellung und den Betrieb von Agenten in einem sicheren privaten Netzwerk auf Amazon Virtual Private Cloud (Amazon VPC) und deckt alles ab, was für den realen Betrieb benötigt wird.

Was ist Context Engineering?

Context Engineering ist die Disziplin, die Informationen im begrenzten Kontextfenster eines großen Sprachmodells (LLM) so zu optimieren, dass Agenten ihr Bestes geben. Anthropic Claude Sonnet 4.5, verfügbar auf Amazon Bedrock, bietet ein Kontextfenster von 200K, aber komplexe Produktionsaufgaben überschreiten es schnell. Beispielsweise durchläuft eine scheinbar unkomplizierte Anfrage wie „Verkaufsdaten analysieren und einen DOCX-Bericht erstellen“ mehrere Phasen: Laden und Erkunden der Daten (5 Min.), verkaufsbasierte Kategorieanalyse (3 Min.), Erzeugen von fünf Diagrammen für die Zeitreihenanalyse (10 Min.), statistische Validierung (3 Min.) und abschließende Berichterstellung (5 Min.). Zusammen verbrauchen sie über 150K Token in 15 Minuten.

Die Verarbeitung solcher Aufgaben in einem einzigen Kontext verursacht Probleme: Das Fenster läuft mitten in der Aufgabe über, veralteter Kontext verschlechtert die Leistung, und Fehler erfordern das erneute Ausführen der gesamten Pipeline. Mit wachsendem Kontext sinkt die Aufmerksamkeit für wichtige Informationen, und Ineffizienz erhöht die Kosten bei Preisen pro Token.

„Mit steigender Anzahl von Token im Kontextfenster nimmt die Fähigkeit des Modells ab, Informationen aus diesem Kontext korrekt abzurufen (Context rot).“

— Anthropic, „Effective Context Engineering for AI Agents” (2025.09)

Context Engineering löst genau diese Probleme, und es ist nicht nur eine Sammlung von Techniken. Es umfasst Architekturdesign, Prompt-Schreibung, Tool-Implementierung und Verifikation und ist eine geschichtete Disziplin, bei der jede Schicht kompensiert, was die vorherigen vermissen lassen. Dieser Beitrag beschreibt detailliert den Vier-Schichten-Ansatz, den Sie zur effizienten Verwaltung des Kontexts anwenden können.

Wie man Aufgaben bewältigt, die das Kontextfenster überschreiten

Anthropic hat mehrere Techniken für den Umgang mit langfristigen Aufgaben veröffentlicht. Deep Insight gruppiert diese Techniken in vier Schichten, wobei jede Schicht die Beschränkungen der anderen adressiert. Die folgende Tabelle stellt die vier Schichten dar.

Die folgenden Abschnitte behandeln jede Schicht der Reihe nach, indem sie angeben, was die Schicht vorschreibt, warum die vorherigen Schichten allein nicht ausreichen und wie die Praxis in Deep Insight umgesetzt wird.

1. Isolierung des Kontexts durch eine Multi-Agenten-Architektur

Geben Sie jedem spezialisierten Agenten sein eigenes Kontextfenster und übergeben Sie nur komprimierte Ergebnisse an den Orchestrator. Deep Insight tut dies mit einer Hierarchie aus Coordinator, Planner, Plan Reviewer, Supervisor und Tool Agents (Coder, Validator, Reporter, Tracker, Auditor).

Bei einem einzelnen Agenten sammelt sich die gesamte Information – von der Benutzeranfrage über Datenexploration, Analyse, Diagrammerzeugung, Validierung bis hin zur Berichterstattung – in einem Kontext an und überschreitet leicht das Fenster. Wenn jeder Agent seinen eigenen Kontext erhält, bleibt selbst der Coder, der den meisten verwendet, insgesamt unter 25K Tokens. Jeder Agent erhält nur das, was er benötigt, und signalisiert anderen mit einer Abschlussbenachrichtigung und einer kurzen Zusammenfassung.

Der Schlüssel zur Isolierung besteht darin, die gemeinsam genutzten Informationen zu minimieren. Deep Insight verwendet ein Python-Dictionary, shared_state, das nur vier Dinge speichert:

• messages: Die letzte Nachricht des vorherigen Agenten (nicht den gesamten Gesprächsverlauf).
• clues: Komprimierte Zusammenfassungen, die von jedem Agenten gesammelt werden.
• full_plan: Eine Checkliste, die vom Planner erstellt und vom Tracker aktualisiert wird.
• history: Ein kurzes Protokoll der Agentennamen und Nachrichten.

Die Hinweise verwenden ein festes CLUES_FORMAT: Statt des vollständigen Gesprächs jedes Agenten (Zehntausende von Tokens) werden nur komprimierte Kernergebnisse übergeben.

# coder_agent_tool.py -- context passing format
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the next step.*"

# After Coder completes: add only compressed result to clues
clues += CLUES_FORMAT.format("coder", response["text"])

Dieses Muster ist das in Anthropics Beitrag „How We Built Our Multi-Agent Research System“ empfohlene Muster, das ein Orchestrator-Worker-Muster beschreibt, bei dem ein Lead-Agent an spezialisierte Subagents delegiert und jeder Agent nur innerhalb seines eigenen Kontexts arbeitet. Sie müssen es nicht selbst bauen: Das agents-as-tools -Muster im Strands Agents SDK bietet diese Isolierung auf Framework-Ebene.

2. Steuerung des Kontextzuflusses durch Prompts

Die Isolierung der Schicht 1 allein ist nicht ausreichend: Selbst mit unabhängigen Kontexten bläht ein Agent, der lange Antworten generiert, den Kontext des Supervisors auf. Schicht 2 begrenzt die Ausgabe jedes Agenten durch Prompts.

Für Deep Insight verwenden wir Prompts, um zu begrenzen, wie viele Informationen jeder Agent an den Supervisor zurückgibt. Drei Regeln erledigen den größten Teil der Arbeit, wie Deep Insights Prompts zeigen.

„Beginnen Sie mit dem stärksten Modell und einem einfachen Prompt. Fügen Sie dann schrittweise spezifische Anweisungen basierend auf tatsächlich beobachteten Fehlerfällen hinzu.“

— Anthropic, „Effective Context Engineering for AI Agents“ (2025.09)

Implementierungsdetail 2-1: Explizite Ausgabe-Token-Budgets pro Agent

Der Prompt jedes Agenten gibt eine maximale Antwort-Token-Anzahl vor, wodurch lange Antworten vermieden werden, die den Kontext des Supervisors verschmutzen.

Anthropics Beitrag „ Writing Effective Tools for Agents“ schlägt vor, Tools eine Option CONCISE oder DETAILED für eine effiziente Kontextnutzung zu geben. Wendet man dieselbe Idee eine Ebene höher an, im System-Prompt jedes Agents. In Deep Insight teilen sich alle Agents ein standardisiertes Format:

## Status
[SUCCESS | PARTIAL_SUCCESS | ERROR]
## Completed Tasks
- [Task 1 from FULL_PLAN -- use exact wording so Tracker can match]
- [Task 2 -- be specific, not generic]
## Key Insights
- [Key finding 1 with numbers and ratios]
- [Key finding 2 with business implications]
## Generated Files
- ./artifacts/chart.png -- brief description
- ./artifacts/calculation_metadata.json -- N calculations

Implementierungsdetail 2-2: Philosophie eigenständigen Codes

Der Prompt des Coder-Agents besagt ausdrücklich, dass „Variablen nicht zwischen Skripten persistent sind“. Jedes Skript muss alle notwendigen Imports enthalten und Daten direkt laden. Der Prompt bietet sowohl falsche als auch korrekte Beispiele:

# WRONG -- Attempting to use a variable from Turn 1 in Turn 2
# Turn 1:
df = pd.read_csv('data.csv')
total = df['Amount'].sum()

# Turn 2:
print(f"Total: {total}")  # NameError: name 'total' is not defined

# CORRECT -- Every script is self-contained
import pandas as pd
df = pd.read_csv('./artifacts/cache/df_main.csv')  # Load from cache
total = df['Amount'].sum()
print(f"Total: {total}")

Der Grund, warum diese Regel mit Context Engineering zusammenhängt, ist, dass das Referenzieren von Variablen aus vorherigen Skripten erfordert, dass der Agent sich frühere Unterhaltungen „merkt“, was bedeutet, dass vergangener Code im Kontext bleiben muss. Das Prinzip des eigenständigen Codes bedeutet, dass vergangener Code sicher aus dem Kontext entfernt werden kann.

Implementierungsdetail 2-3: Regel zur Abschnittsfertigstellung des Supervisors

Der Prompt des Supervisors enthält die Regel „Do not move to the next agent until all checklist items in the current agent’s section are marked [x].“ Wir formulieren diese Regel im Prompt, weil die Entscheidung, ob die Arbeit des Coders abgeschlossen ist, erfordert, dass der Supervisor den Plan anhand der Informationen aus den Updates des Trackers interpretiert. Diese Einschätzung lässt sich schwer allein in Code ausdrücken.

3. „Nur Zeiger im Kontext, tatsächliche Daten in Dateien“

Schicht 1 isoliert den Kontext zwischen Agents, und Schicht 2 begrenzt die Ausgabe innerhalb der Agents. Aber wenn der Coder-Agent 100 Zeilen Python-Code generiert, gelangt dieser Code selbst in den Kontext. Selbst mit Prompt-Anweisungen wie „antworte kurz“ lässt sich mancher Code nicht kurz schreiben. Schicht 3 nutzt Tool-Design, um schwere Inhalte aus dem Kontext hinaus ins Dateisystem zu verlagern. Vier Techniken bringen den größten Nutzen, wie die folgenden Implementierungsdetails zeigen.

Implementierungsdetail 3-1: Verlagerung von Code aus dem Kontext mit Write- und Execute-Tool

Der Coder liest den Analyseplan, schreibt Python und führt es aus, um Visualisierungen zu erzeugen. Aber wenn der Code lang wird, fügt der konventionelle Ansatz (getrennte File-Write- und Execute-Tools) pro Skript 100 Zeilen direkt zum Kontext hinzu und akkumuliert über 1,000 Zeilen.

Die Lösung besteht darin, die beiden Schritte zu einem einzigen Tool zusammenzufassen, sodass der Code nie als Nachricht in den Kontext gelangt. Der Coder-Agent von Deep Insight verwendet dafür ein write_and_execute_tool hierfür.

Hier ist ein Teil des write_and_execute_tool. Nach dem Schreiben und Ausführen der Datei gibt es nur eine Zusammenfassung zurück: „Wrote 105 lines, execution successful, completed analysis of five categories.“ Der Code bleibt in der Datei, und etwa drei Zeilen Zusammenfassung bleiben im Kontext. Basierend auf diesem Beispiel werden dadurch etwa 95 Prozent der Tokens gespart.

# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
    """Write a Python script and immediately execute it."""
    # Step 1: Write file
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)
    # Step 2: Execute immediately
    result = subprocess.run(
        f"python {file_path}",
        shell=True,
        capture_output=True,
        timeout=timeout
    )
    # Return only summary
    return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
        f"Execution successful\n" \
        f"Output: {result.stdout[:500]}"  # Only first 500 chars

„Server-seitige Filterung: Filtern von Daten auf der Ausführungsebene, bevor sie den Kontext erreichen, 98.7% Token-Reduktion (150K auf 2K).“

— Anthropic, „Code Execution with MCP” (2025.11)

Implementierungsdetail 3-2: Wiederverwendung gemeinsamer Logik als Module im Coder-Agent

Gemeinsame Module werden über Analysen hinweg wiederverwendet. Statt sie jedes Mal neu zu generieren, definiert man häufig verwendete Funktionen einmal als Modul und importiert sie, was Token-Verschwendung und Kontext-Duplizierung verhindert.

Ohne dies erzeugen Definitionen von Funktionen wie to_python_type() oder track_calculation() in jeder Analyse 200–300 Zeilen doppelten Code über 10 Analysen hinweg. Deep Insight generiert vor der ersten Aufgabe ein Modul namens coder_analysis_utils.py vor der ersten Aufgabe. Es enthält Funktionen zur Konvertierung von numpy-Typen, zur Nachverfolgung von Berechnungsmetadaten und zum Speichern als JSON. Nachfolgende Analysen importieren es und ersetzen dadurch 20–30 neu generierte Zeilen durch zwei Importzeilen, was Tokens spart und Konsistenz sowie Debugging verbessert.

# coder_analysis_utils.py -- common module generated before first task
import numpy as np
import json
from datetime import datetime

_calculations = []

def to_python_type(value):
    """Convert numpy/pandas types to Python native types"""
    if isinstance(value, (np.integer, np.int64)): return int(value)
    elif isinstance(value, (np.floating, np.float64)): return float(value)
    elif isinstance(value, np.ndarray): return value.tolist()
    return value

def track_calculation(calc_id, value, description, formula,
                      source_file, source_columns, importance):
    """Track calculation metadata -- Validator independently verifies later"""
    _calculations.append({
        "id": calc_id, "value": to_python_type(value),
        "description": description, "formula": formula,
        "source_file": source_file, "source_columns": source_columns,
        "importance": importance
    })

def save_calculation_metadata(path="./artifacts/calculation_metadata.json"):
    """Save all tracked calculations to JSON"""
    with open(path, 'w', encoding='utf-8') as f:
        json.dump({"generated_at": datetime.now().isoformat(),
                   "calculations": _calculations}, f, ensure_ascii=False, indent=2)

Implementierungsdetail 3-3: Speichern und Teilen von Analyseergebnissen durch strukturierte Notizen

Wir verwenden strukturierte Notizen, um detaillierte Analyseergebnisse zu teilen, ohne sie durch den Kontext jedes Agents zu leiten. Deep Insight speichert diese Ergebnisse in einer Datei namens all_results.txt, die anschließend von Agents bei Bedarf gelesen wird.

Zum Beispiel fügt der Coder-Agent Ergebnisse hinzu in all_results.txt nach jeder Analyseaufgabe:

with open('./artifacts/all_results.txt', 'a', encoding='utf-8') as f:
    f.write(f"""
## Category Sales Analysis (completed at: 14:32)
- Top revenue category: Fruit (417,166,008 KRW, 45% of total)
- Top 3 categories: Fruit, Vegetables, Meat (78% of total)
- Generated file: ./artifacts/category_sales_chart.png
""")

Der Coder zeichnet detaillierte Ergebnisse nach jeder Analyse in dieser Datei auf, und der Reporter liest sie beim Verfassen des Abschlussberichts. Andere Agenten arbeiten auf die gleiche Weise über all_results.txt zusammen.

Ohne Notizen macht der Coder dem Supervisor nach jeder Aufgabe detaillierte Ergebnisse mit, die sich in seinem Kontext ansammeln. Mit Notizen wird nur eine ungefähr 30 Token lange Nachricht wie „Kategorieverkaufsanalyse abgeschlossen, 3 zentrale Erkenntnisse gefunden, detaillierte Ergebnisse in all_results.txt gespeichert“ übergeben, und der Reporter liest die Datei bei Bedarf.

Das Muster lässt sich über eine einzelne Datei hinaus verallgemeinern. Das Dateisystem selbst kann als Kommunikationsbus zwischen den Agenten dienen, wie es bei Deep Insight der Fall ist:

„Der ’Just in time‘-Ansatz, der Daten zur Laufzeit dynamisch in den Kontext lädt, anstatt alle relevanten Daten im Voraus zu verarbeiten, hält den Kontext frisch, relevant und anpassungsfähig an den sich entwickelnden Zustand der Aufgabe.“

— Anthropic, „Effective Context Engineering for AI Agents” (2025.09)

Implementierungsdetail 3-4: Laden nur des benötigten Wissens mit Skills

Statt alles Spezialwissen in den Systemprompt zu packen, wird es mit diesem Ansatz nur bei Bedarf geladen. Die Aufnahme jedes Skill-Leitfadens (Datenstrukturprüfung, README-Generierung, Skill-Erstellung, Systemprompt-Schreiben, Tool-Erstellung) würde mehr als 20K Tokens hinzufügen, bei jedem Aufruf unnötige Informationen in den Coder-Agenten laden und einen Redeploy erzwingen, um einen Skill hinzuzufügen.

Deep Insights Skills-System lädt beim Start nur einen Skill-Katalog von etwa 500 Tokens, wobei die Skill-Liste nur Namen und kurze Beschreibungen enthält. Wenn ein Benutzer „Erstelle eine README-Datei“ anfordert, entscheidet der Agent „Ich brauche den readme-generator-Skill“ und ruft skill_tool(skill_name="readme-generator")auf. Der SkillLoader liest readme-generator/SKILL.md und gibt einen detaillierten Leitfaden von etwa 3K Tokens zurück.

# 1. Skill Discovery (at initialization)
from src.utils.skills.skill_utils import initialize_skills
available_skills, skill_prompt = initialize_skills(
    skill_dirs=["./skills"],
    verbose=True
)

# 2. Add to System Prompt (~500-token catalog)
system_prompt = base_prompt + skill_prompt

# 3. Runtime -- Agent loads skill when needed
# Agent decides: "This is README generation, I need the readme-generator skill"
# -> skill_tool(skill_name="readme-generator")
# -> Returns full SKILL.md content (~3K tokens)

Jeder Skill ist als SKILL.md -Datei definiert, die aus YAML-Frontmatter und einem detaillierten Markdown-Leitfaden besteht. Er enthält Metadaten wie Name, Beschreibung, Lizenz und allowed-tools sowie Overview, When to Use This Skill, detaillierte Anweisungen und Best Practices. Um einen neuen Skill hinzuzufügen, erstellt man ein neues Verzeichnis unter skills/ und schreibt eine SKILL.md-Datei, und er wird automatisch erkannt.

Beim Start lädt der Agent einen Skill-Katalog von etwa 500 Tokens, anstatt mehr als 20,000 Tokens für vollständige Leitfäden zu verschwenden (etwa 97 Prozent weniger). Bei Bedarf kann er zusätzlich einige tausend Tokens an detaillierten Anweisungen für Skills laden.

4. Qualitätssicherung mit Verifizierungsagenten und Sicherheitsvorkehrungen

Selbst mit den Layers 1–3 bleibt ein Risiko bestehen: Isolierte Agenten können die Arbeit der anderen nicht sehen, sodass der Reporter einen Fehler des Coders in den Bericht überträgt. Layer 4 ist die letzte Verteidigungslinie.

„Stellen Sie Testwerkzeuge bereit, damit der Agent Funktionen selbst überprüfen und Fehler beheben kann, die allein aus dem Code nicht ersichtlich sind. Lassen Sie das Modell seinen Fortschritt mit aussagekräftigen Commit-Messages in git committen und Fortschrittszusammenfassungen in einer Fortschrittsdatei schreiben.“

— Anthropic, „Effective Harnesses for Long-Running Agents” (2025.11)

Implementierungsdetail 4-1: Tracker-, Validator- und Auditor-Agenten: Fortschrittsverfolgung und Qualitätssicherung

Der Tracker aktualisiert die Checkliste des Plans in Echtzeit. Wenn der Coder das Laden der Daten abschließt, ruft der Supervisor den Tracker auf, der den Planpunkt auf Basis von Informationen wie „Dat laden abgeschlossen (1,000 Zeilen, 5 Spalten)“ von [ ] auf [x] basierend auf Informationen wie „Data load complete (1,000 rows, 5 columns).“ Dies hilft sowohl den Nutzern als auch dem System, genau zu wissen, wo der Fortschritt steht.

Der Validator führt die Berechnungen des Coders unabhängig erneut aus, um die Genauigkeit zu überprüfen. Er liest calculation_metadata.json, wiederholt jede Berechnung anhand der Quelldaten und vergleicht: Übereinstimmungen innerhalb von 0.01 bestehen, Abweichungen werden markiert. Verifizierte Berechnungen gehen an citations.json , damit der Reporter sie zitieren kann. Nachdem der Reporter fertig ist, prüft der Auditor das endgültige DOCX gegen citations.json und calculation_metadata.json , ohne diese zu verändern. Er erfasst Zitierfehler in audit_findings.json und kann vom Reporter bis zu zwei gezielte Korrekturdurchläufe anfordern.

Implementierungsdetail 4-2: Priorisierung der zu verifizierenden Berechnungen

Jede Berechnung zu verifizieren ist ineffizient, daher should der Umfang der Verifizierung nach Wichtigkeit begrenzt werden. Deep Insights OptimizedValidator wendet die folgenden Schwellenwerte an:

• Mehr als 50 Berechnungen: aggressives Filtern, alle high verifizieren plus nur 10 medium.
• Mehr als 20 Berechnungen: moderates Filtern, alle high verifizieren plus 15 medium.
• 20 oder weniger Berechnungen: den größten Teil verifizieren, alle high plus alle medium plus 5 low.

Außerdem wird ein typsicherer Vergleich angewendet: Um Probleme durch den Unterschied zwischen numpy- und Python-Typen zu vermeiden, werden alle Werte in float() konvertiert und auf eine absolute Differenz unter 0.01 geprüft:

# validator.md -- type-safe numerical comparison
try:
    match = abs(float(expected) - float(actual)) < 0.01
except:
    match = str(expected) == str(actual)

Implementierungsdetail 4-3: SummarizingConversationManager: das letzte Sicherheitsnetz

Der Kontext kann in Ausnahmefällen trotzdem überlaufen, daher sollte ein Sicherheitsnetz unter den anderen Schichten bestehen. Deep Insight verwendet dafür den SummarizingConversationManager im Strands Agents SDK.

# strands_sdk_utils.py -- safety net configuration at agent creation
agent = Agent(
    model=llm,
    system_prompt=system_prompts,
    tools=tools,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.5,  # summarize oldest 50% on overflow
        preserve_recent_messages=10,  # always preserve 10 most recent messages
        summarization_system_prompt=apply_prompt_template("summarization", {})
    )
)

Bei einem Überlauf fasst das LLM die ältesten 50 Prozent der Nachrichten in einer zusammen, während stets die 10 zuletzt erhaltenen Nachrichten bewahrt werden, um den Kontext der aktuellen Aufgabe zu behalten. Der Summarization-Prompt (summarization.md) verlangt, dass clues, plansund tracking status wörtlich erhalten bleiben.

Implementierungsdetail 4-4: Selektives Prompt-Caching zur Kostenoptimierung

Context Engineering umfasst auch Kostenoptimierung, nicht nur Token-Einsparungen. Aktivieren Sie Prompt-Caching pro Agent, abhängig davon, wie oft jeder mit demselben Prompt aufgerufen wird. Deep Insights Einstellungen pro Agent:

Agents mit aktiviertem Caching fügen Cache-Punkte in System-Prompts und Tool-Definitionen ein und senken damit die Eingabe-Token-Kosten bei wiederholten Aufrufen um bis zu 90 Prozent. Dies ist eine Funktion, die vom Strands Agents SDK nativ unterstützt wird. Plan Reviewer erscheint nicht in der Tabelle, da es sich um einen Human-in-the-Loop-Schritt handelt, der die Zustimmung oder Rückmeldung des Nutzers einholt, statt ein Modell aufzurufen.

Fazit

Dieser Beitrag hat den vierschichtigen Engineering-Ansatz beschrieben, mit dem Sie den Kontext für komplexe Aufgaben, die das Kontextfenster überschreiten, effizient verwalten können.

• Schicht 1 (Isolation auf Architekturebene): Jeder Agent arbeitet in einem unabhängigen Kontext durch eine Multi-Agent-Architektur, wobei nur komprimierte Zusammenfassungen übergeben werden.
• Schicht 2 (promptbasierte Steuerung): Output-Token-Budgets, standardisierte Antwortformate und die Philosophie eigenständigen Codes begrenzen aktiv den Kontextzufluss.
• Schicht 3 (Nutzung des Dateisystems): write_and_execute_tool hält Code außerhalb des Kontexts, das Dateisystem dient als Kommunikationsbus zwischen Agents, und Wissen wird nur bei Bedarf lazy geladen.
• Schicht 4 (Verifikation und Sicherungen): Die unabhängige Neuberechnungsprüfung des Validators, das schreibgeschützte Zitat-Audit des Auditor für den Abschlussbericht, die Fortschrittsverfolgung des Tracker, die Overflow-Verhinderung durch SummarizingConversationManager sowie selektives Prompt-Caching verwalten Qualität und Kosten zugleich.

Jede Schicht bildet ein Verteidigungssystem, das ausgleicht, was die vorherigen Schichten übersehen. Wenn die Architektuolisolation nicht ausreicht, begrenzen Prompts die Ausgabe. Wenn Prompts nicht ausreichen, halten Tools Inhalte extern. Und wenn Probleme dennoch auftreten, fängt die Verifikation sie auf.

Jede dieser Schichten ist in Anthropics Engineering-Beiträgen dokumentiert, “Effective Context Engineering for AI Agents”, “Code Execution with MCP”, sowie „How We Built Our Multi-Agent Research System“. Vieles davon, was sie empfehlen, ist bereits im Strands Agents SDK enthalten und muss nicht selbst gebaut werden: SummarizingConversationManager, Prompt-Caching und das Agents-as-Tools-Muster.

Beim Bau von Produktions-Agents reicht das Kontextfenster des LLM allein selten aus. Wenden Sie diese Context-Engineering-Techniken an, um Kontext effizient zu verwalten und Ihre Agents für Produktions-Workloads zu skalieren.

Deep Insight, die hier verwendete Referenzimplementierung, ist Open Source. Sehen Sie sich den Code an und erweitern Sie ihn für Ihre Domäne.

• GitHub
• Workshop

Über die Autoren