Примітка щодо сфери застосування. Cryptohopper MCP розроблений як stateless — кожен виклик інструмента є незалежним, а сервер нічого не зберігає між запитами. Пам'ять живе на стороні клієнта або у сховищі, яке ви контролюєте. Посібник стосується саме цього рівня.
Передумови
Клієнт MCP з робочим підключенням до Cryptohopper MCP. Див. огляд налаштувань.
Місце для зберігання даних. Це може бути локальний файл, база даних SQLite, JSON-блок, збережений у хмарі, або інструмент на кшталт Notion. Для початку інфраструктура не потрібна.
Що вважається "пам'яттю"
Три рівні, кожен корисний з різних причин:
Рівень | Приклад | Типове розташування |
Пам'ять сесії | Під час розмови модель пам'ятає, що ти сказав раніше | Контекстне вікно моделі (вбудоване) |
Пам'ять між запусками | Поточний запуск агента пам'ятає, що спостерігалося під час минулого тижневого запуску | Файл, база даних, Notion тощо |
Профіль користувача | Агент знає твій список спостереження, пріоритетну біржу, схильність до ризику | Те саме, що й між запусками; завантажується на початку сесії |
Пам'ять сесії безкоштовна та автоматична. Для пам'яті між запусками та профілю користувача потрібно налаштувати сховище.
Налаштування — профіль користувача
Напиши короткий markdown-файл, який описує тебе як крипто-користувача. Тримай його менше сторінки:
Про користувача
Торгує переважно на Binance.
Список спостереження: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Тримає спотові активи; запускає спотових ботів на SOL та AVAX через Cryptohopper.
Більше стурбований ризиком просадки, ніж втратою потенційного прибутку.
Не торгує ф'ючерсами.
Стандартні налаштування
Біржа: Binance
Валюта: USDT
Таймфрейм ТА: 4h (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 для неймспейсингу записів. Кожен агент читає лише свої записи, або читає повний файл, але знає, який агент написав який рядок.
Файл профілю користувача застаріває. Вподобання змінюються. Якщо помітиш, що агент використовує стандартний таймфрейм або біржу, яку ти більше не використовуєш, онови профіль — не обходь це за допомогою перевизначень у кожному запиті.