Wie unterscheidet sich dies von der Zieldekomposition?

Die Dekomposition erzeugt die Aufgaben; die Priorisierung entscheidet über die Reihenfolge, in der die resultierenden Aufgaben ausgeführt werden. Sie ergänzen sich gegenseitig: Die Dekomposition füllt das Backlog, die Priorisierung baut es sinnvoll ab.

Sollte das LLM selbst die Prioritäten bewerten?

Es kann Signale wie den geschätzten Impact vorschlagen, aber kombinieren Sie diese mit einer transparenten, überprüfbaren Funktion. Eine deterministische Formel über benannte Signale ist einfacher zu kalibrieren, zu protokollieren und vertrauenswürdiger als ein einzelner, undurchsichtiger Ranking-Aufruf.

Wie verhindere ich, dass Aufgaben mit niedriger Priorität niemals ausgeführt werden?

Nutzen Sie Aging, um die Priorität von lange wartenden Aufgaben schrittweise zu erhöhen, oder reservieren Sie einen Teil der Kapazität für niedrigere Stufen, und überwachen Sie die Tail-Wartezeit, um sicherzustellen, dass nichts verhungert.

OrchestrierungAktualisiert 2026-06-24 · Version 1.1

Aufgabenpriorisierung

Ordnen Sie die potenziellen Aufgaben eines Agenten nach Wert, Dringlichkeit, Abhängigkeiten und Kosten, anstatt sie nach dem First-In-First-Out-Prinzip zu verarbeiten. Eine Scoring-Funktion und eine Priority Queue entscheiden, was als Nächstes ausgeführt wird, sodass begrenzte Rechenleistung, Budget und Zeit in die wichtigste Arbeit fließen. Berechnen Sie Scores bei Zustandsänderungen neu und begrenzen Sie die Queue, damit sie nicht unendlich wächst.

Evidenz: ProduktionKonfidenz: NiedrigQuelle: ProduktionssystemQuelle: Persönliche ErfahrungQuelle: Branchenbeobachtung

Maschinenlesbar: JSON

Problem

Ein Agent, der ein Ziel zerlegt, steht oft vor vielen potenziellen Aufgaben gleichzeitig: Suchen ausführen, Dateien lesen, Tools aufrufen, Unterziele verfolgen. Die Verarbeitung in der Reihenfolge des Eintreffens behandelt einen trivialen Bereinigungsschritt gleichwertig mit einer blockierenden, termingebundenen Aufgabe. Wichtige Arbeit wartet hinter unwichtigem Rauschen, Abhängigkeiten werden verletzt und Budget wird für Aufgaben ausgegeben, die nach einer Lageänderung keine Rolle mehr spielen.

Wann zu verwenden

Verwenden Sie dieses Muster, wenn ein Agent oder Orchestrator ein Backlog unabhängiger oder lose gekoppelter Aufgaben verwaltet und diese aufgrund von Einschränkungen bei Rechenleistung, Rate-Limits, Kosten oder realer Zeit nicht alle sofort ausführen kann. Es eignet sich für Planer- und Supervisor-Architekturen, bei denen eine Komponente entscheidet, was als Nächstes ausgeführt wird. Es setzt voraus, dass Sie jeder Aufgabe Signale – Auswirkung, Deadline, Abhängigkeit, Kosten – zuweisen können und dass sich Prioritäten verschieben können, wenn neue Beobachtungen eintreffen.

Lösung

Weisen Sie jeder Aufgabe explizite Signale zu: erwartete Auswirkung auf das Ziel, Dringlichkeit oder Deadline, Abhängigkeitsbeziehungen (was zuerst abgeschlossen sein muss) und geschätzte Kosten in Token, Geld oder Latenz. Kombinieren Sie diese mithilfe einer transparenten, überprüfbaren Funktion zu einem einzigen Score, statt sich auf ein undurchsichtiges Modellurteil zu verlassen. Leiten Sie bewertete Aufgaben in eine Priority Queue, sodass die bereitstehende Aufgabe mit dem höchsten Wert als Nächstes ausgeführt wird. Berücksichtigen Sie Abhängigkeiten immer zuerst: Eine Aufgabe, deren Voraussetzungen nicht erfüllt sind, ist unabhängig von ihrem Score nicht „bereit“, was die korrekte Reihenfolge wahrt und unnötige Fehlversuche verhindert.

