Prompt-Registry als First-Class Citizen – wie CAP-Apps ihre AI-Calls versionieren
Prompts gehören in den Quellcode, nicht in `.env`-Files oder hartcodiert. Eine Prompt-Registry mit Versionierung, A/B-Testing und Rollback ist 2-3 Tage Aufwand – und spart 6 Monate später den Albtraum mit „warum gibt der Agent jetzt andere Antworten?“.
Das Problem, das Teams im 4. Monat trifft
Ein BTP-CAP-Team hat seinen ersten AI-Agent live. Funktioniert. Drei Monate später, im laufenden Betrieb, beobachtet ein User: „Der Agent gibt seit gestern komplett andere Antworten.“ Niemand weiss, warum. Es gab kein Deploy. Es gab kein Code-Change.
Was war passiert: jemand hat in der .env einen Prompt-String geändert und über Application Gateway deployt, ohne PR. Keine Audit-Spur. Keine Rollback-Möglichkeit. Nur ein Vor-und-Zurück-Versuch ins Blaue.
Das passiert allen, die Prompts nicht wie Code behandeln.
Warum Prompts wie Code behandeln
mermaid
flowchart LR
PR[Prompt-Änderung] --> Code[Im Code-Repo]
Code --> PR2[Pull Request]
PR2 --> Review[Review + Eval]
Review --> CI[CI: Eval-Tests]
CI --> Merge[Merge to main]
Merge --> Tag[Version-Tag<br/>z.B. prompt-v3.2]
Tag --> Deploy[Deploy mit Tag-Reference]
Deploy --> Audit[Audit-Trail vollständig]
Die Vorteile spiegeln genau die Code-Vorteile: - Versionierung: jede Prompt-Änderung ist nachvollziehbar - Review: Vier-Augen vor Live - Rollback: vorherige Version mit einem Tag-Switch zurückholbar - A/B-Testing: zwei Versionen parallel, Eval-Vergleich - Eval-Coverage: jede Version durchläuft die Golden-Set-Tests
Wie eine Prompt-Registry strukturiert ist
In BAMVP haben wir die Registry so strukturiert:
prompts/
bug-repro/
v1.md # initial
v2.md # add safety-prefix
v3.md # tighter tool-use schema
v3.2.md # current
HISTORY.md # change-log
pr-review/
v1.md
v2.md # current
HISTORY.md
bench-judge/
v1.md # current
Im CAP-Service:
```typescript // srv/ai-handlers.js import { promptRegistry } from './prompts/registry';
const promptForBugRepro = promptRegistry.load('bug-repro/v3.2'); // ... use in Anthropic call ```
Die registry.load() cached und exposes Metadaten (Version, Last-Modified, Eval-Score).
A/B-Testing in Production
Wenn Sie Prompt v3 mit v3.2 vergleichen wollen, ohne Live-Risiko:
typescript
const promptVersion = req.user.email.endsWith('@beta-tester.example')
? 'bug-repro/v3.2-experimental'
: 'bug-repro/v3.2';
Der CAP-Service routet pro User zur Variante, das Audit-Log zeigt welche Version zu welchem Call gehörte. Nach 2-4 Wochen haben Sie genug Daten für eine Eval-Auswertung.
Was im Eval-Loop pro Version läuft
Pro Prompt-Version: 1. Golden Cases (10-20 hand-kuratierte Repro-Fälle): muss durchlaufen 2. Regression-Suite (50+ historische Fälle): darf nicht schlechter werden 3. Cost-Check: Token-Verbrauch im Erwartungsband? 4. Safety-Check: keine Refusal in legitimen Cases? Keine PII-Echos?
Eine Promotion vN-rc → vN läuft erst, wenn alle 4 Gates grün sind.
Was die meisten Teams nicht haben
- Eval-Set für die eigene Domäne – generische Eval-Frameworks reichen nicht
- Token-Budget pro Prompt-Version – eine v4 die 3× mehr Tokens braucht ist nicht „besser“
- Versions-Pinning im Aufruf – der CAP-Code muss die Version explizit holen, nicht „latest“
- Audit-Log mit Version – der Audit-Eintrag enthält welche Prompt-Version genutzt wurde
Investition vs Ertrag
Eine vollständige Prompt-Registry mit Eval-Loop ist ~40-60 Personenstunden Initial-Setup, dann 10-20 Stunden pro Quartal Wartung. Bei einem AI-Service mit > 1000 Calls pro Tag und 3+ Prompt-Versionen pro Halbjahr – Investition zahlt sich nach dem ersten „mysteriösen Verhaltenswechsel“ zurück.
Wer das nicht macht, debuggt im 5. Monat ohne Audit-Spur.
Wer es einrichten will
Ein Workshop (halbtägig) baut Ihre Prompt-Registry: Verzeichnisstruktur, Eval-Set, CI-Integration, Versions-Pinning im CAP-Code. Output: lauffähiger Setup, kein Konzept-Papier.
Stand: 2026-05-10
