从 VexDB 看 Active Memory：AI Agent 的记忆到底该怎么设计

2025 年底，一个不太起眼的概念开始在 AI 基础设施圈子里传开：Active Memory（主动记忆）。

它跟向量数据库有关，但不是”又一个向量数据库”。它回答的是一个更根本的问题——AI Agent 的记忆应该是什么形态？是被动等待查询的存储桶，还是能主动参与推理、具备时效感知和遗忘机制的认知系统？

VexDB 是这个问题目前最有野心的答案之一。它的核心设计哲学可以用一句话概括：记忆不是存出来的，是活出来的。

---

一、为什么向量数据库不够用了

先看现状。2026 年的大多数 AI Agent 用向量数据库做长期记忆：对话历史向量化存入，需要时做相似度检索。这套流程跑通之后，大家都觉得”记忆问题解决了”。

但实际上有几个根本性问题一直没被解决：

问题一：所有记忆同等重要

向量数据库存储的是静态向量。昨天存入的向量跟一年前存入的向量在检索时的权重是一样的（除非你手动加 metadata filter）。但人类的记忆不是这样工作的——最近发生的事、反复出现的事、跟当前上下文相关的事，天然比不相关的事更容易被想起来。

问题二：记忆之间没有关联

向量检索做语义相似度匹配，但不构建记忆之间的关联网络。你知道 Agent 在三个月前提到过某个项目，但你可能不知道那个项目跟今天讨论的问题有什么关联——因为向量空间里它们是孤立的点。

问题三：记忆不会”衰减”和”遗忘”

人类的记忆会随时间衰减，不重要的细节会被遗忘，只保留概要。但向量数据库里的所有数据永久存在，除非你手动删除。这意味着检索结果会随着时间被越来越多的噪声稀释。

问题四：记忆不能”主动”参与推理

在标准架构里，Agent 先决定”我需要回忆什么”，然后查询向量库，最后把检索结果塞进 prompt。这是被动检索。但真正有用的记忆系统应该能在 Agent 推理过程中主动触发——“等等，这个场景我之前处理过”。

Active Memory 要解决的就是这四个问题。

---

二、VexDB 的架构设计

VexDB（Vector Experience Database）的架构设计有几个关键特征，值得逐一拆解。

2.1 三层记忆结构

VexDB 不把所有数据存在一个平面的向量空间里，而是分了三层：

工作记忆（Working Memory）：

• 存储在内存中，只保留最近 N 轮交互的关键信息
• 高访问频率，低延迟要求（< 10ms）
• 自动过期机制——超过时间窗口的数据自动降级到长期记忆

情景记忆（Episodic Memory）：

• 存储具体的历史交互事件
• 每个条目包含：时间戳、上下文、参与实体、情感标记
• 支持时间范围查询和关联查询

语义记忆（Semantic Memory）：

• 存储从情景记忆中提炼出的”知识”
• 类似人类的”经验总结”——不记得具体是哪天发生的，但知道该怎么做
• 通过周期性 consolidation 过程从情景记忆中提炼

这三层对应认知心理学中对人类记忆的分类。VexDB 的设计巧妙之处在于：它不是简单地把数据分三个表存，而是定义了数据在三层之间流动的机制。

2.2 记忆巩固（Consolidation）

这是 VexDB 最核心的创新。

人类的记忆在睡眠中会经历”巩固”——白天的短期记忆被筛选、重组、整合进长期记忆。VexDB 模拟了这个过程：

情景记忆（新事件）
    ↓ [定期触发，比如每 24 小时]
Consolidation 引擎
    ↓
    ├── 重要事件 → 保留在情景记忆中，标记为"高重要性"
    ├── 可提炼知识 → 提取为语义记忆条目
    └── 低价值事件 → 归档或删除

Consolidation 的具体规则：

• 频率加权：同一主题的事件出现 3 次以上，自动提炼为语义记忆
• 时间衰减：情景记忆条目的检索权重随时间指数衰减（半衰期可配置）
• 关联增强：如果两个事件在语义上相关且经常被一起检索，在它们之间建立显式关联

2.3 主动触发（Active Recall）

这是”Active Memory”中”Active”的来源。

传统的向量检索是 Agent 发起查询 → 数据库返回结果。VexDB 增加了一个反向通道：

