Cara Memberi Memori Manusia pada AI dengan Supermemory

TL;DR / Jawaban Singkat

Supermemory memberi Anda lapisan memori dan konteks untuk aplikasi AI, tetapi sistem memori lebih sulit di-debug daripada API CRUD normal. Alur kerja yang andal adalah menguji jalur penyerapan, profil, dan pencarian Supermemory secara langsung, menjaga nilai containerTag terisolasi per pengguna atau proyek, dan memverifikasi perilaku asinkron sebelum Anda memercayai apa yang ditampilkan klien atau agen MCP dalam obrolan.

Pendahuluan

Bug memori AI menjengkelkan karena jarang terlihat seperti bug API biasa. Permintaan Anda berhasil, tetapi agen mengingat fakta yang salah. Profil kosong untuk satu pengguna dan kelebihan beban untuk yang lain. Hasil pencarian terlihat bagus di notebook, lalu bising dalam produksi. Pada saat seseorang menyadarinya, masalah tersebut berada di balik pembungkus SDK, klien MCP, dan prompt.

Itulah mengapa supermemory layak untuk dicermati. Supermemory memposisikan dirinya sebagai lapisan memori dan konteks untuk AI dengan ekstraksi memori, profil pengguna, pencarian hibrida, konektor, pemrosesan file, dan server MCP untuk klien seperti Cursor, Claude Code, VS Code, Windsurf, dan Claude Desktop. Repo juga menunjukkan metode mulai cepat seperti client.add(), client.profile(), dan client.search.memories(), sementara dokumen API yang dihosting mengekspos endpoint seperti POST /v3/documents, POST /v3/search, dan POST /v4/profile.

Perpecahan itu penting. Tim aplikasi Anda tidak hanya membutuhkan "memori." Anda membutuhkan cara untuk memeriksa apa yang telah diserap, bagaimana itu dikelompokkan, apa yang dikembalikan oleh panggilan profil, dan apakah kueri pencarian hibrida menarik kombinasi konteks dokumen dan konteks pribadi yang tepat.

Mengapa API Memori AI Lebih Sulit Di-debug Daripada API Standar

Bug API normal terlihat cepat. Respons salah, kode status salah, atau permintaan tidak pernah mencapai layanan.

Sistem memori berbeda. Anda bisa mendapatkan 200 kembali dan masih memiliki perilaku produk yang salah karena pertanyaan sebenarnya bukan "apakah permintaan berhasil?" Ini adalah:

• Apakah konten yang tepat diserap?
• Apakah itu dilampirkan ke pengguna atau lingkup proyek yang benar?
• Apakah ekstraksi profil selesai sebelum permintaan berikutnya?
• Apakah kueri pencarian menggunakan mode dan ambang batas yang tepat?
• Apakah fakta yang lebih baru menimpa yang lebih lama?
• Apakah klien MCP meneruskan batas konteks yang sama dengan yang Anda gunakan dalam pengujian API Anda?

Supermemory dibangun di sekitar bagian-bagian yang bergerak tersebut. Repositori ini menjelaskan:

• ekstraksi memori dari percakapan dan dokumen
• profil pengguna dengan konteks statis dan dinamis
• pencarian hibrida di seluruh memori dan dokumen
• konektor seperti Google Drive, Gmail, Notion, OneDrive, GitHub, dan web crawling
• pemrosesan file untuk PDF, gambar, video, dan kode
• server MCP untuk klien AI

Itu kuat, tetapi itu juga berarti Anda men-debug status, waktu, dan kualitas pengambilan secara bersamaan.

Berikut adalah bentuk masalahnya:

Aplikasi atau klien MCP -> Penyerapan Supermemory -> pembaruan ekstraksi/profil -> panggilan pencarian/profil -> prompt agen -> jawaban yang terlihat oleh pengguna

Jika Anda hanya menguji dari lapisan obrolan, Anda tidak dapat mengetahui tahapan mana yang salah. Jika Anda menguji alur API yang mendasari dalam ruang kerja permintaan bersama, Anda dapat mengisolasi setiap tahapan.

Apa yang Supermemory Berikan kepada Anda dari Kotak

Repositori supermemory melakukan pekerjaan yang bagus untuk menunjukkan bentuk produk sebelum Anda menyentuh API yang dihosting.

Dari README, primitif utama yang dihadapi pengembang adalah:

