TencentDB Agent Memory: Share Experience, Not Privacy

August 13, 2026

AI AgentArchitectureDeveloper Tools

Project context shouldn’t need to be re-explained in every session. Documents shouldn’t be re-read from page one. A proven workflow shouldn’t be rediscovered from scratch next time.

This quote from the TencentDB Agent Memory README hits a core pain point in today’s Agent applications: experience can’t be accumulated — every session starts from zero.

This article breaks down the design philosophy behind TencentDB Agent Memory and how it solves this problem.

The Core Problem: Agent Amnesia

flowchart LR
    A["Agent A hits a bug"] --> B["Experience stays in chat"] --> C["Agent B repeats the mistake"] --> D["Team reinvents the wheel"]

Most agents work like this: you spend 20 minutes teaching it project context, it completes the task, and the conversation ends. Next session with a different agent — or even the same one — you start over.

TencentDB Agent Memory’s solution is straightforward: turn experience into reusable assets so the next agent can pick up where you left off.

Design Philosophy: Three Core Judgments

Before diving into technical details, let’s look at three design judgments behind TencentDB Agent Memory. These judgments shaped the entire product:

Judgment 1: Memory Isn’t Flat — It Grows in Layers

Most agent memory solutions store everything flat and recall everything at once. TencentDB chose layering:

flowchart TD
    subgraph "Memory Layers"
        L0["L0 Conversation<br/>Raw dialogue & full context"]
        L1["L1 Atom<br/>Facts, preferences, constraints & events"]
        L2["L2 Scenario<br/>Knowledge blocks organized by project or scene"]
        L3["L3 Persona<br/>Long-term profile, stable patterns & high-level cognition"]
    end

    L0 -->|"Asynchronous refinement"| L1
    L1 -->|"Aggregation"| L2
    L2 -->|"Abstraction"| L3

    L3 -->|"Quick context entry"| Agent
    L2 -->|"Scene recovery"| Agent
    L1 -->|"Precise recall"| Agent
    L0 -->|"Original text verification"| Agent

Layer	What It Stores	Primary Use	Retrieval Strategy
L0 Conversation	Raw dialogue & full context	Verify original text, timing, and source	BM25 exact match
L1 Atom	Facts, preferences, constraints & events	Precise recall of actionable information	Vector search + RRF
L2 Scenario	Knowledge blocks organized by project or scene	Quickly restore a work context	Semantic search
L3 Persona	Long-term profile, stable patterns & high-level cognition	Get agents into user/team context	Direct injection

Why this design?

Context windows are a scarce resource. Injecting L0 full conversation every time would explode token consumption. But injecting only L3’s highly abstracted profile would lose specific details. Layering allows the system to recall on demand: use L2/L3 for quick context entry in daily use, and fall back to L1/L0 via BM25 + vector search + RRF fusion when specific facts are needed.

This is a precision vs. cost tradeoff: layering adds indexing and retrieval complexity but significantly reduces per-session token consumption.

Judgment 2: Memory Isn’t a Global Prompt — It’s an Agent’s Loadout

flowchart TD
    subgraph "Traditional: Global Injection"
        A1["All Memory"] --> A2["Inject into all Agents"]
    end

    subgraph "TencentDB: Loadout Assembly"
        B1["Memory Asset Pool"] --> B2["Team Filter"]
        B2 --> B3["ACL Filter"]
        B3 --> B4["Relevance Recall"]
        B4 --> B5["Inject into specific Agent"]
    end

Traditional approaches dump all memory into the System Prompt — simple but problematic:

Token waste: most memory is irrelevant to the current task
Noise interference: irrelevant information can mislead the agent
Privacy leaks: no granular control over who sees what

TencentDB’s Loadout mechanism solves these issues:

Visibility	Semantics	Use Case
`private`	Only owner can read, team admin excluded	Personal preferences, private decisions
`team`	Team members can read, managed by Owner/Admin	Shared docs, public Skills
`restricted`	Fine-grained via User/Role/Agent ACL	Sensitive info, role-specific assets
`agent`	Targeted assembly for same-team agents	Memory transfer between agents

This is a product decision: TencentDB chose to make “sharing” an explicit action, not a default. New memories are private by default and require active sharing. This aligns with enterprise data security expectations.

Judgment 3: Knowledge Isn’t Injected by the Ton — It’s Called on Demand

