推出记忆体（Memoria）：全球首个面向人工智能代理记忆的 Git 系统

无人解决的记忆难题

打开 Cursor。告诉它你的项目使用 React、TypeScript 和采用切片模式的 Zustand。看着它精准构建你想要的内容。

关闭标签页。开启一段新对话。让它添加一个用户模块。

“当然！你用的是什么框架？状态管理用的是 Redux 还是 MobX？”

你二十分钟前刚告诉过它。它已经忘了。
现在打开 OpenClaw。你已经用了好几个月——它记得你的偏好、项目上下文和工作流模式。但打开 MEMORY.md 文件，看看里面累积了什么：数百条记录，每次会话都在增长。每一条都会在每次 API 调用时注入系统提示中，无论是否相关，都在消耗令牌。你的月度账单不断攀升。当你尝试换一台新机器，或与队友共享你的配置时，这些记忆却散落在本地 Markdown 文件中，既无法导出，也无法同步，更没有结构。

这些并非边缘情况。这就是 2026 年数百万开发者使用人工智能代理时的日常现实。模型非常聪明，但记忆成了瓶颈。

纵览当前代理记忆的现状

要理解我们为何打造 Memoria，有必要先看清行业实际所处的位置——涵盖编码代理、OpenClaw 以及自定义构建的代理。

完全没有记忆

大多数编码代理——如 Cursor、Claude Code、Kiro——均未配备任何持久化记忆功能。每次会话都从一张白纸开始。代理不知道你的技术栈、代码风格、命名规范，也不知道你上周做出的架构决策。它只能基于当前对话窗口中的内容进行工作。

这种代价虽不可见却持续存在：反复设置上下文、重复提问、跨会话输出不一致。代理在当下很聪明，却缺乏连续性。它每天早上都像一个新入职的员工。

基于 Markdown 的记忆

行业最初的应对方案是静态文件。.cursorrules 文件用于告知 Cursor 你的偏好。CLAUDE.md 对 Claude 起同样作用。Kiro 使用引导文件。OpenClaw 则构建了一个社区驱动的规则库，让开发者可以共享和复用配置。

OpenClaw 更进一步，引入了 MEMORY.md——代理可将记忆写入磁盘，并在下次会话时重新读取。这确实实现了持久化。但其实现存在结构性问题：

• 令牌膨胀。 所有累积的记忆都会在每次调用时加载到系统提示中。到第 10 次会话时，代理甚至还没读取你的消息，就已消耗超过 10,000 个上下文令牌。而其中大多数记忆与当前任务无关。
• 缺乏语义检索。 记忆仅按日期和类别匹配，而非按含义匹配。当你要求代理“格式化此文件”时，它无法找到“格式化偏好”——除非恰好包含完全匹配的关键词。
• 缺乏可移植性。 记忆存储在本地 .md 文件中。更换新机器、与队友共享或跨设备同步，都需要手动复制粘贴。
• 缺乏结构。 代码风格、架构决策、部署流程、个人偏好——所有内容都混杂在扁平文件中，最终演变成一团难以维护的乱麻。
• 无法回滚。 如果某条错误的记忆条目破坏了代理的行为，你必须手动查找并删除它。系统没有撤销功能。

结构化记忆框架

Mem0、Letta 和 Zep 代表了下一代方案。它们将记忆存储在真正的数据库中，并使用向量嵌入技术，从而实现语义检索。这是实质性的进步——代理现在能根据含义（而不仅仅是关键词）找到相关的记忆。