当 Agent 在处理某个任务时，VexDB 的记忆引擎会并行扫描工作记忆和情景记忆，如果发现匹配模式，主动向 Agent 推送相关记忆。

举个例子：

• Agent 正在调试一个数据库连接问题
• VexDB 的记忆引擎检测到”数据库”、“连接”、“超时”等关键词
• 主动推送：「3 周前，用户遇到过类似的 PostgreSQL 连接超时问题，解决方案是调整 max_connections 参数」

这种机制的关键是低开销——主动扫描不能显著拖慢 Agent 的推理速度。VexDB 的实现方式是在后台维护一个轻量级的索引，只在 Agent 的推理步骤之间进行异步扫描。

2.4 记忆图谱（Memory Graph）

VexDB 不只有向量索引，还在语义记忆层维护了一个图结构。

每个语义记忆条目是一个节点，条目之间的关联是边。边的权重由关联强度决定——两个条目被同时检索的频率越高，边的权重越大。

这个图结构让 Agent 能做”跳跃式”回忆：

• 从”数据库连接超时”跳到”PostgreSQL 配置”
• 从”PostgreSQL 配置”跳到”上次系统升级的时间”
• 从”系统升级”跳到”升级后出现的其他问题”

这在纯向量检索中是做不到的——向量检索只能找到跟查询直接相似的条目，不能做关联推理。

---

三、跟现有方案的对比

维度	向量数据库（Chroma/Pinecone）	LangGraph Checkpointer	VexDB Active Memory
存储结构	平面向量空间	状态快照	三层记忆 + 图谱
时间感知	无（需手动加 metadata）	有（按时间线存储）	内建（衰减 + 过期）
遗忘机制	无	无	有（Consolidation）
主动触发	无	无	有
关联推理	不支持	不支持	支持（Memory Graph）
查询延迟	低	极低	中（主动扫描增加开销）
部署复杂度	低	低	中高

VexDB 的设计更复杂，但换来的是更接近人类记忆能力的功能。是否值得，取决于你的 Agent 需要多强的”记住”能力。

---

四、实战：用开源组件搭建一个轻量版 Active Memory

VexDB 本身还在开发中，但你已经可以用现有组件搭一个轻量版的 Active Memory 系统。

组件选择

• 工作记忆：Redis（内存存储，天然支持过期）
• 情景记忆：ChromaDB（轻量向量库，支持 metadata filter）
• 语义记忆：ChromaDB 独立 collection + NetworkX（图结构）
• Consolidation：定时任务（Celery 或 APScheduler）

工作记忆的实现

import redis
import json

class WorkingMemory:
    def __init__(self, ttl_seconds=3600):
        self.redis = redis.Redis(host='localhost', port=6379)
        self.ttl = ttl_seconds

    def store(self, session_id: str, key: str, value: dict):
        self.redis.set(
            f"wm:{session_id}:{key}",
            json.dumps(value),
            ex=self.ttl
        )

    def retrieve(self, session_id: str) -> dict:
        pattern = f"wm:{session_id}:*"
        results = {}
        for key in self.redis.scan_iter(pattern):
            results[key.decode()] = json.loads(self.redis.get(key))
        return results

工作记忆用 Redis 的好处是 TTL 机制天然支持”遗忘”——超过时间窗口的数据自动消失，不需要手动清理。

情景记忆的存储

import chromadb
from datetime import datetime

class EpisodicMemory:
    def __init__(self):
        self.client = chromadb.PersistentClient(path="./episodic")
        self.collection = self.client.get_or_create_collection("episodes")

    def store(self, episode: dict):
        self.collection.add(
            embeddings=[episode["embedding"]],
            documents=[episode["content"]],
            metadatas=[{
                "timestamp": episode["timestamp"],
                "topic": episode["topic"],
                "entities": json.dumps(episode.get("entities", [])),
                "importance": episode.get("importance", 0.5)
            }],
            ids=[episode["id"]]
        )

    def retrieve(self, query_embedding: list, hours=24) -> list:
        # 时间衰减加权
        cutoff = datetime.now().timestamp() - hours * 3600
        results = self.collection.query(
            query_embeddings=[query_embedding],
            n_results=10,
            where={"timestamp": {"$gt": cutoff}}
        )
        return self._apply_decay(results)

    def _apply_decay(self, results, half_life_hours=48):
        # 指数衰减加权
        now = datetime.now().timestamp()
        for i, metadata in enumerate(results["metadatas"][0]):
            age_hours = (now - metadata["timestamp"]) / 3600
            decay = 0.5 ** (age_hours / half_life_hours)
            results["distances"][0][i] *= (1 - decay * 0.5)
        return results

