Hermes Mixture of Agents: o que é, como funciona e quando vale usar

Uma leitura operacional do conceito geral e da implementação real do Hermes — com código, docs, trade-offs e exemplos do dia a dia.

Mixture of Agents, ou MoA, é a ideia de pedir mais de um modelo para pensar sobre o mesmo problema e deixar um modelo final agregar essas perspectivas antes de responder ou agir. No Hermes isso não é só teoria: existe uma implementação concreta que transforma o MoA em um provider virtual de modelo, preservando o loop normal do agente, as tools, a sessão, a persistência e o contexto que você já usa no dia a dia.

De onde esta página saiu

Esta página foi construída a partir de quatro camadas de evidência:

• documentação oficial do Hermes: https://hermes-agent.nousresearch.com/docs/user-guide/features/mixture-of-agents;
• código local do Hermes, especialmente website/docs/user-guide/features/mixture-of-agents.md, hermes_cli/moa_config.py, hermes_cli/moa_cmd.py, agent/moa_loop.py, agent/moa_trace.py, agent/auxiliary_client.py, run_agent.py e gateway/slash_commands.py;
• estado real desta instalação, via hermes moa list e leitura de ~/.hermes/config.yaml;
• fontes externas sobre o conceito, especialmente o paper arXiv Mixture-of-Agents Enhances Large Language Model Capabilities (2406.04692) e o post técnico da Together AI sobre o tema.

Saída real desta instalação

Mixture of Agents presets
Default: default
Active in config: (off)

* default
  Reference models:
    1. openai-codex:gpt-5.5
    2. openrouter:deepseek/deepseek-v4-pro
  Aggregator: openrouter:anthropic/claude-opus-4.8

O que quer dizer Mixture of Agents

Em termos simples, MoA significa: em vez de confiar em uma única cadeia de raciocínio, você coleta múltiplas leituras do mesmo problema e usa outra camada para combinar, filtrar, sintetizar e decidir.

A formulação mais conhecida veio do paper Mixture-of-Agents Enhances Large Language Model Capabilities. A ideia ali é uma arquitetura em camadas: vários agentes geram respostas, uma camada seguinte recebe essas respostas como contexto auxiliar e produz respostas refinadas, e isso pode seguir em múltiplos níveis. A Together AI publicou resultados fortes com esse desenho, incluindo 65,1% no AlpacaEval 2.0, superando o então 57,5% do GPT-4o no benchmark citado pela própria publicação.

O ponto importante é este: MoA não é só ensemble estatístico. Não é “tirar média” de modelos. É usar modelos diferentes como analistas, depois usar outro modelo como integrador. Essa diferença importa porque o integrador pode:

• detectar divergências;
• escolher o argumento mais sólido;
• combinar pontos complementares;
• rejeitar uma análise ruim sem jogar fora as boas.

O que isso quer dizer especificamente no Hermes

No Hermes, MoA não aparece como uma tool separada. A documentação oficial e o código convergem em um desenho bem específico: MoA é um provider virtual de modelo. Cada preset configurado aparece como um “modelo” dentro do provider moa.

Isso muda bastante a ergonomia. Em vez de acionar um modo exótico fora do fluxo normal, você pode selecionar um preset MoA como se estivesse escolhendo qualquer outro modelo. Por isso ele compõe com o resto do sistema: sessão, slash commands, gateway, TUI, Desktop, goals e tool loop continuam funcionando do jeito usual.

Como o Hermes executa o MoA internamente

A documentação oficial do Hermes e o arquivo agent/moa_loop.py mostram um fluxo claro por iteração do agente:

1. resolve o preset escolhido;
2. monta uma visão “advisory” da conversa para os modelos de referência;
3. executa os reference models em paralelo;
4. injeta as respostas deles como contexto privado para o aggregator;
5. chama o aggregator com as tools normais do Hermes;
6. trata a resposta do aggregator como a resposta real do modelo da sessão;
7. se o aggregator pedir tools, o Hermes executa as tools normalmente e, na próxima iteração, o processo MoA roda de novo sobre o estado atualizado.

