记忆 API 给 Agent 返回的那两条数据，分数都 0.
这事儿得从一个很具体的场景说起。Agent 问记忆系统：「生产库用的啥？」接口返回两条记录，PostgreSQL 得分 0.94，MongoDB 得分 0.91。Agent 很听话，选了分高的 PostgreSQL。结果部署炸了——因为四个月前架构组早把库换成 MongoDB 了。
检索没毛病，语义相关度也算对了。问题出在 接口把记录间的时序关系直接扔了。
存储层其实知道真相：PostgreSQL 管到 2026 年 4 月，之后被 MongoDB 取代。这叫双时态建模，SQL:2011 早就标准化了，应用时间 + 系统版本表。Edward Izgorodin 在上一篇帖子里提过，数据库圈玩「这事儿当时真、现在假」十多年了。你要是存储层还在覆盖式更新，先去补补课，文献一抓一大把。
真正的坑在 检索接口这一层。
大多数记忆 API 继承的是传统 RAG 那套：查询进，排序列表出。带个 timestamp、source、confidence 叫元数据。但 Agent 需要的不是「最相关的几条」，而是 「当前生效的是哪条、哪条被废弃了、俩冲突咋回事」。列表结构根本放不下记录间的边——Edward 原话：「A ranked list has nowhere to put an edge.」
举个更接地气的例子：
- 记录 A：客户退款需经理审批
- 记录 B：100 美元以下退款免审
这俩在存储层看起来像「更新」，但在业务层完全是两码事：B 可能是纠错、可能是政策变更、也可能是不同地区不同规则。把它们拍平成同权重的列表丢给 Agent，Agent 根本没法推理。
现在的接口设计隐含了一个危险假设：「语义相似度 ≈ 当前真实度」。这在文档检索里能凑合，在 Agent 做决策时就是送命题。
我在折腾自建 Agent 记忆层时踩过这坑。后来把检索接口改成了返回 「事实图谱片段」 而不是列表：
{
"current_fact": "MongoDB",
"valid_from": "2026-04-15",
"supersedes": {
"fact": "PostgreSQL",
"valid_until": "2026-04-14",
"reason": "architecture_decision_2026_q2"
},
"confidence": 0.97
}Agent 拿到这个结构，推理链路清晰多了：当前生效什么、为啥生效、前一个为啥作废。哪怕中间还夹着个「中间方案用过 TiDB」，图谱里也能串上。
当然，构建这种图谱要付出成本：写入时要显式声明关系、要维护有效期窗口、要处理冲突合并。但比起 Agent 在生产环境里拿着过期配置跑偏，这点工程投入算便宜的。
如果你也在搭 Agent 记忆系统，建议先自查三件事：
1. 存储层是不是还在硬覆盖？ 加上 valid_from / valid_to，别删历史
2. 检索接口还在吐扁平列表？ 试着返回带边的子图，哪怕只加个 supersedes 字段
3. 有没有「当前生效视图」的物化缓存？ Agent 高频决策别每次都跑一遍图遍历
记忆系统的核心指标不是 Recall@K，而是 「Agent 基于返回结果做决策的正确率」。列表结构在前者上能跑满分，在后者上可能是负分。
想听听大家在记忆层怎么处理「废弃事实」和「版本冲突」的，评论区直接甩方案。
