9个节点、20个智能体同时开工，昨天定的方案今天就忘——这不是人的问题，是架构的硬伤。Joe团队用PostgreSQL+pgvector给OpenClaw搭了一套"外接海马体"，22,000条消息、736个会话、27个智能体的记忆终于不再碎片化。
他们的Markdown记忆系统原本有四层：会话上下文、CONTEXT.md工作记忆、每日原始日志、定期整合的长期记忆。但跨智能体共享知识靠手动复制，文件越多搜索越烂。
新方案是加一层"Layer 0"记忆服务，不是替换而是共存。查询时并行跑Markdown的memory_search和Memory Service的/search，结果合并——这叫"双查询模式"。
Postgres里塞了什么
messages表存了22,000+记录，sessions表736条，agents表27条。facts表用主谓宾结构存知识，public_knowledge表当共享知识库。
Python写的Memory Service开8092端口，暴露三个接口：/search做语义检索，/facts管结构化知识，/ingest吞会话数据。systemd跑的同步守护进程每5分钟把OpenClaw的JSONL日志刷进Postgres。
Joe提到一个细节：JSONL不是每行一条消息，是事件驱动格式。他们第一版按行解析，结果灌进去一堆垃圾数据。得给每种事件类型写分支逻辑。
更坑的是并发。27个智能体同时连库，连接池配小了直接崩。他们调了池大小和超时，又给(session_key, message_index)加复合唯一约束，用ON CONFLICT DO NOTHING保证幂等——重跑同步不会重复灌数据。
向量检索的隐性成本
pgvector确实香，但同步生成22,000条消息的嵌入不是开玩笑的。Joe没提具体用了多久，只说是"implementation pitfall"之一。
他们的facts表设计很有意思：主谓宾结构。不是存"用户喜欢深色模式"，而是拆成(用户, 偏好, 深色模式)。这种结构化知识可以跨会话推理，比纯向量相似度更精准。
public_knowledge表是另一个关键点——27个智能体的共享记忆池。以前靠手动复制MEMORY.md，现在写进这张表就全员可见。
双查询模式的具体合并策略Joe没细说，但提到"leverage both"。我猜测是向量检索召回候选，再用结构化facts做精排——类似RAG里的重排序环节。
为什么选Postgres而不是专用向量库
团队显然算过账。他们已经在跑OpenClaw集群，再加一套Pinecone或Milvus意味着新的运维负担。pgvector的HNSW索引在Postgres 15里足够用，而且事务、备份、权限管理都是现成的。
一个产品经理视角的观察：这套架构的"可逆性"很好。如果pgvector哪天不够用了，facts表和public_knowledge表的数据模型可以直接迁移，业务逻辑不用重写。
Joe的原文有个值得玩味的表述——"co-existence rather than replacement"。不是推倒重来，是嫁接。这种渐进式改造在大厂很常见，但写出来的人不多。
他们的同步间隔是5分钟。这意味着最坏情况下，一个会话的记忆有5分钟延迟才能被其他智能体检索到。对于实时协作场景，这个延迟够吗？Joe没给答案，但留下了这个数字。
22,000条消息、736个会话、27个智能体——这三个数字是2026年3月29日的快照。按5分钟同步一次的频率，现在应该膨胀到什么规模了？
热门跟贴