Notka zakresu. Cryptohopper MCP jest z natury bezstanowy — każde wywołanie narzędzia jest niezależne, a serwer niczego nie przechowuje między żądaniami. Pamięć znajduje się po stronie klienta lub w pamięci masowej, którą kontrolujesz. Ten przewodnik dotyczy tej warstwy.
Wymagania
Klient MCP z działającym połączeniem Cryptohopper MCP. Zobacz przegląd konfiguracji.
Miejsce do przechowywania danych. Może to być plik lokalny, baza danych SQLite, obiekt JSON przechowywany w chmurze lub narzędzie takie jak Notion. Na początek nie jest potrzebna żadna infrastruktura.
Co liczy się jako „pamięć”
Trzy warstwy, każda przydatna z różnych powodów:
Warstwa | Przykład | Typowa lokalizacja |
Pamięć sesji | W trakcie jednej rozmowy model pamięta, co wcześniej powiedziałeś | Okno kontekstu modelu (wbudowane) |
Pamięć między przebiegami | Dzisiejszy przebieg agenta pamięta, co zaobserwował zeszłotygodniowy przebieg | Plik, baza danych, Notion itp. |
Profil użytkownika | Agent zna Twoją listę obserwowanych, preferowaną giełdę, tolerancję ryzyka | Tak jak pamięć między przebiegami; ładowana na starcie sesji |
Pamięć sesji jest darmowa i automatyczna. Pamięć między przebiegami i profil użytkownika wymagają skonfigurowania magazynu.
Konfiguracja — profil użytkownika
Napisz krótki plik markdown opisujący siebie jako użytkownika kryptowalut. Zachowaj go poniżej jednej strony:
O użytkowniku
Handluje głównie na Binance.
Lista obserwowanych: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Posiada pozycje spot; uruchamia boty siatkowe na SOL i AVAX przez Cryptohopper.
Bardziej zależy mu na ryzyku spadku niż na przegapieniu zysku.
Nie handluje kontraktami futures.
Domyślne ustawienia
Giełda: Binance
Para: USDT
Okres TA: 4h (200 świec)
Tolerancja ryzyka: umiarkowana
Preferencje w promptach
Preferuj konkretne liczby zamiast przymiotników.
Oznaczaj spekulacje jako spekulacje.
Jeśli ticker jest niejednoznaczny, pytaj zamiast zgadywać.Załaduj go na początku każdej rozmowy z agentem. Dwa podejścia:
Ręczne wklejanie: na początku każdej sesji wklej plik.
Zintegrowane z klientem: użyj funkcji trwałej pamięci klienta (Projekty na pulpicie Claude'a, reguły Kursora, kontekst Zed), aby automatycznie wstrzyknąć.
Zachowaj niewielki rozmiar pliku. Cokolwiek powyżej ~300 linii staje się szumem, który model pomija. Chodzi o ograniczenia, a nie autobiografię.
Wersjonuj go. Kiedy zmienisz swoją listę obserwowanych lub preferencje, zatwierdź zmianę w git (lub historii Notion). Zachowanie Twojego agenta zmieni się wraz z profilem; będziesz chciał wiedzieć, dlaczego.
Konfiguracja — pamięć między przebiegami (prosta)
Najprostsza pamięć między przebiegami to pojedynczy plik markdown, który agent odczytuje na początku i do którego dopisuje na końcu:
Utwórz memory.md z szkieletem:
Pamięć agenta Ostatnie obserwacje (Dopisuj tu wpisy po każdym przebiegu.) Zaległe pozycje do obserwacji (Rzeczy, które agent oznaczył do przyszłej uwagi.) Poprzednie decyzje (Godne uwagi decyzje i ich uzasadnienie.)
Na początku każdego przebiegu agenta wstrzyknij zawartość pliku:
[PAMIĘĆ AGENTA] {zawartość memory.md} [ZADANIE] Dzisiejsze zadanie: uruchom dzienny skrót.Na końcu każdego przebiegu dodaj nowe obserwacje. Poproś agenta, aby je wyraźnie wygenerował:
Po wykonaniu zadania napisz 2-4 linie podsumowujące wszystko, co warto zapamiętać na przyszłość. Użyj tego formatu: [RRRR-MM-DD] {obserwacja} Przykłady: [2026-05-27] Wolumen SOL podwyższony przez 3 kolejne dni; utrzymuje się w przedziale około 83-87. [2026-05-27] Lista obserwowanych: oznaczyłem LINK jako spokojny, ale warto sprawdzić za 7 dni. Dopiszę to ręcznie do memory.md.Okresowo przeglądaj i przycinaj. Raz w tygodniu mniej więcej, przycinaj
memory.md— usuwaj przestarzałe wpisy, konsoliduj wzorce. Niezarządzany plik pamięci rośnie w nieskończoność i staje się szumem.
Konfiguracja — pamięć między przebiegami (strukturalna)
Dla agentów, którzy korzystają z historii możliwej do zapytania, dobrze działa mała baza danych SQLite. Sugerowana schemat:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- np. "daily-digest"
category TEXT, -- np. "volume-spike", "trend-change"
token TEXT, -- np. "SOL"
content TEXT NOT NULL, -- tekst obserwacji
metadata JSON -- wszelkie pola strukturalne
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Pozwala to na zadawanie zapytań typu: „jakie obserwacje dotyczące SOL poczyniliśmy w ciągu ostatnich 14 dni?” — i przekazanie odpowiedzi agentowi jako kontekstu dla dzisiejszego przebiegu.
Agent zapisuje do tej tabeli za pomocą małego pomocnika Pythona:
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()
Używaj tego oszczędnie. Pamięć strukturalna jest warta konfiguracji tylko wtedy, gdy faktycznie będziesz jej używać do zapytań; w przypadku prostego skrótu, plik markdown jest zazwyczaj wystarczający.
Co zapamiętać, a czego nie
Dobre kandydaty do zapamiętania:
„SOL od 5 dni porusza się w trendzie bocznym w przedziale 83–87” — kontekst zakresu, którego pojedyncza dzisiejsza świeca nie pokaże w jutrzejszym przebiegu.
„Wczoraj oznaczyliśmy LINK do anomalii wolumenu; kontynuujemy dzisiaj.”
„Użytkownik zapytał o boty siatkowe dla AVAX w dniu 2026-05-20; parametry były X, Y, Z.”
Nie są to dobre kandydaty do zapamiętania:
Surowe dane rynkowe. Zmieniają się — pobieraj je ponownie z MCP zamiast polegać na przestarzałej pamięci podręcznej.
Pełne transkrypcje rozmów. Stosunek sygnału do szumu jest zbyt niski.
Automatyczne podsumowania każdego przebiegu. Bez kuracji stają się w większości bezużyteczne.
Dobry test: „jeśli usunę ten wpis z pamięci, czy agent będzie gorzej działał w przyszłym tygodniu?” Jeśli nie, usuń go.
Rozwiązywanie problemów
Agent cytuje dane z pamięci, które są sprzeczne z bieżącymi danymi.
To jest podstawowe ryzyko buforowanego kontekstu. Agent „pamięta”, że SOL był w trendzie wzrostowym, ale od tego czasu nastąpiło odwrócenie. Naprawa: poinstruuj agenta, aby zawsze weryfikował twierdzenia z pamięci z bieżącymi danymi MCP przed traktowaniem ich jako faktu. „Przed poleganiem na wpisie z pamięci, sprawdź bieżące dane i oznacz, jeśli pamięć jest nieaktualna.”
Pliki pamięci stają się niezarządzalnie duże.
Dopisujesz bez przycinania. Ustaw twardą zasadę: raz w tygodniu przejrzyj wpisy z ostatniego tygodnia i usuń / połącz. Lub obracaj pliki pamięci co miesiąc (memory-2026-04.md, memory-2026-05.md).
Agent ignoruje blok pamięci.
Prompt nie wymaga od agenta jego użycia. Bądź precyzyjny: „przejrzyj powyższy blok pamięci przed odpowiedzią. Odwołuj się do konkretnych wpisów, gdzie to stosowne. Jeśli wpis jest sprzeczny ze świeżymi danymi, oznacz to wyraźnie.”
Pamięć wprowadza pewne, ale błędne odpowiedzi.
Agent traktuje pamięć jako autorytatywną. Ustawiaj pamięć jako wskazówki, a nie prawdę: „pamięć zawiera przeszłe obserwacje; traktuj jako kontekst, a nie fakt. Zawsze weryfikuj z bieżącymi danymi.”
Chcesz, aby agent aktualizował pamięć bez Twojej interwencji.
Możliwe, ale ryzykowne — monitorowana pamięć tylko do dopisywania gromadzi złe wpisy tak szybko, jak dobre. Jeśli zautomatyzujesz to, zawsze połącz to z cotygodniowym etapem przeglądu. Nigdy nie pozwól, aby pamięć rosła przez miesiąc bez odczytu.
Pamięć wielu agentów myli się.
Jeśli wielu agentów dzieli jeden plik pamięci, użyj pola agent_name do nazewnictwa wpisów. Każdy agent odczytuje tylko swoje wpisy, lub odczytuje cały plik, ale wie, który agent napisał który wiersz.
Plik profilu użytkownika staje się przestarzały. Preferencje się zmieniają. Jeśli zauważysz, że agent domyślnie ustawia okres lub giełdę, której już nie używasz, zaktualizuj profil — nie obchodź tego za pomocą przesłonięć w każdym prompcie.