Claude Code Workflows: Was sie sind und wann Sie wirklich einen brauchen

Claude Code Workflows: Was sie sind und wann Sie wirklich einen brauchen

Aktualisieren Sie Claude Code auf v2.1.154 und Sie finden in /config eine neue Zeile namens Dynamic workflows. Schalten Sie sie ein, und Claude kann nun ein JavaScript-Skript schreiben, das die Arbeit auf bis zu 16 gleichzeitige Agenten verteilt. Das ist das Feature, über das gerade alle reden. Die offizielle Dokumentation erklärt, was es tut. Was sie nicht erklärt, ist das, was Sie eigentlich wissen wollen: Brauchen Sie es, oder reichen die Subagenten, die Sie bereits haben?

Genau diese Lücke wollen wir schließen. Claude Code Workflows sind als Research Preview erschienen, und die Dokumentation liest sich wie Referenzmaterial, nicht wie Ratschlag. Deshalb haben wir den einzigen mitgelieferten Workflow, /deep-research, in unserer eigenen Content-Pipeline ausgeführt, die realen Zahlen protokolliert und ein ehrliches Urteil gefällt. Kurze Version: Solange Sie Ihre Agenten noch selbst im Blick behalten können, brauchen Sie noch keinen Workflow. Für manche von Ihnen sieht die Sache anders aus. Lesen Sie weiter, um herauszufinden, zu welcher Gruppe Sie gehören.

Wichtigste Erkenntnisse:

• Ein Claude Code Workflow ist ein JavaScript-Skript, das Claude selbst schreibt, um Subagenten zu koordinieren (Research Preview, v2.1.154+, alle bezahlten Pläne).
• Sie brauchen einen Workflow nur dann, wenn eine Aufgabe mehr Agenten erfordert, als ein einziges Gespräch koordinieren kann. Ansonsten reichen Subagenten.
• Heute ist ein einziger Workflow verfügbar: /deep-research. Er läuft im Hintergrund, während Ihre Session reaktionsfähig bleibt.
• Workflows verbrauchen viele Tokens. Wir haben einen echten Lauf gemessen, bevor wir ihn empfehlen (Zahlen weiter unten).

Was ist ein Claude Code Workflow?

Ein Claude Code Workflow ist ein JavaScript-Skript, das Subagenten koordiniert. Sie beschreiben die Aufgabe, Claude schreibt das Skript, und eine Runtime führt es im Hintergrund aus, während Ihr Chat-Fenster reaktionsfähig bleibt. Es ist ein Research-Preview-Feature in Claude Code, erfordert Claude Code v2.1.154+ und läuft auf allen bezahlten Plänen (Pro, Max, Team, Enterprise sowie über die API und Bedrock/Vertex/Foundry).

Die Alltagsversion: Stellen Sie sich vor, Sie treten an einen Küchentresen und beschreiben das Gericht, das Sie möchten. Der Chefkoch schreibt ein Rezept, reicht es an die Köche im Hintergrund weiter, und die legen los, während Sie am Tresen weiterplaudern. Sie managen keinen einzelnen Koch. Das Rezept übernimmt das. Das Rezept ist der Workflow, die Köche sind Subagenten, und die Hintergrundküche ist die Runtime.

Ein Workflow ist kein weiterer Agent. Er ist das Skript, das Ihren Agenten sagt, was sie tun sollen, in welcher Reihenfolge und was mit den Ergebnissen zu geschehen hat. Diese Unterscheidung ist wichtiger als alles andere in diesem Artikel, und im nächsten Abschnitt machen wir sie konkret.

Zur schnellen Klarstellung: Suchen Sie nach "claude code workflows" und stoßen Sie auf GitHub-Repos, Plugins und einen marketplace voller Community-Swarm-Tools wie Ruflo, claude-flow und wshobson/agents. Das sind Drittanbieter-Orchestratoren. Anthropics offizielles Dynamic workflows-Feature ist etwas anderes, Eingebautes. Wenn es in /config auf v2.1.154+ nicht auftaucht, ist es nicht das offizielle Feature.

Das reiht sich ein in andere Anthropic-Research-Preview-Releases wie die kürzlich erschienene Fast Mode Research Preview: früh ausgeliefert, hinter einem Toggle, und noch nicht ganz ausgereift. Behandeln Sie es als Preview, weil es genau das ist. Die vollständige Spezifikation finden Sie in der offiziellen Workflows-Dokumentation.

