Claude hat begonnen, selbst Programme zur Verwaltung von Agenten zu entwickeln: Anthropic veröffentlicht die neue Generation von Multi-Agent-Orchestrierungsarchitektur

In Multi-Agent-Systemen können Aufgaben auf verschiedene Agents verteilt und parallel erledigt werden. Nach der Aufteilung der Aufgaben bedarf es jedoch nach wie vor eines Orchestrierungsmechanismus, der für die Koordination der Ausführung, die Übermittlung der Ergebnisse und die Entscheidung über den nächsten aufzurufenden Agent zuständig ist.

Anthropic hat kürzlich einen neuen Implementierungsansatz vorgestellt: Claude generiert anhand der Aufgabenanforderungen ein Orchestrierungsprogramm, das für das Starten von Sub-Agents, die Verbindung verschiedener Phasen und die Verarbeitung der zurückgegebenen Ergebnisse zuständig ist, bevor die Ausführungsinformationen an den Haupt-Agent zurückgegeben werden. Ein Teil der Koordinierungsarbeiten, die zuvor eine ständige Beteiligung des Haupt-Agents erforderten, kann so von Hintergrundprogrammen übernommen werden.

Am 9. Oktober hat Anthropic Dynamic Workflows (dynamische Arbeitsabläufe) für Claude Managed Agents veröffentlicht, das sich derzeit in der Betaphase befindet. Am 12. Oktober stellten die Anthropic-Techniker CJ Avilla und Harrison Stall diesen Mechanismus im Workshop der Konferenz AI Engineer New York 2026 näher vor.

Bei der Konferenzpräsentation erläuterte der Anthropic-Ingenieur anhand des Übergangs des Unix- und Linux-Projekts von der individuellen Entwicklung zur groß angelegten Zusammenarbeit, dass mit der Beteiligung immer mehr Agents an der Softwareentwicklung die Aufgabenorganisation und -koordination selbst zu einem Engpass wird. Dynamic Workflows ist der neue Mechanismus, den Anthropic dafür ausprobiert.

1

Den Ausführungsplan für Multi-Agents in ein Programm schreiben

Wenn Entwickler Multi-Agents in realen Projekten einsetzen, stellen sie oft fest, dass die Verteilung der Aufgaben nur der erste Schritt ist. Der aufwendigere Teil besteht darin, den gesamten Prozess zu verbinden. Beispielsweise ist es nicht schwer, den Haupt-Agent gleichzeitig mehrere Sub-Agents zur Informationssuche zu schicken – das Problem ist, dass jedes Ergebnis in den Hauptdialog zurückkehren muss, bevor der Haupt-Agent es einzeln verarbeitet und nachfolgende Aufgaben anordnet. Bei vielen Aufgaben wird der Kontext leicht mit Zwischenergebnissen überfüllt.

Im Modus, in dem der Haupt-Agent Sub-Agents direkt aufruft, ist der Haupt-Agent für die Zuweisung von Aufgaben, das Lesen der zurückgegebenen Ergebnisse und die Entscheidung über das weitere Vorgehen zuständig. Sub-Agents können parallel arbeiten, die nachfolgende Koordination wird jedoch weiterhin vom Haupt-Agent vorangetrieben.

Bei Dynamic Workflows (dynamischen Arbeitsabläufen) wird ein Teil der Koordinierungslogik in das Programm geschrieben. Claude generiert anhand der Aufgabenanforderungen ein Orchestrierungsprogramm, das festlegt, wie Aufgaben aufgeteilt werden, in welche Phasen sie unterteilt sind und wie die Arbeit verschiedener Agents miteinander verbunden wird. Anschließend wird dieses Programm auf dem Server im Hintergrund ausgeführt, es ist für das Starten von Agents, die Übermittlung von Zwischenergebnissen und das Vorantreiben nachfolgender Aufgaben entsprechend dem Ausführungsstand zuständig.

Das hier genannte Orchestrierungsprogramm ist keine Aufgabenliste, die nur für das Modell zum Lesen gedacht ist. Es enthält tatsächliche Ausführungslogiken, beispielsweise das parallele Starten mehrerer Agents, die Verwendung des Ergebnisses der vorherigen Phase als Eingabe für die nächste Phase, die Entscheidung anhand der Prüfergebnisse, ob eine bestimmte Aufgabe neu ausgeführt werden soll, sowie die Wahl zwischen Fortsetzung oder Beendigung bei Ausfall eines Sub-Agents.

