> ## Documentation Index > Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt > Use this file to discover all available pages before exploring further. # Dynamische Devin-Workflows > Orchestrieren Sie zahlreiche Devin-Sitzungen mit einem deterministischen Python-Skript: Verteilen Sie Aufgaben, leiten Sie strukturierte Ergebnisse zwischen Phasen weiter und setzen Sie einen Durchlauf dort fort, wo er unterbrochen wurde. Dynamische Workflows sind in jeder Devin-Sitzung verfügbar — beschreiben Sie einfach die Aufgabe und bitten Sie Devin, sie als Workflow auszuführen. **Enterprise-Konten:** Die Funktion ist deaktiviert, bis ein Enterprise-Admin unter [Enterprise Settings > Devin](https://app.devin.ai/settings/enterprise-devin) **Dynamische Workflows** aktiviert. Bis dahin führt Devin in keiner der Organisationen des Enterprise Workflows aus.
## Was sind dynamische Workflows?
Ein dynamischer Workflow ist ein **deterministisches Python-Skript, das ein Team von Devin-Agenten orchestriert**. Devin schreibt und führt das Skript aus. Das Skript entscheidet, welche Agenten in welcher Reihenfolge ausgeführt werden und welche Anweisungen sie erhalten — dabei nutzt es die strukturierten Ergebnisse früherer Agenten, um die Prompts späterer Agenten zu erstellen. Jeder Agentenaufruf wird aufgezeichnet, sodass ein Workflow-Durchlauf während der Ausführung nachvollziehbar ist und nach einer Unterbrechung fortgesetzt werden kann: Abgeschlossene Agenten geben ihre aufgezeichneten Ergebnisse sofort wieder, und nur die noch nicht abgeschlossene Arbeit wird erneut ausgeführt. Dies geht über [verwaltete Devins](/de/work-with-devin/advanced-capabilities#managed-devins) hinaus, bei denen die koordinierende Sitzung untergeordnete Sitzungen manuell startet und betreut. In einem Workflow ist die Orchestrierung selbst Code.
## Wann ein Workflow sinnvoll ist
Nutze einen Workflow, wenn die Aufgabe eine klare Struktur hat: * **Breite Auffächerung mit Zusammenführungsschritt** — etwa fünf oder mehr unabhängige Einheiten (Dateien, Module, Endpunkte, Tickets), die jeweils eine Bewertung oder Überprüfung erfordern und deren Ergebnisse anschließend zusammengeführt werden. * **Eine mehrstufige Pipeline** — spätere Stufen nutzen die strukturierte Ausgabe früherer Stufen, zum Beispiel *Prüfen → Beheben → Verifizieren*. Bleibe bei einer einfachen Sitzung (oder einigen [verwalteten Devins](/de/work-with-devin/advanced-capabilities#managed-devins)), wenn: * Die Änderung mechanisch ist — ein Codemod, Linter-Autofix oder Generator erledigt sie schneller und zuverlässiger als Agenten. * Nur eine oder zwei unabhängige Sitzungen benötigt werden und keine Daten zwischen ihnen fließen. * Die Arbeit durch gemeinsamen Zustand eng gekoppelt oder klein und sequenziell ist.
### Beispiel-Prompts
Sie beschreiben die Aufgabe und fordern einen Workflow an; Devin schreibt das Skript. **Migration** — starten Sie für jede Einheit einen Agent in einem eigenen Branch und führen Sie die Ergebnisse anschließend zusammen: ```text theme={null} Nutze einen Workflow, um jeden Job in jobs/ vom Legacy-Cron-Runner auf unsere neue Scheduler-API umzustellen — ein Agent pro Job, jeder auf einem eigenen Branch, der die Tests des Jobs ausführt — und fasse anschließend zusammen, welche Jobs manuell nachbearbeitet werden müssen ``` **Recherche** — parallel Belege zusammentragen und anschließend zusammenfassen: ```text theme={null} Nutze einen Workflow, um Postgres, DynamoDB und CockroachDB für den neuen Events-Dienst zu bewerten: ein Agent pro Option, der diese anhand unserer Anforderungen an Latenz, Kosten und Betrieb bewertet, dann ein abschließender Agent, der die Evidenz vergleicht und eine Option empfiehlt ``` **Code-Review** — ein Reviewer pro Datei, anschließend ein Merge-Schritt: ```text theme={null} Nutze einen Workflow, um jede in diesem Branch geänderte Datei anhand von CONTRIBUTING.md zu reviewen — ein Reviewer pro Datei — und führe die Befunde anschließend zu einer einzigen, nach Schweregrad sortierten Liste ohne Duplikate zusammen ``` **Codebase-weites Audit** — eine schrittweise *Audit → Fix → Verifizierung*-Pipeline: ```text theme={null} Nutze einen Workflow, um jede SQL-Query im Reporting-Modul auf fehlende Paginierung und N+1-Muster zu prüfen, jedes bestätigte Problem in einem eigenen Branch zu beheben und jede Korrektur mit einem EXPLAIN davor und danach zu verifizieren ``` **Schleife** — wiederholen, bis eine Prüfung bestanden ist oder der Fortschritt ins Stocken gerät: ```text theme={null} Nutze einen Workflow, um die instabile Integrationstest-Suite grün zu bekommen: führe sie aus, korrigiere alles, was fehlgeschlagen ist, und wiederhole das so lange, bis sie drei aufeinanderfolgende Runs besteht oder eine Runde nichts Neues mehr korrigiert ```
## So funktioniert ein Durchlauf
1. **Devin schreibt das Skript** in eine Datei und startet den Durchlauf. Sie genehmigen ihn zunächst, sofern Sie nicht unter **Settings → Preferences → Workflows automatisch genehmigen** die automatische Genehmigung aktiviert haben. 2. **Das Skript läuft auf Devin's Maschine.** Workflow-Primitiven werden automatisch eingebunden – Sie müssen nichts installieren oder importieren. 3. **Jeder Agentenaufruf startet einen Agenten** und wartet auf dessen strukturierte Ausgabe. Standardmäßig ist dieser Agent eine unabhängige Devin-Sitzung auf einer eigenen VM. 4. **Der Fortschritt wird in die Sitzung gestreamt.** Das Workflow-Panel zeigt jede Phase, ihre Agenten und deren Live-Status; von dort aus können Sie die Sitzung jedes Agenten öffnen. 5. **Ergebnisse werden** unter einer Durchlauf-ID erfasst, wodurch sich der Durchlauf fortsetzen lässt. Der Durchlauf erfolgt im Hintergrund, sodass die Sitzung reaktionsfähig bleibt – Sie können während der Ausführung weiter mit Devin sprechen, nach einer Fortschrittszusammenfassung fragen oder Devin bitten, den Durchlauf zu stoppen. Beim Stoppen wird das Skript abgebrochen und die verbleibenden untergeordneten Sitzungen werden in den Ruhezustand versetzt; alles bereits Erfasste kann weiterhin zum Fortsetzen verwendet werden.
## Erstellungsmodell
Das Skript besteht aus reinem Python. Devin schreibt es, aber beim Überprüfen hilft es, seine Struktur zu kennen: | Grundelement | Funktion | | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `register_workflow(meta)` | Deklariert Name, Beschreibung und Phasen des Workflows. Muss abgewartet werden, bevor Agenten ausgeführt werden. | | `agent(prompt, phase=..., schema=...)` | Führt einen Agenten aus und gibt dessen strukturierte Ausgabe als Dict zurück. | | `pipeline(items, stage1, stage2, ...)` | Führt jeden Eintrag unabhängig durch die Phasen — es gibt keine Barriere zwischen den Phasen. Daher kann sich Eintrag A bereits in Phase 3 befinden, während Eintrag B noch in Phase 1 ist. | | `parallel([...])` | Führt asynchrone Callables parallel aus und wartet auf alle. Nur verwenden, wenn eine Phase tatsächlich alle vorherigen Ergebnisse benötigt, etwa bei einem Merge- oder Deduplizierungsschritt. | | `log("message")` | Schreibt eine Fortschrittszeile, die sichtbar ist, solange die Ausführung noch läuft. | Jeder `agent()`-Aufruf erhält ein JSON-Schema und gibt ein entsprechend strukturiertes Dict zurück. So werden die Befunde einer Phase zum Prompt der nächsten Phase. Halten Sie Schemas klein und flach.
### Beispiel
Eine Pipeline zum Prüfen und Beheben über drei Module hinweg: ```python theme={null} import asyncio import json REPO = "github.com/acme/api" MODULES = ["auth", "billing", "search"] META = { "name": "error-handling-audit", "description": "Audit and fix error-handling bugs across api modules", "phases": [ {"title": "analyze", "detail": "audit each module for error-handling bugs"}, {"title": "fix", "detail": "fix confirmed issues and push a branch"}, ], } FINDINGS_SCHEMA = { "type": "object", "properties": { "module": {"type": "string"}, "issues": {"type": "array", "items": {"type": "string"}}, }, "required": ["module", "issues"], } FIX_SCHEMA = { "type": "object", "properties": {"branch": {"type": "string"}, "summary": {"type": "string"}}, "required": ["branch", "summary"], } async def analyze(module): return await agent( f"In {REPO}, audit the '{module}' module for error-handling bugs. " "Report each issue as a one-line string.", phase="analyze", schema=FINDINGS_SCHEMA, label=f"analyze-{module}", ) async def fix(findings): if not findings["issues"]: return None return await agent( f"In {REPO}, fix these issues in the '{findings['module']}' module:\n" + json.dumps(findings["issues"], sort_keys=True) + "\nPush your work to a new git branch (do not open a PR) and " "report the branch name and a one-line summary.", phase="fix", schema=FIX_SCHEMA, label=f"fix-{findings['module']}", ) async def main(): await register_workflow(META) results = await pipeline(MODULES, analyze, fix) for module, result in zip(MODULES, results): log(f"{module}: {result['branch'] if result else 'no fix needed/failed'}") asyncio.run(main()) ```
## Wo Agents ausgeführt werden
Standardmäßig wird jeder Agent auf einer eigenen VM ausgeführt. Alternativ kann er an die Maschine der orchestrierenden Sitzung angepinnt werden. Eine vollständige untergeordnete Devin-Sitzung mit eigener Maschine, Repo-Klonen und [Umgebung](/de/onboard-devin/environment/blueprints). Sie kann nicht auf die Dateien der orchestrierenden Sitzung zugreifen. Code wird daher über Git-Branches übergeben: Jeder Agent pusht einen Branch und meldet dessen Namen; spätere Phasen lesen ihn aus der strukturierten Ausgabe aus. Der Agent wird auf der Maschine der orchestrierenden Sitzung ausgeführt und teilt deren Working Tree, einschließlich nicht committeter Änderungen – eine Git-Übergabe ist nicht erforderlich. Verwenden Sie dies, wenn Agents den aktuellen Working Tree lesen oder bearbeiten müssen oder wenn das Repo nur auf dieser Maschine vorhanden ist. Agents auf gemeinsamen VMs konkurrieren mit der Sitzung um CPU, Arbeitsspeicher und Speicherplatz und unterliegen einer niedrigeren Parallelitätsobergrenze. Da sie sich ohne Isolierung einen Working Tree teilen, müssen parallele Schreibvorgänge strikt getrennte Dateien oder Verzeichnisse verwenden. Agents können außerdem an einen bestimmten Devin-Modus angepinnt werden – zum Beispiel an das kostengünstigere Devin Lite, um einzelne Elemente bei einer breiten Auffächerung zu klassifizieren.
## Determinismus und Fortsetzen
Beim Fortsetzen eines Durchlaufs wird ein Workflow-Skript von Anfang an erneut ausgeführt. Jeder Agentenaufruf wird anhand eines Hashs seines Prompts, Schemas und seiner Ausführungseinstellungen identifiziert. Alles, was bereits abgeschlossen wurde, wird anhand des aufgezeichneten Ergebnisses wiederholt; der Rest wird mit neuen Sitzungen erneut ausgeführt. Das funktioniert nur, wenn das Skript jedes Mal dieselben Aufrufe ausführt. Workflow-Logik und Prompts dürfen nicht von der aktuellen Uhrzeit oder dem aktuellen Datum, Zufälligkeit, generierten IDs, Umgebungsvariablen, dem Zustand des Dateisystems oder Netzwerkantworten abhängen. Alles, was die Außenwelt prüfen muss, gehört in einen `agent()`-Aufruf, dessen aufgezeichnete Ausgabe vom restlichen Skript verwendet wird. Zwei wichtige Konsequenzen: * **Wenn Sie einen Prompt bearbeiten, wird dieser Agent erneut ausgeführt** – ebenso wie alles, was davon abhängt. Unveränderte frühere Agenten werden weiterhin wiederholt. * **Ein Durchlauf, bei dem ein Timeout auftrat oder der unterbrochen wurde, wird an der Stelle fortgesetzt, an der er aufgehört hat**, wenn er anhand seiner Durchlauf-ID fortgesetzt wird. Das Standard- und Maximalbudget für einen Durchlauf beträgt sieben Tage. Wenn ein Agent fehlschlägt – weil seine Sitzung beendet wurde oder er keine gültige strukturierte Ausgabe erzeugt hat –, entscheidet das Skript über das weitere Vorgehen: das Element überspringen, einen Standardwert einsetzen, es erneut versuchen oder den Durchlauf fehlschlagen lassen. Ein fortgesetzter Durchlauf versucht fehlgeschlagene Agenten mit neuen Sitzungen erneut.
## Kosten
Jeder Agent in einem Workflow ist eine Devin-Sitzung. Daher kann ein Durchlauf deutlich mehr ACUs verbrauchen als dieselbe Aufgabe in einer einzelnen Sitzung. Bevor Sie einen Workflow auf ein gesamtes Repo anwenden, führen Sie ihn zunächst für einen Ausschnitt aus – ein Verzeichnis, drei Module oder eine enger gefasste Frage – und prüfen Sie im Workflow-Panel die ACU-Nutzung der Agents. Ein kostengünstigerer [Modus](/de/essential-guidelines/when-to-use-devin) für Phasen mit hohem Durchsatz, etwa bei der Klassifizierung einzelner Elemente, hält auch eine breite Auffächerung bezahlbar.
## Einen Workflow zur Wiederverwendung speichern
Sobald ein Workflow funktioniert, kann er als [Skill](/de/product-guides/skills) in Ihrem Repo committet werden: als `workflow.py` neben einer `SKILL.md`, die beschreibt, wann er verwendet werden soll. Devin erkennt ihn dann bei zukünftigen Aufgaben und führt ihn erneut aus, statt ein neues Skript zu schreiben. Bitten Sie Devin, einen Workflow zu speichern, und Devin erstellt die erforderlichen Dateien für Sie. * [Erweiterte Funktionen](/de/work-with-devin/advanced-capabilities) — verwaltete Devins direkt orchestrieren * [Skills](/de/product-guides/skills) — wiederverwendbare Verfahren, einschließlich Workflows, in Ihren Repos speichern * [Devin MCP](/de/work-with-devin/devin-mcp) — Sitzungen programmgesteuert erstellen und überwachen