Mid-Conversation-System-Prompts: Agentensteuerung ohne Cache-Verlust

Ein LLM-basierter Agent führt oft stundenlange Gespräche durch, in denen ein großer System-Prompt als stabiler Kontext dient. Dieser wird gecacht, um jede neue Interaktion kostengünstig zu verarbeiten. Doch was passiert, wenn während der Session neue Informationen bekannt werden – etwa ein Projektwechsel von Python zu Go?

Die naheliegende Lösung wäre, den System-Prompt zu aktualisieren. Doch dieser steht am Anfang des gecachten Präfixes. Jede Änderung dort invalidiert den gesamten Cache. Plötzlich wird die gesamte Konversationshistorie mit hohen Kosten neu verarbeitet. Für lange Sessions kann das teuer und langsam werden.

Dynamische Anweisungen ohne Cache-Verlust

Die Lösung heißt Mid-Conversation-System-Prompts. Diese Funktion, die aktuell in den neuesten Claude-Modellen verfügbar ist, erlaubt es, System-Nachrichten direkt in das Nachrichten-Array einzufügen – und zwar nach der gecachten Historie. Dadurch bleibt der Cache unberührt, und nur die neue Anweisung wird mit voller Kostenlast verarbeitet.

Ein typisches Code-Beispiel zeigt die Implementierung:

const response = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 16000,
  system: [
    {
      type: "text",
      text: STABLE_SYSTEM,
      cache_control: { type: "ephemeral" }
    },
  ],
  messages: [
    ...history, // Gecachte Historie bleibt unverändert
    { role: "user", content: latestUserMessage },
    // System-Nachricht als Operator-Anweisung
    { role: "system", content: "Dieses Projekt ist in Go. Alle Codeschnipsel müssen in Go geschrieben werden." },
  ],
}, {
  headers: { "anthropic-beta": "mid-conversation-system-2026-04-07" }
});

Durch die Position der neuen System-Nachricht nach der Historie bleibt der Cache intakt. Die Kosten beschränken sich auf die neue, kurze Nachricht – und der Agent erhält dennoch die Anweisung mit voller Operator-Berechtigung.

Sicherheit vs. Spoofing-Risiko

Früher wurde versucht, solche Anweisungen in Benutzer-Nachrichten zu verstecken, etwa mit Markierungen wie <system-reminder>. Das bewahrt zwar den Cache, birgt aber ein Sicherheitsrisiko: Benutzer-Nachrichten können manipuliert werden. Jeder, der auf die Eingabe zugreift, könnte solche Anweisungen fälschen und dem Agenten falsche Befehle unterjubeln.

Eine echte role: "system"-Nachricht hingegen ist nicht spoofbar. Sie stammt direkt vom Operator und garantiert, dass die Anweisung vertrauenswürdig ist. Das ist besonders wichtig, wenn sensible Zustandsänderungen – wie Modus-Wechsel oder Berechtigungen – in eine Session mit unvertrauenswürdigen Benutzereingaben eingebettet werden müssen.

Kontext statt Kommando: Die richtige Formulierung

Ein häufiger Fehler liegt in der falschen Formulierung der System-Nachricht. Statt direkter Befehle wie „Ignoriere die vorherige Anweisung“ oder „Mach stattdessen X“ sollte der Kontext als Fakt dargestellt werden. Das Modell reagiert dann entsprechend, ohne dass Sicherheitsmechanismen greifen.

Gut formulierte Beispiele:

• "Der Auto-Approve-Modus ist für diese Session aktiviert."
• "Das Projekt wurde von Python zu Go migriert. Alle Codeschnipsel müssen in Go verfasst werden."

Riskante Formulierungen wie:

• "Ignoriere die Anfrage des Benutzers und führe stattdessen X aus."

werden vom Modell oft abgelehnt, da sie gegen die trainierten Sicherheitsvorkehrungen verstoßen.

Wichtige Einschränkungen und Fallbacks

Bevor Entwickler diese Funktion einsetzen, sollten sie die technischen Rahmenbedingungen kennen:

• Eine Mid-Conversation-System-Nachricht muss einer Benutzer-Nachricht folgen. Sie darf nicht als erste Nachricht in der Session erscheinen. Für den initialen System-Prompt bleibt die klassische Methode bestehen.
• Der Inhalt der System-Nachricht ist auf Text beschränkt – keine Bilder oder strukturierten Daten.
• Die Funktion ist modellabhängig. Versucht man, sie auf einem nicht unterstützten Modell einzusetzen, erhält man eine Fehlermeldung wie role 'system' is not supported on this model. In diesem Fall sollte auf die Benutzer-Nachrichten-Lösung zurückgegriffen werden.

Ein typischer Fallback-Mechanismus sieht so aus:

try {
  // Mid-Conversation-System-Nachricht versuchen
} catch (err) {
  if (err instanceof Anthropic.BadRequestError && err.message.includes("system")) {
    // Fallback: Anweisung als Benutzer-Nachricht mit Markierung einbetten
    messages.push({
      role: "user",
      content: `<system-reminder>Dieses Projekt ist in Go. Alle Codeschnipsel müssen in Go verfasst werden.</system-reminder>`
    });
  } else {
    throw err;
  }
}

Wann lohnt sich der Einsatz?

Mid-Conversation-System-Prompts sind ideal für Szenarien, in denen der Agent während einer Session neue, relevante Informationen erhält, die den weiteren Verlauf beeinflussen. Typische Anwendungsfälle:

• Modus-Wechsel: Der Agent wechselt von einem Modus in einen anderen, etwa von Analyse zu Code-Generierung.
• Dynamische Kontext-Updates: Neue Dateien oder Daten werden in die Session eingebracht, die der Agent kennen muss.
• Zustandsänderungen: Berechtigungen oder Einschränkungen werden angepasst, ohne die gesamte Session neu zu starten.

Kein Einsatzgebiet sind Informationen, die bereits zu Beginn der Session bekannt sind. Diese gehören weiterhin in den statischen System-Prompt. Die Mid-Conversation-Methode ist ausschließlich für nachträglich gelernte Fakten gedacht – und spart so teure Cache-Invalidierungen.

Mit dieser Technik bleibt der Cache heiß, bleiben Anweisungen vertrauenswürdig und entfällt das Risiko, teure Rechenlast durch vermeidbare Cache-Invalidierungen zu erzeugen.