Der Unterschied zur herkömmlichen Delegationsweise von Sub-Agents liegt darin, wer die nachfolgenden Ausführungsschritte bestimmt. Bisher musste nach der Rückgabe des Ergebnisses durch einen Sub-Agent oft der Haupt-Agent erneut eine Inferenz durchführen, um die nächste Operation zu bestimmen. Dynamic Workflows erlaubt es hingegen, dass das Orchestrierungsprogramm direkt auf Basis der zurückgegebenen Daten weiterarbeitet. Der Haupt-Agent muss nicht an jeder Aufgabenübergabe teilnehmen, er kann andere Dinge erledigen, während der Hintergrund-Arbeitsablauf läuft, und sich nach Abschluss der Ausführung die Endergebnisse ansehen.

Anthropic hat in der offiziellen Dokumentation zu Multiagent-Orchestrierung auf der Claude-Plattform (https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration) einen speziellen Vergleich zwischen herkömmlichen Subagents und Dynamic Workflows vorgenommen: Bei ersterem entscheidet der Haupt-Agent schrittweise über die nachfolgenden Operationen anhand der zurückgegebenen Ergebnisse der Teilaufgaben; bei letzterem werden Logiken wie Schleifen, bedingte Verzweigungen und Ergebnisübermittlung an das Orchestrierungsprogramm übergeben, Zwischendaten können in Programmvariablen gespeichert werden, ohne dass sie jedes Mal an den Haupt-Agent zur erneuten Verarbeitung zurückgegeben werden müssen.

Vor Ort auf der Konferenz wurde eine Demo mit der Scanaufgabe für eine Aktienbeobachtungsliste durchgeführt: In der ersten Phase werden verschiedene Aktien an Agents mit unabhängigen Kontexten verteilt, in nachfolgenden Phasen werden die Scanergebnisse überprüft und anschließend ein Bericht erstellt. Dieses Beispiel zeigt, wie Arbeitsabläufe verteilte Ausführung, zentralisierte Überprüfung und abschließende Zusammenfassung miteinander verbinden.

Entwickler können nach wie vor die an den Aufgaben beteiligten Agents einschränken. Offiziell werden vordefinierte Agents und temporär definierte Inline-Agents unterstützt: Ersterer nutzt vorher eingestellte Modelle, Prompts und Werkzeuge; Letzterer wird für die aktuelle Aufgabe erstellt und übernimmt die Modell- und zugehörigen Werkzeugkonfigurationen des Haupt-Agents. Entwickler können die temporäre Erstellungsfunktion deaktivieren und nur zulassen, dass der Arbeitsablauf Agents aus einer festgelegten Liste aufruft. Daher können die dynamische Generierung von Ausführungsplänen und die vorkonfigurierten professionellen Agents gleichzeitig existieren. Beispielsweise kann ein Entwickler einen speziell für die Überprüfung zuständigen Agent vorhalten und Claude selbst entscheiden lassen, wann er ihn aufruft.

Dynamische Arbeitsabläufe reduzieren den Aufwand für Entwickler, Aufgabenausführungspfade im Voraus zu entwerfen, heben aber nicht die Einschränkungen von Entwicklern für das Systemverhalten auf. Welche Agents teilnehmen dürfen, welche Werkzeuge sie aufrufen können, wie viele Kosten entstehen dürfen und welches Ergebnis eine Aufgabe als abgeschlossen gilt, müssen weiterhin von Entwicklern über Konfigurationen, Berechtigungsrichtlinien und Geschäftsvalidierungsmechanismen festgelegt werden.

2

1000 Agents sind die kumulative Obergrenze, auch das Budget hat Ausführungsgrenzen

Wie kann übermäßiger Aufruf vermieden werden, wenn eine einfache Aufgabe auch eine große Anzahl von Agents startet? Wie lassen sich die Kosten für Multi-Agents kontrollieren? Das ist ein Thema, das viele Entwickler beschäftigt.

Gemäß der offiziellen Dokumentation von Anthropic kann ein einzelner dynamischer Arbeitsablauf maximal kumulativ 1000 Agents starten, die Obergrenze für gleichzeitig laufende Agent-Threads beträgt jedoch 64, und ein einzelner Arbeitsablauf läuft standardmäßig maximal 24 Stunden. Das bedeutet, dass 1000 die kumulative Anzahl der im gesamten Ausführungszyklus gestarteten Agents ist, es bedeutet nicht, dass Claude gleichzeitig 1000 Agents koordinieren kann, geschweige denn, dass es bereits in der Lage ist, Multi-Agent-Aufgaben in diesem Umfang stabil abzuschließen.

