Chain of Recall Nedir? Stable ID'ler Yapay Zeka Ajanlarına Nasıl Hafıza Kazandırır

Chain of Recall, uzun süre çalışan bir yapay zekâ ajanına, bağlam penceresini (context window) her şeyle doldurmak zorunda kalmadan bellek kazandırmanın bir yoludur. Her bir Trigger, Thread ve Worker kalıcı bir ID alır. Bağlamda yalnızca ID'ler, kısa özetler ve yakın iletiler saklanır; ajan ise daha eski verilere ulaşmak için bu ID'ler arasındaki bağlantıları birkaç adımda izler.

Bugün Apidog'u deneyin

Bu terim, DeepSeek Harness'ın 01.11.2026 tarihinde yayımlanan "Exploring Super-agent Design" başlıklı tasarım makalesinden geliyor. Devam etmeden önce küçük bir uyarı: Bu makale kullanıma sunulmuş bir özellikten değil, bir mimariden bahsediyor. Mimarinin bazı bölümleri, yazarların "resmî bir DeepSeek ürünü değildir" şeklinde tanımladığı prototip bir eklenti olan dsh-superagent-prototype içinde yer alıyor. Yani açabileceğiniz hazır bir Chain of Recall anahtarı yok; bu, bizzat inşa etmeniz gereken bir tasarım kalıbıdır.

Uzun süre çalışan bir ajanda bağlam penceresi sorunu

Uzun süre çalışan bir ajan, iş akışı hiç durmadığı için eninde sonunda bağlam sınırına takılır. Sohbet kanallarını, GitHub'ı ve CI süreçlerini izleyen bir süper ajan günde yüzlerce olayla karşılaşır; dünkü işleri barındıran bir pencerenin bugünküleri de taşıması mümkün değildir.

Bu duruma karşı başvurulan alışılagelmiş yöntemlerin her birinin bir bedeli vardır:

• Her şeyi saklamak: Bağlam penceresi hızla dolar ve maliyet her turda katlanarak artar.
• Eski turları özetlemek: Özetleme süreci, daha sonra ihtiyaç duyacağınız net bir hata mesajını veya PR numarasını gözden kaçırabilir.
• Benzerliğe göre getirmek (similarity retrieval): İhtiyacınız olan bilgi arama sorgunuza benzemediği anda bu yöntem yetersiz kalır.

Anthropic'in yapay zekâ ajanları için bağlam mühendisliği rehberi, bağlamı titizlikle yönetilmesi gereken kısıtlı bir kaynak olarak ele alır. Chain of Recall, bu yönetimi gerçekleştirmenin somut yollarından biridir; yapay zekâ ajanlarında belleğin nasıl çalıştığını anlatan rehberimiz ise çok daha geniş bir seçenek yelpazesini kapsamaktadır.

Inline ve spill: Bir önbellek olarak bağlam

Makalede bağlam penceresi iki temel hamleye sahip bir önbellek gibi ele alınır:

• Inline: Ajanın o an ihtiyaç duyma olasılığı yüksek olanları (ID'ler, kısa özetler, komşu iletiler) doğrudan bağlamda tutmak.
• Spill: Geri kalan her şeyi dışarı aktarmak; yani içeriği kısaltıp ajanın daha sonra takip edebileceği bir işaretçi (pointer) bırakmak.

Dışarı aktarılan (spill edilen) bir öğe silinmez; yalnızca işaretçisi prompt içinde kalır.

Router'a gelen bir CI hatası için bu yapının nasıl göründüğüne dair bir örnek (bu biçim sadece örneklendirme amaçlıdır, DeepSeek'in doğrudan kodu değildir):

{
  "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)"
  }
}

Tek satırlık özet yeterliyse, ajan hiçbir zaman 41 KB'lık günlüğün maliyetini üstlenmek zorunda kalmaz. Yetersiz kaldığında ise günlüğü doğrudan ID üzerinden çeker.

Kalıcı ID'ler ve referans grafı

Chain of Recall'un işe yaramasının temel nedeni, ID'lerin hiçbir zaman değişmemesidir. Makaledeki tasarıma göre bu kimlikleri üç farklı nesne türü taşır:

Bir Trigger bir Thread'e aittir, bir Thread bir veya daha fazla Worker tarafından yönetilir ve bir Worker'ın raporu üzerinde işlem yaptığı Trigger'lara atıfta bulunur. Bu bağlantılar bir referans grafı oluşturur ve işte bu graf ajanın belleğidir.

Bilgiyi geri çağırma (recall) işlemi; tüm geçmişi yükleyerek ya da benzer metinleri aratarak değil, bağlantıları adım adım takip ederek gerçekleşir. Tam Router ve Worker mimarisinde Trigger, Thread ve Worker bileşenlerinin nereye oturduğunu öğrenmek için süper ajan oluşturma rehberimize göz atabilirsiniz.

