Habilidades do Assistente de IA Hermes para Configurações de Produção

O assistente de IA Hermes, documentado oficialmente como Hermes Agent, não se posiciona como um simples wrapper de chat.

Para instalação, configuração de provedores, sandboxing de ferramentas e configuração do gateway, consulte o guia do Assistente Hermes AI. As interfaces de CLI do dia a dia (hermes profile, hermes skills, hermes cron e comandos relacionados) são resumidas na folha de referência rápida da CLI do Hermes Agent. Este artigo foca na arquitetura de skills e perfis que determina como o Hermes se comporta uma vez em execução. Para detalhes concretos sobre a criação de SKILL.md — campos de frontmatter, layout de diretórios, segredos versus config.yaml e skills que desaparecem dos comandos de barra — consulte Criação de Skills do Hermes Agent — Estrutura e Melhores Práticas do SKILL.md.

A documentação oficial e o repositório descrevem um agente de autoaperfeiçoamento com um ciclo de aprendizado integrado que cria skills a partir da experiência, aprimora-as durante o uso, persiste o conhecimento entre sessões e roda em qualquer coisa, desde um VPS de baixo custo até sandboxes na nuvem.

Em abril de 2026, o repositório público no GitHub mostra cerca de 94,6k estrelas, 13,2k forks e o lançamento mais recente tagueado como v0.10.0 em 16 de abril de 2026. Essa é atividade suficiente para chamar o projeto de rápido, bem adotado e, ao mesmo tempo, ainda operacionalmente jovem.

Essa natureza dual é importante para o design de produção. O Hermes é maduro o suficiente para suportar trabalho real, mas dinâmico o suficiente para que uma configuração desorganizada envelheça mal. O artigo abaixo trata configuração e skills como uma questão de arquitetura operacional, não como uma lista de recursos.

Por que o Hermes precisa de uma arquitetura centrada em perfis

As skills do Hermes são documentos de conhecimento sob demanda. Elas usam divulgação progressiva para que o agente possa ver primeiro um índice compacto de skills e carregar apenas o conteúdo completo da skill quando necessário, o que mantém o uso de tokens sob controle, mesmo quando muitas skills estão instaladas. Cada skill instalada se torna um comando de barra na CLI e nas superfícies de mensagens, e a documentação posiciona explicitamente as skills como o mecanismo de extensão preferido quando uma capacidade pode ser expressa com instruções, comandos de shell e ferramentas existentes, em vez de código de agente personalizado.

A complicação em produção é que o Hermes trata as skills como estado vivo, não como pacotes congelados. Skills embutidas, skills instaladas pelo hub e skills criadas pelo agente vivem todas sob ~/.hermes/skills/, e a documentação afirma que o agente pode modificar ou excluir skills. O mesmo sistema expõe ações de criação, patch, edição, exclusão e arquivos de suporte para gerenciamento de skills. Isso é poderoso, mas também significa que um agente “faz-tudo” excessivamente grande tende a se tornar um armário bagunçado de procedimentos.

Perfis são a resposta. Perfis do Hermes são ambientes totalmente isolados, cada um com seu próprio config.yaml, .env, SOUL.md, memórias, sessões, skills, trabalhos cron e banco de dados de estado. A CLI também transforma um perfil em seu próprio alias de comando, então um perfil chamado coder se torna coder chat, coder setup, coder gateway start e assim por diante. Na prática, isso faz com que os perfis sejam a verdadeira unidade de propriedade em produção, não a skill individual.

A linha de base de produção

A forma da linha de base é surpreendentemente limpa. O Hermes armazena comportamento não secreto em ~/.hermes/config.yaml, segredos em ~/.hermes/.env, identidade em SOUL.md, fatos persistentes em memories/, conhecimento procedural em skills/, trabalhos agendados em cron/, sessões em sessions/ e logs em logs/. O comando hermes config set roteia chaves de API para .env e tudo o resto para config.yaml, e a ordem de precedência documentada é: flags da CLI primeiro, depois config.yaml, depois .env, depois os valores padrão embutidos. Essa também é a resposta mais limpa à FAQ de produção sobre como segredos e configuração devem ser divididos.

Um layout prático de múltiplos perfis geralmente acaba ficando assim, com um perfil por responsabilidade em vez de um perfil por humano:

~/.hermes/profiles/
  eng/
  research/
  ops/
  execops/
  ml/

Esse padrão corresponde a como os perfis do Hermes são documentados: cada perfil é seu próprio ambiente isolado, e os perfis podem ser clonados de uma configuração base quando valores padrão comuns são úteis. A documentação também observa que os perfis não compartilham memória ou sessões, e que skills atualizadas podem ser sincronizadas entre perfis quando a instalação principal é atualizada.

