Curso / Lição 2  ·  EN
Lição 02 · O sistema com que aprendemos

Engenharia Reversa do Hermes

O Hermes Agent é o "agente de IA auto-aperfeiçoável" da Nous Research — uma base de código Python de mais de um milhão de linhas. Você não pode fundir o que não entende, então a fusão começou com um mapa. Esta lição é o núcleo desse mapa: o que o Hermes é, a única ideia estrutural que o torna extensível, e o ciclo fechado de aprendizado que se tornou a razão inteira da fusão.

~2.497
arquivos Python
~1,18M
linhas de código
87
arquivos de tool em tools/
30
chaves de toolset

Realidade de escala: o mapa não é uma leitura linha-a-linha de todas as 1,18M LOC — ele aprofunda as prioridades e cataloga a cauda longa, com a fronteira de cobertura declarada explicitamente. Fonte: docs/hermes-complete-map.md §1, §6.

O que é o Hermes

O Hermes é um agente de IA pessoal que roda o mesmo núcleo de agente em várias superfícies — uma CLI, um gateway de mensagens (Telegram, Discord, Slack e ~20 outras plataformas), uma TUI Ink/React e um app desktop Electron. Construído pela Nous Research, licença MIT. Seus diferenciais de destaque, nas próprias palavras dele:

As duas restrições de design das quais tudo decorre

1 · O cache de prompt por conversa é sagrado. Uma conversa longa reusa um prefixo em cache a cada turno; qualquer coisa que mute o contexto passado ou reconstrua o system prompt no meio da conversa invalida o cache e multiplica o custo. A única exceção sancionada é compressão de contexto. 2 · O núcleo é uma cintura estreita; capacidade vive nas bordas. Toda tool de modelo é enviada em toda chamada de API, então a barra para uma nova tool de núcleo é alta — nova capacidade chega como um comando de CLI + skill ou um plugin, não como superfície de núcleo.

Note a rima com a Lição 1: Hermes e Alembic chegaram independentemente a "uma cintura estreita + prompt estável de cache". Esse instinto compartilhado é exatamente por que a fusão compõe em vez de brigar — e é o fio que puxamos na Lição 3.

O linchpin: a arquitetura de registro de tools

Esta é a ideia estrutural mais importante e mais portátil do Hermes. As tools se auto-registram no momento do import; nada mantém uma lista central de imports. Cada arquivo de tool chama registry.register(...) no nível de módulo; um passo de descoberta faz glob no diretório e importa cada arquivo, e o side-effect do import popula o registro.

