Agent 的记忆战争：GBrain vs EverOS，两条路线的终局

昨天我写了一篇《用 LLM 构建程序化知识系统》，提出「记忆 · 知识 · 技能」三层架构。文章发出后不到 48 小时，两个重量级项目几乎同时进入我的视野——YC 总裁 Garry Tan 开源了 GBrain，EverMind 团队发布了 EverOS。

更巧的是，这两个项目恰好代表了 AI Agent 长期记忆的两条截然不同的技术路线：一条是"用自然语言指令驱动 LLM 自行理解"，另一条是"用工程架构确定性落地"。它们互为镜像，又互相矛盾。

我把它们放在一起比较，同时加入了我自己的实践，最终得出了一个你可能没想到的结论：这场战争没有输赢，只有分层。

一、无状态困境：Agent 进化的最大瓶颈

如果你今天问任何一个 AI Agent：“昨天你帮我做了什么？“不用说，它大概率会"一脸茫然”，然后开始胡言乱语。

这是因为绝大多数基于 LLM 的智能体都受困于无状态困境（Stateless Dilemma）：会话一旦结束，记忆即刻清零。下一次对话，永远是从零开始的冷启动。你反复解释过的项目背景、合作伙伴的性格偏好、你曾经表达过的观点，对 Agent 而言都是一片虚无。

这正是阻挡 Agent 从"好用的工具"进化为"真正的助手"的核心障碍。

而 GBrain 和 EverOS 都在试图解决这个问题，只是路径完全不同。

二、GBrain：Prompt 驱动的"个人第二大脑”

YC 总裁 Garry Tan 开源 GBrain 时，在 X 上写了一句话：“我希望所有人都能拥有自己的’个人迷你 AGI’。”

他的方案非常极简：让 Agent 经历 读取 → 对话 → 写入 的闭环。每当有新信号进入系统——邮件、会议录音、推文、日历变动——Agent 先查询已有知识库，理解上下文后回应，然后将新知识写回，供下一次使用。

新信号（邮件/录音/推文/日历）
    │
    ▼
┌──────────────────────┐
│  1. 读取：查询知识库  │
│  2. 对话：理解+回应    │
│  3. 写入：更新知识库   │
└──────────────────────┘
    │
    ▼
每走一圈，Agent 更懂你

两个迷人机制

GBrain 最吸引人的地方在于它的**「梦境循环」**（Dream Cycle）：Agent 在用户睡觉时后台运行，扫描当天对话，充实实体信息、修复引用、合并冗余记忆。Tan 的原话是：“我早上醒来，大脑已经比我睡着前更聪明了。”

另一个亮点是**「编译真相」**（Compiled Truth）架构：每个实体页面顶部是 Agent 综合判断的"最新摘要"（可随新证据重写），底部是"不可修改的时间线"（原始证据链）。兼顾动态更新与事实溯源。

争议：这到底是软件还是提示词？

然而 GBrain 上线六天后，DEV Community 上的一篇代码审查文章就给出了不太乐观的结论：GBrain README 中宣传的三个重要功能——编译真相重写、梦境循环维护、实体检测——在代码库中均无对应的确定性逻辑实现。

文章认为，这些功能本质上是写在 Markdown 文档中的 Agent 指令，依赖 LLM 去解读和执行，而非通过代码实现。此外，项目 Issue 中记录了 12 个关键 Bug（竞态条件、NULL 嵌入覆盖等），安全审计甚至标注其 S3 后端"未达到生产就绪"状态。

这触及了一个更深层的争论：当一个系统的核心功能是通过自然语言指令让 LLM 代为执行，而非通过确定性代码实现时，它究竟算不算一个"软件产品"？还是更接近于一套精心编排的提示词工程？

三、EverOS：工程落地的"记忆操作系统"

如果说 GBrain 是"用想法驱动 Agent"，那么 EverOS 就是"用架构保证结果"。

EverMind 团队发布的 EverOS 是一个完整的 AI Agent 长期记忆操作系统，包含两套核心方法和两个基准测试，已有 3 篇 arXiv 论文，其中 HyperMem 已被 ACL 2026 接收。

整体架构