O próximo limite de produção é a execução. O Hermes suporta seis backends de terminal - local, Docker, SSH, Modal, Daytona e Singularity - e a documentação de segurança descreve um modelo de defesa em profundidade que inclui aprovação de comandos perigosos, isolamento de container, filtragem de credenciais MCP, verificação de arquivos de contexto, isolamento entre sessões e sanitização de entrada. Em outras palavras, a decisão “perfil primeiro” responde quem possui o estado, e a decisão de backend responde onde o trabalho arriscado é permitido acontecer.

A automação fica sobre essa linha de base. Trabalhos cron do Hermes podem anexar zero, um ou múltiplas skills, e eles rodam em sessões de agente frescas, em vez de herdar o chat atual. O gateway de mensagens também é o processo em segundo plano que gerencia sessões, roda o cron e roteia os resultados de volta para plataformas como Telegram, Discord, Slack, WhatsApp, Email, Matrix e outras. O guia oficial do MCP adiciona mais uma regra de produção que é fácil de passar despercebida: o melhor padrão não é conectar tudo, mas expor a menor superfície útil. Para execução multi-agente estilo fila em modelos auto-hospedados, use Kanban no Hermes Agent para Fluxos de Trabalho de LLMs Auto-Hospedados como um runbook complementar. Se seu layout de produção coloca o Hermes em uma máquina sem interface gráfica e os operadores conectam-se de clientes de desktop, use Configuração de Servidor Headless e Desktop Remoto do Hermes Agent para a topologia de rede e serviço.

O perfil de engenharia de software

A persona mais óbvia do Hermes é o engenheiro de software que quer que o agente se comporte menos como uma janela de chat e mais como um operador de repositório repetível. Este perfil geralmente se preocupa com autenticação de repositório, triagem de issues, criação de PRs, revisão de código, depuração e execução baseada em planos. Nos catálogos do Hermes, o pacote de skills embutido principal é incomummente coerente para essa tarefa: github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging e test-driven-development. Se a delegação é importante, o Hermes também entrega skills de agentes autônomos embutidas como codex, claude-code, opencode e hermes-agent-spawning.

O que torna esse pacote útil não é nenhuma skill individual. É a maneira como as skills codificam o procedimento de desenvolvimento. github-pr-workflow cobre o ciclo de vida completo do PR, github-issues formaliza operações de issues, github-code-review e code-review fazem da revisão uma etapa distinta em vez de uma reflexão tardia, e systematic-debugging impede que o agente salte diretamente para correções prematuras. Isso também responde à questão prática de quais skills de assistentes de IA são mais importantes para fluxos de trabalho de codificação. As skills de maior valor geralmente são aquelas que garantem higiene de repositório e disciplina de revisão, não aquelas que prometem mais geração bruta de código.

A delegação do Hermes fortalece ainda mais este perfil. A plataforma pode gerar agentes filhos isolados com sua própria conversa, sessão de terminal e conjunto de ferramentas, e apenas o resumo final é retornado ao pai. Para bases de código, isso é um ajuste mais limpo do que enfiar cada diff intermediário, stack trace e nota de revisão em uma única conversa. Em termos de produção, o perfil de engenharia se beneficia de conjuntos de skills estreitos, um backend sandboxed como Docker ou SSH, e uso generoso de delegação quando o ruído de contexto começa a dominar.

O perfil de pesquisa e conhecimento

O perfil de pesquisa é onde o Hermes começa a parecer distinto de assistentes comuns. Os catálogos embutidos já incluem arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel e ml-paper-writing, enquanto o catálogo opcional oficial adiciona qmd, parallel-cli, scrapling e uma camada de pesquisa mais ampla para domínios especializados. Esse stack cobre busca de papers, monitoramento de fontes, OCR, sistemas de notas locais, reconhecimento de domínio, escrita e recuperação híbrida, sem forçar tudo em um único padrão RAG.

Este perfil também é o lugar mais claro para responder à questão memória versus skills. A documentação do Hermes define memória como fatos sobre usuários, projetos e preferências, enquanto skills armazenam procedimentos sobre como fazer as coisas. Trabalho de pesquisa precisa de ambos. A memória guarda o que o assistente já aprendeu sobre o domínio e as preferências do leitor; skills codificam procedimentos repetíveis como “escanear arXiv, resumir novos papers e escrever notas no Obsidian.” Essa distinção é importante porque sistemas de pesquisa em produção falham quando tudo é tratado como memória ou tudo é tratado como fluxo de trabalho. O Hermes dá casas separadas para essas preocupações. Para o quadro técnico completo de como a memória funciona — a arquitetura de dois arquivos, limites de caracteres, cache de prefixo e todas as oito opções de provedores externos — consulte Sistema de Memória do Hermes Agent.

