Kami Mengekstrak Sistem Memori OpenClaw dan Sumber Terbuka (memsearch)

OpenClaw (sebelumnya clawdbot dan moltbot) menjadi viral - 189 ribu+ bintang GitHub dalam waktu kurang dari dua minggu. Ini sangat gila. Sebagian besar dari buzz yang ada adalah seputar kemampuannya yang otonom dan agen di seluruh saluran obrolan sehari-hari, termasuk iMessages, WhatsApp, Slack, Telegram, dan banyak lagi.

Namun sebagai insinyur yang bekerja pada sistem basis data vektor, yang benar-benar menarik perhatian kami adalah pendekatan OpenClaw terhadap memori jangka panjang. Tidak seperti kebanyakan sistem memori di luar sana, OpenClaw memiliki AI yang secara otomatis menulis log harian sebagai file Markdown. File-file tersebut adalah sumber kebenaran, dan model hanya "mengingat" apa yang dituliskan ke disk. Pengembang manusia dapat membuka file-file penurunan harga tersebut, mengeditnya secara langsung, menyaring prinsip-prinsip jangka panjang, dan melihat dengan tepat apa yang diingat oleh AI pada titik mana pun. Tidak ada kotak hitam. Sejujurnya, ini adalah salah satu arsitektur memori yang paling bersih dan paling ramah pengembang yang pernah kami lihat.

Jadi tentu saja, kami memiliki pertanyaan: mengapa ini hanya bekerja di dalam OpenClaw? Bagaimana jika ada agen yang bisa memiliki memori seperti ini? Kami mengambil arsitektur memori yang tepat dari OpenClaw dan membangun memsearch - perpustakaan memori jangka panjang yang berdiri sendiri, plug-and-play yang memberikan agen mana pun memori yang persisten, transparan, dan dapat diedit oleh manusia. Tidak ada ketergantungan pada bagian lain dari OpenClaw. Cukup masukkan saja, dan agen Anda akan mendapatkan memori yang tahan lama dengan pencarian yang didukung oleh Milvus/Zilliz Cloud, ditambah log penurunan harga sebagai sumber kebenaran kanonik.

• GitHub Repo: github.com/zilliztech/memsearch (sumber terbuka, lisensi MIT)

• Dokumentasi: https://zilliztech.github.io/memsearch/

• Plugin kode Claude: https://zilliztech.github.io/memsearch/claude-plugin/

Apa yang Membuat Memori OpenClaw Berbeda

Sebelum masuk ke dalam arsitektur memori OpenClaw, mari kita luruskan dua konsep: konteks dan memori. Keduanya terdengar mirip tetapi dalam praktiknya sangat berbeda.

• Konteks adalah segala sesuatu yang dilihat oleh agen dalam satu permintaan - perintah sistem, file panduan tingkat proyek seperti AGENTS.md dan SOUL.md, riwayat percakapan (pesan, panggilan alat, ringkasan yang dikompresi), dan pesan pengguna saat ini. Ini terbatas pada satu sesi dan relatif ringkas.

• Memori adalah apa yang bertahan di seluruh sesi. Memori ini berada di disk lokal Anda - riwayat lengkap percakapan sebelumnya, file yang pernah digunakan agen, dan preferensi pengguna. Tidak diringkas. Tidak dikompresi. Hal-hal yang masih mentah.

Sekarang, inilah keputusan desain yang membuat pendekatan OpenClaw menjadi istimewa: semua memori disimpan sebagai file Markdown biasa di sistem berkas lokal. Setelah setiap sesi, AI menulis pembaruan ke log Markdown tersebut secara otomatis. Anda-dan pengembang mana pun-dapat membukanya, mengeditnya, mengatur ulang, menghapusnya, atau menyempurnakannya. Sementara itu, basis data vektor berada di samping sistem ini, membuat dan memelihara indeks untuk pencarian. Setiap kali file Markdown berubah, sistem akan mendeteksi perubahan tersebut dan mengindeks ulang secara otomatis.

Jika Anda pernah menggunakan alat seperti Mem0 atau Zep, Anda akan segera melihat perbedaannya. Sistem-sistem tersebut menyimpan memori sebagai penyematan - itulah satu-satunya salinan. Anda tidak dapat membaca apa yang diingat oleh agen Anda. Anda tidak dapat memperbaiki memori yang buruk dengan mengedit sebuah baris. Pendekatan OpenClaw memberikan Anda keduanya: transparansi file biasa dan kekuatan pencarian vektor menggunakan basis data vektor. Anda bisa membacanya, git diff itu, grep itu - itu hanya file.

