Заметка о сфере применения. Cryptohopper MCP разработан без состояния — каждый вызов инструмента независим, и сервер ничего не сохраняет между запросами. Память находится на стороне клиента или в контролируемом вами хранилище. Это руководство посвящено этому уровню.
Предварительные условия
Клиент MCP с рабочим подключением к Cryptohopper MCP. См. обзор настройки.
Место для хранения данных. Это может быть локальный файл, база данных SQLite, JSON-объект в облаке или такой инструмент, как Notion. Для начала инфраструктура не требуется.
Что считается «памятью»
Три уровня, каждый полезен по разным причинам:
Уровень | Пример | Типичное местоположение |
Память сеанса | В рамках одного разговора модель помнит, что ты сказал ранее | Окно контекста модели (встроенное) |
Память между запусками | Текущий запуск агента помнит, что наблюдал прошлый запуск | Файл, база данных, Notion и т. д. |
Профиль пользователя | Агент знает твой список наблюдения, предпочитаемую биржу, предпочтения по риску | То же, что и между запусками; загружается при начале сеанса |
Память сеанса бесплатна и автоматическая. Память между запусками и профиль пользователя требуют настройки хранилища.
Настройка — профиль пользователя
Напиши короткий markdown-файл, описывающий тебя как криптопользователя. Удерживай его в пределах одной страницы:
О пользователе
Торгует в основном на Binance.
Список наблюдения: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Держит спот; запускает сетчатых ботов на SOL и AVAX через Cryptohopper.
Больше заботится о риске просадки, чем о упущенной прибыли.
Не торгует фьючерсами.
Настройки по умолчанию
Биржа: Binance
Котировка: USDT
Временной интервал ТА: 4ч (200 баров)
Толерантность к риску: умеренная
Предпочтения при постановке задач
Предпочитает конкретные числа вместо прилагательных.
Помечает спекуляции как спекуляции.
Если тикер неоднозначен, спрашивает, а не угадывает.Загружай его в начале каждого диалога с агентом. Два подхода:
Ручное копирование: в сеансе первое, что нужно сделать, это вставить файл.
Интеграция с клиентом: используй функцию постоянной памяти своего клиента (проекты Claude desktop, правила Cursor, контекст Zed) для автоматического добавления.
Держи файл небольшим. Все, что превышает ~300 строк, становится шумом, который модель пропускает. Суть в ограничениях, а не в автобиографии.
Версионируй его. Когда меняешь свой список наблюдения или предпочтения, фиксируй изменение в git (или истории Notion). Поведение твоего агента изменится вместе с профилем; ты захочешь понять, почему.
Настройка — память между запусками (простая)
Самая простая память между запусками — это один markdown-файл, который агент читает в начале и дополняет в конце:
Создай memory.md с каркасом:
Память агента Последние наблюдения (Добавляй записи сюда после каждого запуска.) Незавершенные пункты для отслеживания (Вещи, которые агент отметил для будущего внимания.) Прошлые решения (Заметные решения и их обоснование.)
В начале каждого запуска агента вставляй содержимое файла:
[ПАМЯТЬ АГЕНТА] {содержимое memory.md} [ЗАДАЧА] Сегодняшняя задача: запустить ежедневный дайджест.В конце каждого запуска добавляй новые наблюдения. Попроси агента явно их создать:
После выполнения задачи напиши 2-4 строки, суммируя все, что стоит запомнить на будущее. Используй следующий формат: [ГОД-МЕСЯЦ-ДЕНЬ] {наблюдение} Примеры: [2026-05-27] Объем SOL растет 3 дня подряд; держится в диапазоне примерно 83-87. [2026-05-27] Список наблюдения: отметил LINK как спокойный, но стоит проверить через 7 дней. Я вручную добавлю эти строки в memory.md.Периодически просматривай и обрезай. Примерно раз в неделю обрезай
memory.md— удаляй устаревшие записи, консолидируй паттерны. Неуправляемый файл памяти будет расти бесконечно и превратится в шум.
Настройка — память между запусками (структурированная)
Для агентов, которым выгодно иметь возможность запрашивать историю, хорошо подойдет небольшая база данных SQLite. Предложение по схеме:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- например, "daily-digest"
category TEXT, -- например, "volume-spike", "trend-change"
token TEXT, -- например, "SOL"
content TEXT NOT NULL, -- текст наблюдения
metadata JSON -- любые структурированные поля
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Это позволит тебе задавать такие вопросы, как: «Какие наблюдения мы сделали относительно SOL за последние 14 дней?» — и передавать ответ агенту в качестве контекста для сегодняшнего запуска.
Агент записывает в эту таблицу с помощью небольшого 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()
Используй это экономно. Структурированная память стоит затрат на настройку только тогда, когда ты действительно будешь ее запрашивать; для простого дайджеста markdown-файла обычно достаточно.
Что запоминать, а что нет
Хорошие кандидаты для запоминания:
«SOL торгуется в боковике в диапазоне 83–87 в течение 5 дней» — контекст диапазона, который не будет показан на завтрашнем запуске по одной свече.
«Вчера мы отметили аномалию объема по LINK; продолжить сегодня.»
«Пользователь спрашивал о сетчатых ботах для AVAX 2026-05-20; параметры были X, Y, Z.»
Плохие кандидаты для запоминания:
Сырые рыночные данные. Они меняются — перетягивай их из MCP, а не доверяй устаревшему кэшу.
Полные стенограммы разговоров. Соотношение сигнал/шум слишком низкое.
Автоматические сводки каждого запуска. Без кураторства они становятся в основном бесполезными.
Хороший тест: «Если я удалю эту запись из памяти, станет ли агент хуже работать на следующей неделе?» Если нет, удаляй.
Устранение неполадок
Агент ссылается на память, которая противоречит текущим данным.
Это фундаментальный риск кэшированного контекста. Агент «помнит», что SOL рос, но тренд с тех пор развернулся. Решение: проинструктируй агента всегда проверять утверждения из памяти на основе текущих данных MCP, прежде чем использовать их как факт. «Прежде чем полагаться на запись из памяти, проверь текущие данные и отметь, если память устарела».
Файлы памяти становятся непомерно большими.
Ты добавляешь без обрезки. Установи жесткое правило: раз в неделю просматривай записи за последнюю неделю и удаляй/объединяй. Или переключай файлы памяти ежемесячно (memory-2026-04.md, memory-2026-05.md).
Агент игнорирует блок памяти.
В запросе не указано, что агент должен его использовать. Будь точен: «просмотри блок памяти выше, прежде чем отвечать. Ссылайся на конкретные записи, где это применимо. Если запись противоречит свежим данным, отметь это явно».
Память вводит уверенные, но ошибочные ответы.
Агент считает память авторитетной. Представляй память как подсказки, а не истину: «память содержит прошлые наблюдения; рассматривай как контекст, а не факт. Всегда проверяй на основе текущих данных».
Ты хочешь, чтобы агент обновлял память без твоего вмешательства.
Возможно, но рискованно — неотслеживаемая память только для добавления быстро наберет плохие записи так же быстро, как и хорошие. Если ты автоматизируешь это, всегда сопровождай еженедельным этапом проверки. Никогда не позволяй памяти расти месяц без чтения.
Память нескольких агентов путается.
Если несколько агентов используют один файл памяти, используй поле agent_name для пространственной организации записей. Каждый агент читает только свои записи или читает весь файл, но знает, какой агент написал каждую строку.
Файл профиля пользователя устаревает. Предпочтения меняются. Если ты заметишь, что агент по умолчанию использует временной интервал или биржу, которые ты больше не используешь, обнови профиль — не обходи это переопределением в каждом запросе.