Gestalten Sie die Priorisierung dynamisch. Berechnen Sie nach jedem Schritt die Scores betroffener Aufgaben neu, da neue Ergebnisse die Auswirkung verändern, Deadlines näher rücken und manche Aufgaben obsolet werden und verworfen werden können. Schützen Sie sich vor Starvation durch Aging – indem Sie die Priorität lange wartender Aufgaben schrittweise erhöhen – oder durch die Reservierung von Kapazitäten für niedrigere Stufen. Begrenzen Sie das Backlog mit einem expliziten Limit und einer Admission Policy: Wenn die Queue voll ist, weisen Sie die schwächsten Aufgaben ab, führen Sie sie zusammen oder verwerfen Sie sie, anstatt die Queue unbegrenzt wachsen zu lassen. Halten Sie die Scoring-Gewichtungen konfigurierbar und protokollieren Sie, warum jede Aufgabe ausgewählt wurde, damit das Verhalten nachvollziehbar bleibt.

Komponenten

Signal-ExtraktorScoring-FunktionPriority QueueAbhängigkeits-ResolverRepriorisierungs-LoopAdmission- und Aging-Controller

Vorteile

Begrenzte Rechenleistung, Budget und Zeit fließen in wertvolle, zeitkritische Arbeit statt in das, was zuerst eingetroffen ist.
Die Berücksichtigung von Voraussetzungen vermeidet unnötige Fehlversuche und Nacharbeiten, die entstehen, wenn Aufgaben ausgeführt werden, bevor ihre Inputs vorliegen.
Die Neuberechnung der Scores ermöglicht es dem Agenten, inzwischen irrelevante Aufgaben zu verwerfen und neu dringliche Aufgaben vorzuziehen, wenn sich die Situation weiterentwickelt.
Kostenbewusstes Scoring und eine begrenzte Queue halten Token- und Latenz-Budgets unter Kontrolle, statt sie ausufern zu lassen.

Risiken

Eine falsche Gewichtung oder eine schlechte Kostenschätzung kann systematisch wichtige Arbeit blockieren (Starvation) oder unwichtigen Aufgaben hinterherjagen; die Formel erfordert Überprüfung und Kalibrierung.
Ohne Aging oder reservierte Kapazitäten werden Aufgaben mit niedriger Priorität möglicherweise nie ausgeführt, wodurch notwendige Bereinigungen oder Hintergrundarbeiten dauerhaft unerledigt bleiben.
Zu häufiges Repriorisieren kann dazu führen, dass der Agent ständig den Fokus wechselt, Latenz durch Kontextwechsel verursacht und nie etwas zu Ende bringt.
Wenn die Zerlegung schneller neue Aufgaben hinzufügt, als diese abgeschlossen werden, bläht ein unbegrenztes Backlog den Speicherbedarf, die Kosten und die Planungslatenz auf.

Wann nicht zu verwenden

Wenn es nur eine Handvoll ähnlicher Aufgaben gibt, ist FIFO oder einfache Parallelisierung unkomplizierter und der Scoring-Overhead lohnt sich nicht.
Wenn Aufgaben in einer festen, durch die Domäne vorgegebenen Reihenfolge ausgeführt werden müssen, ist ein statischer Workflow oder ein DAG klarer als eine dynamische Priority Queue.
Wenn Sie alles sofort innerhalb des Budgets und der Limits ausführen können, gibt es nichts zu priorisieren, und eine Sortierung bringt nur unnötige Komplexität.

Technologien

Task queuesPlanner agentsScheduling / priority queuesCost-aware routing

Beispiele

Ein Agent, der Beweise sammelt, priorisiert die Suchen, die am wahrscheinlichsten offene Fragen klären, und überspringt redundante Abfragen, sobald eine Behauptung bestätigt ist.
Ein Operations-Agent ordnet Behebungsschritte nach Schadensradius und Deadline und behebt den kundenwirksamen Ausfall vor Warnungen mit geringer Auswirkung.
Ein Pipeline-Agent plant wertvolle oder zeitkritische Dokumente zuerst ein und stellt günstige Massenaufgaben zurück, während Aging verhindert, dass die Massen-Queue dauerhaft blockiert.

Praxisbelege

Kontext: Single-Operator, Local-First OpenClaw-Bereitstellung, beobachtet über 57 Tage (161 Sessions / 2.776 Turns), aggregiert aus den eigenen Trajektorien-Traces des Agenten.
Szenario: Ein autonomer Agent wird nach einem Zeitplan geweckt (Heartbeat + Cron), wobei ein Staggering zu Beginn jeder Stunde und ein Heartbeat-Cooldown für Backpressure sorgen, damit sich Jobs nicht anhäufen.
Technologie: CronService-Scheduler, Heartbeat-Runner, ein 5-minütiges Staggering zu Beginn jeder Stunde, Heartbeat-Cooldown-Verzögerungslogik und ein Feld für niedrige/normale/hohe Priorität bei Heartbeat-Ergebnissen.
Last: 2.801 Heartbeat-Turns + 57 Cron-Turns + 106 User-Turns über 57 Tage (Heartbeat ~94 % der Trigger).
Ergebnisse: Der Scheduler hielt täglich etwa fünfzig autonome Aktivierungen aufrecht, wobei Staggering und Cooldown ein Anhäufen von Jobs verhinderten; es trat kein zeitplangesteuerter Fehler auf. Single-Operator, Local-First-Bereitstellung.

