Cara Kerja Memori Agen AI (dan Cara Mengujinya via API)

TL;DR

Agen AI gagal bukan karena kurang cerdas tetapi karena mereka lupa. Memahami empat jenis memori agen, cara penyimpanannya, dan bagaimana pengaruhnya terhadap perilaku API memungkinkan Anda membangun agen yang lebih andal dan mendeteksi bug sebelum masuk produksi.

Pendahuluan

Inilah rahasia kotor di balik sebagian besar kegagalan agen AI: modelnya baik-baik saja. Lapisan memorinya rusak.

Agen yang tidak dapat mengingat apa yang terjadi tiga giliran lalu, yang kehilangan konteks pengguna antar sesi, atau yang saling bertentangan di tengah tugas tidak sedang berhalusinasi karena kualitas model. Agen tersebut gagal karena arsitektur memori tidak dirancang dengan cermat atau tidak diuji sama sekali.

Hippo, sebuah sistem memori agen sumber terbuka yang baru-baru ini menjadi tren, mengambil pendekatan yang terinspirasi dari biologi: sistem ini memodelkan memori jangka pendek, jangka panjang, dan episodik secara terpisah, sama seperti cara kerja memori manusia. Proyek tersebut menyoroti kesenjangan nyata: sebagian besar pengembang membangun memori agen sebagai bagian terakhir dan baru menyadari bahwa itu rusak di produksi.

Apa itu memori agen AI?

Memori agen adalah mekanisme apa pun yang memungkinkan sistem AI mengakses atau menyimpan informasi di luar input saat ini. Tanpa itu, setiap panggilan API bersifat stateless: model menerima prompt, mengembalikan respons, dan tidak mengingat apa pun.

Empat jenis memori yang berbeda melayani tujuan yang berbeda.

Empat jenis memori agen

Memori kerja

Memori kerja adalah konteks aktif agen: semua yang ada dalam prompt saat ini. Untuk sebagian besar agen berbasis LLM, ini adalah jendela konteks. GPT-4o memiliki jendela konteks 128K token. Claude 3.5 Sonnet mendukung 200K. Gemini 1.5 Pro mendukung 1M.

Memori kerja cepat dan tepat tetapi mahal (Anda membayar per token) dan terbatas. Setelah mencapai batas, konteks terlama akan dihapus secara diam-diam. Ini adalah sumber paling umum dari bug agen dalam tugas yang berjalan lama.

Memori episodik

Memori episodik menyimpan apa yang terjadi: log interaksi, keputusan, dan pengamatan masa lalu. Anggap saja sebagai buku harian agen.

Dalam praktiknya, ini biasanya adalah database vektor (Chroma, Pinecone, Qdrant) atau log peristiwa terstruktur. Agen mengambil episode masa lalu yang relevan melalui pencarian semantik sebelum menghasilkan respons. Pendekatan Hippo menyimpan urutan interaksi dengan stempel waktu dan bobot peluruhan, sehingga interaksi terbaru mendapatkan prioritas pengambilan yang lebih tinggi.

Memori semantik

Memori semantik menyimpan apa yang diketahui agen: fakta, pengetahuan domain, preferensi pengguna, dan pengetahuan dunia yang stabil. Tidak seperti memori episodik, ia tidak berurutan waktu.

Ini dapat dimuat sebelumnya (prompt sistem dengan data profil pengguna), dibangun secara dinamis (fakta yang diekstrak dari percakapan masa lalu dan disimpan dalam grafik pengetahuan), atau bersumber secara eksternal (RAG terhadap penyimpanan dokumen).

Memori prosedural

Memori prosedural menyimpan cara melakukan sesuatu: urutan tindakan, pola penggunaan alat, dan keterampilan yang telah dipelajari agen. Ini adalah yang paling sulit dibangun dan sering dilewati dalam sistem produksi.

Dalam praktiknya, ini muncul sebagai contoh few-shot yang tertanam dalam prompt sistem, atau sebagai pustaka rencana tindakan yang disimpan yang dapat diambil dan diadaptasi oleh agen.

Bagaimana memori disimpan dalam sistem nyata

Keempat jenis jarang dipetakan secara bersih ke empat penyimpanan terpisah. Pengaturan nyata terlihat lebih seperti ini:

Jendela konteks (kerja): semua yang ada dalam prompt aktif. Dikelola oleh kerangka kerja agen. Berakhir saat percakapan selesai.

Penyimpanan vektor eksternal (episodik + semantik): Chroma, Pinecone, atau Qdrant menyimpan embedding interaksi masa lalu dan potongan pengetahuan. Agen mengkueri ini pada setiap giliran dan menyuntikkan potongan yang relevan ke dalam prompt.

DB terstruktur (semantik + prosedural): PostgreSQL atau SQLite untuk preferensi pengguna, status akun, atau template tindakan yang dipelajari. Dikuery melalui panggilan alat.

Cache dalam memori (overflow kerja): Redis atau kamus sederhana untuk akses cepat ke konteks terbaru yang tidak memerlukan pencarian embedding.