情景记忆的关键设计是检索时的时间衰减。不是删除旧数据，而是在检索时给旧数据降低权重。这样既保留了完整的历史，又让新数据更容易被检索到。

Consolidation 引擎

from apscheduler.schedulers.blocking import Scheduler
from collections import Counter

class ConsolidationEngine:
    def __init__(self, episodic, semantic):
        self.episodic = episodic
        self.semantic = semantic

    def run(self):
        # 1. 获取所有情景记忆
        all_episodes = self.episodic.collection.get(include=["documents", "metadatas"])

        # 2. 按主题聚类
        topics = Counter(m["topic"] for m in all_episodes["metadatas"])

        # 3. 高频主题提炼为语义记忆
        for topic, count in topics.items():
            if count >= 3:
                # 提取该主题的概要
                summary = self._summarize_topic(all_episodes, topic)
                self.semantic.store({
                    "content": summary,
                    "source_topic": topic,
                    "source_count": count,
                    "consolidated_at": datetime.now().isoformat()
                })

        # 4. 清理低重要性旧事件
        self._archive_low_importance()

    def _summarize_topic(self, episodes, topic):
        # 用 LLM 对该主题的所有事件做摘要
        topic_episodes = [
            d for d, m in zip(episodes["documents"], episodes["metadatas"])
            if m["topic"] == topic
        ]
        return llm.summarize(topic_episodes)

Consolidation 是 Active Memory 系统最重要的组件。它的核心逻辑很简单：高频出现的模式值得提炼成知识，低重要性的旧事件应该归档。

---

五、VexDB 对 Agent 架构的影响

VexDB 代表的 Active Memory 范式，对 AI Agent 的设计有深远影响：

5.1 Agent 的”直觉”

有了主动触发机制，Agent 开始表现出类似”直觉”的能力——不是通过逻辑推理得出的结论，而是记忆引擎主动推送的相关经验。这种”直觉”在多轮对话场景中特别有用：用户还没说完，Agent 已经根据记忆预判了需求。

5.2 个性化体验

Consolidation 让 Agent 的记忆随时间进化。使用一个月的 Agent 和使用一天的 Agent，拥有不同的语义记忆。这意味着同样的产品，给不同用户的服务会越来越个性化——不是因为模型变了，是因为记忆变了。

5.3 可解释性

记忆图谱让 Agent 的决策过程更可解释。当 Agent 做出某个建议时，你可以追溯它引用了哪些记忆条目，这些条目是如何关联的。这比单纯看 LLM 的推理链（chain of thought）更透明。

---

六、什么时候不该用 Active Memory

不是所有场景都需要这么复杂的记忆系统。

不需要 Active Memory 的场景：

• 单轮问答（没有上下文连续性需求）
• 工具调用型 Agent（记忆全部是工具定义，不需要情景存储）
• 高频低延迟场景（Active Memory 的主动扫描会增加 10-50ms 的延迟）

需要 Active Memory 的场景：

• 多轮对话助手（需要记住用户偏好和历史）
• 个性化推荐 Agent（需要从交互历史中提炼用户画像）
• 长期陪伴型 Agent（需要随时间”了解”用户）
• 复杂任务规划 Agent（需要从过往经验中提取模式）

---

七、未来方向

Active Memory 是 2026 年 AI Agent 基础设施中最值得关注的方向之一。几个正在发展的趋势：

1. 图向量融合：向量检索和图遍历的混合查询正在成为标配，单纯选一个都不够
2. 端侧记忆：随着小模型能力提升，部分记忆处理将迁移到端侧，减少云端依赖
3. 跨 Agent 记忆共享：多个 Agent 之间共享语义记忆层的协议正在标准化
4. 记忆压缩：用更小模型提炼记忆概要的技术正在成熟，降低存储成本

VexDB 可能是 Active Memory 的第一个工业级实现，但它不会是最后一个。这个方向的竞争才刚刚开始。