KPIs

Gewichteter Wert abgeschlossener Aufgaben pro Kosteneinheit: Erfasst, ob der Aufwand in hochwirksame Arbeit fließt; ein gutes Ergebnis zeigt sich in mehr zielrelevantem Wert pro Token oder Dollar im Vergleich zu einer FIFO-Baseline.
Einhaltung von Deadlines / SLAs bei zeitkritischen Aufgaben: Zeigt, ob Dringlichkeitssignale funktionieren; ein gutes Ergebnis bedeutet, dass dringende Aufgaben meist vor ihrer Deadline abgeschlossen werden.
Starvation-Indikator (maximale und Tail-Wartezeit für Aufgaben mit niedriger Priorität): Zeigt, ob Aging effektiv ist; ein gutes Ergebnis sind begrenzte Wartezeiten im Worst Case, ohne dass eine Aufgabe unendlich festsitzt.
Queue-Tiefe im Verhältnis zum Limit und Admission-/Eviction-Rate: Bestätigt, dass das Backlog begrenzt bleibt; ein gutes Ergebnis zeigt sich in einer Tiefe unter dem Limit, wobei das Verwerfen (Eviction) wirklich geringwertigen Aufgaben vorbehalten bleibt.

Beobachtete Fehlermuster

Eine hochpriorisierte Aufgabe wartet auf eine Voraussetzung mit niedriger Priorität, die nie eingeplant wird; der Resolver muss die Dringlichkeit auf Blockierer übertragen.
Einmalig berechnete und nie aktualisierte Prioritäten führen zu Entscheidungen auf Basis veralteter Auswirkungs- oder Deadline-Informationen; daher muss eine Neuberechnung bei relevanten Zustandsänderungen getriggert werden.
Eine Unterschätzung der Kosten einer Aufgabe führt dazu, dass sie das Budget monopolisiert; Schätzungen benötigen Feedback aus dem tatsächlich gemessenen Verbrauch.
Eine aggressive Admission Policy verwirft eine Aufgabe, die sich später als notwendig herausstellt, was eine teure erneute Ermittlung erzwingt; das Verwerfen (Eviction) sollte wirklich redundante Elemente bevorzugen.

Lessons Learned

Eine überprüfbare, konfigurierbare Formel ist einfacher zu debuggen und abzustimmen als ein undurchsichtiges Modellurteil darüber, was als Nächstes zu tun ist.
Behandeln Sie den Abschluss von Voraussetzungen als separate Bereitschaftsprüfung, damit ein hoher Score eine Aufgabe niemals vor ihre Inputs springen lässt.
Fügen Sie von Anfang an Aging oder reservierte Kapazitäten hinzu; Hintergrundarbeit mit niedriger Priorität, die nie ausgeführt wird, führt zu einer unbemerkten Korrektheitslücke.
Eine harte Obergrenze mit einer klaren Zulassungsrichtlinie ist der einfachste Schutz gegen eine ausufernde Dekomposition, die Kosten und Latenz in die Höhe treibt.

FAQs

Wie unterscheidet sich dies von der Zieldekomposition?: Die Dekomposition erzeugt die Aufgaben; die Priorisierung entscheidet über die Reihenfolge, in der die resultierenden Aufgaben ausgeführt werden. Sie ergänzen sich gegenseitig: Die Dekomposition füllt das Backlog, die Priorisierung baut es sinnvoll ab.
Sollte das LLM selbst die Prioritäten bewerten?: Es kann Signale wie den geschätzten Impact vorschlagen, aber kombinieren Sie diese mit einer transparenten, überprüfbaren Funktion. Eine deterministische Formel über benannte Signale ist einfacher zu kalibrieren, zu protokollieren und vertrauenswürdiger als ein einzelner, undurchsichtiger Ranking-Aufruf.
Wie verhindere ich, dass Aufgaben mit niedriger Priorität niemals ausgeführt werden?: Nutzen Sie Aging, um die Priorität von lange wartenden Aufgaben schrittweise zu erhöhen, oder reservieren Sie einen Teil der Kapazität für niedrigere Stufen, und überwachen Sie die Tail-Wartezeit, um sicherzustellen, dass nichts verhungert.