flowchart LR
    subgraph "Traditional RAG"
        A1["Document Chunking"] --> A2["Vector Search"]
        A2 --> A3["Top-K Injection"]
    end

    subgraph "TencentDB Wiki + CodeGraph"
        B1["Structured Index"] --> B2["API Discovery"]
        B2 --> B3["On-Demand Call"]
        B3 --> B4["Precise Read"]
    end

Traditional RAG chops documents into chunks and returns Top-K fragments. The problem: fragments lose document structure and relationships.

TencentDB’s Wiki and CodeGraph use a different strategy:

Component	Indexing Method	Query Method	Advantage
Wiki	Structured pages + link graph	`/v3/tools/list` to discover, `/v3/tools/call` to read	Preserves document structure, supports link drill-down
CodeGraph	Symbols, files, call relationships	callers / callees queries	Supports impact analysis, not just text matching

This is a technical tradeoff: pre-indexing adds build cost (asynchronous processing required), but queries are more precise with lower token consumption.

Architecture Overview: How the Three Components Work Together

flowchart TD
    subgraph SA["Deployment Architecture"]
        MC["Memory Core<br/>Memory Processing Engine"] --> MH["Memory Hub<br/>Management Panel + API"]
        MH --> P["Proxy<br/>Agent Access Layer"]
    end

    subgraph MA["Memory Assets"]
        CM["Chat Memory"]
        SK["Skill"]
        WK["Wiki"]
        CG["CodeGraph"]
    end

    subgraph AG["Agent Integration"]
        CC["Claude Code"]
        CB["CodeBuddy"]
        OC["OpenClaw"]
        HM["Hermes"]
    end

    MH --> MA
    P --> AG

Component	Responsibility	Key Capabilities
Memory Core	Memory processing engine	Dialogue refinement (L0→L3), Wiki generation, CodeGraph indexing
Memory Hub	Management panel + API	Asset CRUD, team/permission management, Agent Loadout assembly
Proxy	Agent access layer	Unified API interface, adapts to multiple agent frameworks

Deployment is a one-click startup of all three components:

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # Fill in two sets of LLM params (memory group + proxy group)
./start-all.sh     # One-click start

Four Memory Assets: Deep Dive

Chat Memory: Layered Memory in Practice

Core question: How do you extract structured memory from raw conversations?

flowchart LR
    subgraph "Input"
        A["User dialog<br/>'Don't refactor the old auth module, mobile is still using it'"]
    end

    subgraph "L1 Atom Extraction"
        B["Fact: Old auth module can't be refactored"]
        C["Constraint: Mobile still depends on it"]
        D["Decision: Keep current implementation"]
    end

    subgraph "L2 Scenario Aggregation"
        E["Scenario: Auth module maintenance decision"]
        F["Link: Mobile dependency relationship"]
    end

    subgraph "L3 Persona Abstraction"
        G["Preference: Values backward compatibility"]
        H["Pattern: Conservative refactoring strategy"]
    end

    A --> B & C & D
    B & C & D --> E & F
    E & F --> G & H

Technical details:

L0→L1 extraction: LLM identifies facts, preferences, constraints, and events from conversation
L1→L2 aggregation: Organizes Atoms into knowledge blocks by topic or scenario
L2→L3 abstraction: Distills long-term profiles and stable patterns from multiple Scenarios

Recall strategy:

User question
    ↓
Semantic analysis → Determine which memory layer is needed
    ↓
L2/L3 direct injection (fast context entry)
    ↓
If specific facts are needed
    ↓
BM25 + Vector Search + RRF fusion → Recall L1/L0
    ↓
Limit count + Token budget + Timeout control
    ↓
Inject into Agent context

Why RRF fusion?

Single retrieval strategies have limitations:

BM25: Strong exact matching, but can’t understand semantics
Vector search: Strong semantic understanding, but may miss exact keywords
RRF (Reciprocal Rank Fusion): Combines both rankings, leveraging their complementary strengths

Skill: Not Just a Prompt — an Executable Unit

flowchart TD
    subgraph "Skill Structure"
        A["Version Management"]
        B["Resource Files<br/>Config/Scripts/Templates"]
        C["Trigger Boundary<br/>When to activate"]
        D["Execution Steps<br/>Operation sequence"]
        E["Validation Rules<br/>Post-execution checks"]
    end

    subgraph "Skill Lifecycle"
        F["Agent executes task"] --> G["Skill is distilled"]
        G --> H["Personal Skill is private"]
        H --> I["Review & Share"]
        I --> J["Equip to other agents"]
    end

