<!-- Generated from pt-BR/automate-with-workflows.html. Do not edit by hand. -->

> Markdown twin of https://conduitllm.com/pt-BR/automate-with-workflows.html
> Crie no Conduit um fluxo que acompanha as versões de um projeto, resume cada uma com um modelo de baixo custo e só avisa quando há mudanças incompatíveis.

---
Tutorial

# Como automatizar tarefas com os Fluxos de trabalho do Conduit

Atualizado em 15 de outubro de 2026

Algumas tarefas valem a pena todo dia, mas não valem a pena fazer à mão: ler um changelog, ver se uma página mudou, resumir o que chegou numa pasta. Os Fluxos de trabalho do [Conduit](https://conduitllm.com/pt-BR/), um app de IA para desktop gratuito e de código aberto, executam essas rotinas por você, num horário definido ou quando algo novo aparece, e só incomodam quando há algo para ver.

## Introdução

Um fluxo de trabalho é uma lista de etapas que rodam em ordem. Algumas etapas buscam ou leem coisas, outras pedem a um modelo que trabalhe sobre elas, e outras salvam o resultado ou avisam você. Cada etapa pode usar o que as anteriores produziram, e você pode executar a lista inteira à mão, num horário definido ou a cada vez que um feed ou uma pasta recebe algo novo.

Neste tutorial, você vai criar um fluxo de trabalho que acompanha as versões de uma ferramenta da qual você depende. O exemplo usa o [uv](https://github.com/astral-sh/uv), o gerenciador de pacotes do Python, porque ele lança versões com frequência e suas notas de versão são detalhadas. Para cada nova versão, o fluxo lê as notas, pede um resumo curto a um modelo de baixo custo, salva o resumo e envia uma notificação no desktop somente quando a versão traz mudanças que quebram a compatibilidade. Você vai testá-lo com segurança, ler o que cada etapa fez, corrigir uma etapa sem executar tudo de novo e, por fim, aprová-lo para rodar sozinho.

Você pode acompanhar com qualquer projeto no GitHub; só o endereço do feed muda.

## Principais conclusões

- Um fluxo de trabalho pode começar à mão, num horário definido (todos os dias, nos dias úteis ou a cada poucas horas), ou quando uma nova publicação aparece num feed RSS ou Atom ou um novo arquivo chega a uma pasta.
- As etapas passam resultados umas às outras por meio de valores que você insere a partir de um menu, como o link da publicação ou o texto produzido por uma etapa anterior.
- Cada etapa que usa um modelo pode escolher o seu, então o trabalho de rotina pode ir para um modelo rápido e barato.
- Uma etapa **Continuar somente se…** encerra a execução em silêncio quando não há nada que mereça a sua atenção.
- Antes de um fluxo de trabalho rodar sozinho, ele lista tudo o que terá permissão para fazer, e você aprova a lista. Qualquer coisa a mais pausa a execução e pergunta.
- Cada execução registra o que cada etapa fez, e você pode executar de novo a partir de qualquer etapa sem repetir as anteriores.
- O mesmo fluxo de trabalho pode ser desenhado como uma tela, pode se ramificar conforme uma condição e rodar etapas lado a lado, e pode passar trabalho a agentes que perguntam antes de agir.

## Pré-requisitos

Para acompanhar este tutorial, você vai precisar de:

- **O Conduit instalado** no Windows, macOS ou Linux. Baixe a versão mais recente na [página de versões](https://github.com/runningpixels/conduit/releases).
- **Um provedor de modelo configurado no Conduit** com a sua própria chave de API. Este tutorial usa o GLM 5.3 Flash pelo OpenRouter para os resumos, mas qualquer provedor serve, inclusive um modelo local. Para configurar um, siga um dos [guias de provedores](https://conduitllm.com/providers.html) (em inglês), como [Use OpenRouter in a desktop app](https://conduitllm.com/providers/openrouter.html) (em inglês).
- **Notificações do desktop permitidas** para o Conduit nas configurações do seu sistema operacional, para que você veja os alertas que o fluxo de trabalho envia.
- **(Opcional) O endereço de um feed do seu interesse.** Todo repositório do GitHub publica suas versões como um feed Atom em `https://github.com/<owner>/<repo>/releases.atom`.

## Passo 1 — Começando por um fluxo de trabalho pronto

O Conduit vem com fluxos de trabalho prontos que você pode usar como estão ou modificar. Neste passo, você vai criar um que já acompanha um feed e usá-lo como base para o monitor de versões.

Escolha **Fluxos de trabalho** na barra lateral ou pressione Ctrl+6 (⌘6 no macOS). Se você ainda não tem fluxos de trabalho, a página lista os prontos em **Nenhum fluxo de trabalho ainda**; caso contrário, escolha **Novo fluxo de trabalho** para vê-los.

A lista inclui:

- **Resumo matinal** — lê dois sites e salva as principais notícias de cada um num único resumo.
- **Acompanhar uma página** — verifica uma página e avisa você só quando ela muda.
- **Monitoramento de tema** e **Resumo semanal de pesquisa** — pesquisam um tema e mantêm um resumo atualizado.
- **Apresentação de números semanais** e **Seção do relatório mensal** — atualizam uma apresentação do Slides ou um rascunho da Escrita que você escolher.
- **Resumir novas publicações** e **Pasta de entrada** — executam uma vez para cada nova publicação de um feed ou cada novo arquivo de uma pasta.
- **Conferir notas com meus documentos** — compara um arquivo de notas com trechos das suas coleções de documentos.
- **Começar do zero** — um fluxo de trabalho vazio que você monta etapa por etapa.

Encontre **Resumir novas publicações** e escolha **Usar este**. O Conduit cria o fluxo de trabalho e abre a página dele.

O novo fluxo de trabalho já tem quatro etapas: busca a publicação, pede ao modelo que a resuma, salva o resumo e mostra uma notificação. Nada roda ainda; um fluxo de trabalho que acompanha um feed só começa a monitorar depois que você ativa **Executar automaticamente**, o que você fará no Passo 9. Antes disso, você vai apontá-lo para as versões do uv.

## Passo 2 — Apontando o fluxo de trabalho para um feed de versões

O que inicia um fluxo de trabalho é definido na seção **Começa quando**. Neste passo, você vai trocar o feed que este fluxo acompanha: sai o blog do Rust e entram as versões do uv.

Na página do fluxo de trabalho, escolha **Editar**. O cabeçalho mostra o nome do fluxo de trabalho com **Editar como JSON**, **Cancelar** e **Salvar**. As etapas ficam à esquerda; um painel lateral à direita traz **Início** (com as opções de **Começa quando**), depois **Pedido a cada execução**, **Ajudantes** e **Configurações do fluxo de trabalho**, onde você define o nome, a descrição, o provedor de modelos e a pasta.

**Observação:** Os fluxos de trabalho também podem ser mostrados como uma tela. Acima das etapas, um seletor **Tela** / **Lista** escolhe a visão, e o Conduit lembra a sua escolha. Este tutorial usa a visão em lista, então escolha **Lista** para ver os cartões de etapa que ele descreve.

Faça estas alterações:

1. Em **Configurações do fluxo de trabalho**, mude o **Nome** para `uv releases`.
2. Em **Começa quando**, deixe **uma nova publicação aparece em um feed** selecionado e defina **Endereço do feed** como `https://github.com/astral-sh/uv/releases.atom`.
3. Defina **Verificar a cada** como **360 minutos**. Um monitor de versões não precisa olhar a cada meia hora; verificar quatro vezes por dia basta.

As outras opções em **Começa quando** são **Somente quando eu executar ou em um horário**, para fluxos de trabalho que você executa à mão ou em horários definidos; **um novo arquivo aparece na pasta do fluxo de trabalho**, que exige que você escolha antes uma pasta em **Configurações do fluxo de trabalho**; e **um conector traz algo novo**.

**Observação:** Na primeira vez que o fluxo de trabalho olha o feed, ele apenas anota as versões que já estão lá. Ele não resume um acúmulo de versões antigas, só as publicadas depois que você o ativa, da mais antiga para a mais recente. Se várias chegarem de uma vez, ele inicia no máximo cinco execuções por verificação e as demais esperam a próxima.

O fluxo de trabalho agora acompanha o feed certo. A seguir, você vai ver como a primeira etapa usa a publicação que iniciou a execução.

## Passo 3 — Buscando as notas de versão

Cada execução de um fluxo de trabalho de feed trata de uma publicação, e os detalhes dela ficam disponíveis para todas as etapas como valores. Neste passo, você vai ver como a primeira etapa usa um deles para buscar as notas de versão.

Role até **Etapas**. Cada etapa é um cartão intitulado com seu número e tipo, como **1. Buscar páginas**, com um id curto ao lado, aqui `fetch`. O id é como as etapas seguintes se referem a esta.

O campo **Página 1** da etapa de busca contém um chip com o link da publicação. Valores como esse são inseridos com o menu **Inserir valor…** ao lado de cada campo, que lista o que está disponível naquele ponto do fluxo de trabalho:

- **Do gatilho** — o título, o link, o resumo, a data e o id da publicação.
- **Etapas anteriores** — o que as etapas acima produziram, como *fetch · texto da primeira página*.
- **Pedido a cada execução** — valores que você preenche ao executar o fluxo de trabalho, se adicionar algum.

Deixe a etapa de busca como está. No uv, o link de cada publicação é a página do GitHub daquela versão, então a etapa busca as notas de versão. Uma etapa de busca lê até dez páginas, guarda até 50.000 caracteres de cada uma e só busca endereços https públicos.

Repare na configuração **Se falhar, tentar novamente** no cartão: por padrão, uma busca é repetida duas vezes, o que supera um problema breve de rede. Toda etapa também tem **Continuar mesmo se esta etapa falhar**. Deixe desativada aqui; sem as notas de versão, não há o que resumir.

O fluxo de trabalho agora consegue ler cada nova versão. A seguir, você vai dizer ao modelo o que fazer com ela.

## Passo 4 — Escrevendo a etapa de resumo e escolhendo o modelo dela

Uma etapa **Perguntar ao modelo** envia uma instrução e um texto a um modelo e guarda a resposta. Neste passo, você vai escrever uma instrução adequada a notas de versão e escolher um modelo barato só para esta etapa.

Encontre a etapa 2, **Perguntar ao modelo**, com o id `summary`. Substitua a **Instrução** dela por esta:

```
Summarize these release notes for a developer who uses this tool every day.
List new features and fixes in at most five bullet points.
Then add a section titled "Breaking changes" that lists anything that could break
an existing project, such as removed options, changed defaults or new minimum versions.
If there are none, write exactly: No breaking changes.
```

O campo **Texto a processar** já contém o título da publicação seguido do texto buscado, para que o modelo saiba qual versão está lendo. Deixe como está.

A última linha da instrução importa. No Passo 6, você vai usar exatamente essa frase para decidir se avisa você, por isso o modelo é instruído a escrevê-la sempre do mesmo jeito.

Agora escolha o modelo. Em **Modelo para esta etapa**, o padrão é **Usar o modelo do fluxo de trabalho**, e a configuração **Modelo** do próprio fluxo, no topo do editor, tem como padrão **Seguir o modelo do chat**, ou seja, o último modelo que você escolheu num chat. Para um resumo de rotina, escolha em vez disso um modelo rápido e de baixo custo. Este tutorial usa o **GLM 5.3 Flash** pelo OpenRouter.

**Observação:** Escolher o modelo por etapa permite misturar modelos num mesmo fluxo de trabalho: um barato para resumos em volume, um mais forte para o texto final, ou um modelo local para etapas que lidam com arquivos privados. Se o provedor que uma etapa nomeia não estiver mais configurado, a etapa usa o modelo do chat e a execução registra a troca, em vez de falhar.

O fluxo de trabalho agora produz um resumo com uma última seção previsível. A seguir, você vai garantir que todo resumo seja guardado.

## Passo 5 — Salvando cada resumo

Uma etapa **Salvar um documento** guarda o texto como um documento que você pode abrir depois. Neste passo, você vai configurá-la para manter um documento por versão.

Encontre a etapa 3, **Salvar um documento**, e defina:

- **Título** — `uv ` seguido do chip *Título da publicação*, para que cada documento leve o nome da sua versão.
- **Conteúdo** — deixe o chip do resumo e a linha `Source:` com o link da publicação.
- **Salvar como** — **Documento**.
- **A cada execução** — **Adiciona um novo documento**.

A outra opção para **A cada execução**, **Substitui o mesmo documento**, mantém um único documento com o resultado mais recente, o que serve para acompanhar uma página ou para um resumo diário. Para um histórico de versões, você quer um documento por versão.

O salvamento vem antes da verificação que você vai adicionar a seguir, de propósito: toda versão fica registrada, até as que hoje não precisam da sua atenção.

A seguir, você vai adicionar a etapa que decide se avisa você.

## Passo 6 — Avisando só sobre mudanças que quebram a compatibilidade

Uma etapa **Continuar somente se…** verifica um valor e encerra a execução em silêncio se a verificação falhar. Neste passo, você vai adicionar uma entre o salvamento e a notificação, para ser avisado só sobre versões com mudanças que quebram a compatibilidade.

No fim de **Etapas**, abra **Adicionar uma etapa…** e escolha **Continuar somente se…**. A nova etapa é adicionada no final, então use o botão ↑ dela para movê-la acima de **Mostrar uma notificação**. Depois defina:

- **Valor a verificar** — insira *summary · texto* em **Etapas anteriores**.
- **Continuar somente se** — **não contém**.
- **Texto** — `No breaking changes`.

A comparação ignora maiúsculas e espaços extras. Os outros testes são **mudou desde a última execução**, **não está vazio**, **está vazio**, **contém** e **é igual a**; o primeiro é o que o modelo pronto **Acompanhar uma página** usa para avisar você só quando uma página muda.

Por fim, atualize a etapa 5, **Mostrar uma notificação**. Defina **Título** como `Breaking changes in uv` e **Mensagem** como o chip *Título da publicação*.

Se o modelo um dia esquecer a frase exata, a verificação deixa a notificação passar, então o pior caso é uma notificação de que você não precisava, nunca uma mudança que quebra a compatibilidade e que você deixou passar.

Escolha **Salvar**. Se algo não fechar, como uma etapa lendo um valor que ainda não existe, o editor lista o problema em **Corrija isto antes de salvar:** e mantém **Salvar** desativado até que seja corrigido. Depois de salvar, a página do fluxo de trabalho lista as cinco etapas em linguagem simples.

O fluxo de trabalho está completo. Antes de deixá-lo rodar sozinho, você vai testá-lo.

## Passo 7 — Testando o fluxo de trabalho com Executar agora

Uma execução de teste mostra exatamente o que o fluxo de trabalho vai fazer, com dados reais. Neste passo, você vai executá-lo uma vez à mão.

Na página do fluxo de trabalho, escolha **Executar agora**. Num fluxo de trabalho que acompanha um feed, uma execução manual usa a publicação mais recente do feed como teste, então você não precisa esperar a próxima versão. O botão muda para **Executando…**, aparece um botão **Interromper**, e a execução surge em **Execuções recentes** como **Execução de teste:** seguido do nome da versão.

Quase todo o tempo da execução é da etapa do modelo. Com o GLM 5.3 Flash, a execução de teste mostrada aqui levou menos de um minuto. Quando termina, o status é **Concluído** se a versão tinha mudanças que quebram a compatibilidade e você recebeu uma notificação, ou **Nada de novo** se a verificação encerrou a execução depois de salvar o resumo. Nos dois casos, **Salvo:** leva ao resumo que ela salvou.

**Observação:** Uma execução que você inicia à mão não é barrada por aprovações, porque você está lá para acompanhá-la. As aprovações, que você vai configurar no Passo 9, servem para execuções que ninguém acompanha.

Espere que um modelo julgue de forma diferente, de uma execução para outra, as versões que ficam na fronteira. A versão uv 0.12.24 foi principalmente de correções de bugs, algumas das quais deixam o uv mais rigoroso, como conferir hashes informados mesmo com a verificação de hashes desativada. Em duas execuções de teste com essa versão, o GLM 5.3 Flash ora listou essas correções como mudanças que quebram a compatibilidade, ora escreveu *No breaking changes.* Se você quiser ser avisado de mudanças assim, diga isso na instrução, por exemplo: *Count bug fixes that make uv stricter as breaking changes.*

Escolha um modelo que responda direto para etapas como esta. Um modelo que raciocina por muito tempo antes de responder pode levar muitos minutos numa página longa, e uma execução para ao atingir o limite de 30 minutos.

A seguir, você vai abrir a execução e ver o que cada etapa fez.

## Passo 8 — Lendo uma execução e repetindo uma etapa

Toda execução guarda um registro de cada etapa: o que entrou, o que saiu, qual modelo foi usado e quanto tempo levou. Neste passo, você vai ler esse registro, mudar o resumo e executar de novo apenas as etapas que precisam.

Escolha a execução de teste em **Execuções recentes**. A seção **O que esta execução fez** lista as etapas, cada uma com um status: **Concluído**, **Falhou**, **Ignorado** ou **Reutilizado**. Se a verificação encerrou a execução, aparece **Nada de novo — parou em** seguido do id da etapa, aqui `check`.

Expanda a etapa `summary`. Uma linha que começa com *Usou* nomeia o modelo e o provedor em que ela rodou, e abaixo ficam a **Entrada** e a **Saída** da etapa. Em **Salvo:**, escolha o nome do documento para abrir o próprio resumo.

Suponha que o resumo esteja mais longo do que você quer. Escolha **Editar**, troque `at most five bullet points` por `at most three bullet points` e salve. Depois abra a execução de teste de novo, encontre a etapa `summary` e escolha **Executar novamente a partir desta etapa**.

A nova execução marca a etapa de busca como **Reutilizado**: ela pega as notas de versão da execução anterior em vez de buscá-las de novo, e executa o resumo, o salvamento, a verificação e a notificação com a sua nova instrução. Na execução mostrada abaixo, a repetição levou 10 segundos, contra 16 da execução completa, porque a página não foi buscada de novo. Num fluxo de trabalho mais longo, isso economiza tempo e chamadas ao modelo.

Se uma execução falhar, a mesma tela mostra qual etapa falhou e por quê, em linguagem simples. Corrija essa etapa e execute de novo a partir dela.

O fluxo de trabalho faz o que você quer. A seguir, você vai deixá-lo rodar sozinho.

## Passo 9 — Ativando as execuções automáticas

Um fluxo de trabalho que roda sozinho precisa ser aprovado antes. Neste passo, você vai revisar o que o monitor de versões tem permissão para fazer e ativá-lo.

Na página do fluxo de trabalho, escolha o chip **Começa** abaixo da descrição (na visão de tela, selecione a etapa Início). O painel Início abre com uma seção **Agendamento**; marque **Executar automaticamente**. (**← Voltar** no painel retorna ao fluxo de trabalho.) O Conduit mostra um painel intitulado **Deixar executar sozinho?**, que lista tudo o que o fluxo de trabalho terá permissão para fazer sem perguntar. Para o monitor de versões, a lista é:

- **Ler páginas em github.com** — para ler o feed.
- **Ler páginas nos endereços que a etapa “fetch” obtiver ao ser executada** — o endereço da etapa de busca vem do feed, então o Conduit não consegue nomear o site de antemão.
- **Enviar texto para OpenRouter, online** — para a etapa de resumo.
- **Salvar documentos**.

As notificações e a verificação não precisam de aprovação. Escolha **Permitir e ativar**. A seção passa a mostrar **Monitorando github.com a cada 360 min**, e uma linha que começa com **Ao ser executado sozinho, ele pode:** mantém a lista aprovada à vista.

Se mais tarde você editar o fluxo de trabalho de modo que ele precise de algo a mais, como um site novo ou outro provedor, a página mostra **Precisa da sua aprovação para mais** com um botão **Aprovar**. Até você aprovar, uma execução automática que chega a essa etapa para e pergunta. Você recebe uma notificação, a execução mostra **Precisa de você**, e o Início a lista em **Precisa de você**. Você pode escolher **Permitir uma vez**, **Sempre permitir** ou **Não permitir**; se ninguém responder em um dia, a etapa não segue adiante.

Na primeira vez que você ativa as execuções automáticas, o Conduit também oferece **Manter em execução na área de notificação**. As execuções automáticas só acontecem enquanto o Conduit está aberto, então aceite se você costuma fechar a janela. Você pode mudar isso depois, na mesma seção, junto com **Iniciar o Conduit na área de notificação ao entrar**.

**Observação:** Para executar um fluxo de trabalho em horários definidos, e não quando um feed muda, escolha **Somente quando eu executar ou em um horário** em **Começa quando**. Então **Executar automaticamente** oferece **Todos os dias** ou **Nos dias úteis** num horário que você escolher, ou **A cada poucas horas**: a cada 1, 2, 3, 4, 6, 8, 12 ou 24 horas.

O monitor de versões agora roda sozinho. No último passo, você vai ver um jeito mais rápido de começar o próximo.

## Passo 10 — Descrevendo um fluxo de trabalho em vez de montá-lo

Você não precisa montar todo fluxo de trabalho etapa por etapa. Neste passo, você vai pedir ao Conduit que crie um rascunho a partir de uma frase.

Na página Fluxos de trabalho, escolha **Novo fluxo de trabalho**. Em **Descreva um fluxo de trabalho**, digite:

Todo dia útil às 9h, leia a página inicial do Hacker News e a página inicial do Lobsters, e salve uma única lista com as notícias sobre Rust ou Python.

Escolha **Criar rascunho**. O modelo do chat escreve um fluxo de trabalho, o Conduit o verifica do mesmo jeito que verifica um fluxo que você salva e devolve os problemas ao modelo para que os corrija. O rascunho abre no editor *sem estar salvo*: nada é salvo nem agendado até você escolher **Salvar** e ativá-lo por conta própria.

O modelo nunca escolhe o que só você pode escolher, como uma pasta, uma apresentação, ou uma coleção de documentos, e não ativa agendamentos. Quando um rascunho precisa de algum desses itens, o editor mostra **Ainda falta preencher antes de salvar** com uma lista curta. Para a descrição acima, a lista diz *Ative o agendamento: todo dia útil às 9h.*, um lembrete para definir o horário na página do fluxo de trabalho depois de salvá-lo.

Há outras duas formas de iniciar um fluxo de trabalho a partir de palavras:

- **Pelo Início.** Digite o que você quer na caixa de pergunta e escolha o chip **Automatizar**; o Conduit abre os Fluxos de trabalho e cria o rascunho.
- **Por um chat.** Depois de fazer algo à mão num chat, abra a paleta de comandos com Ctrl+K (⌘K no macOS) e escolha **Salvar chat como fluxo de trabalho…**. O rascunho se baseia no que você pediu e nas ferramentas usadas; o modelo não vê as páginas nem os documentos em si.

Seja como for, revise o rascunho, teste-o com **Executar agora** e só então ative **Executar automaticamente**.

## Indo além: tela, ramificações e agentes

O monitor de versões é uma linha reta, mas um fluxo de trabalho não precisa ser. Quatro recursos se apoiam no que você acabou de fazer.

- **A tela.** Escolha **Tela** na visão das etapas para ver o início, cada etapa, os laços e as linhas entre eles. Durante uma execução, cada etapa mostra se está rodando, concluída, com falha, ignorada ou esperando por você, e selecionar uma etapa mostra a entrada e a saída dela. No editor, você pode adicionar etapas a partir de uma paleta, arrastá-las para reordenar e arrastar um fio de uma etapa a outra para escolher qual saída entra em qual campo, em vez de digitar.
- **Ramificações e etapas lado a lado.** Uma etapa **Se… senão** leva a execução por um caminho de sim ou de não; o caminho não seguido é registrado como *Não seguido*. Uma etapa pode esperar por várias etapas anteriores, então as etapas que não dependem umas das outras rodam lado a lado, até quatro ao mesmo tempo, e uma etapa posterior pode reuni-las. Trocar a etapa **Continuar somente se…** do monitor de versões por uma ramificação, por exemplo, poderia notificar por um caminho e apenas salvar pelo outro.
- **Resultados.** Tudo o que uma execução concluída salvou fica guardado, com uma prévia. Abra a aba **Resultados** de um fluxo de trabalho, ou a lista Resultados na barra lateral de Fluxos de trabalho para todos os fluxos, e use **Abrir** para ler.
- **Agentes.** Uma etapa **Deixar o modelo usar ferramentas** pode usar até dez ferramentas de conector e passar tarefas a ajudantes que você define, cada um com suas próprias instruções, modelo e limite de tokens. Uma ferramenta de conector que envia, publica ou altera algo pausa a execução e pergunta, e a **Caixa de entrada** reúne tudo o que seus fluxos de trabalho estão esperando. Com **Configurações → Computador** ativado, um agente também pode executar comandos e alterar arquivos em uma pasta que você indicar, e todo comando pergunta antes, a menos que uma regra que você permitiu o cubra. A [documentação dos Fluxos de trabalho](https://conduitllm.com/pt-BR/docs.html#workflows) lista os limites.

## Todos os tipos de etapa num relance

O monitor de versões usa cinco tipos de etapa. Aqui estão todos eles, como aparecem no menu **Adicionar uma etapa…**:

| Etapa | O que faz |
| --- | --- |
| Buscar páginas | Lê até dez páginas da web, inclusive PDFs. Até 50.000 caracteres por página. |
| Pesquisar na web | Pesquisa com o backend de busca escolhido em Configurações e devolve até 20 resultados. |
| Ler um arquivo | Lê um arquivo de texto, Markdown, CSV, JSON, PDF ou Word da pasta do fluxo de trabalho, e de nenhum outro lugar. |
| Transformar texto em tabela | Transforma CSV, TSV ou JSON em linhas e colunas que as etapas seguintes podem usar. |
| Pesquisar um assunto | Executa uma Pesquisa Rápida ou Padrão e produz um relatório com citações. |
| Pesquisar nos meus documentos | Encontra os trechos que melhor correspondem a uma consulta nas coleções de documentos que você escolher. |
| Usar um conector | Chama uma ferramenta de um dos seus conectores (servidores MCP). As ferramentas que apenas leem rodam sozinhas; uma ferramenta que envia, publica ou altera algo pausa a execução e pergunta. |
| Perguntar ao modelo | Envia uma instrução e um texto a um modelo, sem ferramentas, e guarda a resposta. |
| Deixar o modelo usar ferramentas | Deixa o modelo pesquisar na web, ler páginas, consultar a hora, fazer contas, usar ferramentas de conector e passar tarefas a ajudantes algumas vezes antes de responder. Ele também pode executar comandos e alterar arquivos na pasta do fluxo de trabalho, se você ativar isso. |
| Atualizar uma apresentação | Altera uma apresentação do Slides que você escolher, conforme a instrução. O texto fixado nunca é alterado, e a alteração pode ser desfeita. |
| Atualizar um rascunho | Altera um rascunho da Escrita que você escolher, do mesmo jeito. |
| Escrever texto | Junta valores de etapas anteriores num único texto, sem um modelo. |
| Repetir para cada item | Executa as etapas que estão dentro dela uma vez para cada item de uma lista, até 50 itens. |
| Salvar um documento | Salva um documento ou uma página da web no Conduit, seja um novo a cada execução ou o mesmo substituído. |
| Salvar um arquivo | Grava um arquivo Markdown, de texto, CSV, JSON ou HTML na pasta de exportações do Conduit. |
| Sugerir uma memória | Sugere algo para a Memória. Nada é lembrado até você aceitar. |
| Me perguntar | Pausa a execução para fazer uma pergunta a você, com opções ou uma resposta digitada, e um padrão caso ninguém responda. |
| Mostrar uma notificação | Mostra uma notificação no desktop, opcionalmente só quando ela difere da última execução. |
| Continuar somente se… | Encerra a execução em silêncio, como *Nada de novo*, a menos que um valor passe numa verificação. |
| Se… senão | Leva a execução por um caminho de sim ou de não, com as mesmas verificações. As etapas do outro caminho são registradas como *Não seguido*. |

Um fluxo de trabalho pode ter até 50 etapas. Todo campo de texto de toda etapa pode incluir valores inseridos, e a definição inteira pode ser editada à mão com **Editar como JSON** no editor. Nessa visualização, os valores inseridos são escritos como `{{steps.summary.text}}` ou `{{trigger.link}}`; para escrever as próprias chaves, coloque uma barra invertida antes delas: `\{{`.

Para referência, este é o monitor de versões que você criou, como a visualização JSON o mostra:

```
{
  "steps": [
    {
      "id": "fetch",
      "type": "fetch_page",
      "urls": [
        "{{trigger.link}}"
      ]
    },
    {
      "id": "summary",
      "input": "{{trigger.title}}\n\n{{steps.fetch.text}}",
      "model": {
        "model": "z-ai/glm-5.3-flash",
        "provider": "openrouter"
      },
      "prompt": "Summarize these release notes for a developer who uses this tool every day.\n…",
      "type": "summarize"
    },
    {
      "content": "{{steps.summary.text}}\n\nSource: {{trigger.link}}",
      "id": "save",
      "mode": "create",
      "title": "uv {{trigger.title}}",
      "type": "save_artifact"
    },
    {
      "id": "check",
      "is": "not_contains",
      "text": "No breaking changes",
      "type": "condition",
      "value": "{{steps.summary.text}}"
    },
    {
      "body": "{{trigger.title}}",
      "id": "notify",
      "title": "Breaking changes in uv",
      "type": "notify"
    }
  ],
  "trigger": {
    "everyMinutes": 360,
    "kind": "feed",
    "url": "https://github.com/astral-sh/uv/releases.atom"
  }
}
```

## Perguntas

**Um fluxo de trabalho roda com o Conduit fechado?**

Não. As execuções agendadas e automáticas acontecem enquanto o Conduit está aberto. Para mantê-las depois de fechar a janela, ative **Manter em execução na área de notificação ao fechar a janela** na seção **Agendamento** do fluxo de trabalho e, se quiser, **Iniciar o Conduit na área de notificação ao entrar**. Uma execução agendada perdida enquanto o Conduit estava fechado acontece uma vez, na próxima vez que ele for iniciado, e não uma vez para cada horário perdido.

**Quanto custa executar um fluxo de trabalho?**

O Conduit é gratuito. As etapas que buscam páginas, leem arquivos, verificam condições, salvam documentos ou mostram notificações não chamam um modelo e não custam nada. As etapas que consultam o modelo são cobradas pelo seu provedor, na sua própria chave, como qualquer mensagem de chat. Cada execução é limitada a 30 minutos de tempo de execução e 500.000 tokens do modelo, e para com uma mensagem se passar disso. Toda chamada ao modelo feita por um fluxo de trabalho fica registrada em **Configurações → Uso e custo**.

**Um fluxo de trabalho pode alterar coisas nos meus outros apps?**

Sim, com a sua aprovação. Uma etapa **Usar um conector** roda sozinha as ferramentas que apenas leem, como listar issues ou ler uma agenda. Uma ferramenta que envia, publica ou altera algo pausa a execução e mostra a chamada exata, e você escolhe **Enviar**, **Editar** ou **Não enviar**; você pode permitir uma ação daí em diante nesse fluxo de trabalho. Dentro do Conduit, um fluxo de trabalho pode salvar documentos e arquivos, sugerir uma memória para você aceitar e atualizar uma apresentação do Slides ou um rascunho da Escrita que você escolher. As atualizações nunca mexem no texto que você fixou, e **Desfazer esta atualização** na execução devolve a apresentação ou o rascunho ao que era.

**Uma página da web pode assumir o controle de um fluxo de trabalho?**

Uma página buscada é texto sobre o qual as etapas seguintes trabalham; ela não consegue adicionar etapas nem mudar aprovações. Uma etapa **Perguntar ao modelo** não tem ferramenta nenhuma, então uma página com instruções não consegue fazê-la buscar, pesquisar nem salvar nada. Uma etapa **Deixar o modelo usar ferramentas** trata o que lê da web como dado, não como instrução, e só tem as ferramentas somente leitura que você marcar. Uma execução que ninguém acompanha só pode fazer o que você aprovou ao ativar as execuções automáticas.

**Posso compartilhar um fluxo de trabalho com outra pessoa?**

Ainda não há botão de importar ou exportar. Você pode copiar um fluxo de trabalho à mão: escolha **Editar**, depois **Editar como JSON**, e copie a definição. A outra pessoa cria um fluxo de trabalho a partir de **Começar do zero**, abre **Editar como JSON** e cola. As aprovações não fazem parte da definição, então ela aprova de novo antes de o fluxo rodar sozinho.

**Posso usar um modelo local?**

Pode. Escolha um modelo do Ollama ou do LM Studio como o modelo do fluxo de trabalho ou em **Modelo para esta etapa**. No modo somente local, uma etapa que nomeia um provedor na nuvem falha com uma mensagem dizendo isso, em vez de enviar texto pela internet.

## Conclusão

Neste tutorial, você criou um fluxo de trabalho que acompanha as versões do uv: ele busca as notas de cada nova versão, as resume com um modelo de baixo custo, salva cada resumo e avisa você só sobre mudanças que quebram a compatibilidade. Você o testou com uma versão real, leu o que cada etapa fez, executou-o de novo a partir da etapa que mudou e aprovou exatamente o que ele pode fazer sozinho.

O mesmo padrão de buscar algo, perguntar ao modelo sobre isso, guardar o resultado e só alertar você quando importa serve para muitas rotinas. Experimente apontar uma cópia para as versões de cada ferramenta de que o seu projeto depende, usar **Acompanhar uma página** numa página de preços ou de status, ou deixar a **Pasta de entrada** resumir cada arquivo que você solta numa pasta. Para ir além, veja estes guias:

- [A documentação dos Fluxos de trabalho](https://conduitllm.com/pt-BR/docs.html#workflows), com todas as configurações e limites.
- [Como fazer uma pesquisa aprofundada com o Conduit e o Exa](https://conduitllm.com/pt-BR/research-with-exa.html), para conhecer as Pesquisas que a etapa **Pesquisar um assunto** de um fluxo de trabalho usa.
- [Os guias de provedores](https://conduitllm.com/providers.html) (em inglês), para escolher e configurar os modelos que os seus fluxos de trabalho usam.

[Baixar o Conduit](https://github.com/runningpixels/conduit/releases)

Os detalhes do Conduit correspondem à versão mais recente e podem ser conferidos na [documentação](https://conduitllm.com/pt-BR/docs.html) e no [código-fonte](https://github.com/runningpixels/conduit). Encontrou um erro? [Conte para a gente](https://github.com/runningpixels/conduit/discussions) e nós corrigimos.

## Relacionados

- [Como fazer uma pesquisa aprofundada com o Conduit e o Exa](https://conduitllm.com/pt-BR/research-with-exa.html) — Ative a busca do Exa, escreva o resumo da pesquisa e leia um relatório com fontes citadas no Conduit, com células solares como exemplo. Sem chave do Exa.
- [Como demonstrar um servidor MCP para um cliente](https://conduitllm.com/pt-BR/mcp-distribution.html) — Hospedar um servidor MCP não é uma demo para o cliente. Comparação entre chat hospedado, Claude Desktop com extensão e seu próprio cliente desktop.