run_agent.py · cli.py · batch_runner.py entry points disparam a descoberta model_tools.py importa o registry + roda discover_builtin_tools() tools/*.py  — 87 arquivos cada um chama registry.register(...) no nível de módulo (side-effect do import) tools/registry.py sem deps — possui schema, dispatch, disponibilidade, limites

Há uma nuance crucial em que o mapa insiste — e é a fonte de um número que é mal-citado. A auto-descoberta registra o schema de uma tool, mas a tool só é exposta a um agente se seu nome aparecer num toolset em toolsets.py. Então três contagens diferentes descrevem três coisas diferentes:

ContagemO que realmente mede
87arquivos de tool em tools/*.py (verificado ls | wc -l). Inclui arquivos de infra como registry.py, scanners de segurança e helpers compartilhados — nem todos são tools voltadas ao agente.
30chaves de toolset em toolsets.py (browser, memory, skills, web, …) — os bundles nomeados que uma plataforma herda.
"64 tools"O número que o material de aprendizado orange-book cita para tools voltadas ao agente. Mantemos a distinção arquivo/tool explícita em vez de colapsar os três num número só.
Por que isso importa para o mapa. "Quantas tools o Hermes tem?" não tem resposta única — depende se você conta arquivos, chaves de toolset ou tools expostas. Uma engenharia reversa fiel declara as três e o que cada uma mede, em vez de escolher a mais redonda.

O ciclo fechado de aprendizado — a afirmação "auto-aperfeiçoável", mecanicamente (§1.10)

A propriedade de destaque é concreta no código, não marketing. Após um turno, o agente pode forkar a si mesmo para revisar o que acabou de acontecer e decidir se algo vale a pena lembrar — e as escritas caem em stores duráveis que a próxima sessão lê.

um turno do usuário run_conversation() fork de revisão de fundo thread daemon, AIAgent forkado whitelist: só tools de memória + skill stores duráveis MEMORY.md / USER.md + skills criadas pelo agente curador ciclo de vida a próxima sessão carrega o snapshot atualizado — a conversa principal + cache de prompt NUNCA são tocados

As peças, cada uma concreta na fonte:

A única frase para levar à Lição 3

Para o Alembic, este ciclo inteiro — fork-após-turno → auto-revisão sob uma whitelist só de memória/skill → escrever em stores duráveis → ciclo de vida do curador → próxima sessão lê o snapshot atualizado — é o CLONE conceitual de maior valor, e compõe limpo com o pipeline de validador/portão existente do Alembic.

A disciplina do mini-loop (§5)

O repo hermes-mini-loop é uma implementação de referência mínima da mesma ideia, e declara a disciplina como três regras — as regras que impedem um ciclo de auto-aperfeiçoamento de se afogar no próprio ruído:

RegraO que previne
Aprender só de vitórias (score ≥ 0.7)Sedimentar lições de turnos falhos ou de baixa confiança. Só sucessos validados viram memória durável.
Reforçar, não duplicarRever o mesmo fato deve fortalecer a entrada existente, não anexar uma quase-cópia que incha o store limitado.
Recombinar átomos provadosNovas skills são compostas de peças já validadas em vez de inventadas do zero — melhoria por recombinação.

Segure o limite 0.7 e o "reforçar-não-duplicar" — ambos reaparecem, portados literalmente, como o portão padrão e o comportamento de dedup do ciclo do Alembic na Lição 4.

Confusões comuns

"O Hermes é um gateway de modelo." O gateway dele é um gateway de mensagens (Telegram/Discord/…), não de modelo. O papel de provedor de modelo é distribuído por providers/ + plugins/model-providers/ + um proxy local compatível com OpenAI — um subsistema inteiramente diferente.
"O revisor de fundo muda a conversa atual." Não — é um fork. Ele escreve em stores duráveis; a conversa viva e seu cache de prompt nunca são mutados. "Auto-aperfeiçoável" é literal mas diferido: a melhoria aparece no load da próxima sessão.
"87 = o número de tools." 87 é o número de arquivos em tools/. A exposição é controlada pelas 30 chaves de toolset; o orange-book conta ~64 tools voltadas ao agente. Três números, três significados.
1. No Hermes, qual é a relação entre o 87 e o 30?
Correto: b. A auto-descoberta registra o schema de uma tool (87 arquivos, muitos deles infra/helpers), mas uma tool só é exposta se seu nome está num toolset (30 chaves). As "64 tools" do orange-book são ainda um terceiro número — tools voltadas ao agente. Um mapa fiel mantém a distinção arquivo/tool.
2. Por que a revisão de fundo roda num agente forkado numa thread daemon, com uma whitelist de tools só de memória/skill?
Correto: d. A restrição #1 (o cache de prompt é sagrado) proíbe mutar a conversa viva. Um fork herda o prompt em cache literalmente, escreve em stores duráveis e deixa o turno principal intocado — então "auto-aperfeiçoável" é real mas diferido para a próxima sessão.
3. A regra do mini-loop "aprender só de vitórias (score ≥ 0.7)" existe para prevenir o quê?
Correto: c. Um ciclo de auto-aperfeiçoamento que aprende de tudo rapidamente se envenena. O piso 0.7 (mais "reforçar, não duplicar" e "recombinar átomos provados") mantém só vitórias validadas — e esse limite exato é portado no portão do Alembic na Lição 4.