Masterarbeit/Versuche/Versuch_02

Versuch 02 – Agentengestützt (V2)

Rollenspezialisierte Agentendateien statt eines einzelnen Threads. Agentenmodus des Skills: custom; die Rollen werden per --agents übergeben.

Dateien

Datei	SHA-256	Zweck
01_Prompt.md	DCDC0E3F…B71BCF	Analyseanweisung, Prompt-Version 02-A
01_Agents.json	6943EECD…AF1696	acht Agentenrollen

Der Prompt: abgeleitet aus V1, angepasst an Agentendateien

Prompt-Version 02-A entsteht aus Versuche/Versuch_01/02_Prompt.md (F9B2A1AA…0D7849) durch eine Ergänzung: den Abschnitt Arbeitsteilung. Alles Übrige – Auftrag, Scope, Vorgehensschritte 0 bis 6, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur – ist unverändert.

Warum die Ergänzung nötig ist. Prompt-Version 02 unterstellt an mehreren Stellen stillschweigend, dass ein Bearbeiter die gesamte Kette durchläuft: Sie ordnet Schritte zeitlich (erst Inventar, dann Mindestabdeckung, dann Vertiefung), vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Wird die Arbeit auf Rollen verteilt, ist nichts davon mehr von selbst erfüllt: IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen.

Der Abschnitt nennt keine Rolle und schreibt keinen Zuschnitt vor – welche Rollen es gibt, stellt der Versuchsaufbau bei. Seine vier Kernsätze:

• ID-Bereiche vorab vergeben, überschneidungsfrei; zusammengeführt je Ebene lückenlos
• Die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter – fällt in einem Ausschnitt eine fremde Ebene an, wird sie dort geführt und über Tracelinks verbunden
• Die Mindestabdeckung ist erreicht, wenn jedes Modul des gemeinsamen Inventars eine Anforderung trägt – nicht, wenn jeder seinen Ausschnitt abgedeckt hat
• Der Konsistenzcheck gilt dem zusammengeführten Ergebnis, mit besonderem Blick auf die Ränder der Ausschnitte

Der Abschnitt gilt ausdrücklich nur bei verteilter Bearbeitung; bei einem einzelnen Bearbeiter ist er wirkungslos. Damit bleibt der Prompt auch für einen solo-Lauf gültig und der fachliche Auftrag über V1, V2 und V3 identisch.

Die acht Rollen

Rolle	Aufgabe	Schreibt Anforderungen?
modulinventar	Schritt 0: vollständiges Inventar samt Abdeckungsbuchführung	nein
faktenermittler	belegte Fakten samt durchsetzender Codestelle, je Modulausschnitt	nein
strs-autor	Stakeholder-Ebene	ja, nur StRS
syrs-autor	Systemebene	ja, nur SyRS
swrs-autor	Softwareebene, zusätzlich Konsolidierungsprüfung	ja, nur SwRS
iso29148-orchestrator	führt die Ebenen zur Spezifikation zusammen	nein
belegpruefer	öffnet zitierte Stellen und prüft, ob PRIMÄR trägt	nein
konsistenzpruefer	vollständige Regelprüfung gegen die Promptvorgaben	nein

Die vier von der Arbeit genannten Rollen – Stakeholder, System, Software und ISO-29148-Orchestrator – sind damit besetzt; modulinventar, faktenermittler, belegpruefer und konsistenzpruefer kommen aus den Messungen hinzu.

Der Orchestrator delegiert nicht. Er startet keine Subagenten und schreibt keine Anforderungen, sondern stellt her, was erst am zusammengeführten Bestand entstehen kann: durchgängige Nummerierung samt mitgezogener Verweise, beidseitig geschlossene Traceability, eine aus dem Gesamtbestand erzeugte Hypothesenliste, die Abdeckungstabelle über das gemeinsame Inventar. Ein delegierender Orchestrator erzeugte eine zweite Ebene, deren Subagenten-Prompts nicht protokollierbar sind – in Versuch 1 blieben so 18 von 31 Aufrufen unerfassbar.

Woraus die Rollen abgeleitet sind

Jede Regel in den Agentenprompts ist an einen gemessenen Befund aus den 17 Läufen von Versuch 1 gekoppelt:

Drei Autoren statt einem – die Ebenenverteilung schwankte bei identischem Prompt von 92,7 % StRS bis 89,4 % SwRS. Ursache: Der Prompt verlangt in Schritt 0b je Modul eine Anforderung, sagt aber nicht, auf welcher Ebene. Getrennte Autoren machen die Verteilung strukturell statt emergent.

