Laços multi-agente são barulhentos. Aqui está como limpá-los.

Você provavelmente já se deparou com este cenário:
Você ativa um grupo de agentes para resolver uma tarefa complexa—talvez pesquisando um tópico, auditando código ou extraindo dados estruturados. Você espera um resultado limpo e unificado. Em vez disso, você recebe três versões da mesma frase, quatro resumos ligeiramente diferentes do mesmo bloco JSON e ruído redundante suficiente para estourar seu orçamento de tokens.

A questão central geralmente não é a qualidade individual dos LLMs; é a falta de coordenação na camada de saída. Em arquiteturas de múltiplos agentes, a redundância não é apenas irritante—é cara e tecnicamente obstrutiva. Se o Agente A e o Agente B ambos concluem que 'A migração do banco de dados falhou devido a um tempo limite', ter ambas as declarações na sua janela de contexto final não adiciona sinal. Apenas adiciona entropia.

Eu vi equipes construírem enormes quantidades de código Python personalizado apenas para deduplicar essas respostas. Elas escrevem padrões regex, implementam bibliotecas de correspondência de strings difusas e passam mais tempo depurando sua lógica de deduplicação do que melhorando seu raciocínio agente. Isso se torna mais um pedaço frágil de infraestrutura que precisa de manutenção sempre que a verbosidade do modelo muda.

Precisávamos de uma maneira de tratar a reconciliação de saída como um primitivo padrão, em vez de um pensamento posterior. É exatamente por isso que construímos o deduplicador de saída de agente.

Além da Correspondência Simples de Strings

Uma abordagem ingênua para esse problema é verificar se string_a == string_b. Mas os agentes raramente produzem strings idênticas, mesmo quando dizem a mesma coisa exatamente. Um pode usar um ponto de bala; outro pode usar uma frase completa.

Para tornar isso útil para cargas de trabalho de engenharia reais, você precisa de matemática. Especificamente, você precisa de medidas de similaridade que lidem com sobreposição semântica sem exigir modelos de incorporação pesados para cada comparação.

O deduplicador aproveita a similaridade de Jaccard e a sobreposição de n-gramas (especificamente $n=2$ e $n=3$). Ao olhar para conjuntos de sequências de palavras que se intersectam em relação ao total de sequências únicas, ele identifica clusters de informações que representam o mesmo fato subjacente, independentemente de variações sintáticas menores.

Como o Conjunto de Ferramentas Opera

O servidor MCP expõe três ferramentas principais projetadas para se encaixar em diferentes estágios de um fluxo de trabalho agente:

1. get_similarity_score: Este é seu probe de baixo nível. Se você quiser verificar programaticamente se duas peças específicas de evidência são efetivamente duplicatas antes de decidir se deve mesclá-las ou descartar uma, isso lhe dá essa certeza matemática.

2. identify_duplicates: Isso lida com o trabalho mais pesado. Em vez de comparar pares manualmente, você alimenta uma coleção inteira de saídas—digamos, tudo coletado durante um loop de pesquisa de longa duração—e ele escaneia em busca de clusters de informações redundantes. Você pode passar um limite personalizado (entre 0 e 1) aqui; mais alto significa uma adesão mais rigorosa à singularidade, mais baixo permite um agrupamento mais agressivo.

3. resolve_canonical_selection: Uma vez que você sabe que as coisas são redundantes, o que você realmente faz com elas? A maioria das pessoas pensa que deve apenas escolher uma aleatoriamente ou pegar a mais curta. Isso é uma má prática porque alguns agentes são inerentemente melhores em certas tarefas do que outros.
   A ferramenta de resolução permite que você escolha uma versão 'canônica' com base na prioridade do agente ou na ordem de execução. Se seu 'Agente Arquiteto Sênior' produz uma saída semelhante à do seu 'Agente Estagiário Júnior', essa ferramenta garante que o arquiteto vença todas as vezes.

Por que a maioria dos desenvolvedores ignora essa etapa (e por que não deveriam)

A razão pela qual a maioria dos desenvolvedores ignora a redundância é que gerenciar o estado em fluxos de trabalho de agentes já parece difícil o suficiente. Adicionar uma etapa de pós-processamento parece como uma latência extra.

Mas considere o custo: latência aumentada em chamadas LLM a montante devido a contextos inchados, custos aumentados por solicitação e, mais importante—gatilhos de alucinação causados por informações conflitantes, mas quase idênticas, aparecendo repetidamente no histórico de prompts.

perder o controle sobre o que permanece na sua janela de contexto é como pequenos scripts de automação se transformarem em bagunças inadministráveis uma vez escalados.

Você pode encontrar a implementação completa e a documentação em https://vinkius.com/mcp/agent-output-deduplicator.

O objetivo não é apenas reduzir tokens; é garantir que, quando seu sistema finalmente apresenta uma resposta a um humano ou toma uma decisão por meio de chamada de função, essa decisão se baseie em uma verdade destilada em vez de ecos repetitivos.

Os MCPs são a música dos Agentes de IA. Nós construímos o catálogo. Descubra Catálogo MCP Vinkius.