我们阅读了克劳德代码的泄露源代码。它的内存是如何工作的

克劳德代码》的源代码意外公开发布。2.1.88 版包含一个 59.8 MB 的源代码映射文件，本应从构建中删除。这个文件包含了完整的、可读的 TypeScript 代码库--512,000 行，现在镜像在 GitHub 上。

内存系统引起了我们的注意。克劳德代码是市场上最流行的人工智能编码 Agents，而内存是大多数用户在不了解其工作原理的情况下与之交互的部分。于是我们深入研究了一下。

简而言之：克劳德代码的内存比你想象的要基础得多。它的上限是 200 行笔记。它只能通过精确的关键字匹配来查找记忆--如果你问的是 "端口冲突"，而笔记上写的是 "docker-compose 映射"，那么你什么也得不到。而且，这些内容都没有留下克劳德代码。换一个 Agents，你就从零开始了。

下面是四个层

• CLAUDE.md- 你自己编写的文件，其中包含了克劳德需要遵循的规则。手动、静态，受限于你事先写下的内容。
• 自动记忆--克劳德在会话过程中会自己记笔记。非常有用，但索引上限为 200 行，且不能按含义搜索。
• 自动梦境--一个后台清理程序，可在你闲置时整合杂乱的记忆。有助于处理数天前的杂乱记忆，但无法弥补数月前的记忆。
• KAIROS- 在泄露的代码中发现的未发布的始终在线守护进程模式。目前尚未公开。

下面，我们将对每一层进行解包，然后介绍架构的缺陷所在，以及我们为弥补这些缺陷而构建的架构。

CLAUDE.md 如何工作？

CLAUDE.md 是一个 Markdown 文件，由你创建并放置在你的项目文件夹中。您可以在其中填入任何希望克劳德记住的内容：代码样式规则、项目结构、测试命令、部署步骤。克劳德会在每次会话开始时加载该文件。

有三个范围：项目级（在 repo 根目录下）、个人级（~/.claude/CLAUDE.md ）和组织级（企业配置）。较短的文件会得到更可靠的跟踪。

限制是显而易见的：CLAUDE.md 只能保存你事先写下的内容。调试决定、你在谈话中提到的偏好、你们一起发现的边缘情况，这些都不会被记录下来，除非你停下来手动添加。大多数人都不会这样做。

自动记忆功能如何工作？

自动记忆会捕捉工作中出现的内容。克劳德会决定哪些内容值得保留，并将其写入你机器上的记忆文件夹，分为四类：用户（角色和偏好）、反馈（你的修正）、项目（决策和上下文）和参考（内容所在位置）。

每个笔记都是一个单独的 Markdown 文件。入口是MEMORY.md - 一个索引，其中每一行都是一个简短的标签（150 个字符以下），指向一个详细的文件。克劳德会读取索引，然后在相关文件出现时提取特定文件。

~/.claude/projects/-Users-me-myproject/memory/
├── MEMORY.md                  ← index file, one pointer per line
├── user_role.md               ← "Backend engineer, fluent in Go, new to React"
├── feedback_testing.md        ← "Integration tests must use real DB, no mocking"
├── project_auth_rewrite.md    ← "Auth rewrite driven by compliance, not tech debt"
└── reference_linear.md        ← "Pipeline bugs tracked in Linear INGEST project"
MEMORY.md sample (each line ≤150 chars):

[User role](user_role.md) — Backend engineer, strong Go, new to React
[Testing rule](feedback_testing.md) — No mocking the database in integration tests
[Auth rewrite](project_auth_rewrite.md) — Compliance-driven, not tech debt
[Bug tracker](reference_linear.md) — Pipeline bugs → Linear INGEST

每个会话都会加载 MEMORY.md 的前 200 行。除此之外的内容都是不可见的。

一个聪明的设计选择是：泄露的系统提示告诉克劳德将自己的内存视为一个提示，而不是事实。在根据记忆中的内容采取行动之前，它会先对照真实代码进行验证，这有助于减少幻觉--其他人工智能 Agents 框架也开始采用这种模式。

自动梦境如何巩固陈旧记忆？

自动记忆会捕捉笔记，但使用数周后，这些笔记就会过时。一条写着 "昨天部署错误 "的记录在一周后就变得毫无意义。一条记录说你使用 PostgreSQL，而更新的记录却说你迁移到了 MySQL。删除的文件仍有内存条目。索引中充满了矛盾和过时的引用。

Auto Dream 就是清理程序。它在后台运行，并且

