Orquestração de agentes: quando é precisa e quando é peso morto
As bibliotecas de orquestração resolvem um problema real: uma execução que dura minutos, toca vários sistemas e tem de sobreviver a um reinício sem repetir o pagamento já feito. Isso é real e desagradável de resolver à mão.
Também não é o problema da maioria dos agentes. Um agente de apoio que responde em quinze segundos e pode recomeçar do zero não precisa de nada disto.
O que a orquestração dá mesmo#
- Estado durável: a execução sobrevive a um deploy, a uma falha ou a uma redução de escala.
- Passos idempotentes: uma repetição não repete um efeito já ocorrido.
- Ramos e junções: verdadeiro controlo de fluxo, não um prompt que o descreve.
- Retoma: pausa para uma aprovação humana que chega quatro horas depois.
- Observabilidade por construção: cada passo é um objeto com estado.
O teste que decide#
Uma pergunta: se esta execução morresse a meio, quanto custaria repeti-la? Se forem uns cêntimos e uns segundos, repitam — precisam de repetição, não de durabilidade. Se for um reembolso duplicado ou vinte minutos de espera de uma pessoa, precisam de passos duráveis e idempotentes.
A maioria das equipas descobre a sua resposta no primeiro deploy a meio de uma execução.
Onde aparece a complexidade#
| Aspeto | Ciclo à mão | Orquestrado |
|---|---|---|
| Desenvolvimento local | Correr o ficheiro | Mais worker e armazenamento de estado |
| Depuração | Um rasto linear | Correlacionar passos num histórico |
| Deploy a meio da execução | A execução morre | A execução retoma |
| Aprovações humanas | Desajeitado; normalmente novo pedido | Pausa e retoma de primeira classe |
| Custo de um bug no passo 3 | Correr tudo de novo | Correr só o passo 3 |
O meio-termo que muitos saltam#
Não precisam de escolher entre ciclo nu e plataforma completa. Uma fila modesta, uma linha de estado por execução e chaves de idempotência nas duas ferramentas com efeitos cobrem talvez oitenta por cento do benefício.
Perguntas frequentes
Posso usar orquestração num agente de conversa simples?
Podem, e funciona, mas pagam diariamente em atrito no desenvolvimento local por um benefício que raramente acionam.
Basta uma fila de mensagens?
Muitas vezes sim. Fila mais linha de estado por execução mais chaves de idempotência cobrem as falhas habituais.
Como manter execuções distribuídas depuráveis?
Com um identificador estável em cada linha de log, chamada e pedido de saída.
orquestração de agentesfluxos duráveismotor de fluxo llmpassos idempotentesagentes de longa duração
