Padrões de orquestração multi-agente e melhores práticas

A orquestração generativa também suporta sistemas multi-agente, onde um agente chama outros agentes. Quando divides os problemas em vários agentes especializados, tornas a tua aplicação mais modular, escalável e gerível.

Agentes inline

Os agentes inline, também conhecidos como agentes de elemento subordinado, são pequenos fluxos de trabalho reutilizáveis dentro do mesmo agente. Muitas vezes são apenas tópicos que o agente principal usa como sub-rotinas. Por exemplo, o agente principal pode chamar um tópico "Traduzir Texto" como um passo num plano maior. Os agentes inline partilham o contexto com o agente principal, por isso a passagem de dados entre eles é simples.

Boa prática: Mantenha os agentes em linha centrados numa única responsabilidade e teste-os bem.

Agentes conectados

Agentes conectados são agentes separados com sua própria orquestração, ferramentas e conhecimento. O agente principal delega parte de um pedido a um agente infantil. Por exemplo, um agente de TI liga a um agente de vendas para obter informações sobre preços. Os agentes ligados permitem modularidade e separação de domínios, podendo contornar os limites do plano. Podem ter privilégios ou conhecimentos diferentes, por isso aplicam controlos de governação e auditoria.

No entanto, a utilização de agentes ligados requer uma governação cuidadosa:

  • Orquestração: O orquestrador principal deve ter critérios claros para quando transferir para um agente conectado. O orquestrador normalmente faz a entrega quando a intenção do utilizador corresponde ao domínio do agente ligado. Para ajudar neste processo, descreva claramente o propósito do agente ligado na configuração do progenitor. Trate todo o agente ligado como uma "ferramenta" por meio de agentes com uma descrição, da perspetiva do elemento principal.

  • Transferência de dados: Deve gerir a transferência de dados. Decida que contexto do elemento principal deve ser passado para o agente ligado. O Copilot Studio transmite o histórico de conversas por defeito quando um agente liga a outro, para que o agente ligado compreenda o contexto anterior da conversa. Mas talvez também precises de cumprir parâmetros específicos. Por exemplo, se o agente principal já souber o nome do utilizador de antes, pode enviá-lo para o agente ligado para evitar perguntar novamente.

  • Segurança: O agente conectado pode ter acesso a coisas que o agente principal não tem. Certifique-se de que ligar ao agente ligado não contorna inadvertidamente as restrições. Por exemplo, se o agente principal não tiver permissão para eliminar registos mas o agente conectado tiver, o agente principal não deve chamar o agente conectado em cenários onde a eliminação possa ocorrer sem uma prévia autorização apropriada. Trate uma chamada de agente ligado como qualquer outra ação avançada. Se estiver a fazer algo sensível, sujeitem-no às verificações necessárias ou ao consentimento do utilizador.

  • Auditoria e monitorização: Registe quando um agente ligado foi invocado e o que ele fez. Como é um agente separado, tem transcrições separadas para esse agente. É importante para a depuração correlacionar as sessões principais e as sessões ligadas. Normalmente, identificadores na telemetria ligam os dois.

Quando separar os agentes

Não cries um agente separado para cada subtarefa. Utilize agentes separados se a subtarefa:

  • É suficientemente complexo para ter o seu próprio conjunto de ferramentas ou conhecimentos (área de especialização diferente)
  • Requer regras de governação ou controlos de acesso diferentes do agente principal
  • Puder ser reutilizada em muitos agentes principais diferentes (funcionando como um agente de serviço)

Se nenhuma dessas condições se aplicar, um agente em linha simples pode dar conta da tarefa, além de ser mais simples do que um agente conectado. Agentes separados introduzem sobrecarga no sistema. O tempo de execução é ligeiramente mais longo devido à troca de contexto e à complexidade na manutenção de múltiplos agentes. Por isso, usa-os com discernimento. Para uma abordagem prática, comece por um único agente. Depois, só se divide em múltiplos agentes quando se vê claramente necessidade de modularidade ou um limite que um único agente não deve ultrapassar.

Melhores práticas para orquestração multi-agente

As seguintes boas práticas aplicam-se ao criar instruções para o pai e subagentes numa configuração multi-agente.

1. Princípio da resposta única

Garante que só um agente fala com o utilizador por turno. Numa configuração multi-agente, o agente principal é o único que deve fornecer a resposta final. Os subagentes são investigadores, não respondedores.

  • Faça: adicione às instruções principais: "És o único agente que comunica com o utilizador. Combina as conclusões de todos os agentes de elemento subordinado numa única resposta."
  • Não: Deixe ambíguo. Sem orientação explícita, os subagentes respondem diretamente ao utilizador, causando mensagens duplicadas ou parciais.

2. As instruções do subagente devem declarar o seu papel

Diz sempre aos subagentes que são subagentes. Os subagentes não sabem inerentemente que fazem parte de uma orquestração. Sem orientação explícita, comportam-se como agentes autónomos e enviam mensagens diretamente ao utilizador.

  • Faça: Adicione às instruções de cada subagente: "És um subagente. NÃO responda diretamente ao utilizador. O seu trabalho é procurar informações e enviar as suas conclusões ao agente parental. O agente principal trata de toda a comunicação com o utilizador."
  • Não: Assumir que os subagentes descobrem o padrão de orquestração por si próprios.

3. Use uma linguagem clara e direta nas instruções

