Poznámka k rozsahu. Cryptohopper MCP je navržen jako bezstavový — každý volání nástroje je nezávislé a server nic neukládá mezi požadavky. Paměť sídlí na straně klienta nebo v úložišti, které ovládáš. Tento průvodce je o této vrstvě.
Předpoklady
Klient MCP s funkčním připojením k Cryptohopper MCP. Viz přehled nastavení.
Místo pro ukládání dat. Může to být lokální soubor, databáze SQLite, JSON blob uložený v cloudu nebo nástroj jako Notion. Pro začátek není potřeba žádná infrastruktura.
Co se počítá jako "paměť"
Tři vrstvy, každá užitečná z jiných důvodů:
Vrstva | Příklad | Typické umístění |
Paměť relace | V rámci jedné konverzace si model pamatuje, co jsi řekl dříve | Kontextové okno modelu (vestavěné) |
Paměť napříč spuštěními | Dnešní spuštění agenta si pamatuje, co pozoroval minulý týden | Soubor, databáze, Notion atd. |
Uživatelský profil | Agent zná tvůj watchlist, preferovanou burzu, aversion k riziku | Stejné jako napříč spuštěními; načteno na začátku relace |
Paměť relace je zdarma a automatická. Paměť napříč spuštěními a uživatelský profil vyžadují nastavení úložiště.
Nastavení — uživatelský profil
Napiš krátký markdown soubor popisující sebe jako kryptouživatele. Udrž ho pod jednu stránku:
O uživateli
Primárně obchoduje na Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Drží spot; spouští grid boty na SOL a AVAX přes Cryptohopper.
Více se stará o riziko propadu než o zmeškání růstu.
Neobchoduje futures.
Výchozí nastavení
Burza: Binance
Měna: USDT
Časový rámec TA: 4h (200 barů)
Tolerance rizika: střední
Preferované zadávání pokynů
Preferuje konkrétní čísla před adjektivy.
Spekulaci označuje jako spekulaci.
Pokud je ticker nejednoznačný, raději se zeptá, než aby hádal.Načti ho na začátku každé konverzace s agentem. Dva přístupy:
Ruční vložení: první věc v každé relaci vlož soubor.
Integrované v klientovi: použij funkci persistentní paměti svého klienta (projekty Claude desktop, pravidla Cursor, kontext Zed) k automatickému vkládání.
Udržuj soubor malý. Cokoliv nad ~300 řádků se stane šumem, který model přeskočí. Pointou jsou omezení, ne autobiografie.
Verzuj ho. Když změníš watchlist nebo preference, potvrď změnu do gitu (nebo historie Notion). Chování agenta se s profilem změní; budeš chtít vědět proč.
Nastavení — paměť napříč spuštěními (jednoduchá)
Nejjednodušší pamětí napříč spuštěními je jeden markdown soubor, který agent čte na začátku a na konci jej obohacuje:
Vytvoř memory.md se základem:
Agent paměť Nedávná pozorování (Záznamy přidávej sem po každém spuštění.) Neuzavřené položky ke sledování (Věci, které agent označil pro budoucí pozornost.) Minulá rozhodnutí (Významná rozhodnutí a jejich odůvodnění.)
Na začátku každého spuštění agenta vlož obsah souboru:
[PAMĚŤ AGENTA] {obsah souboru memory.md} [ÚKOL] Dnešní úkol: spustit denní souhrn.Na konci každého spuštění přidávej nová pozorování. Požádej agenta, aby je explicitně vytvořil:
Po dokončení úkolu napiš 2-4 řádky shrnující cokoliv pozoruhodného, co stojí za zapamatování pro příště. Použij tento formát: [RRRR-MM-DD] {pozorování} Příklady: [2026-05-27] Objem SOL zvýšený 3 dny v řadě; drží se zhruba v rozmezí 83-87. [2026-05-27] Watchlist: označil LINK jako klidný, ale stojí za kontrolu za 7 dní. Přidám je ručně do memory.md.Pravidelně kontroluj a promazávej. Zhruba jednou týdně prořež
memory.md— smaž staré položky, konsoliduj vzorce. Nespravovaný soubor paměti roste neomezeně a stává se šumem.
Nastavení — paměť napříč spuštěními (strukturovaná)
Pro agenty, kterým prospívá prohledávatelná historie, dobře poslouží malá databáze SQLite. Návrh schématu:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- např. "daily-digest"
category TEXT, -- např. "volume-spike", "trend-change"
token TEXT, -- např. "SOL"
content TEXT NOT NULL, -- text pozorování
metadata JSON -- jakákoliv strukturovaná pole
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
To ti umožní pokládat dotazy jako: "jaká pozorování jsme udělali ohledně SOL za posledních 14 dní?" — a odpověď předat agentovi jako kontext pro dnešní spuštění.
Agent zapisuje do této tabulky pomocí malého Python pomocníka:
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()
Používej to střídmě. Strukturovaná paměť stojí za nastavení jenom v případě, že ji skutečně budeš využívat; pro jednoduchý souhrn, markdown soubor je obvykle dostatečný.
Co si pamatovat, co ne
Dobří kandidáti na zapamatování:
"SOL se již 5 dní pohybuje do strany v pásmu 83–87" — kontext rozsahu, který svíčka jednoho dne neukáže při zítřejším spuštění.
"Včera jsme označili LINK kvůli objemové anomálii; dnes navázat."
"Uživatel se zeptal na grid boty pro AVAX dne 2026-05-20; parametry byly X, Y, Z."
Ne dobří kandidáti na zapamatování:
Surová tržní data. Mění se — znovu je načti z MCP namísto spoléhání na zastaralou cache.
Plné přepisy konverzací. Poměr signálu k šumu je příliš nízký.
Automatické souhrny každého spuštění. Bez kurace se stávají většinou k ničemu.
Dobrý test: „pokud tuto položku paměti smažu, bude agent příští týden fungovat hůře?“ Pokud ne, smaž ji.
Řešení problémů
Agent cituje paměť, která je v rozporu s aktuálními daty.
Toto je základní riziko cachovaného kontextu. Agent si "pamatuje", že SOL rostl, ale od té doby se otočil. Oprava: instruuj agenta, aby vždy ověřil tvrzení z paměti proti aktuálním datům MCP, než je použije jako fakta. "Než se spolehneš na položku v paměti, zkontroluj aktuální data a upozorni, pokud je paměť zastaralá."
Soubory paměti se stávají nezvládnutelně velkými.
Přidáváš bez promazávání. Nastav si pevné pravidlo: jednou týdně zkontroluj záznamy za poslední týden a smaž / slouč je. Nebo měň soubory paměti měsíčně (memory-2026-04.md, memory-2026-05.md).
Agent ignoruje blok paměti.
Prompt nevyžaduje, aby ho agent používal. Buď explicitní: "před zodpovězením zkontroluj výše uvedený blok paměti. Odkazuj na konkrétní položky, kde je to relevantní. Pokud položka odporuje čerstvým datům, explicitly naní upozorni."
Paměť zavádí sebevědomé, ale mylné odpovědi.
Agent považuje paměť za autoritativní. Rámování paměti jako nápovědy, ne pravdy: "paměť obsahuje minulá pozorování; považuj ji za kontext, ne za fakt. Vždy ověřuj proti aktuálním datům."
Chceš, aby agent aktualizoval paměť bez tvého zásahu.
Možné, ale riskantní — ne monitorované paměti pouze s přidáváním nových záznamů se zaplňují stejně rychle dobrými jako špatnými. Pokud to automatizuješ, vždy to spoj s týdenním krokem revize. Nikdy nenech paměť růst měsíc bez toho, aby byla přečtena.
Paměť více agentů se zamotává.
Pokud více agentů sdílí jeden soubor paměti, použij pole agent_name k jmennému prostoru záznamů. Každý agent čte pouze své vlastní záznamy, nebo čte celý soubor, ale ví, který agent kterou řádku napsal.
Soubor uživatelského profilu zastarává. Preference se mění. Pokud si všimneš, že agent používá výchozí časový rámec nebo burzu, kterou už nepoužíváš, aktualizuj profil — neobcházej to výchozími přepisy pro každý prompt.