Leitura resumida do loop oficial do Hermes

1. resolve o preset;
2. roda os reference models sem tool schemas;
3. anexa as saídas como contexto privado;
4. chama o aggregator com o schema normal de tools;
5. trata a resposta do aggregator como resposta real;
6. executa tools normalmente se forem chamadas;
7. repete na iteração seguinte com o contexto atualizado.

Há detalhes de implementação importantes aqui:

• os references rodam sem tools;
• o Hermes remove o system prompt normal da cópia advisory e reconstrói essa visão como texto puro;
• tool calls e tool results anteriores são “achatados” para texto legível na cópia advisory;
• o aggregator é o único que continua com poder real de chamar tools.

O papel dos modelos de referência

No Hermes, os models de referência não são co-agentes autônomos operando tools. Eles funcionam mais como consultores analíticos. O próprio código de agent/moa_loop.py injeta um system prompt dizendo, em essência: “você é um advisor, não o agente que executa”.

Isso é inteligente por dois motivos. Primeiro, fica mais barato e mais compatível com providers estritos. Segundo, evita o caos de vários modelos competindo para chamar ferramentas ao mesmo tempo.

Os references rodam em paralelo

O Hermes usa ThreadPoolExecutor com limite de até 8 workers para disparar os references em paralelo. Então, se um preset tem dois ou três modelos de referência, eles podem pensar ao mesmo tempo em vez de sequencialmente. Isso ajuda a reduzir parte da latência extra, ainda que MoA continue mais lento do que um modelo único.

Prompt caching e custo de contexto

Um dos pontos mais interessantes da implementação do Hermes é que ela foi desenhada para não quebrar o prefix cache principal da conversa. A documentação oficial e o código explicam que o bloco com o contexto dos references é anexado no fim da mensagem do aggregator, para preservar o prefixo estável do histórico e maximizar cache hit.

Em outras palavras: o custo extra do MoA vem principalmente de mais chamadas de modelo, não de destruir o cache da sessão a cada turno.

Como o Hermes lida com falhas

O comportamento não é “tudo ou nada”. Se um reference falhar por credencial, provider ou qualquer outro motivo, o código não derruba o turno inteiro. Ele insere uma nota do tipo [failed: ...] e segue com os demais modelos. Isso torna a feature mais resiliente para uso real, onde provedores diferentes podem oscilar.

Como está configurado hoje nesta instalação

No host inspecionado, o Hermes tem um preset padrão chamado default, mas ele não está ativo por padrão na configuração global. Ou seja: o recurso está disponível, porém hoje o seu fluxo principal ainda não roda em MoA por padrão.

Isso é coerente com o desenho-padrão do próprio arquivo hermes_cli/moa_config.py, que define exatamente essa combinação como preset default quando não há outra configuração explícita salva.

Como usar no dia a dia com o Hermes

Na prática, o Hermes oferece dois jeitos principais de usar MoA:

• selecionar um preset como modelo da sessão, via /model ... --provider moa ou pelos pickers normais;
• usar o atalho one-shot /moa <prompt>, que aplica o preset padrão só naquele turno e depois restaura o modelo anterior.

Exemplos citados na documentação do Hermes

/model default --provider moa
/model review --provider moa

/moa desenhe e implemente um plano de migração para este cluster de testes instável

Para o nosso dia a dia com Hermes assistente pessoal, o mais interessante costuma ser o segundo modo: MoA como ferramenta de escalada intelectual. Você deixa o fluxo normal simples e só aciona MoA quando a tarefa pede uma análise mais profunda.

Como configurar MoA no seu cenário

