DynaFlow lässt KI-Agenten ihre Zusammenarbeit selbst planen

Programme legen Rollen, Reihenfolge und Informationsfluss fest

Das Hauptmodell hat drei grundlegende Möglichkeiten: direkt antworten, ein gewöhnliches Werkzeug aufrufen oder ein Workflow-Programm generieren und ausführen lassen. In der beschriebenen Implementierung ist dieses Programm in JavaScript formuliert. Es legt fest, welche Sub-Agenten welche Teilaufgaben bearbeiten, welche Aufrufe parallel laufen dürfen und welche Schritte voneinander abhängen. [3]

Bei unabhängigen Teilaufgaben kann das Programm mehrere Agenten parallel starten. Wenn ein späterer Schritt ein früheres Ergebnis benötigt, muss dieses Ergebnis gezielt weitergereicht werden. Die Sub-Agenten erhalten dabei nur die Anweisungen und Eingaben, die das Workflow-Programm ihnen zuweist. So werden neben der Reihenfolge auch die Abhängigkeiten zwischen Zwischenergebnissen Teil der Orchestrierungslogik. [3]

Die Ausführungsumgebung gibt dem Hauptmodell sowohl Ergebnisse als auch einen Ablauf-Trace zurück. Dieser protokolliert laut Arbeit den Status und die Ausgaben einzelner Agentenaufrufe. Das Hauptmodell ergänzt diese Beobachtungen zu seinem bisherigen Verlauf und kann dann entscheiden, ob es eine Antwort formuliert, ein Werkzeug nutzt oder einen weiteren Workflow anstößt. Die Autoren beschreiben die Laufzeit als ressourcenbeschränkt, nennen im verfügbaren Ergebnisauszug aber keine quantitativen Grenzwerte. [3]

Nach einem Workflow ist die Rolle des Hauptmodells begrenzt: In den workflowbasierten Testmodi koordiniert es, bewertet die Rückmeldungen und fasst sie zu einer Antwort zusammen. Die eigentliche fachliche Problemlösung und die vorgesehene Verifikation sollen die Sub-Agenten übernehmen. Das unterscheidet den Ansatz von einem System, in dem das Hauptmodell sämtliche Arbeit erledigt und weitere Modelle lediglich unverbindlich konsultiert. [3]

Trainiert wird die Steuerung, nicht die Agentenflotte

DynaFlow wird in zwei überwachten Trainingsstufen entwickelt. In der ersten Stufe erzeugt ein Lehrmodell Beispiele für vollständige Bearbeitungsverläufe. Für das Training des Hauptmodells werden Beispiele übernommen, deren Endantwort korrekt ist und die das vorgesehene Delegationsprotokoll einhalten. Die überwachten Ziele enthalten sowohl die erste Begründung des Hauptmodells als auch dessen ersten Workflow-Aufruf. [3]

Als Lehrmodell nennen die Autoren GLM-5.3 Max. Für Stufe eins berichten sie von 2.031 distillierten Beispielen, mit denen das Hauptmodell mittels QLoRA feinjustiert wurde. In der zweiten Stufe wurde das Training mit einer kleineren, kuratierten Auswahl von 712 Beispielen fortgesetzt. Die Sub-Agenten blieben dabei unverändert; trainiert wurde ausschließlich das Hauptmodell. [3]

Die Auswahl für Stufe zwei sollte nicht nur richtige Endantworten belohnen. Ein Sprachmodell-Richter prüfte Workflows auf drei Arten von Mängeln: unbelegte Prämissen, voreingenommene Verifikationsschritte und Fehler im Informationsfluss. Dazu zählt die Arbeit etwa fehlenden Kontext, falsche Verweise oder den Ersatz eines benötigten Zwischenergebnisses durch einen fest einprogrammierten Wert. Beanstandungen sollten durch konkrete Stellen im Programm oder in dessen Argumenten gestützt sein. [3]

Dieser Trainingsaufbau trennt die Fähigkeit, Aufgaben zu lösen, von der Fähigkeit, vorhandene Fähigkeiten zu koordinieren. Für Unternehmen ist das als Forschungsrichtung relevant, weil es prinzipiell ermöglicht, einen Orchestrator mit unterschiedlichen, bereits verfügbaren Agenten zu kombinieren. Die publizierte Evaluation testet diese Übertragbarkeit jedoch nicht: Hauptmodell und Sub-Agenten verwenden dort dieselbe Modellfamilie, und die Sub-Agenten bleiben auf dem Qwen3.5-27B-Basismodell. [3]

88,08 Prozent im erzwungenen Modus

