Prompt Engineering für Agenten

Was ist Prompt Engineering für Agenten?

Prompt Engineering für Agenten bezeichnet die Engineering-Disziplin, mit der ein AI Agent über mehrere Inference-Turns hinweg konsistent das gewünschte Verhalten zeigt. Während klassisches Prompt Engineering (2022–2023) das Verfassen eines einzelnen, klugen Instruktions-Strings meinte, ist bei einem Agenten das Kontextfenster kein statischer Text mehr, sondern ein dynamisch komponierter Systemzustand: System-Prompt, Tool-Definitionen, Tool-Ergebnisse, Gesprächsverlauf, abgerufene RAG-Chunks, Scratchpad-Notizen und strukturierter State.

Andrej Karpathy beschrieb diese Verschiebung am 25. Juni 2025 als „the delicate art and science of filling the context window with just the right information for the next step", einen Tag nachdem Shopify-CEO Tobi Lütke denselben Begriff geprägt hatte. Anthropic formalisierte ihn am 29. September 2025 in „Effective context engineering for AI agents" als „die natürliche Weiterentwicklung von Prompt Engineering". Wichtig für die Einordnung: Context Engineering subsumiert Prompt Engineering, es ersetzt es nicht. Ein guter System-Prompt bleibt notwendige Bedingung; er ist nur nicht mehr hinreichend.

Diese Hub-Seite gibt den Überblick über die fünf zentralen Bausteine: System-Prompts, Tool-Beschreibungen, Planungs-Loops (ReAct), Context-Window-Management und Evaluation.

System-Prompt-Architektur

Der System-Prompt ist das einzige Stück Kontext, das ein Agent in jedem Turn sieht — er ist Code: versioniert, reviewbar, diffbar. Production-System-Prompts strukturieren sich 2026 konsistent in vier Schichten:

Anthropic empfiehlt, diese Sektionen über XML-Tags oder Markdown-Header zu trennen — das Modell parst strukturierte Prompts zuverlässiger. Die richtige Länge nennt Anthropic „the right altitude": Practitioner-Reports konvergieren auf 500–3.000 Tokens für den Kern (ohne Tool-Schemas). Beide Extreme schaden: Zu lange Prompts mit 47 nummerierten Regeln führen dazu, dass das Modell späte Regeln seltener anwendet (Lost-in-the-Middle im eigenen System-Prompt); zu vage Prompts („Du bist ein hilfreicher Assistent") überlassen zu viel der Modell-Inferenz.

Eine zentrale Verschiebung betrifft absolute Regeln: OpenAIs GPT-5-Guidance (2026) warnt explizit, ALWAYS/NEVER nur für echte Invarianten zu nutzen — „for judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead". Für DACH-Teams gilt zusätzlich: die Antwortsprache stets explizit setzen (Frontier-Modelle defaulten sonst auf Englisch bei technischem Content), und Höflichkeitsform (Sie/Du) explizit pinnen, um Style-Drift im Loop zu vermeiden.

Tool-Beschreibungen: Wo Agenten tatsächlich scheitern

Wenn ein Production-Agent fehlerhaft handelt, liegt die Ursache nach Anthropics eigener Engineering-Erfahrung „in den meisten Fällen" nicht beim Modell, sondern bei der Tool-Definition. Die Leitfrage lautet: „If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better."

Entscheidend ist, dass Tool-Beschreibungen Teil des Prompt-Budgets sind. Jedes Tool fügt 100–300 Tokens „always-on" hinzu; ein 10-Tools-Katalog kostet 1.000–3.000 Tokens pro Call. Die wirkungsvollste, meist vergessene Komponente ist die When-not-to-use-Klausel: Existieren search_web und query_internal_db parallel, entscheidet diese Klausel über die Tool-Selektion. Tool-Overlap — zwei Tools, die plausibel dieselbe Query beantworten — ist das einzige Problem, das kein noch so guter Prompt löst.

Die empirische Evidenz ist deutlich. Mit Anthropics tool_search-Tool und defer_loading: true für selten genutzte Tools stieg die Tool-Selection-Accuracy in internen MCP-Evals auf Opus 4 von 49 % auf 74 %, auf Opus 4.5 von 79,5 % auf 88,1 % (Anthropic, November 2025), bei rund 85 % Token-Einsparung. Ab etwa 10 aktiven Tools beginnt messbare Degradation. Das Produktions-Pattern lautet daher 3–7 always-loaded Tools plus Tool-Search für den Rest.

