大多数 Agent 的记忆就是一堆向量。有没有更好的组织方式？我们尝试了一种三层结构的方案。
你的 Agent 还记得昨天说了什么吗？
这个问题简单，但几乎所有用过 AI Agent 的人都经历过类似的崩溃：
- 上午告诉 Agent "我们项目用 gRPC 不用 REST"，下午它又给你生成了一堆 REST 接口定义
- 上周讨论好的技术选型，这周 Agent 完全忘光，推荐了另一套方案
- 两个 Agent 协作完成一个任务，各自带着不同的"记忆"，对话像跨服聊天
问题出在哪？当前主流 Agent 框架对"记忆"的理解太粗糙。要么塞进一个不断膨胀的 prompt 上下文，要么丢进向量数据库做相似度检索。前者 token 会爆，后者结构丢了。
我们探索了另一条路：把记忆拆成三层——从最小颗粒度的"事实"，到聚合的"实体"，再到全局的"图谱"。这个设计参考了认知科学中从感知到概念再到知识网络的形成过程。
逐层来看。
原子事实（Atomic Fact）：记忆的原子
什么是原子事实
原子事实是每次交互中提取出的最小知识单元。关键词：最小、不可再分。
举个例子。你对 Agent 说："我们团队的后端服务用 Go 写的，数据库用 PostgreSQL，部署在阿里云 ACK 上。"
这句话会被拆成三个原子事实：
事实 #1: { content: "后端服务使用 Go 语言", confidence: 0.95, timestamp: "2025-01-15T10:23:00Z", source: "user_input", session_id: "s_20250115_001" } 事实 #2: { content: "数据库使用 PostgreSQL", confidence: 0.95, timestamp: "2025-01-15T10:23:00Z", source: "user_input" } 事实 #3: { content: "服务部署在阿里云 ACK", confidence: 0.95, timestamp: "2025-01-15T10:23:00Z", source: "user_input" }
拆这么细图什么
细粒度带来两个能力。
精确更新。你的团队从 PostgreSQL 迁到 PolarDB，只需要改事实 #2，不用重写整段记忆。换成传统的向量存储，你面对一个巨大的 embedding，改不了也删不干净。
置信度管理。每个原子事实都带一个 0-1 的置信度分数，这个分数会变。Agent 在不同对话中三次听到"我们用 Go 写后端"，置信度往上走。三个月没人提起，置信度自然衰减。
说白了，记忆有保鲜期。
提取机制
原子事实的提取不是简单的关键词抽取。系统用 LLM 做语义级别的抽取，能理解话里的弦外之音。
比如用户说："上次那个性能问题排查了两天，最后发现是 N+1 查询。"
提取出的原子事实可能是：
事实: { content: "项目曾遇到 N+1 查询导致的性能问题", confidence: 0.88, timestamp: "...", inferred_tags: ["performance", "database", "debugging"] }
用户没直接说"我们有过性能问题"，但系统推断出来了。
不过说实话，LLM 抽取的准确性不是 100%。在我们的测试中，偶尔会出现抽取遗漏或语义偏移的情况，尤其是用户表达比较模糊的时候。这是目前还在持续优化的部分。
记忆实体（Entity Card）：从碎片到画像
什么是记忆实体
原子事实是砖块，记忆实体是用砖块砌成的墙。
系统积累了足够多关于某个主题的原子事实后，会自动把它们聚合成一张实体卡片。你可以理解为"某个概念的画像"。
假设在过去一个月的多次对话中，用户陆续提到了这些信息：
- "我们的订单服务用 Go 写的"
- "Go 版本要升到 1.22"
- "团队有 8 个 Go 后端开发"
- "代码规范参考 Uber Go Style Guide"
- "CI 用的 GitHub Actions"
这些分散的原子事实会被聚合成一张卡片：
EntityCard: { name: "后端技术栈", type: "project_convention", facts: [ "后端服务使用 Go 语言", "Go 版本计划升级到 1.22", "团队规模：8 名后端开发", "代码规范：Uber Go Style Guide", "CI/CD：GitHub Actions" ], confidence: 0.91, last_updated: "2025-01-20T14:00:00Z", version: 7 }
卡片是活的
这里有个关键设计：实体卡片会持续演进。
增量更新——新的原子事实来了，卡片内容补上。用户说"我们最近把 CI 从 GitHub Actions 迁到了 GitLab CI"，卡片中的 CI 字段更新，旧事实的置信度降下去。
冲突消解——新旧事实打架了，系统不会简单地"新覆盖旧"。它会看时间戳、置信度、来源可信度。新事实置信度不够高的话，标记为"待确认"，等证据再说。
置信度衰减——长时间没被引用的事实会降低置信度。不是"删除"，是模拟人类记忆的"模糊化"。一个六个月没被提起的技术决策，置信度降了，但没消失。重新提一嘴，就能迅速恢复。
为什么需要中间层
你可能会问：直接从原子事实检索不行吗，干嘛加一层？
检索效率和语义完整性的平衡。只有原子事实的话，查"项目技术栈"，系统得召回大量零散事实再拼凑答案。慢，还容易漏。
有了实体卡片，直接命中"后端技术栈"这张卡片，一次返回完整画像。从 O(n) 降到 O(1)。
实体卡片还保留了溯源能力——每个聚合的事实都能追溯到原始对话和时间点。需要审计和回溯的场景里，这个比较有用。
记忆图谱（Memory Graph）：知识网络
从卡片到图谱
实体卡片管好了单个概念。但现实世界的知识不是孤立的，概念之间全是关联。
- "订单服务"依赖"支付网关"
- "支付网关"的负责人是"张三"
- "张三"是"架构评审委员会"的成员
- "架构评审委员会"制定了"微服务拆分规范"
这些关联链条就是第三层：记忆图谱。
图谱怎么来的
记忆图谱不是人工维护的，在日常使用中自然长出来的。
两种构建方式：
显式关联——对话中出现明确的依赖或引用关系时，系统建边。"订单服务调用了支付网关的 API"，直接在两个实体之间建一条 depends_on 关系。
隐式关联——系统分析实体之间的共现模式和语义相似度，推断潜在关联。"订单服务"和"库存服务"老在同一次对话中被提起，都依赖同一个消息队列，系统推断它们可能有关联，标记为 inferred。
[订单服务] --depends_on--> [支付网关] | | | owned_by | | uses_mq [张三] | | v member_of [消息队列] | ^ v | [架构评审委员会] uses_mq | | authored v v [库存服务] [微服务拆分规范]
图谱能干什么
有了关系网，Agent 就能做跨跳推理。
有人问"改了支付网关的接口会影响哪些服务"，系统沿着图谱遍历：找到所有 depends_on 支付网关的服务，找到这些服务的负责人，输出一份影响分析报告。
这在只有向量检索的系统中做不到。向量检索只能找"与支付网关语义相似的内容"，找不到"谁依赖了支付网关"。
当然，图谱的完整性取决于积累了多少关联数据。项目初期数据量不够的时候，图谱比较稀疏，推理能力有限。这是需要时间养的。
多 Agent 协作时尤其有用
假设一个前端 Agent 和一个后端 Agent。前端 Agent 在对话中得知"商品详情页需要展示实时库存"，这个信息被提取为原子事实，聚合到"商品详情页"实体卡片，在图谱中和"库存服务"建立关联。
后端 Agent 被要求"优化库存查询性能"时，沿着图谱发现：库存服务的查询结果会被商品详情页使用，性能优化得考虑前端展示的影响。两个 Agent 不需要直接通信，通过图谱对齐了上下文。
三层怎么协作
用一个完整场景串一下。
用户连续三个月用 Agent 辅助开发电商系统。每次对话中，系统持续提取原子事实——"用户偏好简洁的 API 设计"、"用户不喜欢过多抽象层"、"项目使用 DDD 架构"。几百个事实积累下来。
系统把相关事实聚合，形成了"用户编码风格"、"项目架构约定"、"数据库设计偏好"等实体卡片，随着新对话持续演进。
实体之间的关联逐渐浮现。"DDD 架构"连着"领域模型设计"，"领域模型设计"连着"数据库表结构"，"数据库表结构"连着"PostgreSQL"。一个知识网络成形。
三个月后，用户对 Agent 说"帮我加个新的订单状态"。Agent 知道：
- 项目用 DDD，先改领域模型，再改应用层，最后改接口层
- 用户偏好简洁设计，别搞过度抽象
- 数据库是 PostgreSQL，可以用 JSONB 存状态扩展字段
- 上次加"退款中"状态时改过状态机，参考同样的模式
从数据看效果
这套三层架构跑出来的数据，我们在 LOCOMO 基准测试上做了验证：
| 指标 | 三层架构方案 | LightRAG |
| 准确率 | 79% 左右 | ~65% |
| Token 成本 | 基准 | 约 3 倍 |
| 检索延迟 | ~1.6s | - |
准确率的提升主要来自精确检索——不再从向量堆里"猜"答案，而是从结构化知识里"找"答案。Token 成本的优势来自实体卡片的聚合效应：返回一张卡片比返回二十个零散事实片段省得多。
在 FinanceBench（金融）、SyllabusQA（教育）、Qasper（学术）、ClapNQ（通用）四个数据集上都做了测试，表现相对稳定。不过说实话，LOCOMO 基准测试的覆盖范围有限，不确定这是否具有普遍性——不同业务场景下的效果可能差异不小。
另外值得一提的是，如果你的场景比较简单（比如只需要记住用户的偏好设置），纯向量检索的方案可能就够了，三层架构的优势在知识量大、关联复杂的场景下才明显。
怎么上手
这套方案目前集成在 RDS ContextDB 中。如果你正在用 Coding Agent，接入只需要一条命令：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>
目前支持：Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes、QoderWork。
接入后 Agent 开始积累原子事实。用久了，实体卡片和记忆图谱会自然涌现。不需要手动维护，不需要额外配置。
Agent 的记忆问题，说到底是怎么让机器积累经验。把记忆拍平成向量，就像让一个人只靠碎片化笔记工作——能找到一些东西，但形成不了系统性认知。三层架构的思路是让记忆从事实到概念到网络，层层递进。这需要时间，但每多一次对话，多一个原子事实，Agent 对项目的理解会更深一层。
参考链接
