Context Engineering für AI Agents: Memory und Tools

Viacheslav Dubrov

2025-10-05 · Aktualisiert 2026-08-16 · 14 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Context Engineering ist die Pipeline, die vor jeder Entscheidung auswählt, was ein Model sieht: Instructions, Examples, Knowledge, Memory, Tool Definitions, Observations und Guardrails. Ein Agent handelt nicht auf Basis all dessen, was das System weiß. Er handelt auf Basis des Working Set, das für den nächsten Model Call zusammengestellt wurde.

An dieser Auswahl beginnen viele Fehler. Eine veraltete Preference wirkt aktuell. Abgerufener Text enthält eine Instruction. Ein langes Tool Result verdeckt die fehlende Vorbedingung. Eine Zusammenfassung erinnert sich an die Entscheidung, verliert aber die Information darüber, welche Datei geändert wurde.

Für Engineers, die AI Agents, Retrieval-Systeme und Anwendungen mit Tool Use entwickeln oder betreiben, besteht die praktische Aufgabe darin, für jede Agent-Entscheidung den kleinsten ausreichenden Working Set zusammenzustellen und dabei Scope, Provenance und Berechtigungen zu erhalten. Dieser Artikel zeigt, wie man eine Context Pipeline pro Entscheidung entwickelt, ihre Trust Boundaries identifiziert, testet, ob ihr Working Set die Aufgabe unterstützt, und Fehler nachvollziehbar macht, statt ein Model verantwortlich zu machen, das nur den zusammengestellten Input sieht.

TL;DR. Behandle Context als typisiertes Runtime-Artefakt mit Provenance. Wähle ihn pro Schritt aus, setze Tenant- und Permission-Scope vor dem Retrieval durch und trenne vertrauenswürdige Instructions von nicht vertrauenswürdigen Daten. Plane das Budget nach Utility, validiere Actions außerhalb des Models und evaluiere Task Outcomes statt ausschließlich die Context Length.

Context ist ein Decision Input, kein Memory

Das Context Window ist der aktuelle Input des Models plus die generierten Tokens. Es kann Conversation Turns enthalten, ist aber kein dauerhaftes Memory-System. Long-Term Memory, Document Indexes, Databases und Artifact Stores liegen außerhalb des Windows. Eine Context Pipeline entscheidet, was hineinkopiert wird.

Die Window Size ist eine Kapazitätsgrenze, keine Qualitätsgarantie. Lost in the Middle und RULER zeigen, dass Retrieval und Reasoning von Position, Task, Model und Sequence Length abhängen können. Die operative Schlussfolgerung ist nicht, dass mittlere Tokens immer ignoriert werden. Vielmehr kann das Hinzufügen relevant wirkender Tokens die Task Performance trotzdem verschlechtern.

Das Diagramm zeigt das qualitative Ergebnis der Studie, keine universelle Attention-Kurve. Liu et al. testeten Multi-Document Question Answering und Key-Value Retrieval. Häufig beobachteten sie eine bessere Performance, wenn das relevante Item am Anfang oder Ende erschien. Größe und Form des Effekts unterschieden sich je nach Model, Task und Context Length. Teste die Position als Variable in deinem eigenen Evaluation Set, statt eine feste Middle Penalty anzunehmen.

Das folgende Beispiel ist ein illustratives Pydantic Schema, keine getestete Repository-Implementierung. Es validiert ausschließlich Field Types und Literal Values. Es autorisiert den Tenant nicht, hält total_input_tokens konsistent mit items, persistiert das Manifest nicht und setzt kein Model-Verhalten durch.

from datetime import datetime
from typing import Literal

from pydantic import BaseModel

class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int

class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

Das Manifest macht einen Fehler reproduzierbar. Aus „Das Model hat halluziniert“ wird eine testbare Frage: Welche Evidence, Version, Permission Scope und Tool Schema hat es tatsächlich erhalten?

Der Assembly Lifecycle

Eine zuverlässige Pipeline führt diese Operationen in der folgenden Reihenfolge aus:

1. Trusted Request Context auflösen. Authentifiziere Actor, Tenant, Locale, Zeit und aktuellen Task State außerhalb des Models.
2. Die nächste Entscheidung auswählen. Ein Planning Step, Evidence Lookup, Tool Selection und eine Final Response benötigen unterschiedlichen Context.
3. Innerhalb des Scopes abrufen. Wende Authorization- und Tenant-Filter vor dem Semantic Ranking an, nicht erst, nachdem Documents in den Candidate Set gelangt sind.
4. Rangfolge und Budget festlegen. Wähle Items anhand von Utility, Freshness, Authority und Diversity unter einem Input Budget aus.
5. Mit Trust Boundaries assemblieren. Halte Policy in Instruction Channels und behandle abgerufenen Content als Daten. Abgerufene Instructions werden nicht zu System Policy.
6. Ein typisiertes Proposal generieren. Constrained Decoding kann unterstützte Syntax und Form erzwingen. Es macht Values jedoch nicht korrekt.
7. Validieren und ausführen. Application Code prüft Authorization, Business Rules, Tool Arguments und Postconditions.
8. Provenance und Outcome erfassen. Speichere Manifest, ausgewählte Source IDs, Referenzen auf Tool Results, Validation Result und Task Outcome.

Der Lifecycle gilt pro Entscheidung. Einen großen Context für einen gesamten Agent Run wiederzuverwenden, erzeugt veraltete Evidence und gibt jedem Schritt Zugriff auf Material, das er nicht benötigt.

Gib jeder Context Source eine Aufgabe

Instructions definieren dauerhaftes Verhalten

Instructions legen Role, Policy, Output Contract und Escalation Behavior fest. Halte stabilen Content stabil, um Prefix Caching zu verbessern, friere aber keine Values ein, die sich zur Laufzeit ändern. Eine Refund Threshold gehört in einen Policy Service oder einen versionierten Data Record, nicht dauerhaft in einen Prompt kopiert.

Instruction Hierarchy ist eine Control Boundary, keine Security Sandbox. Ein Model kann weiterhin bösartigen Text in einem abgerufenen Document befolgen. Begrenze nicht vertrauenswürdigen Content, kennzeichne ihn als Evidence statt als Instruction, beschränke Tools unabhängig davon und teste Prompt-Injection-Fälle.

Übertrage die Role Names eines Providers nicht in eine universelle Hierarchy. Die OpenAI Model Spec definiert Authority Levels für Platform- oder System-, Developer- und User-Instructions. Die Anthropic Messages API verwendet einen Top-Level-Parameter namens system sowie user- und assistant-Messages. Sie stellt in dieser API keine entsprechende developer-Role bereit. Andere Runtimes treffen andere Entscheidungen. Mappe deine Policy auf die dokumentierten Channels des Providers und setze Permissions sowie Side Effects anschließend in Application Code durch.

Task State hält Commitments fest

Conversation Prose ist für Multi-Step Work eine schlechte Source of Truth. Halte den Objective, die aktuelle Phase, abgeschlossene Actions, ausstehende Approvals, Artifact References und den Test Status explizit fest. Das Model kann diesen State für die Narration zusammenfassen. Application Code besitzt die kanonische Version.

Examples veranschaulichen Edge Decisions

Few-Shot Examples sind nützlich, wenn sie eine schwierige Boundary klären, nicht wenn sie lediglich das Schema wiederholen. Wähle Examples aus, die zur aktuellen Entscheidung passen und relevante Edge Cases enthalten. Evaluiere Example Retrieval wie Document Retrieval: Ein oberflächlich ähnliches, aber Policy-inkompatibles Example kann schlechter sein als gar keines.

Knowledge liefert Evidence

Retrieval eignet sich für aktuelle, private oder zitierfähige Fakten. Es gibt kein universell bestes top_k, keine universell beste Chunk Size, Hybrid Weight oder Reranker Cutoff. Optimiere den gesamten Pfad anhand von Questions mit bekannter Supporting Evidence.

Ein nützliches Evidence Item enthält:

• Source und stabile Document ID
• Version oder Effective Date
• Permission Scope
• zitierter Span und Location
• Retrieval- und Reranking Scores für das Debugging