• 用准确的日期替换模糊的时间引用。"昨天的部署问题"→"2026-03-28 部署问题"。
• 解决矛盾。PostgreSQL 备注 + MySQL 备注 → 保留当前真相。
• 删除陈旧条目。删除已删除文件或已完成任务的注释。
• 将MEMORY.md 控制在 200 行以内。

触发条件：距离上次清理超过 24 小时，并且至少积累了 5 个新会话。也可以输入 "dream "手动运行。该进程在后台子 Agents 中运行--就像真正的睡眠一样，它不会干扰你正在进行的工作。

Dream Agent 的系统提示以以下内容开头："您正在执行一个梦境--对您的记忆文件进行反思"

什么是 KAIROS？克劳德代码未发布的 "始终开启 "模式

前三层已经上线或推出。泄露的代码中还包含一些尚未发布的内容：KAIROS。

KAIROS 显然是以希腊语中 "正确时刻 "一词命名的，在源代码中出现了 150 多次。它将把克劳德代码从一个你主动使用的工具变成一个持续观察你的项目的后台助手。

根据泄露的代码，KAIROS

• 记录全天的观察、决策和行动。
• 定时检查。每隔一段时间，它就会收到一个信号，然后决定：行动还是保持沉默。
• 不妨碍你。任何会阻碍你超过 15 秒的行动都会被推迟。
• 在内部运行梦境清理，并在后台进行完整的 "观察-思考-行动 "循环。
• 拥有普通克劳德代码所没有的独家工具：向你推送文件、发送通知、监控你的 GitHub 拉取请求。

KAIROS 位于编译时功能标志之后。它不在任何公开版本中。把它想象成 Anthropic 在探索当Agents 内存不再逐会话存储，而是永远在线时会发生什么。

克劳德代码的内存架构有哪些缺陷？

克劳德代码的内存确实在工作。但是，随着项目的增长，有五个结构限制制约了它的处理能力。

限制	限制
200 行索引上限	MEMORY.md 保存 ~25 KB。一个项目运行数月，旧条目就会被新条目挤掉。"我们上周确定的 Redis 配置是什么？- 没了。
仅 Grep 检索	内存搜索使用字面关键字匹配。你记得 "部署时端口冲突"，但备注中却写着 "docker-compose 端口映射"。Grep 无法弥合这一差距。
只有摘要，没有推理	自动记忆功能保存的是高级笔记，而不是调试步骤或推理过程。这就失去了 "如何"。
复杂性叠加，却不解决基础问题	CLAUDE.md → Auto Memory → Auto Dream → KAIROS。每一层的存在都是因为上一层不够。但再多的分层也改变不了下面的内容：一个工具、本地文件、逐个会话捕捉。
内存被锁定在克劳德代码中	切换到 OpenCode、Codex CLI 或其他 Agents，你将从零开始。没有输出，没有共享格式，没有可移植性。

这些都不是错误。它们是单一工具、本地文件架构的自然限制。每个月都会有新的 Agents 推出，工作流程也会发生变化，但你在项目中积累的知识不应该随之消失。这就是我们建立memsearch 的原因。

什么是 memsearch？任何人工智能编码代理的持久内存

memsearch将内存从代理中提取出来，放入自己的层中。代理来来去去。内存保持不变。

如何安装 memsearch

克劳德代码用户从市场上安装：

/plugin marketplace add zilliztech/memsearch
/plugin install memsearch

完成。无需配置。

其他平台也同样简单。OpenClaw:openclaw plugins install clawhub:memsearch 。通过 uv 或 pip 安装 Python API：

uv tool install "memsearch[onnx]"

memsearch 能捕获什么？

一旦安装，memsearch 就会与 Agents 的生命周期挂钩。每次对话都会自动汇总和索引。当你提出一个需要历史记录的问题时，memsearch 会自动触发。

记忆文件以 Markdown 的形式存储--每天一个文件：

.memsearch/
└── memory/
    ├── 2026-03-28.md    ← one file per day
    ├── 2026-03-29.md
    ├── 2026-03-30.md
    └── 2026-04-01.md

你可以用任何文本编辑器打开、阅读和编辑记忆文件。如果要迁移，可以复制文件夹。如果你想进行版本控制，可以使用 git。

存储在Milvus中的向量索引是一个缓存层--如果它丢失了，你可以从 Markdown 文件中重建它。你的数据保存在文件中，而不是索引中。

memsearch如何查找记忆？语义搜索与Grep