Hippo secara khusus memodelkan sistem memorinya tiga tingkat dengan logika serah terima eksplisit: entri memori kerja yang belum diakses baru-baru ini dikonsolidasikan ke dalam memori episodik, yang pada akhirnya diringkas menjadi memori semantik. Ini mencerminkan bagaimana konsolidasi memori manusia bekerja selama tidur (proyek ini bahkan memiliki perintah "tidur" untuk memicu konsolidasi).

Bagaimana memori agen memengaruhi perilaku API

Di sinilah hal-hal menjadi sangat penting. Jika Anda membangun atau mengonsumsi API agen, memori secara langsung membentuk seperti apa panggilan API Anda dan apa yang bisa salah.

ID Sesi: sebagian besar API agen menggunakan ID sesi atau thread untuk mengkorelasikan memori antar panggilan. OpenAI Assistants API menggunakan thread_id. ID thread yang hilang atau digunakan kembali menyebabkan agen kehilangan konteks atau mencampur sesi dua pengguna.

Ukuran konteks dalam payload permintaan: agen yang menyuntikkan memori ke dalam prompt menghasilkan badan permintaan yang lebih besar seiring waktu. Percakapan agen yang dimulai dengan 2KB dapat bertambah menjadi 40KB setelah 20 giliran. Jika klien HTTP Anda memiliki batas ukuran payload, permintaan akan gagal secara diam-diam.

Latensi pengambilan: pencarian penyimpanan vektor menambahkan 50-200ms per giliran. Jika Anda menegaskan waktu respons API, pengambilan memori adalah kontributor nyata.

Status tidak konsisten setelah kegagalan: jika panggilan alat agen gagal di tengah tugas, log episodik dapat merekam tindakan parsial. Giliran berikutnya dimulai dari status yang rusak. Agen yang baik melakukan checkpoint status sebelum dan sesudah penggunaan alat.

Cara menguji memori agen melalui API dengan Apidog

Menguji API agen yang stateful membutuhkan lebih dari sekadar penegasan permintaan tunggal. Anda perlu memverifikasi bahwa konteks terbawa di beberapa panggilan, bahwa respons yang didukung memori berubah seperti yang diharapkan, dan bahwa sistem menurun secara anggun ketika memori tidak tersedia.

Skenario Uji Apidog menangani hal ini dengan tepat. Berikut cara mengaturnya untuk API agen.

Uji 1: penerusan konteks

Buat skenario dengan tiga langkah berurutan:

1. POST /agent/chat dengan pesan yang memperkenalkan fakta ("Proyek saya menggunakan PostgreSQL 16")
2. POST /agent/chat dengan tindak lanjut yang memerlukan mengingat fakta tersebut ("Database apa yang harus saya optimalkan?")
3. Tegaskan pada respons langkah 2: response.message.content harus berisi "PostgreSQL"

Jika lapisan memori agen berfungsi, langkah 2 mengambil fakta dari memori episodik atau semantik dan menggunakannya dalam respons. Jika tidak, Anda mendapatkan jawaban umum.

Uji 2: isolasi sesi

Jalankan urutan dua langkah yang sama dua kali dengan nilai session_id yang berbeda. Tegaskan bahwa respons sesi kedua tidak berisi konteks apa pun dari sesi pertama. Ini menangkap bug memori bersama: salah satu masalah paling umum dan paling sulit di-debug dalam penerapan agen multi-penyewa.

Uji 3: penurunan kegagalan memori

Gunakan Smart Mock Apidog untuk mensimulasikan kegagalan backend memori. Konfigurasikan mock untuk mengembalikan 503 pada endpoint pencarian penyimpanan vektor. Kemudian jalankan percakapan agen Anda dan tegaskan bahwa: - Agen merespons tanpa crash - Respons mencakup fallback yang anggun ("Saya tidak memiliki cukup konteks untuk menjawab itu") - Sesi dapat dilanjutkan setelah mock dihapus

Uji 4: luapan jendela konteks

Kirim 30+ pesan cepat secara berurutan untuk mendorong memori kerja melewati batas konteks. Tegaskan bahwa: - Agen tidak memunculkan kesalahan context_length_exceeded (ia harus memotong dengan anggun) - Respons pada giliran 30 masih menjawab dengan benar menggunakan pengambilan episodik - Jumlah token dalam response.usage tetap dalam rentang yang diharapkan

Anda dapat menjalankan keempatnya sebagai satu Skenario Uji di Apidog, merantainya secara berurutan dengan variabel bersama untuk ID sesi dan data respons. Lihat [internal: how-to-build-tiny-llm-from-scratch] untuk latar belakang mengapa jendela konteks bekerja seperti itu pada tingkat model.

Mode kegagalan memori umum

Pemotongan konteks diam: jendela konteks terisi dan pesan lama menghilang tanpa peringatan. Agen menjawab berdasarkan riwayat yang tidak lengkap. Tangkap ini dengan menegaskan response.usage.prompt_tokens dan memverifikasi bahwa itu tetap di bawah batas konteks model Anda.

Pencampuran sesi: sesi dua pengguna berbagi namespace memori. Tangkap ini dengan tes isolasi sesi.

