用 AI 编程 Agent 超过一周的人，都会碰到同一个问题：

你花了半小时让它理解项目的技术栈、代码风格、部署约定——然后新开一个 Task，它全忘了。

这不是 Agent 的 bug，这是 LLM 的本质：无状态。每次对话都是从零开始。

过去一年，大家想了各种办法绕过这个限制：CLAUDE.md 文件、RAG 检索、把历史对话塞进 context。但这些都是补丁，不是解法。

最近两个开源项目，对这个问题给出了两条完全不同的解题路径——

MemOS：工业级记忆操作系统，图数据库 + 向量检索 + 异步调度。

self-improving-agent：几个 Markdown 文件 + 两个 Shell 脚本。

两个项目解决的是同一个问题，但工程哲学截然不同。这篇文章把它们放在一起看，帮你搞清楚各自适合什么场景。

先说共同的痛点

不管你用的是 OpenClaw 还是别的 AI 编程 Agent，这四个问题你一定遇到过：

1. 跨会话失忆

你告诉 Agent："这个项目用 pnpm，不用 npm；组件用函数式，不用 class；API 错误统一用 custom Error 类。"下次新会话，它又用 npm install 了。

2. Debug 知识无法复用

你花了一小时排查一个 SSR hydration error，最后发现是某个库不支持 SSR。下次遇到类似问题，Agent 又从零开始排查。那一小时的经验完全消失了。

3. 多实例信息孤岛

你同时跑三个 Agent 实例处理不同 PR，实例 A 踩了一个坑并解决了，实例 B 完全不知道，又踩了同一个坑。

4. token 消耗失控

为了让 Agent 有"记忆感"，最简单的方式是把历史对话全塞进 context。但项目跑了三个月后，70% 的 token 都在重复传递旧信息。

两个项目对这四个问题的解法，风格迥异。

方案 A：MemOS——工业级记忆操作系统

MemOS 由 MemTensor 团队开源，目前 v2.0（代号"星尘"），6.7k stars。

核心思路

在 LLM 之外建一个独立的记忆中间件——不是 RAG 框架，不是向量数据库，而是一个统一管理"存、取、改、忘"的操作系统级基础设施。

记忆怎么存

MemOS 用图数据库（Neo4j）+ 向量库（Qdrant）组合存储，把记忆组织成"MemCube"——每个用户、项目、Agent 一个独立空间，支持隔离和受控共享。

三类记忆统一管理：

记忆怎么用

通过 REST API 增删改查，任何 LLM 应用都能接入：

# 存入记忆POST /product/add{"user_id": "...", "messages": [{"role": "user", "content": "I like strawberry"}]}# 检索记忆POST /product/search{"query": "What do I like", "user_id": "..."}

检索是语义级的——你不需要精确匹配关键字，模型理解你的意图后从记忆图里拉取最相关的内容。

与 OpenClaw 的集成

MemOS 在 3 月初发布了 OpenClaw 官方插件，挂在 Task 的生命周期钩子上：

• • Task 启动前：从记忆库检索相关上下文，注入 system prompt
• • Task 结束后：提取有价值信息，异步写入记忆库

OpenClaw 完全感知不到记忆层的存在——对它来说就是多了一段 system prompt。两个版本：Cloud（API Key 即用，多实例共享）和 Local（SQLite + 全文/向量混合搜索，完全离线）。

实测数据

对比 OpenAI Memory：准确率 +43.70%，token 消耗降低 35.24%，个性化理解（PrefEval）+2568%。在 OpenClaw 集成场景中实测 72% 更低 token 使用。

方案 B：self-improving-agent——用 Markdown 做记忆

self-improving-agent 由 peterskoett 开发，196 stars，但在 OpenClaw 社区里热度极高。

核心思路

完全不引入外部基础设施。就用三个 Markdown 文件 + 两个 Shell 脚本，让 Agent 在工作过程中主动记录自己学到的东西。

记忆怎么存

在项目目录建 .learnings/ 文件夹：

.learnings/├── LEARNINGS.md         # 纠正、知识盲区、最佳实践├── ERRORS.md            # 命令失败、工具报错└── FEATURE_REQUESTS.md  # 用户提到的缺失功能

每条记录有结构化格式：

## [LRN-20260312-001] pnpm_convention**Logged**: 2026-03-12T14:00:00Z**Priority**: high**Status**: pending**Area**: config### Summary项目使用 pnpm，不是 npm### Details尝试 npm install 失败，lock 文件是 pnpm-lock.yaml### Suggested Action所有包管理命令用 pnpm

就是 Markdown。可以 cat、可以 grep、可以 git diff。

记忆怎么用

两个 Shell hook 驱动：

activator.sh（UserPromptSubmit hook）：每次用户发 prompt 前注入提醒——"任务完成后评估一下有没有值得记录的东西"。约 50-100 token 开销。

error-detector.sh（PostToolUse hook）：每次 Bash 命令执行后，扫描输出里有没有 Error:、Traceback、npm ERR! 等模式。检测到了就提示 Agent 记录到 ERRORS.md。

