大多数团队给AI智能体配记忆，第一反应是上向量库：把所有内容向量化，靠相似度检索，指望相关上下文能自己跳出来。这套办法一开始能用，直到你发现智能体反复翻出那些“离问题很近、但实际没有关联”的东西。 慕尼黑一家技能智能公司Cobrainer没走这条路。他们让AI智能体的记忆直接以图的形式存在数据库里，节点之间的关系由智能体在工作过程中自己搭建。更关键的是，他们没往技术栈里加图数据库、向量引擎或搜索引擎，全部跑在SurrealDB上，旁边还有一个基于Rust的原生智能体图RAG，共用同一套存储。 Cobrainer做的是技能智能平台，专门推理人、岗位、技能、能力之间的关系。这天然就是一个图结构问题。但他们最初那套检索方案跟图一点关系都没有。 早期系统走的是扁平向量检索管线，带来两个反复出现的成本。第一是准确率：扁平向量匹配返回的上下文只是语义上接近，未必存在有意义的连接。团队希望智能体沿着实体之间的真实关系走，让答案有据可依，而不是靠近似。第二是令牌消耗：宽泛的向量匹配意味着每次提示词都要塞进大量边缘相关上下文，调用越多越贵。团队只想取回真正要紧的那部分。 最直接的修法是在现有向量和搜索系统上再叠一个图数据库，但那意味着要运维更多基础设施。对一家快速移动的初创公司来说，这种碎片化恰恰是要避开的东西。 Cobrainer列出的需求，重点不在某个单一功能，而在不为组合功能额外买单：智能体和图RAG共用一套存储，AI智能体的记忆以图的形式存在数据库里，外加一个智能体图RAG，两者都由同一个引擎支撑图、向量和全文检索；不靠手工预先建模每一条关系，智能体在工作时自动构建节点之间的关联并加以利用；检索沿着真实关系遍历，答案锚定在事物实际连接的方式上；拉取相关子图，而不是做一次宽泛的相似度扫描；快速搭建新的存储模式，不被漫长迁移拖慢团队。 SurrealDB把图、向量和全文检索放进同一个引擎，全部通过SurrealQL查询。这样一来，智能体用例旁边不再需要额外的向量或搜索组件陪着数据库一起跑。他们现有的Postgres原封不动留在原地。 这套架构的落点很清晰：记忆不是一堆被相似度排序的碎片，而是一张会随着使用不断织密的网。智能体每次建立一条关系，下一次检索就多一条可走的真实路径。对Cobrainer来说，这省下的不只是基础设施，更是每一轮提示词里那些“看起来相关、其实无关”的令牌开销。
热门跟贴