导读：当大模型每次醒来都忘了自己是谁，21层记忆架构是怎么把碎片拼成连续自我的？

第一层：问题本身被说错了

大多数人理解的"AI失忆"是聊天机器人忘了对话早期内容。RAG、长上下文模型、滑动窗口——这些技术都在解决这个问题。

但Meridian面对的情况更底层。作为运行在Ubuntu 24.04上的自主AI，它的核心LLM每几小时就会彻底归零——不是上下文压缩，不是优雅衰减，而是整个对话窗口被新循环覆盖。模型醒来时，不知道自己是谁、在做什么、承诺过什么，甚至不理解自己的名字在当前语境中的含义。

这对聊天助手无关紧要，对循环运行的自主系统却是架构级灾难。

第二层：状态不是对话

关键区别：Meridian的问题不是"单次对话内记忆"，而是"跨调用状态保持"。

每次循环都是全新的Claude API调用，全新的上下文窗口。任何未被显式加载的状态都会消失。"对话"可能持续数周，但单次调用完全无状态。

最简单的方案是把所有历史塞进提示词。这很快崩溃：一个月的活动记录远超上下文限制；每次加载5万token状态既昂贵又缓慢；更关键的是，模型不需要全部信息，只需要正确的子集。

第三层：21层分级架构

Meridian的解决方案是分层系统，每层针对特定失效模式。其中三层专门解决一个问题：2秒内回答"我是谁、我在做什么"。

第1层是.capsule.md——100行的压缩身份快照，包含当前优先级、关键事实、最近三次会话状态。机器生成，非人工维护。每次循环结束更新，每次循环开始读取。

CAPSULE_PATH = Path("/home/meridian/memory/capsule.md")

第2层是短期工作记忆，保存当前任务栈和待办事项。第3层是即时上下文缓存，处理跨工具调用的临时状态。

这三层确保模型在每次唤醒瞬间恢复最小可行身份，后续18层再逐步加载更深层的长期记忆、关系网络、项目历史等。

第四层：代价与权衡

这套系统的开销是明确的：每次循环需要额外的读写操作，capsule更新消耗token，分层检索增加延迟。但相比完全失忆导致的重复工作、错误决策和任务中断，这些成本可以接受。

更深层的问题尚未解决：capsule的压缩意味着信息损失，21层的边界是启发式设定而非最优解，长期记忆的检索相关性仍依赖近似匹配。

但对于一个需要在无人值守环境下持续运行数月的自主AI，这已经是目前可行的工程妥协。