• client.add() untuk menyimpan konten
• client.profile() untuk mengambil profil pengguna dan hasil pencarian opsional
• client.search.memories() untuk pencarian hibrida
• dukungan unggah dokumen
• integrasi kerangka kerja untuk alat seperti Vercel AI SDK, LangChain, LangGraph, OpenAI Agents SDK, Mastra, Agno, dan n8n
• endpoint MCP untuk asisten seperti Claude, Cursor, dan VS Code

Dokumen tersebut menambahkan detail yang berguna: permukaan REST berversi dan dibagi berdasarkan kemampuan. Contoh dalam dokumen publik menunjukkan:

• POST /v3/documents untuk menyerap konten
• POST /v3/search untuk pencarian
• POST /v4/profile untuk pengambilan profil
• POST /v3/documents/file untuk unggahan file

Itu berarti tugas debugging pertama Anda bukanlah "mempelajari setiap fitur." Ini adalah "mengunci alur persis yang digunakan aplikasi Anda."

Untuk sebagian besar tim, alur tersebut adalah:

1. Kirim konten ke Supermemory
2. Kueri profil atau cari dengan cakupan pengguna atau proyek yang stabil
3. Konfirmasi apa yang harus dilihat aplikasi atau agen selanjutnya

Jika Anda tidak dapat mengulang tiga langkah tersebut dengan input dan output yang sama, produk AI Anda masih dalam mode prototipe.

Bangun Alur Kerja Uji Supermemory yang Andal

Langkah pertama terbaik adalah menguji Supermemory secara langsung sebelum Anda menambahkan pembungkus, antarmuka obrolan, atau orkestrasi agen Anda sendiri.

Langkah 1: Tentukan strategi cakupan Anda terlebih dahulu

Dokumen dan README Supermemory sama-sama menekankan containerTag atau containerTags. Perlakukan itu sebagai keputusan desain utama, bukan parameter kecil.

Rencana cakupan yang bersih terlihat seperti ini:

• satu tag untuk pengguna, seperti user_123
• satu tag untuk proyek aktif, seperti project_alpha
• nilai staging dan produksi yang terpisah

Jika Anda melewatkan ini, hasil pencarian dan profil Anda akan menjadi keruh dengan cepat.

Langkah 2: Serap satu set fakta yang diketahui

Gunakan payload kecil yang jelas terlebih dahulu. Jangan mulai dengan dump PDF raksasa atau sinkronisasi konektor penuh.

Berikut adalah contoh API langsung berdasarkan dokumen publik:

curl https://api.supermemory.ai/v3/documents \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "content": "User prefers TypeScript, ships API backends, and is debugging rate limits this week.",
 "containerTags": ["user_123", "project_alpha"],
 "customId": "session-001",
 "metadata": {
 "source": "support_chat",
 "team": "platform"
 }
 }'

Detail utamanya bukanlah konten itu sendiri. Ini adalah bahwa setiap bidang disengaja. Anda tahu fakta yang tepat, cakupan yang tepat, dan metadata yang tepat.

Langkah 3: Kueri profil setelah penyerapan

Endpoint profil adalah tempat perilaku memori menjadi lebih berguna daripada pencarian mentah karena mengembalikan tampilan ringkas dari pengguna.

curl https://api.supermemory.ai/v4/profile \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "containerTag": "user_123",
 "q": "What stack does this user prefer?"
 }'

Dokumen publik menunjukkan respons dengan:

• profile.static
• profile.dynamic
• searchResults

Itulah bentuk respons yang Anda ingin tim Anda periksa sebelum Anda mengatakan "agen mengingat dengan benar."

Langkah 4: Uji pencarian secara terpisah

Pencarian tidak identik dengan pengambilan profil. Jika aplikasi Anda menggunakan pengambilan untuk groundung atau pembuatan jawaban, ujilah secara independen.

curl https://api.supermemory.ai/v3/search \
 --request POST \
 --header "Authorization: Bearer $SUPERMEMORY_API_KEY" \
 --header "Content-Type: application/json" \
 --data '{
 "q": "What is the user working on?",
 "containerTag": "user_123",
 "searchMode": "hybrid",
 "limit": 5
 }'

Dokumen Supermemory merekomendasikan searchMode: "hybrid" ketika Anda menginginkan konteks memori dan dokumen dalam satu kueri. Itu adalah default yang baik untuk tim produk karena sesuai dengan cara kerja asisten AI nyata: konteks pribadi plus konteks basis pengetahuan, bukan salah satu atau yang lain.

