Anti-Pattern Giant System Prompt: riesiger System-Prompt

Idee in 30 Sekunden

Giant System Prompt ist ein Anti-Pattern, bei dem fast die gesamte Agentenlogik in einen großen system prompt gepackt wird.

Dadurch beginnen Instruktionen zu kollidieren, Prioritäten werden unklar, und das Modellverhalten wird instabil. Das erhöht latency, cost und das Risiko von Regressionen nach kleinen Änderungen.

Einfache Regel: system prompt sollte kurz und stabil bleiben; variable Logik gehört in Route-Blöcke, Policy-Layer und Output-Validierung im Code. System prompt sollte Rolle und Basisregeln setzen, aber nicht die komplette Business-Logik des Systems enthalten.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten und ergänzt neue Regeln fortlaufend in einem system prompt.

Mit der Zeit wird dieser Prompt zu einem riesigen Instruktionsblock für alle Szenarien zugleich.

SYSTEM_PROMPT = """
You are support agent.
- Always be brief.
- Always provide detailed step-by-step explanation.
- Never call tools unless user asks.
- For payment issues always call get_payment_status.
- Reply only in strict JSON.
- Prefer natural text if JSON looks unnatural.
... hundreds of lines ...
"""

response = agent.run(
    system_prompt=SYSTEM_PROMPT,
    user_message=user_message,
)

In diesem Setup sieht das Modell zu viele Instruktionen mit konkurrierenden Prioritäten:

always_be_brief + give_step_by_step_explanation
json_only + prefer_natural_text
never_call_tools + always_call_payment_tool

Für diesen Fall ist ein kurzer Base-Prompt plus separate route-specific Blöcke besser:

system_prompt = BASE_PROMPT + ROUTE_PROMPTS[route]

In diesem Fall erzeugt ein giant prompt:

• Konflikte zwischen Regeln
• schwierige Wartung nach Änderungen
• instabiles Antwortformat und instabilen Ton

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn ein Team "alles schnell per Prompt lösen" will, ohne klare Grenze zwischen Instruktionen, Policy und runtime-Logik.

Typische Ursachen:

• jeder neue Incident wird mit einer weiteren Zeile im system prompt "gefixt"
• fehlende Modularität: ein Prompt für alle Routen
• Policy-Regeln leben im Prompt-Text statt im Code
• keine klaren Owner und keine Versionierung von Prompt-Blöcken

Daraus folgen Probleme:

• Instruktionskonflikte - im Prompt stehen gleichzeitig widersprüchliche Regeln
• instabiles Verhalten - dieselbe Anfrage liefert unterschiedlichen Stil und unterschiedliches Format
• höhere latency und cost - langer Prompt erhöht Tokens pro Run
• fragile Änderungen - kleine Anpassungen können andere Szenarien brechen
• schwieriges Debugging - schwer nachzuvollziehen, welche Regel tatsächlich gegriffen hat

Typische Production-Signale, dass der system prompt bereits zu groß ist:

• eine Regeländerung verursacht Regression in anderer Route
• cost per request steigt wegen langem, unverändertem Prompt
• Team kann Priorität zwischen zwei widersprüchlichen Instruktionen nicht schnell erklären
• nach kleiner Prompt-Änderung sinkt success rate in Teilen der Cases

Tool-Wahl, Format-Wahl und Stil-Wahl sind Teil der LLM inference. Wenn im Prompt zu viele heterogene Instruktionen stehen, steigt die Zahl möglicher Interpretationen, und das Modell wählt häufiger eine Regel, die formal passt, aber für diese Route nicht optimal ist.

Wenn dieses Setup wächst, ist ohne trace und Ausführungsvisualisierung schwer nachvollziehbar, welcher Prompt-Block in einem konkreten Run genutzt wurde und welche Regel das Modellverhalten beeinflusst hat.

Richtiger Ansatz

Startet mit einem kurzen stabilen system prompt, der Rolle und Basisregeln definiert. Variable Logik verschiebt ihr in Route-Blöcke, Policy-Gates und Output-Prüfungen im Code.

Praktischer Rahmen:

• haltet einen kleinen BASE_PROMPT für gemeinsame Regeln
• ergänzt ROUTE_PROMPTS nur für konkrete Aufgabentypen
• implementiert Policy und Grenzen im Code, nicht in einem riesigen Text
• validiert Output und messt Änderungseffekte (zum Beispiel bessere success rate ohne starken Anstieg von latency und cost per request)

Zum Beispiel sollte Antwortformat via Schema-Validierung geprüft werden, bevor das Ergebnis zurückgegeben wird.

BASE_PROMPT = """
You are a support agent.
Follow safety and output rules.
"""  # stable instructions shared across all routes

ROUTE_PROMPTS = {
    "payment": "Use payment policy. Return strict JSON.",
    "refund": "Use refund policy. Ask clarifying question if needed.",
}

def run_support_agent(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules
    system_prompt = BASE_PROMPT + "\n\n" + ROUTE_PROMPTS[route]

    response = agent.run(
        system_prompt=system_prompt,
        user_message=user_message,
    )

    if not validate_output(response):  # schema / required fields / safety checks
        return stop("invalid_output")

    return response

In diesem Setup werden Regeln transparenter: eine konkrete Route ist leichter aktualisierbar, und Nachbarszenarien brechen seltener.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr ein giant-system-prompt Risiko:

• Versucht ein system prompt fast alle Szenarien gleichzeitig abzudecken?
• Führt eine kleine Prompt-Änderung oft zu Nebenregressionen in anderen Fällen?
• Ist schwer festzustellen, welche Regel bei Konflikt höhere Priorität hat?

Worin es sich von anderen Anti-Patterns unterscheidet

Overengineering Agents vs Giant System Prompt

Too Many Tools vs Giant System Prompt

Agents Without Guardrails vs Giant System Prompt

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für das Anti-Pattern Giant System Prompt.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Ist ein langer system prompt immer schlecht?
A: Nein. Das Problem ist nicht Länge allein, sondern Monolithik und Konflikte. Wenn ein Prompt wächst, aber modular bleibt und klare Prioritäten hat, sind Risiken deutlich kleiner.

Q: Wann sollte eine Regel aus Prompt in Code verschoben werden?
A: Wenn die Regel kritisch für Sicherheit, Kosten oder Formatstabilität ist. Solche Grenzen sollten als explizite runtime-Prüfungen umgesetzt werden, nicht nur als Textinstruktion.

Q: Wie kommt man ohne großen Refactor von giant prompt zu modularem Setup?
A: Startet klein: extrahiert BASE_PROMPT, ergänzt 1-2 route-spezifische Blöcke für häufige Cases und verschiebt Policy-Regeln schrittweise aus Prompt in Code-Gates.

Was als Nächstes

Ähnliche Anti-Patterns:

• Overengineering Agents - wenn Komplexität schneller wächst als Nutzen.
• Too Many Tools - wenn Rauschen in Tool-Auswahl Verhalten instabil macht.
• Agent Everywhere Problem - wenn ein Agent selbst für deterministische Aufgaben eingesetzt wird.

Was ihr stattdessen bauen solltet:

• Allowed Actions - wie Aktionsgrenzen im Code verankert werden.
• Routing Agent - wie Routen getrennt und relevante Instruktionen gegeben werden.
• Policy Boundaries in Architecture - wie Policy von Prompt in explizite Architekturgrenzen verschoben wird.