Skill vs. Prompt:

Dimension	Prompt	Skill
Structure	Plain text	Version + resources + steps + validation
Reusability	One-shot	Iterable, rollbackable
Controllability	None	Trigger boundaries and validation rules
Traceability	None	Version history and usage records

Real-world example:

# Release Checklist Skill
version: 2.1
resources:
  - checklist.md
  - rollback-script.sh
trigger:
  when: "agent is about to deploy code"
  confidence: 0.9
steps:
  - Read checklist.md
  - Verify each item
  - If issues found, execute rollback
validation:
  - Check all tests pass
  - Check deployment script is executable
  - Check rollback path exists

Wiki + CodeGraph: Structured Knowledge Graph

Wiki’s design inspiration comes from Karpathy’s LLM Wiki: treating documents as knowledge assets incrementally maintained by LLMs, generating compound interest over time.

flowchart TD
    subgraph "Wiki Construction"
        A["Source Documents<br/>PRD/Design Specs/Operations Manuals"] --> B["LLM Processing"]
        B --> C["Structured Pages"]
        C --> D["Link Graph"]
    end

    subgraph "CodeGraph Construction"
        E["Code Repository"] --> F["AST Parsing"]
        F --> G["Symbol Index"]
        G --> H["Call Relationship Graph"]
    end

    subgraph "Agent Query"
        I["/v3/tools/list"] --> J["Discover available assets"]
        J --> K["/v3/tools/call"]
        K --> L["Read specific page/source code"]
    end

Key differences:

Traditional RAG	TencentDB Wiki/CodeGraph
Document chunking loses structure	Preserves document structure and link relationships
Text matching can’t understand call relationships	Indexes symbols, call relationships, and impact paths
May return duplicate fragments	Precise reads of specific pages or functions
Can’t do impact analysis	Can query callers / callees

CodeGraph impact analysis in practice:

Agent wants to modify UserService.login()

Traditional RAG:
  Search "UserService login" → returns relevant code snippets
  Agent doesn't know which places call this method

CodeGraph:
  Query UserService.login()'s callers
  Finds: AuthController, SessionManager, TokenService all depend on it
  Agent knows which modules will be affected by this change

Comparison with Industry Solutions

vs. Mem0

Mem0 is another popular agent memory solution.

Dimension	Mem0	TencentDB Agent Memory
Positioning	General memory layer	Team-level memory hub
Memory structure	Flat storage	Layered (L0-L3)
Team collaboration	No native support	Full Team + ACL
Skill management	None	Versioned Skill assets
Code understanding	None	CodeGraph call relationships
Deployment complexity	Low (single service)	Medium (three components)

Core difference: Mem0 suits lightweight memory needs for individuals or small teams; TencentDB is better for enterprise scenarios requiring team collaboration, asset management, and code understanding.

vs. LangGraph Memory

LangGraph provides a Memory module with conversation history management.

Dimension	LangGraph Memory	TencentDB Agent Memory
Memory types	Conversation history	Four asset types
Storage	In-memory/Redis/Postgres	Dedicated storage engine
Team collaboration	Must build yourself	Native support
Knowledge graph	Needs separate integration	Wiki + CodeGraph built-in
Access control	Must build yourself	Four-tier visibility + ACL

Core difference: LangGraph Memory is more flexible (customizable storage backend) but requires more development work; TencentDB is more opinionated and works out of the box.

vs. Zep

Zep is a commercial agent memory platform.

Dimension	Zep	TencentDB Agent Memory
Deployment	SaaS / Self-hosted	Self-hosted (open source)
Memory types	Conversation history + entity extraction	Four asset types
Team collaboration	Basic support	Full Team + ACL
Cost	Usage-based pricing	Free (open source)
Data control	SaaS data in the cloud	Full self-control

Core difference: Zep is a commercial product, ready to use but with costs; TencentDB is open source, requires self-hosting but gives full data control.

Potential Issues & Room for Improvement

Current Limitations

Issue	Impact	Possible Improvement
Memory extraction credibility is questionable	Facts/preferences distilled by LLMs may be inaccurate; bad memories get “inherited”	Provenance tracing, confidence scoring, human verification
Wiki/CodeGraph async construction	First use requires waiting	Incremental updates, pre-warming
CodeGraph prioritizes public repos	Poor private repo experience	SSH credential support, local indexing
Memory routing requires manual binding	Not enough automation	Content-based auto-routing
Limited cross-framework migration	Vendor lock-in risk	Standardized memory format

