ai newsDo., 5. Nov.
EilmeldungRun LLMs Locally in 2026: Ollama vs LM Studio vs llama.cpp, Compared

Apa Itu Chain of Recall? Cara Stable ID Memberikan Memori pada Agen AI

Apa Itu Chain of Recall? Cara Stable ID Memberikan Memori pada Agen AI Chain of Recall adalah cara memberikan memori kepada agen AI yang berjalan lama tanpa harus menjejalkan semuanya ke dalam context window-nya. Setiap Trigger, Thread, dan Worker mendapatkan ID yang stabil. Konteks hanya menyimpan

dev.toDonnerstag 08:04 · 05.11.7 Min. Lesezeit
Bild: dev.to

Posted on Nov 5 • Originally published at apidog.com

Chain of Recall adalah cara memberikan memori kepada agen AI yang berjalan lama tanpa harus menjejalkan semuanya ke dalam context window-nya. Setiap Trigger, Thread, dan Worker mendapatkan ID yang stabil. Konteks hanya menyimpan ID, ringkasan singkat, dan pesan-pesan terdekat, lalu agen menelusuri tautan antar-ID untuk mengambil fakta-fakta lama hanya dalam beberapa langkah (hops).

Istilah ini berasal dari esai desain DeepSeek Harness bertajuk "Exploring Super-agent Design" yang dipublikasikan pada 01-11-2026. Satu catatan penting sebelum Anda melangkah lebih jauh: esai tersebut memaparkan sebuah arsitektur, bukan fitur yang sudah dirilis. Sebagian darinya diimplementasikan dalam sebuah plugin purwarupa, dsh-superagent-prototype, yang oleh para penulisnya disebut sebagai "bukan produk resmi DeepSeek". Tidak ada sakelar untuk mengaktifkan Chain of Recall. Ini adalah pola arsitektur yang perlu Anda bangun sendiri.

Agen yang berjalan lama (long-running agent) cepat atau lambat akan membentur batas konteksnya karena pekerjaan tidak pernah berhenti berdatangan. Super-agent yang memantau obrolan, GitHub, dan CI melihat ratusan peristiwa setiap hari, dan jendela konteks yang menampung pekerjaan kemarin tidak akan mampu menampung pekerjaan hari ini sekaligus.

Solusi yang biasa digunakan masing-masing memiliki konsekuensi tersendiri:

Panduan Anthropic mengenai rekayasa konteks untuk agen AI memandang konteks sebagai sumber daya terbatas yang harus dikurasi. Chain of Recall adalah salah satu cara konkret untuk melakukan kurasi tersebut, dan panduan kami tentang cara kerja memori agen AI mengulas berbagai opsi lain yang lebih luas.

Esai tersebut memperlakukan context window layaknya sebuah cache dengan dua pendekatan:

Item yang di-spill tidak dihapus; melainkan hanya pointernya yang tetap tersimpan di dalam prompt.

Beginilah gambarannya saat sebuah kegagalan CI masuk ke Router. Struktur ini bersifat ilustratif, bukan kode resmi dari DeepSeek:

{ "trigger_id": "trg_8f21", "source": "github.check_run", "thread_id": "thr_pr_412", "summary": "CI failed on PR #412: 3 of 118 tests red in payments/", "neighbours": [ "trg_8f1c: review comment asking for retry logic" ], "spilled": { "full_log": "GET /triggers/trg_8f21/payload (41 KB, truncated)" } } Enter fullscreen mode Exit fullscreen mode Jika ringkasan satu baris tersebut sudah cukup, agen tidak perlu membayar biaya token untuk log sebesar 41 KB. Jika tidak, agen tinggal mengambil log lengkap berdasarkan ID-nya.

Chain of Recall dapat bekerja karena ID tidak pernah berubah. Dalam rancangan esai tersebut, ada tiga jenis objek yang memilikinya:

Trigger merupakan bagian dari Thread, Thread dimiliki oleh satu atau beberapa Worker, dan laporan Worker mengutip Trigger yang telah ditindaklanjutinya. Tautan-tautan tersebut membentuk graf referensi, dan graf itulah yang menjadi memori agen.