Weitere belastbare Konventionen: Verb-Noun-Namen (get_user, send_email), Field-Level-Descriptions mit Semantik, dokumentierte Return-Formate und Failure-Modes, search-fokussierte statt list-all-Tools, sowie harte Response-Token-Limits (Anthropic-Richtwert ~25.000 Tokens pro Tool-Return). DACH-Praxis: Tool-Namen und Parameter englisch (Interoperabilität), Descriptions in der Runtime-Sprache des Agents.

Planungs-Loops: ReAct und seine Nachfolger

Planung ist die Struktur der Entscheidungsschleife eines Agents. Vier Patterns dominieren 2026, mit klaren Trade-offs:

ReAct interleavt Reasoning und Handeln (Thought → Action → Observation) und ist der robuste Default für nicht-reasoning Modelle. Bei Reasoning-Modellen verschiebt sich das Bild: Interleaved Thinking (Anthropic Claude mit Extended Thinking, OpenAI o-Serie/GPT-5) lässt das Modell zwischen Tool-Calls neu planen und kollabiert damit viele klassische „ReAct-in-a-Loop"-Implementierungen in einen einzigen API-Call. In der Praxis nutzen Production-Agents Hybride: eine ReAct-Schleife mit explizitem Planning-Step zu Beginn und Verifikation vor irreversiblen Aktionen.

Disziplinierte Termination ist die wichtigste Absicherung — Infinite Loops waren die häufigste Production-Bug-Klasse 2025–2026. Robuste Loops kombinieren Max-Iterations (Hard-Cap, typisch 10–30 general, 50–100 für Coding), ein Success-Criterion (z. B. ein submit_final_answer-Tool), Cost-Caps, Repeated-State-Detection gegen Tool-Thrashing und einen Human-Escalation-Pfad.

Context-Window-Management

Lange Kontextfenster sind 2026 verfügbar (Claude Opus 1M, Gemini 2M Tokens), aber nicht uniform nutzbar. Chromas „Context Rot"-Studie (Juli 2025, 18 Frontier-Modelle) belegt: alle Modelle degradieren mit zunehmender Input-Länge. Drei Mechanismen verstärken sich: Lost-in-the-Middle (Liu et al., Stanford/TACL 2024 — Modelle attendieren auf Anfang und Ende, schlecht in der Mitte), Attention-Dilution und Distractor-Interference. Als Heuristik liegt die effektive Kapazität bei 30–50 % der nominalen für reasoning-heavy und 60–80 % für retrieval-heavy Tasks — wer ein 1M-Window komplett füllt, betreibt Verschwendung mit Quality-Penalty.

Lance Martin (LangChain) hat dafür die kanonische Vier-Pillar-Taxonomie geprägt, die Anthropic und Manus übernommen haben:

• Write — Information außerhalb des Fensters persistieren (Scratchpads, todo.md, Memory-Store)
• Select — die richtigen Tokens pro Step hereinholen (RAG, Tool-Filtering, Sub-Agent-Dispatch)
• Compress — nur task-relevante Tokens behalten (Summarisierung, Anthropic Context-Editing)
• Isolate — Kontext über Sub-Agents und Schema-Felder aufteilen

Drei Hebel dominieren die Ökonomie. Prompt Caching ist der wichtigste: Anthropic-Cache-Reads kosten rund 10 % der Standard-Input-Rate (≈90 % Discount), OpenAI bietet rund 50 %. Eine arXiv-Studie (Februar 2026, „Don't Break the Cache") misst über Agentic-Workloads 41–80 % geringere API-Kosten und 13–31 % kürzere Time-to-First-Token durch strategisches Cache-Block-Control. Pruning entfernt alte Turns und stale Tool-Results. Compaction komprimiert bei 70–85 % Kapazität — in Claude Code via /compact, das laut Anthropic „architectural decisions, unresolved bugs, and implementation details" bewahrt und redundante Tool-Outputs verwirft. Sub-Agent-Dispatch wirkt als Compaction-Primitiv: ein Sub-Agent exploriert in eigenem Fenster und liefert nur eine 1.000–2.000-Token-Zusammenfassung zurück.

Evaluation: Wenn du nicht misst, hast du nichts getan

Die brutalste Einsicht für Tech Leads lautet: Context-Engineering-Änderungen werden durch Evals validiert, nicht durch Intuition. Hamel Husains meistzitierter Rat — „Look at your data" — bedeutet konkret: 50–100 echte Production-Traces lesen, Failures frei labeln, in eine Taxonomie clustern, pro häufigem Modus einen Code-Eval oder einen LLM-as-Judge-Eval schreiben und diese in CI/Monitoring integrieren.

Husain warnt dabei vor reinem Eval-first-Development: „Write evaluators for errors you discover, not errors you imagine." Der praktikable Mittelweg startet mit einem kleinen End-to-End-Eval (10–50 repräsentative Tasks), iteriert und baut spezifische Sub-Evals für reale Failure-Modes. Eine ernüchternde, empirisch belegte Erkenntnis: viele populäre Prompt-Tipps („Du bist ein Experte", „Think step by step", „I'll tip you $200") zeigen in rigorosen Evals minimale oder keine Verbesserung — auf Reasoning-Modellen ist „think step by step" bereits Default-Verhalten und manuell oft kontraproduktiv.