Memory Credibility: The Overlooked Risk

This issue deserves its own section.

TencentDB Agent Memory relies on LLMs to distill L1 Atoms (facts, preferences, constraints) from conversations. But LLM distillation is not always trustworthy:

An LLM may misread user intent — turning “don’t refactor for now” into “never touch this”

An LLM may overgeneralize — treating a one-off preference as a universal rule

An LLM may drop critical context — losing important constraints

An LLM may invent memories that never existed — hallucinations

Worse: those incorrect memories can be assembled into other agents, creating “error inheritance.” A preference Agent A misunderstood becomes a fact Agent B executes.

The current project doesn’t appear to provide:

Accuracy evaluation for memory extraction
Provenance tracing (which conversation did this memory come from?)
Conflict detection (what happens when two memories contradict?)
Human verification / correction workflows

What this means: TencentDB Agent Memory solves “how experience can be accumulated and shared,” but not fully “whether the accumulated experience is correct.” Users should treat memory assets as less than 100% trustworthy — critical decisions still need human confirmation.

Design Tradeoffs

Layered vs. Flat: Layering adds complexity but reduces query costs. Is this the right tradeoff? It depends on the use case — if agents primarily need fast context entry, layering is worth it; if they frequently query specific facts, layering may add latency.

Pre-indexed vs. On-demand retrieval: Pre-indexing adds build cost but queries are more precise. Is this the right tradeoff? It depends on document/codebase size — small repos benefit from pre-indexing; large repos may need smarter incremental updates.

Private-first vs. Share-first: Defaulting to private is safer but may slow knowledge flow. Is this the right tradeoff? It depends on enterprise security requirements — strict environments need private-first.

When Should You Use It?

The key question isn’t team size — it’s whether you need these capabilities:

Required Capability	Recommended Approach
Cross-session memory, experience accumulation	RAG + simple memory management
Multi-agent memory sharing and isolation	TencentDB Agent Memory
Memory asset versioning and review	TencentDB Agent Memory
Fine-grained access control (ACL)	TencentDB Agent Memory
Structured code understanding (call relationships, impact analysis)	TencentDB Agent Memory
Document knowledge graph (preserving structure and links)	TencentDB Agent Memory

Specific scenarios:

Scenario	Recommended Approach	Reason
Personal agent assistant	Lightweight RAG + local memory	Simple, no maintenance
Enterprise agent platform, no cross-agent sharing needed	RAG + custom development	Big companies use RAG too, it depends on needs
Multi-role agent collaboration with memory isolation and sharing	TencentDB Agent Memory	Native Team + ACL support
Knowledge-intensive project requiring code impact analysis	TencentDB Agent Memory	CodeGraph provides structured indexing
Skill reuse and version management needed	TencentDB Agent Memory	Skill is a complete executable unit

Summary

TencentDB Agent Memory’s core value:

Experience as assets: Turn conversations, documents, and code into reusable Chat Memory, Skill, Wiki, and CodeGraph
Layered storage: L0→L3 progressive refinement, BM25 + vector + RRF fusion recall, balancing precision and cost
Precise assembly: Fixed Binding + ACL, load memory by role and need, control noise and privacy
Team collaboration: Share experience, not privacy, with version management and asset review

This solution addresses a real pain point: how to let agent teams continuously accumulate experience, instead of starting from zero every time.

But it comes with costs: higher architectural complexity and operational overhead. Whether to use it depends on whether your scenario truly needs team-level memory management.

References

TencentDB Agent Memory GitHub — Project homepage (⭐ 20.8k)
INSTALL.md — Installation guide
ROADMAP.md — Project roadmap
CONTRIBUTING.md — Contribution guide
CodeGraph — Upstream project for CodeGraph asset module
Andrej Karpathy’s LLM Wiki — Design inspiration for Wiki layer
Mem0 — General agent memory layer
Zep — Commercial agent memory platform

Attribution

Images and data cited in this article come from the official TencentDB Agent Memory README and have been checked against the source.

项目背景讲过了，不该换个 Session 再讲。文档读过了，不该每个 Agent 从第一页重读。一套做法已经跑通，不该下次再摸索一遍。

