Ihr Subagent läuft in die falsche Richtung? Jetzt steuern Sie ihn mitten im Lauf um

Montagnachmittag lassen Sie Hermes drei Subagents starten, um einen Refactor zu parallelisieren: einen fürs Frontend, einen fürs Backend, einen für die Tests. Eine halbe Stunde später werfen Sie einen Blick auf den Fortschritt und stellen fest, dass der Backend-Subagent in die falsche Richtung rennt – er schreibt immer noch gegen die alte API, während die neue an jeder Signatur gedreht hat. Früher blieb Ihnen nur, den gesamten Batch abzubrechen, die Anforderungen neu zu erklären und von vorn anzufangen; wenn Sie Pech hatten, gerieten auch die zwei Subagents, die gerade gut unterwegs waren, mit in die Schusslinie. Das ist vorbei. Seit dem 13. August bringt delegate_task eine Echtzeit-Kontrolloberfläche mit: Sie können die laufenden Subagents auflisten, den abgedrifteten per steer auf Kurs bringen oder einen, der nicht mehr zu retten ist, per stop beenden – ohne den Rest des Teams zu unterbrechen.
Die Konsole des Dirigenten: drei Steuer-Aktionen
Zunächst eine kurze Vorbemerkung: Ein Subagent ist ein separater „Klon“, den Hermes ausschickt, um eigenständig zu arbeiten – mit eigenem, isoliertem Gesprächskontext und eigener Terminal-Sitzung. Bisher konnte delegate_task genau eines: spawnen – eine Aufgabe abfeuern und auf die Zusammenfassung warten. PR #85232 ergänzt drei Steuer-Aktionen direkt im selben Tool, ohne ein neues Tool einzuführen. Das Modell ruft weiterhin delegate_task auf; es bekommt nur drei neue Parameter: action, subagent_id und message.
| Aktion | Parameter | Wirkung |
|---|---|---|
action='list' |
keine | Listet die noch laufenden Subagents auf, die von diesem Gespräch gestartet wurden |
action='steer' |
subagent_id + message |
Stellt eine Kurskorrektur bei einem laufenden Subagent in die Warteschlange, ohne ihn zu stoppen |
action='stop' |
subagent_id |
Unterbricht einen Subagent vorzeitig; sein Teilergebnis kommt weiterhin normal zurück |
weggelassen oder action='spawn' |
goal/tasks usw. |
Der ursprüngliche Spawn-Modus – Verhalten unverändert |
Die drei Steuer-Aktionen laufen synchron – sie wandern nie in die Background-Dispatch-Warteschlange und kehren sofort zurück. Sie bekommen die Antwort „was läuft gerade?“ also unmittelbar im Gespräch.
So verwenden Sie es: eine komplette Übung in discover → steer → stop
Angenommen, Sie haben gerade drei Subagents losgeschickt und möchten nach ihnen sehen:
{
"tool": "delegate_task",
"action": "list"
}
Jeder Eintrag der zurückgegebenen Liste enthält subagent_id, parent_id, depth, goal, model, started_at und accepting_steer – am goal-Feld erkennen Sie auf einen Blick, welcher noch „gegen die alte API schreibt“.
Sobald Sie den Ausreißer gefunden haben, spielen Sie eine Korrektur ein:
{
"tool": "delegate_task",
"action": "steer",
"subagent_id": "sa-7f3k9",
"message": "Heads up: the backend API signature changed. Use the new /v2/users endpoint — the field is userId, not id."
}
steer funktioniert so, dass der Text in die ausstehende Eingabe des Ziel-Subagents eingereiht und am nächsten tool boundary des Kindes zugestellt wird – der Subagent wird also nicht aus dem gerissen, was er gerade tut; die Korrektur landet an einem sicheren Punkt. Und falls der Subagent fertig wird, bevor er den steer überhaupt verarbeitet, verschwindet die Anweisung nicht im Nichts: Sie taucht als missed_steer-Feld im Abschluss-Eintrag des Subagents auf – so wissen Sie, dass die Kurskorrektur nie angekommen ist.
Wenn dieser Subagent wirklich nicht mehr zu retten ist, beenden Sie ihn:
{
"tool": "delegate_task",
"action": "stop",
"subagent_id": "sa-7f3k9"
}
stop nutzt die Interrupt-Mechanik: Der Subagent hält an seiner nächsten Iterationsgrenze an, und jedes Teilergebnis, das er produziert hat, kommt als normale Abschlussmeldung zurück – keine verschwendete Arbeit, kein hängender Zustand. Sie können die Teilergebnisse übernehmen und einen frischen Subagent losschicken, der den Rest erledigt.
Grenzen und Sicherheit: Sie können nur Ihren eigenen Baum kontrollieren
Die Kontrolloberfläche bringt einige bewusst gestaltete Grenzen mit – wer sie kennt, wird nicht überrascht:
- Ownership-Kette: Ein Gespräch kann nur Subagents kontrollieren, die es selbst gestartet hat. Hermes setzt das über eine
_delegate_parent_ref-Weakref-Kette mit Identitätsprüfungen durch – von Ihrem Gespräch aus können Sie die Kinder eines anderen Gesprächs nicht persteerbeeinflussen. Das ist dieselbe Garantie, die verhindert, dass sich mehrere Hermes-Sitzungen gegenseitig auf die Füße treten. - Steuer-Aktionen verbrauchen kein Spawn-Budget: Es gibt ein Limit dafür, wie viele Subagents Sie pro Turn spawnen können – aber
list/steer/stopsind ausgenommen, und das mit Absicht. Genau dann, wenn das Limit erreicht ist, zählt „den Ausreißer dringend stoppen“ am meisten, deshalb bleibtstopnutzbar. - Subagents können standardmäßig keine Subagents spawnen: Ein Kind mit
role='leaf'bekommt dasdelegate_task-Tool nie; nur ein explizitesrole='orchestrator'behält das Dispatch-Toolset (begrenzt durchdelegation.max_spawn_depth). Die Kontrolle liegt immer auf der Seite des Gesprächs auf oberster Ebene. - Timing der steer-Zustellung:
steerist „eingereihte Injektion“, keine „sofortige Unterbrechung“. Hängt der Subagent in einem einzigen sehr langen Tool-Call fest, landet die Korrektur erst am nächsten tool boundary – für die meisten Fälle reicht das, aber in Situationen, in denen es „sofort stoppen“ heißen muss, iststopdas richtige Werkzeug.
Wann sich Live-Orchestrierung auszahlt
Der eigentliche Wert liegt darin, die „menschliche Prüfung“ von nachträglich auf mitten im Lauf zu verlagern:
- Frühe Kurskorrektur bei langen Aufgaben: Wer Zehntausende Zeilen umschreibt, für den ist es teuer, erst nach 10 Minuten zu merken, dass die Richtung falsch war. Ein
list+steerzwischendurch kann Stunden sparen. - Chirurgisches Eingreifen in parallelen Batches: Wenn von drei Subagents nur einer abgedriftet ist, trifft
steeroderstopnur diesen einen, während die anderen beiden weiterlaufen – statt den ganzen Batch neu zu starten. - Zusammenarbeit mit Kanban- und Review-Workflows: Wenn Sie Subagent-Aufgaben auf einem Board verwalten (siehe unsere Anleitung zum Kanban-Review-Lifecycle), schließt die Kontrolloberfläche die Lücke „Wie greife ich mitten in der Aufgabe ein?“, die das Board allein nicht schließen konnte.
Über delegate_task haben wir schon einmal berichtet – der Merge-Reconciler, ein neutraler Schlichter für Code-Merges zeigte das Muster „dispatch und auf Ergebnisse warten“. Diese Kontrollfläche entwickelt delegate_task von fire-and-forget zu conduct-while-running weiter. Subagents sind seit v0.20.0 das Herzstück der Multi-Agent-Workflows von Hermes (siehe die Release-Notes zu v0.20.0 Herald) – und jetzt haben sie endlich ein Live-Lenkrad.
Ein Satz zum Merken: list lässt Sie sehen, steer lässt Sie sprechen, stop lässt Sie bremsen – alle drei, ohne die Subagents zu unterbrechen, die gerade gut unterwegs sind. Wenn ein Subagent beim nächsten Mal abdrifftet, müssen Sie nicht den Tisch umwerfen und von vorn anfangen.