Satu-satunya kekurangannya? Saat ini sistem memori yang mengutamakan penurunan harga ini sangat terkait erat dengan ekosistem OpenClaw secara keseluruhan - proses Gateway, konektor platform, konfigurasi ruang kerja, dan infrastruktur pesan. Jika Anda hanya menginginkan model memori, maka akan ada banyak mesin yang harus diikutsertakan.

Itulah mengapa kami membangun memsearch: filosofi yang sama - Markdown sebagai sumber kebenaran, pengindeksan vektor otomatis, dapat diedit oleh manusia sepenuhnya - tetapi disampaikan sebagai pustaka mandiri yang ringan yang dapat Anda masukkan ke dalam arsitektur agen apa pun.

Bagaimana Memsearch Bekerja

Seperti yang telah disebutkan sebelumnya, memsearch adalah pustaka memori jangka panjang yang sepenuhnya independen yang mengimplementasikan arsitektur memori yang sama dengan yang digunakan di OpenClaw-tanpa membawa serta tumpukan OpenClaw lainnya. Anda dapat menyambungkannya ke dalam kerangka kerja agen apa pun (Claude, GPT, Llama, agen khusus, mesin alur kerja) dan secara instan memberikan memori yang persisten, transparan, dan dapat diedit oleh manusia kepada sistem Anda.

Semua memori agen dalam memsearch disimpan sebagai Markdown teks biasa dalam direktori lokal. Strukturnya sengaja dibuat sederhana agar para pengembang dapat memahaminya dengan cepat:

~/your-project/
└── memory/
    ├── MEMORY.md              # Hand-written long-term memory
    ├── 2026-02-09.md          # Today's work log
    ├── 2026-02-08.md
    └── 2026-02-07.md

Memsearch menggunakan Milvus sebagai basis data vektor untuk mengindeks berkas-berkas Markdown ini untuk pengambilan semantik yang cepat. Tetapi yang terpenting, indeks vektor bukanlah sumber kebenaran - berkas-berkasnya yang benar. Jika Anda menghapus indeks Milvus sepenuhnya, Anda tidak akan kehilangan apa pun. Memsearch hanya menyematkan kembali dan mengindeks ulang file Markdown, membangun kembali lapisan pengambilan penuh dalam beberapa menit. Ini berarti memori agen Anda transparan, tahan lama, dan dapat direkonstruksi sepenuhnya.

Berikut ini adalah kemampuan inti dari memsearch:

Markdown yang Dapat Dibaca Membuat Debugging Semudah Mengedit File

Debugging memori AI biasanya menyakitkan. Ketika sebuah agen menghasilkan jawaban yang salah, sebagian besar sistem memori tidak memberi Anda cara yang jelas untuk melihat apa yang sebenarnya disimpan. Alur kerja yang umum dilakukan adalah menulis kode khusus untuk meminta API memori, kemudian memilah-milah embedding yang tidak jelas atau gumpalan JSON yang bertele-tele-tidak ada yang memberi tahu Anda banyak tentang keadaan internal AI yang sebenarnya.

memsearch menghilangkan seluruh kelas masalah tersebut. Semua memori berada di dalam memori/folder sebagai Markdown biasa:

## Morning
- Fixed N+1 query issue — switched to selectinload()
- Query count dropped from 152 to 3

Jika AI melakukan kesalahan, memperbaikinya semudah mengedit file. Perbarui entri, simpan, dan memsearch secara otomatis mengindeks ulang perubahan. Lima detik. Tidak ada panggilan API. Tidak ada perkakas. Tidak ada misteri. Anda men-debug memori AI dengan cara yang sama seperti men-debug dokumentasi-dengan mengedit file.

Memori yang Didukung Git Berarti Tim Dapat Melacak, Meninjau, dan Mengembalikan Perubahan

