编辑 | 云昭
过去一年，几乎所有 AI 产品都在谈一个词：记忆。
ChatGPT 在加“长期记忆”，Claude 开始“更懂上下文”，各种 Agent 框架都在强调“持续对话”。但问题一直没变：这些记忆，到底属于谁？
最近刷屏的开源项目 Clawdbot，给了一个完全不同、甚至有点危险的答案。
它不把记忆交给云端，不交给公司，也不藏在黑盒里。它把所有记忆，原封不动地，放在你自己的硬盘上。
这款 MIT 许可的开源个人人工智能助手，由 Peter Steinberger 创建。在经历了一周疯狂增长之后，Clawdbot 很快就在 Github 上拿到 53 k星。
ps：多说一嘴，Clawdbot 的 LOGO 也突然从螃蟹改成了龙虾🦞。
它能做的事情并不稀奇，都是大模型很擅长的事情：管理邮件、安排行程、航班值机、定时跑后台任务……
但最为显著不同的是，它接入 Discord、WhatsApp、Telegram、Slack 等常用聊天工具之后，奇妙的化学反应就产生了：它不会忘。
哪怕你三天不找它，三个月不找它，重启电脑、换模型、清空上下文，它都还记得你们做过的决定、偏好和历史。
这很快引起来圈内开发人士的注意，Clawdbot 究竟怎么做到的呢？
就在刚刚，一位AI研究工程师 Manthan Gupta，特别研究了这个问题。他解构了 Clawdbot 背后的记忆系统，发现与 ChatGPT、Claude 大不相同。
上下文 ≠ 记忆
为了说清这个问题，Manthan Gupta 表示需要搞清楚一个很容易被业界混淆的一个概念：上下文 ≠ 记忆。
“要理解 Clawdbot，必须先把很多产品刻意混淆的两件事拆开。”
什么是上下文？上下文，其实就是模型在这一轮请求中能看到的所有信息，包括：
System Prompt、对话历史、工具返回结果、当前消息等
为什么不管是做大模型开发还是Agent开发，大家一提上下文就会头疼，是因为上下文自带三个缺点：短、贵、有限。
那什么才是记忆？在 Clawdbot 里，Memory 是另一种大家已经习惯的事物：
记忆 = 存在磁盘上的文件
毕竟 prompt 也好，工具返回结果也好，都是给 AI 看的。但磁盘里的 Markdown 文件，确是人类用户能打开、能编辑、能 grep 的 。
这个 Markdown 文件更符合大家对于“记忆”的现象。
持久：重启、隔天、隔月都在
无界：理论上可以无限增长
便宜：不占 API 成本
可搜索：已建立语义索引
Manthan 表示，正是基于这一理念，Clawdbot 把 AI 从“会话工具”拉回成了“长期协作者”。
反行业设计：不靠“上下文窗口撑着”，MD文件就够了
Clawdbot 的核心记忆设计，总结起来就是一句话：
Memory is just Markdown.
没有专有数据库，没有云端私有格式，没有你看不懂的内部状态。它的默认目录结构长这样：
~/clawd/
├── MEMORY.md # 长期记忆（整理后的重要信息）
└── memory/
├── 2026-01-26.md # 今天的流水笔记
├── 2026-01-25.md
└── ...
这是一个非常“反 AI 行业”的设计选择。这样的设计好处很多，因为这意味着：
用户可以直接读、改、随时删除，甚至可以用 Git 管理。
没有任何“AI 特权”。
两层记忆设计
其中，值得注意的一个关键设计点是，Clawdbot 把记忆分成了两层。
第一层：每日日志（短期、原始）。这一点就像人的工作笔记本。
今天聊了什么、做了什么决定、你随口提过的偏好，它都会写进去：
## 10:30 AM - API Discussion
Decided to use REST over GraphQL.
## 4:00 PM - User Preference
User prefers TypeScript over JavaScript.
要点不在于追求结构优雅，只求不丢原始信息。
第二层：长期记忆（整理、沉淀）。这一点可以理解成人类的“脑内知识库”。
当某些信息被反复提及、确认、引用，Agent 会把它们整理进 MEMORY.md，比如：
用户长期偏好、已做出的关键决策、项目背景、重要联系人等等。
这一步，相当于从记事本升级成常识。
# Long-term Memory
## User Preferences
- Prefers TypeScript over JavaScript
- Likes concise explanations
- Working on project "Acme Dashboard"
## Important Decisions
- 2026-01-15: Chose PostgreSQL for database
- 2026-01-20: Adopted REST over GraphQL
- 2026-01-26: Using Tailwind CSS for styling
## Key Contacts
- Alice (alice@acme.com) - Design lead
- Bob (bob@acme.com) - Backend engineer
会话运行时自动加载的 AGENT.md 则规定了读取这些记忆的一些原则：
SOUL.md （备注：这里的soul也是创建者 Peter 称之为没有彻底开源的唯一一点秘密。）告诉你是谁。
USER.md 告诉 agent 正在服务谁。
memory/YYYY-MM-DD.md 则存储当前的 contex。
如果在会话，还需要读取 MEMORY.md.
## Every Session
Before doing anything else:
1. Read SOUL.md - this is who you are
2. Read USER.md - this is who you are helping
3. Read memory/YYYY-MM-DD.md (today and yesterday) for recent context
4. If in MAIN SESSION (direct chat with your human), also read MEMORY.md
Don't ask permission, just do it.
有意思的是，Peter 还特别设置了一条：不要请求权限，干就完了！
记忆文件是如何建立索引的
当记忆文件保存之后，后台就会对这些这些记忆进行切片，建立向量语义索引。
┌─────────────────────────────────────────────────────────────┐
│ 1. File Saved │
│ ~/clawd/memory/2026-01-26.md │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 2. File Watcher Detects Change │
│ Chokidar monitors MEMORY.md + memory/**/*.md │
│ Debounced 1.5 seconds to batch rapid writes │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 3. Chunking │
│ Split into ~400 token chunks with 80 token overlap │
│ │
│ ┌────────────────┐ │
│ │ Chunk 1 │ │
│ │ Lines 1-15 │──────┐ │
│ └────────────────┘ │ │
│ ┌────────────────┐ │ (80 token overlap) │
│ │ Chunk 2 │◄─────┘ │
│ │ Lines 12-28 │──────┐ │
│ └────────────────┘ │ │
│ ┌────────────────┐ │ │
│ │ Chunk 3 │◄─────┘ │
│ │ Lines 25-40 │ │
│ └────────────────┘ │
│ │
│ Why 400/80? Balances semantic coherence vs granularity. │
│ Overlap ensures facts spanning chunk boundaries are │
│ captured in both. Both values are configurable. │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 4. Embedding │
│ Each chunk -> embedding provider -> vector │
│ │
│ "Discussed REST vs GraphQL" -> │
│ OpenAI/Gemini/Local -> │
│ [0.12, -0.34, 0.56, ...] (1536 dimensions) │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 5. Storage │
│ ~/.clawdbot/memory/.sqlite │
│ │
│ Tables: │
│ - chunks (id, path, start_line, end_line, text, hash) │
│ - chunks_vec (id, embedding) -> sqlite-vec │
│ - chunks_fts (text) -> FTS5 full-text │
│ - embedding_cache (hash, vector) -> avoid re-embedding │
└─────────────────────────────────────────────────────────────┘
这里注意：
sqlite-vec是一个 SQLite 扩展，它可以直接在 SQLite 中进行向量相似性搜索，无需外部向量数据库。
FTS5是 SQLite 内置的全文搜索引擎，为 BM25 关键词匹配提供支持。
它们共同使 Clawdbot 能够从单个轻量级数据库文件中运行混合搜索（语义搜索 + 关键词搜索）。
Trick：它是怎么“想起”这些记忆的？
重点来了。
Clawdbot 从来不会把所有记忆一股脑塞进上下文。它的策略是：先搜索，再注入。
搜索怎么做？
每次涉及“过去的事”，Agent 必须先走一遍内存搜索流程：
向量语义搜索（理解你在说什么）
关键词 BM25 搜索（确保不漏专有名词）
两者加权融合：
finalScore = 0.7 * semantic + 0.3 * keyword
结果不够相关，直接丢弃。
这意味着什么？意味着上下文里永远只出现当前真正需要的记忆，而不是“我怕忘所以全塞”。
一个细节：没有使用外部数据库
很多人会忽略这一点。
即上面提到的，所有索引，全在一个本地 .sqlite 文件里。
Clawdbot 的向量搜索，不是用外部向量数据库，而是：SQLite、sqlite-vec、FTS5。没有任何 SaaS 依赖。
这里也可以看出 Peter 对于“私人 Agent”的设计理念：私人AI助手，就该是单文件、可迁移、可备份的。
长对话怎么处理？上下文窗口
现实很残酷：再大的上下文窗口，也会被用完。
Clawdbot 的应对策略也很直接：压缩（Compaction）。
（小编注：这一点类似于上周末OpenAI公开的Codex的处理办法，同样也是压缩。）
把早期对话总结成一段结构化摘要
保留最近的原始消息
把摘要写入磁盘，而不是只存在 prompt 里
这里有一个特别的处理：在压缩之前，先强制刷新记忆。也就是说，在模型“遗忘”之前，它会先把重要信息写进 Markdown 文件。
这一步非常巧妙，既压缩了上下文，同时又避免了“总结时顺手把关键决策抹掉”的经典事故。
┌─────────────────────────────────────────────────────────────┐
│ Context Approaching Limit │
│ │
│ ████████████████████████████░░░░░░░░ 75% of context │
│ ↑ │
│ Soft threshold crossed │
│ (contextWindow - reserve - softThreshold)│
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Silent Memory Flush Turn │
│ │
│ System: "Pre-compaction memory flush. Store durable │
│ memories now (use memory/YYYY-MM-DD.md). │
│ If nothing to store, reply with NO_REPLY." │
│ │
│ Agent: reviews conversation for important info │
│ writes key decisions/facts to memory files │
│ -> NO_REPLY (user sees nothing) │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Compaction Proceeds Safely │
│ │
│ Important information is now on disk │
│ Compaction can proceed without losing knowledge │
└──────
多 Agent，多人格，但记忆彼此隔离
Clawdbot 支持多个 Agent：
个人、工作、实验用、自动化脚本
每个 Agent 都有：独立工作区、独立记忆、独立索引，彼此默认互不读取。
你可以让 WhatsApp 上的“生活助理”，完全不知道 Slack 里的工作内容。
这在今天的 AI 产品里，几乎是奢侈配置。
~/.clawdbot/memory/ # State directory (indexes)
├── main.sqlite # Vector index for "main" agent
└── work.sqlite # Vector index for "work" agent
~/clawd/ # "main" agent workspace (source files)
├── MEMORY.md
└── memory/
└── 2026-01-26.md
~/clawd-work/ # "work" agent workspace (source files)
├── MEMORY.md
└── memory/
└── 2026-01-26.md总结：Clawdbot 记忆系统的四个原则
Clawdbot的记忆系统之所以成功，是因为它遵循了几个关键原则：
1. 透明胜过黑盒
Memory 使用的是纯 Markdown 格式。用户可以阅读、编辑和进行版本控制。它不使用任何晦涩难懂的数据库或专有格式。
2. 搜索胜过注入
智能体不会将所有信息都塞进上下文，而是搜索相关信息。这样既能保持上下文的聚焦性，又能降低成本。
3. 持久性优于会话
重要信息不仅保存在对话记录中，还会保存在磁盘上的文件中。压缩操作无法删除已保存的内容。
4. 混合型搜索优于单一搜索
单独使用向量搜索无法精确匹配，单独使用关键词搜索无法获取语义信息。混合搜索则能兼顾两者。
真正重要的：用户掌握自己的数据
回过头来，如果只看实现，Clawdbot 并不神秘。但正如 Peter 当时创建它的想法：
“今年会是个人 agent 之年，这个领域很可能会被 OpenAI、Anthropic 这些大厂主导。但我想做一个不同的选择：你能掌握自己的数据，而不是把更多数据交给这些巨头。”
因此，它传递出一个信号：
AI 的记忆，开始回到用户手里了。
它可以存在本地的磁盘里，用户可以像操作自己的“微信聊天记录一样”，可读、可控、可删除、可迁移。
很显然，这条路显然更受用户的欢迎。这也就不难理解，为什么2026开年，它会被大家刷屏了。
毕竟，当 Agent 开始长期陪伴用户，当 AI 不再只是回答问题，而是参与决策、执行、协作，记忆就从“功能”，变成了“权力”。
而谁掌握这份记忆，决定了 AI 最终站在谁那一边。
参考链接：
https://x.com/manthanguptaa/status/2015780646770323543
