Nota técnica. El MCP de Cryptohopper es sin estado por diseño: cada llamada a una herramienta es independiente y el servidor no persiste nada entre solicitudes. La memoria reside del lado del cliente o en el almacenamiento que tú controlas. Esta guía trata sobre esa capa.
Requisitos previos
Un cliente MCP con una conexión funcional al MCP de Cryptohopper. Consulta la descripción general de la configuración.
Un lugar para almacenar datos. Puede ser un archivo local, una base de datos SQLite, un blob JSON almacenado en la nube o una herramienta como Notion. No se requiere infraestructura para empezar.
Qué se considera "memoria"
Tres capas, cada una útil por diferentes motivos:
Capa | Ejemplo | Ubicación típica |
Memoria de sesión | Dentro de una conversación, el modelo recuerda lo que dijiste antes | La ventana de contexto del modelo (incorporada) |
Memoria entre ejecuciones | La ejecución del agente de hoy recuerda lo que observó la ejecución de la semana pasada | Archivo, base de datos, Notion, etc. |
Perfil de usuario | El agente conoce tu lista de seguimiento, tu exchange preferido, tu tolerancia al riesgo | Lo mismo que la memoria entre ejecuciones; se carga al inicio de la sesión |
La memoria de sesión es gratuita y automática. La memoria entre ejecuciones y el perfil de usuario requieren que configures el almacenamiento.
Configuración — perfil de usuario
Escribe un breve archivo markdown que te describa como usuario de criptomonedas. Mantenlo por debajo de una página:
Sobre el usuario
Opera principalmente en Binance.
Lista de seguimiento: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Tiene spot; ejecuta bots de cuadrícula en SOL y AVAX a través de Cryptohopper.
Le importa más el riesgo de drawdown que perderse la subida.
No opera perpetuos.
Valores predeterminados
Exchange: Binance
Moneda de cotización: USDT
Marco de tiempo TA: 4h (200 barras)
Tolerancia al riesgo: moderada
Preferencias de prompting
Prefiere números concretos a adjetivos.
Etiqueta la especulación como especulación.
Si un ticker es ambiguo, pregunta en lugar de adivinar.Cárgalo al inicio de cada conversación del agente. Dos enfoques:
Pegado manual: lo primero en cada sesión, pega el archivo.
Integrado en el cliente: usa la función de memoria persistente de tu cliente (Proyectos de escritorio de Claude, reglas de Cursor, contexto de Zed) para inyectarlo automáticamente.
Mantén el archivo pequeño. Cualquier cosa por encima de unas 300 líneas se convierte en ruido que el modelo omite. El punto son las restricciones, no una autobiografía.
Controla las versiones. Cuando cambies tu lista de seguimiento o preferencias, guarda el cambio en git (o en el historial de Notion). El comportamiento de tu agente cambiará con el perfil; querrás saber por qué.
Configuración — memoria entre ejecuciones (simple)
La memoria entre ejecuciones más simple es un único archivo markdown que el agente lee al inicio y al que añade al final:
Crea memory.md con un esqueleto:
Memoria del agente Observaciones recientes (Añade entradas aquí después de cada ejecución.) Elementos pendientes a observar (Cosas que el agente marcó para atención futura.) Decisiones pasadas (Decisiones notables y su razonamiento.)
Al inicio de cada ejecución del agente, inyecta el contenido del archivo:
[MEMORIA DEL AGENTE] {contenido de memory.md} [TAREA] Tarea de hoy: ejecutar el resumen diario.Al final de cada ejecución, añade nuevas observaciones. Pide explícitamente al agente que las produzca:
Después de completar la tarea, escribe 2-4 líneas resumiendo cualquier cosa notable que valga la pena recordar para la próxima vez. Usa este formato: [AAAA-MM-DD] {observación} Ejemplos: [2026-05-27] Volumen de SOL elevado durante 3 días consecutivos; se mantiene en un rango de aproximadamente 83-87. [2026-05-27] Lista de seguimiento: marcó LINK como tranquilo pero vale la pena revisarlo en 7 días. Añadiré estas manualmente a memory.md.Revisa y poda periódicamente. Una vez por semana más o menos, recorta
memory.md— elimina entradas obsoletas, consolida patrones. Un archivo de memoria sin gestión crece indefinidamente y se convierte en ruido.
Configuración — memoria entre ejecuciones (estructurada)
Para los agentes que se benefician del historial consultable, una pequeña base de datos SQLite funciona bien. Sugerencia de esquema:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- ej: "daily-digest"
category TEXT, -- ej: "volume-spike", "trend-change"
token TEXT, -- ej: "SOL"
content TEXT NOT NULL, -- el texto de la observación
metadata JSON -- cualquier campo estructurado
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Esto te permite hacer consultas como: "¿qué observaciones hicimos sobre SOL en los últimos 14 días?" — y alimentar la respuesta al agente como contexto para la ejecución de hoy.
El agente escribe en esta tabla a través de un pequeño ayudante de 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()
Usa esto con moderación. La memoria estructurada solo vale la pena si realmente la vas a consultar; para un resumen simple, el archivo markdown suele ser suficiente.
Qué recordar y qué no
Buenos candidatos para memoria:
"SOL ha estado moviéndose lateralmente en un rango de 83–87 durante 5 días" — contexto de rango que una sola vela diaria no mostrará en la ejecución de mañana.
"Marcamos a LINK por una anomalía de volumen ayer; haz seguimiento hoy."
"El usuario preguntó sobre bots de cuadrícula para AVAX el 2026-05-20; los parámetros fueron X, Y, Z."
No son buenos candidatos para memoria:
Datos brutos del mercado. Cambian — vuelve a obtenerlos del MCP en lugar de confiar en una caché obsoleta.
Transcripciones completas de conversaciones. La relación señal/ruido es demasiado baja.
Resúmenes automáticos de cada ejecución. Sin curación, se vuelven mayormente inútiles.
Una buena prueba: "si borro esta entrada de memoria, ¿se comporta peor el agente la próxima semana?" Si no, bórrala.
Solución de problemas
El agente cita memoria que contradicen datos actuales.
Este es el riesgo fundamental del contexto en caché. El agente "recuerda" que SOL estaba en tendencia alcista, pero desde entonces ha revertido. Solución: indica al agente que siempre verifique las afirmaciones de memoria con los datos actuales del MCP antes de usarlas como hechos. "Antes de confiar en una entrada de memoria, verifica los datos actuales y marca si la memoria está desactualizada."
Los archivos de memoria crecen de forma inmanejable.
Estás añadiendo sin podar. Establece una regla estricta: una vez por semana, revisa las entradas de la última semana y elimina / fusiona. O rota los archivos de memoria mensualmente (memory-2026-04.md, memory-2026-05.md).
El agente ignora el bloque de memoria.
El prompt no exige que el agente lo use. Sé explícito: "revisa el bloque de memoria anterior antes de responder. Haz referencia a entradas específicas donde sea relevante. Si una entrada contradice datos frescos, márcalo explícitamente."
La memoria introduce respuestas seguras pero incorrectas.
El agente está tratando la memoria como autoritaria. Enmarca la memoria como pistas, no como la verdad: "la memoria contiene observaciones pasadas; trátala como contexto, no como hechos. Siempre verifica con datos actuales."