问题是：向量数据库并非真正的"记忆"

过去一年间，随着开发者工作流向 Claude Code、Cursor 以及自定义 Agent 集群等自主编码 Agent 迁移，一个显而易见的技术短板变得无法回避：

AI Agent 患有全面失忆症。

每次会话结束或子 Agent 被唤醒时，模型的运行上下文就被清空。当第二天让 Agent 实现一个新功能时，它完全不记得：

• 昨天花了两个小时讨论的架构取舍。
• 上周确定的数据库约束和 Schema 规范。
• 花了一整个上午才隔离出来的 Bug 变通方案。

为此，大多数团队默认采用标准"RAG 记忆"方案：

1. 捕获对话轮次。
2. 用 OpenAI 或 Jina 生成向量嵌入。
3. 将文本块存入向量数据库（Pinecone、Chroma、pgvector）。
4. 下一轮运行时执行余弦相似度搜索。

虽然这套演示在 3 页 PPT 上看起来很漂亮，但在真实软件工程场景中完全失效。

1. 向量搜索对时间无感知

考虑这个真实场景：

• 2026 年 1 月：你对 Agent 说："我们用 MySQL 8 做认证数据库。"
• 2026 年 8 月：你对 Agent 说："我们把认证数据库迁移到了带行级安全性的 PostgreSQL 18。"

当用"我们用什么数据库做认证？"查询时，这两句话的语义嵌入几乎相同。标准最近邻向量搜索会返回两个事实，且相似度得分几乎相等。LLM 产生困惑，将两者合并，或者虚构出一个错误的混合配置。

2. 缺乏词法精确性和负向精度

密集向量相似度本质上是概率性的。它在以下场景中表现不佳：

• 精确的符号名和标识符（ORA-00942、DiskANN、River）。
• 具体版本号（PostgreSQL 18 vs 16）。
• 负向规则（"在任何情况下都不要使用包 X"）。

3. 上下文窗口膨胀与 Token 效率低下

由于向量搜索缺乏精确性，开发者通过增加 top_k 候选数量或向提示中塞入庞大的 3000 行 .cursorrules 文件来弥补。

如果你的 Agent 每天执行 100 次查询，每轮都倾倒 6000 token 的原始历史记录，每天就浪费 600,000 token——每月在 LLM 账单上多花数百美元，却没有真正解决失忆问题。

---

解决方案：设计 Nexusyn

为了从根本上解决 Agent 记忆问题，我们设计了 Nexusyn（https://nexusyn.ai）。Nexusyn 不是简单地在嵌入模型外层包一层外壳，而是一个专为 Agent 长期记忆设计的数据平面。

以下是它的工作原理架构解析。

                    ┌─────────────────────────┐
                    │      AI Agent / IDE     │
                    │ (Claude Code, Cursor, …)│
                    └────────────┬────────────┘
                         HTTP    │   MCP (/v1/mcp)
                                 ▼
┌────────────────────────────────────────────────────────────────────────┐
│                             NEXUSYN ENGINE                             │
│                                                                        │
│   POST /v1/ingest                                POST /v1/query        │
│         │                                              │               │
│         ▼                                              ▼               │
│   [ Deduplication ]                             [ Sub-query Gen ]      │
│         │                                              │               │
│   [ Chunker ]                                   [ Hybrid Retrieval ]   │
│         │                                       ├── Vector (DiskANN)   │
│         ▼                                       ├── BM25 Full-Text     │
│   [ River Queue (Async) ]                       ├── Entity Graph       │
│   ├── Batch Embeddings                          └── Date Anchor Boost  │
│   ├── Entity & Relation Extraction                     │               │
│   └── Wiki / Profile Compilation                       ▼               │
│                                                 [ Reranker (Cross-Enc) ]│
│                                                        │               │
│                                                        ▼               │
│                                                 [ Grounded Synthesizer ]│
└────────────────────────────────────────────────────────────────────────┘

1. 基于 DiskANN 的高吞吐向量索引

我们选用了 Go 1.24 和 PostgreSQL 18（配合 pgvectorscale）。