升级链：.learnings/→ 项目永久记忆

这是最关键的设计——学到的东西不只停留在临时日志里，有明确的升级路径：

升级触发条件：同一 pattern 出现 3 次以上 + 跨 2 个不同 task + 30 天以内。满足条件后，系统提示从冗长的学习记录精炼成短小的规则，写入 system prompt 级文件。

Skill 自动提取

./scripts/extract-skill.sh skill-name

一条命令把某个高价值 learning 提取成标准格式的 SKILL.md，可以通过 ClawdHub 分享给其他人。个人经验变成社区工具。

正面对比

为什么 self-improving-agent 在 OpenClaw 社区这么火

这个项目只有 196 stars，但在 OpenClaw 用户里的讨论度远超这个数字。原因有几个：

1. 零摩擦上手

不需要 Docker，不需要数据库，不需要 API Key。git clone 然后 mkdir .learnings，就能用了。对于大多数个人开发者来说，部署 Neo4j + Qdrant 只是为了让 Agent 有记忆，太重了。

2. 完全可审计

记忆就是文本文件。你打开 .learnings/ERRORS.md 就能看到 Agent 记住了什么、什么时候记的、优先级是什么。不满意就直接改、直接删。

对比之下，向量数据库里的 embedding 是不可读的——你需要一个 Dashboard 才能知道 Agent "记住了什么"。

3. 天然适配 OpenClaw 的 workspace 注入机制

OpenClaw 本身就有读取 CLAUDE.md、AGENTS.md 等文件注入 system prompt 的能力。self-improving-agent 做的就是让 Agent 自己来维护这些文件——升级链的目标正是写入这些文件。

这意味着不需要任何额外集成——它利用了 OpenClaw 已有的机制。

4. 学习记录可以 git 管理

.learnings/ 可以直接提交到仓库。这意味着：

• • 团队成员 pull 下来就能看到项目的"踩坑史"
• • CI 可以检查是否有 critical 优先级的未解决 learning
• • 代码审查时可以看到 Agent 的学习轨迹

5. 网络效应：Skill 提取 → 社区共享

当某个 learning 被验证后提取成 Skill，发布到 ClawdHub，其他人可以直接安装。这个链路让个人项目的踩坑经验变成社区资产。

为什么 MemOS 也不可替代

但 self-improving-agent 有明确的天花板：

记忆规模的瓶颈

当 .learnings/ 文件积累了几百条记录，全量注入 workspace 的 token 成本就变得不可接受了。MemOS 的语义检索只拉取最相关的记忆，消耗的 token 是可控的。

多实例/多用户场景

self-improving-agent 的记忆是本地文件，多个 Agent 实例无法实时共享。MemOS 通过同一 user_id 天然实现多实例记忆同步——这在团队协作和自动化 pipeline 场景里是刚需。

记忆的关系推理

MemOS 用图数据库存记忆，"用户 A 的偏好"和"用户 A 正在做的项目"之间的关联是图里天然存在的。Markdown 文件无法做到这种结构化关联。

多模态记忆

MemOS 支持图片、图表与文本的联合检索。self-improving-agent 只能处理文本。

怎么选

做决策其实很简单，问自己两个问题：

问题一：你的记忆量会有多大？

如果你是个人开发者、每天处理几个到十几个 Task，几百条学习记录足够——self-improving-agent，5 分钟上手，无需运维。

如果你在跑持续运行的 Agent pipeline，每天产生上千条记忆——MemOS，语义检索保证记忆规模增长时成本可控。

问题二：你需要多实例协作吗？

不需要→ self-improving-agent。需要→ MemOS。

它们并不互斥

更有趣的可能性是组合使用：

• • 用 self-improving-agent 在日常开发中捕获学习记录（零成本、高透明）
• • 当 .learnings/ 里积累了足够多高价值记录后，批量导入 MemOS 做语义索引
• • MemOS 的 Skill Memory 可以把从 .learnings/ 提取的 Skill 作为输入源

一个是轻量的"写入前端"，一个是重量的"检索后端"。这种组合在工程上完全可行。

更大的图景

这两个项目代表的是 AI Agent 基础设施演化中的一个关键趋势：

记忆正在从 prompt 的附属品，变成独立的系统层。

self-improving-agent 用最小可行产品证明了这件事有价值——用几个文本文件就能显著提升 Agent 的持续工作能力。

MemOS 则在证明这件事能规模化——当记忆量、用户量、并发量都上去之后，你需要的是操作系统级的基础设施。

这跟 Web 开发的演化路径惊人地相似：

• • 最初：session 信息存文件，session_data.txt
• • 然后：存 Redis，有了独立的缓存层
• • 再后来：分布式缓存 + 消息队列 + 数据库的组合

AI Agent 的记忆层，现在大概在"文件"到"Redis"的过渡阶段。self-improving-agent 是文件时代的最佳实践，MemOS 是 Redis 时代的提前布局。

两个都值得认真看。