> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows dinâmicos do Devin

> 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.

<Info>
  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](https://app.devin.ai/settings/enterprise-devin). Até lá, o Devin não executará workflows em nenhuma das organizações da Enterprise.
</Info>

<div id="what-are-dynamic-workflows">
  ## O que são workflows dinâmicos?
</div>

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](/pt-BR/work-with-devin/advanced-capabilities#managed-devins), em que a sessão coordenadora inicia e supervisiona manualmente sessões filhas. Em um workflow, a própria orquestração é código.

<div id="when-to-use-a-workflow">
  ## Quando usar um workflow
</div>

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](/pt-BR/work-with-devin/advanced-capabilities#managed-devins)) 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.

<div id="example-prompts">
  ### Exemplos de prompts
</div>

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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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*:

```text theme={null}
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:

```text theme={null}
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
```

<div id="how-a-run-works">
  ## Como funciona uma execução
</div>

1. **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**.
2. **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.
3. **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.
4. **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á.
5. **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.

<div id="authoring-model">
  ## Modelo de criação
</div>

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.

<div id="example">
  ### Exemplo
</div>

Um pipeline de auditoria seguida de correção em três módulos:

```python theme={null}
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())
```

<div id="where-agents-run">
  ## Onde os agentes são executados
</div>

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.

<CardGroup cols={2}>
  <Card title="VM separada (padrão)" icon="server">
    Uma sessão filha completa do Devin, com sua própria máquina, clones do repo e [ambiente](/pt-BR/onboard-devin/environment/blueprints). 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.
  </Card>

  <Card title="VM compartilhada" icon="folder-tree">
    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.
  </Card>
</CardGroup>

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.

<div id="determinism-and-resuming">
  ## Determinismo e retomada
</div>

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.

<div id="cost">
  ## Custo
</div>

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](/pt-BR/essential-guidelines/when-to-use-devin) 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.

<div id="saving-a-workflow-for-reuse">
  ## Salvando um workflow para reutilização
</div>

Quando um workflow estiver funcionando, ele poderá ser comitado no seu repo como uma [skill](/pt-BR/product-guides/skills): 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.

<div id="related">
  ## Conteúdos relacionados
</div>

* [Recursos avançados](/pt-BR/work-with-devin/advanced-capabilities) — orquestre Devins gerenciados diretamente
* [Skills](/pt-BR/product-guides/skills) — salve procedimentos reutilizáveis, incluindo workflows, nos seus repos
* [Devin MCP](/pt-BR/work-with-devin/devin-mcp) — crie e monitore sessões programaticamente