这是腾讯开源的 TencentDB Agent Memory 项目 README 里的一段话。读完之后，我意识到它戳中了当前 Agent 应用的一个核心痛点：经验无法沉淀，每次都是从零开始。

这篇文章剖析 TencentDB Agent Memory 的设计思路，看看它如何解决这个问题。

核心问题：Agent 的”健忘症”

flowchart LR
    A["Agent A 踩坑"] --> B["经验留在对话里"] --> C["Agent B 重蹈覆辙"] --> D["团队重复劳动"]

大多数 Agent 的工作模式是这样的：你花 20 分钟教它项目背景，它完成了任务，然后对话结束。下次换个 Agent 或换个 Session，一切重来。

TencentDB Agent Memory 的解法很直接：把经验变成可复用的资产，让下一个 Agent 直接读档开工。

设计哲学：三个核心判断

在深入技术细节之前，先看 TencentDB Agent Memory 背后的三个设计判断。这三个判断决定了整个产品的走向：

判断一：记忆不是平铺的，而是分层生长的

大多数 Agent 记忆方案把所有信息平铺存储，查询时一次性召回。TencentDB 的选择是分层：

flowchart TD
    subgraph "记忆分层"
        L0["L0 Conversation<br/>原始对话与完整上下文"]
        L1["L1 Atom<br/>事实、偏好、约束与事件"]
        L2["L2 Scenario<br/>围绕项目或场景组织的知识块"]
        L3["L3 Persona<br/>长期画像、稳定模式与高层认知"]
    end

    L0 -->|"异步提炼"| L1
    L1 -->|"聚合"| L2
    L2 -->|"抽象"| L3

    L3 -->|"快速进入语境"| Agent
    L2 -->|"场景恢复"| Agent
    L1 -->|"精确召回"| Agent
    L0 -->|"核对原话"| Agent

层级	保存什么	主要用途	检索策略
L0 Conversation	原始对话与完整上下文	核对原话、时间和来源	BM25 精确匹配
L1 Atom	事实、偏好、约束与事件	精确召回可执行信息	向量检索 + RRF
L2 Scenario	围绕项目或场景组织的知识块	快速恢复一个工作场景	语义检索
L3 Persona	长期画像、稳定模式与高层认知	让 Agent 进入用户和团队语境	直接注入

为什么这样设计？

上下文窗口是稀缺资源。如果每次都注入 L0 全量对话，token 消耗会爆炸。但如果只注入 L3 高度抽象的画像，又会丢失具体细节。分层让系统可以根据当前需求按需召回：平时用 L2/L3 快速进入语境，需要具体事实时通过 BM25 + 向量检索 + RRF 融合回到 L1/L0。

这是一个精度 vs 成本的权衡：分层增加了索引和检索的复杂度，但显著降低了每次对话的 token 消耗。

判断二：记忆不是全局 Prompt，而是 Agent 的 Loadout

flowchart TD
    subgraph "传统方案：全局注入"
        A1["所有记忆"] --> A2["注入所有 Agent"]
    end

    subgraph "TencentDB：Loadout 装配"
        B1["记忆资产池"] --> B2["按 Team 过滤"]
        B2 --> B3["按 ACL 过滤"]
        B3 --> B4["按问题相关性召回"]
        B4 --> B5["注入特定 Agent"]
    end

传统方案把所有记忆塞进 System Prompt，简单粗暴但问题明显：

token 浪费：大部分记忆与当前任务无关
噪音干扰：无关信息可能误导 Agent
隐私泄露：无法精确控制谁看什么

TencentDB 的 Loadout 机制解决了这些问题：

可见性	语义	使用场景
`private`	只有 Owner 可读，团队管理员也不例外	个人偏好、私密决策
`team`	团队成员可读，Owner / Admin 负责管理	共享文档、公共 Skill
`restricted`	通过 User / Role / Agent ACL 精确授权	敏感信息、特定角色专属
`agent`	用于同团队 Agent 的定向装配	Agent 间的记忆传递

这是一个产品决策：TencentDB 选择让”分享”成为一个显式动作，而不是默认行为。新记忆默认私有，需要主动分享。这符合企业场景下的数据安全预期。

判断三：知识不整库注入，而是按需调用

