Umfangsdefinition. Der Cryptohopper MCP ist stateless konzipiert – jeder Tool-Aufruf ist unabhängig, und der Server speichert nichts zwischen den Anfragen. Speicher lebt clientseitig oder in von dir kontrolliertem Speicher. Dies hier ist eine Anleitung zu dieser Ebene.
Voraussetzungen
Ein MCP-Client mit einer funktionierenden Cryptohopper MCP-Verbindung. Siehe Setup-Übersicht.
Ein Ort zur Datenspeicherung. Dies kann eine lokale Datei, eine SQLite-Datenbank, ein Cloud-gespeicherter JSON-Blob oder ein Tool wie Notion sein. Keine Infrastruktur erforderlich, um zu starten.
Was zählt als "Speicher"
Drei Ebenen, jede aus unterschiedlichen Gründen nützlich:
Ebene | Beispiel | Typischer Speicherort |
Sitzungsspeicher | Innerhalb einer Konversation erinnert sich das Modell, was du zuvor gesagt hast | Das Kontextfenster des Modells (eingebaut) |
Cross-Run-Speicher | Die gestrige Ausführung des Agenten erinnert sich an das, was die letzte Woche beobachtet wurde | Datei, Datenbank, Notion, etc. |
Benutzerprofil | Der Agent kennt deine Watchlist, deine bevorzugte Börse, deine Risikobereitschaft | Wie Cross-Run; wird beim Sitzungsstart geladen |
Sitzungsspeicher ist kostenlos und automatisch. Cross-Run- und Benutzerprofil-Speicher erfordern, dass du einen Speicher einrichtest.
Einrichtung – Benutzerprofil
Schreibe eine kurze Markdown-Datei, die dich als Kryptonutzer beschreibt. Halte sie unter einer Seite:
Über den Benutzer
Handelt hauptsächlich auf Binance.
Watchlist: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
Hält Spot; betreibt Grid-Bots auf SOL und AVAX über Cryptohopper.
Legt mehr Wert auf Drawdown-Risiko als auf das Verpassen von Aufschlägen.
Handelt keine Perpetuals.
Standards
Börse: Binance
Quote: USDT
TA-Zeitrahmen: 4h (200 Bars)
Risikobereitschaft: moderat
Prompting-Präferenzen
Bevorzuge konkrete Zahlen gegenüber Adjektiven.
Spekulationen als Spekulationen kennzeichnen.
Wenn ein Ticker mehrdeutig ist, frage, anstatt zu raten.Lade sie zu Beginn jeder Agentenkonversation. Zwei Ansätze:
Manuelles Einfügen: zuerst in jeder Sitzung die Datei einfügen.
Client-integriert: nutze die persistente Speicherfunktion deines Clients (Claude Desktop Projects, Cursor rules, Zed context), um sie automatisch einzufügen.
Halte die Datei klein. Alles über ca. 300 Zeilen wird zu Rauschen, das das Modell überspringt. Der Punkt sind die Einschränkungen, nicht eine Autobiografie.
Versioniere sie. Wenn du deine Watchlist oder Präferenzen änderst, committe die Änderung an Git (oder Notion History). Das Verhalten deines Agenten ändert sich mit dem Profil; du wirst sehen wollen, warum.
Einrichtung – Cross-Run-Speicher (einfach)
Der einfachste Cross-Run-Speicher ist eine einzelne Markdown-Datei, die der Agent zu Beginn liest und am Ende hinzufügt:
Erstelle memory.md mit einem Skelett:
Agenten-Speicher Aktuelle Beobachtungen (Hier Einträge nach jeder Ausführung hinzufügen.) Offene Punkte zur Beobachtung (Dinge, die der Agent für zukünftige Aufmerksamkeit markiert hat.) Vergangene Entscheidungen (Bemerkenswerte Entscheidungen und ihre Begründung.)
Zu Beginn jeder Agentenausführung den Dateiinhalt einfügen:
[AGENTEN-SPEICHER] {Inhalt von memory.md} [AUFGABE] Heutige Aufgabe: den täglichen Digest ausführen.Am Ende jeder Ausführung neue Beobachtungen anhängen. Bitte den Agenten, sie explizit zu erstellen:
Nach Abschluss der Aufgabe, schreibe 2-4 Zeilen, die alles Bemerkenswerte zusammenfassen, das für das nächste Mal erinnert werden sollte. Verwende dieses Format: [YYYY-MM-DD] {Beobachtung} Beispiele: [2026-05-27] SOL-Volumen seit 3 Tagen erhöht; hält sich im Bereich von etwa 83-87. [2026-05-27] Watchlist: LINK als ruhig markiert, aber es lohnt sich, in 7 Tagen nachzuschauen. Ich werde diese manuell an memory.md anhängen.Regelmäßig überprüfen und bereinigen. Ungefähr einmal pro Woche, trimme
memory.md– lösche veraltete Einträge, konsolidiere Muster. Eine ungemanagte Speicherdatei wächst unendlich und wird zu Rauschen.
Einrichtung – Cross-Run-Speicher (strukturiert)
Für Agenten, die von abfragbarer Historie profitieren, eignet sich eine kleine SQLite-Datenbank gut. Schema-Vorschlag:
sql
CREATE TABLE observations (
id INTEGER PRIMARY KEY,
run_at TEXT NOT NULL, -- ISO-8601
agent_name TEXT NOT NULL, -- z.B. "daily-digest"
category TEXT, -- z.B. "volume-spike", "trend-change"
token TEXT, -- z.B. "SOL"
content TEXT NOT NULL, -- der Beobachtungstext
metadata JSON -- beliebige strukturierte Felder
);
CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);
Dies ermöglicht dir Abfragen wie: "Welche Beobachtungen haben wir über SOL in den letzten 14 Tagen gemacht?" – und die Antwort dem Agenten als Kontext für die heutige Ausführung zu geben.
Der Agent schreibt über einen kleinen Python-Helfer in diese Tabelle:
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()
Nutze dies sparsam. Strukturierter Speicher lohnt sich nur, wenn du ihn tatsächlich abfragst; für einen einfachen Digest ist die Markdown-Datei normalerweise ausreichend.
Was man sich merken sollte, was nicht
Gute Kandidaten für den Speicher:
"SOL hat sich 5 Tage lang seitwärts in einem Band von 83–87 bewegt" – Kontext über einen Zeitraum, den eine einzelne Tageskerze bei der morgigen Ausführung nicht zeigt.
"Wir haben LINK gestern wegen einer Volumenanomalie markiert; heute nachfassen."
"Benutzer fragte am 20.05.2026 nach Grid-Bots für AVAX; Parameter waren X, Y, Z."
Keine guten Kandidaten für den Speicher:
Rohe Marktdaten. Sie ändern sich – ziehe sie stattdessen wieder aus dem MCP, anstatt einem veralteten Cache zu vertrauen.
Vollständige Gesprächsprotokolle. Das Signal-Rausch-Verhältnis ist zu gering.
Automatische Zusammenfassungen jeder Ausführung. Ohne Kuratierung werden diese weitgehend nutzlos.
Ein guter Test: "Wenn ich diesen Speichereintrag lösche, verhält sich der Agent nächste Woche schlechter?" Wenn nein, lösche ihn.
Fehlerbehebung
Der Agent zitiert Speicher, der von aktuellen Daten widerlegt wird.
Das ist das grundlegende Risiko von zwischengespeichertem Kontext. Der Agent "erinnert" sich, dass SOL aufwärts tendierte, aber er hat sich seitdem umgekehrt. Lösung: weise den Agenten an, Gedächtnisansprüche immer gegen aktuelle MCP-Daten zu verifizieren, bevor er sie als Fakt verwendet. "Stelle sicher, dass die Gedächtniseinträge aktuell sind, indem du die aktuellen Daten prüfst und falls die Information veraltet ist, dies signalisierst."
Speicherdateien werden unübersichtlich groß.
Du fügst hinzu, ohne zu bereinigen. Stelle eine strikte Regel auf: Überprüfe einmal pro Woche die Einträge der letzten Woche und lösche/konsolidiere. Oder rotiere Speicherdateien monatlich (memory-2026-04.md, memory-2026-05.md).
Der Agent ignoriert den Speicherblock.
Der Prompt verlangt nicht, dass der Agent ihn nutzt. Sei explizit: "Überprüfe den obigen Speicherblock, bevor du antwortest. Beziehe dich, wo relevant, auf spezifische Einträge. Wenn ein Eintrag frische Daten widerspricht, weise explizit darauf hin."
Speicher führt zu zuversichtlichen, aber falschen Antworten.
Der Agent behandelt den Speicher als autoritativ. Stelle den Speicher als Hinweise, nicht als Wahrheit dar: "Der Speicher enthält vergangene Beobachtungen; behandle ihn als Kontext, nicht als Fakt. Vergleiche immer mit aktuellen Daten."
Du möchtest, dass der Agent den Speicher ohne dein Eingreifen aktualisiert.
Möglich, aber riskant – ungeprüfter, nur anfügender Speicher sammelt genauso schnell schlechte wie gute Einträge. Wenn du ihn automatisierst, koppele ihn immer mit einem wöchentlichen Überprüfungsschritt. Lasse Speicher niemals einen Monat lang wachsen, ohne ihn zu lesen.
Multi-Agenten-Speicher wird verwirrt.
Wenn mehrere Agenten eine Speicherdatei teilen, verwende das Feld agent_name, um Einträge zu benennen. Jeder Agent liest nur seine eigenen Einträge oder liest die gesamte Datei, weiß aber, welcher Agent welche Zeile geschrieben hat.
Die Benutzerprofil-Datei wird veraltet. Präferenzen ändern sich. Wenn du bemerkst, dass der Agent auf einen Zeitrahmen oder eine Börse standardmäßig zugreift, die du nicht mehr verwendest, aktualisiere das Profil – umgehe es nicht mit per-Prompt-Overrides.