Haupt-Agent nur für Koordination · Schwere Aufgaben an Sub-Agenten delegieren · Stets ansprechbar
Problem: Du gibst dem AI-Assistenten eine schwere Aufgabe, und dann reagiert er nicht auf Nachrichten, du kannst nicht unterbrechen, es dauert Minuten bis zur Antwort. Ursache: Nicht das Modell ist langsam, sondern der Haupt-Agent führt die schwere Aufgabe im Vordergrund aus – der gesamte Antwortzyklus ist blockiert; die Nachrichten des Nutzers warten in der Warteschlange. Lösung: Mache „schwere Aufgaben delegieren + stets ansprechbar“ zu einer harten Regel in den Agenten-Instruktionen und schreibe sie mit einem Skript idempotent auf das lokale System.
Plattformunabhängig: Der Regelblock selbst ist plattformunabhängig und funktioniert mit jedem AI-Agenten, der Instruktionsdateien / System-Prompts / Sub-Agenten unterstützt (Claude Code / Codex / Cursor / WorkBuddy / Hermes / andere ähnliche Plattformen). Das Bereitstellungsskript schreibt nur an zwei getesteten Orten direkt in Dateien; für alle anderen Plattformen wird der Regelblock als einfügbare Markdown-Datei exportiert – es werden keine Konfigurationspfade erraten oder Felder erfunden.
Wann verwenden
- Wenn Benutzer sich beschweren: „zu lange Wartezeiten / Unterbrechung blockiert / niemand antwortet / ich muss oft chatten“;
- Um die Regel „schwere Aufgaben an Sub-Agenten delegieren, Haupt-Agent bleibt ansprechbar“ auf einem oder mehreren lokalen Agenten-Instanzen zu institutionalisieren;
- Um diese Mechanik einer Instanz hinzuzufügen (mit
scripts/provision_agent_responsiveness.py) und ihre Wirksamkeit zu überprüfen (mitscripts/audit_agent_responsiveness.py).
Ursache
Der Haupt-Agent führt schwere Aufgaben (Batch-Abrufe, mehrere Dateien, lange Skripte) im Vordergrund aus → der gesamte Antwortzyklus wird blockiert:
- Während eines langen Vordergrundbefehls können Benutzernachrichten nur in der Warteschlange warten;
- Bei manchen Plattformen werden Benutzerunterbrechungen, während Sub-Agenten laufen, zu „Warten“ degradiert – sie werden erst am Ende des gesamten Zyklus gelesen;
- So entsteht beim Benutzer das Gefühl: „Der Assistent ignoriert mich“ – dabei arbeitet er nur verbissen.
Schlussfolgerung: Damit man den Assistenten jederzeit erreichen kann, muss der Assistent schwere Aufgaben nicht selbst ausführen und es muss einen sofortigen Unterbrechungskanal geben, während er beschäftigt ist. Beides muss zusammen umgesetzt werden.
Drei Dinge gemeinsam tun (alle notwendig)
1. Regelblock in die Instruktionsebene des Agenten schreiben (ganz oben)
Den vollständigen Regelblock findest du in templates/agent-ops-rules.md (das Skript verwendet ihn). Die sechs Kernregeln:
- Vierstufige Bewertung (erst bewerten, dann handeln): L0 (Frage/Antwort) → direkt antworten, nicht delegieren ｜ L1 (schnelle, einfache Aufgabe ≤ 1 Tool und ≤ 20 Sekunden) → direkt erledigen ｜ L2 (mehrere Schritte / lange Arbeit / Batch / Netzwerk) → immer delegieren ｜ L3 (Benutzerentscheidung nötig) → zuerst antworten „Das müssen Sie entscheiden: X“.
- Nach der Delegierung sofort eine Antwort senden und die Runde beenden (Nicht warten; warten = nicht delegiert).
- Befehle länger als 60 Sekunden in den Hintergrund verschieben (Vordergrundbefehle blockieren den gesamten Antwortzyklus).
- Sub-Agenten liefern nur Ergebnisse + Pfad zur Ausgabe zurück; Analyse und Integration macht der Haupt-Agent.
- Benutzerunterbrechung hat höchste Priorität: Zuerst sofort antworten; wenn möglich beantworten; niemals den Benutzer warten lassen.
- Aufgaben, die Fragen/Entscheidungen erfordern, bleiben beim Haupt-Agent (Sub-Agenten können Menschen nicht fragen).
Der Regelblock ist mit
<!-- agent-ops-rules:v1 -->…<!-- /agent-ops-rules -->umschlossen. Das Bereitstellungsskript nutzt diese Markierungen für Idempotenz: Bei wiederholter Ausführung wird nur der markierte Block ersetzt, deine anderen Inhalte bleiben unberührt.
2. Sofortigen Unterbrechungskanal bereitstellen (plattformabhängig)
Verschiedene Plattformen haben unterschiedliche Semantiken für „Benutzer unterbricht, während der AI beschäftigt ist“ – die Auswirkungen sind sehr unterschiedlich:
| Unterbrechungssemantik | Tatsächliche Erfahrung | Erfüllt „jederzeit ansprechbar“? |
|---|---|---|
| Wartet bis zum Ende des gesamten Zyklus | Benutzer wartet | ❌ |
| Wird an das letzte Tool-Ergebnis angehängt und erst zugestellt, wenn die aktuellen Tools fertig sind | Wenn der Haupt-Agent einen langen Vordergrundbefehl ausführt, bleibt alles bis zum Exit blockiert | ❌ (bei langen Befehlen unwirksam) |
| Unterbricht sofort die aktuelle Generierung / Anfrage, behandelt die Benutzereingabe als neue Nachricht und behält die bereits abgeschlossene Arbeit | Unterbrechung ist nahezu sofort wirksam | ✅ |
Kriterium (ein Satz): Für „jederzeit unterbrechbar“ muss die Semantik sofortige Unterbrechung + Behalten abgeschlossener Arbeit gewählt werden; und sie muss mit der Regel „lange Befehle in den Hintergrund“ kombiniert werden – beides zusammen ergibt Sinn. (Details für Hermes siehe references/hermes-implementation.md; für andere Plattformen suche die entsprechende Option in den Einstellungen.)
3. Ausreichende Parallelität für Sub-Agenten (sonst führt „alles delegieren“ zu Warteschlangen)
Voraussetzung für „schwere Aufgaben immer delegieren“ ist, dass mehrere gleichzeitig ausgeführt werden können. Bei geringer Parallelität wird Delegieren zum Warten – der Benutzer wartet trotzdem.
- Stelle die Parallelitätsgrenze auf ein akzeptables Niveau ein (üblich: 3–6). Die Folgen einer Überschreitung sind plattformabhängig (manche lehnen den gesamten Batch ab, andere kürzen ihn). Batchweises Delegieren ist sicherer als die Grenze zu überreizen.
- Parallelität wirkt sich direkt auf die Kosten aus: Jeder Sub-Agent wird separat abgerechnet; stelle nach Bedarf ein, nicht blind auf Maximum.
4. Nach Änderungen muss der Agent die Instruktionen neu laden
Instruktionsdateien / System-Prompts werden normalerweise nur beim Start des Prozesses gelesen. Schreiben ohne Neustart = keine Wirkung:
- Starte den entsprechenden Agenten-Prozess / das Gateway / die Sitzung gemäß den Vorgaben deiner Plattform neu;
- Überprüfe nach dem Neustart: Lass den Agenten die Regel einmal wiederholen. Nur wenn er sie aussprechen kann, ist sie wirklich geladen (nicht „ich denke, sie ist geladen“).
Ein-Klick-Bereitstellung / Prüfung
# ① Vorschau (Standardverhalten, keine Dateiänderungen): Zeigt, welche Dateien betroffen wären
python3 scripts/provision_agent_responsiveness.py
# ② Tatsächliches Schreiben (automatische Sicherung + idempotent; exportiert einfügbaren Regelblock, wenn keine Plattform erkannt wird)
python3 scripts/provision_agent_responsiveness.py --apply
# ③ Regelblock als einfügbare Markdown-Datei exportieren (für Codex / Cursor / WorkBuddy / unbekannte Plattformen)
python3 scripts/provision_agent_responsiveness.py --apply --export --out ./agent-ops-rules.md
# ④ Prüfung: Existiert der Regelblock? Ist er ganz oben? Stimmt er mit der aktuellen Vorlage überein?
python3 scripts/audit_agent_responsiveness.py
Verhalten des Bereitstellungsskripts (fest codiert, nachprüfbar):
| Vereinbarung | Erklärung |
|---|---|
| Standardmäßig dry-run | Ohne --apply wird nie auf die Festplatte geschrieben |
| Automatische Sicherung | Vor dem Schreiben wird <dateiname>.bak-agent-ops-<zeitstempel> erstellt |
| Idempotent | Mit Markierung: Vergleich des Inhalts; bei Übereinstimmung → überspringen; bei Abweichung → nur den markierten Block ersetzen |
| Benutzerinhalte nicht überschreiben | Nur am Anfang der Datei einfügen (YAML-Frontmatter überspringen), keine Originaltexte löschen |
| Keine Pfade erraten | Nur an zwei getesteten Orten schreiben (Hermes SOUL.md, Claude Code ~/.claude/CLAUDE.md); für andere Plattformen exportieren |
| Reine Standardbibliothek | Nur argparse, pathlib, json etc. verwenden; kompatibel mit Windows/macOS/Linux |
Verhalten des Prüfskripts: Überprüft einzeln auf Dateiebene überprüfbare Fakten (existiert / ist markiert / ist ganz oben / Inhalt aktuell). Wenn keine unterstützte Plattform erkannt wird, gibt es ehrlich „Keine unterstützte Plattform erkannt“ aus und verlässt mit Exit-Code 2 – niemals fälschlich „bestanden“ melden.
Plattform-Adapter (Tool-Namenszuordnung)
| Abstrakte Aktion | Hermes (getestet) | Claude Code | Cursor / Codex / WorkBuddy | Andere ähnliche Plattformen |
|---|---|---|---|
| Regelblock ablegen | <HERMES_HOME>/SOUL.md (und <HERMES_HOME>/profiles/<p>/SOUL.md) | ~/.claude/CLAUDE.md | Entsprechend der globalen Instruktion / System-Prompt-Position deiner Plattform | agent-ops-rules.md exportieren und in den System-Prompt einfügen |
| Sub-Agenten delegieren | delegate_task | Task / Sub-Agent-Tool (gemäß Zuordnung deiner Plattform) | Gemäß Zuordnung deiner Plattform | Gemäß Zuordnung deiner Plattform |
| Lange Befehle in den Hintergrund verschieben | Hintergrundausführung + Benachrichtigung bei Fertigstellung | Hintergrundtask / asynchroner Modus des Befehls-Tools | Gemäß Hintergrundausführungsmethode deiner Plattform | Hintergrundprozess des Systems + Logdatei |
Ehrlichkeitsgrenze: Die Schlüsselnamen und Semantiken für Hermes basieren auf lokalen Tests. Der Pfad
~/.claude/CLAUDE.mdfür Claude Code ist getestet. Die Toolnamen für Cursor / Codex / WorkBuddy können sich mit Versionen ändern – dieses Skill erfindet keine Befehle oder Feldnamen – bitte selbst zuordnen laut obiger Tabelle. Eine vollständigere Version der plattformübergreifenden Delegationsregeln findest du im Skillsubagent-firstdesselben Autors.
Fallstricke (plattformübergreifend)
- Instruktionsdatei wird nur beim Start gelesen: Nach Änderung nicht neu gestartet (oder nicht die richtige Instanz) = keine Wirkung. „Im File steht es drin“ ist kein Nachweis.
- Falsche Unterbrechungssemantik gewählt: Wer „zustellen, wenn aktuelle Tools fertig“ wählt, kombiniert mit „Haupt-Agent führt langen Befehl im Vordergrund“ → Benutzer fühlt sich ignoriert. Muss „sofort unterbrechen + abgeschlossene Arbeit behalten“ sein.
- Umgebungsvariablen können Konfiguration überschreiben: Viele Plattformen haben „env vor config“. Prüfe nach Änderung die tatsächliche Quelle der Einstellung, nicht nur die Konfigurationsdatei.
- Falscher Neustart: Nur der Wrapper-Prozess / die Planungsinstanz beendet, aber der eigentliche Kindprozess läuft noch mit alter Konfiguration. Zur Überprüfung auf Prozessstartzeit achten, nicht auf Prozessanzahl.
- Parallelitätsgrenze nicht überprüft: Gedacht „alle können delegiert werden“, aber tatsächlich wird der gesamte Batch abgelehnt oder gekürzt. → Batchweise delegieren und aktuelle Grenze prüfen.
- Nur an einer Stelle installiert: Mehrere Instanzen / Profile haben eigene, unabhängige Instruktionsdateien und Skill-Verzeichnisse – jede muss einzeln beschrieben werden (das Bereitstellungsskript durchläuft alle Hermes-Profile; für andere Plattformen entsprechend für jede Instanz).
- Haupt-Agent nicht seiner schweren Tools berauben, um ihn zum Delegieren zu zwingen: Auf den meisten Plattformen ist das Toolset der Sub-Agenten eine Teilmenge des Haupt-Agenten (kann keine Tools haben, die der Haupt-Agent nicht hat). Berauben schwächt das gesamte System.
- Falsch bestanden: Wenn das Prüfskript nur prüft, ob „die Wörter im File stehen“, kann es leicht bei veraltetem Inhalt / späteren Überschreibungen dennoch „bestanden“ melden. Überprüfe, ob der Inhalt mit der aktuellen Vorlage übereinstimmt; melde ehrlich „Keine unterstützte Plattform erkannt“, wenn nichts gefunden wird.
Abnahmeliste (Antworte damit, wenn jemand fragt „Ist es wirklich wirksam?“)
A. Dateiebene (vom Skript automatisch prüfbar)
- Zieldatei des Regelblocks existiert und kann
agent-ops-rules:v1per grep finden; - Regelblock ganz oben (in den ersten 33 % der Datei);
- Inhalt des Regelblocks stimmt mit aktueller Vorlage überein (kein veralteter Rest);
- Wiederholtes Ausführen des Bereitstellungsskripts erzeugt keinen zweiten Regelblock und überschreibt keine vorhandenen Inhalte;
-
audit_agent_responsiveness.pyist komplett grün (Exit-Code 0); bei nichterkannter Plattform Exit-Code 2 + klarer Hinweis.
B. Laufzeit (manuelle Überprüfung)
- Nach Neustart: Lass den Agenten die Regel wiederholen. Kann er sie aussprechen = Instruktion wirklich geladen;
- Gib dem Agenten eine schwere Aufgabe → er antwortet sofort mit „Delegiert (wer macht was)“, anstatt 10+ Minuten zu arbeiten;
- Während der schweren Aufgabe: Unterbrich mit einer Nachricht → erhältst sofort eine Quittung, und die Antwort wird nicht unterbrochen;
- Nach Fertigstellung: Das Ergebnis kann vom Haupt-Agenten zurückgelesen und verifiziert werden (nicht nur „Selbstmeldung erledigt“).
C. Grenzfälle
- Während der Benutzerunterbrechung werden laufende Sub-Agenten nicht kaskadenartig abgebrochen (oder die abgebrochenen Teile werden klar kommuniziert);
- Aufgaben, die eine Benutzerentscheidung erfordern, werden nicht an Sub-Agenten delegiert.
Lizenz
MIT License. Frei verwendbar für private und kommerzielle Projekte, mit Namensnennung des Autors.
🙋 Über den Autor
JiuPinJinLi ｜ Verpackt selbst erlebte Fallstricke in „sofort nutzbare“ Skills, kein Lehrbuch. Dieses Skill ist die Version, die ich täglich selbst verwende.
WeChat: ly5419495 (Bei Kontaktaufnahme „SkillHub“ im Betreff angeben – ich priorisiere) Öffentlicher Account: 初五Agent (WeChat-Suche; Rekapitulationen und Methoden sind dort – auch ohne WeChat-Zugang lesbar)
Weitere von mir erstellte, direkt nutzbare Tools findest du auf dieser Regal-Seite (im Browser öffnen): https://skillpay.alipay.com/public/jiupinjinlie
Wenn du bei der Nutzung stecken bleibst oder andere Szenarien hast, die ich in einen Skill verpacken soll, kontaktiere mich über einen der oben genannten Kanäle.
Dieses Skill ist die vollständige Version, ohne Funktionskürzungen.