O perfil de pesquisa também se beneficia desproporcionalmente do cron. Trabalhos cron do Hermes podem carregar explicitamente skills antes da execução, e os guias de automação enfatizam que prompts agendados devem ser totalmente autocontidos porque eles rodam em sessões frescas. Um pipeline recorrente que combina blogwatcher, arxiv, obsidian ou llm-wiki é, portanto, mais confiável do que um trabalho vago de “verificar o que mudou hoje”. Em outras palavras, perfis de pesquisa funcionam melhor quando a descoberta de fontes, escrita de notas e armazenamento a longo prazo são representados por uma skill nomeada em vez de escondidos dentro de um único prompt de linguagem natural longo.

O perfil de automação e operações

O perfil de ops é menos glamuroso e frequentemente mais valioso. Este é o usuário que quer que o Hermes reaja a eventos, inspecione sistemas, execute verificações scriptadas, roteie saída para um canal e faça tudo isso sem transformar o host em uma responsabilidade. O Hermes tem os blocos de construção certos para esse estilo de trabalho: webhook-subscriptions embutidas para ativação orientada a eventos, native-mcp e mcporter embutidos para ferramentas baseadas em MCP, e skills opcionais oficiais como docker-management, fastmcp, cli e 1password quando o fluxo de trabalho se expande para containers, servidores MCP personalizados ou injeção de segredos.

A razão pela qual este pacote funciona é que cada skill possui uma fronteira. webhook-subscriptions lida com a entrada de sistemas externos. docker-management transforma tarefas de container em um procedimento nomeado em vez de um jogo de shell livre. fastmcp é útil quando o Hermes precisa se tornar o orquestrador ao redor de novas ferramentas MCP, e 1password mantém o manejo de segredos explícito em vez de contrabandeado no histórico do shell ou em arquivos markdown. A orientação oficial do MCP reforça o mesmo instinto de produção: conecte a coisa certa com a menor superfície útil. Quando este perfil de ops é consumido através de interfaces de chat mobile, os detalhes de implementação estão cobertos em Controle de Voz do Hermes do Seu Telefone.

Este perfil também é o lugar mais limpo para responder como fluxos de trabalho de IA agendados permanecem confiáveis. A documentação do cron do Hermes diz que os trabalhos rodam em sessões frescas, podem anexar uma ou mais skills e devem usar prompts autocontidos. O guia de solução de problemas do cron adiciona que o disparo automático depende do ticker do gateway em vez de uma sessão de chat de CLI comum. Então, o padrão confiável é direto, mesmo que a implementação não seja: skills explícitas, alvo de entrega explícito, prompt autocontido, backend isolado e um gateway que está realmente rodando.

O perfil de operações executivas

Existe uma persona mais silenciosa, mas muito real, do Hermes que se parece com um chefe de gabinete, líder de operações ou fundador sobrecarregado. As skills relevantes são menos chamativas e mais moldadas pelo escritório: google-workspace, notion, linear, nano-pdf, powerpoint, e a skill de email himalaya embutida, além de skills opcionais oficiais como agentmail, telephony e one-three-one-rule. Essa mistura dá ao Hermes acesso a caixa de entrada, calendário, documentos, tarefas, apresentações, limpeza de PDF, um framework de comunicação estruturado e até fluxos de trabalho de telefone e SMS onde isso realmente importa.

O fluxo aqui é mais importante do que o catálogo. google-workspace ancora a execução diária. Notion e Linear impedem que o assistente se torne o sistema de registro de tarefas. one-three-one-rule é surpreendentemente útil porque o suporte à decisão é frequentemente a coisa mais difícil de padronizar, e essa skill dá ao Hermes um procedimento nomeado para propostas em vez de comportamento genérico de “resuma isso”. nano-pdf e powerpoint são o tipo de multiplicadores operacionais que parecem pequenos até que uma equipe comece a tocar em apresentações e PDFs todos os dias.

Os recursos de mensagens e voz do Hermes tornam este perfil mais prático do que parece à primeira vista. O gateway pode expor o agente através do Slack, Telegram, Discord, WhatsApp, Email, Matrix e vários outros canais, e o stack de voz suporta entrada de microfone, respostas faladas em mensagens e conversas de voz ao vivo no Discord. A documentação também observa que uma instância do Hermes pode servir múltiplos usuários através de listas de permissão e pareamento de DM, enquanto tokens de bot permanecem exclusivos para um único perfil. É por isso que uma implantação pesada em comunicação geralmente se beneficia de pelo menos um perfil dedicado em vez de compartilhar a mesma identidade de bot com engenharia ou ops.

