memsearch：给 AI Coding Agent 做本地长期记忆

这篇文章解决什么问题

memsearch 是 Zilliz 做的一个跨平台 agent memory 系统，仓库地址：

• zilliztech/memsearch

它解决问题很具体：

• agent 每轮会话都忘上下文
• 长期偏好、项目约束、历史决策很难复用
• 现成 memory 工具很多偏云端、偏 SaaS、偏数据库视角
• 人已经写在 Markdown、Obsidian、Apple Notes 里的东西，agent 不一定吃得到

一句话：

memsearch 想做的不是“又一个向量库封装”，而是让 Markdown 笔记、Milvus 索引和渐进式检索一起变成 agent 可调用的长期记忆层。

采集时间：2026-04-28

先说结论

• memsearch 最适合已经有本地笔记体系、又想把这些内容直接喂给 coding agent 的人。
• 它核心不是“存 embedding”，而是“以 Markdown 为真相源，再用 Milvus shadow index 做检索加速”。
• 它强调 cross-platform、可人类编辑、可 agent 调用，不把用户锁死在专有云存储里。
• 小规模数据可以直接用默认 Milvus Lite；数据更大时，可以切到 Milvus Server 或 Zilliz Cloud。
• 如果你要的是“会自动替你总结生活记忆的产品化 app”，它不是这一路。
• 如果你要的是“我已有一堆笔记和项目文档，想让 Claude Code / Codex / MCP 直接查”，它路子很对。

我的判断：

memsearch 本质上是面向 agent 的本地记忆基础设施，不是面向终端用户的聊天玩具。

它和常见 memory 工具差在哪

memsearch 官方文档里把自己放在几个交叉点上：

• 既不是只做向量库
• 也不是只做纯文档搜索
• 也不是只做封闭式记忆产品

它强调几个取舍：

维度	memsearch 的选择
数据归属	本地优先，Markdown 为主
人类可维护性	直接编辑原始文件，不要求进专有格式
检索方式	Dense 语义检索 + BM25 全文检索 + RRF 融合
存储策略	Markdown 文档是真相源，Milvus 索引是派生物
扩展方式	小规模本地跑，大规模可切向量后端
面向对象	AI agent、MCP、知识工作流

这和很多“记忆系统”差别很大。

很多同类方案默认假设是：

• 用户把内容写进数据库
• 平台托管 embedding 和索引
• 记忆主要给某个固定产品自己消费

memsearch 反过来：

• 先承认用户已经有现成知识库
• 不要求迁移写作习惯
• 不要求把原文交给云端托管
• 先把“记得住”问题做成开放检索层

这也是它最有意思地方。

核心设计：Markdown 是真相源，Shadow Index 是加速层

这是 memsearch 最值得记的一点。

官方 README 和设计文档里明确强调：

• Markdown is source of truth
• Milvus is shadow index
• 检索层应该服务内容，而不是反过来控制内容

翻成人话就是：

1. 你的笔记、记忆、项目规则，真正落在普通 Markdown 文件里。
2. 检索索引只是这些文件的派生加速结构。
3. Milvus 索引坏了可以重建，但原始记忆不能被专有格式绑死。

这套思路有几个直接好处。

1. 人能读，agent 也能读

你不用把记忆写进只有程序看得懂的数据结构。

同一份内容：

• 人可以用编辑器、Obsidian、Apple Notes 去改
• agent 可以走 memsearch 检索
• 迁移成本也低

2. 更适合长期积累

记忆这种东西，本来就比会话长。

如果记忆层绑死在某个 app、某个托管服务、某个 schema 里，时间一长就会变成数据孤岛。memsearch 把原始内容保留在普通文件里，这件事更耐用。

3. 更适合 coding agent 场景

coding agent 真正需要的长期记忆，经常不是“某人今天午饭吃什么”，而是：

• 仓库约束
• 代码风格
• 历史决策
• 业务术语
• 常见坑
• 组件边界
• 之前修过的问题

这类内容本来就很适合写成 Markdown。

检索不是只靠向量：Dense + BM25 + RRF

很多人一看到 memory / RAG，就默认等于 embedding search。

memsearch 不是这思路。

从 README 和 design philosophy 看，它至少把三类信号放在一起：

• dense vector search
• BM25 sparse search
• RRF reranking

这点很重要，因为长期记忆检索里，经常会遇到三类问题：

1. 语义相近，但关键词不一致

比如你搜“用户偏好”，文档里写的是“个人约束”“协作习惯”“写法偏好”。

这类要靠 dense 语义召回。

2. 关键词精确，不能只靠向量

比如你搜：

• pnpm docs:build
• CDULDDY.html
• responseType: 'blob'

这种精确文本，BM25 往往更稳。

3. 混合排序比单路召回更稳

dense 擅长语义，BM25 擅长关键词，但都不完美。memsearch 用 RRF 把两路结果合并，避免只押一个信号源。

所以它不是“向量库套壳”，而是把记忆检索当成一个混合排序问题。

为什么它对 agent 特别有用

memsearch 文档里反复提到 agent、MCP、Codex CLI、Claude Code 一类集成方式。原因不复杂：

• agent 擅长生成
• agent 不擅长长期记忆
• 记忆如果不稳定，agent 每轮都要重新理解你