┌────────────────────────────────────────────────────────────┐
│                        EverOS                               │
│                                                             │
│  ┌───────────────┐      ┌───────────────────────────────┐  │
│  │   Methods      │      │         Benchmarks             │  │
│  │               │      │                                │  │
│  │ EverCore      │      │ EverMemBench  · 三层质量评估   │  │
│  │ (记忆OS)       │      │ EvoAgentBench · 自我进化评估   │  │
│  │               │      │                                │  │
│  │ HyperMem      │      │                                │  │
│  │ (超图记忆)     │      │                                │  │
│  └───────────────┘      └───────────────────────────────┘  │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐ │
│  │           12+ Use Cases                                │ │
│  │ OpenClaw · Claude Code · Golutra · Mobi · LAI ...     │ │
│  └───────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘

EverCore：自组织记忆操作系统

EverCore 的核心单元是 MemCell——原子级记忆单元，从对话中自动提取。它将记忆分为七种类型：

EverCore 采用六层分层架构：

Agentic Layer        ← 统一记忆接口（提取/检索/重排编排）
    │
Memory Layer         ← MemCell 提取 + 记忆类型分类 + Prompt 管理
    │
Retrieval Layer      ← BM25 + 向量搜索 + RRF 融合 + Agent 多轮召回
    │
Business Layer       ← API 端点 + 请求处理 + 业务规则
    │
Infrastructure Layer ← MongoDB + Elasticsearch + Milvus + Redis
    │
Core Framework       ← 依赖注入 + 生命周期 + 中间件 + 配置管理

在 LoCoMo 基准上，EverCore 达到了 93% 的准确率。

HyperMem：超图记忆架构（ACL 2026）

HyperMem 是 EverOS 更学术化的一面。它的核心创新是用超图（Hypergraph）捕获高阶关联——传统 RAG 只能表示 pairwise 关系，而超图可以表示多对多的高阶依赖。

L3 Topic ───── Topic ───── Topic        (超边连接相关主题)
    │           │          │
L2 Episode──Episode  Episode             (超边连接同主题事件)
    │          │
L1 Fact-Fact-Fact  Fact-Fact             (超边连接同事件事实)

检索采用自顶向下、从粗到细的三阶段策略：先找到相关 Topic，再在 Topic 内找到 Episode，最后在 Episode 内找到 Fact。这种设计避免了传统 RAG “大海捞针"的低效。

在 LoCoMo 基准上，HyperMem 达到 92.73%，超越最强 RAG 基线 HyperGraphRAG（86.49%）6.24 个百分点。精选对比数据如下：

四、Agent 记忆成熟度模型

在比较完 GBrain 和 EverOS 之后，我提出了一个五层记忆成熟度模型，用来评估任何 Agent 记忆系统的成熟度：

                    ┌────────┐
                   │  L5    │  自我进化
                  ┌┴────────┴┐
                 │   L4      │  结构化记忆
                ┌┴───────────┴┐
               │     L3       │  混合检索
              ┌┴──────────────┴┐
             │       L2        │  持久化存储
            ┌┴─────────────────┴┐
           │         L1         │  上下文窗口
           └────────────────────┘

每一层的含义：

用这个模型打分，结果很有意思：

GBrain 的 L3 和 L5 打了 ⚠️，因为它的检索依赖 PGLite + pgvector（够用但不够强），而 Dream Cycle 是 Prompt 指令而非代码实现。EverOS 则五层全满——但这不代表它一定比 GBrain 好，因为复杂度也高了一个数量级。

五、第三条路线：你的「记忆 · 知识 · 技能」架构

回到我上一篇文章提出的架构。与 GBrain 和 EverOS 相比，我的方案走了一条中间路线：

┌──────────────────────────────────────────────────┐
│              你的博客 Agent                        │
│                                                    │
│  ┌──────────┐   ┌────────────┐   ┌──────────┐   │
│  │ 记忆引擎  │   │  知识图谱   │   │ 技能注册表│   │
│  │          │   │            │   │          │   │
│  │ 三层结构  │   │ 自动演化    │   │ 版本管理  │   │
│  │ 压缩遗忘  │   │ 冲突解决    │   │ 动态加载  │   │
│  │ TTL/权重  │   │ 图查询增强  │   │ 回归测试  │   │
│  └──────────┘   └────────────┘   └──────────┘   │
│                                                    │
│       ↕            ↕               ↕              │
│  ┌──────────────────────────────────────────┐    │
│  │           LLM Orchestrator                │    │
│  │    理解意图 → 规划路径 → 调用模块 → 评估   │    │
│  └──────────────────────────────────────────┘    │
└──────────────────────────────────────────────────┘

