A maioria dos agentes hoje são amnesíacos brilhantes. Eles conseguem planejar, chamar ferramentas e escrever código em uma única sessão, mas no momento em que o chat termina, a lição se perde. Execute a mesma tarefa de pesquisa de mercado dez vezes e o agente recomeça do zero na décima primeira. As correções do usuário, os caminhos sem saída, o fluxo que finalmente funcionou — tudo evapora.
O HugAgentOS, um projeto open-source do Centro Colaborativo de Inovação em Inteligência Artificial coproduzido por província e ministérios da Universidade de Zhejiang, trata essa amnésia como um problema de sistema operacional. Ele não apenas dá ao agente um cartão de memória maior. Ele constrói uma stack que transforma traces de execução em capacidades reutilizáveis, compõe essas capacidades em workflows e envolve todo o processo com atribuição, verificação por replay e rollback. O objetivo não é um turno mais inteligente, mas um agente que se torna mais competente quanto mais você o usa.
Qual problema está realmente sendo resolvido?
A equipe do HugAgentOS argumenta que memória bruta não basta. A experiência só se torna habilidade após quatro conversões:
- Retenção — o trace de uma execução bem-sucedida precisa ser mantido, não enterrado num log de chat.
- Estruturação — caminhos recorrentes precisam ser extraídos como ativos explícitos e reutilizáveis.
- Transferência — habilidades isoladas precisam ser compostas em workflows de ponta a ponta para classes inteiras de tarefas.
- Feedback em circuito fechado — melhorias precisam ser atribuídas, verificadas isoladamente, aprovadas e reversíveis.
A memória de longo prazo resolve a retenção, mas ignora as outras três. Por isso os agentes continuam repetindo os mesmos erros e os mesmos loops de planejamento. O HugAgentOS constrói as quatro conversões dentro do sistema operacional.
Os três motores de autodesenvolvimento
O sistema divide o harness do agente em três motores, cada um capaz de melhorar com a experiência.
1. Motor de memória — guardar o que importa, esquecer o ruído
O motor de memória armazena traces de execução, mescla conteúdo duplicado e esmaece informações obsoletas. Não é um depósito de todos os tokens já gerados; é um registro gerenciado do que realmente aconteceu. Esse registro se torna o conjunto de treinamento para os dois motores seguintes.
2. Motor de habilidades — transformar acidente em playbook
Quando o mesmo tipo de tarefa tem sucesso repetidamente, o motor de habilidades destila o caminho comum em uma habilidade reutilizável, semelhante a um arquivo SKILL.md. O ativo inclui checkpoints e notas de falhas, então o agente sabe não apenas o que funcionou, mas o que já falhou antes. No próprio exemplo do projeto, uma requisição repetida de pesquisa de mercado gerou um “Playbook de Pesquisa de Mercado” com três regras rígidas: empresas não verificadas não entram na tabela; sentimento positivo não é igual a ausência de risco; número de patentes não é igual a força técnica. Essas regras vieram do próprio histórico de falhas do usuário, não de um prompt genérico.
3. Motor de orquestração — compor habilidades em jogadas padrão
Tarefas reais precisam de mais de uma habilidade. Um relatório de pesquisa pode exigir uma habilidade de busca, uma ferramenta de visualização, uma habilidade de geração de documentos e um sub-agente revisor. Quando esses quatro componentes têm sucesso juntos repetidamente, o motor de orquestração empacota a combinação como o workflow padrão para aquela classe de tarefas. Da próxima vez, o agente não pergunta “qual ferramenta primeiro?”. Ele chega com a stack completa.
Memória → habilidade → orquestração é o flywheel composto: a experiência permanece, vira habilidade, e as habilidades se unem.
Dois guardrails para a autoevolução
Autodesenvolvimento sem controle é recursão sem freio. O HugAgentOS adiciona dois guardrails.
Portão de atribuição — uma falha, um responsável
Quando uma execução falha, os três motores poderiam tentar corrigi-la. O motor de memória quer registrar o estado ruim. O motor de habilidades quer adicionar uma etapa de verificação. O motor de orquestração quer trocar a fonte de dados. Se todos atualizarem ao mesmo tempo, o resultado são patches conflitantes.
O portão de atribuição fica à frente deles. Sua função não é decidir como corrigir a falha, mas se ela deve ser corrigida e qual motor é o responsável. Uma única falha pode acionar apenas uma camada responsável. O portão também tem o direito de rejeitar a atualização por completo quando a causa raiz está fora dos motores — por exemplo, uma entrada ausente na base de conhecimento, uma limitação de formato do modelo ou uma mudança em uma API externa.
Somente após replay isolado e confirmação do usuário a mudança entra em produção. O usuário pode ver a evidência, as tarefas históricas afetadas e o diff proposto em um console de evolução, e pode revertê-la.
Fronteira ontológica — guardrails legíveis por máquina
O segundo guardrail é uma ontologia de domínio escrita como regras executáveis. Ela define conceitos (ex.: entidade empresa, evento de risco), relações (um evento de risco precisa de pelo menos uma fonte de evidência), restrições (uma consulta de risco exige primeiro um ID de empresa verificado) e workflows (análise de alto risco vai para um comitê de revisão).
Antes mesmo de o LLM rodar, um portão determinístico verifica a ação contra a ontologia. Se o agente tenta consultar risco sem verificar a empresa, o portão bloqueia, cita o número da regra e retorna um caminho concreto de correção. Esse portão não custa tokens e responde em milissegundos. Ele também restringe a própria evolução: novas memórias, habilidades e workflows precisam passar pela validação ontológica antes de serem promovidos.
Analogia: de post-its a uma fábrica de playbooks
Pense em um agente típico de memória longa como um funcionário que guarda todos os post-its de todas as reuniões. Ele consegue encontrar notas antigas, mas ainda planeja cada projeto do zero.
O HugAgentOS é mais parecido com um manual de operações vivo. Cada projeto atualiza o manual: sequências bem-sucedidas viram procedimentos padrão, combinações recorrentes de ferramentas viram playbooks padrão, e toda mudança proposta passa por um processo leve de controle de mudanças — quem é o responsável, que evidência a sustenta, se foi testada por replay e como desfazê-la.
Por que isso importa além do laboratório
A adoção de agentes nas empresas tem sido limitada por dois fatores: o custo de falhas repetidas e a impossibilidade de auditar por que um agente fez o que fez. O HugAgentOS ataca ambos. Se você está comparando ferramentas de agentes, combine isto com nosso diretório de ferramentas de agentes e a análise hands-on do Manus.
- Custo composto, não recorrente. Cada tarefa concluída deixa um ativo, não apenas uma transcrição. Com o tempo, o custo marginal de tarefas repetidas cai, porque o agente já conhece o playbook.
- Auditabilidade por design. Atribuição, replay e rollback transformam a caixa-preta em uma stack de capacidades com versionamento. Isso importa para workflows regulados ou de alto risco.
- Infraestrutura aberta. Como o projeto é open source, o padrão pode se espalhar por frameworks de agentes, ferramentas de observabilidade e produtos de compliance, em vez de permanecer um recurso exclusivo de um único fornecedor.
Se o primeiro semestre de 2026 foi sobre janelas de contexto maiores e inferência mais barata, o segundo semestre aponta cada vez mais para infraestrutura de capacidades: como os agentes lembram, melhoram e permanecem dentro de limites. O HugAgentOS é um sinal concreto dessa mudança.
Como experimentar
- Código: github.com/ZJU-REAL/HugAgentOS
- Releases: GitHub Releases (clientes desktop para Windows, macOS, Linux)
- Site: hugagentos.com
Um ciclo prático para começar:
- Escolha uma tarefa repetitiva, como um scanner semanal de mercado ou um briefing de concorrentes.
- Execute-a de cinco a dez vezes com a camada de autoevolução ativada.
- Revise a habilidade destilada na biblioteca de habilidades e edite os checkpoints se necessário.
- Ative o portão de atribuição para que apenas uma camada mude por falha.
- Defina uma pequena restrição de domínio — por exemplo, “toda alegação de risco deve citar uma fonte” — e deixe o portão determinístico aplicá-la.
A proposta não é substituir o LLM. É fazer com que a saída do LLM se acumule em algo que a equipe possa possuir, revisar e reutilizar.