克劳德代码的记忆检索使用的是grep--字面关键词匹配。当你有几十个笔记时，这种方法很有效，但当你记不起确切的措辞时，这种方法就会在几个月后失效。

memsearch则使用混合搜索。即使措辞不同，语义向量也能找到与你的查询相关的内容，而 BM25 则匹配精确的关键词。RRF（互惠排名融合）将两个结果集合并在一起并进行排名。

如果您问 "上周我们是如何解决 Redis 超时问题的？- 语义搜索可以理解您的意图并找到它。如果你问 "搜索handleTimeout"，BM25 会准确找到函数名称。这两条路径覆盖了对方的盲点。

当召回触发时，子 Agents 会分三个阶段进行搜索，只有在需要时才会深入：

L1：语义搜索--简短预览

子代理针对 Milvus 索引运行memsearch search ，并提取最相关的结果：

┌─ L1 search results ────────────────────────────┐
│                                                 │
│  #a3f8c1 [score: 0.85] memory/2026-03-28.md    │
│  > Redis port conflict during deploy, default   │
│    6379 occupied, switched to 6380, updated     │
│    docker-compose...                            │
│                                                 │
│  #b7e2d4 [score: 0.72] memory/2026-03-25.md    │
│  > Auth module rewrite complete, JWT replaced   │
│    with session tokens, mobile token refresh    │
│    was unreliable...                            │
│                                                 │
│  #c9f1a6 [score: 0.68] memory/2026-03-20.md    │
│  > DB index optimization, added composite       │
│    index on users table, query time dropped     │
│    from 800ms to 50ms...                        │
│                                                 │
└─────────────────────────────────────────────────┘

每个结果都会显示相关性得分、源文件和 200 个字符的预览。大多数查询到此为止。

L2:完整上下文--展开特定结果

如果 L1 的预览还不够，子 Agents 会运行memsearch expand a3f8c1 来提取完整的条目：

┌─ L2 expanded result ───────────────────────────┐
│                                                 │
│  ## 2026-03-28 Deploy troubleshooting           │
│                                                 │
│  Redis port conflict resolution:                │
│  1. docker-compose up → Redis container failed  │
│  2. Host port 6379 occupied by another instance │
│  3. Changed docker-compose.yml: "6380:6379"     │
│  4. Updated .env: REDIS_PORT=6380               │
│  5. Updated config/database.py connection       │
│                                                 │
│  Note: Only affects local dev. Prod unaffected. │
│                                                 │
│  [source: memory/2026-03-28.md  lines: 42-55]  │
└─────────────────────────────────────────────────┘

L3：原始对话记录

在极少数情况下，如果您需要查看确切的对话内容，子代理会调出原始交流内容：

┌─ L3 raw transcript ───────────────────────────┐
│                                                │
│  [user] docker-compose up won't start, Redis   │
│         port conflict — can you take a look?   │
│                                                │
│  [agent] Checking host port usage...           │
│          Running lsof -i :6379...              │
│          Suggest remapping to port 6380...     │
│          (tool_call: Bash "lsof -i :6379")     │
│          (tool_call: Edit "docker-compose.yml")│
│                                                │
│  [user] Done. Anything else to update?         │
│                                                │
│  [agent] Also need to update .env and          │
│          database.py...                        │
│                                                │
└────────────────────────────────────────────────┘

该副本保留了所有内容：您的原话、 Agents 的准确回复以及每个工具呼叫。这三个阶段由浅入深--由子 Agents 决定深入的程度，然后将整理好的结果返回到您的主会话。

memsearch 如何跨人工智能编码代理共享内存？

这是 memsearch 与克劳德代码内存之间最根本的差距。

克劳德代码的内存被锁定在一个工具中。如果使用 OpenCode、OpenClaw 或 Codex CLI，你将从头开始。MEMORY.md 是本地的，与一个用户和一个代理绑定。

memsearch 支持四种编码代理：Claude Code、OpenClaw、OpenCode 和 Codex CLI。它们共享相同的 Markdown 内存格式和相同的Milvus Collections。从任何代理写入的记忆库都可以从其他代理中搜索到。

两个真实场景

切换工具。你在 Claude Code 中花了一个下午的时间弄清部署管道，遇到了几个障碍。对话会被自动汇总并编入索引。第二天，您切换到 OpenCode，询问 "昨天的端口冲突是如何解决的？OpenCode 会搜索 memsearch，找到昨天克劳德代码的记忆，并给出正确答案。