Workflows, Subagenten und Skills: Wer trägt den Plan?

Die sauberste Art, diese drei auseinanderzuhalten, ist eine einzige Frage: Wer trägt den Plan? Ein Skill sind gepackte Anweisungen und Wissen, die Claude auf Abruf lädt. Ein Subagent ist ein separater Kontext, der einen delegierten Job erledigt. Ein Workflow ist das Orchestrierungs-Skript, das Subagenten koordiniert, bis zu 16 gleichzeitig. Dieselbe Werkzeugkiste, drei verschiedene Aufgaben.

Hier ist der Vergleich, den die offizielle Dokumentation andeutet, aber nie nebeneinanderstellt:

Solange ein einziges Claude-Gespräch noch den gesamten Plan im Blick behalten kann, brauchen Sie einen Subagenten, keinen Workflow. Sobald Sie mehr Agenten starten, als Sie als Mensch noch überblicken können, wer was in welcher Reihenfolge tut, hat der Plan das Gespräch überwachsen. Das ist die Grenze, die ein Workflow überschreitet.

Sie möchten tiefer in das erste Glied einsteigen? Unser Skills-Tutorial erklärt, wie Sie Wissen verpacken, das Claude auf Abruf lädt. Und wenn Sie abwägen, ob Sie ein vollständiges Agent-Framework statt nativer Orchestrierung einsetzen sollen, hilft dieser Vergleich weiter. Unsere ehrliche Einschätzung: Native Primitive tragen Sie weiter, als man erwarten würde, bevor ein Framework seinen Aufwand rechtfertigt.

Wann brauchen Sie wirklich einen Claude Code Workflow?

Sie brauchen einen Claude Code Workflow, wenn (a) eine Aufgabe mehr Agenten erfordert als ein Gespräch koordinieren kann, (b) Sie die Orchestrierung als wiederholbaren Code und nicht als einmaligen Prompt haben möchten, oder (c) Sie eine gegenseitige Überprüfung durch mehrere Agenten benötigen. Wenn nichts davon zutrifft, reichen Subagenten. Seien Sie dabei ehrlich zu sich selbst.

Das ist der Teil, den die Dokumentation nicht ausspricht, also tun wir es: Sie brauchen wahrscheinlich noch keinen Workflow. Eine Handvoll Subagenten, die über ein normales Gespräch koordiniert werden, erledigen die tägliche Arbeit. Workflows sind kein Upgrade, zu dem man irgendwann aufsteigt. Sie sind ein Werkzeug für eine ganz bestimmte Aufgabenform: mehr Agenten als ein Kopf überblicken kann.

Gehen Sie diese Checkliste durch. Sie brauchen wahrscheinlich einen Workflow, wenn Sie mindestens eine Frage mit Ja beantworten:

• Die Aufgabe benötigt mehr Agenten, als ein Gespräch noch verwalten kann.
• Sie möchten die Orchestrierung als wiederholbaren Code, nicht als einen Prompt, den Sie jedes Mal neu eingeben.
• Sie brauchen eine gegenseitige Überprüfung durch Agenten, die die Arbeit der anderen kontrollieren.
• Sie führen dieselbe Mehr-Agenten-Aufgabe regelmäßig aus, etwa ein wiederkehrendes Codebase-Audit oder eine Migration von 500 Dateien.

Alle vier mit Nein beantwortet? Bleiben Sie bei Subagenten. Sie sparen Tokens, behalten die Debuggbarkeit und verlieren nichts. Wer aus der Spec-getriebenen Fraktion kommt, kennt dieses Muster aus guten CLAUDE.md-Best-Practices: Plan einmal aufschreiben, wiederholbar machen, aufhören ihn neu einzutippen. Ein Workflow ist genau diese Idee, weitergedacht bis zu dem Punkt, an dem der Plan selbst eine Runtime braucht.

Der einzige vorhandene Workflow: /deep-research

/deep-research ist der einzige Workflow, der in der Preview mitgeliefert wird. Stellen Sie eine Frage, und er verteilt Subagenten, die das Thema parallel recherchieren, gleicht ihre Ergebnisse gegenseitig ab und gibt eine einzige, zusammengefasste Antwort in Ihren Kontext zurück, während alles im Hintergrund läuft, sodass Ihre Session nutzbar bleibt.

