Multiagentes acabam consumindo muitos tokens e também perdem o contexto com frequência? Por isso criei um LLM Wiki que adota uma estrutura de “redação de jornal”.

• Agentes autônomos multiagente têm aparecido bastante ultimamente, mas, quando você realmente os coloca para rodar, eles acabam consumindo de 5 a 10 vezes mais tokens e também perdem o contexto com frequência. Por isso estruturei o sistema multiagente inspirado em uma redação de jornal.
• Existem cinco papéis de agentes, mas o único agente em que o LLM decide por conta própria é o desk (revisão). Os demais são tarefas de escrita, verificações em Python baseadas em regras, não em LLM, como lint, e coordenação de tarefas, isto é, orquestração.
• Como no conceito de LLM Wiki, ele lê documentos originais para criar páginas-fonte, extrai dali rascunhos de pessoas e conceitos, e empilha isso em páginas de visão geral por tema, organização de contradições e síntese. O armazenamento é simplesmente em arquivos Markdown com git, e todas as ferramentas em Python rodam localmente. Basta dar clone para rodar imediatamente o grafo de exemplo, mesmo sem chave de API.
• O exemplo que está agora no GitHub trata do debate sobre “o que é open source em IA”, mas o framework em si não depende do tema.

---

Por que não simplesmente soltei vários agentes

• Os relatos de pessoas que rodaram isso de verdade, gastando milhares de dólares, em geral chegavam à mesma conclusão: consome um monte de tokens, os agentes perdem o contexto ao trocar mensagens entre si e marcam como concluídas tarefas que ainda não terminaram.
• Por isso, em vez de deixar que decidam sozinhos, dei mais peso a regras definidas e isolamento de contexto. Embora eu use a metáfora da redação, o único LLM que realmente julga de forma livre é o desk; os demais fazem apenas tarefas predefinidas.

Respondendo de antemão a objeções prováveis

• Os documentos vão inchando até ficarem inutilizáveis: acho que essa é a preocupação mais realista. Por isso separei completamente o papel de quem escreve e o desk que decide se algo passa. Para o desk, mostro apenas o resultado e os critérios de avaliação, sem mostrar com que intenção o autor escreveu. Além disso, um lint baseado em regras filtra mecanicamente quando os documentos incham, ficam duplicados ou se alongam sem direção. Ainda assim, não posso dizer que “impedi” o inchaço.
• Se a edição for repetida, os erros se acumulam; e, se o sistema se corrige com feedback que ele mesmo gerou, acaba repetindo apenas os padrões que já existiam: essa é uma suspeita que sempre acompanha a ideia de autoaperfeiçoamento, e também a considero válida. Por isso, quando defeitos que o desk encontra repetidamente são refletidos de volta nas diretrizes, troco a cada vez os casos de falha usados para validação, para evitar que o sistema apenas fique bom nas mesmas questões de teste (overfit). É como verificar sempre com casos que ele vê pela primeira vez. Nas páginas de síntese, também incluí uma verificação que compara se conteúdos de fontes diferentes não foram misturados de forma grosseira.
• No fim, isso não é só RAG com embeddings trocados manualmente?: se o objetivo for busca, sim. A diferença é que o resultado não é um índice vetorial, mas documentos conectados que uma pessoa pode simplesmente ler; e que os pontos em que as fontes não concordam não são encobertos, mas expostos separadamente em páginas de contradições. A ideia não é recopilar os textos originais a cada pergunta, mas deixar acumulados os julgamentos já construídos.

Um conceito antigo: Memex

• Criei isso tendo em mente ideias como o Memex de Vannevar Bush, uma máquina de informação conectada concebida em 1945, e “Man-Computer Symbiosis”, de Licklider.
• Por isso incluí trails, ou caminhos associativos, que conectam página a página, e uma função discover que encontra conexões inesperadas. Não se trata de extrair índices automaticamente, mas de tentar deixar caminhos que uma pessoa possa percorrer por conta própria.

Considerações de uso

• Dizer que “não precisa de chave de API” é só meio verdade: o Python dentro de tools roda localmente, então não exige chave externa. Mas os agentes em si rodam com Claude Code, portanto cada pessoa precisa usar a própria chave (BYOK).
• O repositório público contém a ideia e um pequeno exemplo: há um exemplo em inglês com 15 nós, então qualquer pessoa pode reproduzir o mesmo grafo apenas clonando o repositório. A instância real com cerca de 2.300 nós que venho rodando diariamente fica separada e privada, então peço que a vejam como distinta do repositório público.
• Modo em coreano (WIKI_LANG=ko): apenas o corpo do texto e os metadados no topo do documento (frontmatter) são alterados para coreano; as marcações que representam a estrutura do documento, como ## Summary e [fact], são deixadas intencionalmente em inglês. Ou seja, não é “totalmente em coreano”.

Motivação e estado atual

• O ponto de partida foi anexar uma implementação ao gist de LLM Wiki compartilhado por Karpathy. Esse conceito em si já foi apresentado antes no GeekNews: https://pt.news.hada.io/topic?id=28208
• Se separar quem escreve de quem revisa realmente reduz aprovações feitas de qualquer jeito, e se o loop de autoaperfeiçoamento de fato ajuda, ainda não são resultados medidos adequadamente, mas hipóteses em experimentação.