Catatan Lingkup. MCP Cryptohopper dirancang stateless — setiap panggilan alat independen, dan server tidak menyimpan apa pun di antara permintaan. Memori hidup di sisi klien atau di penyimpanan yang Anda kontrol. Panduan ini tentang lapisan itu.

Prasyarat

Klien MCP dengan koneksi MCP Cryptohopper yang berfungsi. Lihat gambaran umum penyiapan.
Tempat untuk menyimpan data. Ini bisa berupa file lokal, database SQLite, blob JSON yang disimpan di cloud, atau alat seperti Notion. Tidak perlu infrastruktur untuk memulai.

Apa saja yang termasuk "memori"

Tiga lapisan, masing-masing berguna untuk alasan yang berbeda:

Lapisan	Contoh	Lokasi Umum
Memori Sesi	Dalam satu percakapan, model mengingat apa yang kamu katakan sebelumnya	Jendela konteks model (bawaan)
Memori Lintas Jalur	Jalur agen hari ini mengingat apa yang diamati jalur minggu lalu	File, database, Notion, dll.
Profil Pengguna	Agen tahu daftar pantauanmu, bursa pilihanmu, preferensi risikomu	Sama seperti lintas jalur; dimuat saat sesi dimulai

Memori sesi gratis dan otomatis. Memori lintas jalur dan profil pengguna mengharuskan kamu menyiapkan penyimpanan.

Penyiapan — profil pengguna

Tulis file markdown pendek yang menjelaskan dirimu sebagai pengguna kripto. Jaga agar tidak lebih dari satu halaman:


Tentang pengguna
  Utamanya trading di Binance.
  Daftar Pantauan: BTC, ETH, SOL, AVAX, ARB, OP, LINK, AAVE, UNI.
  Memegang spot; menjalankan bot grid di SOL dan AVAX melalui Cryptohopper.
  Lebih peduli pada risiko drawdown daripada kehilangan potensi kenaikan.
  Tidak trading perpetual.

Default
  Bursa:       Binance
  Quote:       USDT
  Timeframe TA:   4j (200 bar)
  Toleransi Risiko: moderat

Preferensi prompt
  Lebih memilih angka konkret daripada kata sifat.
  Menandai spekulasi sebagai spekulasi.
  Jika ticker ambigu, tanyakan daripada menebak.

Muat saat setiap percakapan agen dimulai. Dua pendekatan:
- Tempel Manual: hal pertama di setiap sesi, tempel file.
- Terintegrasi Klien: gunakan fitur memori persisten klienmu (Proyek desktop Claude, aturan Cursor, konteks Zed) untuk menyuntikkan secara otomatis.
Jaga agar file tetap kecil. Apa pun yang lebih dari ~300 baris akan menjadi kebisingan yang dilewati model. Poinnya adalah batasan, bukan otobiografi.
Versionalkan. Saat kamu mengubah daftar pantauan atau preferensimu, commit perubahan ke git (atau riwayat Notion). Perilaku agenmu akan berubah dengan profil; kamu akan ingin tahu alasannya.

Penyiapan — memori lintas jalur (sederhana)

Memori lintas jalur paling sederhana adalah satu file markdown yang dibaca agen di awal dan ditambahkan di akhir:

Buat memory.md dengan kerangka:

Memori Agen  Pengamatan terbaru (Tambahkan entri di sini setelah setiap jalur.)  Item tertunda untuk dipantau (Hal-hal yang ditandai agen untuk perhatian di masa mendatang.)  Keputusan masa lalu (Keputusan penting dan alasannya.)

Di awal setiap jalur agen, suntikkan isi file:

[MEMORI AGEN] {isi memory.md}  [TUGAS] Tugas hari ini: jalankan ringkasan harian.

Di akhir setiap jalur, tambahkan pengamatan baru. Minta agen untuk menghasilkannya secara eksplisit:

Setelah menyelesaikan tugas, tulis 2-4 baris merangkum apa pun yang patut diingat untuk lain waktu. Gunakan format ini:  [YYYY-MM-DD] {pengamatan}  Contoh: [2026-05-27] Volume SOL meningkat selama 3 hari berturut-turut; menahan rentang sekitar 83-87. [2026-05-27] Daftar Pantauan: menandai LINK sebagai tenang tetapi layak diperiksa dalam 7 hari.  Saya akan menambahkannya ke memory.md secara manual.

Tinjau dan pangkas secara berkala. Sekitar seminggu sekali, pangkas `memory.md` — hapus entri usang, konsolidasikan pola. File memori yang tidak dikelola akan tumbuh tanpa batas dan menjadi kebisingan.

Penyiapan — memori lintas jalur (terstruktur)

