🧠 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。数字を出したことへの反応としては素直だと思う。

元ネタ: https://github.com/TencentCloud/TencentDB-Agent-Memory