O perfil de plataforma de ML e dados

O Hermes é construído por um laboratório de pesquisa, e essa linhagem mostra. Os catálogos incluem jupyter-live-kernel para trabalho estilo notebook com estado, huggingface-hub para operações de modelo e conjunto de dados, evaluating-llms-harness e weights-and-biases para avaliação e rastreamento de experimentos, qdrant-vector-search para armazenamento RAG de produção, e uma grande camada de MLOps embutida e opcional com skills como axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant e nemo-curator.

O que é notável aqui não é apenas a amplitude. É que as skills abrangem todo o stack, desde iteração de notebook até curadoria de dados, avaliação, busca vetorial, ajuste fino e otimização de inferência. Para um usuário de plataforma de ML, o Hermes deixa de parecer um assistente e começa a parecer um plano de controle que pode carregar procedimentos através do ciclo de vida. jupyter-live-kernel lida com exploração iterativa, evaluating-llms-harness e weights-and-biases formalizam a medição, e as skills opcionais de computação e otimização permitem que o Hermes fale coerentemente tanto sobre experimentação quanto sobre implantação.

Este também é o perfil onde a contenção é mais importante. Porque o catálogo opcional de MLOps é tão grande, uma configuração de produção do Hermes para trabalho de ML geralmente se beneficia de ser opinativa sobre escopo. Um perfil de engenharia de plataforma que possui avaliação e implantação não precisa de cada framework de treinamento instalado. Um perfil de pesquisa que possui papers e sistemas de notas não precisa de cada skill de banco de dados vetorial. O Hermes pode carregar inventários enormes de skills, mas a utilidade em produção ainda vem de estreitar a superfície ativa.

Onde as skills se tornam responsabilidades

A parte mais forte do sistema de skills do Hermes é também o lugar onde as configurações de produção dão errado. O Hermes pode navegar e instalar skills de seu catálogo embutido, do catálogo opcional oficial, do skills.sh da Vercel, endpoints de skills bem conhecidos, repositórios diretos do GitHub e fontes comunitárias estilo marketplace. O modelo de segurança distingue entre fontes builtin, official, trusted e community, executa varreduras de segurança para skills instaladas pelo hub e permite --force apenas para blocos de política não perigosos. Um veredito de varredura perigoso permanece bloqueado. O Hermes também expõe metadados upstream como URL do repositório, instalações semanais e sinais de auditoria durante a inspeção. Esse é um modelo de confiança sólido, mas não é um substituto para o bom gosto.

Também há um limite para o que se deve pedir a uma skill para fazer. A documentação do Hermes é explícita de que skills são a escolha preferida quando o trabalho pode ser expresso como instruções mais comandos de shell mais ferramentas existentes, enquanto plugins são a abstração mais honesta para ferramentas personalizadas, hooks e comportamento de ciclo de vida. O guia de plugin até mostra como um plugin pode embalar sua própria skill. Em produção, isso significa que as skills são melhor tratadas como procedimentos reutilizáveis, não como um substituto forçado para design de ferramenta ou plugin adequado.

A comunidade e o suporte parecem saudáveis, mas não apagam a velocidade de mudança. A documentação do Hermes aponta os usuários para Discord, GitHub Discussions, Issues e o Skills Hub, e o repositório público mostra lançamentos frequentes e uma grande pegada de contribuição. A lição operacional é simples o suficiente: atualizações são parte do sistema, não um evento fora dele. Uma configuração de produção real assume que perfis, skills e suposições de fluxo de trabalho evoluirão, e então usa isolamento e pacotes de skills estreitos para que a mudança permaneça local quando inevitavelmente chegar.

O Hermes funciona melhor quando as skills são tratadas como contratos procedureis ao redor de perfis claramente separados. No momento em que um perfil se torna o agente de engenharia, o assistente de pesquisa, o trabalhador de ops, o bot de caixa de entrada e a plataforma de ML tudo ao mesmo tempo, o sistema para de se acumular e começa a vazar responsabilidades. O padrão de produção limpo é menos sobre ter mais skills e mais sobre dar a cada perfil uma descrição de trabalho que ele possa realmente manter.

Este artigo faz parte do cluster Sistemas de IA, que cobre assistentes auto-hospedados, arquitetura de recuperação, infraestrutura de LLM local e observabilidade.