# Memória do Grok Build entre sessões: definições e limitações
> Como ativar a memória, onde são guardadas as notas e como funcionam /flush, /remember, /dream e /memory. Prioridade das definições, verificação e eliminação de entradas.
Source: https://ailoot.ai/blog/pt-pt/grok-build-memory/
Canonical: https://ailoot.ai/blog/pt-pt/grok-build-memory/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-111
Revision: sha256-fb7a1bd1435d52f380f38ff16267f42b80a4550827003a9d162070c3b51a6b6b
O Grok Build, o agente de terminal da xAI, tem memória entre sessões: consegue recordar convenções do projeto, decisões e passos de depuração bem-sucedidos e, depois, acrescentá-los ao contexto de uma nova sessão sem que seja necessário voltar a lembrá-lo. A funcionalidade está desativada por predefinição e é experimental — pode ser ativada com uma única definição.
Esta descrição baseia-se no guia oficial do repositório `xai-org/grok-build`, tal como estava a 20 de setembro de 2026. O autor do artigo original não utilizou o produto: o funcionamento foi descrito com base na documentação, e não em testes pessoais.
[Encontre na documentação informações práticas sobre como trabalhar com Ailoot](https://ailoot.ai/docs/).
## O que oferece a memória no Grok Build?
Principal conclusão
Sem memória, uma nova sessão do Grok Build não recebe qualquer informação das sessões anteriores: nem as convenções que explicou, nem as decisões que tomou, a menos que estejam registadas num ficheiro de instruções do repositório. Com a memória ativada, o agente pesquisa as notas guardadas e acrescenta automaticamente as relevantes ao contexto de uma nova sessão. As notas são guardadas como ficheiros Markdown normais, que pode ler e editar.
Por exemplo, numa sessão explicou ao agente que o projeto usa indentação de dois espaços, que as migrações da base de dados são executadas com um comando separado e que um módulo específico trata dos pagamentos. Numa nova sessão, tem de voltar a fornecer estas informações.
Com a memória ativada, o Grok Build pode:
- recordar convenções do projeto que explicou anteriormente;
- usar passos de depuração que já deram resultado;
- levar decisões de arquitetura para sessões posteriores;
- evitar voltar a perguntar sobre assuntos que já foram esclarecidos.
A funcionalidade é experimental e está desativada por predefinição. O comportamento do agente não muda enquanto não a ativar.
## Como ativar a memória?
Principal conclusão
Para uma única execução, defina a variável de ambiente `GROK_MEMORY=1`. Para a manter ativada, adicione uma secção `[memory]` com `enabled = true` a `~/.grok/config.toml`. Para que as notas guardadas sejam adicionadas no início do trabalho, inicie uma nova sessão com `/new` depois de ativar a memória.
**Uma vez, para uma única execução:**
```bash
GROK_MEMORY=1 grok
```
A variável aplica-se apenas a esta execução. O comando `export GROK_MEMORY=1` mantém-na na shell atual e ativa a memória em todas as execuções seguintes de `grok` nessa shell — até a sessão do terminal terminar ou executar `export GROK_MEMORY=0`.
**Permanentemente, através da configuração.** Adicione o seguinte a `~/.grok/config.toml`:
```toml
[memory]
enabled = true
```
**Numa sessão, sem reiniciar:** abra `/memory` e prima `t`.
Esta alternância aplica-se apenas à sessão atual e não é guardada na configuração. Pode ser usada para ativar ou desativar a memória. Desativá-la retira o acesso às ferramentas de memória, mas não elimina os ficheiros do disco; voltar a ativá-la abre novamente o acesso ao armazenamento. A alternância não pode sobrepor-se a uma desativação forçada da memória para todo o processo através de `GROK_MEMORY=0`: `/memory` permanece indisponível durante toda a sessão.
Se as definições forem especificadas em vários locais, têm a seguinte prioridade:
- `GROK_MEMORY=0` desativa forçosamente a memória para todo o processo e tem a prioridade mais elevada.
- Um `enabled = false` explícito na configuração desativa a memória, mesmo que uma definição remota gerida a ative.
- A memória pode ser ativada com `GROK_MEMORY=1`, com `enabled = true` na configuração ou através de uma definição remota gerida.
- Se nada for especificado, a memória fica desativada.
As notas são adicionadas no primeiro turno de uma sessão. Se ativou a memória a meio do trabalho e quer que o agente comece a usar as informações guardadas sobre o projeto, execute `/new`. Pode verificar se a memória está ativada no resultado de `grok inspect`.
## O que regista o Grok Build e onde?
Principal conclusão
As notas são guardadas em `~/.grok/memory/` como ficheiros Markdown: um `MEMORY.md` global para todos os projetos, um `MEMORY.md` separado para cada projeto e registos de sessões. O resumo automático no fim de uma sessão é escrito sem uma chamada ao modelo; as notas detalhadas são criadas com `/flush` e `/remember`; e `/dream` agrupa entradas dispersas por tema.
A estrutura do diretório `~/.grok/memory/`:
| Localização | Âmbito | Conteúdo |
|----|----|----|
| `~/.grok/memory/MEMORY.md` | Global | Factos e preferências para todos os seus projetos |
| `~/.grok/memory/` + diretório do projeto com hash + `/MEMORY.md` | Projeto | Convenções e contexto de um repositório específico |
| `~/.grok/memory/` + diretório do projeto com hash + `/sessions/` | Sessões | Resumos e registos de sessões individuais |
É acrescentado um hash curto do identificador do repositório ao nome do diretório do projeto. Para a identificação, é utilizado o remoto `origin` no formato “organização/repositório” ou, se não existir um repositório Git, o caminho do diretório. Assim, os clones e as árvores de trabalho (cópias de trabalho separadas de branches Git) do mesmo repositório partilham a mesma memória do projeto: aquilo de que o agente se lembra numa cópia fica disponível noutra.
As entradas são criadas de quatro formas:
1. **Resumo automático no fim da sessão.** Quando uma sessão termina, o Grok Build guarda um breve resumo de serviço no registo diário: o número de mensagens, até cinco das primeiras trocas substanciais e a data e hora. O resumo é criado a partir de metadados, sem chamada ao modelo nem demora. As sessões muito curtas são ignoradas: se tiverem menos de três trocas substanciais ou menos de 50 bytes do seu texto, não é criada nenhuma entrada. O resumo não inclui as ferramentas utilizadas, os caminhos dos ficheiros nem os comandos. Os resumos automáticos podem ser desativados com a definição `session.save_on_end = false`.
2. **`/flush` — uma nota detalhada a pedido.** Com este comando, o modelo resume os pontos mais importantes da sessão atual: decisões, padrões, passos de depuração e conclusões sobre APIs. O resumo é escrito num registo datado e indexado para sessões futuras. A documentação recomenda executar `/flush` antes da compactação do contexto, no fim de uma sessão de depuração bem-sucedida e após descobrir padrões importantes.
3. **`/remember` — um pedido explícito para recordar algo.** Escreva `/remember lembra-te de abrir sempre os links dos PR depois de os enviar` ou diga ao agente: «lembra-te de que…». Antes de a entrada ser escrita, abre-se um painel de revisão: a nota só é guardada depois de confirmar, e aparece no feed `Memory saved to ~/.grok/memory/MEMORY.md`. As informações do projeto são guardadas no `MEMORY.md` do projeto; as informações partilhadas por todos os projetos são guardadas no ficheiro global.
4. **`/dream` — consolidação.** O comando agrupa registos e notas dispersos por tema e elimina duplicados para tornar a pesquisa mais precisa. Tal como acontece com `/flush`, a consolidação é realizada pelo modelo — este lê as entradas acumuladas e reescreve-as por temas, pelo que deve rever periodicamente o resultado com `/memory`. Existe também um modo automático: por predefinição, o Grok Build verifica as condições ao iniciar e uma vez por hora; inicia a consolidação quando tiverem passado pelo menos 24 horas e se tiverem acumulado pelo menos 5 sessões. Os limites podem ser configurados na secção `[memory.dream]` da configuração.
As notas são pesquisadas através de um índice SQLite: por predefinição, utiliza a pesquisa de texto integral FTS5 e, se estiver configurado um modelo de embeddings, acrescenta-se a pesquisa vetorial semântica.
## Como chega a memória a uma nova sessão?
Principal conclusão
No primeiro turno de uma sessão, o Grok Build pesquisa na memória entradas relacionadas com o projeto e acrescenta-as automaticamente ao contexto — não precisa de lhe voltar a lembrar. A pesquisa é repetida após a compactação automática do contexto. As entradas de sessões mais antigas são assinaladas para verificação da atualidade.
A injeção inicial usa um limiar de seleção de `min_score = 0.9`, que pode alterar na secção `[memory.initial_injection]`. Após a compactação automática do contexto, o agente volta a pesquisar na memória para restaurar informações que possam ter sido removidas do contexto juntamente com trocas mais antigas.
Também pode perguntar diretamente ao agente: «O que te lembras?» A resposta será agrupada por origem: preferências globais, conhecimento do projeto e histórico de sessões.
As entradas das sessões têm marcadores de atualidade. Quanto mais antiga for uma entrada do registo de sessões, mais destacado será o aviso: «Confirma se isto ainda está atualizado antes de te baseares nesta informação.» Os ficheiros globais e de projeto `MEMORY.md` não recebem estes marcadores: o conteúdo destina-se a uso a longo prazo, pelo que tem de acompanhar a sua precisão.
## Como ver, editar e eliminar notas?
Principal conclusão
O comando `/memory` abre uma vista geral de todos os ficheiros de memória, com pré-visualizações. Pode editar os ficheiros em qualquer editor de texto — as alterações serão detetadas na pesquisa seguinte. O pedido «esquece…» funciona sem garantia; para remover uma entrada específica de forma fiável, edite o ficheiro.
O comando `/memory` numa sessão abre uma janela com todos os ficheiros de memória, agrupados por âmbito: global, projeto e sessões (por ordem cronológica inversa). A lista de ficheiros fica à esquerda e uma pré-visualização só de leitura do ficheiro selecionado fica à direita.
Teclas úteis na vista geral:
| Tecla | Ação |
|----|----|
| `↑`/`↓` ou `j`/`k` | Percorrer a lista |
| `/` | Filtrar a lista |
| `y` | Copiar o caminho do ficheiro selecionado |
| `x` | Eliminar a nota selecionada (prima novamente para confirmar) |
| `t` | Ativar ou desativar a memória |
| `Esc` | Fechar a janela |
A janela permite eliminar notas individuais e ficheiros de sessões; não permite eliminar os índices `MEMORY.md` gerados (global e de projeto).
O segundo método consiste em editar diretamente os ficheiros. Estão em `~/.grok/memory/` e podem ser abertos em qualquer editor. As alterações no diretório são monitorizadas: os ficheiros criados e modificados são reindexados e os ficheiros eliminados são removidos do índice na pesquisa seguinte.
O pedido «esquece o snake_case» funciona sem garantia: o modelo pesquisa e remove as entradas correspondentes, mas pode não encontrar algumas. Para garantir a eliminação, abra o ficheiro (pode copiar facilmente o caminho com `y` em `/memory`) e remova a entrada manualmente. Pode limpar totalmente a memória a partir da linha de comandos: `grok memory clear` para a memória do projeto, `grok memory clear --global` para a memória global e `grok memory clear --all` para ambas.
## Em que difere a memória de um ficheiro de instruções do repositório?
Principal conclusão
Escreve um ficheiro de instruções, como CLAUDE.md ou AGENTS.md, e coloca-o no repositório — é partilhado com a equipa através do Git. O agente Grok Build mantém notas de memória e guarda-as em `~/.grok/memory/`, fora do repositório: são pessoais e não são partilhadas através do Git.
As instruções do repositório são partilhadas com todas as pessoas que trabalham no projeto e são visíveis no código e no histórico de alterações. A memória cresce ao longo das sessões, é guardada na sua máquina e não é publicada por si só.
A memória não substitui um ficheiro de instruções. As regras gerais do projeto necessárias para toda a equipa e para qualquer agente continuam a fazer sentido no repositório. Temos um guia separado sobre como usar um único ficheiro de instruções para Claude Code, Codex e Cursor: [AGENTS.md e CLAUDE.md em conjunto](https://ailoot.ai/blog/pt-pt/agents-md-claude-md-one-instruction-file/). A memória preserva o contexto pessoal: as suas preferências, aquilo que já foi tentado e a decisão tomada.
O Claude usa uma distinção semelhante: explicamos como a memória difere de CLAUDE.md no artigo [Memória do Claude e CLAUDE.md](https://ailoot.ai/blog/pt-pt/claude-memory-claude-md-auto-memory/). Para comparar as próprias ferramentas, consulte [Grok Build ou Claude Code](https://ailoot.ai/blog/pt-pt/grok-build-vs-claude-code/).
## Limitações e verificação do funcionamento da memória
Principal conclusão
A funcionalidade é experimental: os comandos e as definições podem mudar. Para que as notas sejam adicionadas no primeiro turno depois de ativar a memória, inicie uma nova sessão com `/new`. Algumas entradas são criadas pelo modelo, por isso reveja as notas periodicamente e peça-lhe que não guarde segredos na memória.
Tenha em conta as seguintes limitações:
- **Estado experimental.** Os comandos, os limiares e o comportamento podem mudar em versões futuras; se algo não funcionar como esperado, consulte o guia de memória do repositório.
- **Injeção inicial numa nova sessão.** Depois de ativar a memória, comece a trabalhar com `/new` para que as notas guardadas sejam adicionadas no primeiro turno.
- **O modelo decide o que é importante.** O modelo cria o resumo de `/flush` e escolhe o que incluir na nota. De uma em uma ou de duas em duas semanas, abra `/memory` e reveja o que se acumulou; elimine o que for desnecessário.
- **Não lhe peça para guardar segredos na memória.** Chaves, tokens e palavras-passe não devem constar de notas de longa duração: os ficheiros em `~/.grok/memory/` são guardados em texto simples. Se for registada alguma informação sensível, remova-a editando o ficheiro.
- **A memória do projeto é partilhada entre cópias do repositório.** Se o agente guardar algo num clone que esteja desatualizado noutro, tenha em conta que o diretório é partilhado quando fizer a limpeza.
Se a memória não funcionar:
1. Verifique o resultado de `grok inspect` para confirmar que a memória está ativada.
2. Verifique se `GROK_MEMORY=0` ou a configuração não a estão a desativar.
3. Para diagnóstico, execute `RUST_LOG=debug GROK_LOG_FILE=/tmp/grok.log grok` e verifique as linhas sobre a memória em `/tmp/grok.log`.
## Resumo breve
A memória do Grok Build é ativada com `GROK_MEMORY=1` ou com `[memory] enabled = true` em `~/.grok/config.toml`. Para que as notas sejam adicionadas logo no primeiro turno depois de a ativar, inicie uma nova sessão com `/new`. O agente escreve notas em `~/.grok/memory/`: resumos de sessões sem chamada ao modelo, resumos detalhados com `/flush`, entradas explícitas com `/remember` após a sua confirmação e temas organizados com `/dream`. Consulte e organize as notas através de `/memory` e da edição direta dos ficheiros. A funcionalidade é experimental, por isso confirme os limiares e os comandos no guia oficial e reveja as notas periodicamente.
### Fontes
- Grok Build, guia oficial “Cross-Session Memory” (guia do utilizador, capítulo 13):
- Grok Build, repositório da xAI no GitHub:
Para trabalhar de forma sistemática, é útil a combinação **clone de IA + Segundo Cérebro + Engenharia de Contexto**.
[Aceda ao Ailoot](https://ailoot.ai/).
## Perguntas frequentes
### Porque não aparecem notas guardadas depois de ativar a memória?
As notas guardadas são acrescentadas no primeiro turno de uma sessão nova. Abra uma sessão depois de ativar a memória e verifique o estado com grok inspect; um processo iniciado com GROK_MEMORY=0 não consegue ativá-la pelo controlo da sessão.
### Desligar a memória elimina os ficheiros?
Não. Desativar remove o acesso às ferramentas de memória, mas deixa as notas Markdown no disco. Inspecione ou edite separadamente as notas guardadas se precisar de remover uma entrada.
## Ailoot · A empresa e a sua carteira de projetos
A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.
A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.
A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.