Memori AI yang berada di dalam basis data sulit untuk dikolaborasikan. Mencari tahu siapa yang mengubah apa dan kapan berarti menggali log audit, dan banyak solusi yang tidak menyediakannya. Perubahan terjadi secara diam-diam, dan ketidaksepakatan tentang apa yang harus diingat oleh AI tidak memiliki jalur penyelesaian yang jelas. Tim akhirnya mengandalkan pesan dan asumsi Slack.

Memsearch memperbaiki masalah ini dengan menjadikan memori hanya sebagai berkas penurunan versi-yang berarti Git menangani pembuatan versi secara otomatis. Satu perintah menunjukkan seluruh riwayat:

git log memory/MEMORY.md
git diff HEAD~1 memory/2026-02-09.md

Sekarang memori AI berpartisipasi dalam alur kerja yang sama dengan kode. Keputusan arsitektur, pembaruan konfigurasi, dan perubahan preferensi semuanya muncul dalam diff yang dapat dikomentari, disetujui, atau dikembalikan oleh siapa pun:

+ ## Architecture Decision
+ - Use Kafka for event bus instead of RabbitMQ
+ - Reason: better horizontal scaling

Memori Plaintext Membuat Migrasi Menjadi Hampir Mudah

Migrasi adalah salah satu biaya tersembunyi terbesar dari kerangka kerja memori. Berpindah dari satu alat ke alat lain biasanya berarti mengekspor data, mengonversi format, mengimpor ulang, dan berharap bidang-bidang tersebut kompatibel. Pekerjaan semacam itu dapat dengan mudah menghabiskan setengah hari, dan hasilnya tidak pernah terjamin.

memsearch menghindari masalah ini sepenuhnya karena memori adalah plaintext Penurunan harga. Tidak ada format kepemilikan, tidak ada skema yang perlu diterjemahkan, tidak ada yang perlu dimigrasi:

• Pindah mesin: rsync folder memori. Selesai.

• Ganti model penyematan: Jalankan kembali perintah indeks. Ini akan memakan waktu lima menit, dan file penurunan harga tidak akan tersentuh.

• Ganti penyebaran basis data vektor: Mengubah satu nilai konfigurasi. Misalnya, beralih dari Milvus Lite dalam pengembangan ke Zilliz Cloud dalam produksi:

# Development
ms = MemSearch(milvus_uri="~/.memsearch/milvus.db")
# Production (change only this line)
ms = MemSearch(milvus_uri=“https://xxx.zillizcloud.com”)

File memori Anda tetap sama persis. Infrastruktur di sekitarnya dapat berkembang dengan bebas. Hasilnya adalah portabilitas jangka panjang - sifat yang langka dalam sistem AI.

File Penurunan Harga Bersama Memungkinkan Manusia dan Agen Menulis Memori Bersama

Di sebagian besar solusi memori, mengedit apa yang diingat oleh AI memerlukan penulisan kode terhadap API. Itu berarti hanya pengembang yang dapat mengelola memori AI, dan bahkan bagi mereka, hal ini merepotkan.

Memsearch memungkinkan pembagian tanggung jawab yang lebih alami:

• AI menangani: Catatan harian otomatis (YYYY-MM-DD.md) dengan detail eksekusi seperti "diterapkan v2.3.1, peningkatan kinerja 12%."

• Manusia menangani: Prinsip-prinsip jangka panjang di MEMORY.md, seperti "Tumpukan tim: Python + FastAPI + PostgreSQL."

Kedua belah pihak mengedit file Markdown yang sama dengan alat apa pun yang sudah mereka gunakan. Tidak ada pemanggilan API, tidak ada perkakas khusus, tidak ada penjaga gerbang. Ketika memori terkunci di dalam basis data, kepenulisan bersama seperti ini tidak mungkin dilakukan. memsearch menjadikannya sebagai default.

Di Balik Tudung: memsearch Berjalan pada Empat Alur Kerja yang Menjaga Memori Tetap Cepat, Segar, dan Ramping

memsearch memiliki empat alur kerja inti: Menonton (memantau) → Indeks (memotong dan menyematkan) → Cari (mengambil) → Ringkas (meringkas). Inilah yang dilakukan oleh masing-masing alur tersebut.

1. Perhatikan: Mengindeks Ulang Secara Otomatis pada Setiap Penyimpanan File

Alur kerja Watch memonitor semua file Markdown dalam memori/direktori dan memicu indeks ulang setiap kali sebuah file dimodifikasi dan disimpan. Debounce 1500ms memastikan pembaruan terdeteksi tanpa membuang-buang komputasi: jika beberapa penyimpanan terjadi secara berurutan, pengatur waktu akan diatur ulang dan menyala hanya ketika pengeditan telah stabil.

Penundaan itu disetel secara empiris:

• 100ms → terlalu sensitif; menyala pada setiap penekanan tombol, membakar panggilan penyematan

• 10 detik → terlalu lambat; pengembang menyadari adanya kelambatan

• 1500ms → keseimbangan ideal antara daya tanggap dan efisiensi sumber daya

Dalam praktiknya, ini berarti pengembang dapat menulis kode di satu jendela dan mengedit MEMORY.md di jendela lain, menambahkan URL dokumen API atau mengoreksi entri yang sudah ketinggalan zaman. Simpan file, dan kueri AI berikutnya akan mengambil memori yang baru. Tidak perlu memulai ulang, tidak perlu mengindeks ulang secara manual.

2. Indeks: Pemotongan Cerdas, Deduplikasi, dan Penyematan Sadar Versi

Index adalah alur kerja yang sangat penting bagi kinerja. Ini menangani tiga hal: chunking, deduplikasi, dan ID chunk berversi.

Pemenggalan membagi teks di sepanjang batas semantik-judul dan badan teks-sehingga konten yang terkait tetap bersama. Hal ini untuk menghindari kasus di mana frasa seperti "Konfigurasi Redis" terpecah menjadi beberapa bagian.

Misalnya, Penurunan harga ini:

## Redis Caching
We use Redis for L1 cache with 5min TTL.
The connection pool is configured with max 100 connections.
## Database
PostgreSQL 16 is the primary database.

Menjadi dua potongan:

• Potongan 1: ## Redis Caching\nWe use Redis for L1 cache...

• Potongan 2: Potongan 2: ## Database\nPostgreSQL 16 is the primary database.

Deduplikasi menggunakan hash SHA-256 untuk setiap potongan untuk menghindari penyematan teks yang sama dua kali. Jika beberapa file menyebutkan "PostgreSQL 16," API penyematan dipanggil sekali, bukan sekali per file. Untuk ~500KB teks, ini menghemat sekitar $0,15/bulan. Dalam skala besar, penghematan ini bisa mencapai ratusan dolar.

Desain ID Chunk mengkodekan semua yang diperlukan untuk mengetahui apakah sebuah chunk sudah basi. Formatnya adalah hash(source_path:start_line:end_line:content_hash:model_version). Bidang model_version adalah bagian yang penting: ketika sebuah model penyematan ditingkatkan dari text-embedding-3-small ke text-embedding-3-large, penyematan yang lama menjadi tidak valid. Karena versi model dimasukkan ke dalam ID, sistem secara otomatis mengidentifikasi potongan mana yang perlu disematkan ulang. Tidak diperlukan pembersihan manual.

3. Pencarian: Pencarian Vektor Hibrida + BM25 untuk Akurasi Maksimum

Pencarian menggunakan pendekatan pencarian hibrida: pencarian vektor berbobot 70% dan pencarian kata kunci BM25 berbobot 30%. Hal ini menyeimbangkan dua kebutuhan berbeda yang sering muncul dalam praktiknya.

• Pencarian vektor menangani pencocokan semantik. Kueri untuk "Redis cache config" mengembalikan potongan yang berisi "Redis L1 cache dengan TTL 5 menit" meskipun kata-katanya berbeda. Ini berguna ketika pengembang mengingat konsepnya tetapi tidak mengingat frasa yang tepat.

• BM25 menangani pencocokan yang tepat. Kueri untuk "PostgreSQL 16" tidak mengembalikan hasil tentang "PostgreSQL 15." Hal ini penting untuk kode kesalahan, nama fungsi, dan perilaku spesifik versi, di mana close tidak cukup baik.

Pembagian default 70/30 bekerja dengan baik untuk sebagian besar kasus penggunaan. Untuk alur kerja yang sangat condong ke arah pencocokan yang sama persis, menaikkan bobot BM25 menjadi 50% adalah perubahan konfigurasi satu baris.

Hasil dikembalikan sebagai potongan top-K (default 3), masing-masing dipotong menjadi 200 karakter. Ketika konten lengkap diperlukan, memsearch expand <chunk_hash> akan memuatnya. Pengungkapan progresif ini membuat penggunaan jendela konteks LLM tetap ramping tanpa mengorbankan akses ke detail.

4. Ringkas: Meringkas Memori Historis untuk Menjaga Konteks Tetap Bersih

Memori yang menumpuk pada akhirnya menjadi masalah. Entri lama memenuhi jendela konteks, meningkatkan biaya token, dan menambahkan noise yang menurunkan kualitas jawaban. Compact mengatasi hal ini dengan memanggil LLM untuk meringkas memori historis ke dalam bentuk yang ringkas, kemudian menghapus atau mengarsipkan yang asli. Ini dapat dipicu secara manual atau dijadwalkan untuk berjalan pada interval yang teratur.

Cara memulai dengan memsearch

Memsearch menyediakan API Python dan CLI, sehingga Anda bisa menggunakannya di dalam kerangka kerja agen atau sebagai alat debugging mandiri. Penyiapannya minimal, dan sistem ini dirancang agar lingkungan pengembangan lokal dan penerapan produksi Anda terlihat hampir sama.

Memsearch mendukung tiga backend yang kompatibel dengan Milvus, semuanya diekspos melalui API yang sama:

• Milvus Lite (default): File .db lokal, tanpa konfigurasi, cocok untuk penggunaan individu.

• Milvus Standalone / Cluster: Di-host sendiri, mendukung beberapa agen berbagi data, cocok untuk lingkungan tim.

• Zilliz Cloud: Dikelola sepenuhnya, dengan penskalaan otomatis, pencadangan, ketersediaan tinggi, dan isolasi. Ideal untuk beban kerja produksi.

Beralih dari pengembangan lokal ke produksi biasanya merupakan perubahan konfigurasi satu baris. Kode Anda tetap sama.

Instal

pip install memsearch

memsearch juga mendukung beberapa penyedia penyematan, termasuk OpenAI, Google, Voyage, Ollama, dan model lokal. Ini memastikan arsitektur memori Anda tetap portabel dan vendor-agnostik.

Opsi 1: API Python (terintegrasi ke dalam kerangka kerja agen Anda)

Berikut ini adalah contoh minimal dari perulangan agen lengkap menggunakan memsearch. Anda dapat menyalin/menempel dan memodifikasi sesuai kebutuhan:

from openai import OpenAI
from memsearch import MemSearch
llm = OpenAI()
ms = MemSearch(paths=[“./memory/”])
async def agent_chat(user_input: str) -> str:
# 1. Recall — search relevant memories
memories = await ms.search(user_input, top_k=3)
context = “\n”.join(f"- {m[‘content’][:200]}" for m in memories)
<span class="hljs-comment"># 2. Think — call LLM</span>
resp = llm.chat.completions.create(
    model=<span class="hljs-string">&quot;gpt-4o-mini&quot;</span>,
    messages=[
        {<span class="hljs-string">&quot;role&quot;</span>: <span class="hljs-string">&quot;system&quot;</span>, <span class="hljs-string">&quot;content&quot;</span>: <span class="hljs-string">f&quot;Memories:\n<span class="hljs-subst">{context}</span>&quot;</span>},
        {<span class="hljs-string">&quot;role&quot;</span>: <span class="hljs-string">&quot;user&quot;</span>, <span class="hljs-string">&quot;content&quot;</span>: user_input},
    ],
)

<span class="hljs-comment"># 3. Remember — write to markdown, update index</span>
save_memory(<span class="hljs-string">f&quot;## <span class="hljs-subst">{user_input}</span>\n<span class="hljs-subst">{resp.choices[<span class="hljs-number">0</span>].message.content}</span>&quot;</span>)
<span class="hljs-keyword">await</span> ms.index()
<span class="hljs-keyword">return</span> resp.choices[<span class="hljs-number">0</span>].message.content

Ini menunjukkan perulangan inti:

• Ingat: memsearch melakukan pengambilan vektor hibrida + BM25

• Pikirkan: LLM Anda memproses input pengguna + memori yang diambil

• Ingat: agen menulis memori baru ke Markdown, dan memsearch memperbarui indeksnya

Pola ini cocok secara alami ke dalam sistem agen apa pun - LangChain, AutoGPT, router semantik, LangGraph, atau loop agen khusus. Ini adalah kerangka kerja yang bersifat agnostik secara desain.

Opsi 2: CLI (operasi cepat, bagus untuk debugging)

CLI sangat ideal untuk alur kerja mandiri, pemeriksaan cepat, atau memeriksa memori selama pengembangan:

memsearch index ./docs/              # Index files
memsearch search "Redis caching"     # Search
memsearch watch ./docs/              # Watch for file changes
memsearch compact                    # Compact old memory

CLI mencerminkan kemampuan API Python tetapi bekerja tanpa menulis kode apa pun-bagus untuk debugging, inspeksi, migrasi, atau memvalidasi struktur folder memori Anda.

Bagaimana memsearch Dibandingkan dengan Solusi Memori Lainnya

Pertanyaan paling umum yang ditanyakan oleh para pengembang adalah mengapa mereka menggunakan memsearch ketika sudah ada opsi yang sudah ada. Jawaban singkatnya: memsearch menukar fitur-fitur canggih seperti grafik pengetahuan temporal dengan transparansi, portabilitas, dan kesederhanaan. Untuk sebagian besar kasus penggunaan memori agen, itu adalah pertukaran yang tepat.

Solusi	Kekuatan	Keterbatasan	Paling cocok untuk
memsearch	Memori plaintext transparan, penulisan bersama manusia-AI, gesekan migrasi nol, debugging yang mudah, Git-native	Tidak ada grafik temporal bawaan atau struktur memori multi-agen yang kompleks	Tim yang menghargai kontrol, kesederhanaan, dan portabilitas dalam memori jangka panjang
Mem0	Dikelola sepenuhnya, tidak ada infrastruktur yang harus dijalankan atau dipelihara	Buram-tidak dapat memeriksa atau mengedit memori secara manual; penyematan adalah satu-satunya representasi	Tim yang menginginkan layanan terkelola lepas tangan dan tidak masalah dengan visibilitas yang lebih rendah
Zep	Rangkaian fitur yang kaya: memori temporal, pemodelan multi-persona, grafik pengetahuan yang kompleks	Arsitektur yang berat; lebih banyak bagian yang bergerak; lebih sulit untuk dipelajari dan dioperasikan	Agen yang benar-benar membutuhkan struktur memori tingkat lanjut atau penalaran yang sadar waktu
LangMem / Letta	Integrasi yang dalam dan mulus di dalam ekosistem mereka sendiri	Kerangka kerja terkunci; sulit untuk di-porting ke tumpukan agen lain	Tim yang sudah berkomitmen pada kerangka kerja spesifik tersebut

Coba memsearch dan beri tahu kami umpan balik Anda

Memsearch sepenuhnya bersifat open source di bawah lisensi MIT, dan repositori siap untuk percobaan produksi hari ini.

• Repositori: github.com/zilliztech/memsearch

• Dokumen: zilliztech.github.io/memsearch

Jika Anda sedang membangun sebuah agen yang perlu mengingat berbagai hal di seluruh sesi dan menginginkan kontrol penuh atas apa yang diingatnya, memsearch patut dicoba. Pustaka ini dipasang dengan satu pip install, bekerja dengan kerangka kerja agen apa pun, dan menyimpan semuanya sebagai Markdown yang dapat Anda baca, edit, dan versi dengan Git.

Kami secara aktif mengembangkan memsearch dan sangat mengharapkan masukan dari komunitas.

• Buka masalah jika ada sesuatu yang rusak.

• Kirimkan PR jika Anda ingin memperluas perpustakaan.

• Bintangi repo jika filosofi Markdown-sebagai-sumber-kebenaran sesuai dengan Anda.

Sistem memori OpenClaw tidak lagi terkunci di dalam OpenClaw. Sekarang, siapa pun dapat menggunakannya.

Teruslah membaca

• Apa itu OpenClaw? Panduan Lengkap untuk Agen AI Sumber Terbuka

• Tutorial OpenClaw: Menghubungkan ke Slack untuk Asisten AI Lokal

• Membuat Agen AI Bergaya Clawdbot dengan LangGraph & Milvus

• Agen RAG vs Agen yang Sudah Berjalan Lama: Apakah RAG Sudah Usang?

• Membuat Keterampilan Antropik Khusus untuk Milvus untuk Memutar RAG dengan Cepat