Fordere das Model nicht auf, eine URL zu zitieren, die es nie erhalten hat. Logge nicht allein zum Debugging der Auswahl vollständige private Documents.

Memory liefert Scoped Continuity

Memory ist abgerufene Data mit zusätzlichen Lifecycle-Risiken. Als Design-Metadaten solltest du Subject, Provenance, Purpose, die anwendbare Consent- oder Legal-Basis-Entscheidung, Creation Time, Expiry- oder Review Policy und Deletion Path erfassen. Das anwendbare Datenschutzrecht und Product Counsel bestimmen die Rechtsgrundlage für ein Produkt und seine Daten, nicht diese Checkliste.

Feste Regeln wie „Preferences werden 365 Tage gespeichert“ sind keine portierbare Policy. Retention richtet sich nach Product Need, User Expectation und geltendem Recht. Prüfe vor dem Laden eines Memory:

1. Gehört es zu diesem authentifizierten Subject und Tenant?
2. Ist sein Purpose für diese Entscheidung relevant?
3. Ist es aktuell genug für die Verwendung?
4. Ist seine Source authoritative oder lediglich vom Model inferred?

Behandle inferred Memories als Hypothesen. Mache aus einer einzelnen Model Response nicht stillschweigend eine dauerhafte User Fact.

Tool Contracts machen Capabilities sichtbar

Tool Descriptions sollten Preconditions, Effects, Authorization Scope, Input Schema, Output Schema, Idempotency und aussagekräftige Failures erklären. Ein Schema-valider Call kann dennoch unauthorisiert oder unsicher sein.

Ersetze nach der Ausführung verbose Raw Output durch eine typisierte Observation, die das für die Entscheidung relevante Resultat und eine Referenz auf das vollständige Artifact erhält:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

Die MCP Specification standardisiert, wie Clients mit Tools, Resources und Prompts interagieren. Sie autorisiert deren Verwendung nicht und macht zurückgegebenen Content nicht vertrauenswürdig. Halte Gateway-, Credential- und Policy Checks außerhalb des Models und der Protocol Description.

Lade Details, wenn eine Entscheidung sie benötigt

Progressive Disclosure ist ein Context-Assembly-Pattern: Halte Identifiers und Trusted Task State verfügbar und lade Details anschließend für die aktuelle Entscheidung. Es ist keine Zusage, dass ein bestimmtes Token Budget für jedes Model funktioniert.

Der Router muss Authorization und Tenant Scope vor dem Retrieval anwenden. Er sollte Evidence Spans, Memory Records und Tool Schemas zurückgeben, die der aktuellen Entscheidung dienen. Das Model schlägt anschließend eine Action vor. Application Code validiert dieses Proposal vor der Ausführung. Anthropic verwendet in seiner Tool-Context Guidance dasselbe selektive Prinzip für große Toolsets. Tool Search hält Definitions außerhalb des Context Windows, bis das Model danach fragt. Miss in deinem System, ob der zusätzliche Routing-Schritt Task Success, Latency und Tokens per Successful Task verbessert.

Wie Context degradiert

Schlechter Context versagt nicht nur auf eine Weise. Das folgende Fünf-Muster-Modell der Degradation ist meine Synthese für das Debugging, die sich auf die oben genannten Long-Context-Evals und die Prompt-Injection-Forschung stützt:

• Position Loss: Die benötigte Evidence ist vorhanden, aber das Model verwendet sie aufgrund ihrer Position und der umgebenden Sequence inkonsistent. Long-Context-Evals zeigen, dass der Effekt je nach Model und Task variiert. Es gibt keinen universellen „schlechten mittleren“ Bereich.
• Poisoning: Ein falsches Memory, ein veraltetes Document, eine bösartige Instruction oder eine fehlerhafte Tool Observation gelangt in den Working Set und beeinflusst spätere Entscheidungen.
• Distraction: Relevante Evidence konkurriert mit Material, das aktuell oder semantisch ähnlich, für den aktuellen Schritt aber unnötig ist.
• Confusion: Überlappende Instructions, Examples oder Tool Descriptions lassen dem Model mehrere plausible Interpretationen des Tasks.
• Clash: Zwei scheinbar autoritative Items widersprechen sich bei einem Value, einer Policy oder der nächsten Action, und der Assembler macht weder ihre Versions noch ihre Precedence sichtbar.