Die Autoren evaluieren DynaFlow auf 688 Aufgaben aus sechs Benchmarks: AIME 2024, AIME 2025, AIME 2026, PolyMATH, GPQA-Diamond und HotpotQA. Die Sets decken mathematische Wettbewerbsaufgaben, mehrsprachiges mathematisches Schlussfolgern, wissenschaftliche Fragen und mehrstufige Informationssuche ab. HotpotQA wird für die Recherche mit Websuche bearbeitet. [3]

Verglichen werden drei Betriebsmodi. Im Direct-Modus antwortet das Hauptmodell ohne Werkzeuge oder Workflows. Im Dynamic-Modus entscheidet es zunächst zwischen direkter Antwort und Workflow. Im Forced-Modus muss es vor der inhaltlichen Problemlösung einen Workflow aufrufen. Die Auswertung zählt Läufe ohne gültige Endantwort als falsch; die Gesamtgenauigkeit ist ein über alle 688 Aufgaben gebildeter mikroaggregierter Wert. [3]

Im Forced-Modus erreicht DynaFlow laut Tabelle 88,08 Prozent Genauigkeit. Der stärkste dort aufgeführte Einzelmodell-Baselinewert stammt von Self-Refine mit 77,18 Prozent. Der Abstand beträgt 10,90 Prozentpunkte; beide Ansätze verwenden den Qwen3.5-27B-Backbone. Gegenüber dem nicht trainierten Hauptmodell im Forced-Modus steigt die Genauigkeit von 75,87 auf 88,08 Prozent. [3]

Im Dynamic-Modus berichten die Autoren 87,94 Prozent Gesamtgenauigkeit. Bei 47,1 Prozent der Fragen wurde kein Workflow aufgerufen. Im Vergleich dazu erreicht der trainierte Direct-Modus 77,18 Prozent. Das Ergebnis spricht in der untersuchten Aufgabenmischung dafür, dass die Möglichkeit, je nach Bedarf zu delegieren, mit hoher Genauigkeit vereinbar sein kann. Es zeigt aber nicht, dass ein solches Routing in beliebigen Unternehmensaufgaben ebenso zuverlässig entscheidet, wann zusätzliche Agenten nötig sind. [3]

Die Einzelwerte fallen je nach Benchmark unterschiedlich aus. Im Forced-Modus nennt die Ergebnistabelle beispielsweise 100 Prozent für alle drei AIME-Sets, 90,50 Prozent für PolyMATH, 84,85 Prozent für GPQA-Diamond und 83,50 Prozent für HotpotQA. Diese Werte stammen aus den jeweiligen Testmengen und sind nicht als allgemeine Erfolgswahrscheinlichkeit für mathematische, wissenschaftliche oder Rechercheaufgaben zu lesen. [3]

Ein Vergleichsvorteil mit Einschränkungen

Die Untersuchung legt einen wichtigen Kontrollbefund vor: Ein Workflow verbessert die Ergebnisse nicht automatisch. Beim nicht trainierten Hauptmodell sinkt die Genauigkeit im Forced-Modus gegenüber dem direkten Antworten in fünf der sechs Benchmarks; nur bei HotpotQA fällt der Vergleich positiv aus. Nach dem Training liegt der Forced-Modus laut Ergebnistabelle dagegen in allen sechs Kategorien mindestens auf dem Niveau des nicht trainierten Direct-Modus. Das stützt die These der Autoren, dass die Qualität der Koordination selbst gelernt werden muss. [3]

Der HotpotQA-Wert verlangt besondere Vorsicht. Die Projektseite weist darauf hin, dass nur die Websuch- und Workflow-Konfigurationen über Retrieval verfügen; einfache Baselines ohne Recherchewerkzeug seien dort deshalb nicht unmittelbar vergleichbar. Für diesen Benchmark ist ein Teil des gemessenen Unterschieds folglich nicht allein der Orchestrierung zuzuschreiben, sondern auch den verfügbaren Recherchefunktionen. [5]

Auch die Ergebnisse insgesamt sind an eine konkrete Versuchsplattform gebunden: Qwen3.5-27B als Hauptmodell, festgehaltene Sub-Agenten und eine gemeinsame Laufzeit für die Workflow-Vergleiche. Die Arbeit misst in ihrer Haupttabelle Genauigkeit. Daraus lässt sich weder ableiten, wie stark zusätzliche Agenten die Antwortlatenz erhöhen, noch welcher Token- oder Infrastrukturaufwand pro korrekt gelöster Aufgabe entsteht. Für eine betriebliche Bewertung wären diese Größen neben der Qualität entscheidend. [3]