Langkah 5: Periksa asumsi asinkron

Supermemory melakukan pemrosesan asinkron untuk alur dokumen dan file. Dokumen menunjukkan pemrosesan antrean dan perilaku berbasis status untuk unggahan. Itu berarti permintaan kedua Anda bisa "terlalu cepat" bahkan ketika yang pertama berhasil.

Ini adalah salah satu bug memori termudah untuk dilewatkan:

1. Serap konten
2. Kueri profil segera
3. Dapatkan hasil yang tipis atau tidak lengkap
4. Menyalahkan mesin memori alih-alih waktu

Itulah mengapa alur kerja pengujian Anda harus menyertakan penantian singkat atau polling di mana perilaku endpoint bersifat asinkron.

Ubah Supermemory menjadi Alur Kerja Uji yang Dapat Diulang

Di sinilah alur kerja API bersama menjadi berguna dengan cara yang tidak dimiliki cURL mentah. API memori bukan hanya tentang sintaks permintaan. Ini tentang kemampuan pengulangan.

Langkah 1: Buat lingkungan Supermemory

Buat variabel lingkungan seperti:

base_url = https://api.supermemory.ai
supermemory_api_key = sm_your_api_key
user_tag = user_123
project_tag = project_alpha
custom_id = session-001

Ini memberi Anda cara yang aman untuk beralih antara pengguna uji, proyek, dan ruang kerja tanpa mengedit permintaan secara manual.

Langkah 2: Buat permintaan penyerapan

Buat permintaan:

• Metode: POST
• URL: {{base_url}}/v3/documents
• Header: Authorization: Bearer {{supermemory_api_key}}
• Header: Content-Type: application/json
• Isi:

{
 "content": "User prefers TypeScript, ships API backends, and is debugging rate limits this week.",
 "containerTags": ["{{user_tag}}", "{{project_tag}}"],
 "customId": "{{custom_id}}",
 "metadata": {
 "source": "api_workflow_test"
 }
}

Kemudian tambahkan pernyataan seperti:

pm.test("Status is success", function () {
 pm.expect(pm.response.code).to.be.oneOf([200, 201, 202]);
});

pm.test("Response contains memory id", function () {
 const json = pm.response.json();
 pm.expect(json.id).to.exist;
});

Jika layanan mengembalikan queued, itu adalah informasi yang berguna, bukan kegagalan. Ini memberitahu Anda bahwa permintaan berikutnya perlu memperhitungkan waktu pemrosesan.

Langkah 3: Buat permintaan profil

Buat permintaan kedua:

• Metode: POST
• URL: {{base_url}}/v4/profile
• Isi:

{
 "containerTag": "{{user_tag}}",
 "q": "What stack does this user prefer?"
}

Pernyataan yang membantu:

pm.test("Profile payload exists", function () {
 const json = pm.response.json();
 pm.expect(json.profile).to.exist;
});

pm.test("Static or dynamic profile content returned", function () {
 const json = pm.response.json();
 const staticItems = json.profile?.static || [];
 const dynamicItems = json.profile?.dynamic || [];
 pm.expect(staticItems.length + dynamicItems.length).to.be.above(0);
});

Ini memungkinkan Anda memisahkan tiga kasus dengan cepat:

• penyerapan tidak terjadi
• penyerapan terjadi tetapi pemrosesan belum selesai
• profil ada tetapi kueri atau cakupan Anda salah

Langkah 4: Buat permintaan pencarian

Tambahkan permintaan ketiga untuk kualitas pengambilan:

{
 "q": "What is the user debugging?",
 "containerTag": "{{user_tag}}",
 "searchMode": "hybrid",
 "limit": 5
}

Pemeriksaan yang baik meliputi:

• waktu respons berada dalam target tim Anda
• setidaknya satu hasil dikembalikan
• hasil teratas mencakup topik yang diharapkan
• cakupan yang tepat muncul tanpa membocorkan konteks pengguna lain

Alat alur kerja API bersama sangat berguna di sini karena Anda dapat mengkloning permintaan yang sama dan membandingkan:

• searchMode: "hybrid" versus perilaku hanya memori
• satu containerTag versus yang lain
• ambang batas lebih rendah versus ambang batas lebih tinggi
• kueri singkat versus kueri bahasa alami yang bising

