Ist dir aufgefallen, dass Hermes, wenn du ihm etwas wirklich Komplexes aufträgst – „Dieses Modul refactoren und Tests hinzufügen“ – in der Session eine todo-Liste führt, Einträge nach und nach abhakt und sich auch nach einer Kontext-Kompression noch merkt, wo es stand? Diese Liste hatte früher eine harte Obergrenze: sie war flach. Jede Aufgabe stand in einer einzigen Spalte, und die Reihenfolge bedeutete Priorität. „Erst A machen, und innerhalb von A gibt es dann die Schritte 1, 2, 3“ auszudrücken, erforderte umständliche Prosa, war für den Agenten schwerer zu lesen und für dich schwerer zu überblicken. PR #97921 (am 29. August gemerged) beseitigt diese Obergrenze: todo-Einträge können jetzt verschachtelt werden – Subtasks hängen über ein optionales parent-Feld an einem Parent, und jede Oberfläche rendert den Baum mit Einrückung.

Was das todo-Tool ist

Zuerst der Hintergrund. todo ist ein eingebautes Hermes-Tool: Der Agent verwendet es automatisch, um eine Tracking-Liste aufzubauen – für komplexe Aufgaben (die offiziellen Tool-Dokumente empfehlen 3+ Schritte) oder wenn du ihm mehrere Dinge auf einmal gibst. Sein Design ist bewusst zurückhaltend:

• Ein einziges todo-Tool – todos-Parameter übergeben zum Schreiben, weglassen zum Lesen der aktuellen Liste;
• Jeder Aufruf gibt die vollständige aktuelle Liste zurück, sodass der Agent immer weiß, wo er steht;
• Nur vier Status: pending, in_progress, completed, cancelled;
• Nach der Kontext-Kompression wird die Liste mit einem stabilen Header wieder eingespielt („[Your active task list was preserved across context compression]“), damit lange Aufgaben nichts vergessen.

Der Agent pflegt die Liste selbst – du musst dir keinen Command merken. Bitte ihn in deinem Prompt einfach darum, „erst einen Plan zu machen“ oder „das in eine Aufgabenliste zu zerlegen“, und er übernimmt von dort.

Wie Subtasks aussehen

Die Änderung ist eine einzige: Jeder todo-Eintrag bekommt ein optionales parent-Feld, das auf die id eines anderen Eintrags zeigt.

1. Refactor parser module         (id: t1)
   ├─ Split parse_line function   (id: t2, parent: t1)
   └─ Add unit tests              (id: t3, parent: t1)
2. Update docs                    (id: t4)

Die Wirkung: jede Oberfläche – CLI-Text, das Aufgaben-Panel der Desktop-App, der ACP-Adapter – rendert Teilbäume eingerückt. Die offizielle Tool-Referenz formuliert es schlicht: Das optionale parent-Feld eines Eintrags zeigt auf die id eines anderen Eintrags und macht ihn damit zum Subtask; Oberflächen rendern den Baum eingerückt.

Die Implementierung schützt außerdem davor, dass sich der Agent in Widersprüche verstrickt:

• Selbstreferenzen werden verworfen – ein parent, der auf sich selbst zeigt, wird ignoriert;
• Verwaiste und zyklische Referenzen werden bereinigt – ein parent, der nicht existiert, oder eine A→B→A-Schleife wird nach dem Schreiben aufgeräumt;
• Ein abgeschlossener Parent bleibt sichtbar, solange ein Nachkomme aktiv ist – nach dem Wiedereinspielen nach der Kompression wird ein Parent, dessen Kinder noch laufen, nicht ausgeblendet;
• Umordnen überspringt verschachtelte Listen – das Verschieben einer flachen Position würde einen Subtask von seinen Geschwistern losreißen, also bleibt der Baum intakt;
• Der ACP-Adapter rückt maximal 4 Ebenen ein – damit der Baum nie unlesbar wird.

Auch die Kostenkontrolle ist erwähnenswert: das gesamte Feature ergänzt eine String-Property und einen Verhaltenssatz im gecachten Tool-Schema – rund 45 Tokens. Kein neues Tool, keine neuen Parameter außer parent, keine Änderungen am System-Prompt.

So verwendest du es: Alltagssprache reicht

Du fasst nie JSON an – todo ist das Tool des Agenten, und du musst nur die Absicht „ich will Ebenen“ ausdrücken:

"Break this release down into a task list: code freeze first, then tests, build, and packaging as subtasks under it"

Den Rest erledigt der Agent und erzeugt eine verschachtelte Liste mit parent-Verknüpfungen; du kannst jederzeit fragen „Wo stehen wir gerade?“, und er liest die Liste, um es dir zu sagen. Für Strukturen, die von Natur aus parallel laufen – etwa eine „Recherchephase“ mit „Option A vergleichen“ und „Option B vergleichen“ darunter – liest sich die Verschachtelung deutlich klarer als eine flache Liste.

Wann es am meisten hilft

• Mehrstufige Aufgaben: Releases, Migrationen, Refactorings – von Natur aus hierarchisch („große Phase → kleine Schritte“), und die Verschachtelung macht den Fortschritt auf einen Blick sichtbar.
• Lange Sessions: Nach der Kompression wird der Baum intakt wieder eingespielt, sodass der Agent Subtasks nie mit Parents verwechselt.
• Mehrere Oberflächen: Das Aufgaben-Panel der Desktop-App rendert einen echten Baum, und auch Gateway-Nachrichten zeigen die eingerückte Struktur.

Diese Änderung landete am 29. August (PR #97921) und ist derzeit nur auf main – noch kein Release-Tag enthält sie (v0.20.6 wurde am 27. August getaggt). Um sie jetzt auszuprobieren, führe hermes update auf den aktuellsten Code aus.

Zusammenfassung

Der Weg von einer flachen Liste zu einem verschachtelbaren Aufgabenbaum ist nur ein kleines Feld, aber er verbessert die Erfahrung bei langen Aufgaben spürbar: Die Struktur stimmt, das Fortschritts-Tracking des Agenten und dein Überblick werden beide einfacher – und das alles für 45 Tokens. Wenn du Hermes das nächste Mal etwas Komplexes übergibst, sag ihm, es soll „die Aufgabe in eine Liste mit Subtasks zerlegen“ – und beobachte den Unterschied.

Weitere Mechaniken für lange Aufgaben (Turn-Limits, Run-Budgets, Unterbrechen ohne Stoppen) findest du in unserem Unlimited-Turns-Guide und im Context-Token-Optimierungs-Guide.