Diese Einschränkungen klären die Ausführungsgrenzen dynamischer Arbeitsabläufe, aber Anthropic hat noch keine allgemeingültige Antwort darauf gegeben, wie viele Agents genau für eine bestimmte Aufgabe gestartet werden sollen. Bei der Frage- und Antwortrunde vor Ort erwähnte Stall, dass derzeit die Anzahl der Agents hauptsächlich durch Bewertungen und niedrige Standardeinstellungen kontrolliert wird; für komplexere Aufgaben ist normalerweise eine klare Anleitung des Modells zur Erhöhung der Parallelität erforderlich. Er fügte hinzu, dass das Modell zur Laufzeit nicht weiß, welches Budget ihm zur Verfügung steht, Entwickler können Sitzungsbudgets festlegen.

Die Kosten müssen ebenfalls konkret betrachtet werden. Bei der Vorführung der Aktienbeobachtungslisten-Scanaufgabe vor Ort erklärte Avilla, dass dynamische Arbeitsabläufe mehr Kosten verursachen als Ein-Agent-Lösungen, aber auch mehr Details entdecken können.

In Bezug auf die Kostenkontrolle bieten Managed Agents einen Sitzungs-basierten Budgetmechanismus an, die Plattform summiert die Kosten anhand des öffentlichen Preises entsprechend dem Verbrauch von Modell-Tokens, Websuche und Sitzungslaufzeit. Nach Erreichen der Budgetobergrenze stoppt das System die Ausgabe neuer Modellanforderungen, die Aufgabe wird angehalten; Entwickler können die Ausführung durch Anpassung des Budgets wieder aufnehmen.

Es handelt sich jedoch nicht um einen harten Schalter, der sofort alle Berechnungen unterbricht. Bereits ausgegebene Modellanforderungen werden abgeschlossen, wenn mehrere Agents parallel laufen, kann der endgültige Verbrauch die Budgetobergrenze überschreiten. Da das Budget zudem nach dem öffentlichen Preis berechnet wird, kann das statistische Ergebnis von dem tatsächlichen Abrechnungsbetrag des Unternehmens abweichen.

Dies erklärt auch, warum "der Haupt-Agent liest weniger Zwischenergebnisse" nicht direkt zu "insgesamt günstiger" führt: Jeder an der Arbeit beteiligte Agent erzeugt Inferenzverbrauch, zusätzliche Überprüfungsvorgänge erfordern ebenfalls Rechenressourcen.

3

Können sich Arbeitsabläufe selbst verbessern?