flowchart LR
    subgraph "传统 RAG"
        A1["文档切片"] --> A2["向量检索"]
        A2 --> A3["Top-K 注入"]
    end

    subgraph "TencentDB Wiki + CodeGraph"
        B1["结构化索引"] --> B2["API 发现"]
        B2 --> B3["按需调用"]
        B3 --> B4["精确读取"]
    end

传统 RAG 把文档切成片段，检索时返回 Top-K 片段。问题是：片段丢失了文档的结构和关系。

TencentDB 的 Wiki 和 CodeGraph 采用了不同的策略：

组件	索引方式	查询方式	优势
Wiki	结构化页面 + 链接图谱	`/v3/tools/list` 发现，`/v3/tools/call` 读取	保留文档结构，支持链接下钻
CodeGraph	符号、文件、调用关系	callers / callees 查询	支持 impact analysis，不只是文本匹配

这是一个技术权衡：预索引增加了构建成本（需要异步处理），但查询时更精确，token 消耗更低。

架构全景：三件套如何协作

flowchart TD
    subgraph SA["部署架构"]
        MC["Memory Core<br/>记忆处理引擎"] --> MH["Memory Hub<br/>管理面板 + API"]
        MH --> P["Proxy<br/>Agent 接入层"]
    end

    subgraph MA["记忆资产"]
        CM["Chat Memory"]
        SK["Skill"]
        WK["Wiki"]
        CG["CodeGraph"]
    end

    subgraph AG["Agent 接入"]
        CC["Claude Code"]
        CB["CodeBuddy"]
        OC["OpenClaw"]
        HM["Hermes"]
    end

    MH --> MA
    P --> AG

组件	职责	关键能力
Memory Core	记忆处理引擎	对话提炼（L0→L3）、Wiki 生成、CodeGraph 索引
Memory Hub	管理面板 + API	资产 CRUD、团队/权限管理、Agent Loadout 装配
Proxy	Agent 接入层	统一 API 接口，适配多种 Agent 框架

部署方式是一键拉起三件套：

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # 填入两组 LLM 参数（memory 组 + proxy 组）
./start-all.sh     # 一键起

四种记忆资产：深度解析

Chat Memory：记忆分层的技术实现

核心问题：如何从原始对话中提取结构化记忆？

flowchart LR
    subgraph "输入"
        A["用户对话<br/>'别重构旧鉴权模块，移动端还在用'"]
    end

    subgraph "L1 Atom 提取"
        B["事实: 旧鉴权模块不能重构"]
        C["约束: 移动端仍在使用"]
        D["决策: 保持现有实现"]
    end

    subgraph "L2 Scenario 聚合"
        E["场景: 鉴权模块维护决策"]
        F["关联: 移动端依赖关系"]
    end

    subgraph "L3 Persona 抽象"
        G["偏好: 重视向后兼容"]
        H["模式: 保守重构策略"]
    end

    A --> B & C & D
    B & C & D --> E & F
    E & F --> G & H

技术细节：

L0→L1 提取：LLM 从对话中识别事实、偏好、约束和事件
L1→L2 聚合：按主题或场景将 Atom 组织成知识块
L2→L3 抽象：从多个 Scenario 中提炼长期画像和稳定模式

召回策略：

用户问题
    ↓
语义分析 → 判断需要哪层记忆
    ↓
L2/L3 直接注入（快速进入语境）
    ↓
如果需要具体事实
    ↓
BM25 + 向量检索 + RRF 融合 → 召回 L1/L0
    ↓
条数限制 + 字符预算 + 超时控制
    ↓
注入 Agent 上下文

为什么需要 RRF 融合？

单一检索策略有局限：

BM25：精确匹配强，但无法理解语义
向量检索：语义理解强，但可能漏掉精确关键词
RRF（Reciprocal Rank Fusion）：融合两种排序，取长补短

Skill：不只是 Prompt，而是可执行单元

flowchart TD
    subgraph "Skill 结构"
        A["版本管理"]
        B["资源文件<br/>配置/脚本/模板"]
        C["触发边界<br/>什么场景激活"]
        D["执行步骤<br/>操作序列"]
        E["验证规则<br/>执行后校验"]
    end

    subgraph "Skill 生命周期"
        F["Agent 执行任务"] --> G["提炼 Skill"]
        G --> H["个人 Skill 私有"]
        H --> I["审核分享"]
        I --> J["配装给其他 Agent"]
    end

Skill 与 Prompt 的区别：