Die Analyse rückt den Informationsfluss in den Mittelpunkt

Die Autoren untersuchen nicht nur Endantworten, sondern auch Eigenschaften der erzeugten Workflows. Nach der Darstellung auf der Projektseite steigt der Anteil hybrider Abläufe mit parallelen und anschließenden sequenziellen Schritten von 3,4 Prozent vor dem Training auf 85,6 Prozent danach. In 97,7 Prozent der untersuchten trainierten Abläufe wurden vorgelagerte Ergebnisse ausdrücklich weiterverwendet. Diese Angaben stammen aus der Analyse der Projektgruppe und sind keine unabhängige Bewertung. [5]

Die Beispiele auf der Projektseite zeigen, wie sich das praktisch auswirken kann: Mehrere parallele Rechnungen können in einem weiteren Schritt von einem Prüfer verglichen werden; bei einer mehrstufigen Recherche können identifizierte Personen oder Quellen an nachfolgende Suchschritte übergeben werden. Die Beispiele illustrieren den Mechanismus, ersetzen aber keinen systematischen Nachweis, dass jede zusätzliche Prüfschleife die Fehlerquote senkt. [5]

Für den Unternehmenseinsatz ist damit nicht die bloße Zahl der Agenten der zentrale Punkt. Entscheidend ist, ob ein System Zwischenergebnisse korrekt übergibt, ihre Herkunft nachvollziehbar hält und Prüfungen tatsächlich unabhängig ausführt. DynaFlow macht diese Eigenschaften durch ausführbare Programme und Ablaufspuren zumindest teilweise sichtbar. Die veröffentlichte Genauigkeit allein belegt jedoch nicht, dass die dabei erzeugten Informationen in sensiblen Prozessen ausreichend abgesichert oder auditierbar sind. [3][5]

Code verfügbar, aber kein Nachweis für Produktreife

Das Projektteam stellt ein GitHub-Repository mit Programmcode und einer Demo bereit. Laut dessen Dokumentation benötigt der Direct-Modus Python 3.11 oder neuer. Für Dynamic und Forced werden zusätzlich Node.js 24 oder neuer, npm und Docker mit Linux-Containern vorausgesetzt. Die Modelle müssen über eine OpenAI-kompatible Streaming-Chat-Completions-API erreichbar sein; für die Workflow-Ausführung müssen sie Tool-Aufrufe unterstützen. Für dynamische oder erzwungene Workflows sind außerdem Zugangsdaten für Websuche und Seitenabruf vorgesehen. [4]

Die Demo greift auf echte APIs zurück. Ein erfolgreicher Lauf bedeutet laut Repository, dass die Fragen mit gültiger Antwortübergabe abgeschlossen wurden; die inhaltliche Korrektheit der Antworten wird dabei nicht bewertet. Die Demo eignet sich deshalb als technischer Einstieg, nicht als Ersatz für eine Reproduktion der Benchmarkresultate oder eine Prüfung im eigenen Anwendungsfall. Das Repository weist den ursprünglichen Code als MIT-lizenziert aus. [4]

Für Entscheider ergibt sich ein begrenzter, aber konkreter Befund: DynaFlow zeigt, dass ein trainiertes Hauptmodell in einer kontrollierten Benchmark-Umgebung Aufgaben auf flexible, programmierte Agentenabläufe verteilen kann. Der deutliche Abstand zu den verglichenen Baselines ist ein Ergebnis dieser Evaluation, kein Beleg für eine allgemeine Überlegenheit oder sofortige Einsatzreife. Vor einer Einführung müssten Unternehmen insbesondere Qualität auf eigenen Daten, Kosten, Latenz, Fehlertoleranz und die Kontrolle von Werkzeug- und Agentenzugriffen separat prüfen. [1][3][4]

Quellen

1. [1] [2610.34467v1] DynaFlow: Learning Free-Form Multi-Agent Orchestration — https://arxiv.org/abs/2610.34467v1 (abgerufen am 2026-10-27)
2. [3] DynaFlow: Learning Free-Form Multi-Agent Orchestration — https://arxiv.org/pdf/2610.34467 (abgerufen am 2026-10-27)
3. [4] GitHub - amiya-special/Dynaflow: DynaFlow: Learning Free-Form Multi-Agent Orchestration · GitHub — https://github.com/amiya-special/Dynaflow (abgerufen am 2026-10-27)
4. [5] DynaFlow · Learning Free-Form Multi-Agent Orchestration — https://amiya-special.github.io/DynaFlow-website (abgerufen am 2026-10-27)