Orquestre várias sessões do Devin com um script Python determinístico: distribua o trabalho, encaminhe resultados estruturados entre etapas e retome uma execução de onde ela parou.
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.
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.
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.
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 anossa nova API de scheduler — um agent por job, cada um trabalhando na própriabranch e rodando os testes do job — e depois consolide quais jobs precisam deatenção manual
Pesquisa — reúna evidências em paralelo e depois sintetize:
Use um workflow para avaliar Postgres, DynamoDB e CockroachDB para o novoserviço de eventos: um agent por opção, pontuando cada uma frente aos nossosrequisitos de latência, custo e operação, e depois um agent final que compara asevidê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 noCONTRIBUTING.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 depagination ausente e patterns N+1, corrigir cada problema confirmado em umabranch 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 runsconsecutivos ou até uma rodada não corrigir nada de novo
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.
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.
Um pipeline de auditoria seguida de correção em três 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())
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.
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.
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.
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.