Use sempre uma linguagem diretiva. Evite frases suaves ou educadas. A plataforma injeta instruções ao nível do sistema usando linguagem forte (DEVE, NÃO, NUNCA). Instruções escritas com linguagem suave ("por favor tente", "deveria", "seria bom fazê-lo") perdem prioridade quando entram em conflito.

  • Faça: "NUNCA responda diretamente ao utilizador. APENAS apresente as suas conclusões.
  • Faz: "Deve haver exatamente uma resposta final por pergunta do utilizador."
  • Não: "Por favor, tente evitar enviar mensagens ao utilizador e, em vez disso, devolva as suas descobertas."
  • Não faça: "Idealmente, queremos uma única resposta combinada."

4. Utilizar uma fonte de conhecimento por subagente (sem sobreposição)

Atribuir fontes de conhecimento distintas e não sobrepostas a cada subagente. Se dois subagentes pesquisarem na mesma base de conhecimento, um dos subagentes encontra a resposta primeiro. O segundo subagente ou devolve resultados duplicados ou ignora completamente a sua pesquisa, sem acrescentar valor.

  • Faz: O CA-1 procura na Fonte de Conhecimento A (por exemplo, políticas de RH). O CA-2 pesquisa na Fonte de Conhecimento B (por exemplo, documentação de TI).
  • Não o faças: Dá a ambos os subagentes acesso aos mesmos documentos, tabelas Dataverse ou SharePoint sites.
  • Nota: Se só tiver uma fonte de conhecimento, use um único agente com conhecimento em vez de dividir em dois subagentes. A abordagem multiagente só tem valor quando as fontes são genuinamente diferentes.

5. Utilizar descrições precisas e distintas para subagentes

Escreva descrições claras e distintas para cada subagente visível para o pai. O agente principal usa descrições de subagentes para determinar o encaminhamento. Se as descrições forem vagas, idênticas ou imprecisas, o pai não consegue tomar boas decisões de encaminhamento.

  • Faça: CA-1: "Pesquisa documentos de política de RH para questões relacionadas com o funcionário." CA-2: "Pesquisa na base de conhecimento de TI para questões de suporte técnico."
  • Não: Dê a ambos os agentes a mesma descrição quando servem domínios diferentes.
  • Não faça: Use descrições genéricas como "Este agente pode ajudar com dúvidas."

6. As instruções principais devem definir o padrão de orquestração

Diga ao agente principal como orquestrar. Não digas apenas "usa agentes infantis". O pai precisa de instruções explícitas sobre o padrão: invocar agentes, esperar pelos resultados, combinar e depois responder.

  • Faça o seguinte: "Quando o utilizador coloca uma pergunta: 1. Invoca ambos os agentes de elemento subordinado para recolher informações. 2. Aguarda que ambos os agentes de elemento subordinado devolvam as suas conclusões. 3. Combine os resultados numa resposta única e unificada. 4. Dê apenas uma resposta ao utilizador. Agentes crianças não devem responder diretamente ao utilizador."
  • Não faça: "Quando o utilizador fizer uma pergunta, invoca os agentes de elemento subordinado, obtém as respostas de ambas as origens e fornece uma única resposta combinada." (Demasiado vago. A instrução não diz aos subagentes para permanecerem em silêncio.)

7. Incluir a diretiva de não responder diretamente ao delegar a tarefa

Mesmo com instruções claras para subagentes, adicionar reforço na tarefa delegada proporciona uma rede de segurança.

  • Faça: Adicione às instruções dos pais: "Ao delegar a um agente infantil, inclua sempre na tarefa: 'Devolva apenas as suas conclusões. Não respondas ao utilizador.'"
  • Não: Confiar apenas nas instruções do próprio subagente. O contexto da tarefa dá ao subagente mais sinais que reforçam o padrão.

8. Testar com consultas que não correspondem ao domínio

Teste sempre com perguntas que não correspondam ao domínio de nenhum subagente. Este teste revela se os subagentes devolvem corretamente "nenhuma informação encontrada" ou se devolvem informações que possam estar incorretas, ficam bloqueados ou enviam mensagens confusas.

  • Fazer: Testar com consultas fora de todos os domínios dos subagentes (por exemplo, perguntar sobre o tempo quando os agentes tratam de RH e TI).
  • Faça: Verifique se o elemento principal processa corretamente "nenhum dos agentes encontrou informação".
  • Não faça: Teste apenas com consultas de caso simples que correspondam perfeitamente ao domínio de um subagente.

9. Prefira perguntar em vez de informar quando se espera uma resposta de seguimento

Use interações do tipo pergunta/pergunta ao esperar que o utilizador responda. Utilize o estilo inform/send apenas para mensagens finais unidirecionais. Se o agente perguntar algo ao utilizador através de uma mensagem unidirecional (informar), a resposta do utilizador volta para o planeador principal como uma consulta totalmente nova. Neste caso, é melhor continuar a mesma conversa com o subagente.

  • Faça: Escreva instruções como: "Se precisar de esclarecimentos, faça uma pergunta ao utilizador e espere pela resposta dele."
  • Não: Escreva instruções como: "Informe o utilizador sobre as opções e deixe-o escolher." "Informar" sinaliza uma mensagem unidirecional, enquanto "perguntar" indica uma troca bidirecional.

Lista rápida de referências

# Verificar
1 As instruções do elemento principal declaram explicitamente: "só eu é que respondo ao utilizador"
2 Todas as instruções do subagente dizem "não responder diretamente ao utilizador"
3 As instruções usam uma linguagem diretiva forte (DEVE, NUNCA, SOMENTE)
4 Cada subagente tem uma fonte de conhecimento única e não sobreposta
5 As descrições dos subagentes são precisas, distintas e específicas
6 As instruções principais definem o padrão completo de orquestração (invocar → esperar → combinar os resultados → responder)
7 O elemento principal transmite "sem resposta direta" no contexto da tarefa delegada
8 Testado com consultas de desajuste de domínio
9 A distinção entre perguntar e informar está correta nas instruções do subagente
  • Last updated on