Diese Failures erfordern unterschiedliche Fixes. Besseres Ranking kann bei Distraction helfen, aber keine veraltete Source reparieren. Delimiters können die Trennung von Daten und Instructions unterstützen, aber kein Tool autorisieren. Ein größeres Context Window kann mehr widersprüchlichen Content bewahren, ohne den Konflikt aufzulösen.

Wenn ein Run fehlschlägt, untersuche das Manifest und frage zunächst, welches Muster aufgetreten ist, bevor du den Prompt änderst oder eine weitere Retrieval Stage hinzufügst.

Budgetiere nach Utility, nicht nach Component Quota

Ein Context Budget reserviert zunächst Platz für den Output und weist anschließend Input der aktuellen Entscheidung zu. Gehe vom unterstützten Window des Models aus, ziehe Maximum Output und Protocol Overhead ab und packe die Candidates in den verbleibenden Raum.

Bewerte Candidates anhand von Features, die deine Evals hinterfragen können:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

Betrachte die Formel als Design-Anstoß. In einer Policy-Antwort kann Authority die Semantic Similarity dominieren. Beim Debugging kann ein aktueller fehlerhafter Log allgemeine Documentation übertreffen.

Auch die Reihenfolge ist wichtig. Halte stabile, vertrauenswürdige Instructions an den Anfang, wenn die Cache-Semantics des Providers von einem gemeinsamen Prefix profitieren. Platziere den aktuellen Task und die Entscheidung nahe bei der Evidence, auf die sie sich beziehen. Vermeide Timestamps oder Request IDs in stabilen Prefixes, wenn sie dort nicht benötigt werden.

Komprimiere, ohne State zu verlieren

Compression ist verlustbehaftet, sofern das Original nicht adressierbar bleibt. Die Evaluation von Factory Research zu drei Compression-Ansätzen über langfristige Agent Sessions fasst das Ziel als Tokens per Task, nicht als Tokens per Request. Ich leite daraus eine Engineering-Empfehlung ab: Optimiere Tokens per Successful Task, nicht Tokens per Request, unter vergleichbaren Task-Bedingungen – nicht als universelles Gesetz. Factory Research Evaluation

Verwende für unterschiedliche Materialien separate Mechanismen:

• Conversation: Fasse Decisions, Unresolved Questions und Commitments zusammen.
• Tool Observations: Bewahre typisierte Findings und Artifact References. Entferne Boilerplate und wiederholte Payloads.
• Retrieved Evidence: Halte Source IDs, Supporting Spans und Effective Dates fest, damit das System erneut abrufen kann.
• Task State: Speichere ihn außerhalb der Summary kanonisch.
• File- oder Artifact Trail: Führe einen expliziten Index der Reads, Writes, Hashes und Test Results.

Löse Compaction anhand gemessener Degradation oder einer Budget Threshold aus, die für Model und Task gewählt wurde. Veröffentliche keine generische Regel wie „bei 70 % komprimieren“, als würden alle Models am selben Punkt versagen.

Evaluiere Compression mit Probes, die eine Fortsetzung erfordern, nicht mit Lexical Overlap:

• Was ist das aktuelle Objective und die nächste Action?
• Welche Files oder Records wurden geändert?
• Welche Entscheidung wurde abgelehnt und warum?
• Welche Source unterstützt die aktuelle Aussage?
• Welche Approval steht noch aus?

Führe denselben Task mit und ohne Compression aus. Vergleiche Success, Incorrect Actions, Re-Fetches, Latency und Total Tokens.

Optimiere den Context Path

Optimierung sollte den Decision Contract erhalten. Vier Techniken sind nützlich, sobald du einen gemessenen Bottleneck hast:

