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.
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 hinaus, bei denen die koordinierende Sitzung untergeordnete Sitzungen manuell startet und betreut. In einem Workflow ist die Orchestrierung selbst Code.
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), 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.
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:
Nutze einen Workflow, um jeden Job in jobs/ vom Legacy-Cron-Runner auf unsereneue Scheduler-API umzustellen — ein Agent pro Job, jeder auf einem eigenen Branch, derdie 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:
Nutze einen Workflow, um Postgres, DynamoDB und CockroachDB für den neuenEvents-Dienst zu bewerten: ein Agent pro Option, der diese anhand unsererAnforderungen an Latenz, Kosten und Betrieb bewertet, dann einabschließender Agent, der die Evidenz vergleicht und eine Option empfiehlt
Code-Review — ein Reviewer pro Datei, anschließend ein Merge-Schritt:
Nutze einen Workflow, um jede in diesem Branch geänderte Datei anhand vonCONTRIBUTING.md zu reviewen — ein Reviewer pro Datei — und führe die Befundeanschließend zu einer einzigen, nach Schweregrad sortierten Liste ohneDuplikate zusammen
Codebase-weites Audit — eine schrittweise Audit → Fix → Verifizierung-Pipeline:
Nutze einen Workflow, um jede SQL-Query im Reporting-Modul auf fehlendePaginierung und N+1-Muster zu prüfen, jedes bestätigte Problem in einemeigenen Branch zu beheben und jede Korrektur mit einem EXPLAIN davor unddanach zu verifizieren
Schleife — wiederholen, bis eine Prüfung bestanden ist oder der Fortschritt ins Stocken gerät:
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
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.
Das Skript läuft auf Devin’s Maschine. Workflow-Primitiven werden automatisch eingebunden – Sie müssen nichts installieren oder importieren.
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.
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.
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.
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.
Eine Pipeline zum Prüfen und Beheben über drei Module hinweg:
import asyncioimport jsonREPO = "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())
Standardmäßig wird jeder Agent auf einer eigenen VM ausgeführt. Alternativ kann er an die Maschine der orchestrierenden Sitzung angepinnt werden.
Separate VM (Standard)
Eine vollständige untergeordnete Devin-Sitzung mit eigener Maschine, Repo-Klonen und Umgebung. 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.
Gemeinsame VM
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.
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.
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 für Phasen mit hohem Durchsatz, etwa bei der Klassifizierung einzelner Elemente, hält auch eine breite Auffächerung bezahlbar.
Sobald ein Workflow funktioniert, kann er als Skill 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.