Adım adım çok atlamalı geri çağırma örneği

Diyelim ki bir ekip arkadaşınız Cuma günü Router'a şu soruyu sordu: "Ödeme istemcisine neden yeniden deneme (retry) mantığı ekledik?" İlgili tartışma Salı günü gerçekleşmiş ve çoktan dışarı aktarılmıştır (spill edilmiştir). İzlenen adımlar şöyledir:

1. Thread'i bulma: Router'ın bağlamında hâlâ tek satırlık bir dizin kaydı bulunmaktadır: thr_pr_412: payments retry PR, merged Wed. Buradan GET /threads/thr_pr_412 çağrısını yapar.
2. Worker'ı bulma: Thread kaydında owner_workers: ["wkr_77a0"] listelenmektedir. Router, GET /workers/wkr_77a0 isteğini atar ve Worker'ın nihai raporunu okur.
3. Nedeni bulma: Rapor, CI hatası olan trg_8f21 kaydına atıfta bulunur. Router bu Trigger'ın yükünü (payload) çeker ve günlükteki zaman aşımı hatalarını okur.
4. Yanıt: "PR #412 üzerindeki CI süreci Salı günü 3 ödeme zaman aşımı nedeniyle başarısız oldu. Worker wkr_77a0 üstel geri çekilmeli (backoff) yeniden deneme mantığı ekledi ve PR Çarşamba günü birleştirildi (merge edildi)."

Üç küçük ve nokta atışı veri çekme işlemi. Hiçbir şey tahmin edilmedi ve prompt içinde üç gün boyunca gereksiz hiçbir veri tutulmadı.

Vektör bellek ve özetlere karşı Chain of Recall

Chain of Recall diğer bellek tekniklerinin yerini almaz; farklı bir soruya yanıt verir. Retrieval-augmented generation (RAG) makalesi ile popülerleşen vektörel getirme "buna ne benziyor?" sorusunu sorarken, Chain of Recall "buna ne bağlı?" sorusunu sorar.

Pratikte bunları birlikte kullanırsınız: Vektör dizini başlangıç için bir Thread ID'si bulur, ardından Chain of Recall adım adım ilerleyerek kesin bilgilere ulaşır. MemGPT makalesinde ele alınan işletim sistemi tarzı bellek hiyerarşisi bu yapının yakın bir akrabasıdır. Hazır bir depolama çözümüyle başlamayı tercih ederseniz, MCP ile yapay zekâ ajanlarına kalıcı bellek ekleme rehberimize göz atabilirsiniz.

Burada iki sınırlama bulunuyor. Makale, uzun vadeli belleği henüz çözülmemiş açık problemler arasında sıralıyor ve Chain of Recall'un bunu tek başına çözdüğünü iddia etmiyor. Ayrıca deneylerde Thread doğrudan geçişinin (pass-through) kaldırılması, çalıştırma başına önbellek okuma token'larını 23,2 milyondan 31,8 milyona çıkararak yaklaşık %37'lik bir artışa neden oldu; bu durum Chain of Recall'un sağladığı bir tasarruf değil, eksik bir özelliğin getirdiği maliyettir.

Arka plandaki API'lerin sağlaması gereken garantiler

Bu senaryodaki her adım bir API çağrısıdır. Tek bir çağrı farklı bir kayıt dönerse ya da hiç kayıt dönmezse zincir kırılır; ajan ya takılıp kalır ya da tahmin yürüterek yanıt verir. Bu nedenle Chain of Recall'un arkasındaki API'lerin dört temel sözleşmeyi karşılaması gerekir:

1. ID'ler hiçbir zaman değişmez: Bugün dönen bir ID, gelecek ay da aynı nesneye karşılık gelmelidir. Silinen ID'ler tekrar kullanılamaz ve veri taşıma (migration) sonrası yeniden numaralandırma yapılamaz.
2. ID ile getirme (fetch-by-ID) hızlı, düşük maliyetli ve kesindir: GET /threads/{id} doğrudan o kaydı döndürür; arama yapmaz veya "en yakın eşleşmeyi" getirmez.
3. Bilinmeyen ID'ler açıkça hata verir: Bulunamayan bir ID, RFC 9110 standardında tanımlandığı şekilde net bir hata gövdesiyle birlikte 404 Not Found dönmelidir. Boş bir nesneyle dönen 200 yanıtı, ajana aslında var olmayan bir belleğin mevcut olduğunu düşündürür.
4. İmleçler (cursor) boşluk bırakmadan sayfalar: GET /threads/{id}/events?cursor= uzun bir Thread'i sırayla tarar. Her olay tam olarak bir kez görünür, hiçbir şey atlanmaz ve yeni olaylar gelse bile imleç geçerliliğini korur.