Diese Techniken lösen unterschiedliche Probleme. Compaction und Context Editing können den an das Model gesendeten Content reduzieren. Selective Tool Loading verhindert, dass ungenutzte Schemas gesendet werden. Prompt Caching kann die Kosten wiederholter Prefixes reduzieren, verringert aber nicht die Anzahl der Tokens im Context Window. Partitioning verändert, welche Capabilities und Evidence jede Entscheidung erhält. Der Anthropic Tool-Context Guide macht diese Unterschiede explizit, und seine Context-Editing-Dokumentation stellt konfigurierbare Triggers statt einer universellen Threshold bereit.

Abgeschlossene History komprimieren

Ersetze alte Conversation Turns durch einen strukturierten Handoff, der Decisions, Unresolved Questions, geänderte Artifacts und den Test State festhält. Bewahre das Original-Transcript oder die Artifacts adressierbar auf, wenn Review oder Recovery dies erfordern.

Verbose Observations maskieren

Ein Tool kann seitenweise Logs zurückgeben, obwohl der nächste Schritt nur Status, Error Code und Artifact Reference benötigt. Konvertiere das Raw Result nach der Validierung in eine typisierte Observation und halte die vollständige Payload außerhalb des Prompts. Lass das Model nicht die einzige Failure-Evidence wegzusammenfassen.

Cacheable Prefixes erhalten

Provider und Runtimes können Arbeit wiederverwenden, wenn der Anfang eines Requests stabil bleibt. Halte Durable Instructions und Tool Schemas in einer konsistenten Reihenfolge und verschiebe Timestamps, Request IDs, Retrieved Evidence und den aktuellen State in das dynamische Suffix. Bestätige die Cache-Semantics des Providers, bevor du deine Architektur darauf ausrichtest.

Nach Decision partitionieren

Ein Planner, Retriever, Tool Caller und Final-Answer Step benötigen nicht dasselbe Material. Gib jedem Step nur die minimal erforderlichen Trusted Instructions, den relevanten State, Evidence und die benötigten Tools. Partitioning reduziert gleichzeitig Token Use und Capability Exposure; ob dabei notwendige Informationen entfernt wurden, können jedoch nur Task-Level Evals zeigen.

Sichere die Context Supply Chain

Die Prompt-Injection-Forschung betrachtet nicht vertrauenswürdigen externen Content als Attack Surface (Paper). Im operativen Modell dieses Artikels kann Context Poisoning über Documents, Memories, Tool Results, Skills oder frühere Assistant Messages eintreffen. Text als „untrusted“ zu markieren hilft dem Model, aber die Durchsetzung muss architektonisch erfolgen.

Die folgende Supply-Chain-Checkliste ist meine Engineering-Empfehlung. Sie überführt Protocol- und Threat-Model-Boundaries in Application Controls. Weder die MCP Specification noch das Prompt-Injection-Paper erzwingen diese vollständige Checkliste.

Verwende diese Boundaries:

1. Autorisiere vor Retrieval und Tool Execution.
2. Trenne Daten von Instruction Channels und begrenze externen Text durch Delimiters.
3. Erlaube Tools pro Step und Actor über eine Allowlist. Standardmäßig sollen keine Side-Effect Capabilities verfügbar sein.
4. Validiere Resource Identifiers, statt das Model Tenant Keys oder File Paths erfinden zu lassen.
5. Fordere für High-Impact Operations eine Confirmation gemäß Policy, nicht gemäß Model Confidence.
6. Scanne und reviewe ausführbare Skills oder Connectors vor der Installation.
7. Verhindere, dass Secrets und unverarbeiteter sensibler Context in Logs und Long-Term Memory gelangen.

Automatisches „Repair“ ist nur für Änderungen angemessen, die die Bedeutung erhalten, etwa beim Parsen eines bekannten Date Formats. Fehlende Tool Arguments mit „sinnvollen Defaults“ zu ergänzen, kann die Operation verändern. Bitte um Clarification oder lehne ab, wenn die Bedeutung unsicher ist.

Worked Example: eine Support-Anfrage zu einem API Key

Bei „Warum funktioniert mein API Key nicht?“ ist die nächste Entscheidung die Sammlung diagnostischer Evidence, nicht die Generierung der Final Response. Der Assembler könnte Folgendes aufnehmen:

