Marico's space
别再把 Agent 记忆系统搭在向量数据库上了。这是在给团队挖坑。
Vector RAG 在演示里看起来很优雅。传个查询，返回相似片段，塞进 context，搞定。但扩到多个 Agent 长期协作的时候？崩了。彻底崩了。
原因就一个：RAG 把检索和协调混为一谈了。它假设所有知识都是可叠加的，冲突不存在，Agent 不会互相覆盖。实际上？冲突存在，Agent 互相覆盖。
你真正需要的不是检索，是合并。不是「给我找点类似的」，而是「这是我对世界的看法，现在让我们把它和你的观点调和起来」。
答案来了：版本化 SQL。
不是普通的 SQL，是结构化数据的 Git。记录带哈希，变更形成 DAG，冲突通过明确的合并策略解决，历史被保留而非扁平化。
RAG 里的向量是无状态的快照。Embedding 编码的是某个时间点的语义，但它们没法告诉你语义是怎么演变的、从哪来的、谁最后改的。
多个 Agent 并发写入记忆。没有版本控制，你就丢失因果性，丢失意图，最后陷入 garbage-in-garbage-out 的死循环。
支持合并的系统追踪 lineage。每次变更都链接到父节点。Agent 能看到某条内容被写入的原因，而不只是它存在。这才让安全协作成为可能。
想象两个 Agent 同时更新一条客户记录。一个添加了新地址，另一个把账户标记为 inactive。在 RAG 的世界里，两次更新都消失在 embedding 空间里，谁赢了？天知道。
有了版本化 SQL，这些变更作为独立的 commit 存在，合并策略决定如何解决冲突。可能是系统自动解决，可能是标记给人类处理——无论哪种，你都掌控全局。
Long-context window 曾被寄予厚望来解决一切问题。往模型里塞更多 token 就完事了！结果呢，现在你在和「lost in the middle」搏斗——模型会忘记埋在 context 深处的内容。
向量搜索加剧了这个问题。相似性搜索返回语义相关的片段，但排序无法保证，检索到的事实也没有时间连贯性。
版本化记忆用不同的方式解决：不把原始文本塞进 prompt，而是存储紧凑的表示形式。任务图、语义摘要、结构化 diff。
beads 这类工具把知识压缩成最小可组合单元。每个 bead 都追踪依赖关系，内容再怎么变，关系依然完整。
这不再是索引文档的问题，而是建模不断演变的信念。
Dolt 为关系表带来了 Git 风格的版本控制。结合基于哈希的 ID 和依赖追踪，这就是真正协作式 Agent 记忆的基石。
每个 Agent 写入自己的分支。Commit 通过类 SHA 标识符引用先前的状态。合并冲突显式暴露，没有静默覆盖，没有幻觉真理。
语义压缩层叠其上：将大型 changeset 总结为原子事实，和完整历史一起存储，根据需要查询任一表示形式。
这才是团队构建共享理解的方式——而不是把 embedding 丢进 Pinecone，然后祈祷一切顺利。
别误解。Embedding 不会消失。它们在分类、聚类、异常检测方面表现出色。
但把向量作为 Agent 记忆的主要存储，就像用 Redis 存源代码——短期内能 work，然后并发反咬你一口，然后一致性崩盘。
向量缺乏身份标识，缺乏事务语义，缺乏审计追踪。这些不是 bug，是设计上的局限。
需要模糊性的时候用向量。需要精确性的时候用版本化 SQL。
从结构开始。定义反映领域逻辑的 schema。Task、entity、relationship——都需要类型。
加版本控制。追踪每一次变更。保留因果性。启用分支工作流。
实现合并策略。提前决定冲突写入如何解决。尽可能自动化，必要时告警给人类。
叠加压缩层。提取语义核心。剪除冗余路径。只保留推理必需的内容。
这样才能构建出可扩展的记忆系统——清晰，而非混乱。
你的 RAG 设置在并发多 Agent 写入下崩过吗？或者你已经在对 Agent 记忆进行版本控制了？在下面分享你的架构吧。
原文：Why Versioned SQL Beats Vector RAG for Agent Memory Systems