🧠 TencentのAIエージェント用メモリ基盤、SWE-benchの成功率を58.4%から64.2%へ
TencentDB Agent MemoryはL0からL3までの4層で会話を圧縮しつつ元データへ遡れる設計。WideSearch成功率は33%から50%、トークン消費は最大61%減。自己申告ベンチマークの中身を読む。
エージェントに記憶を持たせる話は、たいていベンチマークの手前で止まる。効きそうな設計は語られるのに、で、どれだけ効いたのという数字が出てこない。
TencentCloud/TencentDB-Agent-Memory はそこを飛ばさなかった。SWE-benchの成功率が58.4%から64.2%、WideSearchが33%から50%、トークン消費は最大61%減。作者の自己申告で第三者の追試はまだ無いので、そこは差し引いて読む必要がある。それでも、測って出しているだけで珍しい部類だ。
記憶を「圧縮」するというより「階層化」する
エージェントに長期記憶を持たせる方法として、これまではベクトルDBに会話をそのまま突っ込む方式が主流だった。TencentDB Agent Memoryはそれをやらない。会話ログをL0からL3まで4段のピラミッドに変換する。
- L0: 生の会話ログ
- L1: アトミックな事実
- L2: シーン単位のブロック
- L3: ユーザーペルソナ
下の層はデータベースに証拠として残り、上の層はMarkdownファイルとして構造だけを持つ。上に行くほど圧縮されるが、必要になれば下の層まで遡って元のやり取りを確認できる。「圧縮したら追跡できなくなる」というありがちなトレードオフを、二層戦略で避けている格好だ。
保存先はデフォルトでこうなる。
~/.openclaw/memory-tdai/
├── l1_facts/
├── l2_scenes/
└── l3_persona.md
全部人間が読めるファイルなので、エージェントが「なぜその判断をしたか」を後から検証できる。ベクトルの中身をダンプしてもわからない、というよくある不満がここでは起きない。
短期記憶はMermaidグラフで持たせる
長期記憶とは別に、直近のタスク状態は「短期記号化メモリ」という仕組みで扱う。冗長なツール実行ログを外部ファイルにオフロードし、タスクの状態遷移をMermaidのグラフとして持つ。ノードIDを指定すればログの詳細までドリルダウンできる。
ログをそのままコンテキストに積み続けると、古い方針と新しい方針が混ざって挙動がおかしくなることがある。あれをMermaidグラフ1枚に押し込めてしまえば、直近の状態だけをコンテキストに乗せられる。トークン削減の6割はここの効果が大きいはずだ。
導入は拍子抜けするほど簡単
OpenClaw環境なら、プラグインを1つ入れるだけで動く。
openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
~/.openclaw/openclaw.json に "enabled": true を足せば自動起動する。バックエンドはローカルのSQLite + sqlite-vecがデフォルトで、リモートならTencent Cloud TCVDBにも対応する。ゼロ設定で動くと謳っているツールは大抵どこかで詰まるものだが、少なくとも構成の複雑さは持ち込まない設計になっている。
日本語圏はまだ「階層メモリ」の理論止まり
Zenn・Qiitaで階層メモリを調べると、L0〜L3の概念設計を語る記事はいくつも出てくる。でも、この規模のベンチマークを出したOSS実装を扱った記事はまだ見当たらなかった。理論は輸入されているのに、実装の話は追いついていない状態だ。
Mem0のようなフラットなベクトル蓄積との違いは、この「証拠を残したまま圧縮する」という一点に尽きる。RAGだけで長期記憶を組んで recall の精度に悩んでいるなら、一度READMEを読んでみる価値はある。公開から日が浅いのにスターは9.3k、フォークは885。数字を出したことへの反応としては素直だと思う。