Flujos de trabajo dinámicos de Devin

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.Cuentas Enterprise: la funcionalidad está desactivada hasta que un administrador de Enterprise active Flujos de trabajo dinámicos en Settings de Enterprise > Devin. Hasta entonces, Devin no ejecutará flujos de trabajo en ninguna de las organizaciones de Enterprise.

¿Qué son los flujos de trabajo dinámicos?

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 Devin gestionados, 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.

Cómo funcionan los flujos de trabajo dinámicos y cuándo usarlos, con un ejemplo de revisión de accesibilidad de 12 componentes

Cuándo usar un flujo de trabajo

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.

Ejemplos de prompts

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 a
nuestra nueva API de programación: un agente por job, cada uno trabajando en su
propia rama y ejecutando las pruebas del job; después, resume qué jobs requieren
atenció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 nuevo
servicio de eventos: un agente por opción que la evalúe frente a nuestros
requisitos de latencia, costo y operación, y luego un agente final que compare
la 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ún
CONTRIBUTING.md — un revisor por archivo — y luego combina los hallazgos en
una ú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 busca
de pagination faltante y patterns N+1, corrige cada issue confirmado en su
propia 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 o
hasta que una ronda no corrija nada nuevo

Cómo funciona una ejecución

Devin escribe el script en un archivo e inicia la ejecución. Las ejecuciones se aprueban automáticamente de forma predeterminada; para que Devin te pida aprobación antes de cada ejecución, desactiva 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 del flujo 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.

Modelo de creación

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.

Ejemplo

Un proceso de auditoría y corrección para tres módulos:

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())

Dónde se ejecutan los agentes

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.

Determinismo y reanudación

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.

Coste

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.

Guardar un flujo de trabajo para reutilizarlo

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.

Capacidades avanzadas — orquestar directamente Devins gestionados
Skills — guardar procedimientos reutilizables, incluidos flujos de trabajo, en tus repos
Devin MCP — crear y supervisar sesiones de forma programática

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Flujos de trabajo dinámicos de Devin

¿Qué son los flujos de trabajo dinámicos?

Cuándo usar un flujo de trabajo

Ejemplos de prompts

Cómo funciona una ejecución

Modelo de creación

Ejemplo

Dónde se ejecutan los agentes

VM independiente (predeterminada)

VM compartida

Determinismo y reanudación

Coste

Guardar un flujo de trabajo para reutilizarlo

​¿Qué son los flujos de trabajo dinámicos?

​Cuándo usar un flujo de trabajo

​Ejemplos de prompts

​Cómo funciona una ejecución

​Modelo de creación

​Ejemplo

​Dónde se ejecutan los agentes

VM independiente (predeterminada)

VM compartida

​Determinismo y reanudación

​Coste

​Guardar un flujo de trabajo para reutilizarlo

​Contenido relacionado

¿Qué son los flujos de trabajo dinámicos?

Cuándo usar un flujo de trabajo

Ejemplos de prompts

Cómo funciona una ejecución

Modelo de creación

Ejemplo

Dónde se ejecutan los agentes

Determinismo y reanudación

Coste

Guardar un flujo de trabajo para reutilizarlo

Contenido relacionado