Cara Mengatasi Kehilangan Memori Agent LangChain dalam Percakapan Panjang

Jika agent LangChain melupakan detail selama percakapan panjang, perbaiki arsitekturnya sebelum memperbesar jendela konteks model. Pada agent gaya LangChain v1 saat ini, kontinuitas percakapan dibangun dari dua lapisan terpisah: checkpointer untuk status jangka pendek berbasis thread dan store untuk informasi jangka panjang yang harus bertahan lintas thread. Percakapan panjang kemudian memerlukan perhatian ketiga: manajemen konteks, biasanya memangkas atau merangkum pesan lama sebelum membebani model.

Panduan ini mengikuti dokumentasi resmi LangChain yang diperiksa pada 11 September 2026. Dokumentasi saat ini merekomendasikan langchain.agents.create_agent untuk agent baru dan mendeskripsikan persistensi LangGraph sebagai sistem memori yang mendasarinya. Contoh lama yang berbasis ConversationChain, ConversationBufferMemory, atau initialize_agent mungkin masih muncul dalam materi legacy, tetapi panduan migrasi LangChain v1 telah memindahkan rantai legacy dan fungsionalitas yang tidak digunakan lagi ke langchain-classic. Lihat panduan migrasi resmi LangChain v1.

Apa Arti Sebenarnya dari “Kehilangan Memori” di LangChain

Sebelum mengubah kode, pisahkan tiga masalah yang sering terlihat identik dari sudut pandang pengguna.

Dokumentasi memori jangka pendek LangChain mendefinisikan memori jangka pendek sebagai status dalam satu thread. Dokumentasi memori jangka panjangnya mendefinisikan memori jangka panjang sebagai informasi yang bertahan di berbagai percakapan dan sesi yang berbeda.

Yang Anda Butuhkan Sebelum Memulai

Anda memerlukan aplikasi LangChain/LangGraph terkini, integrasi model, dan tempat untuk menyimpan status secara persisten. Untuk eksperimen lokal, InMemorySaver sudah cukup. Untuk produksi, gunakan checkpointer yang didukung database. Dokumentasi resmi LangChain menunjukkan PostgreSQL melalui paket terpisah langgraph-checkpoint-postgres.

Jaga kejelasan empat pengidentifikasi:

• ID Percakapan atau Chat: pengidentifikasi yang diekspos aplikasi Anda kepada pengguna.
• thread_id: kunci persistensi LangGraph yang digunakan untuk melanjutkan status satu thread.
• ID Pengguna: identitas tahan lama yang digunakan untuk memberi namespace pada memori jangka panjang.
• Kunci Memori: kunci untuk satu item tahan lama di dalam namespace store.

Mereka tidak boleh secara otomatis memiliki nilai yang sama. Satu pengguna dapat memiliki banyak thread, dan satu thread dapat berisi banyak fakta.

Langkah 1: Reproduksi Kegagalan dengan Tes Dua Permintaan

Mulai dengan tes sekecil mungkin. Minta agent untuk mengingat detail unik, lalu panggil lagi dan minta detail tersebut. Jangan menguji memori dengan satu panggilan invoke() karena model dapat melihat semuanya dalam satu permintaan tersebut bahkan ketika persistensi rusak.

config = {"configurable": {"thread_id": "debug-thread-001"}}

agent.invoke(
    {"messages": [{"role": "user", "content": "Ingat bahwa nama sandi proyek saya adalah Juniper."}]},
    config,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "Apa nama sandi proyek saya?"}]},
    config,
)

Jika permintaan kedua melupakan “Juniper,” periksa konfigurasi checkpointer dan thread_id yang sebenarnya sebelum mengubah prompt.

Langkah 2: Tambahkan Checkpointer untuk Memori Thread yang Sama

Sebuah checkpointer menyimpan snapshot status graf agent. LangGraph menggunakannya untuk memori jangka pendek, pemulihan interupsi, alur human-in-the-loop, dan toleransi kesalahan. Panduan persistensi saat ini mendeskripsikan checkpointer sebagai berbasis thread dan menyatakan bahwa aplikasi mengakses status dengan meneruskan thread_id. Lihat panduan persistensi resmi LangGraph.

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
)

config = {"configurable": {"thread_id": "customer-42:case-7"}}

