Eskalierende Sub-Agenten für Codex
Empfohlener Koordinator: gpt-6.1-sol mit niedrigem Aufwand. Behalte das ausgewählte Modell des übergeordneten Agenten bei; dieses Skill ändert es nicht. Der Hauptagent orchestriert: wähle die Stufe, definiere Abnahmekriterien, briefe Worker, prüfe Übergaben, bewerte Ergebnisse und erstelle Berichte. Er bearbeitet niemals Produktcode. Beginne mit kompakten Berichten (maximal 30 Zeilen), umfasse Diffs und Beweispfade; inspiziere mehr Code oder führe Prüfungen durch, wenn Beweise fehlen, umstritten oder für das Risiko der Stufe D unzureichend sind. Wiederhole Prüfungen nicht mechanisch an einem unveränderten Patch.
Worker führen eine zugewiesene Stufe aus und delegieren niemals oder rufen dieses Skill auf. Respektiere Host-Berechtigungen und den Kollaborationsmodus; der Plan-Modus erlaubt keine Implementierung oder mutationserzeugende Erkundung.
Stufen
Benenne die Stufe in der ersten Fortschrittszeile. Jede Phase kann sie hochstufen; niemals herabstufen. Bei einer Hochstufung behalte die Zähler bei, verwende das höhere Gesamtbudget der Stufe und überarbeite die Kriterien für jeden betroffenen Worker. Erhöhe bei D für Erkundung/Validierung auf mindestens Stufe 3; senke niemals eine bestehende Stufe. Führe neu erforderliche Erkundung vor der weiteren Implementierung durch.
| Stufe | Arbeit | Ablauf | Startstufe |
|---|---|---|---|
| A | Triviale, vollständig spezifizierte, risikoarme Bearbeitung mit einem konkreten Test | Implementieren; Übergabe ersetzt Validieren | 1 |
| B | Klare Änderung, die von Delegation profitiert | Implementieren → Validieren | 1 für beide |
| C | Unklarer Bug oder umfangreiches Feature; Standard | Erkunden → Implementieren → Validieren | 1 für alle |
| D | Authentifizierung, Mandantenisolierung, Migrationen, Warteschlangen/Synchronisation, Änderungen an Produktionsdaten | Erkunden → Implementieren → Validieren | Erkunden/Validieren 3; Implementieren 1 |
Phasen und Prüfungen
- Abnahmekriterien - übergeordneter Agent: Definiere „Erledigt bedeutet“ vor dem Dispatch. A/B leiten Prüfungen und erwartete Ergebnisse aus der Anfrage ab; C/D verfeinern den Entwurf nach der Erkundung. Implementieren und Validieren erhalten identische Kriterien und die ursprüngliche Anfrage.
- Erkunden - C/D: Bestätige den Umfang oder reproduziere das Problem. Keine Produktbearbeitungen; explizit eigene Repro-/Testdateien sind erlaubt. Berichte Ursache/Umfang mit Orten, Beweisen, vorgeschlagenen Kriterien und offenen Fragen. Verbiete bei rein lesender Erkundung Repository-Bearbeitungen im Brief und überprüfe den Umfang; erfinde keine agentenspezifische Sandbox-Einstellung.
- Implementieren: Ändere nur eigene Dateien; berichte Bearbeitungen, Befehle, Exit-Status und unerledigte Arbeit.
- Validieren - B/C/D: Ein neuer Agent, der nicht implementiert hat, prüft den integrierten Patch gegen Anfrage, Spezifikationen und Kriterien. Keine Repository-Bearbeitungen oder neuen Regressionstests; schlage fehlende Tests für die Implementierung vor. Kratzberichte und normale Testartefakte sind erlaubt. Berichte Beweise pro Kriterium und ungetestete Bereiche.
Überprüfe Testvoraussetzungen, bevor du Commits an Befehle sendest. Bevorzuge praktikable Alternativen nur, wenn ihre Abdeckung gleichwertig ist. Ersetze niemals Unit-Tests für erforderliche Integrations-, End-to-End-, visuelle oder gerätespezifische Nachweise nur um ein BESTANDEN zu erhalten. Trage blockierte erforderliche Prüfungen in das Endergebnis ein; nimm nicht an, dass ein bestimmter Testläufer in der Sandbox ausgeführt werden kann. Wiederhole Umgebungsfehler nur nach einer konkreten Abhilfe.
Erkunden/Implementieren geben FERTIG, TEILWEISE oder BLOCKIERT zurück. Validieren gibt BESTANDEN, FEHLGESCHLAGEN, BLOCKIERT oder NICHT SCHLÜSSIG zurück. Zeitbudgets pro Aufruf: A/B 10 Minuten; C/D 25 Minuten. Gib bei Erreichen des Limits TEILWEISE oder NICHT SCHLÜSSIG mit abgeschlossener Arbeit, Beweisen, ausstehenden Prüfungen und dem nächsten Schritt zurück.
Leiter und Dispatch
| Stufe | Modell | reasoning_effort |
|---|---|---|
| 1 | gpt-6-luna | medium |
| 2 | gpt-6-luna | medium |
| 3 | gpt-6.1-sol | low |
| 4 | gpt-6.1-sol | medium |
| 5 | gpt-6.1-sol | high |
Stufe 2 ist ein erneuter Luna-Versuch mit konkreten Korrekturbeweisen. Sol low ist Light in der App, keine zusätzliche Stufe.
Bei einem konkreten Auslassen oder einer Fehlinterpretation des Briefs eine Stufe aufsteigen; Stufe 2 ist der einzige Wiederholungsversuch für Auslassen vor dem stärkeren Modell. Bei einem bestätigten Reasoning-Fehler auf Stufe 1 oder 2 direkt zu Stufe 3 springen. Auf Stufe 3 oder höher eine Stufe aufsteigen. „Eskalieren“ unten bedeutet diese Regel. Stoppe, wenn unzureichende Arbeit Stufe 5 erschöpft. Produktive Fortsetzungen und korrigierte Umgebungsfehler erhöhen die Stufe nicht. Wiederhole nicht denselben fehlgeschlagenen Ansatz ohne eine konkrete Korrektur; eskaliere stattdessen. Dies verbietet keine produktiven Fortsetzungen.
Verwende das offengelegte Codex-Schema: spawn_agent mit einem eindeutigen task_name, vollständigem Brief in message, explizitem model, reasoning_effort und fork_turns: "none", wo unterstützt. Verwende keinen Fork mit vollständigem Verlauf für Überschreibungen. Melde inkompatible Steuerungen, anstatt die globale Konfiguration zu ändern oder sie mit einem verschachtelten CLI zu umgehen. Verwende followup_task für Fortsetzungen auf derselben Stufe und einen neuen Spawn für Modell-/Aufwandsänderungen. Warte-/Liste-/Steuerungsaufrufe erzeugen keine freien zusätzlichen Aufgaben. Unterbreche überfällige Worker und stelle sicher, dass Schreibvorgänge beendet werden, bevor du fortfährst.
Zeichne angeforderte und beobachtbare effektive Einstellungen auf; verwende unavailable, wenn effektive Werte nicht offengelegt sind. Ersetze niemals stillschweigend nicht verfügbare Modelle oder Einstellungen. Behalte Beweispfade in Briefen, anstatt Transkripte zu kopieren. Wiederholte Briefe benennen die Korrektur/Hypothese und sagen setze den Patch fort oder ersetze diese Hunkte.
Abrechnung und Bewertung
Verfolge Gesamtaufrufe, Aufrufe pro Phase und Stufe pro Phase/Arbeitselement separat. Jeder neue Arbeitsauftrag, Wiederholungsversuch oder Fortsetzung kostet einen Aufruf; Statusmeldungen und Wartezeiten kosten keinen. Parallele Worker und Basislinien-Test-Worker werden einzeln gezählt. Erstelle, wenn unterstützt, einen Laufzeit-Task-Listen-Eintrag pro ausgesendetem Auftrag oder Fortsetzung; das Aktualisieren kostet keinen Aufruf. Ein korrektes Validieren FEHLGESCHLAGEN ist eine erfolgreiche Validierung, kein Grund, den Validator zu eskalieren. Diagnostiziere den Fehler, bevor du eine Zeile auswählst.
| Feststellung | Nächste Aktion | Zählt als |
|---|---|---|
| Unzureichende Arbeit | Eskaliere die verantwortliche Phase mit Beweisen | Aufruf + Stufenaufstieg/-sprung |
| TEILWEISE mit solidem Ansatz und Fortschritt | Fahre auf derselben Stufe fort | Aufruf |
| Zweite TEILWEISE auf derselben Stufe oder keine Fortschrittsbeweise | Eskaliere diese Phase | Aufruf + Stufenaufstieg/-sprung |
| Falsche Diagnose | Eskaliere Erkunden; überarbeite danach den Implementierungs-Brief | Aufruf + Stufenaufstieg/-sprung (Erkunden) |
| Validieren FEHLGESCHLAGEN ist falsch | Übergeordneter Agent korrigiert mit aufgezeichneten Beweisen oder eskaliert Validieren; ändere Implementieren nicht | Keiner für Korrektur; Aufruf + Stufenaufstieg/-sprung für erneute Validierung |
| Validieren FEHLGESCHLAGEN identifiziert korrekt unzureichende Implementierung | Eskaliere Implementieren, dann neues Validieren auf seiner aktuellen Stufe | Aufruf + Stufenaufstieg/-sprung (Implementieren), Aufruf (Validieren) |
| Validieren läuft mit aufgelisteten abgeschlossenen Prüfungen ab | Fahre auf seiner aktuellen Stufe mit ausstehenden Prüfungen fort | Aufruf |
| Umgebungsfehler oder fehlende Voraussetzung | Behebe innerhalb der Autorisierung, dann einmal wiederholen; stoppe, wenn ungelöst | Aufruf für Wiederholung; keine Stufenänderung |
| Blockierende Mehrdeutigkeit ändert „erledigt“ oder Risiko der Stufe D | Frage den Benutzer; benenne den Blocker | Keiner |
Die Korrektur durch den übergeordneten Agenten hebt Prüfungen nicht auf: Akzeptanz erfordert Beweise für jedes Kriterium. Setze die Validierung im selben Agenten nur fort, wenn er nie implementiert hat und der Patch unverändert ist. Verwende nach einer Reparatur einen neuen Validator. Ein korrektes FEHLGESCHLAGEN auf Stufe 5 erschöpft den Validator nicht; bewerte die Implementierung.
Budgets: A 3 Aufrufe; B 4; C/D 8. Überprüfe vor dem Dispatch: Die verbleibenden Aufrufe müssen alle vorgeschlagenen Worker plus eine abschließende Validierung abdecken, wenn ihre Arbeit dies erfordert. Die Validierung selbst benötigt nur ihren eigenen Aufruf. Ein verbleibender + abschließende Validierung ist erlaubt; zwei verbleibende + Implementieren ist erlaubt; zwei verbleibende + zwei Implementieren ist nicht erlaubt. Reduziere einen Batch nur, wenn alle erforderlichen Arbeiten noch hineinpassen. Respektiere nach einer Hochstufung die Budgets der neuen Stufe. Überprüfe erneut nach der Hochstufung erneut.
Der letzte erlaubte Aufruf kann die Aufgabe erfolgreich abschließen. Stoppe andernfalls vor unbezahlbarer Arbeit, bei Fehlschlag auf der letzten Stufe oder bei ungelösten Blockern. Überspringe niemals stillschweigend erforderliche Arbeiten oder behaupte Fertigstellung mit ausstehender erforderlicher Validierung. Gewöhnliche Implementierungsentscheidungen benötigen keine Benutzerfrage; dokumentiere sie.
Snapshots und Übergaben
Der übergeordnete Agent allein führt das eingebettete Bash-/Git-Snapshot-Skript unten aus. Es wird keine Begleitdatei benötigt. Erstelle mit umask 077 ${TMPDIR:-/tmp}/escalating-subagents/, dann ein eindeutiges task.XXXXXX-Verzeichnis dort mit mktemp -d. Extrahiere den markierten Block mit diesem Befehl, niemals durch erneutes Eintippen (SKILL ist der absolute Pfad dieses Dokuments, TASK das Aufgabenverzeichnis):
sed -n '/^<!-- agent-snapshot:start -->$/,/^<!-- agent-snapshot:end -->$/p' SKILL | sed '1,/^```bash$/d;/^```$/,$d' > TASK/agent-snapshot.sh
Sein SHA-256 (shasum -a 256 oder sha256sum) muss ddc6cd474ae00cb7fc7613deefb4a9f5ff959f6b641abf041f1a7e26d7d8ca95 sein; eine Abweichung ist ein Blocker. Verwende <task>/state separat für Snapshots. Platziere das Skript nicht im anfänglich leeren Zustandsverzeichnis. Führe es mit Bash aus, never source it.
Zeichne absolute Repository-, Helfer- und Zustandspfade im übergeordneten Register auf; übergib sie explizit bei jedem Aufruf, ohne dich auf den Shell-Zustand zwischen Befehlen zu verlassen. Worker führen niemals den Helfer aus oder erhalten seine Kontrollpfade. Initialisiere erfolgreich vor jedem Dispatch; melde Initialisierungsfehler und stoppe, identifiziere Sandbox-Blocker nur, wenn Berechtigungen sie verursacht haben. Großbuchstaben unten sind Platzhalter; zitiere tatsächliche Pfade:
bash HELFER init REPO STATE
bash HELFER capture STATE base
bash HELFER capture STATE pre-1
bash HELFER capture STATE post-1
bash HELFER diff STATE pre-1 post-1 names0
bash HELFER diff STATE pre-1 post-1 stat
bash HELFER diff STATE base post-1 patch
Erfasse base einmal, pre-N unmittelbar vor jedem Dispatch/Batch und post-N, nachdem alle seine Worker und Schreibvorgänge abgeschlossen sind. Speichere integrierte Patch-Ausgabe in Kratz-Beweisen. Benannte Snapshots sind unveränderlich. Der Zustand persistiert Tree-IDs und temporäre Indizes/Objekte; die tatsächliche Index-/Objekt-Datenbank bleibt unverändert. Verfolgte ignorierte Dateien und nicht ignorierte unversionierte Dateien sind enthalten. Verwende git diff HEAD nicht als Ersatz.
Helfer-Fehler sind Blocker. Er lehnt gleichzeitige Schreibvorgänge ab; lösche eine Sperre nicht, es sei denn, ihr aufgezeichneter Prozess ist bestätigt gestoppt. Unterbrochene unveröffentlichte Erfassungen können benannte Snapshots nicht ersetzen. Behalte den Zustand bis zum Abschluss der Berichterstattung und aller beabsichtigten Folgemaßnahmen.
Verwende NUL-getrennte geänderte Pfade für Umfangsprüfungen, stat für Zusammenfassungen und den integrierten Patch für die Validierung. Änderungen außerhalb des Umfangs werden abgelehnt, es sei denn, der übergeordnete Agent erweitert explizit den Besitz für eine legitime Abhängigkeit. Bewahre nicht zusammenhängende Arbeit; setze sie niemals automatisch zurück, bereinige sie, stashe sie oder mache sie rückgängig.
Versende disjunkte Implementierungs-Worker zusammen im Rahmen der verfügbaren Kapazität. Vergleiche für jeden Batch mit der Vereinigungsmenge des Besitzes; Berichte liefern individuelle Zuordnung, keinen Autornachweis. Warte auf den gesamten Batch, bevor du den Umfang überprüfst oder validierst. Serialisiere gemeinsame Dateien/Infrastruktur und nicht zusammenhängende gleichzeitige Schreiber, die Snapshots verunreinigen würden.
Überprüfe Befehlsergebnisse, Beweispfade, zitierte Orte und Dateizustandsrelevanz bei Übergaben. Neue Bearbeitungen machen betroffene Prüfungen ungültig. Akzeptierte Arbeit schreitet voran; abgelehnte Arbeit kehrt zur Bewertung zurück. Verfolge langlaufende Befehle bis zum Abschluss und stoppe ausstehende Schreibvorgänge vor dem Snapshot; Hintergrundstart ist kein Abschluss.
Repository-Einschränkungen und Briefe
Lies die entsprechenden AGENTS.md, bereichsspezifische Anweisungen, Spezifikationen und Designrichtlinien. Verwende den Paketmanager des Repositorys, Sperrung, Abhängigkeitsversionen, Migrations- und Dokumentationsrichtlinien. Trage Produktionsdaten-Einschränkungen explizit in relevante Worker-Briefe ein, einschließlich Live-Daten- und Nur-Additiv-Anforderungen, wo zutreffend; verlasse dich nicht darauf, dass Worker sie indirekt entdecken.
Worker committen, pushen, deployen oder führen niemals nicht zusammenhängende externe Schreibvorgänge durch. Der übergeordnete Agent darf explizit angeforderte Aktionen nur ausführen, wenn Repository- und Host-Regeln sie erlauben.
Jeder Brief enthält: Aufgabe, Stufe, ursprüngliche Anfrage, absolute Repository-/Anweisungs-/Beweispfade, Modell/Aufwand, Kriterien wörtlich, Besitz, Befehlstimeouts, Wanduhr-Budget, Produktionsdaten-Einschränkungen und „delegiere nicht, rufe dieses Skill nicht auf oder führe den Snapshot-Helfer nicht aus".
- Erkunden: Relevante Pfade, vorheriger Bericht, falls Wiederholung; besitzt nichts außer explizit autorisierten Repro-/Testdateien. Keine Produktbearbeitungen oder Installationen. Berichte Ergebnis, Ursache/Umfang, Orte, Beweise, vorgeschlagene Kriterien, offene Punkte, nächsten Schritt.
[Fortsetzung folgt – gekürzt aufgrund der Länge]