/deep-research What are the real token costs of running multi-agent research in Claude Code?

Das ist die gesamte Schnittstelle. Darunter durchläuft er Phasen: Er zerlegt Ihre Frage in Recherche-Threads, startet Agenten, die jedem Thread nachgehen, führt eine gegenseitige Überprüfung durch, damit Agenten schwache Aussagen der anderen in Frage stellen, und synthetisiert dann eine finale Antwort zurück in Ihren Chat. Sie können ihn nicht mitten im Lauf steuern. Sie fragen, er arbeitet, er meldet sich zurück.

Das ist wirklich nützlich für unübersichtliche Recherchefragen, bei denen Sie sonst zehn Tabs öffnen und den Nachmittag verlieren würden. Wenn Sie bereits Research-Tooling aufbauen, ergänzt unsere Übersicht der besten MCP-Server diese Art von Fächerrecherche gut. Aber "nützlich" und "den Token-Preis wert" sind nicht dasselbe, genau das wollten wir messen.

Was passierte, als wir einen Workflow in unserer eigenen Pipeline ausführten

Unser /deep-research-Lauf startete 9 Subagenten über 4 Phasen, verbrauchte etwas über 1 Million Tokens und war nach etwa 8 Minuten Echtzeit fertig. War es das wert? Für eine schnelle Frage: nein. Für eine Recherche-Aufgabe, die wir sonst händisch über ein halbes Dutzend Agenten koordiniert hätten: ja. Hier die ehrliche Aufschlüsselung.

In unserer Pipeline wurde dieser Artikel selbst von einem Mehr-Agenten-System produziert: Recherche, Briefing, Schreiben, Validierung, Übersetzung und Veröffentlichung laufen jeweils als separate Subagenten. Wir leben also bereits in der "zu viele Agenten für ein Gespräch"-Welt aus der Checkliste oben. Das machte uns zum richtigen Testfall, keinem konstruierten.

Wir haben /deep-research auf einem echten Keyword ausgeführt, das wir ohnehin recherchierten, und den kompletten Lauf protokolliert:

Was uns am meisten überraschte, war die gegenseitige Prüfphase. Ein paar frühe Aussagen eines Agenten wurden still korrigiert, nachdem ein anderer Agent sie in Frage stellte, genau die Art von Dingen, die ein einzelnes Gespräch meistens durchwinkt. Dieser adversarielle Schritt ist der eigentliche Wert, mehr noch als die reine Parallelisierung. Der Token-Preis ist aber hoch, denn diese Agenten laufen auf Opus-Tier-Modellen (siehe Was ist neu in Opus 4.8 für die Bedeutung das für die Kosten hat). Eine Million Tokens für eine Frage, die man in zwei Prompts hätte beantworten können, ist ein schlechter Tausch. Für eine Frage, bei der wirklich sechs Quellen abgeglichen werden müssen, ist es ein Gewinn, gemessen an Ihrer Zeit.

Genau diese Art von Orchestrierung bauen wir bei Techsy für Kunden, also hatten wir bereits eine klare Vorstellung davon, wann es sich rechnet und wann es nur Budget verbrennt. Unsere Empfehlung: Setzen Sie ihn für die schwierigen Fragen ein, überspringen Sie ihn bei den einfachen.

Eigene Workflows erstellen und speichern

Um einen eigenen Workflow zu erstellen, beschreiben Sie die Aufgabe in einfacher Sprache mit dem Stichwort workflow, prüfen und genehmigen Sie das generierte Skript, und speichern Sie es dann als wiederverwendbaren /command. Für höheren Aufwand setzen Sie /effort ultracode, und Claude plant selbstständig einen Workflow. Kein JavaScript Ihrerseits nötig: Claude schreibt das Skript, Sie genehmigen es.

Hier der vollständige Ablauf, der gleichzeitig als Schritt-für-Schritt-Anleitung dient:

1. Dynamic workflows aktivieren. Öffnen Sie auf Pro /config und schalten Sie die Zeile Dynamic workflows ein. (Sie sind auf v2.1.154+, oder?)

   bash

   /config
   # dann die Zeile "Dynamic workflows" aktivieren

