腾讯 Agent 记忆系统开源实测：10 秒记住你的习惯
Ranking
No observed public metrics; popularity remains neutral/archived.
Merged summary
TL;DR - Tencent Cloud Database open-sourced TencentDB Agent Memory (~11k GitHub stars), a long-term memory layer for agents, and this article walks through hands-on tests of its write → distill → retrieve → update lifecycle plus a source-code breakdown of its mechanisms. It matters because persistent cross-session memory is being pushed down from the application layer into the database layer.
- Memory pyramid (L0–L3): L0 stores raw dialogue verbatim (millisecond persistence), L1 extracts structured cards (preference/event/rule with priority), L2 groups cards into scenario files with a hit-count "heat" score, L3 is a stable persona summary injected unconditionally into every new session.
- Async distillation latency: raw turns land instantly, but model-based extraction took ~6s, making a card searchable ~10s after being spoken. Triggers default to every 5 turns or 10 idle minutes, with a warm-up ramp (1, 2, 4 turns) at session start.
- Retrieval gotcha: strategy defaults to hybrid (keyword + embedding rank fusion), but semantic recall is off by default, so out-of-the-box it degrades to pure literal matching — testers found "川菜"/"忌口"/"spicy food" failed to recall a "can't eat spicy" memory.
- Conflict arbitration & fallbacks: new cards trigger candidate recall then an LLM decides add/skip/overwrite/merge; without semantic recall, a PostgreSQL→MySQL preference change was stored as a new card alongside the old one. Degradation is fail-soft (retrieval returns empty, 5s injection timeout) so chat never breaks. A separate "task map" externalization reportedly cut WideSearch tokens from 221M to 85M and raised pass rate from 33% to 50%.
Sources (1)
腾讯 Agent 记忆系统开源实测：10 秒记住你的习惯
TL;DR - Tencent Cloud Database open-sourced TencentDB Agent Memory (~11k GitHub stars), a long-term memory layer for agents, and this article walks through hands-on tests of its write → distill → retrieve → update lifecycle plus a source-code breakdown of its mechanisms. It matters because persistent cross-session memory is being pushed down from the application layer into the database layer.
- Memory pyramid (L0–L3): L0 stores raw dialogue verbatim (millisecond persistence), L1 extracts structured cards (preference/event/rule with priority), L2 groups cards into scenario files with a hit-count "heat" score, L3 is a stable persona summary injected unconditionally into every new session.
- Async distillation latency: raw turns land instantly, but model-based extraction took ~6s, making a card searchable ~10s after being spoken. Triggers default to every 5 turns or 10 idle minutes, with a warm-up ramp (1, 2, 4 turns) at session start.
- Retrieval gotcha: strategy defaults to hybrid (keyword + embedding rank fusion), but semantic recall is off by default, so out-of-the-box it degrades to pure literal matching — testers found "川菜"/"忌口"/"spicy food" failed to recall a "can't eat spicy" memory.
- Conflict arbitration & fallbacks: new cards trigger candidate recall then an LLM decides add/skip/overwrite/merge; without semantic recall, a PostgreSQL→MySQL preference change was stored as a new card alongside the old one. Degradation is fail-soft (retrieval returns empty, 5s injection timeout) so chat never breaks. A separate "task map" externalization reportedly cut WideSearch tokens from 221M to 85M and raised pass rate from 33% to 50%.