Perbandingan berdampingan semacam itu jauh lebih sulit dipertahankan dengan perintah shell satu kali.

Langkah 5: Ubah permintaan menjadi skenario

Ini adalah peningkatan alur kerja bernilai tertinggi untuk Supermemory.

Buat skenario uji yang melakukan ini:

1. Tambahkan konten
2. Tunggu sebentar jika alur Anda asinkron
3. Kueri profil
4. Kueri pencarian
5. Tegaskan bahwa profil dan hasil pencarian keduanya mencerminkan set fakta baru

Itu memberi Anda pengujian regresi yang dapat digunakan kembali untuk perilaku memori, bukan hanya ketersediaan endpoint.

Langkah 6: Dokumentasikan alur kerja untuk tim

Bug memori membuang-buang waktu karena melewati batas tim. Backend mengira pengambilan berfungsi. QA mengira pencarian bising. Produk mengira asisten mengarang cerita.

Jika Anda memublikasikan alur kerja di Apidog, semua orang dapat memeriksa:

• permintaan yang tepat yang digunakan untuk menyerap memori
• batas cakupan untuk pengguna atau proyek
• bentuk respons profil
• bentuk hasil pencarian
• pernyataan yang diharapkan tim Anda untuk lulus

Unduh Apidog gratis

Di Mana MCP Cocok dalam Lingkaran Debugging

Supermemory menyertakan jalur instalasi MCP cepat dan menunjukkan URL server MCP yang dihosting. Itu berguna untuk menghubungkan Claude, Cursor, Windsurf, atau VS Code dengan cepat, tetapi MCP bukanlah tempat untuk mulai men-debug.

Jika asisten Anda mengingat hal yang salah, kerjakan dalam urutan ini:

1. Periksa permintaan API langsung di ruang kerja API Anda
2. Verifikasi containerTag atau batas proyek yang tepat
3. Konfirmasi konten telah diserap dan diproses
4. Verifikasi profil dan hasil pencarian secara langsung
5. Baru setelah itu pindah ke konfigurasi klien MCP

Mengapa? Karena MCP menambahkan satu lapisan abstraksi lagi. Hasil penarikan yang buruk bisa berasal dari:

• kunci API atau mode otentikasi yang salah
• batas cakupan yang salah
• penyerapan yang usang atau tidak lengkap
• perilaku pemanggilan alat khusus klien
• instruksi prompt yang menyalahgunakan output memori

README Supermemory juga menunjukkan pola konfigurasi MCP manual seperti ini:

{
 "mcpServers": {
 "supermemory": {
 "url": "https://mcp.supermemory.ai/mcp"
 }
 }
}

Jika jalur klien itu berperilaku aneh, strategi isolasi tercepat Anda adalah mereproduksi perilaku memori yang mendasari melalui HTTP API terlebih dahulu.

Teknik Lanjutan dan Kesalahan Umum

Berikut adalah kesalahan yang paling penting dalam produksi.

1. Mencampur cakupan

Jika Anda menggunakan kembali containerTag yang sama di seluruh pengguna yang tidak terkait, sistem memori terlihat bising bahkan ketika mesin melakukan persis seperti yang Anda minta.

2. Hanya menguji jalur bahagia

Anda juga harus menguji:

• kueri profil sebelum penyerapan
• kueri profil segera setelah penyerapan
• pencarian dengan kueri yang lemah
• pencarian dengan tag proyek yang salah
• unggahan yang masih diproses

3. Memperlakukan profil dan pencarian sebagai dapat dipertukarkan

Keduanya memecahkan masalah yang berbeda. Profil adalah konteks pengguna yang dipadatkan. Pencarian adalah pengambilan. Aplikasi Anda mungkin membutuhkan salah satu, yang lain, atau keduanya.

4. Mengabaikan perbedaan versi

README repo berpusat pada metode SDK, sementara dokumen menunjukkan endpoint HTTP berversi seperti /v3 dan /v4. Kunci versi yang tepat yang digunakan tim Anda, lalu cerminkan itu dalam alur kerja pengujian API Anda.

5. Melewati pengujian pembaruan dan kontradiksi

Sistem memori berharga karena menangani perubahan seiring waktu. Jika pengguna mengubah preferensinya, pengujian Anda harus memeriksa apakah fakta yang lebih baru mengungguli yang lebih lama.