2. Aufgabe mit dem Stichwort workflow beschreiben. Schreiben Sie workflow irgendwo in Ihren Prompt, zum Beispiel: "Run a workflow to audit every route file in this repo for missing auth checks." Claude Code hebt das Wort hervor und schreibt ein Skript, anstatt Schritt für Schritt vorzugehen. Soll Claude selbst entscheiden? Setzen Sie /effort ultracode, das kombiniert xhigh-Reasoning mit automatischer Workflow-Orchestrierung für jede substanzielle Aufgabe, und verbraucht dabei mehr Tokens. Für Routinearbeit steigen Sie wieder auf /effort high zurück.

3. Generiertes Skript prüfen und genehmigen. Claude zeigt Ihnen die JavaScript-Orchestrierung, bevor irgendetwas ausgeführt wird. Lesen Sie sie durch. Das ist Ihre Chance, einen zu breiten Fan-out zu erkennen.

4. Als /command für Wiederverwendung speichern. Sobald es funktioniert, speichern Sie den Workflow als benutzerdefinierten Slash-Befehl, damit das Audit nächstes Quartal nur noch einen Tastendruck kostet.

Die Wiederverwendbarkeit ist der stille Gewinn. Ein einmaliges /deep-research ist praktisch, aber ein gespeicherter Workflow für "Authentifizierung über alle Routen prüfen" oder "Verzeichnis zur neuen API migrieren" verwandelt eine mehrstündige Koordinationsaufgabe in einen einzigen wiederholbaren Befehl. Ab diesem Punkt amortisieren sich die Token-Kosten über mehrere Läufe, anstatt einmalig zu schmerzen.

Limits, Kosten und wie Sie Workflows deaktivieren

Workflows laufen mit bis zu 16 gleichzeitigen Agenten bei einem harten Limit von 1.000 Agenten pro Lauf, nehmen nach dem Start keine Eingaben mehr entgegen und können nur innerhalb derselben Session fortgesetzt werden. Sie sind von Natur aus Token-intensiv, da jeder Agent eigenen Kontext verbraucht. Sie können das Feature vollständig mit disableWorkflows in der Konfiguration oder der Umgebungsvariablen CLAUDE_CODE_DISABLE_WORKFLOWS deaktivieren.

Jedes dieser Limits hat praktische Konsequenzen. Keine Eingabe während des Laufs bedeutet, dass Sie nicht korrigieren können, sobald er läuft, ein vager Prompt verschwendet also Tokens für einen ganzen Lauf. Nur innerhalb derselben Session fortsetzbar bedeutet: Schließen Sie das Terminal, ist der Lauf verloren. 1.000 Agenten pro Lauf klingt enorm, aber ein breiter Fan-out zu Opus-Tier-Preisen kostet echtes Geld. Behandeln Sie das Standard-Limit von 16 gleichzeitigen Agenten als Schutzfunktion, nicht als Decke, die es zu durchbrechen gilt.

Zum Deaktivieren:

export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# oder in Ihrer Konfiguration: "disableWorkflows": true setzen

Ein häufiger Stolperstein: Wenn /config keine Zeile Dynamic workflows zeigt, sind Sie unterhalb von v2.1.154. Erst aktualisieren. Und wenn Sie solche Agenten-Pipelines für echte Arbeit aufbauen und möchten, dass sie sich auch lohnen, bauen wir Agenten-Pipelines für B2B-Teams. Kostenloses Erstgespräch anfragen →, wenn Orchestrierung zum Engpass wird.

Fazit

Dieser Artikel in fünf Zeilen. Ein Claude Code Workflow ist ein JavaScript-Skript, das Claude schreibt, um Subagenten zu koordinieren, ausgeliefert als Research Preview in v2.1.154. Der einzige heute verfügbare Workflow ist /deep-research. Sie brauchen einen Workflow nur, wenn eine Aufgabe über das hinauswächst, was ein Gespräch koordinieren kann, wenn Sie wiederholbare Orchestrierung als Code möchten, oder wenn Sie möchten, dass Agenten sich gegenseitig überprüfen. Unser realer Lauf kostete ca. 1 Million Tokens für 9 Agenten in 8 Minuten, was bei einfachen Fragen zu viel ist und sich bei echter Mehrquellen-Recherche lohnt. Sie brauchen wahrscheinlich noch keinen, und das ist in Ordnung.

Häufig gestellte Fragen

Was ist ein Claude Code Workflow?

