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 Context Engineering, „the delicate art and science of filling the context window with just the right information for the next step“, knapp eine Woche nachdem Shopify-CEO Tobi Lütke den Begriff populär gemacht 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, also 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. Einen anderen Weg geht Code Execution mit MCP: Der Agent spricht MCP-Server über Code an und lädt Tool-Definitionen erst bei Bedarf.

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 und Gemini jeweils bis 1M 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, verschwendet Tokens und verschlechtert die Qualität.

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 10 % der Standard-Input-Rate, bei einzelnen aktuellen Modellen weniger (Stand Oktober 2026: 5 % bei Opus 5.5 und Sonnet 5.5, 2,5 % bei Fable 5.1 und Mythos 5.1). OpenAI berechnet bei der GPT-5-Familie ebenfalls 10 %, bei GPT-4.1 25 % und bei GPT-4o 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 etwa über /compact. Laut Anthropic bewahrt das „architectural decisions, unresolved bugs, and implementation details“ und verwirft redundante Tool-Outputs. 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 im Strict-Mode (GA seit August 2024) und Anthropics Structured Outputs mit striktem Tool-Use (seit November 2025) erzwingen Schema-Konformität per Constrained Decoding und ersetzen das frühere „JSON parsen und hoffen“. Ausnahmen nennt die Anthropic-Doku ausdrücklich: Ablehnungen, Abbrüche am Token-Limit und gelegentlich abweichende Groß-/Kleinschreibung bei Enum- und Const-Werten.

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 so viel deutschen Inhalt, wie auf Englisch in rund 130–150K Tokens passt. Das bedeutet höhere Kosten, aber auch einen höheren Caching-ROI, weil der Cache-Rabatt auf eine größere Token-Zahl wirkt.

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 für Hochrisiko-Systeme: Durch den AI-Omnibus (VO (EU) 2026/1744) gilt es für Anhang-III-Systeme ab 2. Dezember 2027 und für Anhang-I-Produkte ab 2. August 2028. Für Schweizer Teams gelten DSGVO und AI Act nur bei EU-Bezug. Die DSGVO greift nach Art. 3 Abs. 2, wenn das Team Personen in der EU Waren oder Dienstleistungen anbietet oder deren Verhalten beobachtet. Der AI Act greift nach Art. 2, wenn es KI-Systeme in der EU in Verkehr bringt oder deren Output in der EU verwendet wird. National gilt seit 1. September 2023 das revidierte Datenschutzgesetz (revDSG). Diese Einordnung ist informativ und keine Rechtsberatung. Engineering-seitig heißt die Logging-Pflicht: 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, am besten 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, die 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.