维度	Prompt	Skill
结构	纯文本	版本 + 资源 + 步骤 + 验证
复用性	一次性	可迭代、可回滚
可控性	无	有触发边界和验证规则
可追溯性	无	有版本历史和使用记录

实际例子：

# Release Checklist Skill
version: 2.1
resources:
  - checklist.md
  - rollback-script.sh
trigger:
  when: "agent准备发布代码"
  confidence: 0.9
steps:
  - 读取 checklist.md
  - 逐项验证
  - 如果发现问题，执行回滚
validation:
  - 检查所有测试通过
  - 检查部署脚本可执行
  - 检查回滚路径存在

Wiki + CodeGraph：结构化知识图谱

Wiki 的设计灵感来自 Karpathy 的 LLM Wiki：将文档视为由 LLM 增量维护、可持续复利的知识产物。

flowchart TD
    subgraph "Wiki 构建"
        A["原始文档<br/>PRD/设计稿/运维手册"] --> B["LLM 处理"]
        B --> C["结构化页面"]
        C --> D["链接图谱"]
    end

    subgraph "CodeGraph 构建"
        E["代码仓库"] --> F["AST 解析"]
        F --> G["符号索引"]
        G --> H["调用关系图"]
    end

    subgraph "Agent 查询"
        I["/v3/tools/list"] --> J["发现可用资产"]
        J --> K["/v3/tools/call"]
        K --> L["读取特定页面/源码"]
    end

关键区别：

传统 RAG	TencentDB Wiki/CodeGraph
文档切片，丢失结构	保留文档结构和链接关系
文本匹配，无法理解调用关系	索引符号、调用关系、影响路径
每次检索可能返回重复片段	精确读取特定页面或函数
无法做 impact analysis	可以查 callers / callees

CodeGraph 的 impact analysis 场景：

Agent 要修改 UserService.login() 方法

传统 RAG：
  检索 "UserService login" → 返回相关代码片段
  Agent 不知道哪些地方调用了这个方法

CodeGraph：
  查询 UserService.login() 的 callers
  发现：AuthController、SessionManager、TokenService 都依赖它
  Agent 知道修改这个方法会影响哪些模块

与业界方案的深度对比

与 Mem0 的对比

Mem0 是另一个流行的 Agent 记忆方案。

维度	Mem0	TencentDB Agent Memory
定位	通用记忆层	团队级记忆中枢
记忆结构	扁平存储	分层（L0-L3）
团队协作	无原生支持	完整的 Team + ACL
Skill 管理	无	版本化 Skill 资产
代码理解	无	CodeGraph 调用关系
部署复杂度	低（单服务）	中（三件套）

核心差异：Mem0 更适合个人或小团队的轻量记忆需求；TencentDB 更适合需要团队协作、资产管理和代码理解的企业场景。

与 LangGraph Memory 的对比

LangGraph 提供了 Memory 模块，支持对话历史管理。

维度	LangGraph Memory	TencentDB Agent Memory
记忆类型	对话历史	四种资产类型
存储方式	内存/Redis/Postgres	专用存储引擎
团队协作	需自建	原生支持
知识图谱	需额外集成	Wiki + CodeGraph 内置
权限控制	需自建	四级可见性 + ACL

核心差异：LangGraph Memory 更灵活（可以自定义存储后端），但需要更多开发工作；TencentDB 开箱即用，但定制性相对较低。

与 Zep 的对比

Zep 是一个商业化的 Agent 记忆平台。

维度	Zep	TencentDB Agent Memory
部署方式	SaaS / 自托管	自托管（开源）
记忆类型	对话历史 + 实体提取	四种资产类型
团队协作	基础支持	完整 Team + ACL
成本	按用量付费	免费（开源）
数据控制	SaaS 版数据在云端	完全自控

核心差异：Zep 是商业产品，开箱即用但有成本；TencentDB 是开源方案，需要自建但数据完全可控。

潜在问题与改进空间

当前局限

问题	影响	可能的改进方向
记忆提取可信度存疑	LLM 提炼的事实/偏好可能不准确，错误记忆会被”传承”	记忆来源追溯、置信度评分、人工验证机制
Wiki/CodeGraph 异步构建	首次使用需要等待	增量更新、预热机制
CodeGraph 优先支持公开仓库	私有仓库体验差	SSH 凭证支持、本地索引
记忆路由仍需人工绑定	自动化程度不够	基于内容的自动路由
跨框架迁移有限	锁定风险	标准化记忆格式