Bu sözleşmeler yeniden yapılandırma (refactor) süreçlerinde sessizce bozulabilir; bu yüzden otomatik testlerle güvenceye alınmalıdır. Ayrıca ajan araç yanıtları ve bağlam penceresi hakkındaki rehberimizde ayrıntılı olarak ele aldığımız gibi, araç yanıtlarının da küçük tutulması gerekir.

Kodlama ajanınızın recall API'lerini Apidog CLI ile test etmesini sağlayın

Chain of Recall, yalnızca ID ile getirme uç noktaları kadar güvenilirdir ve bir kodlama ajanı bu kontrolleri sizin yerinize yazıp tekrar tekrar çalıştırabilir. Apidog CLI; ajana uç noktaları tanımlaması, test senaryoları oluşturması ve bunları terminalden çalıştırması için gerekli komutları sağlar.

Tek seferlik kurulum:

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

Ardından Claude Code, Codex veya kullandığınız ajan hangisiyse ona şu prompt'u verin:

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.

Ajan her yük (payload) şemasını okur, herhangi bir şey yazmadan önce JSON formatını doğrular, ardından test senaryolarını oluşturup çalıştırır:

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

cli raporlayıcısı terminalde her doğrulama (assertion) için başarılı ve başarısız durumlarını yazdırırken, json raporu ajana hangi adımın bozulduğunu açıklayabilmesi için okuyabileceği bir dosya sunar. Bir migration sonrasında bir ID çözümlenemez hale gelirse, ajanınız kopuk bir zincire dayanarak yanıt üretmeye başlamadan önce bunu raporda görürsünüz. Aynı kontrolleri her merge işleminde çalıştırmak için raporlayıcıyı -r junit ile değiştirebilirsiniz; Claude Code içinde Apidog CLI incelememiz ajan döngüsünün tamamını göstermektedir.

Chain of Recall nerede devreye girer?

Ajanınızın belleği birbiriyle bağlantı kurulabilir ayrık olayların (PR'lar, biletler, CI çalıştırmaları, destek talepleri, dağıtımlar) geçmişinden oluşuyorsa Chain of Recall kullanın. Bu olaylar zaten doğal ID'lere sahiptir ve insanların onlar hakkında sorduğu sorular ("bunu neden yaptık?", "ondan sonra ne oldu?") doğrudan bu bağlantılarla ilgilidir.

Yapılandırılmamış belgeler ve ucu açık sorular için vektörel getirmeyi; ayrıntı kaybının sorun teşkil etmediği kısa oturumlar içinse özetleri tercih edin.

Chain of Recall tek bir makaleden ve prototipten doğmuştur: Bir ürün değil, net ve test edilebilir bir fikirdir. Makalenin arkasındaki aracı tanımak için DeepSeek Harness'ın ne olduğunu anlatan yazımızla başlayabilirsiniz.

SSS

Chain of Recall etkinleştirebileceğim bir DeepSeek özelliği mi?
Hayır. Bu, DeepSeek Harness'ın süper ajan makalesinde geçen bir terimdir ve belirli kısımları yazarların resmî bir DeepSeek ürünü olmadığını belirttiği prototip bir eklentide yer almaktadır. Bu kalıbı kendiniz hayata geçirirsiniz.

Inline ve spill arasındaki fark nedir?
Inline; ID'leri, kısa özetleri ve komşu iletileri prompt içinde tutar. Spill ise geri kalan kısmı kırpar ve gerektiğinde ajanın ID ile çekebileceği bir işaretçi bırakır.

Chain of Recall, RAG'in yerini mi alıyor?
Hayır. RAG benzer içerikleri bulur; Chain of Recall ise doğrudan kesin ID bağlantılarını takip eder. Birçok ajan her ikisini birlikte kullanır.

Chain of Recall token kullanımını %37 oranında azalttı mı?
Hayır. %37 rakamı Thread doğrudan geçişiyle (pass-through) ilgilidir: Makaledeki deneyde bunun kaldırılması, çalıştırma başına önbellek okuma token'larını 23,2 milyondan 31,8 milyona çıkarmıştır. Makalede Chain of Recall'un kendisi için bildirilen bir token tasarrufu bulunmamaktadır.

ID ile getirme API'si bilinmeyen bir ID için ne döndürmelidir?
Net bir hata gövdesiyle birlikte 404 Not Found döndürmelidir. Boş bir nesneyle 200 dönmek, ajanın böyle bir kaydın var olduğuna inanmasına yol açarak geri çağırma zincirini sessizce bozar.

Ajanımın bellek API'lerinin kararlı kaldığını nasıl test edebilirim?
Bir çağrıdan alınan ID'nin bir sonrakinde çözümlendiğini, bilinmeyen ID'lerin 404 döndürdüğünü ve imleçlerin boşluk bırakmadan sayfalama yaptığını doğrulayan test senaryoları yazın. Bir kodlama ajanı, Apidog CLI kullanarak her merge işleminde bunları oluşturabilir ve çalıştırabilir.