O que é aqui realmente um fluxo de trabalho
A maioria das ferramentas de «fluxo de trabalho» no espaço da IA são encadeamentos de pedidos com uma camada fina por cima. O construtor do ToRun é um grafo acíclico dirigido (DAG) de passos tipados: liga invocações de modelo, chamadas de ferramentas, ramos condicionais, ciclos e subfluxos num grafo, e o motor executa-os por ordem de dependência, em paralelo onde o grafo o permite.
Cada passo é uma entidade de primeira classe com a sua própria configuração: tipo de passo (chamada LLM, pesquisa web, execução de código, geração de imagem, recuperação, transformação, etc.), esquema de entrada, política de erro (falhar depressa, repetir com espera, passar a uma alternativa), teto de orçamento de execução por passo e tempo limite.
O encaminhamento de modelo dentro de cada passo LLM passa pelo mesmo canal de capacidades de tudo o resto no ToRun. Declara o que precisa — saída estruturada, visão, uso de ferramentas, raciocínio, uma janela de contexto de pelo menos N fichas — e o executor resolve o modelo que melhor corresponde entre os fornecedores disponíveis nesse momento. Se o seu fornecedor preferido devolver um 5xx, a cadeia de recurso assume automaticamente.
Executores com prioridade à qualidade e o que isso muda na prática
Quando corre um fluxo, o executor escolhe deliberadamente modelos de nível de qualidade em vez da opção mais barata. Duas razões: as automações produzem artefactos (relatórios, conteúdo gerado, código) que ninguém revê de imediato, pelo que as falhas de qualidade se acumulam em silêncio; e a volume moderado a diferença de custo é inferior ao preço de uma saída má que obriga a repetir a execução ou a corrigir à mão.
Na prática isto significa que um fluxo de «resumir investigação e redigir um relatório» preferirá um modelo de raciocínio sólido para o resumo e um modelo de texto de alta qualidade para a redação, em vez de correr para o mínimo de preço. Pode sobrepor-se por passo se souber que aí basta um modelo leve.
A faturação segue o resto do ToRun: cada invocação de modelo dentro de um fluxo escreve exatamente um registo com um instantâneo de tarifa congelado. Uma execução que chame três modelos diferentes em cinco passos produz cinco registos. Pode auditar o custo exato de cada execução, repartido por passo, a posteriori — mesmo meses depois, quando os preços do fornecedor já se tiverem movido.
Depurar uma execução
Cada execução de fluxo produz um rasto estruturado. O rasto mostra o DAG com cada nó anotado: hora de início, hora de fim, modelo resolvido, contagem de fichas de entrada e de saída, chamadas de ferramentas efetuadas e o erro, se houve. Nos passos LLM pode expandir o pedido exato enviado e a resposta em bruto recebida.
Se um passo falhar, o rasto diz-lhe se o erro veio da chamada ao modelo (erro do fornecedor, transbordo de contexto, recusa por política de conteúdo), de uma ferramenta a jusante (tempo limite de rede, falha de validação de esquema) ou da sua própria lógica condicional. Não tem de acrescentar registo: é capturado ao nível da infraestrutura em cada execução.
Qualquer execução pode ser repetida com a mesma entrada, o que torna direto reproduzir uma falha.
Um pequeno exemplo: fluxo semanal de vigilância concorrencial
Imagine um fluxo que lança todas as segundas-feiras de manhã:
- Passo de pesquisa web — procura cobertura recente de um conjunto de palavras-chave de concorrentes e devolve uma lista de endereços e excertos.
- Passo de recuperação — traz os últimos quatro relatórios de uma base de conhecimento para fixar o contexto de partida.
- Passo de resumo (LLM) — destila os resultados de pesquisa em constatações estruturadas: novas funcionalidades, alterações de preço, anúncios relevantes.
- Passo de redação (LLM) — escreve uma nota interna concisa num estilo de casa consistente, fundamentada nas constatações resumidas.
- Passo de entrega — publica a nota para um ponto de ligação webhook configurado.
O grafo tem uma dependência natural: o passo 3 depende do 1 e do 2 (que podem correr em paralelo), o 4 depende do 3, o 5 depende do 4. O executor procede assim sem qualquer configuração explícita de paralelismo: lê as arestas.