Was ist Chain of Recall? Wie stabile IDs KI-Agenten ein Gedächtnis verleihen

Posted on Nov 5 • Originally published at apidog.com

Chain of Recall ist ein Ansatz, um langlebigen KI-Agenten ein Gedächtnis zu geben, ohne deren Kontextfenster zu überladen. Jeder Trigger, Thread und Worker erhält eine dauerhafte ID. Im Kontext verbleiben lediglich IDs, kurze Zusammenfassungen und benachbarte Nachrichten – der Agent folgt dann den Verknüpfungen zwischen den IDs, um ältere Fakten in wenigen Schritten abzurufen.

Der Begriff stammt aus dem Design-Essay „Exploring Super-agent Design“ von DeepSeek Harness, der am 01.11.2026 veröffentlicht wurde. Ein wichtiger Hinweis vorab: Der Essay beschreibt eine Architektur, kein fertiges Produktfeature. Teile davon finden sich in einem Prototyp-Plugin namens dsh-superagent-prototype, das die Autoren ausdrücklich als „kein offizielles DeepSeek-Produkt“ bezeichnen. Es gibt keinen Schalter, mit dem sich Chain of Recall einfach aktivieren ließe – es handelt sich um ein Entwurfsmuster, das man selbst implementiert.

Ein langlebiger Agent stößt unweigerlich an seine Kontextgrenzen, da kontinuierlich neue Aufgaben eingehen. Ein Super-Agent, der Chats, GitHub und CI-Pipelines überwacht, verarbeitet täglich Hunderte von Ereignissen – und das Fenster, das die Aufgaben von gestern enthielt, kann die von heute nicht auch noch aufnehmen.

Die üblichen Lösungsansätze haben alle ihren Preis:

Anthropics Leitfaden zu Context Engineering für KI-Agenten beschreibt den Kontext als begrenzte Ressource, die man gezielt kuratieren muss. Chain of Recall ist ein konkreter Weg für diese Kuration – und unser Übersichtsartikel darüber, wie das Gedächtnis von KI-Agenten funktioniert, beleuchtet das gesamte Spektrum der Möglichkeiten.

Der Essay betrachtet das Kontextfenster wie einen Cache mit zwei zentralen Operationen:

Ein ausgelagertes Element wird nicht gelöscht; lediglich sein Zeiger verbleibt im Prompt.

So sieht das beispielsweise für einen CI-Fehlschlag aus, der beim Router eingeht. Diese Struktur dient der Veranschaulichung und stellt keinen Originalcode von DeepSeek dar:

{ "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 Reicht die einzeilige Zusammenfassung aus, fallen für den Agenten keine Token-Kosten für das 41-KB-Log an. Reicht sie nicht, ruft er das Log gezielt über die ID ab.

Chain of Recall funktioniert deshalb, weil sich die IDs niemals ändern. Im Design des Essays tragen drei Arten von Objekten solche IDs:

Ein Trigger gehört zu einem Thread, ein Thread wird von einem oder mehreren Workern verwaltet, und der Bericht eines Workers verweist auf die Trigger, auf deren Basis er agiert hat. Diese Verknüpfungen bilden einen Referenzgraphen – und dieser Graph ist das Gedächtnis des Agenten.

Der Abruf erfolgt Schritt für Schritt durch das Verfolgen dieser Verknüpfungen – nicht durch das Laden des gesamten Verlaufs oder das Durchsuchen nach ähnlichen Texten. Der ergänzende Leitfaden zum Aufbau eines Super-Agenten erklärt, wie sich Trigger, Threads und Worker in das Gesamtdesign aus Router und Workern einfügen.

Angenommen, ein Teammitglied fragt den Router am Freitag: „Warum haben wir dem Payments-Client eine Retry-Logik hinzugefügt?“ Die ursprüngliche Diskussion fand am Dienstag statt und wurde längst ausgelagert. So läuft der Abruf ab:

Drei kleine, präzise API-Aufrufe. Nichts wurde erraten, und nichts musste drei Tage lang unnötig im Prompt verweilen.

Chain of Recall ersetzt andere Gedächtnistechniken nicht, sondern beantwortet eine grundlegend andere Frage. Der Vektorabruf, bekannt geworden durch das Paper zu Retrieval-Augmented Generation, fragt: „Was sieht dem hier ähnlich?“ Chain of Recall fragt hingegen: „Was ist damit verknüpft?“

In der Praxis wird man diese Ansätze kombinieren: Ein Vektorindex findet eine anfängliche Thread-ID, und Chain of Recall navigiert von dort aus zu den exakten Fakten. Die an Betriebssysteme angelehnte Speicherhierarchie aus dem MemGPT-Paper ist ein eng verwandtes Konzept. Wenn Sie lieber mit einer vorgefertigten Speicherlösung starten möchten, hilft Ihnen unser Leitfaden zum Hinzufügen von persistentem Speicher für KI-Agenten mit MCP weiter.

Zwei Einschränkungen: Der Essay führt Langzeitgedächtnis unter den ungelösten Problemen auf und beansprucht keineswegs, dass Chain of Recall dieses Problem löst. Zudem stieg im dortigen Experiment durch das Entfernen des Thread-Pass-Throughs die Zahl der Cache-Read-Tokens von 23,2 Mio. auf 31,8 Mio. pro Durchlauf – ein Zuwachs von rund 37 %. Dies waren jedoch die Kosten eines fehlenden Features und keine Ersparnis durch Chain of Recall selbst.

Jeder Schritt in diesem Ablauf ist ein API-Aufruf. Wenn ein einziger Aufruf einen falschen oder gar keinen Datensatz zurückgibt, reißt die Kette ab – und der Agent bleibt entweder hängen oder greift auf bloße Vermutungen zurück. Daher müssen die APIs hinter Chain of Recall vier verbindliche Zusagen erfüllen:

Solche Vereinbarungen brechen bei Refactorings oft unbemerkt und gehören daher zwingend in automatisierte Tests. Zudem müssen die Antworten von Tools kompakt gehalten werden, worauf unser Leitfaden zu Tool-Antworten bei Agenten und dem Kontextfenster detailliert eingeht.

Chain of Recall ist nur so zuverlässig wie seine Fetch-by-ID-Endpunkte – und ein Coding-Agent kann diese Prüfungen für Sie erstellen und regelmäßig ausführen. Apidog CLI stellt dem Agenten Befehle bereit, um Endpunkte zu definieren, Testfälle zu erstellen und diese direkt über das Terminal auszuführen.

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 Geben Sie Claude Code, Codex oder dem von Ihnen genutzten Agenten anschließend folgenden [REDACTED PROMPT] In Apidog project, 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:

Der Agent liest jedes Payload-Schema ein, validiert das JSON, bevor Daten geschrieben werden, und erstellt sowie führt die Testfälle aus: Enter fullscreen mode Exit fullscreen mode bash apidog cli-schema get endpoint-create apidog cli-schema validate endpoint-create --file thread-get.json apidog endpoint create --project --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 --file id-resolves.json

apidog run --test-case --project -e -r cli,json