InMemorySaver sangat baik untuk memastikan bahwa pengkabelan thread Anda berfungsi, tetapi menyimpan checkpoint di RAM. LangGraph secara eksplisit memperingatkan bahwa MemorySaver/InMemorySaver tidak bertahan di antara restart proses.

Langkah 3: Pertahankan thread_id yang Sama untuk Percakapan yang Sama

Bug tingkat aplikasi yang paling umum adalah membuat thread_id baru pada setiap permintaan HTTP. Database mungkin bekerja dengan sempurna sementara setiap permintaan memulai thread LangGraph yang berbeda.

Misalnya, anggap front end Anda memiliki ID chat chat_8bf4. Petakan nilai tersebut secara deterministik ke thread LangGraph dan gunakan kembali untuk setiap giliran dalam chat tersebut. Chat baru harus menerima ID thread baru.

Jangan gunakan satu thread_id permanen untuk semua chat yang milik pengguna yang sama. Itu menggabungkan percakapan yang tidak terkait menjadi satu aliran status. Jika Anda menggunakan PostgreSQL, panduan pemecahan masalah LangGraph saat ini juga menyatakan bahwa thread_id harus tetap di bawah 255 karakter; UUID atau hash deterministik lebih aman daripada objek terserialisasi yang sangat besar.

Langkah 4: Ganti Persistensi In-Memory Sebelum Produksi

Setelah tes dua permintaan berhasil, uji restart proses. Simpan sebuah fakta, hentikan aplikasi, mulai lagi, lalu minta fakta tersebut dengan ID thread yang sama. Jika Anda masih menggunakan InMemorySaver, lupa adalah perilaku yang diharapkan.

Dokumentasi memori jangka pendek resmi menunjukkan pengaturan produksi berbasis PostgreSQL menggunakan PostgresSaver:

from langchain.agents import create_agent
from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:password@db-host/app"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    agent = create_agent(
        model="your-provider:your-model",
        tools=[],
        checkpointer=checkpointer,
    )

Untuk pengaturan paket yang saat ini didokumentasikan oleh LangChain, lihat Memori Jangka Pendek. Jangan menempatkan kredensial database asli langsung dalam kode sumber; gunakan sistem manajemen rahasia normal Anda.

Langkah 5: Kelola Riwayat Panjang daripada Mengirim Semuanya Selamanya

Jendela konteks adalah jumlah konteks input dan output yang dapat ditangani model dalam satu panggilan model. Checkpointing dapat mempertahankan percakapan yang sangat panjang dalam penyimpanan, tetapi itu tidak berarti setiap pesan historis harus dikirim kembali ke model selamanya.

Panduan memori jangka pendek LangChain menyatakan bahwa riwayat panjang dapat melebihi jendela konteks model dan bahwa bahkan model yang mampu menerima riwayat penuh dapat terganggu oleh konten yang basi atau tidak relevan, dengan latensi dan biaya yang lebih tinggi. Strategi yang didokumentasikan adalah memangkas, menghapus, merangkum, atau menerapkan kebijakan kustom.

Gunakan ringkasan ketika detail lama masih penting

SummarizationMiddleware adalah opsi bawaan saat ini untuk mengganti riwayat lama dengan ringkasan kompak sambil mempertahankan pesan terbaru. Pemicunya dapat didasarkan pada jumlah token, jumlah pesan, atau fraksi dari konteks model.

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
    middleware=[
        SummarizationMiddleware(
            model="your-provider:summary-model",
            trigger=("fraction", 0.8),
            keep=("fraction", 0.3),
        )
    ],
)

Angka-angka di atas adalah contoh kebijakan, bukan pengaturan universal. Pilih ambang batas setelah mengukur prompt Anda sendiri, output alat, batas konteks model, latensi, dan kualitas ringkasan. Lihat dokumentasi middleware bawaan LangChain untuk opsi pemicu dan penyimpanan yang saat ini didukung.

Jangan memangkas pesan alat secara buta

Jika Anda menerapkan penghapusan atau pemangkasan kustom, pertahankan urutan pesan yang valid. LangChain memperingatkan bahwa banyak penyedia memerlukan pesan asisten yang berisi panggilan alat untuk diikuti oleh pesan hasil alat yang sesuai. Menghapus salah satu bagian dari pasangan tersebut dapat membuat kesalahan penyedia atau perilaku model yang membingungkan.