Alternatif dan Perbandingan

Ada tiga cara umum untuk bekerja dengan Supermemory selama pengembangan.

Inilah mengapa alat seperti Apidog cocok di samping Supermemory alih-alih menggantikannya. Supermemory memberi Anda mesin memori. Lapisan alur kerja memberi Anda cara yang dapat diulang untuk memvalidasi perilaku API mesin sebelum perilaku itu menjadi bagian dari produk AI yang lebih besar.

Kasus Penggunaan Dunia Nyata

Kopilot dukungan perlu mengingat tumpukan pilihan pengguna, insiden aktif, dan konteks akun terbaru. Supermemory dapat menyimpan memori itu, sementara alur kerja API bersama memvalidasi bahwa profil dan kueri pencarian mengembalikan fakta yang tepat untuk pengguna yang tepat.

Tim produk yang menggunakan Cursor atau Claude Code dengan MCP menginginkan memori asisten di seluruh proyek jangka panjang. Sebelum memercayai pengalaman obrolan, tim harus memverifikasi penyerapan, batas cakupan, dan kualitas pengambilan langsung terhadap API.

Tim platform yang menyinkronkan dokumen dari GitHub atau Notion perlu mengkonfirmasi perilaku pencarian hibrida sebelum mengaktifkannya untuk agen internal. Alur kerja pengujian terstruktur membantu membandingkan kueri yang banyak dokumen dengan kueri yang banyak memori dalam suite yang sama.

Kesimpulan

Supermemory menarik karena memperlakukan memori sebagai infrastruktur, bukan demo pencarian vektor yang tipis. Repositori dan dokumen menunjukkan platform yang luas: penyerapan, profil, pencarian, konektor, penanganan file, integrasi kerangka kerja, dan dukungan MCP. Masalahnya adalah perilaku memori mudah disalahpahami jika Anda hanya menguji dari permukaan obrolan.

Jika Anda melakukan itu sebelum mengirimkan agen atau alur kerja bertenaga MCP, Anda menangkap bug yang paling sulit dijelaskan nanti. Jika Anda menginginkan cara yang lebih cepat untuk menyimpan permintaan, menambahkan pernyataan, dan membagikan seluruh alur kerja memori dengan tim Anda, Apidog adalah pilihan yang tepat untuk lapisan itu tanpa mengambil alih artikel itu sendiri.

FAQ

Untuk apa Supermemory digunakan?

Supermemory digunakan untuk menambahkan memori, profil, pencarian, konektor, dan pengambilan konteks ke aplikasi dan agen AI. Repositori dan dokumen publik memposisikannya sebagai lapisan memori dan konteks daripada hanya alat pencarian vektor.

Apakah Supermemory memiliki REST API?

Ya. Dokumen publik menunjukkan endpoint HTTP berversi untuk dokumen, pencarian, pengambilan profil, dan unggahan file, sementara README juga mengekspos metode SDK yang memetakan ke kemampuan tersebut.

Mengapa API memori AI lebih sulit di-debug daripada API normal?

Karena respons yang berhasil tidak menjamin perilaku yang tepat bagi pengguna. Anda juga perlu memvalidasi cakupan, waktu, ekstraksi profil, kualitas pengambilan, dan bagaimana output tersebut dikonsumsi oleh agen.

Apa yang harus saya uji pertama di Supermemory?

Mulailah dengan satu permintaan penyerapan yang diketahui, satu permintaan profil, dan satu permintaan pencarian untuk satu cakupan pengguna atau proyek. Itu memberi Anda dasar sebelum Anda menambahkan konektor, file, atau klien MCP.

Dapatkah alat alur kerja API membantu jika aplikasi saya menggunakan MCP?

Ya. Ini membantu Anda memvalidasi perilaku HTTP API yang mendasari sebelum Anda men-debug klien asisten. Itu membuatnya lebih mudah untuk mengetahui apakah masalahnya ada dalam pengambilan memori atau lapisan MCP di atasnya.

Apa parameter Supermemory terpenting yang harus benar?

containerTag atau containerTags adalah salah satu yang terpenting karena mengontrol bagaimana memori dikelompokkan dan diambil. Strategi penandaan yang lemah menciptakan hasil yang bising bahkan jika penyerapan dan pencarian keduanya berhasil.