传统 HNSW（Hierarchical Navigable Small World）向量索引消耗大量内存，因为整个图必须驻留在内存中。相比之下，DiskANN 将压缩后的向量表示存储在内存中，而将主图索引保留在 SSD/NVMe 上。

• 比 HNSW 低 3.4 倍的内存消耗（规模条件下）。
• 单事务 ACID 一致性：关系表、时间戳和向量嵌入共存于同一数据库引擎，并带有行级安全性（RLS）。

2. 基于倒数排名融合（RRF）的序列化混合搜索

当 Agent 查询 Nexusyn 时，引擎在单个只读事务中执行混合搜索：

• 稠密向量检索：在 DiskANN 索引上执行余弦距离搜索。
• PostgreSQL BM25 搜索：在 tsvector 上执行带语言词干提取的词法匹配。
• 倒数排名融合（RRF）：使用以下公式合并结果：$$RRF_Score(d) = \sum_{m \in M} \frac{1}{k + r_m(d)}$$（其中 $k=60$）。
• Cross-Encoder 重排：融合后的前 64 名候选通过托管的 cross-encoder 重排器，评估查询与每个文本块之间的精确语义相关性。

3. 双时间事实版本控制

Nexusyn 中的每条记忆记录都携带两条独立的时间轴：

• 事务时间（Transaction Time）：事实被记录到数据库的时间。
• 有效时间（Valid Time）（valid_from / valid_to）：事实在现实世界中为真的时间。

当 Agent 记录了一条与之前事实相矛盾或更新了之前事实的新决策时，引擎会将之前事实的 valid_to 标记为 now()。历史审计追踪保持完整，但活动查询永远不会将过时状态召回为当前事实。

4. 异步知识图谱

记忆不是扁平的文本，而是由实体、决策和约束相互连接的网络。由 Go 的 River 队列（基于 Postgres）驱动的异步后台队列将命名实体和关系提取到双时间知识图谱中。

通过 get_related 工具，Agent 可以遍历多跳连接（例如将 API 速率限制追溯到强制执行它的安全审查）。

---

原生 Model Context Protocol（MCP）集成

Nexusyn 没有强迫开发者编写定制的 SDK 封装，而是通过 Streamable HTTP（/v1/mcp）实现了官方的 Model Context Protocol（MCP）规范。

它向任何符合 MCP 协议的客户端直接暴露 7 个原生工具：

• add_memory：保存事实、决策、偏好和经验教训。
• search_memory：执行混合检索并返回带引用来源的可靠答案。
• get_guideline：确定性检索组织标准。
• get_related：在知识图谱上探索 1-2 跳的关联关系。
• graph_overview：结构拓扑、中心节点和概念连接器。
• update_memory：原地记忆修正。
• delete_memory：双时间软删除。

10 秒快速接入

claude mcp add nexusyn --transport http \
  "https://api.nexusyn.ai/v1/mcp" \
  --header "Authorization: Bearer <YOUR_API_KEY>"

或通过 Smithery CLI：

npx -y @smithery/cli install @nexusyn/nexusyn --client claude

在 Cursor 中（.cursor/mcp.json）：

{
  "mcpServers": {
    "nexusyn": {
      "url": "https://api.nexusyn.ai/v1/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

---

基准测试结果：LongMemEval-S 与 LoCoMo

为了验证该架构确实产生了实际效果，我们在公开的 LongMemEval-S 基准测试（350 个严格的多会话回忆和时间更新任务）以及 LoCoMo（1,986 个多轮推理问题）上对 Nexusyn 进行了评估：

---

结论与入门指南

赋予 AI Agent 长期记忆不是一种提示工程技巧——它需要专门的数据平面基础设施，能够理解时间、实体和混合检索。

你可以探索开源引擎、部署自托管版本，或使用托管云实例：

• 云 SaaS（免费套餐含 2,000 条记忆）：https://nexusyn.ai
• 开源核心（Apache 2.0）：https://github.com/nexusyn/engine
• Smithery 注册表：https://smithery.ai/servers/@nexusyn/nexusyn
• Glama 注册表：https://glama.ai/mcp/servers/nexusyn/engine