Os workflows dinâmicos estão disponíveis em qualquer sessão do Devin — basta descrever o trabalho e pedir ao Devin que o execute como um workflow.Contas Enterprise: o recurso fica desativado até que um administrador Enterprise ative Workflows dinâmicos em Configurações Enterprise > Devin. Até lá, o Devin não executará workflows em nenhuma das organizações da Enterprise.
O que são fluxos de trabalho dinâmicos?
Um fluxo de trabalho dinâmico é um script Python determinístico que orquestra uma equipe de agentes Devin. O Devin escreve e executa o script, que decide quais agentes serão executados, em que ordem e o que será informado a cada um — usando os resultados estruturados de agentes anteriores para criar os prompts dos seguintes. Cada chamada de agente é registrada, portanto uma execução de fluxo de trabalho pode ser observada enquanto está em andamento e retomada caso seja interrompida: os agentes concluídos reproduzem instantaneamente seus resultados registrados, e apenas o trabalho não concluído é executado novamente. Isso vai além dos Devins gerenciados, em que a sessão coordenadora inicia e supervisiona manualmente sessões filhas. Em um fluxo de trabalho, a própria orquestração é código.Como os workflows dinâmicos funcionam e quando usá-los, com um exemplo de revisão de acessibilidade em 12 componentes
Quando usar um workflow
Solicite um workflow quando o trabalho tiver uma estrutura bem definida:- Várias frentes com uma etapa de consolidação — cerca de cinco ou mais unidades independentes (arquivos, módulos, endpoints, tickets), cada uma exigindo avaliação ou verificação, cujos resultados são então reunidos.
- Um pipeline em etapas — etapas posteriores consomem a saída estruturada das anteriores, por exemplo, auditar → corrigir → verificar.
- A alteração for mecânica — um codemod, uma correção automática do linter ou um gerador a realiza mais rápido e com mais confiabilidade do que agentes.
- Apenas uma ou duas sessões independentes forem necessárias, sem fluxo de dados entre elas.
- O trabalho estiver fortemente acoplado por meio de estado compartilhado ou for pequeno e sequencial.
Exemplos de prompts
Você descreve a tarefa e solicita um fluxo de trabalho; o Devin escreve o script. Migração — distribua um agente por unidade em sua própria branch e, em seguida, consolide:Como funciona uma execução
- Devin grava o script em um arquivo e inicia a execução. Por padrão, as execuções são aprovadas automaticamente; para que o Devin peça sua aprovação antes de cada execução, desative Configurações → Preferências → Aprovar fluxos de trabalho automaticamente.
- O script é executado na máquina do Devin. As primitivas do fluxo de trabalho são inseridas automaticamente — não é necessário instalar nem importar nada.
- Cada chamada de agente inicia um agente e aguarda sua saída estruturada. Por padrão, esse agente é uma sessão independente do Devin em sua própria VM.
- O progresso é transmitido para a sessão. O painel do fluxo de trabalho mostra cada fase, seus agentes e o status em tempo real; você pode abrir a sessão de qualquer agente por lá.
- Os resultados são registrados com um ID de execução, o que permite retomar a execução.
Modelo de criação
O script é Python puro. O Devin o escreve, mas é útil conhecer sua estrutura ao revisá-lo:
Cada chamada a
agent() recebe um JSON Schema e retorna um dicionário conforme esse schema, permitindo que os resultados de uma etapa se tornem o prompt da próxima. Mantenha os schemas pequenos e simples.
Exemplo
Um pipeline de auditoria seguida de correção em três módulos:Onde os agentes são executados
Por padrão, cada agente é executado em sua própria VM, mas também pode ser fixado à máquina da sessão de orquestração.VM separada (padrão)
Uma sessão filha completa do Devin, com sua própria máquina, clones do repo e ambiente. Ela não consegue acessar os arquivos da sessão de orquestração, portanto as transferências de código ocorrem por branches do Git: cada agente envia uma branch e informa seu nome, e as etapas posteriores o leem na saída estruturada.
VM compartilhada
O agente é executado na máquina da sessão de orquestração e compartilha sua árvore de trabalho, incluindo alterações não comitadas — sem necessidade de transferência via Git. Use-a quando os agentes precisarem ler ou editar a árvore de trabalho atual ou quando o repo existir apenas nessa máquina.
Determinismo e retomada
Um script de workflow é reexecutado desde o início quando uma execução é retomada, e cada chamada de agente é identificada por um hash de seu prompt, esquema e configurações de execução. Tudo o que já foi concluído é reproduzido a partir do resultado registrado; o restante é executado do zero em novas sessões. Isso só funciona se o script fizer as mesmas chamadas sempre. A lógica e os prompts do workflow não podem depender da hora ou data atuais, de aleatoriedade, IDs gerados, variáveis de ambiente, estado do sistema de arquivos ou respostas da rede. Tudo o que precisar inspecionar o mundo externo deve ficar dentro de uma chamadaagent(), cuja saída registrada é consumida pelo restante do script.
Duas consequências importantes:
- Editar um prompt reexecuta esse agente e tudo o que vem depois dele, enquanto os agentes anteriores que não foram alterados continuam sendo reproduzidos.
- Uma execução que atingiu o tempo limite ou foi interrompida continua de onde parou quando retomada com seu ID de execução. O orçamento padrão e máximo de uma execução é de sete dias.
Custo
Cada agente em um workflow é uma sessão do Devin, portanto uma execução pode consumir muito mais ACUs do que realizar a mesma tarefa em uma única sessão. Antes de aplicar um workflow a um repo inteiro, execute-o em uma parte — um diretório, três módulos ou uma pergunta mais específica — e verifique o uso de ACU dos agentes no painel do workflow. Solicitar um modo mais econômico em etapas de alto volume, como a classificação de cada item, também ajuda a manter viável uma ampla distribuição de trabalho.Salvando um workflow para reutilização
Quando um workflow estiver funcionando, ele poderá ser comitado no seu repo como uma skill: umworkflow.py ao lado de um SKILL.md que descreve quando usá-lo. O Devin então o identifica e o executa novamente em tarefas futuras, em vez de criar um novo script. Peça ao Devin para salvar um workflow, e ele criará os arquivos necessários.
Conteúdos relacionados
- Recursos avançados — orquestre Devins gerenciados diretamente
- Skills — salve procedimentos reutilizáveis, incluindo workflows, nos seus repos
- Devin MCP — crie e monitore sessões programaticamente

