Zum Inhalt springen
SupaCloud Docs
Farbschema wählenSprache wählen

Einen Koordinator mit Worker-Subtasks fahren

Ein Koordinator ist eine gewöhnliche Agent-Task, deren Profil delegieren darf. Statt alles selbst zu implementieren, zerlegt er einen Issue-Stream in Worker-Subtasks — jede eine echte Task mit eigenem Agenten, Branch, Kosten-Attribution und Event-Feed — und fährt die Schleife: Kapazität planen, delegieren, warten, Rückfragen beantworten, steuern, reviewen, PRs eröffnen, berichten.

Alles Folgende läuft über die MCP-Werkzeuge des Agenten selbst; konfiguriert werden nur die Profile.

  1. Dem Koordinator ein delegationsfähiges Profil geben. Unter Einstellungen → Agent-Profile braucht das Koordinator-Profil die Ops-Stufe (supacloud.ops.*), damit delegate_subtask und die Hub-Werkzeuge auf seiner Fläche liegen. Lege ein zweites, günstigeres Profil für die Worker an (dessen Slug übergibt der Koordinator beim Delegieren). Worker können read-only bleiben.

  2. Vor dem Fan-out planen. Ein guter Koordinator-Prompt beginnt mit den zwei dafür gebauten Lese-Werkzeugen:

    • capacity.get — belegte/freie Concurrency des Workspace, die Slots der Runner-Flotte und die aktiven Kinder des eigenen Baums. Auf einer Ein-Slot-Instanz stellt ein Fünffach-Fan-out nur vier Worker in die Warteschlange.
    • limits.get — verbleibende Werkzeug-Budgets je Task/Stunde (Profil-Overrides eingerechnet), das Geld-Budget des Workspace und die freien Subtask-Plätze (Kinder je Parent, Nachfahren je Root, Delegationstiefe).

  3. Delegieren und blockierend warten — kein Busy-Loop. delegate_subtask(profile_slug, prompt) startet einen Worker; get_subtask_result(sub_task_id, wait_seconds) hält die Antwort server-seitig, bis das Kind fertig ist oder das Fenster abläuft (wait_seconds bis 600, voll gehalten, sofern der Betreiber die Decke nicht gesenkt hat). Beim Ablauf kommt wait_timed_out: true zurück — der Koordinator ruft einfach erneut. subtask.list ist die Streams-Übersicht zwischen den Warterunden: jede Task des Baums mit Status, Branch, verknüpftem Issue und Kosten.

  4. Rückfragen der Worker beantwortet der Koordinator selbst. Wirft ein Worker ein Gate der Klasse Frage, sieht der Koordinator es über subtask.pending_gates und beantwortet es mit subtask.answer_gate — der Worker läuft ohne Mensch weiter. Das ist bewusst eng: nur Fragen. Tool-, Visual-, Danger- und Tier-Change-Gates bleiben menschlich, und ein Mensch sieht weiterhin jedes Gate im Freigaben-Eingang — die Eskalation ist additiv, nie exklusiv.

  5. Einen laufenden Worker steuern. subtask.intervene(sub_task_id, message) stellt eine Nachricht in ein laufendes Kind zu — eine Scope-Erinnerung, eine Kurskorrektur, ein früher Stopp-Hinweis. Das dürfen nur Vorfahren auf der Delegationskette, und jede Zustellung schreibt eine Audit-Zeile.

  6. Dem Continuation-Guard vertrauen. Ein langer Stream heißt viele Warterunden, und ein Modell kann ins Erzählen abdriften statt Werkzeuge zu rufen — die Session endete dann, während Worker noch laufen. Genau das fängt der Continuation-Guard des Runners ab: ein Koordinator mit aktivem Teilbaum wird mit einem Weiter-Pollen-Anstoß fortgesetzt (begrenzt — nach der Kappe endet er laut als unterbrochen-und-wiederaufnehmbar, nie als stiller Erfolg).