与 EverOS 相比，我的架构更轻量——不需要 MongoDB/Elasticsearch/Milvus/Redis 四件套，用 SQLite + 向量数据库就够了。与 GBrain 相比，它更结构化——不是纯靠 Prompt 驱动，而是有明确的模块边界和版本管理。

它的核心优势在于部署成本极低：不需要 Docker Compose 启动五个服务，不需要配置向量数据库，不需要 GPU 跑本地 embedding 模型。一个 Python 脚本 + 一个向量库就能跑起来。

六、终局判断：不是"谁更好”，而是"谁适合谁"

这场"记忆战争"的答案不在技术本身，而在场景。

如果你是一个重度 AI 用户（比如 Tan），每天处理大量人际交互和信息流，GBrain 的"Dream Cycle + Compiled Truth"组合拳足够好用。它不完美，但足够简单——用 Markdown 写指令，让 LLM 去执行。随着模型能力的提升，Prompt 驱动的系统会越来越可靠。

如果你是一个团队或企业，需要为多个 Agent 提供可复用的记忆基础设施，EverOS 是最佳选择。它的六层架构、多存储引擎、两套 benchmark 提供了工业级保障。代价是部署复杂度和运维成本。

如果你是一个独立的开发者或研究者，不想被 infra 绑架，也不想完全依赖 LLM 的"自由发挥"，那么「记忆 · 知识 · 技能」的轻量架构可能是最务实的选择。它吸收了 EverOS 的结构化思想，同时保留了 GBrain 的简洁性。

七、一个更重要的信号

比"谁更好"更重要的一个信号是：记忆正在成为 Agent 的基础设施，就像数据库之于 Web 应用。

回顾 2026 年 Q1 的记忆领域：

• GBrain（Garry Tan）：13 年记忆、14,700 页面、Dream Cycle
• EverOS（EverMind）：3 篇论文、ACL 2026、12+ Use Cases
• Karpathy 的 graphify：把任意文件夹变成知识图谱，25k+ stars
• Karpathy 的 autoresearch：Agent 一晚自主迭代 100 次实验
• Mem0 / MemOS / LangMem：各有特色的记忆中间件

这些项目有一个共同特征：它们都在试图让 Agent “记住”，而不是每次都从零开始。

当记忆成为基础设施，下一个问题是：谁来决定记住什么、遗忘什么、如何进化？ 这不再是一个技术问题，而是一个关于 Agent 自主性和人类控制的哲学问题。

GBrain 选择让 Agent 自主决定（Dream Cycle 全自动），EverOS 选择用算法决定（超图传播 + 权重更新），我的选择是人类定义规则，系统自动执行——TTL、权重衰减、压缩阈值都可以配置，但决策逻辑是确定性的。

八、结语：记忆是 Agent 的"灵魂"吗？

回到开头的那个问题：你问 Agent “昨天你帮我做了什么”，它答不上来。

但也许不久的将来，它不仅会回答"昨天我帮你写了三篇博客、改了两个 Bug"，还会说"我注意到你最近在密集研究 Agent 记忆系统，上周那篇文章的数据和这篇 EverOS 的分析已经整合进你的知识图谱了，需要我生成对比表格吗？"

那一天，Agent 就不再是一个工具了。它是一个有历史的协作者。

记忆让 Agent 有历史，知识让 Agent 有逻辑，技能让 Agent 有手段。当这三者形成闭环，我们就不再是"每次重新调教一个 AI"，而是在"培养一个持续进化的数字协作者"。

它不需要一开始就很完美。它只需要：记住教训，沉淀规律，优化动作，下一次做得更好。

GBrain 和 EverOS 你更看好哪条路线？你的 Agent 有长期记忆吗？欢迎在评论区聊聊。

See also

• 用 LLM 构建程序化知识系统：记忆、技能与进化
• Agent Context Roaming：桌面Agent与云端Agent协同的理想方式
• AI Native 文档：会话即知识，过程即资产
• AI 时代的企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化