Agent 记忆不是向量数据库里的一堆文本：MNEMOVELA 的认知运行时模型
很多 Agent 系统把“长期记忆”实现为一个简单流程：保存聊天记录，切分文本，生成 Embedding，然后在下一次对话中检索相似片段。
这种方法可以增强信息召回，却没有真正建立记忆语义。
向量数据库能够回答“哪些内容在语义上相似”，但无法独立回答：
- 这是一段原始经历，还是经过归纳的事实？
- 该事实现在是否仍然有效？
- 两个互相冲突的记录应该如何处理？
- 这段内容来自真实观察，还是一次假设模拟？
- 它属于哪个 Agent、租户、项目或推理分支？
- 检索结果应如何组合成当前上下文？
MNEMOVELA 将自己定义为 Cognition Runtime。它位于大模型旁边，负责长期记忆、上下文组装和知识表达。
其数据模型包含多种记忆类型：
- Episode：用户说了什么、系统返回了什么等原始事件；
- Fact：带有有效期的主谓宾事实；
- Knowledge：实体关系、分类等结构化认知；
- Experience：行动之后形成的经验和反思；
- Simulation：用于推理可能结果的假设场景；
- Belief、Intention、Procedure、Mission、Preference：Agent 的内部状态和行为倾向。
区分这些类型非常重要。
原始 Episode 不应因为被检索到就自动成为事实；Simulation 中发生的事情也不能被当作现实记忆；Experience 是对行动的反思，而不是行动本身。不同类型具有不同的可信度、时效性和使用规则。
MNEMOVELA 还引入类似 Git 的分支模型。Agent 可以从某一记忆状态创建分支，在分支中进行模拟、尝试或修订，而不立即污染主线认知。
每条记录保持不可变并采用追加写入，同时携带分支、时间、保留级别以及租户和项目作用域。修正事实时，不是直接覆盖历史记录，而是追加新的版本或关系，从而保留认知变化过程。
检索层采用混合方式，将以下维度组合起来：
- 词法匹配；
- 向量语义；
- 实体和关系；
- 时间与有效窗口；
- 分支和身份作用域。
检索之后还需要 Context Assembly。它根据当前任务、Token 预算、记忆类型和相关性，把候选记录组织为模型可以使用的上下文，而不是简单返回相似度最高的若干文本块。
公开仓库提供 Python、TypeScript 和 Go 客户端，以及 JSON-RPC、MCP、REST 和 gRPC 契约。当前公开材料还展示了 Web Console 和 Coding Agent Continuity 场景对该接口的持续使用。
MNEMOVELA 所表达的核心观点是：
记忆不是存储位置，而是一组关于类型、时间、来源、身份、分支和使用方式的语义约束。
向量数据库可以成为记忆系统的一种存储或检索机制，但它本身并不等于 Agent Memory。真正的长期记忆基础设施必须管理记录如何产生、何时有效、如何修订，以及在什么上下文中可以被重新使用。
项目地址：https://github.com/axisrobo/mnemovela-open
