Orquestração multiagente
Rode vários agentes. Deixe um controller decidir a ordem.
Há trabalho cuja ordem não dá para escrever de antemão. Defina type: controller, declare o que precisa ser verdade quando o run terminar, e o Dagu deixa um modelo escolher a próxima etapa de agente conforme os retornos chegam. Cada ação continua sendo uma etapa comum de workflow, com logs, retries, aprovações e histórico de auditoria.
# code-review.yaml
type: controller
llm:
provider: anthropic
model: claude-opus-5
system: |
Get top_n.py past both reviews. When a review fails, pass its finding
to revise, then ask that same reviewer again. A revision made for one
reviewer can break the other.
steps:
- name: review_simplicity
description: Judge simplicity. Prints PASS, or FAIL with what to change.
action: harness.run
with:
provider: opencode
prompt: Read top_n.py. Print "PASS" or "FAIL: <what to change>".
- name: review_correctness
description: Judge correctness. Prints PASS, or FAIL with the bug.
action: harness.run
with:
provider: codex
prompt: Read top_n.py. Print "PASS" or "FAIL: <the bug>".
- name: revise
description: Edit top_n.py to resolve one review finding.
action: dag.run
with: { dag: revise }
tasks:
- name: simplicity_passed
description: The latest simplicity review returned PASS on the current file.
- name: correctness_passed
description: The latest correctness review returned PASS on the current file.Declare critérios de conclusão, não a ordem das etapas
Toda ação é um CLI de agente real: Claude, Codex, Gemini, OpenCode
Cada tarefa se encerra como completed, skipped ou failed
Pausas à espera de resposta humana não deixam processo vivo
At a glance
Workflows controller e frameworks de agentes
Você declara os critérios de conclusão. O run termina quando nenhuma tarefa segue aberta.
Ou o modelo decide que terminou, ou todos os caminhos são desenhados antes e mantidos à mão.
Um run em espera encerra seu processo e retoma em outro.
Esperas longas normalmente significam um processo vivo e um armazenamento de estado para operar.
Agendamentos, filas, retries, artefatos e auditoria vêm do run de DAG.
Reconstruído a cada projeto, ou delegado a um control plane hospedado.
O conjunto de etapas do arquivo de workflow.
Tudo o que as definições de ferramentas permitirem.
In depth
Where each tool fits
A ordem é justamente a parte que não se escreve
Um grafo ramifica por código de saída. Ele não ramifica pelo que a revisão realmente disse. Um workflow controller mantém as ações fixas e entrega apenas o ordenamento.
- As etapas viram um catálogo de ações, então não há depends para manter
- Uma lista tasks declara o que precisa ser verdade ao fim do run
- O controller leva a constatação de um agente para os parâmetros do próximo
O modelo escolhe a ordem, nunca a capacidade
O controller escolhe apenas entre as etapas que você declarou. Ele não inventa etapa, não escreve o próprio comando de shell e não alcança nada que o arquivo não nomeie, então o raio de impacto é a definição do workflow.
- Rode cada agente no host ou em um sandbox de contêiner com montagens e regras de saída explícitas
- Dê a cada papel seu provider e modelo, para que nenhum modelo avalie o próprio trabalho
- O que passa a merecer confiança vai para um subworkflow e deixa de ser uma decisão
Os controles de produção vêm do run, não de um framework
Um run de controller é um run de DAG. Agendamentos, filas, retries, artefatos e auditoria se aplicam sem mudança, e os limites de gasto do agente são ajustes do motor, não instruções de prompt.
- ask_user suspende o run de forma durável: o processo termina e o slot do worker é liberado
- Alguém responde horas depois e o run retoma em um processo novo
- Limites de turnos, tentativas e perguntas falham o run em vez de gastar sem fronteira
Reconstrua qualquer run depois
Um controller não tem arestas de dependência, então o run é apresentado como a sequência de decisões que ele de fato tomou, e não como um grafo.
- Uma linha do tempo de decisões: uma linha por turno, com tentativas, durações e link para o run filho
- Uma visão de tarefas mostrando por que o controller encerrou cada objetivo
- A transcrição completa, incluindo cada resultado de ferramenta que o modelo viu
FAQ
Practical questions before adopting Dagu
Qual a diferença entre um workflow controller e um laço de agente?
Um laço puro deixa o modelo decidir que terminou. O controller mantém o laço, mas retoma a condição de parada: você declara as tarefas e o que significa concluído, e o run acaba quando nenhuma tarefa segue aberta.
O que acontece quando uma tarefa se revela desnecessária?
O controller a marca como skipped e registra o motivo, e o run continua bem-sucedido. Skipped e failed são estados separados porque «não havia o que fazer» e «não foi possível fazer» são desfechos diferentes em um log de auditoria.
Etapas diferentes podem usar modelos diferentes?
Sim. Cada etapa do Agent Harness nomeia seu provider e modelo, e o modelo do próprio controller é configurado à parte, então um modelo barato pode conduzir especialistas caros ou dois providers podem conferir um ao outro.
Como impedir que um run gaste sem limite?
Os limites são impostos pelo motor. Uma ação roda no máximo cinco vezes por run, um run faz no máximo cinco perguntas, e o limite de turnos é cinquenta por padrão e pode ser reduzido. Atingir um limite falha o run e nomeia o que ficou em aberto.
Quando ainda vale usar um grafo comum?
Se dá para desenhar o grafo, desenhe o grafo. type: graph segue como padrão porque é mais rápido, mais barato e reproduzível. Recorra ao controller apenas quando a ordem realmente depender do que as etapas anteriores produziram.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.