Langkah 6: Pindahkan Fakta Tahan Lama ke Store Jangka Panjang

Sebuah store adalah lapisan persistensi LangGraph untuk data yang didefinisikan aplikasi di luar status graf satu thread. Dokumentasi LangChain saat ini menggunakan store untuk informasi yang harus tersedia di berbagai percakapan, seperti preferensi pengguna, fakta, atau pengetahuan aplikasi bersama.

Item store jangka panjang adalah dokumen JSON yang diorganisir oleh namespace dan key. Namespace praktis sering kali berisi pengidentifikasi pengguna atau organisasi:

namespace = ("users", user_id, "preferences")
store.put(
    namespace,
    "response_style",
    {"value": "concise", "source": "explicit_user_request"},
)

Ini berbeda dari menyimpan seluruh transkrip. Simpan informasi yang secara sengaja diperlakukan sebagai tahan lama oleh produk Anda. Jika sebuah fakta bersifat privat atau diatur, terapkan kebijakan retensi, otorisasi, enkripsi, dan penghapusan normal Anda daripada berasumsi bahwa “memori agent” dibebaskan dari kebijakan tersebut.

Gunakan store yang didukung database dalam produksi

Panduan memori jangka panjang resmi menunjukkan baik InMemoryStore maupun PostgresStore, dan secara eksplisit mencatat bahwa implementasi in-memory harus diganti dengan store yang didukung database untuk produksi. Panduan tersebut juga mencantumkan integrasi store di luar PostgreSQL. Gunakan backend yang sesuai dengan persyaratan penerapan dan operasional Anda daripada memilih database vektor hanya karena kata “memori” terlibat.

Tambahkan pencarian semantik hanya ketika Anda membutuhkan daya ingat samar

Store LangGraph dapat dikonfigurasi dengan indeks sehingga store.search() dapat mengambil item berdasarkan kesamaan semantik. Itu berguna ketika Anda memiliki banyak memori dan tidak mengetahui kunci yang tepat. Untuk sejumlah kecil preferensi terstruktur, pencarian namespace/kunci langsung sering kali lebih sederhana dan lebih deterministik.

Langkah 7: Buat Jalur Baca dan Tulis Memori Eksplisit

Menyimpan item jangka panjang tidak menjamin bahwa agent akan menggunakannya. Aplikasi masih memerlukan jalur pengambilan. Agent LangChain saat ini memungkinkan alat untuk mengakses store yang disediakan melalui ToolRuntime.

from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

@dataclass
class Context:
    user_id: str

@tool
def get_response_style(runtime: ToolRuntime[Context]) -> str:
    store = runtime.store
    if store is None:
        return "No memory store configured"

    namespace = ("users", runtime.context.user_id, "preferences")
    item = store.get(namespace, "response_style")
    return item.value["value"] if item else "default"

Anda juga dapat membangun prompt dinamis atau middleware yang membaca status dan memori tahan lama sebelum panggilan model. Aturan desain yang penting adalah bahwa jalur pengambilan harus dapat diamati dan diuji. “Informasi ada di suatu tempat di database” tidak cukup.

Langkah 8: Uji Empat Batas Memori Secara Terpisah

Rangkaian tes memori yang andal harus mencakup lebih dari “model mengingat nama saya sekali.” Gunakan setidaknya empat kasus berikut:

Kemudian tambahkan tes percakapan panjang yang melebihi ambang ringkasan Anda. Tegaskan bahwa fakta tahan lama yang penting bertahan, urutan panggilan alat terbaru tetap valid, dan ukuran prompt tetap dalam anggaran target Anda.

Arsitektur Produksi Minimal

Untuk banyak aplikasi agent, desain yang kuat terlihat seperti ini:

1. API menerima user_id, conversation_id, dan pesan pengguna baru.
2. Aplikasi memetakan conversation_id ke thread_id LangGraph yang stabil.
3. Checkpointer persisten memulihkan status thread.
4. Store jangka panjang mengambil hanya fakta pengguna atau aplikasi tahan lama yang diperlukan untuk permintaan.
5. Ringkasan atau pemangkasan menjaga riwayat yang menghadap model dalam anggaran konteks yang terukur.
6. Agent menjalankan alat dan model.
7. Checkpointer melakukan commit status thread yang diperbarui.
8. Hanya fakta yang disetujui yang ditulis ke store jangka panjang.

