Orquesta varias sesiones de Devin con un script de Python determinista: distribuye el trabajo, transfiere resultados estructurados entre etapas y reanuda una ejecución desde donde se detuvo.
Los flujos de trabajo dinámicos están disponibles en cualquier sesión de Devin: solo describe el trabajo y pídele a Devin que lo ejecute como un flujo de trabajo.
Un flujo de trabajo dinámico es un script determinista de Python que orquesta un equipo de agentes de Devin. Devin escribe y ejecuta el script, que decide qué agentes se ejecutan, en qué orden y qué se le indica a cada uno, utilizando los resultados estructurados de los agentes anteriores para elaborar los prompts de los posteriores.Cada llamada a un agente queda registrada, por lo que una ejecución de flujo de trabajo puede observarse mientras se ejecuta y reanudarse si se interrumpe: los agentes completados reproducen al instante sus resultados registrados y solo se vuelve a ejecutar el trabajo pendiente.Esto va un paso más allá de los managed Devins, donde la sesión de coordinación crea y supervisa manualmente las sesiones secundarias. En un flujo de trabajo, la propia orquestación es código.
Solicita un flujo de trabajo cuando el trabajo tiene una estructura clara:
Amplia distribución con un paso de consolidación — aproximadamente cinco o más unidades independientes (archivos, módulos, endpoints, tickets) que requieren criterio o verificación y cuyos resultados se consolidan posteriormente.
Un proceso por etapas — las etapas posteriores consumen la salida estructurada de las anteriores; por ejemplo, auditar → corregir → verificar.
Usa una sesión simple (o un par de managed Devins) cuando:
El cambio es mecánico — un codemod, la corrección automática del linter o un generador lo realizan más rápido y de forma más fiable que los agentes.
Solo se necesitan una o dos sesiones independientes, sin flujo de datos entre ellas.
El trabajo está estrechamente acoplado por un estado compartido, o es pequeño y secuencial.
Describe la tarea y solicita un flujo de trabajo; Devin escribe el script.Migración — asigna un agente a cada unidad en su propia rama y, después, consolida los resultados:
Usa un flujo de trabajo para migrar cada job de jobs/ del ejecutor cron legacy anuestra nueva API de programación: un agente por job, cada uno trabajando en supropia rama y ejecutando las pruebas del job; después, resume qué jobs requierenatención manual
Investigación: recopila evidencia en paralelo y luego sintetízala:
Usa un flujo de trabajo para evaluar Postgres, DynamoDB y CockroachDB para el nuevoservicio de eventos: un agente por opción que la evalúe frente a nuestrosrequisitos de latencia, costo y operación, y luego un agente final que comparela evidencia y recomiende una
Revisión de código — un revisor por archivo y, luego, un paso de fusión:
Usa un flujo de trabajo para revisar cada archivo modificado en esta rama segúnCONTRIBUTING.md — un revisor por archivo — y luego combina los hallazgos enuna única lista sin duplicados ordenada por gravedad
Auditoría de toda la base de código — un proceso escalonado de auditar → corregir → verificar:
Usa un flujo de trabajo para auditar cada query SQL del module de reportes en buscade pagination faltante y patterns N+1, corrige cada issue confirmado en supropia rama y verifica cada corrección con un EXPLAIN antes y después
Bucle: se repite hasta que se supere una comprobación o se estanque el progreso.
Usa un flujo de trabajo para poner en verde la suite de integración inestable: ejecútala,corrige lo que haya fallado y repite hasta que pase tres ejecuciones consecutivas ohasta que una ronda no corrija nada nuevo
Devin escribe el script en un archivo e inicia la ejecución. Primero debes aprobarlo, a menos que hayas activado la aprobación automática en Settings → Preferences → Aprobar automáticamente los flujos de trabajo.
El script se ejecuta en la máquina de Devin. Las primitivas de los flujos de trabajo se insertan automáticamente; no hay nada que instalar ni importar.
Cada llamada a un agente crea un agente y espera su salida estructurada. De forma predeterminada, ese agente es una sesión de Devin independiente en su propia VM.
El progreso se transmite a la sesión. El panel de flujos de trabajo muestra cada fase, sus agentes y su estado en tiempo real; desde allí puedes abrir la sesión de cualquier agente.
Los resultados se registran con un ID de ejecución, lo que permite reanudarla.
La ejecución se realiza en segundo plano, por lo que la sesión sigue respondiendo; puedes seguir hablando con Devin mientras se ejecuta, pedir un resumen del progreso o pedirle que detenga la ejecución. Al detenerla, se cancela el script y las sesiones secundarias restantes pasan a dormir; todo lo que ya se registró puede reanudarse.
El script es Python puro. Devin lo escribe, pero es útil conocer su estructura al revisar uno:
Primitiva
Función
register_workflow(meta)
Declara el nombre, la descripción y las fases del flujo de trabajo. Debe esperarse antes de ejecutar cualquier agente.
agent(prompt, phase=..., schema=...)
Ejecuta un agente y devuelve su salida estructurada como un diccionario.
pipeline(items, stage1, stage2, ...)
Ejecuta cada elemento por las etapas de forma independiente; no hay barrera entre etapas, por lo que el elemento A puede estar en la etapa 3 mientras el elemento B sigue en la etapa 1.
parallel([...])
Ejecuta llamadas asíncronas de forma simultánea y espera a que todas finalicen. Úsalo solo cuando una etapa realmente necesite todos los resultados anteriores, por ejemplo, en un paso de combinación o eliminación de duplicados.
log("message")
Escribe una línea de progreso visible mientras la ejecución sigue en curso.
Cada llamada a agent() recibe un esquema JSON y devuelve un diccionario con esa estructura; así, los hallazgos de una etapa se convierten en el prompt de la siguiente. Mantén los esquemas pequeños y planos.
Un proceso de auditoría y corrección para tres módulos:
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())
De forma predeterminada, cada agente se ejecuta en su propia VM, aunque también puede fijarse a la máquina de la sesión de orquestación.
VM independiente (predeterminada)
Una sesión secundaria completa de Devin con su propia máquina, clones de repositorios y entorno. No puede ver los archivos de la sesión de orquestación, por lo que las transferencias de código se realizan mediante ramas de git: cada agente envía una rama y comunica su nombre, y las etapas posteriores lo leen de la salida estructurada.
VM compartida
El agente se ejecuta en la máquina de la sesión de orquestación y comparte su árbol de trabajo, incluidos los cambios sin confirmar; no se requiere transferencia mediante git. Úsela cuando los agentes deban leer o editar el árbol de trabajo actual, o cuando el repositorio solo exista en esa máquina.
Los agentes con VM compartida compiten con la sesión por CPU, memoria y disco, y tienen un límite de concurrencia menor. Como comparten un único árbol de trabajo sin aislamiento, a los procesos de escritura en paralelo se les deben asignar archivos o directorios estrictamente distintos.Los agentes también pueden fijarse a un modo específico de Devin; por ejemplo, al Devin Lite más económico para clasificar elementos en paralelo a gran escala.
Un script de flujo de trabajo se vuelve a ejecutar desde el principio cuando se reanuda una ejecución, y cada llamada al agente se identifica mediante un hash de su prompt, esquema y configuración de ejecución. Todo lo que ya se completó se reproduce a partir de su resultado registrado; el resto se ejecuta de nuevo con nuevas sesiones.Esto solo funciona si el script realiza las mismas llamadas cada vez. La lógica del flujo de trabajo y los prompts no deben depender de la hora o fecha actuales, de la aleatoriedad, de ID generados, de variables de entorno, del estado del sistema de archivos ni de respuestas de red. Todo lo que requiera inspeccionar el mundo exterior debe estar dentro de una llamada a agent(), cuya salida registrada consume el resto del script.Dos consecuencias que conviene conocer:
Editar un prompt vuelve a ejecutar ese agente y todo lo que viene después, mientras que los agentes anteriores que no se modificaron se siguen reproduciendo.
Una ejecución que agotó el tiempo de espera o fue interrumpida continúa donde se quedó cuando se reanuda con su ID de ejecución. El presupuesto predeterminado y máximo para una ejecución es de siete días.
Si un agente falla —su sesión finalizó o no produjo una salida estructurada válida—, el script decide qué sucede: omitir el elemento, sustituir un valor predeterminado, reintentar o marcar la ejecución como fallida. Una ejecución reanudada reintenta los agentes fallidos con nuevas sesiones.
Cada agente de un flujo de trabajo es una sesión de Devin, por lo que una ejecución puede consumir muchos más ACU que realizar la misma tarea en una única sesión. Antes de aplicar un flujo de trabajo a un repo completo, pruébalo con una parte: un directorio, tres módulos o una pregunta más acotada, y consulta el uso de ACU de los agentes en el panel del flujo de trabajo. Pedir un modo más económico para las etapas de gran volumen, como la clasificación de cada elemento, también ayuda a que una distribución amplia siga siendo asequible.
Una vez que un flujo de trabajo funciona, puedes confirmarlo en tu repo como una skill: un archivo workflow.py junto a un SKILL.md que describe cuándo usarlo. Devin lo detectará y volverá a ejecutarlo en tareas futuras, en lugar de crear un script nuevo. Pídele a Devin que guarde un flujo de trabajo y creará los archivos necesarios.
