Nota de Escopo. O MCP da Cryptohopper foi projetado para ser stateless — cada chamada de ferramenta é independente, e o servidor não persiste nada entre as requisições. A memória reside no lado do cliente ou em armazenamento que você controla. Este guia é sobre essa camada.
Pré-requisitos
Um cliente MCP com uma conexão MCP da Cryptohopper funcionando. Veja visão geral da configuração.
Um local para armazenar dados. Pode ser um arquivo local, um banco de dados SQLite, um blob JSON armazenado na nuvem, ou uma ferramenta como Notion. Nenhuma infraestrutura é necessária para começar.
O que conta como "memória"
Três camadas, cada uma útil por diferentes motivos:
Camada | Exemplo | Localização Típica |
Memória de Sessão | Dentro de uma conversa, o modelo lembra o que você disse anteriormente. | Janela de contexto do modelo (embutido) |
Memória entre Execuções | A execução do agente de hoje lembra o que a execução da semana passada observou. | Arquivo, banco de dados, Notion, etc. |
Perfil do Usuário | O agente conhece sua watchlist, exchange preferida, preferência de risco. | O mesmo que entre execuções; carregado no início da sessão. |
A memória de sessão é gratuita e automática. A memória entre execuções e de perfil do usuário exige que você configure o armazenamento.
Configuração — perfil do usuário
Escreva um pequeno arquivo markdown descrevendo você como um usuário de cripto. Mantenha-o com menos de uma página:
Sobre o usuário
Opera principalmente na Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Mantém posições spot; opera bots de grade na SOL e AVAX via Cryptohopper.
Preocupa-se mais com o risco de drawdown do que em perder o upside.
Não opera futuros.
Padrões
Exchange: Binance
Moeda de Cotação: USDT
Timeframe de TA: 4h (200 barras)
Tolerância ao Risco: moderada
Preferências de Prompt
Prefere números concretos a adjetivos.
Sinaliza especulação como especulação.
Se um ticker for ambíguo, pergunte em vez de adivinhar.Carregue-o no início de cada conversa com o agente. Duas abordagens:
Colar Manualmente: a primeira coisa em cada sessão, cole o arquivo.
Integrado ao Cliente: use o recurso de memória persistente do seu cliente (Projetos do Claude desktop, regras do Cursor, contexto do Zed) para injetar automaticamente.
Mantenha o arquivo pequeno. Qualquer coisa acima de ~300 linhas se torna ruído que o modelo ignora. O ponto são as restrições, não uma autobiografia.
Versionamento. Quando você mudar sua watchlist ou preferências, comite a mudança para o git (ou histórico do Notion). O comportamento do seu agente mudará com o perfil; você vai querer ver o porquê.
Configuração — memória entre execuções (simples)
A memória entre execuções mais simples é um único arquivo markdown que o agente lê no início e anexa no final:
Crie `memory.md` com um esqueleto:
Memória do Agente Observações Recentes (Anexe entradas aqui após cada execução.) Itens pendentes para monitorar (Coisas que o agente sinalizou para atenção futura.) Decisões Passadas (Decisões notáveis e seus raciocínios.)
No início de cada execução do agente, injete o conteúdo do arquivo:
[MEMÓRIA DO AGENTE] {conteúdo de memory.md} [TAREFA] Tarefa de hoje: executar o resumo diário.No final de cada execução, anexe novas observações. Peça ao agente para produzi-las explicitamente:
Após completar a tarefa, escreva 2-4 linhas resumindo qualquer coisa notável que valha a pena lembrar para a próxima vez. Use este formato: [AAAA-MM-DD] {observação} Exemplos: [2026-05-27] Volume de SOL elevado por 3 dias seguidos; mantendo uma faixa de aproximadamente 83-87. [2026-05-27] Watchlist: sinalizado LINK como quieto, mas vale a pena verificar em 7 dias. Vou anexar estes ao memory.md manualmente.Revise e limpe periodicamente. Mais ou menos uma vez por semana, recorte `memory.md` — delete entradas antigas, consolide padrões. Um arquivo de memória não gerenciado cresce indefinidamente e se torna ruído.
Configuração — memória entre execuções (estruturada)
Para agentes que se beneficiam de histórico consultável, um pequeno banco de dados SQLite funciona bem. Sugestão de esquema:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- ex: "daily-digest"
category TEXT, -- ex: "volume-spike", "trend-change"
token TEXT, -- ex: "SOL"
content TEXT NOT NULL, -- o texto da observação
metadata JSON -- quaisquer campos estruturados
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Isso permite que você faça consultas como: "quais observações fizemos sobre SOL nos últimos 14 dias?" — e alimente a resposta ao agente como contexto para a execução de hoje.
O agente escreve nesta tabela através de um pequeno helper Python:
python
def log_observation(agent_name: str, category: str,
token: str, content: str) -> None:
conn.execute(
"INSERT INTO observations (run_at, agent_name, category, token, content) "
"VALUES (?, ?, ?, ?, ?)",
(datetime.utcnow().isoformat(), agent_name, category, token, content),
)
conn.commit()
Use isso com moderação. Memória estruturada só vale a pena a configuração se você realmente for consultá-la; para um resumo simples, o arquivo markdown geralmente é suficiente.
O que lembrar, o que não lembrar
Bons candidatos à memória:
"SOL tem negociado lateralmente em uma faixa de 83–87 por 5 dias" — contexto de faixa que uma única vela de um dia não mostrará na execução de amanhã.
"Sinalizamos LINK para uma anomalia de volume ontem; acompanhe hoje."
"Usuário perguntou sobre bots de grade para AVAX em 2026-05-20; parâmetros foram X, Y, Z."
Não são bons candidatos à memória:
Dados brutos do mercado. Eles mudam — puxe novamente do MCP em vez de confiar em um cache desatualizado.
Transcrições completas de conversas. A relação sinal-ruído é muito baixa.
Resumos automáticos de cada execução. Sem curadoria, eles se tornam praticamente inúteis.
Um bom teste: "se eu deletar esta entrada de memória, o agente se comportará pior na próxima semana?" Se não, delete-a.
Solução de Problemas
O agente cita memória que é contradita por dados atuais.
Este é o risco fundamental do contexto em cache. O agente "lembra" que SOL estava em tendência de alta, mas desde então reverteu. Correção: instrua o agente a sempre verificar as afirmações de memória contra os dados atuais do MCP antes de usá-las como fatos. "Antes de confiar em uma entrada de memória, verifique os dados atuais e sinalize se a memória estiver desatualizada."
Arquivos de memória crescem descontroladamente.
Você está anexando sem limpar. Defina uma regra rígida: uma vez por semana, revise as entradas da última semana e delete / mescle. Ou rotacione arquivos de memória mensalmente (memory-2026-04.md, memory-2026-05.md).
O agente ignora o bloco de memória.
O prompt não exige que o agente o use. Seja explícito: "revise o bloco de memória acima antes de responder. Referencie entradas específicas quando relevante. Se uma entrada contradiz dados recentes, sinalize isso explicitamente."
A memória introduz respostas confiantes, mas erradas.
O agente está tratando a memória como autoritativa. Enquadre a memória como pistas, não como verdade: "a memória contém observações passadas; trate como contexto, não fato. Sempre verifique contra dados atuais."
Você quer que o agente atualize a memória sem sua intervenção.
Possível, mas arriscado — a memória somente de anexação não monitorada acumula entradas ruins tão rápido quanto as boas. Se você automatizar, sempre combine com uma etapa de revisão semanal. Nunca deixe a memória crescer por um mês sem ser lida.
Memória multi-agente fica confusa.
Se vários agentes compartilham um arquivo de memória, use o campo `agent_name` para criar namespaces para as entradas. Cada agente lê apenas suas próprias entradas, ou lê o arquivo completo, mas sabe qual agente escreveu qual linha.
O arquivo de perfil do usuário fica desatualizado. As preferências mudam. Se você notar o agente usando um timeframe ou exchange que você não usa mais, atualize o perfil — não contorne isso com substituições por prompt.