Depois da leitura e da inspeção do ambiente real, o desenho que faz mais sentido para o seu caso é este: references relativamente próximos em nível e um aggregator tão forte quanto ou mais forte do que eles. Essa intuição é boa. Se os references forem fracos demais, ou muito desalinhados do problema, o aggregator pode gastar energia filtrando ruído em vez de ganhar revisão útil.

Ao mesmo tempo, “parecidos” não precisa significar “idênticos”. O melhor arranjo costuma ser modelos fortes, com estilos diferentes, mas da mesma faixa de qualidade. Por exemplo: um GPT forte e um DeepSeek forte como references, com um Claude topo de linha ou um GPT topo de linha como aggregator. Isso preserva diversidade sem jogar a qualidade média para baixo.

Trecho confirmado da doc de providers do Hermes

Anthropic OAuth no Hermes só funciona com Claude Max + extra usage credits.
Claude Pro não pode usar esse caminho.
Sem isso, use ANTHROPIC_API_KEY.

Passo a passo de configuração

1. Configure os providers primeiro com hermes model fora da sessão. /model só troca entre providers já configurados.
2. Confirme que MoA está disponível com hermes moa list.
3. Crie ou edite um preset com hermes moa configure [nome], ou edite config.yaml manualmente.
4. Ative o preset na sessão com /model <preset> --provider moa.
5. Para uso seletivo, prefira /moa <prompt> em tarefas difíceis, sem transformar MoA no padrão de tudo.

Comandos mínimos

hermes model
hermes moa list
hermes moa configure review

/model review --provider moa
/moa revise este plano de deploy e me diga os riscos reais

Exemplo recomendável hoje, com o que você já tem

Sem OpenRouter e sem Anthropic API confirmada, a forma mais realista de começar é usar OpenAI Codex como aggregator e deixar o DeepSeek entrar como segunda opinião forte. Isso segue a sua lógica: um modelo muito forte fecha a resposta, mas ele enxerga antes uma leitura alternativa de outro modelo competitivo.

moa:
  default_preset: review
  presets:
    review:
      reference_models:
        - provider: openai-codex
          model: gpt-5.5
        - provider: deepseek
          model: deepseek-reasoner
      aggregator:
        provider: openai-codex
        model: gpt-5.5
      reference_temperature: 0.6
      aggregator_temperature: 0.4
      max_tokens: 4096
      enabled: true

Esse desenho faz sentido porque o gpt-5.5 continua sendo o “juiz final”, mas ele recebe antes uma leitura do DeepSeek. Se quiser algo ainda mais conservador, você pode usar deepseek-chat no lugar de deepseek-reasoner quando a tarefa pedir menos cadeia de raciocínio e mais objetividade.

Exemplo ideal quando você tiver um aggregator ainda mais forte

Se no futuro você adicionar OpenRouter ou uma ANTHROPIC_API_KEY própria, aí sim fica muito alinhado com a sua visão de arquitetura: references fortes e parecidos, mais um aggregator superior. Exemplo conceitual:

moa:
  default_preset: premium-review
  presets:
    premium-review:
      reference_models:
        - provider: openai-codex
          model: gpt-5.5
        - provider: deepseek
          model: deepseek-reasoner
      aggregator:
        provider: anthropic
        model: claude-sonnet-4-6
      reference_temperature: 0.6
      aggregator_temperature: 0.3
      max_tokens: 4096
      enabled: true

Aqui a lógica é bem clara: dois references fortes fazem a revisão prévia; o Claude entra como integrador final. Se você depois tiver acesso a um Claude ainda mais forte via API ou OpenRouter, esse papel de aggregator premium fica ainda mais coerente.

O que eu faria no seu lugar

1. começaria com um preset simples e viável já hoje: gpt-5.5 agregando gpt-5.5 + deepseek-reasoner;
2. usaria MoA só por comando em tarefas caras: revisão de plano, debugging difícil, desenho de arquitetura, validação antes de mudança operacional;
3. mediria benefício real: se a resposta final melhora de forma recorrente, aí vale subir para um aggregator ainda melhor no futuro;
4. evitaria references fracos demais só para “ter diversidade”, porque sua intuição está certa: diversidade ruim pode piorar a revisão final.