Jika Anda menerapkan melalui LangGraph Agent Server, panduan persistensi saat ini menyatakan bahwa server menangani infrastruktur persistensi secara otomatis, jadi jangan menduplikasi lapisan tersebut tanpa memeriksa model penerapan.

Kesalahan Umum yang Membuat Memori Terlihat Rusak

Menghasilkan thread_id baru untuk setiap permintaan

Ini membuat status percakapan baru setiap giliran. Catat ID thread di samping ID chat aplikasi Anda dan verifikasi penggunaan kembali.

Menggunakan InMemorySaver dalam layanan multi-worker atau yang dapat di-restart

Status lokal RAM hilang bersama proses dan mungkin tidak dibagikan di antara worker. Gunakan backend persisten untuk kontinuitas produksi.

Berasumsi checkpointer menyelesaikan masalah jendela konteks

Checkpointer mempertahankan status; itu tidak menjamin bahwa transkrip yang terus tumbuh berguna bagi model. Tambahkan kebijakan manajemen konteks yang eksplisit.

Memasukkan setiap fakta historis ke dalam prompt

Lebih banyak konteks tidak secara otomatis berarti konteks yang lebih baik. Ambil informasi yang relevan dengan giliran saat ini dan pertahankan kontinuitas percakapan terbaru secara terpisah.

Memperlakukan ringkasan sebagai database sempurna

Ringkasan adalah representasi terkompresi yang dihasilkan model. Jika sebuah fakta harus tepat—pengidentifikasi akun, batasan kontraktual, preferensi yang disetujui pengguna, atau status alur kerja—simpan sebagai data terstruktur daripada berharap itu bertahan dari ringkasan berulang.

Mencampur cakupan jangka pendek dan jangka panjang

Riwayat thread tidak boleh secara diam-diam menjadi profil pengguna global. Sebaliknya, preferensi pengguna yang dimaksudkan untuk mengikuti pengguna di berbagai chat tidak boleh hidup hanya dalam satu thread.

Menyalin tutorial memori pra-v1 tanpa memeriksa impor

Jika sebuah contoh dimulai dari rantai legacy atau kelas memori lama, bandingkan dengan migrasi v1 saat ini dan dokumentasi memori sebelum menggunakannya dalam aplikasi baru.

Daftar Periksa Pemecahan Masalah

• Konfirmasi bahwa agent dibuat dengan checkpointer.
• Catat dan bandingkan thread_id di antara permintaan berturut-turut.
• Periksa status thread yang disimpan sebelum menyalahkan model.
• Restart proses dan ulangi tes thread yang sama.
• Ganti InMemorySaver dengan checkpointer persisten untuk produksi.
• Ukur pertumbuhan pesan/token selama chat panjang.
• Aktifkan ringkasan atau pemangkasan sebelum riwayat menjadi berlebihan.
• Pertahankan urutan panggilan/hasil alat tetap valid saat menghapus pesan.
• Pindahkan fakta lintas thread ke store jangka panjang berbasis namespace.
• Uji thread baru untuk pengguna yang sama untuk memverifikasi daya ingat jangka panjang yang disengaja.
• Uji pengguna yang berbeda untuk memverifikasi isolasi memori.
• Lacak item memori mana yang diambil untuk setiap jawaban.

Kesimpulan

Kehilangan memori agent LangChain jarang diselesaikan oleh satu jendela konteks yang lebih besar. Pertama, buat status thread persisten dengan checkpointer dan thread_id yang stabil. Kemudian, kendalikan riwayat panjang dengan pemangkasan atau SummarizationMiddleware. Terakhir, tempatkan fakta yang harus bertahan di berbagai percakapan dalam store jangka panjang berbasis namespace dan ambil secara sengaja.

Pemisahan tersebut memberi Anda sesuatu yang jauh lebih berguna daripada “memori”: sebuah sistem yang dapat Anda restart, skalakan, uji, audit, dan pertimbangkan ketika pengguna bertanya, “Mengapa agent lupa?”