团队协作。将 Milvus 后端指向Zilliz Cloud，不同机器上的多个开发人员使用不同的 Agents 读写同一个项目内存。新团队成员加入后，无需翻阅数月的 Slack 和文档，Agent 就已经知道了。

开发人员 API

如果你正在构建自己的Agents 工具，memsearch 提供了 CLI 和 Python API。

CLI：

# Index markdown files
memsearch index ./memory
# Search memories
memsearch search “Redis port conflict”
# Expand a specific memory’s full content
memsearch expand a3f8c1
# Watch for file changes, auto-index
memsearch watch ./memory
# Compact old memories
memsearch compact

Python API：

from memsearch import MemSearch
mem = MemSearch(paths=[“./memory”])
await mem.index()                          # index markdown
results = await mem.search(“Redis config”) # hybrid search
await mem.compact()                        # compact old memories
await mem.watch()                          # auto-index on file change

在引擎盖下，Milvus 处理向量搜索。使用Milvus Lite在本地运行（零配置），通过Zilliz Cloud协作（提供免费层级），或使用 Docker 自主托管。Embeddings默认使用 ONNX - 在 CPU 上运行，无需 GPU。可随时切换到 OpenAI 或 Ollama。

克劳德代码内存与 memsearch：全面比较

特点	克劳德代码内存	内存搜索
保存的内容	克劳德认为重要的内容	自动总结的每次对话
存储限制	~200 行索引（~25 KB）	无限制（每日文件 + 向量索引）
查找旧记忆	Grep 关键字匹配	基于意义 + 关键字的混合搜索 (Milvus)
你能读取它们吗？	手动检查内存文件夹	打开任何 .md 文件
能否编辑？	手动编辑文件	相同 - 保存时自动重新索引
版本控制	并非为其设计	git 可直接使用
跨工具支持	仅限克劳德代码	4 个 Agents，共享内存
长期记忆	数周后衰减	持续数月

开始使用 memsearch

克劳德代码的记忆具有真正的优势--自我怀疑设计、梦境巩固概念以及 KAIROS 中的 15 秒阻断预算。人类正在认真思考这个问题。

不过，单工具内存也有上限。一旦你的工作流程跨越多个 Agents、多个人或超过几周的历史，你就需要独立存在的记忆。

• 试试memsearch吧--开源，MIT 许可。只需两条命令即可在克劳德代码中安装。
• 阅读memsearch 的工作原理或Claude Code 插件指南。
• 有问题？加入Milvus Discord 社区，或预约免费的 Office Hours 会议，了解您的使用案例。

常见问题

克劳德代码的内存系统是如何工作的？

克劳德代码采用四层内存架构，全部存储为本地 Markdown 文件。CLAUDE.md 是您手动编写的静态规则文件。自动记忆可以让克劳德在会话过程中保存自己的笔记，分为四类：用户偏好、反馈、项目背景和参考指针。自动梦境会在后台整合陈旧的记忆。KAIROS 是在泄露的源代码中发现的一个未发布的始终在线守护进程。整个系统的索引上限为 200 行，只能通过精确的关键字匹配进行搜索，不能进行语义搜索或基于意义的调用。

人工智能编码代理能否在不同工具间共享内存？

不能。Claude Code 的内存锁定在 Claude Code 中，没有导出格式或跨 Agents 协议。如果切换到 OpenCode、Codex CLI 或 OpenClaw，就得从头开始。Memsearch 通过将记忆存储为有日期的 Markdown 文件，并在向量数据库（Milvus）中编入索引，解决了这一问题。所有支持的四个 Agents 都读写同一个内存存储，因此当你切换工具时，上下文会自动转移。

代理内存的关键字搜索和语义搜索有什么区别？

关键词搜索（grep）匹配的是精确的字符串--如果你的内存中显示的是 "docker-compose port mapping"，但你搜索的是 "port conflicts"（端口冲突），那么它什么也不会返回。语义搜索将文本转换为向量嵌入，从而捕捉意义，因此即使措辞不同，相关概念也能匹配。membsearch 将这两种方法与混合搜索相结合，让你在一次查询中就能获得基于意义的召回率和精确的关键词精度。

克劳德代码源代码事件泄露了什么？

克劳德代码 2.1.88 版附带了一个 59.8 MB 的源代码映射文件，该文件本应从生产构建中删除。该文件包含完整、可读的 TypeScript 代码库（约 51.2 万行），包括完整的内存系统实现、Auto Dream 整合过程以及对 KAIROS（一种未发布的始终在线 Agents 模式）的引用。在代码被删除之前，GitHub 迅速将其镜像了一遍。