Untuk agen yang mendapat manfaat dari riwayat yang dapat ditanyai, database SQLite kecil bekerja dengan baik. Saran skema:

sql

CREATE TABLE observations (
    id          INTEGER PRIMARY KEY,
    run_at      TEXT NOT NULL,   -- ISO-8601
    agent_name  TEXT NOT NULL,   -- contoh: "ringkasan-harian"
    category    TEXT,            -- contoh: "lonjakan-volume", "perubahan-tren"
    token       TEXT,            -- contoh: "SOL"
    content     TEXT NOT NULL,   -- teks pengamatan
    metadata    JSON             -- bidang terstruktur apa pun
);

CREATE INDEX idx_run_at ON observations(run_at);
CREATE INDEX idx_agent_token ON observations(agent_name, token);

Ini memungkinkanmu mengajukan kueri seperti: "pengamatan apa yang kita buat tentang SOL dalam 14 hari terakhir?" — dan memberikan jawabannya kepada agen sebagai konteks untuk jalur hari ini.

Agen menulis ke tabel ini melalui pembantu Python kecil:

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()

Gunakan ini secara hemat. Memori terstruktur hanya sepadan dengan penyiapannya jika kamu benar-benar akan menanyakannya; untuk ringkasan sederhana, file markdown biasanya cukup.

Apa yang perlu diingat, apa yang tidak

Kandidat memori yang baik:

"SOL telah trending sideways dalam rentang 83–87 selama 5 hari" — konteks rentang yang tidak akan ditunjukkan oleh satu lilin harian pada jalur besok.
"Kami menandai LINK untuk anomali volume kemarin; tindak lanjuti hari ini."
"Pengguna bertanya tentang bot grid untuk AVAX pada 2026-05-20; parameternya adalah X, Y, Z."

Bukan kandidat memori yang baik:

Data pasar mentah. Itu berubah — tarik ulang dari MCP daripada mempercayai cache yang sudah usang.
Transkrip percakapan lengkap. Rasio sinyal terhadap kebisingan terlalu rendah.
Ringkasan otomatis dari setiap jalur. Tanpa kurasi, ini sebagian besar menjadi tidak berguna.

Tes yang baik: "jika saya menghapus entri memori ini, apakah agen akan berperilaku lebih buruk minggu depan?" Jika tidak, hapus.

Pemecahan Masalah

Agen mengutip memori yang bertentangan dengan data saat ini.

Ini adalah risiko mendasar dari konteks yang di-cache. Agen "mengingat" SOL sedang tren naik, tetapi sekarang sudah berbalik arah. Perbaikan: instruksikan agen untuk selalu memverifikasi klaim memori terhadap data MCP saat ini sebelum menggunakannya sebagai fakta. "Sebelum mengandalkan entri memori, periksa data saat ini dan tandai jika memori sudah usang."

File memori tumbuh tidak terkendali.

Kamu menambahkan tanpa memangkas. Tetapkan aturan keras: seminggu sekali, tinjau entri seminggu terakhir dan hapus/gabungkan. Atau rotasi file memori setiap bulan (memory-2026-04.md, memory-2026-05.md).

Agen mengabaikan blok memori.

Prompt tidak menuntut agen untuk menggunakannya. Jadilah eksplisit: "tinjau blok memori di atas sebelum menjawab. Rujuk entri spesifik jika relevan. Jika entri bertentangan dengan data baru, tandai itu secara eksplisit."

Memori memperkenalkan jawaban yang yakin tetapi salah.

Agen memperlakukan memori sebagai otoritatif. Bingkai memori sebagai petunjuk, bukan kebenaran: "memori berisi pengamatan masa lalu; perlakukan sebagai konteks, bukan fakta. Selalu verifikasi terhadap data saat ini."

Kamu ingin agen memperbarui memori tanpa intervensimu.
Mungkin tetapi berisiko — memori hanya-tambah tanpa pengawasan tumbuh entri buruk secepat entri baik. Jika kamu mengotomatiskannya, selalu pasangkan dengan langkah peninjauan mingguan. Jangan pernah biarkan memori tumbuh selama sebulan tanpa dibaca.

Memori multi-agen menjadi bingung.
Jika beberapa agen berbagi satu file memori, gunakan bidang `agent_name` untuk menamai entri. Setiap agen membaca hanya entri miliknya, atau membaca seluruh file tetapi tahu agen mana yang menulis baris mana.

File profil pengguna menjadi usang. Preferensi berubah. Jika kamu melihat agen menggunakan timeframe atau bursa default yang tidak lagi kamu gunakan, perbarui profil — jangan mengatasinya dengan penggantian per-prompt.

cara menambahkan memori ke agen AI kriptomu