• Trusted Support Policy und Response Contract
• authentifizierte Account ID und Plan aus dem Application State
• das aktuelle Ticket Objective und bereits ausgeführte Actions
• zwei aktuelle Runbook Spans, ausgewählt innerhalb des Product- und Version-Scopes
• ein Scoped Memory, dass der Key vor drei Tagen erstellt wurde, einschließlich Provenance
• check_api_key_status und search_incidents, aber keine Tools zum Löschen oder Rotieren des Keys

Das Model schlägt einen Read-Only Status Check vor. Application Code autorisiert den Account, ruft das Tool auf und erfasst eine typisierte Observation. Ein zweiter Model Call erhält die relevanten Runbook Spans zusammen mit dieser Observation. Die Final Response nennt die Runbook Version, gibt niemals den Key aus und bietet Rotation nur als separat autorisierte Action an.

Beachte, was ausgeschlossen bleibt: irrelevante Ticket History, jedes Support Example, unverarbeitete Account Dumps, Mutation Tools und Memories anderer Tenants.

Anti-Patterns explizit testen

• Das Window vollpacken: Alle Retrieved Documents, History, Memories und Tools laden, nur weil noch Capacity vorhanden ist.
• RAG überall: Semantic Retrieval für Values verwenden, die in eine Database, einen Policy Service oder den authentifizierten Application State gehören.
• Unbounded Memory: Inferred Facts ohne Scope, Expiry, Correction oder Deletion Semantics aufbewahren.
• Ein Call für jede Stage: Einen Prompt auffordern, Retrieval, Reasoning, Authorization, Mutation und Explanation ohne beobachtbare Boundaries zu erledigen.
• Schema gleich Correctness: Gültiges JSON als Beweis behandeln, dass Values, Permissions oder Business Decisions korrekt sind.
• Keine Component Evals: Nur die Final Prose bewerten und Retrieval-, Context-Selection- oder Tool-Failures übersehen.

Mache aus jedem Anti-Pattern ein Counterexample im Evaluation Set. Eine Guideline, die von keinem Task oder Trace ausgeübt wird, lässt sich leicht verletzen, ohne dass es auffällt.

Evaluiere den Assembler, nicht nur die Answer

Erstelle ein festes Task Set mit Evidence Labels, Permission Boundaries, erforderlichen Tool Calls und verbotenen Actions. Miss für jede Änderung an der Context Policy:

Verwende Ablations, um den kausalen Nutzen zu ermitteln: Entferne Memory, Reranking, Examples oder Compression jeweils einzeln. Eine Component, die Tokens hinzufügt, ohne den relevanten Slice zu verbessern, sollte nicht standardmäßig geladen werden.

Fazit

Gutes Context Engineering ist selektiv und accountable. Es füllt kein großes Window, nur weil Capacity verfügbar ist. Es erstellt einen Working Set pro Step aus Trusted Instructions, kanonischem Task State, Scoped Evidence, geprüftem Memory und erlaubten Tools.

Der Loop ist kurz: assemblieren, Manifest erstellen, Proposal generieren, validieren, ausführen und evaluieren. Wenn eine Entscheidung fehlschlägt, zeigt dieser Loop, ob Evidence, Freshness, Authority, State oder Policy fehlte. Außerdem liefert er einen Test für die nächste Änderung.

References

• Lost in the Middle — positionsabhängige Nutzung von Long Context
• RULER — Multi-Task-Evaluation der effektiven Context Length
• OpenAI Model Spec — provider-spezifische Authority Levels für Instructions
• Anthropic Messages API — System Parameter und Message-Role-Struktur
• Manage Tool Context — Selective Tool Loading, Caching und Context Editing
• Anthropic Context Editing — konfigurierbares Löschen von Tool Results und Compaction
• Model Context Protocol Specification — Protocol Concepts und aktuelle Specification
• Evaluating Context Compression for AI Agents — Tokens-per-Task-Framing und probe-basierte Evaluation
• Formalizing and Benchmarking Prompt Injection Attacks and Defenses — Threat Taxonomy und Defenses