Memória
Permita que execuções futuras reutilizem conhecimento durável do projeto sem tratar o transcript completo como um prompt permanente.
A memória do Clarvis é uma wiki Markdown local ao workspace. Ela mantém conhecimento útil e não óbvio, como comandos verificados, decisões de arquitetura, sintomas recorrentes de falhas e os motivos de um workaround. São arquivos Markdown comuns — sem vetores nem embeddings — para que o dono do projeto possa ler e editar o que foi preservado.
Diferencie memória, sessões e contexto
- O transcript da sessão é o registro durável do que pessoas e agentes disseram e fizeram.
- O contexto do modelo é o conjunto de trabalho limitado enviado a uma chamada e pode ser compactado.
- A memória é conhecimento curado para reutilização entre execuções no mesmo workspace.
A memória não copia todas as conversas. A maioria das execuções concluídas não deve produzir alteração alguma. Quando vale a pena preservar conhecimento, a wiki guarda detalhes em folhas MEMORY.md, compila resumos de tópicos e mantém PROFILE.md como índice geral do workspace.
<workspace>/.clarvis/memory/
├── PROFILE.md
└── build/
├── TOPIC.md
└── bun/
└── MEMORY.mdAtive a memória
Abra /settings/memory, escolha o escopo global ou do workspace, crie o bloco de memória e selecione o modelo usado para extrair conhecimento durável. Salve a alteração para as próximas execuções. A linha da sessão permite desativar ou reativar temporariamente a memória já configurada sem reescrever as configurações.
A memória precisa de um modelo de extração efetivo. Ela usa o modelo específico quando configurado e, caso contrário, o modelo padrão efetivo. Se nenhum dos dois for resolvido, o Clarvis mantém a configuração, mas avisa que não pode aprender.
Acompanhe como uma execução aprende
No início da execução, o Clarvis adiciona ao contexto do agente o resumo limitado de PROFILE.md. Agentes com acesso à memória podem pesquisar e ler documentos mais profundos. O líder pode atualizar a memória pelas ferramentas protegidas; subagentes recebem leitura, mas não podem conceder a si mesmos autoridade de escrita.
Quando uma execução termina, o Clarvis coloca de forma durável uma indexação em segundo plano na fila. Essa passagem revisa a tarefa, o resultado e evidências limitadas das ferramentas, depois faz uma atualização coerente da wiki ou deixa a memória inalterada. A próxima tarefa do usuário não precisa esperar o fim da indexação.
Diga ao Clarvis o que merece ser anotado
Adicione orientação em Markdown simples em um ou nos dois locais:
| Arquivo | Escopo | Compartilhar? |
|---|---|---|
~/.clarvis/memory-policy.md | sua preferência em todo lugar | não |
<workspace>/.clarvis/memory-policy.md | expectativas deste projeto | opcionalmente versionado |
As duas políticas se combinam, começando pela global. Escreva orientação editorial sobre o que é útil, não uma estrutura substituta para a wiki:
Registre o comando exato que corrigiu um build e explique por que funcionou.
Não preserve dados de clientes, credenciais temporárias nem aliases pessoais do shell.Alterações da política valem na próxima indexação, sem reiniciar o Clarvis.
Mantenha a memória inspecionável e segura
O backend de arquivos padrão fica nos dados do Clarvis dentro do workspace e continua diretamente legível como Markdown. Segredos são removidos dos snapshots limitados antes da indexação, mas uma política de memória ainda é importante: não instrua um agente a reter dados sensíveis que não devem fazer parte do conhecimento durável do projeto.
O Clarvis também pode usar um provedor de memória MCP ou de plugin configurado. O provedor efetivo é responsável pelo armazenamento e pelas capacidades; um provedor somente leitura nunca recebe uma escrita de indexação. Trocar de provedor não reproduz escritas pendentes em outro backend.