Ganhos reais: onde MoA pode ajudar

Nem todo ganho aparece como benchmark. No uso diário, os benefícios mais valiosos tendem a ser qualitativos:

• menos ponto cego: um modelo percebe uma falha que outro não viu;
• melhor estratégia de ação: o aggregator pode combinar uma análise prudente com outra mais criativa;
• mais robustez em tarefas ambíguas: quando o pedido é mal especificado, múltiplas leituras ajudam a mapear hipóteses melhores;
• maior qualidade em tarefas difíceis: debugging complicado, arquitetura, refactor sensível, trade-offs de produto, análise operacional;
• melhor tool use indireto: os references não usam tools, mas podem sugerir ao aggregator quais tools chamariam e em que ordem.

A própria documentação do Hermes cita benchmark interno no HermesBench onde uma configuração com Opus 4.8 agregando uma referência em GPT-5.5 supera os modelos isolados. Isso reforça a tese central: duas perspectivas bem combinadas podem produzir mais qualidade do que uma só.

Perdas e custos: onde dói

Os custos do MoA também são bem concretos:

• latência maior: antes do aggregator agir, os references precisam rodar;
• custo maior: cada iteração do agente pode virar várias chamadas de modelo;
• mais complexidade mental: debugging de comportamento fica mais difícil, porque a resposta final não vem de uma única cadeia visível;
• mais variabilidade: se os references divergem muito, o aggregator pode tanto enriquecer quanto “diluir” a melhor linha;
• pouco benefício em tarefas triviais: pedir a hora, resumir algo simples ou executar uma ação direta geralmente não precisa desse peso.

Isso é o futuro?

A resposta honesta é: talvez seja parte do futuro, mas não o futuro inteiro.

O que parece muito plausível é um mundo em que agentes bons usem roteamento adaptativo: tarefas simples vão para um modelo só; tarefas médias acionam um fallback; tarefas difíceis chamam algum arranjo estilo MoA. Isso faz bastante sentido econômico e técnico.

O que parece menos provável é MoA virar o padrão universal para tudo, porque o custo marginal continua alto. A publicação da Together AI já reconhecia o trade-off: a qualidade sobe, mas o time to first token piora. O Hermes confirma isso por arquitetura: mais chamadas, mais orquestração, mais tempo.

Então a melhor leitura hoje é: MoA é um multiplicador de qualidade para casos selecionados, não um substituto automático do fluxo simples. Ele tem cara de futuro em cenários premium, críticos ou difíceis — especialmente agentes com tools — mas não necessariamente em todo prompt do cotidiano.

Casos de uso no nosso dia a dia com Hermes e assistente pessoal

Aqui é onde a tecnologia fica mais tangível. Alguns casos em que MoA faz sentido no uso prático com Hermes:

1. Debugging difícil de automação ou infraestrutura

Exemplo: um fluxo Playwright falha de forma intermitente, ou um comportamento de gateway muda depois de update. Um reference pode sugerir “isso tem cara de regressão de bootstrap”; outro pode sugerir “isso parece estado quebrado ou symlink pendente”. O aggregator junta as hipóteses e decide a melhor ordem de inspeção real.

2. Decisão de arquitetura com trade-offs reais

Exemplo: separar perfis do Hermes, desenhar um workflow com cron + gateway + skills, ou decidir entre provider único e fallback multi-provider. Um modelo pode priorizar simplicidade operacional; outro, resiliência. O aggregator pode entregar uma decisão mais equilibrada.

3. Revisão de planos e mudanças arriscadas

Antes de editar config, mexer em systemd, trocar provider ou alterar um fluxo de produção, um turno MoA pode servir como “revisão interna” automática: múltiplos modelos examinam riscos antes da execução real.

4. Pesquisa e síntese com mais de uma lente

