É importante ponderar cuidadosamente como e onde são tomadas as decisões no seu sistema baseado em agentes.
Delegar mais decisões a um LLM permite que o sistema possa generalizar para mais tarefas, mas pode comprometer a velocidade, a fiabilidade e a robustez.
Sempre que possível, tente transferir o máximo possível do processo de decisão do LLM para código de software explícito. Isto é especialmente importante em fluxos de trabalho de alto risco e/ou em produção.
Ao conceber um sistema baseado em agentes e em LLM, uma das decisões mais importantes é determinar até que ponto o processo de decisão fica integrado num modelo LLM ou em software explícito.
Para facilitar a compreensão, podemos encarar esta escolha como um espectro entre as seguintes abordagens:
As arquiteturas baseadas em router definem explicitamente a ordem e a lógica no código, assegurando testabilidade, previsibilidade e robustez em tarefas de domínio restrito (também são chamadas «agentes de fluxo de trabalho»).
Os agentes orquestradores recorrem a modelos de linguagem de grande dimensão (LLM) para decidir dinamicamente os fluxos das tarefas através de instruções em linguagem natural. São ideais para interações abertas em que a lógica predefinida é insuficiente ou impossível.
Para fluxos de trabalho de alto risco em produção, recomendamos geralmente mais funcionalidades baseadas em router, reservando os orquestradores para aplicações que exijam conversas flexíveis e generalistas.
Arquiteturas baseadas em router
Os sistemas de agentes baseados em router:
Definem explicitamente o fluxo de decisão através de código ou software e utilizam um LLM para determinar o percurso seguido pelo software.
Aproximam-se dos sistemas de software tradicionais, pois têm percursos claros e previsíveis que produzem resultados mais consistentes.
São ideais para tarefas que podem ser definidas de forma rigorosa.
Segue-se um exemplo simplificado de um agente de reservas de uma companhia aérea que utiliza a «abordagem de router». Embora o LLM ajude a classificar a intenção da pergunta entre três opções possíveis, é o software que, em última análise, associa essa intenção a uma resposta de texto predefinida. Como o LLM está sujeito a fortes restrições, o utilizador terá uma experiência mais consistente.
Arquiteturas de orquestrador
Ao contrário dos sistemas baseados em router, os sistemas de agentes com orquestrador:
Definem fluxos lógicos através de instruções em linguagem natural, em vez de software. Nota: em comparação com uma linguagem de programação, a linguagem natural é inerentemente ambígua e flexível — características simultaneamente positivas e negativas, como veremos adiante. Encaramos isto como «intenção em vez de instrução».
Podem disponibilizar várias opções de processamento, cabendo ao LLM determinar a ordem e o método de execução.
Podem criar dinamicamente novos percursos lógicos difíceis de definir explicitamente em software.
Esta ambiguidade pode gerar resultados inconsistentes, mas, quando funciona, pode parecer «mágica».
O exemplo seguinte aplica uma abordagem de orquestrador ao mesmo problema simplificado da companhia aérea. Em vez de deixar o software decidir qual é a resposta adequada, o processo de decisão é delegado à camada do LLM. Temos aqui um sistema multiagente no qual um agente orquestrador «principal» faz a triagem do pedido do utilizador e o encaminha para um agente concebido especificamente para alterar voos, que acaba por responder ao utilizador.
Neste exemplo, a camada do LLM desempenha as funções de classificador, router e redator da resposta. No exemplo do router, desempenhava apenas a função de classificador, ficando o restante a cargo do software.
Sempre que possível, recomendamos abordagens baseadas em router, pois oferecem as seguintes vantagens:
Velocidade e eficiência: os cálculos locais são mais rápidos do que os orquestradores dependentes de API externas. Também é muito mais barato processar a lógica «IF/ELSE» em Python do que pagar a um fornecedor de LLM para a fazer passar pelo seu modelo de 400 mil milhões de parâmetros.
Testabilidade e previsibilidade: são significativamente mais fáceis de depurar, testar e manter através de práticas de software consolidadas.
Transparência e fiabilidade: uma menor variação do comportamento simplifica a resolução de problemas. Uma maior percentagem do fluxo da aplicação fica também expressa em software transparente e sujeito a controlo de versões, em vez de nos pesos opacos e indecifráveis de um LLM.
As desvantagens das abordagens baseadas em router são a rigidez, a falta de flexibilidade e a dificuldade em lidar com problemas mais abertos. Um chatbot que dê sempre exatamente as mesmas respostas pode ser considerado aborrecido ou estagnado pelos utilizadores.
As arquiteturas de orquestrador têm capacidades poderosas:
Planeamento: podem planear respostas dinamicamente.
Seleção de ferramentas/transferência para agentes: selecionam as ferramentas adequadas ou delegam tarefas em agentes.
Combinação iterativa de resultados: iteram e recombinam resultados de forma criativa.
Determinação da conclusão: determinam quando já foi recolhida informação suficiente para finalizar uma resposta.
A utilização de frameworks como Pydantic-AI ou o Agents SDK da OpenAI torna a orquestração simples e rápida de implementar. Por isso, esta abordagem é excelente para demonstrações ou provas de conceito.
As desvantagens desta abordagem são as seguintes:
Não há garantias de que as etapas de planeamento do LLM e as ações subsequentes sejam corretas ou adequadas. O sistema baseado em router tem o mesmo problema, mas, por ser mais limitado, o seu comportamento é mais previsível.
Para tarefas simples e bem definidas, é pouco provável que precisemos de toda a capacidade de um sistema multiagente. Por exemplo, no caso do nosso agente de companhia aérea, provavelmente existe apenas um número limitado de tipos de pedidos que alguém pretende fazer ao interagir com um sistema de apoio de uma companhia aérea.
Como contém mais lógica no LLM, torna-se muito mais suscetível a ataques de jailbreak ou a outras formas de exploração por agentes mal-intencionados.
Abstrai o processo de decisão para o LLM, dificultando a compreensão do sistema, embora ferramentas de monitorização como Langfuse ou Braintrust possam ajudar parcialmente.
Nota ao leitor: embora as capacidades dos modelos estejam a evoluir rapidamente, é pouco provável que os pontos abaixo se alterem num futuro próximo.
Determine o âmbito do problema.
Consegue definir facilmente num diagrama a lógica de decisão pretendida?
A sua aplicação não pode tolerar falhas nem comportamentos inesperados?
Responder «sim» a qualquer uma das perguntas anteriores sugere que as funcionalidades de router seriam mais adequadas.
Sempre que possível, recomendamos abordagens baseadas em router enquanto forem suficientes. Como princípio geral, se uma parte do sistema puder ser expressa em código, deve sê-lo — ou seja, não utilize LLM em excesso quando não forem necessários.
Quando estas abordagens atingem os seus limites, algumas das vantagens abertas dos orquestradores podem ser reproduzidas de forma controlada. Por exemplo:
Seleção de ferramentas/transferência para agentes: pode ser facilmente implementada através de ramificações condicionais ou classificadores LLM.
Determinação da conclusão: classificadores LLM simples podem verificar se a resposta está completa antes de a devolver ao utilizador.
Contudo, o «planeamento» e a «combinação iterativa de resultados» são indubitavelmente muito mais difíceis de conseguir num sistema rígido baseado em router. Assim, quando uma tarefa exigir estas capacidades — conforme determinado por um classificador LLM ou por outra lógica —, sugerimos criar no sistema uma ramificação de orquestrador com menos restrições.
A escolha entre arquiteturas de router e de orquestrador deve refletir a clareza, a complexidade e o estilo de interação da aplicação. Atualmente, as abordagens baseadas em router oferecem fiabilidade, eficiência e facilidade de teste em tarefas claramente definidas. Os orquestradores oferecem maior flexibilidade em interações conversacionais mais abrangentes.
À medida que os LLM continuam a evoluir, o equilíbrio entre estas abordagens poderá mudar. Para cargas de trabalho em produção, preferimos arquiteturas baseadas em router ou híbridas e reservamos os orquestradores para problemas abertos que exijam uma interação dinâmica e semelhante à humana.