Der faktenermittler ist aus den Läufen abgeschrieben. Drei builtin-Läufe, gleiche Bedingung, unterschiedliche Beauftragung der Subagenten:

Lauf	Auftragsart	Anforderungen mit Primärbeleg
4048	„concrete, citable FACTS only … find the EXACT enforcing location"	97,8 %
fb24	„Research …" mit Faktenpflicht	96,9 %
f8b4	„quickly inspect … open 1-3 representative files"	46,4 %

Nicht die Zahl der Subagenten entscheidet, sondern ob Tiefe oder Breite beauftragt wird. Das Stichproben-Verbot im Prompt der Rolle folgt direkt daraus.

Der belegpruefer ist neu. Die Primärbelegquote schwankte über 17 Läufe zwischen 34,6 % und 100 %. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt – geprüft wurde sie bis dahin nie.

Der konsistenzpruefer adressiert den am häufigsten verfehlten Prüfpunkt. Die risikobasierte Priorisierung scheiterte in 9 von 16 gültigen Läufen, im schlimmsten Fall bei 18 von 49 Anforderungen. In einem Lauf meldete der Agent „alle 36 gedeckt", während die maschinelle Prüfung 51 risikorelevante Anforderungen fand – er hatte gegen einen zu engen eigenen Risikobegriff geprüft. Die Rolle muss ihren Risikobegriff deshalb offenlegen.

Ausführung

Der Skill run-experiment übernimmt das im Modus custom. Ablage der Läufe: <Iteration>/<ModellID>/custom/<Effort>/.

Wichtig: --safe-mode ist hier nicht verwendbar

--safe-mode schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins, hooks, MCP servers, custom commands and agents, output styles, …)" ab – also genau das, was dieser Versuch untersucht. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur das Flag variiert):

Konfiguration	spawned	by_type
mit --safe-mode	0	leer – „die Rollen sind nicht in der Agent-Registry registriert"
ohne --safe-mode	2	{"modulinventar": 1, "konsistenzpruefer": 1}

Ohne diesen Test wäre der erste Lauf stillschweigend als V1-Lauf gemessen worden: --agents hätte keine Wirkung gehabt, der Lauf hätte fehlerfrei durchlaufen und Anforderungen erzeugt – nur eben ohne die Rollen, die den Versuch ausmachen.

Der Ersatz (Skill 7.0.0): kein --safe-mode, stattdessen --strict-mcp-config und --disallowedTools Skill WebSearch WebFetch SlashCommand zusätzlich zur 33er-Denylist. Gegengeprüft mit derselben Werkzeugabfrage: VORGELADEN: NICHTS VORGELADEN · SKILLS: KEINE · WEB: KEIN WEBZUGRIFF · alle Rollen verfügbar. Ohne die Sperre lädt die CLI 16 global installierte Skills (darunter code-review, security-review, run, init); --setting-sources '' unterdrückt sie nicht.

Was der Ersatz nicht abdeckt: Plugins, Hooks und Output-Styles. Auf der Versuchsmaschine ist davon nichts konfiguriert, das ist aber eine Eigenschaft der Umgebung und keine Garantie. Der Skill verlangt deshalb vor jedem Lauf eine Umgebungsprüfung, deren Ergebnis ins Protokoll geht.

Folge für die Vergleichbarkeit: Läufe dieses Versuchs sind hinsichtlich der Isolation nicht unmittelbar mit den solo- und builtin-Läufen aus Versuch 1 vergleichbar. Der Unterschied ist benannt und begrenzt – er betrifft Plugins, Hooks und Output-Styles, nicht CLAUDE.md, Skills, Webzugriff oder MCP.

Offene Punkte vor dem ersten Lauf

1. extract-subagenten.py ist nicht gegen custom-Typen geprüft. Es erwartet die eingebauten Typen Explore und general-purpose; mit --agents heißen sie faktenermittler, strs-autor und so fort.
2. Die Modellbedingung ist bei Delegation über --model allein nicht herstellbar. Zwei dokumentierte Fälle aus Versuch 1: bei Fable liefen die Subagenten auf claude-opus-5[1m], bei Opus entfielen 18,5 Mio. Tokens (4,72 %) auf claude-sonnet-5. Nach jedem Lauf modelUsage prüfen und die Modellbedingung nicht als gesichert annehmen.
3. Hintergrund-Subagenten und Zeitlimit. Der Skill setzt seit 6.1.0 CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; ohne diese Einstellung bricht der Headless-Modus nach 600 s ab und meldet dabei is_error: false bei null Ergebnisdateien.
4. Umgebungsprüfung auf Hooks, Plugins und Output-Styles im User-Profil – siehe oben.