--- title: "Prompt Engineering für Agenten" description: "Prompt Engineering für Agenten: Techniken für System-Prompts, Tool-Use und zuverlässiges Verhalten autonomer AI Agents." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten" category: "KI Agenten" updated: "2026-07-29T08:53:26.674Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Prompt Engineering für Agenten Prompt Engineering für Agenten: Techniken für System-Prompts, Tool-Use und zuverlässiges Verhalten autonomer AI Agents. ## Was ist Prompt Engineering für Agenten? [Prompt Engineering](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/glossar/agent) in jedem Turn sieht; er ist Code: versioniert, reviewbar, diffbar. [Production-System-Prompts](/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/system-prompts-design-patterns) strukturieren sich 2026 konsistent in vier Schichten: | Layer | Inhalt | Typische Länge | | --- | --- | --- | | **Identity** | Rolle, Domäne, Boundaries („Du bist X, zuständig für Y") | 50–200 Tokens | | **Capability** | Verfügbare Tools, was sie tun, wann sie zu nutzen sind | 800–2.000 Tokens (inkl. Tool-Schemas) | | **Behavioral** | Output-Format, Stil, „Niemals X", Beispiele | 200–600 Tokens | | **Context** | Dynamisch: heutiges Datum, aktueller User, Workflow | 100–400 Tokens | 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](/de/glossar/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](/de/glossar/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](/de/wissen/ki-agenten/model-context-protocol-mcp/code-execution-mit-mcp). 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](/de/glossar/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: | Pattern | Idee | Production-Use 2026 | | --- | --- | --- | | **ReAct** (Yao et al. 2022) | Reason → Act → Observe → … | Standard-Default für Tool-Use-Agents | | **Plan-and-Execute** | Erst Plan generieren, dann ausführen | Multi-Step-Workflows, niedrige Latenz | | **Reflexion** (Shinn et al. 2023) | Generieren → kritisieren → revidieren | Quality-sensitive Tasks (2–3× Token-Kosten) | | **Tree of Thoughts** (Yao et al. 2023) | Mehrere Branches parallel, Merge | Hard-Reasoning, sehr teuer, selten Standard | 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](/de/glossar/anthropic-claude) mit Extended Thinking, [OpenAI](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/agent-handoff-strategien) 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](/de/glossar/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](/de/wissen/ki-agenten/agent-architekturen-ueberblick/chain-of-thought-fuer-agenten)", „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](/de/glossar/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](/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/strukturierte-outputs-json-schema) (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](/de/glossar/roi), weil der 90 %-Discount auf eine größere Token-Zahl durchschlägt. Zweitens die [**DSGVO](https://dsgvo-gesetz.de/)-Disziplin** im Kontextfenster: [Personenbezogene Daten](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/dsgvo-rechtsgrundlage-ki-art-6) 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](/de/glossar/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](/de/services/ki-agent-integration), *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. ## Artikel - [System-Prompts für Agenten: 12 Design Patterns für produktionsreifes System Prompt Design](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/system-prompts-design-patterns) — System Prompt Design bezeichnet die strukturierte Konstruktion des System-Prompts eines AI-Agenten aus wiederverwendbaren Bausteinen: Rolle, - [Few-Shot Prompting für robuste Agent-Outputs](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/few-shot-prompting-fuer-agenten) — Few-Shot Prompting bezeichnet die Technik, einem AI-Agenten im Prompt einige wenige Beispiele (typisch 2 bis 5) für korrekte Ein- und Ausgab - [Prompt-Templates versionieren: Git-Workflow für Prompts](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/prompt-templates-und-versionierung) — Prompt-Versionierung bedeutet, Prompt-Templates wie Code zu behandeln: parametrisiert, getrennt von der Anwendungslogik, in Git versioniert, - [Meta-Prompting: Wenn Agenten ihre eigenen Prompts schreiben](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/meta-prompting-techniken) — Meta-Prompting bezeichnet Techniken, bei denen ein LLM seine eigenen Prompts erzeugt, bewertet oder verbessert, statt sie manuell zu formuli - [Prompt Evaluation: Promptfoo, LangSmith, Langfuse im Vergleich (Stand 2026)](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/prompt-evaluation-frameworks) — Prompt Evaluation ist das systematische, messbare Testen von Prompts und LLM-Outputs gegen ein fixes Eval-Set. Methoden sind regelbasierte A - [Prompt-Injection-Defense: 9 Techniken für Production-Agents](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/prompt-injection-defense-techniken) — Prompt Injection Defense bezeichnet die mehrschichtige Absicherung von KI-Agenten gegen manipulierte Eingaben, die Instruktionen unterschieb --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/prompt-engineering-fuer-agenten). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.