Günstige parallele Agenten für Codex
Aufruf: Dieses Skill wird nur ausgeführt, wenn der Benutzer es explizit benennt; es wird niemals automatisch angewandt. Kein Orchestrierungs-Skill ruft das andere auf, und Worker rufen keines auf. Wenn der Benutzer sowohl escalating-subagents als auch dieses Skill für eine Aufgabe aufruft, frage nach, welches zutrifft, bevor du dispatchen.
Angenommener Koordinator: das Elternmodell, wie vom Benutzer ausgewählt, typischerweise GPT-6.1 Sol; high ist eine anfängliche Aufwandsempfehlung zur Bewertung, keine Einstellung, die dieses Skill ändert. Ein Elternmodell auf ultra kann proaktiv delegieren: teile dies in der ersten Fortschrittszeile mit, empfehle high, delegiere nur über die Dispatches dieses Skills und berücksichtige zusätzliche Zuweisungen unter "Pinning". Halte das tatsächliche Elternmodell und den Aufwand im Protokollkopf fest. Der Koordinator orchestriert: klassifiziert das Tier, schreibt "Erledigt bedeutet"-Kriterien, zerlegt in Items, legt Schnittstellen und Entscheidungen fest, briefed Worker, dispatched Batches, erfasst Snapshots, prüft jeden Akzeptanzeintrag, triagiert und berichtet. Er bearbeitet niemals Produktcode und liest niemals Worker-Transkripte. Er liest Evidenzauszüge, wie es die Akzeptanz erfordert, und den integrierten Patch für Tier-D-Akzeptanz, bestrittene Validierung und Scope-Verstöße.
Worker laufen nur auf einem günstigen Modell und führen jeweils ein zugewiesenes Item aus. Sie delegieren niemals, rufen niemals dieses oder ein anderes Orchestrierungs-Skill auf und führen niemals den Snapshot-Helper aus. Respektiere Host-Berechtigungen und den Zusammenarbeitsmodus; der Plan-Modus erlaubt keine Implementierung oder mutationsproduzierende Entdeckung.
Jedes Kriterium trägt eine ID und einen erforderlichen Evidenztyp: behavioral (ausgeführter Test, Build oder Lauf, der die Änderung übt), static (Typprüfung oder Linting), parse (Syntax- oder Parse-Prüfung), format (Formatierungsprüfung) oder inspection (überprüfter Diff). Evidenz, die schwächer ist als der Typ des Kriteriums, erfüllt es nie; eine Parse-Prüfung erfüllt ein parse-Kriterium und nichts weiter.
Tiers und Zuordnungsmatrix
Benenne das Tier in der ersten Fortschrittszeile. Jede Stufe kann es hochstufen; niemals herabstufen. Hochstufung behält Zähler bei, übernimmt das höhere Budget und überarbeitet Kriterien für betroffene Worker. Größe Items an die Matrix anpassen: Ein Worker kann mehrere Dateien besitzen, also Items zusammenführen, anstatt Arbeit fallen zu lassen. Die Validierung läuft einmal pro Zyklus, nachdem der vollständige Implementierungszyklus eingefroren wurde, niemals pro Batch; Zwischenbatches erhalten einen erfassten und geprüften post-N, bevor der nächste Batch startet, und nur vorläufige Worker-Aufzeichnungen.
| Tier | Arbeit | Karte (schreibgeschützt) | Implementieren | Validieren pro Zyklus (V) | Budget |
|---|---|---|---|---|---|
| A | Trivial, vollständig spezifiziert, risikoarme Bearbeitung mit konkreter Prüfung | 0 | 1 bei low | 0; vom Koordinator durchgeführte Post-Capture-Prüfung | 3 |
| B | Klare Änderung | 0 | ≤ 4 bei medium | 1 bei medium | 7 |
| C | Unklarer Bug oder umfangreiches Feature; Standard | ≤ 3 bei low/medium | ≤ 4 bei medium | 1 bei medium | 10 |
| D | Auth, Mandantenisolation, Migrationen, Warteschlange/Sync, Produktionsdatenänderungen | ≤ 3 bei medium | ≤ 4 bei medium | 2 bei medium mit unterschiedlichen Briefings (Tests + Kriterien; Spezifikation + Regressionen); Koordinator liest den Patch | 12 |
Jede neue Zuweisung, Wiederholung oder Fortsetzung kostet einen Aufruf; parallele Worker werden einzeln gezählt; Statusmeldungen und Wartezeiten kosten nichts. Sei M die Anzahl der Shards im Karten-Batch, der aufgenommen wird (0 für einen Implementierungs-Batch), U die erforderlichen, noch nicht versendeten Implementierungs-Items, einschließlich derer in diesem Batch (vor dem Mapping die geplante Anzahl, mindestens 1), und V die Anzahl der Validierer pro Zyklus; die Reserve ist eine Reparatur mit ihrer erneuten Validierung, 1 + V. Aufnahme eines Batches erfordert remaining ≥ M + U + V + (1 + V); falls dies fehlschlägt, reduziere die Breite, führe Items zusammen oder beides. Serialisieren ändert die Parallelität, nicht die Aufrufanzahl: Die Aufnahme zählt jedes verbleibende erforderliche Item. Validierer-Wiederholungen (nicht unterstütztes BESTANDEN, NICHT SCHLÜSSIG) verbrauchen Reserve-Aufrufe. Nach einem FEHLGESCHLAGEN bei r Items: wenn remaining ≥ r + V, führe die r Reparaturen und den vollständigen neuen Validierungssatz ohne weitere Reserve durch, und ein weiteres FEHLGESCHLAGEN beendet den Lauf mit dem Bericht; wenn 1 + V ≤ remaining < r + V, repariere remaining − V Items, validiere und melde den Rest als ungelöst; wenn remaining < 1 + V, stoppe und melde die fehlgeschlagenen Items als ungelöst, ohne einen unveränderten Patch erneut zu validieren. Durchgerechnete Beispiele: Tier B, vier Items mit Breite 4: 7 → 3 nach Implementierern → 2 nach Validierung → ein FEHLGESCHLAGEN bei zwei Items erlaubt eine Reparatur plus einen Validierer → 0, ein Item ungelöst. Tier B mit einem nicht unterstützten BESTANDEN: 7 → 3 → 2 → neuer Validierer → 1 → FEHLGESCHLAGEN → 1 < 2, stoppe. Tier C, ein Karten-Batch von 3 mit 4 geplanten Items: 3 + 4 + 1 + 2 = 10 erlaubt → 7 → implementiere 4 → 3 → validiere → 2 → FEHLGESCHLAGEN bei einem Item → repariere und validiere → 0. Tier D: 3 + 4 + 2 + 3 = 12 → 9 → 5 → 3 → FEHLGESCHLAGEN bei einem Item → 0. Die Leiter ist nur verfügbar, solange das Budget es erlaubt; bei maximaler Breite erlaubt die Reserve eine Reparatur, nicht jede Sprosse, und der Koordinator sagt dies, wenn er die Breite wählt. Die Zerlegung erhöht niemals das Budget.
Aufwandsleiter
Das Worker-Modell ändert sich nie; der Aufwand schon. medium ist die Standardeinstellung und der Ort, an dem man bleiben sollte.
| Sprosse | Modell | reasoning_effort | Verwendung |
|---|---|---|---|
| 0 | gpt-6-luna | low | Mechanische Arbeit: schreibgeschützte Karten-Shards, Umbenennungen, Verschiebungen, Formatierung, Ausführen eines benannten Befehls und Melden; keine Ermessensentscheidungen |
| 1 | gpt-6-luna | medium | Standard für jedes Entdecken, Implementieren und Validieren von Items |
| 2 | gpt-6-luna | medium | Neuer Worker mit einer konkreten Korrektur und dem vorherigen Aufzeichnungspfad; der einzelne Auslassungs-Wiederholungsversuch |
| 3 | gpt-6-luna | max | Nur nach einem bestätigten Reasoning-Fehler auf Sprosse 1 oder 2 oder einem zweiten PARTIELL ohne Fortschritt |
Übersprungene Ebenen: high wird übersprungen, da sein beobachteter Gewinn gegenüber medium in unabhängigen Code-Bewertungen keine Sprosse rechtfertigte, und xhigh, weil die Leiter eine Eskalationssprosse behält und max mehr Punkte pro Dollar brachte. Lücke nicht füllen.
Sprosse-0-Briefings sagen: keine Ermessensentscheidungen; BLOCKIERT zurückgeben, wenn eine nötig ist. Validierer starten bei medium in jedem Tier. Ein korrektes FEHLGESCHLAGEN eskaliert niemals einen Validierer. Umweltfehler erhöhen niemals die Sprosse. Es gibt keine Modell-Eskalation: Wenn die Leiter erschöpft ist, stoppt der Koordinator und berichtet.
| Feststellung | Aktion | Zählt als |
|---|---|---|
| Sprosse-0-Worker gibt BLOCKIERT zurück, weil Ermessen erforderlich ist | Entscheidung vorab treffen, wenn möglich; Item auf Sprosse 1 erneut versenden | Aufruf; Sprosse → 1, kein Fehler |
| Sprosse-1-Worker lässt eine Anforderung aus oder liest das Briefing falsch | Sprosse 2: neuer Worker mit Korrektur und vorherigem Aufzeichnungspfad | Aufruf |
| Bestätigter Reasoning-Fehler auf Sprosse 1 oder 2 oder zweites PARTIELL ohne Fortschritt | Sprosse 3 | Aufruf + Sprosse |
| PARTIELL mit fundiertem Ansatz und Fortschritt | Weiter auf derselben Sprosse | Aufruf |
| Validierer gibt nicht unterstütztes BESTANDEN zurück (Evidenztyp zu schwach, veralteter Snapshot oder eine Prüfung, die nicht lief) | Ablehnen; neuer Validierer auf Sprosse 2 mit expliziten Evidenzanforderungen; zweites Vorkommen → Sprosse 3; Implementierung unberührt | Aufruf pro Stück |
| Validierer gibt korrektes FEHLGESCHLAGEN zurück | Erfolgreiche Validierung; Reparaturzyklus starten: fehlgeschlagene Items eskalieren gemäß ihrer eigenen Leiter, dann vollständiger neuer Validierungssatz | r + V Aufrufe |
| Validierer FEHLGESCHLAGEN wird vom Koordinator mit aufgezeichneter Evidenz widerlegt | Korrektur aufzeichnen; keine Änderung an der Implementierung; nur erneut validieren, wenn sich der Patch ändert | keine |
| Validierer NICHT SCHLÜSSIG oder BLOCKIERT aus Umweltgründen | Behebung im Rahmen der Autorisierung, einmal auf derselben Sprosse wiederholen; ungelöste Prüfungen werden als blockiert in den Bericht übernommen | Aufruf; kein Sprossenwechsel |
| Sprosse 3 fehlschlägt bei einem Item | Einmal pro Item: Item eingrenzen (kleinerer Umfang, Entscheidungen vorab getroffen) und auf Sprosse 1 wiederholen, wenn die Aufnahme es erlaubt; das eingegrenzte Item erbt Historie und Budget | Aufruf |
| Fehler im letzten Reparaturzyklus | Stoppen; ungelöste Items, Evidenz und nächsten Schritt melden; kein weiteres Dispatchen | keine |
| Blockierende Unklarheit ändert "erledigt" oder Tier-D-Risiko | Benutzer fragen; Blocker benennen | keine |
Parallele Batches
Ein Item tritt einem Batch nur bei, wenn alle drei Bedingungen gelten: disjunkter Besitz (Dateien oder Globs); Abhängigkeiten erfüllt (Schnittstellen im Briefing festgelegt, kein Item konsumiert die unvollendete Ausgabe eines anderen); keine widersprüchlichen Seiteneffekte (generierte Dateien, Schema oder Migrationen, Datenbanken, Ports, Caches, Test-Fixtures, CI-Konfiguration). Ansonsten serialisieren oder zusammenführen. Standardgrenzen, vom Benutzer anpassbar, sind 4 Schreiber und 3 schreibgeschützte Shards pro Batch; sie sind Heuristiken aus der asynchronen Delegationsforschung, keine Grenzen. Kapazität stammt von der Laufzeit: verwende die angekündigten Slots des Hosts und seine Zählsemantik und dispatche min(cap, available slots). Dispatche einen ganzen Batch in einer Nachricht. Bei einem teilweisen Dispatch behalte die gestarteten Worker bei, registriere sie beim Namen und dispatche den Rest, wenn Slots frei werden; starte niemals ein bereits laufendes Item neu.
Jedes Briefing enthält die Entscheidungsliste des Koordinators (Namen, Schnittstellen, bisher getroffene Konventionen), da Aktionen Entscheidungen beinhalten und parallele Worker sonst abweichen würden. Die Ausführung im gemeinsamen Arbeitsbereich ohne Worktrees ist ein bewusster Kompromiss: Besitz plus Snapshot-Scope-Prüfungen ersetzen physische Isolation.
Evidenzlebenszyklus und Einfrieren
Batches werden über den Lauf hinweg nummeriert, Karten-, Implementierungs- und Reparatur-Batches gleichermaßen. Erfasse base einmal und pre-N unmittelbar vor Batch N; füge den Snapshot-Namen und die Baum-ID in jedes Briefing dieses Batches ein. Karten-Worker berichten gegen pre-N. Implementierungs-Checks sind bis zur Validierung vorläufig; ihre Aufzeichnungen sagen dies und nennen pre-N. Nachdem alle Schreiber und Hintergrundbefehle von Batch N gestoppt haben, erfasse post-N und prüfe names0 pre-N post-N gegen den Besitz dieses Batches (leer für einen Karten-Batch), bevor du etwas anderes dispatchst; names0 post-N pre-N+1 muss ebenfalls leer sein, und jede Änderung dort ist eine Bearbeitung außerhalb des Geltungsbereichs. Ein Zyklus ist eingefroren, wenn sein letzter Implementierungs-Batch diese Prüfung besteht: neue Validierer erhalten das post-N dieses Batches und erstellen Akzeptanzaufzeichnungen gegen diesen eingefrorenen Zustand, der Koordinator prüft auch die Vereinigung des Zyklus von seinem ersten pre bis zu diesem post, und während der Validierung finden keine Schreibvorgänge statt. Barriere: Die Validierer eines Zyklus werden gemeinsam dispatched und erwartet, und keine Reparatur beginnt, bis jeder von ihnen zurückgekehrt ist oder unterbrochen und bestätigt beendet wurde. Eine Reparatur ist ein eigener Batch: erfasse ihr post-N, prüfe es und führe den vollständigen Validierungssatz neu aus. Vor der Akzeptanz erfasse final; names0 zwischen dem validierten Snapshot und final muss leer sein. Der Helfer erkennt
… [für die Übersetzung gekürzt]