Em pesquisas mais abertas — por exemplo, avaliar uma nova feature do Hermes, um provider, um MCP ou uma estratégia de deploy — um reference pode ser melhor em leitura conceitual e outro em detalhe operacional. O aggregator devolve um quadro mais útil para decisão.

5. Assistente pessoal para decisões mais delicadas

Mesmo fora de código, MoA pode ajudar em tarefas como montar uma estratégia de viagem complexa, comparar opções com restrições, ou estruturar uma decisão pessoal/profissional com múltiplos critérios. Um modelo pode trazer praticidade; outro, visão de risco; o aggregator organiza isso em um parecer mais maduro.

Quando eu não usaria MoA

• tarefas mecânicas de uma etapa;
• consultas rápidas ou triviais;
• ações urgentes onde latência importa mais do que refinamento;
• trabalho repetitivo que já está bem resolvido por uma skill e um modelo único;
• situações em que custo precisa ficar sob controle estrito.

Pontos de implementação do Hermes que valem atenção

Alguns detalhes da implementação mostram que o recurso foi pensado para uso real, não só demonstração:

• provider virtual: o sistema de seleção de modelos trata MoA como provider normal;
• atalho one-shot com restauração: /moa aplica o preset padrão só naquele turno e depois desfaz a troca;
• auxiliares resolvem para o aggregator: tarefas auxiliares não tentam chamar um endpoint “moa”, elas caem no provider/modelo real do aggregator;
• traces opcionais: agent/moa_trace.py permite persistir o que cada reference viu e respondeu, fora do histórico normal da sessão;
• desligamento por preset: enabled: false desliga o fan-out e deixa só o aggregator agir;
• sem recursão: evita árvores MoA dentro de MoA.

Em especial, o arquivo agent/auxiliary_client.py mostra uma escolha arquitetural importante: quando o provider principal da sessão é moa, os auxiliares passam a resolver direto para o aggregator real, porque não existe endpoint HTTP real para “moa”. Isso é uma pista forte de que Hermes trata MoA como camada de orquestração, e não como provider físico de API.

MoA do paper vs. MoA do Hermes

Vale não confundir as duas coisas. O conceito original do paper e da Together AI enfatiza uma arquitetura em múltiplas camadas, potencialmente com vários níveis e vários agentes por camada. Já o Hermes implementa uma forma mais pragmática e operacional:

• vários references;
• um aggregator;
• integração total com tool loop do agente.

Ou seja: o Hermes não tenta reproduzir toda a complexidade do paper. Ele captura a ideia mais útil para um agente real de uso diário: ouvir múltiplas opiniões antes de agir.

Minha recomendação prática para o nosso uso

Para o seu perfil de uso do Hermes, eu não faria do MoA o modo padrão global de cara. Eu trataria assim:

1. modelo simples como default para fluidez e custo controlado;
2. MoA por acionamento seletivo com /moa em tarefas difíceis;
3. se algum tipo de problema provar benefício recorrente, aí sim faz sentido criar um preset mais específico e pensar em adoção mais ampla.

Isso combina melhor com a realidade operacional: você preserva velocidade para o cotidiano e reserva a artilharia pesada para os casos em que ela realmente agrega.

Fontes consultadas

• Docs Hermes: website/docs/user-guide/features/mixture-of-agents.md e a página pública correspondente;
• Configuração Hermes: hermes_cli/moa_config.py e hermes_cli/moa_cmd.py;
• Loop de execução: agent/moa_loop.py;
• Persistência de trace: agent/moa_trace.py;
• Integração com auxiliares: agent/auxiliary_client.py;
• Integração com runtime: run_agent.py e gateway/slash_commands.py;
• Fonte externa conceitual: arXiv 2406.04692, Mixture-of-Agents Enhances Large Language Model Capabilities;
• Fonte externa prática: post da Together AI, Together MoA — collective intelligence of open-source models pushing the frontier of LLM capabilities.