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
02_Prompt.md	5946FC82…C76ECD	aktuell – Analyseanweisung, Prompt-Version 03-A
03_Agents.json	424DDD83…644170	aktuell – acht Agentenrollen, Delegationstiefe unverschachtelt (Abschnitt Keine Weiterdelegation je Rolle)
02_Agents.json	4BF0AF8F…9781F1	acht Agentenrollen, Delegationstiefe verschachtelt – Fassung des ersten V2-Laufs; weiterhin gültige Alternative, siehe Skill 9.2.0
01_Prompt.md	DCDC0E3F…B71BCF	abgelöst – Prompt-Version 02-A, kein Lauf durchgeführt
01_Agents.json	030B2142…21A9D9	abgelöst, kein Lauf durchgeführt. Die README nannte hier bis zum 31.08. den Hash 6943EECD…AF1696; er passte zu keinem Stand der Datei.

Stand 31.08.2026: Prompt-Version 03-A und Zuständigkeitsbindung

Prompt-Version 03-A löst 02-A ab. 02-A leitete sich von Prompt-Version 02 aus Versuch 1 ab. Versuch 1 ist seit Iteration 8 auf Prompt-Version 03 weitergelaufen. Ein V2-Lauf gegen 02-A hätte sich von den Vergleichsläufen in zwei Größen unterschieden – Agentenrollen und Prompt-Version – und wäre als Wirkungsnachweis der Rollen unbrauchbar gewesen. 03-A setzt auf Prompt-Version 03 auf; einzige Ergänzung bleibt der Abschnitt Arbeitsteilung.

Die Rollennutzung ist gebunden. Der Smoke-Test vom 26.08. nutzte von acht beigestellten Rollen nur zwei. Bleibt die Nutzung freigestellt, wird die Versuchsbedingung nicht hergestellt: Der Lauf führte die Rollen mit, ohne sie einzusetzen. Der Prompt verlangt deshalb, dass eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, von ihm ausgeführt wird. Die konkrete Zuordnung Teilaufgabe → Rolle steht im Block Werkzeugkontext des Skills (Version 9.1.0), nicht im Prompt – so bleibt dieselbe Prompt-Datei für solo und builtin gültig und die Rollenbindung die einzige unabhängige Variable.

Gebunden ist wer eine Teilaufgabe ausführt. Frei bleiben Zuschnitt, Anzahl der Aufträge je Rolle, Reihenfolge, Tiefe und Turn-Anzahl – sie bleiben Untersuchungsgegenstand wie in V1b. Die Bindung ist vor dem Lauf statisch deklariert, in _meta\combined_prompt.md archiviert und über den SHA-256 der --agents-Datei versioniert; sie ist damit von den in Skill 9.0.0 entfernten laufzeitabhängigen Adaptereingriffen zu unterscheiden, die Lauf 34 unpoolbar machten.

Da die Bindung auf Promptebene wirkt, ist ihre Einhaltung nicht erzwungen, sondern selbst eine Messgröße: Das Protokollfeld Zuständigkeitsbindung führt die Aufrufe je Rolle aus subagent_stats.by_type, nennt Rollen mit null Aufrufen und gleicht sie gegen die Dokumentationspflicht im Analysebericht.md ab.

Änderungen an den Rollen (02_Agents.json). Namen und die gemessen begründeten Regeln sind unverändert. Neu ist:

Rolle	Änderung	Grund
strs-autor, syrs-autor, swrs-autor	schreiben keine Ergebnisdateien, Rückgabe als Text	Im TensorX-Adapter können Subagenten grundsätzlich nicht schreiben, in der Claude-CLI erben --agents-Rollen alle Werkzeuge. Dieselbe Rollendatei hätte je Adapter eine andere Bedingung ergeben; drei gleichzeitig schreibende Autoren brechen zudem die 7-Datei-Regel und die ID-Disziplin.
iso29148-orchestrator	prüft und liefert einen Übergabebericht mit ausführbaren Anweisungen, statt die Struktur selbst herzustellen	Die alte Fassung verlangte Herstellungsleistungen (Umnummerierung, Ergebnisstruktur) von einem Subagenten, der nicht schreiben kann – im Adapter unausführbar, in der CLI ein zweiter Schreiber neben dem Hauptagenten.
konsistenzpruefer	Prüfpunkte 9 bis 11: 7-Datei-Regel, Anteil nicht analysiert über 10 %, Einhaltung der Zuständigkeitsbindung	Die Rolle prüfte gegen Prompt-Version 02; die beiden Regeln kamen mit Version 03 hinzu. Punkt 11 macht die Bindung im Lauf selbst sichtbar.
belegpruefer	Umfang ist das Zugewiesene; geprüfte Zahl und Bezugsgröße sind zu nennen	Ohne Bezugsgröße ist die Zählung nicht einzuordnen.
alle	„Du legst keine Dateien an"	macht die Bedingung adapterunabhängig

Historisch: Prompt-Version 02-A

Dieser Abschnitt beschreibt die abgelöste Fassung 01_Prompt.md. Er bleibt stehen, weil die Begründung des Abschnitts Arbeitsteilung unverändert gilt; maßgeblich ist der Stand vom 31.08.2026 weiter oben.

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 – als Rückgabetext, ohne Datei
syrs-autor	Systemebene	ja, nur SyRS – als Rückgabetext, ohne Datei
swrs-autor	Softwareebene, zusätzlich Konsolidierungsprüfung	ja, nur SwRS – als Rückgabetext, ohne Datei
iso29148-orchestrator	prüft den zusammengeführten Bestand und liefert den Übergabebericht	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 weder Anforderungen noch Dateien. Er prüft, was sich erst am zusammengeführten Bestand feststellen lässt – durchgängige Nummerierung samt mitzuziehender Verweise, beidseitig geschlossene Traceability, Deckungsgleichheit der Hypothesenliste, Abdeckung über das gemeinsame Inventar – und liefert die fehlenden Schritte als ausführbare Anweisungen zurück; ausgeführt werden sie vom Hauptagenten. 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>/.

TensorX-Modelle

Für TensorX-Läufe in Versuch 2 sind zusätzlich qwen/qwen3.8-flash-next und z-ai/glm-5.3-flash konfiguriert. Beide IDs waren bei der Prüfung am 31.08.2026 im /v1/models-Katalog des Gateways vorhanden. Der Python-Adapter lädt im Modus custom die Agentendatei über --agents und stellt dem Hauptagenten spawn_subagent bereit; ohne diese beiden Teile wäre die Agentenbedingung von Versuch 2 nicht hergestellt.

Der kleine Qwen-Kompatibilitätstest bestätigte Tool-Calling, thinking und Reasoning-Tokens. Der entsprechende GLM-Test lieferte innerhalb von 90 Sekunden keine Antwort; die Modell-ID ist vorhanden und konfiguriert, vor einem kostenintensiven Lauf ist aber ein erneuter Smoke-Test erforderlich.

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. Geklärt am 31.08.2026 durch Inspektion: Das Skript filtert auf die Werkzeugnamen Task/Agent und liest subagent_type generisch aus; eine Liste erwarteter Typen gibt es nicht. Custom-Typen werden damit wie eingebaute erfasst. Bestätigung am ersten realen Lauf steht aus.
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.
5. Der --safe-mode-Smoke-Test lief auf CLI 2.1.246; installiert ist inzwischen 2.1.251. Der Test ist das, was verhindert, dass ein V2-Lauf stillschweigend als V1-Lauf gemessen wird. Vor der Auswertung des ersten Laufs ist subagent_stats.by_type daher darauf zu prüfen, dass die Rollennamen tatsächlich erscheinen.