Ein Claude Code Workflow ist ein JavaScript-Skript, das Subagenten koordiniert. Sie beschreiben die Aufgabe, Claude schreibt das Skript, und eine Runtime führt es im Hintergrund aus, während Ihre Session reaktionsfähig bleibt. Es ist ein Research-Preview-Feature in Claude Code v2.1.154+, verfügbar auf allen bezahlten Plänen.

Was ist der Unterschied zwischen einem Workflow und einem Subagenten?

Ein Subagent ist ein einzelner delegierter Job, der in seinem eigenen Kontext läuft und von Ihnen im Gespräch koordiniert wird. Ein Workflow ist das Orchestrierungs-Skript, das Subagenten gleichzeitig koordiniert, bis zu 16 auf einmal. Wenn ein Gespräch noch den gesamten Plan tragen kann, nutzen Sie einen Subagenten. Wenn der Plan eine Runtime braucht, um die Agenten zu verfolgen, nutzen Sie einen Workflow.

Wie viele Tokens kostet ein Claude Code Workflow?

In unserem gemessenen /deep-research-Lauf verbrauchten 9 Subagenten über 4 Phasen rund 1,05 Millionen Tokens in etwa 8 Minuten. Workflows sind von Natur aus Token-intensiv, weil jeder Agent seinen eigenen Kontext verbraucht, und diese Agenten laufen auf Opus-Tier-Modellen. Für einfache Fragen ist das Verschwendung, für echte Mehrquellen-Recherche rechnet es sich.

Brauche ich einen bezahlten Plan für Claude Code Workflows?

Ja. Dynamic Workflows laufen auf allen bezahlten Claude-Plänen (Pro, Max, Team, Enterprise) sowie über die API und Bedrock/Vertex/Foundry. Es gibt keinen kostenlosen Zugang. Auf Pro aktivieren Sie das Feature, indem Sie nach dem Update auf Claude Code v2.1.154 die Zeile Dynamic workflows in /config einschalten.

Was ist /deep-research in Claude Code?

/deep-research ist der einzige mitgelieferte Workflow der Research Preview. Sie stellen eine Frage, er verteilt Subagenten, die das Thema parallel recherchieren, führt eine Prüfphase durch, in der Agenten die Ergebnisse der anderen verifizieren, und synthetisiert eine Antwort zurück in Ihren Kontext, alles im Hintergrund.

Wie speichere ich einen Workflow als Slash-Befehl?

Beschreiben Sie die Aufgabe mit dem Stichwort workflow, prüfen und genehmigen Sie das generierte JavaScript-Skript, und speichern Sie es dann als benutzerdefinierten /command. Danach läuft der gesamte Mehr-Agenten-Job mit einem einzigen Tastendruck, und genau ab diesem Punkt beginnen sich die Token-Kosten über wiederholte Läufe zu amortisieren.

Wie viele Agenten kann ein Workflow gleichzeitig ausführen?

Ein Workflow läuft mit bis zu 16 gleichzeitigen Agenten bei einem harten Limit von 1.000 Agenten pro Lauf. Das Standard-Limit von 16 besteht aus gutem Grund: Ein breiter Fan-out zu Opus-Tier-Preisen wird schnell teuer. Behandeln Sie die Limits als Leitplanken, nicht als Ziele, und halten Sie Ihren Fan-out so eng wie die Aufgabe es erlaubt.

Wie deaktiviere ich Dynamic Workflows?

Setzen Sie disableWorkflows in Ihrer Konfiguration auf true, oder exportieren Sie die Umgebungsvariable CLAUDE_CODE_DISABLE_WORKFLOWS=1 vor dem Start von Claude Code. Beides deaktiviert das Feature vollständig. Wenn Sie in /config gar keine Zeile Dynamic workflows sehen, sind Sie wahrscheinlich unterhalb der erforderlichen v2.1.154 und müssen erst aktualisieren.

Braucht man wirklich Claude Code Workflows, oder reichen Subagenten?

Subagenten reichen aus, bis eine Aufgabe ein einzelnes Gespräch übersteigt. Eine Handvoll Subagenten, die in einem normalen Gespräch koordiniert werden, deckt die tägliche Arbeit ab, ohne die Token-Kosten. Sie brauchen einen Workflow wirklich nur dann, wenn eine Aufgabe mehr Agenten umfasst als ein Gespräch verfolgen kann, wenn Sie die Orchestrierung als Code haben möchten oder wenn Agenten sich gegenseitig adversarisch überprüfen sollen.