这会直接带来几个高频问题：

• 重复说明项目规则
• 同一个需求背景每次都要再解释
• 之前做过的方案，下轮又忘了
• 用户偏好没有沉淀成可检索事实

memsearch 把这件事拆成一个更工程化方案：

1. 人继续在本地写笔记、规则、决策。
2. 系统把 Markdown 增量切块并建 Milvus shadow index。
3. agent 通过检索接口按需取回相关记忆。

这比把所有“长期约束”硬塞进 system prompt 更稳。因为 prompt 容量有限，而且不同任务真正需要的记忆并不一样。

它还有个很实用的点：跨 agent 共享

这是 memsearch 和很多“单产品记忆”方案差别很大的地方。

同一份记忆，可以在：

• Claude Code
• Codex CLI
• OpenClaw
• OpenCode

之间复用。

这意味着你今天在一个 agent 里沉淀下来的：

• 项目规则
• 架构决策
• 故障排查
• 历史约束

明天换另一套工具时，不需要从零再喂一次。

这件事对频繁切换工具链的人，价值很高。

最小上手链路

从官方 getting started 看，memsearch 上手路径不复杂，而且先支持零配置本地跑通。

1. 安装

pip install "memsearch[local]"

2. 创建记忆空间

mkdir -p quickstart-notes
printf '# Notes\n\n- Redis TTL is 15 minutes\n- Staging URL is https://staging.example.com\n' > quickstart-notes/MEMORY.md

3. 建索引并查询

import asyncio
from memsearch import MemSearch

async def main():
    mem = MemSearch(
        paths=["./quickstart-notes"],
        embedding_provider="local",
    )
    await mem.index()

    results = await mem.search("what is the Redis TTL?", top_k=3)
    for r in results:
        print(r["content"])

    mem.close()

asyncio.run(main())

这个 quick start 很能说明项目定位：

• 默认就能本地跑
• 默认后端就是 Milvus Lite
• 不要求先配云端 API
• 先把“记忆可索引、可召回”跑起来再说

一个更贴近 coding agent 的使用案例

如果把它放进日常开发协作，最自然记忆内容大概长这样：

# Gitlon 协作偏好

- 使用简体中文回复
- 回复尽量短，先结论后原因
- 不主动执行 eslint / format
- 多语言文案放当前页面，不统一抽字典
- 新增 AI 笔记放 `src/notes/ai`
- 通常要同步 `index.md` 和 `.vitepress/config.mjs`

然后 agent 在做新任务前，先做 L1 检索：

memsearch search "How should AI notes be added in this repo?"
memsearch search "What is the preferred communication style?"

如果某条结果需要更多上下文，再做 L2 expand；如果还不够，再回到原始对话 transcript。这个 search → expand → transcript 的三层渐进召回，是它很关键设计点。

召回结果如果稳定，agent 每次开工前就不必重新问一轮基础约束。

这类用法比“记住我喜欢 TypeScript 吗”更有价值，因为它直接影响执行质量。

它适合什么场景

适合

• 已经有 Markdown / Obsidian 知识库
• 想给 coding agent 接长期记忆
• 不想把原始记忆托管到云端
• 需要混合检索，不只做向量召回
• 想保留人类可读、可编辑、可迁移的数据格式

不太适合

• 只想要现成 SaaS，不想管本地知识库
• 数据本身不在文件里，而在强结构化业务库
• 需求更偏聊天助手产品，而不是 agent 基础设施
• 团队根本没有维护长期文档/笔记习惯

说白了：

memsearch 更吃“你本来就有知识沉淀”这件事。没有内容，只有工具，记忆层也救不了 workflow。

我觉得它最对的三个判断

1. 不把数据库当真相源

很多检索系统默认“库里东西才是真的”。memsearch 反过来，让文档是真相，索引是派生物。这个判断更适合知识工作流。

2. 不把语义检索当唯一答案

Dense + BM25 + RRF，比单纯 embedding 更接近日常记忆查询真实需求。

3. 不把记忆做成封闭产品

它不是让你把内容交给某个 app 才能用，而是把已有内容变成可检索能力。这点对 agent 生态尤其重要。

还有哪些边界要看

虽然方向对，但落地时还是要看几个现实问题：

• 大规模知识库下，索引更新延迟和重建成本怎么样
• 多来源同步时，冲突处理做得多细
• 权限隔离是不是足够细粒度
• MCP 接入后，召回结果怎么做去噪和排序
• 如果团队记忆质量差，是否会把噪音也稳定召回

这些不是 memsearch 独有问题，几乎所有长期记忆系统都会遇到。

最后总结

如果只看名字，memsearch 很容易被误解成“一个搜索工具”。

但它真正有价值地方是它的设计立场：

• 本地优先
• Markdown 优先
• 索引可重建
• 混合检索
• 面向 agent

所以我会把它理解成：

给 AI coding agent 接长期记忆时，一个很工程化、也很克制的底座方案。

它没有把问题吹成 AGI，也没有假装“向量库 = 记忆”。这点反而让我更愿意继续观察它。

参考资料

• memsearch GitHub README
• memsearch 文档首页
• memsearch Design Philosophy
• memsearch Getting Started
• memsearch Platform Comparison