Recall dilakukan dengan menelusuri tautan selangkah demi selangkah (hop by hop), bukan dengan memuat seluruh riwayat atau mencari teks yang mirip. Panduan pendamping kami tentang cara membangun super-agent menjelaskan posisi Trigger, Thread, dan Worker dalam rancangan lengkap Router dan Worker.

Katakanlah seorang rekan kerja bertanya kepada Router pada hari Jumat: "Mengapa kita menambahkan logika retry ke klien pembayaran?" Diskusi awalnya terjadi pada hari Selasa dan sudah di-spill sejak lama. Berikut tahapan penelusurannya:

Tiga pemanggilan data yang kecil dan presisi. Tidak ada yang ditebak-tebak, dan tidak ada data yang perlu mengendap di dalam prompt selama tiga hari.

Chain of Recall tidak menggantikan teknik memori lainnya, melainkan menjawab pertanyaan yang berbeda. Retrieval berbasis vektor, yang dipopulerkan oleh makalah retrieval-augmented generation, menjawab pertanyaan "apa yang mirip dengan ini?" Sedangkan Chain of Recall menjawab pertanyaan "apa yang terhubung dengan ini?"

Dalam praktiknya, Anda akan menggabungkan keduanya: indeks vektor bertugas menemukan Thread ID awal, lalu Chain of Recall menelusurinya hingga ke fakta-fakta yang tepat. Hierarki memori bergaya sistem operasi pada makalah MemGPT memiliki konsep yang sangat berdekatan. Jika Anda lebih memilih memulai dengan solusi penyimpanan siap pakai, simak panduan kami tentang menambahkan memori persisten ke agen AI dengan MCP.

Ada dua batasan yang perlu dicatat. Esai tersebut menempatkan memori jangka panjang sebagai masalah terbuka dan tidak mengklaim bahwa Chain of Recall menyelesaikannya. Selain itu, dalam eksperimennya, penghapusan Thread pass-through justru meningkatkan token pembacaan cache dari 23,2 juta menjadi 31,8 juta per run (naik sekitar 37%): ini adalah biaya akibat ketiadaan fitur, bukan penghematan yang dihasilkan oleh Chain of Recall.

Setiap hop dalam alur penelusuran tersebut merupakan panggilan API. Jika satu panggilan saja mengembalikan catatan yang berbeda, atau tidak mengembalikan apa pun, rantai akan terputus dan agen akan macet atau menjawab berdasarkan tebakan semata. Oleh karena itu, API di balik Chain of Recall wajib mematuhi empat kontrak:

Kontrak-kontrak ini kerap rusak tanpa disadari saat refaktorisasi kode, sehingga pengujian otomatis mutlak diperlukan. Respons tool juga harus tetap ringkas, sebagaimana dibahas secara mendalam dalam panduan kami mengenai respons tool agen dan context window.

Keandalan Chain of Recall sepenuhnya bergantung pada endpoint fetch-by-ID miliknya, dan sebuah coding agent dapat menulis serta menjalankan ulang pengujian tersebut untuk Anda. Apidog CLI menyediakan perintah-perintah bagi agen untuk mendefinisikan endpoint, membuat skenario pengujian, dan menjalankannya langsung dari terminal.

npm install -g apidog-cli@latest apidog auth login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted Enter fullscreen mode Exit fullscreen mode Kemudian berikan satu prompt berikut ke Claude Code, Codex, atau agen apa pun yang Anda gunakan:

In Apidog project <projectId>, define three endpoints for our agent memory service: GET /threads/{id}, GET /threads/{id}/events?cursor=, and GET /workers/{id}. Then create test cases that check: 1. A thread_id returned by GET /threads/{id} resolves to the same record on a second call, and each owner worker ID resolves via GET /workers/{id}. 2. An unknown thread ID and an unknown worker ID both return 404. 3. Paging GET /threads/{id}/events with the cursor returns every event once, in order, with no gaps. Run them against the staging environment and summarize any failures. Enter fullscreen mode Exit fullscreen mode Agen akan membaca setiap skema payload, memvalidasi JSON-nya sebelum menulis apa pun, lalu membuat dan menjalankan skenario pengujian tersebut:

apidog cli-schema get endpoint-create apidog cli-schema validate endpoint-create --file thread-get.json apidog endpoint create --project <projectId> --file thread-get.json apidog cli-schema get test-case-create apidog cli-schema validate test-case-create --file id-resolves.json apidog test-case create --project <projectId> --file id-resolves.json apidog run --test-case <caseId> --project <projectId> -e <envId> -r cli,json Enter fullscreen mode Exit fullscreen mode Reporter cli akan mencetak status berhasil dan gagal per asersi di terminal, sedangkan laporan json memberi agen sebuah berkas yang dapat dibaca untuk menjelaskan hop mana yang terputus. Jika suatu ID tidak lagi dapat diakses setelah migrasi, Anda akan mengetahuinya dari laporan tersebut sebelum agen Anda mulai memberikan jawaban berdasarkan rantai yang terputus. Untuk menjalankan pemeriksaan yang sama di setiap proses merge, ubah reporter menjadi -r junit; panduan kami tentang Apidog CLI di Claude Code memperlihatkan alur kerja agen secara lengkap.

Gunakan Chain of Recall saat memori agen Anda berupa riwayat peristiwa diskret yang dapat saling ditautkan: PR, tiket masalah, eksekusi CI, utas dukungan pengguna, deployment. Peristiwa-peristiwa ini sudah memiliki ID alami, dan pertanyaan yang diajukan orang mengenainya ("mengapa kita melakukan ini?", "apa yang terjadi setelah itu?") pada dasarnya adalah pertanyaan seputar keterkaitan hubungan antar-peristiwa.

Gunakan retrieval vektor untuk dokumen tidak terstruktur dan pertanyaan yang tidak pasti, serta gunakan ringkasan untuk sesi-sesi singkat di mana hilangnya detail tidak menjadi masalah.

Chain of Recall bermula dari satu esai dan sebuah purwarupa: sebuah ide yang jelas dan dapat diuji, bukan sebuah produk jadi. Untuk mempelajari tool di balik esai tersebut, mulailah dengan membaca artikel apa itu DeepSeek Harness.

Apakah Chain of Recall merupakan fitur DeepSeek yang bisa saya aktifkan?

Tidak. Ini adalah istilah dari esai super-agent DeepSeek Harness, dan sebagian implementasinya berada dalam plugin purwarupa yang oleh penulisnya dinyatakan bukan produk resmi DeepSeek. Anda perlu mengimplementasikan pola arsitektur ini sendiri.

Inline mempertahankan ID, ringkasan singkat, dan pesan-pesan terdekat di dalam prompt. Sementara spill memangkas sisanya dan meninggalkan pointer yang dapat dipanggil agen berdasarkan ID saat diperlukan.

Apakah Chain of Recall menggantikan RAG?

Tidak. RAG bertugas menemukan konten yang serupa; Chain of Recall menelusuri tautan ID yang pasti. Banyak agen yang menggunakan kombinasi keduanya.

Apakah Chain of Recall memangkas konsumsi token hingga 37%?

Tidak. Angka 37% tersebut berkaitan dengan Thread pass-through: menghapusnya justru meningkatkan token pembacaan cache dari 23,2 juta menjadi 31,8 juta per run dalam eksperimen di esai tersebut. Esai itu tidak mencatat adanya penghematan token khusus untuk Chain of Recall itu sendiri.

Apa yang seharusnya dikembalikan oleh API fetch-by-ID jika ID tidak dikenal?

Mengembalikan 404 Not Found disertai error body yang jelas. Mengembalikan status 200 dengan objek kosong justru akan membuat agen mengira data tersebut ada, yang berakibat pada putusnya rantai recall tanpa terdeteksi.

Bagaimana cara memastikan API memori agen saya tetap stabil?

Buat skenario pengujian yang memverifikasi bahwa ID dari satu pemanggilan dapat diakses pada pemanggilan berikutnya, ID yang tidak dikenal menghasilkan respons 404, dan kursor halaman berfungsi tanpa celah data. Sebuah coding agent dapat membuat dan menjalankan pengujian ini menggunakan Apidog CLI di setiap merge.

Quelle: dev.to (dev.to). Original öffnen