In der Frage- und Antwortrunde vor Ort (https://www.latent.space/) gab es ein weiteres beachtenswertes Thema: Wenn ein dynamischer Arbeitsablauf wiederholt ausgeführt werden muss, kann er sich dann anhand der vorherigen Ausführungsergebnisse stetig verbessern, sodass Aufgaben schneller und kostengünstiger abgeschlossen werden?

Ein Zuhörer stellte eine Frage am Beispiel der Aktienbeobachtungslisten-Scanaufgabe: Wenn das System feststellt, dass das derzeit verwendete Scanmodell nicht gut funktioniert, kann es dann bei der nächsten geplanten Ausführung das Modell aktiv austauschen oder den ursprünglichen Ausführungsablauf anpassen?

Stall erklärte klar, dass Dynamic Workflows derzeit keine eingebaute Fähigkeit zur Selbstverbesserung hat. Er und Avilla erwähnten jedoch zwei mögliche Verbesserungswege: Hill-Climbing (Bergsteigerverfahren) und die Dreaming-Funktion, an der Anthropic derzeit forscht.

Dreaming kann als Mechanismus zur Gedächtnisorganisation für historische Erfahrungen von Agents verstanden werden. Gemäß der Definition in der offiziellen Dokumentation zu Anthropic Dreams (https://platform.claude.com/docs/en/managed-agents/dreams) liest es vorhandene Gedächtnisbibliotheken und vergangene Sitzungsaufzeichnungen, fasst wiederholte Informationen zusammen, ersetzt veraltete oder widersprüchliche Inhalte und extrahiert neue Erfahrungen aus vergangenen Sitzungen, um letztendlich eine neu organisierte Gedächtnisbibliothek zu generieren.

Dieser Prozess überschreibt die ursprüngliche Gedächtnisbibliothek nicht direkt. Dreaming generiert eine separate neue Gedächtnisbibliothek, Entwickler können deren Inhalt prüfen und dann entscheiden, ob sie sie für nachfolgende Sitzungen verwenden wollen. Derzeit befindet sich diese Funktion noch in der Forschungsvorschauphase, für die Nutzung ist eine Beantragung der Zugriffsberechtigung erforderlich.

Avilla erklärte vor Ort, dass Dreaming Agents dabei helfen kann, Erfahrungen aus früheren Sitzungen weiter zu verfeinern und zu festigen. Für Arbeitsabläufe, die wiederholt ausgeführt werden müssen, bedeutet dies, dass Entwickler die Probleme, die bei vergangenen Ausführungen entdeckt wurden, gesammelten Informationen und effektiven Verarbeitungsweisen zu Gedächtnisinhalten organisieren können, auf die nachfolgende Aufgaben verweisen können. Der Gedächtnismechanismus von Managed Agents (https://platform.claude.com/docs/en/managed-agents/memory) erlaubt es Entwicklern, Gedächtnisbibliotheken an neue Sitzungen anzuhängen, sodass Agents relevante Informationen zwischen verschiedenen Sitzungen fortsetzen können.

Die Organisation von Gedächtnis und die Optimierung von Arbeitsabläufen sind jedoch nach wie vor zwei verschiedene Dinge. Dreaming selbst beurteilt nicht, wie viele Agents gestartet werden sollen und welches Modell verwendet werden soll, und ändert auch nicht automatisch das von Claude generierte Orchestrierungsprogramm. Hill-Climbing bietet hingegen einen anderen Ansatz: Durch wiederholte Bewertung und lokale Anpassungen wird versucht, Konfigurationen oder Ausführungsstrategien mit besserer Wirkung zu finden. Allerdings hat Anthropic bei dieser Vorstellung keine vollständige Implementierung veröffentlicht, die diese Mechanismen in Dynamic Workflows integriert.

Daher kann Claude derzeit zwar dynamisch Multi-Agent-Orchestrierungsprogramme entsprechend den Aufgaben generieren, aber Arbeitsabläufe können noch nicht automatisch einen vollständigen Verbesserungszyklus aus "Ausführen, Bewerten, Ändern, Erneut überprüfen" bilden. Um sie bei wiederholten Aufgaben stetig zu optimieren, müssen Entwickler weiterhin Bewertungsmetriken entwerfen, Ausführungsergebnisse aufzeichnen und entscheiden, wie historische Erfahrungen für die nächste Ausführung verwendet werden.

4

Agents können sich gegenseitig ablösen, aber noch nicht frei in Gruppenchats kommunizieren

In dynamischen Arbeitsabläufen sind die einzelnen Sub-Agents zwar unabhängige Dialogkontexte, aber nicht voneinander isoliert. Gemäß der offiziellen Dokumentation zu Workflow Runs von Anthropic (https://platform.claude.com/docs/en/managed-agents/workflow-runs) können sie sowohl Ergebnisse über das Orchestrierungsprogramm übermitteln als auch Informationen über das gemeinsame Dateisystem in der Sitzungs-Sandbox austauschen.

Konkret gibt es hauptsächlich zwei Arten der Informationsübermittlung. Die erste wird vom Orchestrierungsprogramm übernommen: Nachdem ein Agent eine Aufgabe abgeschlossen und das Ergebnis zurückgegeben hat, kann das Programm die relevanten Inhalte als Eingabe an den nächsten Agent übergeben. Beispielsweise analysiert zuerst ein Agent den Code, bevor das Analyseergebnis an einen anderen Agent zur Überprüfung übergeben wird. Die zweite Art erfolgt über das gemeinsame Dateisystem: Verschiedene Agents können Zwischenergebnisse in Dateien schreiben, die von anderen Agents gelesen und verwendet werden.

Diese Art der Zusammenarbeit unterscheidet sich jedoch von dem direkten Senden von Nachrichten zwischen Agents. Stall erklärte in der Frage- und Antwortrunde vor Ort, dass Entwickler derzeit nicht über die API direkt verlangen können, dass ein bestimmter Sub-Agent im Arbeitsablauf eine Nachricht an einen anderen Sub-Agent sendet. Die Aufgabenverknüpfung zwischen Agents hängt hauptsächlich von der durch das Orchestrierungsprogramm definierten Ausführungslogik und den gemeinsamen Daten ab.

Dies unterscheidet sich auch von der Interaktionsweise gewöhnlicher Subagents. Threads herkömmlicher Sub-Agents können beibehalten werden, der Haupt-Agent kann ihnen weiterhin nachfolgende Nachrichten senden; die Threads von Sub-Agents in dynamischen Arbeitsabläufen können jedoch keine Nachrichten auf dieselbe Weise ergänzen und werden am Ende des Arbeitsablaufs archiviert.

Das gemeinsame Dateisystem bringt zudem ein weiteres technisches Problem mit sich: Kontextisolation bedeutet nicht gleich Dateizugriffsisolation. Obwohl die Dialoghistorien jedes Agents voneinander unabhängig sind, können sie auf die gemeinsamen Dateien in derselben Sitzungsumgebung zugreifen. Daher müssen Entwickler bei der Verarbeitung von Codes, Konfigurationsdateien oder sensiblen Daten weiterhin Aspekte wie Dateiüberschreibungen, Konflikte im gemeinsamen Zustand und