Memori semantik usang: pengetahuan yang disimpan berminggu-minggu yang lalu bertentangan dengan fakta saat ini. Agen dengan percaya diri memberikan informasi yang salah. Tangkap ini dengan menyertakan penegasan "tanggal saat ini" dalam tes Anda: jika agen mengutip harga atau nomor versi, tegaskan bahwa itu cocok dengan nilai yang Anda muat dalam konteks tes.

Pergeseran embedding: penyimpanan vektor yang dibangun dengan satu model embedding rusak saat Anda beralih ke model yang berbeda. Semua dokumen yang diambil menjadi secara semantik salah. Tidak dapat diuji secara langsung melalui API, tetapi Anda dapat menambahkan penegasan yang memeriksa apakah konteks yang diambil secara semantik terkait dengan kueri.

Injeksi prompt injeksi memori: input pengguna berbahaya yang memanipulasi apa yang disimpan dan diambil. Sertakan input adversarial dalam suite tes Anda: simpan "preferensi pengguna" yang berisi penimpaan prompt sistem dan verifikasi agen mengabaikannya. Lihat [internal: rest-api-best-practices] untuk panduan pengujian keamanan API yang lebih luas.

Kesimpulan

Memori agen adalah perbedaan antara asisten yang terasa cerdas dan yang terasa amnesia. Keempat jenis, kerja, episodik, semantik, dan prosedural, masing-masing memiliki peran yang berbeda. Memahami cara penyimpanannya dan pengambilannya dalam sistem nyata memberi tahu Anda persis di mana bug dapat bersembunyi dan apa yang harus ditegaskan dalam tes API Anda.

Alat seperti Hippo menunjukkan bidang yang bergerak menuju arsitektur memori yang berprinsip. Sistem memori apa pun yang Anda bangun, Skenario Uji Apidog memberi Anda lapisan pengujian untuk memverifikasi bahwa itu berperilaku seperti yang Anda harapkan, terutama kasus kegagalan yang hanya muncul pada skala besar.

FAQ

Apa cara termudah untuk menambahkan memori ke agen?Pendekatan termudah adalah jendela geser di atas riwayat percakapan: simpan N giliran terakhir dalam prompt. Itu bukan memori episodik, tetapi berfungsi untuk tugas-tugas pendek. Untuk agen yang berjalan lebih lama, tambahkan penyimpanan vektor dan pengambilan semantik.

Bagaimana OpenAI Assistants API menangani memori?Assistants API mengelola objek thread yang menyimpan riwayat percakapan di sisi server. Anda juga dapat melampirkan pencarian file dan alat interpreter kode yang memberi agen akses ke pengetahuan eksternal. Manajemen memori diabstraksikan, yang nyaman tetapi membuat debugging lebih sulit.

Apa database vektor terbaik untuk memori agen?Untuk pengembangan lokal: Chroma (tidak perlu infrastruktur). Untuk produksi: Qdrant atau Pinecone tergantung apakah Anda membutuhkan self-hosted atau managed. Pustaka Hippo mendukung backend penyimpanan yang dapat dicolokkan. Lihat [internal: claude-code] untuk bagaimana Claude Code menggunakan lapisan memorinya sendiri.

Bagaimana cara mencegah agen berhalusinasi interaksi masa lalu?Simpan log interaksi dalam format terstruktur dengan metadata (timestamp, kepercayaan diri, sumber). Saat mengambil konteks masa lalu, sertakan metadata dalam prompt: "Menurut percakapan kita pada [tanggal], Anda menyebutkan X." Kutipan eksplisit mengurangi halusinasi yang percaya diri.

Bisakah saya menguji memori agen tanpa agen yang berjalan?Ya. Gunakan Smart Mock Apidog untuk mensimulasikan respons API agen, termasuk yang didukung memori. Definisikan respons mock yang berubah berdasarkan ID sesi atau konten badan permintaan. Ini memungkinkan Anda menguji penanganan memori oleh frontend atau lapisan integrasi Anda tanpa agen yang aktif.

Berapa biaya penyimpanan vektor dalam produksi?Tingkat gratis Pinecone mendukung 1 indeks dengan 100K vektor. Pada skala besar, Pinecone mengenakan biaya sekitar $0,096/jam untuk pod p1.x1 (1M vektor dimensi 768). Qdrant self-hosted gratis. Untuk sebagian besar agen, biaya yang lebih besar adalah generasi embedding, bukan penyimpanan. Lihat [internal: what-is-mcp-server] untuk bagaimana integrasi server MCP berinteraksi dengan sistem memori agen.

Apa perbedaan antara RAG dan memori agen?RAG (retrieval-augmented generation) mengambil dokumen yang relevan pada waktu kueri dari basis pengetahuan tetap. Memori agen bersifat dinamis: ia tumbuh dan berubah saat agen berinteraksi. Sistem RAG menjawab "apa yang dikatakan dokumen tentang X?" Sistem memori agen menjawab "apa yang saya ketahui tentang pengguna ini dan apa yang telah saya lakukan dengan mereka?"