Production-Reife heißt: Evals laufen automatisch bei jeder Änderung an Context, Tools oder Retrieval — PR-Eval (20–50 Tasks) blockiert Merge, Pre-Deploy-Eval (200–2.000 Tasks) blockiert Deploy, Post-Deploy-Eval auf Production-Traces betreibt Drift-Detection. Structured-Output-Enforcement schließt den Kreis: OpenAI Structured Outputs (GA seit August 2024) und Anthropic Tool-Use mit JSON-Schema liefern 100 % Schema-Adherence und ersetzen das frühere „JSON parsen und hoffen".

DACH-Bezug und Compliance

Für DACH-Teams (Deutschland, Österreich, Schweiz) kommen drei harte Engineering-Constraints hinzu. Erstens die deutsche Tokenisierung: Compound-Nouns und Flexion erzeugen 30–50 % mehr Tokens pro äquivalentem Inhalt als Englisch. Ein 200K-Window fasst damit nur ~130–150K Tokens deutschen Inhalts — höhere Kosten, aber auch höherer Caching-ROI, weil der 90 %-Discount auf eine größere Token-Zahl durchschlägt.

Zweitens die DSGVO-Disziplin im Kontextfenster: Personenbezogene Daten gehören nicht ungefiltert hinein. Patterns sind Pseudonymisierung vor Context-Injection (Klarnamen erst im Tool-Layer auflösen), ein PII-Redaction-Layer vor dem RAG-Inject und auditierbarer Session-State-Reset. Drittens das EU-AI-Act-Logging nach Art. 12, das für Hochrisiko-Systeme ab dem 2. August 2026 voll anwendbar wird (provisorische bzw. stufenweise Anwendbarkeit — diese Einordnung ist informational und keine Rechtsberatung). Engineering-seitig heißt das: System-Prompt-Version, Tool-Catalog-Version, retrieved Documents (oder IDs + Hashes), User-Input, Tool-Calls, Tool-Results und finaler Output müssen audit-fähig und zugleich DSGVO-löschbar persistiert werden — empfohlen pro Tool-Call mit Run-Korrelations-ID.

Ausblick und Praxis-Hinweis

Prompt Engineering für Agenten ist 2026 keine Folklore und keine bloße Umbenennung, sondern die Antwort auf die Verschiebung von One-Shot-Calls zu mehrstufigen agentischen Loops. Wer einen Production-Agent baut, betreibt diese Disziplin — die Frage ist nur, ob bewusst und reproduzierbar oder unbewusst und brüchig. Mehrere Felder bleiben in Bewegung und sollten als „aktueller Snapshot" gelesen werden: die Reasoning-Modell-Konventionen, das Multi-Agent-vs.-Single-Agent-Heuristik (read-heavy parallel funktioniert, write-heavy nicht), sowie Prompt-Optimierungs-Frameworks wie DSPy, die für eng begrenzte Sub-Tasks taugen, aber für vollständige Agent-Loops noch keinen Produktionsstandard bilden.

Der praktische Einstieg ist undramatisch und gut dokumentiert: System-Prompt aus dem Vendor-Playground holen und in Git versionieren, Schema-Validation auf jeden Output, Prompt Caching auf die stabilen Teile aktivieren, harte Cost-Caps setzen und wöchentlich 20 echte Traces lesen. Anthropics Leitsatz fasst das gesamte Ziel präziser als jede Tooling-Diskussion: „Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome." Das ist Engineering — und dann: look at your data.