记忆可信度：被忽视的风险

这是一个值得单独展开的问题。

TencentDB Agent Memory 的记忆提取依赖 LLM 从对话中提炼 L1 Atom（事实、偏好、约束）。但 LLM 提炼的结果不一定可信：

LLM 可能误解用户意图，把”暂时不重构”提炼成”永远不动”

LLM 可能错误归纳，把个案偏好当成普遍规则

LLM 可能遗漏关键上下文，丢失重要约束

LLM 可能添加不存在的”记忆”，产生幻觉

更危险的是：这些错误记忆会被装配给其他 Agent，形成”错误传承”。Agent A 误解的偏好，会被 Agent B 当成事实执行。

当前项目没有看到：

记忆提取的准确率评估机制
记忆来源追溯（这条记忆是从哪段对话提炼的？）
记忆冲突检测（两条记忆矛盾时怎么办？）
人工验证/纠正流程

这意味着：TencentDB Agent Memory 解决了”经验如何沉淀和共享”的问题，但没有完全解决”沉淀的经验是否正确”的问题。使用者需要意识到，记忆资产不是 100% 可信的，关键决策仍需人工确认。

设计权衡的思考

分层 vs 扁平：分层增加了复杂度，但降低了查询成本。这是一个正确的权衡吗？取决于使用场景——如果 Agent 主要需要快速进入语境，分层是值得的；如果需要频繁查询具体事实，分层可能增加延迟。

预索引 vs 按需检索：预索引增加了构建成本，但查询更精确。这是一个正确的权衡吗？取决于文档/代码库的大小——小库预索引划算，大库可能需要更智能的增量更新。

私有优先 vs 共享优先：默认私有更安全，但可能降低知识流动效率。这是一个正确的权衡吗？取决于企业安全要求——严格环境下私有优先是必要的。

适用场景：什么时候该用？

选型的关键不是团队规模，而是是否需要以下能力：

需要的能力	推荐方案
跨 Session 记忆、经验沉淀	RAG + 简单记忆管理
多 Agent 间的记忆共享和隔离	TencentDB Agent Memory
记忆资产的版本管理和审核	TencentDB Agent Memory
精细的权限控制（ACL）	TencentDB Agent Memory
结构化的代码理解（调用关系、影响分析）	TencentDB Agent Memory
文档知识图谱（保留结构和链接关系）	TencentDB Agent Memory

具体场景：

场景	推荐方案	原因
个人 Agent 助手	轻量 RAG + 本地记忆	简单够用，无需运维
企业级 Agent 平台，但不需要跨 Agent 记忆共享	RAG + 定制开发	大企业也在用 RAG，关键看需求
多角色 Agent 协作，需要记忆隔离和共享	TencentDB Agent Memory	原生支持 Team + ACL
知识密集型项目，需要代码影响分析	TencentDB Agent Memory	CodeGraph 提供结构化索引
需要 Skill 复用和版本管理	TencentDB Agent Memory	Skill 是完整的可执行单元

总结

TencentDB Agent Memory 的核心价值：

经验资产化：把对话、文档、代码变成可复用的 Chat Memory、Skill、Wiki、CodeGraph
分层存储：L0→L3 逐层提炼，BM25 + 向量 + RRF 融合召回，平衡精度与成本
精准装配：Fixed Binding + ACL，按角色和需求加载记忆，控制噪音和隐私
团队协作：共享经验，不共享隐私，支持版本管理和资产审核

这套方案解决了一个真实痛点：如何让 Agent 团队的经验持续积累，而不是每次从零开始。

但它也有代价：架构复杂度较高，需要一定的运维成本。选择是否使用，取决于你的场景是否真的需要团队级的记忆管理。

参考资料

TencentDB Agent Memory GitHub — 项目主页（⭐ 20.8k）
INSTALL_CN.md — 完整安装指南
ROADMAP_CN.md — 项目路线图
CONTRIBUTING_CN.md — 贡献指南
CodeGraph — CodeGraph 资产模块复用的上游项目
Andrej Karpathy 的 LLM Wiki — Wiki 层设计灵感来源
Mem0 — 通用 Agent 记忆层方案
Zep — 商业化 Agent 记忆平台

引用说明

本文引用的图片和数据来自 TencentDB Agent Memory 官方 README，已核对原文。