Workflows dinâmicos do Devin

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 workflows dinâmicos?

Um workflow 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 workflow 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 workflow, a própria orquestração é código.

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.

Prefira uma sessão simples (ou algumas Devins gerenciados) quando:

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:

Use um workflow para migrar todo job em jobs/ do executor cron legacy para a
nossa nova API de scheduler — um agent por job, cada um trabalhando na própria
branch e rodando os testes do job — e depois consolide quais jobs precisam de
atenção manual

Pesquisa — reúna evidências em paralelo e depois sintetize:

Use um workflow para avaliar Postgres, DynamoDB e CockroachDB para o novo
serviço de eventos: um agent por opção, pontuando cada uma frente aos nossos
requisitos de latência, custo e operação, e depois um agent final que compara as
evidências e recomenda uma delas

Revisão de código — um revisor por arquivo e, em seguida, uma etapa de merge:

Use um workflow para revisar todos os arquivos alterados nesta branch com base no
CONTRIBUTING.md — um revisor por arquivo — e depois faça o merge dos resultados em uma
única lista sem duplicatas, ordenada por severidade

Auditoria de todo o codebase — um pipeline em etapas de auditar → corrigir → verificar:

Use um workflow para auditar cada query SQL no module de relatórios em busca de
pagination ausente e patterns N+1, corrigir cada problema confirmado em uma
branch separada e verificar cada correção com um EXPLAIN antes e depois

Loop — repita até que uma verificação seja aprovada ou o progresso seja interrompido:

Use um workflow para deixar verde a suíte instável de testes de integração:
execute-a, corrija o que falhou e repita até ela passar em três runs
consecutivos ou até uma rodada não corrigir nada de novo

Como funciona uma execução

Devin grava o script em um arquivo e inicia a execução. Você precisa aprová-lo antes, a menos que tenha ativado a aprovação automática em Configurações → Preferências → Aprovar workflows automaticamente.
O script é executado na máquina do Devin. Os componentes básicos do workflow são inseridos 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 workflow 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.

A execução ocorre em segundo plano, portanto a sessão permanece responsiva — você pode continuar conversando com o Devin enquanto ele executa, pedir um resumo do progresso ou solicitar que interrompa a execução. Interromper a execução cancela o script e coloca as sessões filhas restantes em suspensão; tudo o que já foi registrado continua disponível para retomada.

Modelo de criação

O script é Python puro. O Devin o escreve, mas é útil conhecer sua estrutura ao revisá-lo:

Primitiva	O que faz
`register_workflow(meta)`	Declara o nome, a descrição e as fases do workflow. Deve ser aguardado antes da execução de qualquer agente.
`agent(prompt, phase=..., schema=...)`	Executa um agente e retorna sua saída estruturada como um dicionário.
`pipeline(items, stage1, stage2, ...)`	Executa cada item pelas etapas de forma independente — não há barreira entre as etapas, portanto o item A pode estar na etapa 3 enquanto o item B ainda está na etapa 1.
`parallel([...])`	Executa chamáveis assíncronos simultaneamente e aguarda a conclusão de todos. Use apenas quando uma etapa realmente precisar de todos os resultados anteriores, como em uma etapa de merge ou deduplicação.
`log("message")`	Registra uma linha de progresso visível enquanto a execução ainda está em andamento.

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:

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

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.

Agentes em VM compartilhada disputam CPU, memória e disco com a sessão e têm um limite de concorrência menor. Como compartilham uma única árvore de trabalho sem isolamento, agentes que escrevem em paralelo devem receber arquivos ou diretórios estritamente distintos. Os agentes também podem ser fixados a um modo específico do Devin — por exemplo, o Devin Lite, mais barato, para classificar itens em uma ampla distribuição.

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 chamada agent(), 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.

Se um agente falhar — sua sessão for encerrada ou ele não produzir uma saída estruturada válida — o script decide o que acontece: pular o item, substituir por um valor padrão, tentar novamente ou falhar a execução. Uma execução retomada tenta novamente os agentes que falharam em novas sessões.

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: um workflow.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.

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

Introdução

Diretrizes fundamentais

Integração do Devin

Trabalhando com o Devin

Guias do produto

Integrações

Admin

Notas de versão

Workflows dinâmicos do Devin

O que são workflows dinâmicos?

Quando usar um workflow

Exemplos de prompts

Como funciona uma execução

Modelo de criação

Exemplo

Onde os agentes são executados

VM separada (padrão)

VM compartilhada

Determinismo e retomada

Custo

Salvando um workflow para reutilização

​O que são workflows dinâmicos?

​Quando usar um workflow

​Exemplos de prompts

​Como funciona uma execução

​Modelo de criação

​Exemplo

​Onde os agentes são executados

VM separada (padrão)

VM compartilhada

​Determinismo e retomada

​Custo

​Salvando um workflow para reutilização

​Conteúdos relacionados

O que são workflows dinâmicos?

Quando usar um workflow

Exemplos de prompts

Como funciona uma execução

Modelo de criação

Exemplo

Onde os agentes são executados

Determinismo e retomada

Custo

Salvando um workflow para reutilização

Conteúdos relacionados