如果你和我一样，电脑上装着好几个AI客户端，本地还跑着一两个开源模型，那你大概率经历过这种崩溃：上午在客户端A里把项目背景、技术约束、目标用户从头到尾梳理了一遍，下午切到客户端B想让它接着写代码，结果它完全不知道你在说什么，你又得把上午说过的话原封不动重复一遍。每次切换都像失忆，时间和耐心就是这么被一点点磨没的。后来我实在忍不了，动手做了一个开源工具——MemTether，让多个AI客户端共享同一份记忆。这篇文章就是我从想法到落地的完整复盘，包括架构思路、数据结构、核心代码和踩坑记录，希望能给同样被“AI失忆”困扰的人一点参考。
1. 这个工具到底解决什么问题
1.1 多客户端切换的“失忆”困境
先说说我自己的真实工作流。我平时处理一个项目时，习惯让不同AI干不同的事：客户端A擅长长文本分析和产品梳理，我把需求丢给它，它能产出结构清晰的PRD；客户端B写代码更顺手，我让它实现接口和修bug；本地部署的模型则用来处理一些不方便提交给外部服务的敏感内容。听起来很合理对吧？但实际操作起来有个巨大的问题：这三个“AI”之间没有任何共享信息。
举个例子。某个周三，我用客户端A把项目的数据库选型讨论清楚了，结论是用PostgreSQL加Flyway做迁移。到了下午，我打开客户端B让它写这个项目的建表脚本，它压根不知道前面那个结论，反而根据自己“更熟悉”的MySQL模板给出了完全偏离需求的代码。我当时的表情大概就是：我们不是在聊同一个项目吗？
这种问题不是偶尔发生，而是每次切换必现。我也试过把背景说明写在一个文件里，需要时复制粘贴给AI。但问题是你不知道什么信息该给、给多少，而且随项目推进，背景文件越来越长，改起来也麻烦，粘贴进去又占上下文窗口。说白了，这条路只适合一次性小任务，根本撑不起一个信息会持续增长的真实项目。
1.2 MemTether到底是个什么东西
MemTether这个名字，拆开看就是memory（记忆）加tether（拴绳、连接）。含义很直白：把多个AI客户端的记忆，用一根绳子拴到同一个锚点上。锚点就是我维护的一份结构化记忆数据，任何客户端都能读写它。
一句话定义：MemTether是一个面向AI客户端的开源“记忆层”。它对外提供一组干净的记忆读写接口，让客户端A写入的信息，客户端B能通过检索获取到。它本身不强依赖任何特定AI，也不替代任何AI，只负责做一件事——让“记忆”独立于“客户端”存在。
你可以把它想象成档案系统。你看病时，病历不是跟着医生走的，而是存在医院档案科。你换科室、换医生，新医生调一下档，就知道你的病史。MemTether就是AI世界的档案科。每个客户端都是“科室”，它们可以调阅同一份“病历”，而不是各自记一套互不相通的小本本。
1.3 适合谁用，能解决什么级别的痛点
从实际使用场景看，有三类用户会比较需要它。
第一类，像我这样在多个商业AI客户端和本地模型之间来回切换的个人用户。痛点是上下文断裂，好处是终于不用每次重新做自我介绍。
第二类，小型团队做项目协作。每个成员习惯用的AI不一样，有人用ChatGPT，有人用Claude，有人用本地Ollama。以前大家各自和AI聊，聊出来的项目结论零散地躺在不同的对话记录里。接上MemTether之后，团队的项目背景、已做决策、代码约束可以沉淀成一份共享记忆，任何客户端调出来都是同一版本的事实。
第三类，在做AI Agent或自动化工作流的开发者。Agent跑起来经常需要多步决策，每一步可能调用不同的模型。把中间状态写进记忆层，整个流程就有了“短期工作记忆”，而不是每步都是无状态的调用。
当然它也不是银弹。如果你只是偶尔用AI查点资料、追个热点，那根本用不上这玩意。它是给工作流“重”的人准备的，属于锦上添花还是雪中送炭，取决于你被重复背景说明折磨的程度。
2. 整体设计思路：为什么采用“记忆层”架构
2.1 记忆和客户端为什么要解耦
刚开始做这个工具时，我脑子里其实闪过一个更直接的方案：给每个客户端写插件，直接扩展它们的记忆能力。调研了一圈之后我放弃了，原因有三条。
第一，大多数商业AI客户端是黑盒。它们不开放自定义内存存储，你只能在系统提示词里塞东西，或者在会话里手动引导。这种“记忆”既不持久，也不结构化，更像临时便签。
第二，就算某些客户端自带记忆功能，那也是各自独立的。我在ChatGPT里记住的东西，Claude绝对读不到。记忆被锁在应用的会话体系里，没法迁移。
第三，聊天记录本身是脏数据。里面夹杂大量语气词、错误尝试、重复讨论，直接把整段聊天记录当记忆喂给另一个AI，效果比你想象的差得多。它需要被提炼、压缩、结构化，才能变成真正可复用的记忆。
所以结论很清晰：不要在客户端层面做记忆，要做就做一个独立的中间层。这就像不要在每个App里单独存一份用户画像，而是做一个统一的用户中心，所有App都来调接口。解耦的好处是，以后来了新客户端，只要它能调用HTTP接口或支持工具协议，我就能让它接入同一份记忆，不用为每个客户端单独造轮子。
2.2 三种可行方案的对比
我梳理过市面上可能走得通的三条路线，这里直接做成表格给大家看。
| 方案 | 实现方式 | 侵入性 | 通用性 | 维护成本 |
|---|---|---|---|---|
| A. 客户端插件 | 在客户端内写插件或自定义指令 | 高，受限于客户端开放程度 | 低，每接一个客户端要单独适配 | 高，客户端一升级就可能失效 |
| B. 聊天记录迁移 | 解析导出文件，转换后导入另一个客户端 | 中，只解决一次性迁移 | 很低，无法持续同步 | 高，格式识别是噩梦 |
| C. 中间记忆层 | 独立服务，各客户端通过标准接口读写 | 低，不改客户端本身 | 高，任何能调HTTP/支持工具协议的客户端都能接 | 低，只需维护一个服务端 |
方案A是最符合直觉的，但落地困难；方案B听上去美好，实际上聊天导出的格式五花八门，而且只能导出一次性的，无法做双向持续同步。方案C初看要多搭一个服务，但它把复杂度和扩展性问题一次性解决了。我做MemTether选择的就是方案C。
2.3 架构拆解：Adapter、Memory Service、Storage
MemTether整体的架构可以分成三层，各层职责很清晰。
第一层是适配层（Adapter）。它负责把不同客户端“拉齐”。具体做法是，MemTether对外提供统一的HTTP REST接口，同时也可以封装成MCP Server。MCP是现在很多客户端都在支持的模型上下文协议，像Claude Desktop、Cursor这类支持MCP的工具，可以直接把MemTether当作一个外部工具来调用。适配层做的事情就是：自定义GPT也好、MCP server也罢，最终都翻译成对记忆服务的统一调用。
第二层是记忆服务（Memory Service），这是整个工具的核心。它负责记忆条目的写入、检索、更新、去重和遗忘判断。比如写到过的东西要不要合并，检索时该用关键词还是语义向量，多个客户端同时更新同一条记忆该怎么处理，这些业务逻辑都收敛在这一层。
第三层是存储引擎（Storage）。我第一版用的是SQLite，后面为了做语义检索，又加了向量索引。选SQLite的原因很简单：个人工具部署要轻，单文件存储没有运维负担，数据主权也完全在自己手里。存储层对上层屏蔽了实现细节，哪天记忆量真到了几十万条，我可以把向量部分换成独立数据库，上层接口不需要变。
数据在客户端和MemTether之间的流动大概是这样的：用户在Claude里问“我们之前定的数据库选型是什么”，如果Claude通过MCP接入了MemTether，它会调用记忆检索工具，带上“数据库选型”这个查询；MemTether在记忆库里检索，把结构化的记忆条目返回给Claude；Claude根据返回内容组织回答。整个流程里，Claude不需要在系统提示里看见整段背景，它需要的时候自己“想起”就行。
3. 记忆的数据结构与读写机制
3.1 一条记忆长什么样
做过信息管理的人都知道，没有结构的数据就是垃圾堆。MemTether的每一条记忆，我设计成下面这样的JSON结构：
{ "id": 1024, "type": "fact", "content": "项目数据库选型为 PostgreSQL，迁移工具使用 Flyway", "tags": ["project:alpha", "database", "architecture"], "source": "chatgpt", "created_at": "2025-03-18T10:20:00Z", "updated_at": "2025-03-19T14:05:00Z", "version": 3 }每个字段都有自己的用途。type表示记忆类型，我目前定了四种：fact是事实陈述，preference是用户偏好，summary是对话摘要，progress是任务进度。为什么要做类型区分？因为检索时可以按类型过滤，而且不同类型的清理策略也应该不同。比如fact要长期保留，临时性的progress可能过几天就没用了。
content是记忆本身的内容，要求把它写成一句独立可读的话，而不是口语碎片。“用户喜欢简洁的回复”是一条好记忆，“用户感觉好像那个就是比较喜欢短一点的吧”就不是。tags是标签，我建议用统一的标签体系，后面会讲它带来的收益。source记录这条记忆来自哪个客户端，这个字段对调试和溯源特别有用。version是版本号，用来处理并发写冲突。
3.2 检索从关键词到语义向量的三层演进
MemTether的检索能力不是一步到位的，我走了一个渐进的过程，这里分享出来，可能对你自己实现类似功能有参考价值。
第一版用的是SQLite的LIKE模糊匹配。说实话，凑合能用，但体验很差。比如记忆里存的是“PostgreSQL”，你搜“数据库选型”根本搜不到，因为两者没有共同的字面片段。LIKE匹配适合小数据量、查询词和内容字面高度重合的场景，但对真实语言的多样性无能为力。
第二版升级到SQLite内置的FTS5全文检索。FTS5提供了倒排索引和BM25排序算法，能很好解决“单词匹配”问题，速度也快。但对中文场景，FTS5默认分词器并不好用。我一开始用的是unicode61，它会按Unicode字符简单切分，中文句子切出来的效果一言难尽，检索准确率飘忽不定。后来我用自定义分词逻辑做补偿，才把情况稳住。这段坑在第5章会详细说。
第三版引入了向量检索，这是MemTether真正“智能”起来的关键一步。我用嵌入模型把每条记忆的content转成一个几百维的浮点向量，查询时把用户的问题也转成向量，然后算余弦相似度，取最接近的Top-K条返回。这就是所谓的“语义检索”。生活化理解：全文检索像查字典，必须字面匹配；语义检索像看同义词词典，你说“数据库选型”，它能联想到“我们最后决定了PostgreSQL”。
实际生产的时候，我推荐用混合检索：先向量召回一批候选记忆，再用关键词或标签做一次精确过滤，最后按一个加权分排序。MemTether默认就是这么做的，单独用一个检索方式，要么漏、要么杂。
3.3 写入、更新与版本控制
写入记忆看起来是简单的INSERT，但实际上要小心两件事：去重和更新策略。
先说去重。经常出现的情况是，客户端A写了一条“系统使用JWT做身份认证”，客户端B过两天又写了一条几乎一样的。如果不做去重，记忆库会满是重复条目，检索结果长得都一样，质量很差。我的处理方式是在写入前做一次相似度检查：如果新条目和已有条目的相似度超过阈值（比如0.85），就不是新增，而是更新原条目的updated_at、source等字段。如果相似度不高但明显有关联，我会选择把新条目作为补充写进去，保留下关联信息。
再说更新策略。MemTether默认做得比较保守：更新记忆时不允许裸UPDATE覆盖，而是要带上版本号。写入时如果发现当前内存里的版本号和数据库里的版本号不一致，说明有别的客户端改过这条记忆，这时就触发冲突处理。
冲突处理有三种策略：
| 策略 | 行为 | 适用场景 |
|---|---|---|
| last-write-wins | 后写入的覆盖先写的 | 单机自用，不纠结历史 |
| source-priority | 指定某个source优先 | 团队有明确信息源优先级 |
| merge-mark | 保留旧版本并标记冲突 | 审计要求高的场景 |
对大多数普通用户，last-write-wins已经够用。我自己使用时会设置source优先级，比如把ChatGPT产生的项目决策类记忆当成高优先级来源，避免本地模型偶尔编造的碎片把它覆盖掉。
3.4 遗忘机制同样重要
一提记忆，大家都希望AI“记得越久越好”，但真实使用中发现，记忆库如果只增不减，最后会变得一团糟。你存了几千条细节，检索时每次都命中一堆过期的临时信息，反而干扰判断。
所以MemTether设计了一套轻量的遗忘机制。第一，时间衰减：超过一定时间没有被检索命中的记忆，参考评分会降低，被返回的排序会被推后。第二，固定记忆：用户可以主动给重要记忆打pinned标记，被pinned的条目不参与衰减和清理。第三，定期合并：有些记忆是零散的对话摘要，系统可以定期把这些低层记忆合并成一条更高层的摘要，删掉细节。比如十条“讨论了数据库兼容性”的碎片，合并成一条“Alpha项目数据库需兼容PostgreSQL和MySQL”。遗忘不是功能缺失，而是记忆系统保持健康的必要手段。
4. 从零实现第一版：技术选型与核心代码
4.1 技术栈选择及理由
我实现MemTether第一版时，技术选型其实没有太多纠结。后端选了Python和FastAPI，原因有三：一是Python的AI生态最成熟，后续接嵌入模型顺手；二是FastAPI写这种小型API服务非常快，自带交互式文档，调试体验好；三是个人开源项目要保证别人能快速跑起来，Python几乎不需要构建步骤。
存储先用SQLite，这是故意的。有人跟我建议直接用PostgreSQL，但我觉得第一版能单文件跑起来最重要，用户下载代码、装依赖、启动服务，三步就能用上，这种“零运维”体验对开源项目的传播帮助巨大。等到记忆量真大了，存储层本来就被接口隔离，换掉也容易。
嵌入模型这块，我初期直接调用sentence-transformers里的小模型，本地跑，离线也能用。虽然精度不如商用大模型API，但胜在完全本地、没有调用成本。向量存储我一开始没有上独立数据库，写在SQLite旁边的一个表里。原因是数据量到几万条以内，纯暴力余弦计算完全能扛住，没必要多引入一个服务依赖。
4.2 项目结构
第一版的项目结构很朴素，就几个文件：
memtether/ ├── main.py # FastAPI入口，注册路由 ├── models.py # Pydantic数据模型 ├── memory_store.py # 记忆写入、查询、版本控制 ├── retriever.py # 检索逻辑（FTS5 + 向量） ├── embedder.py # 嵌入模型封装 ├── config.yaml # 配置：存储路径、检索参数 └── requirements.txt不搞复杂的框架分层，是因为核心逻辑本身不复杂，摊开来反而好维护。等社区用户多了、功能需求多了，再重构不迟。
4.3 核心代码实现
先说数据模型。用Pydantic定义MemoryItem，在API入口做数据校验。
# models.py from datetime import datetime from typing import List, Optional from pydantic import BaseModel class MemoryItem(BaseModel): type: str = "fact" # fact / preference / summary / progress content: str tags: List[str] = [] source: str = "" # 来源客户端标识 created_at: datetime = datetime.now() updated_at: datetime = datetime.now() version: int = 1然后是存储层，这里放写入和FTS5索引的简化实现。注意content和tags会同步写入一张FTS5虚拟表，供搜索引擎使用。
# memory_store.py import sqlite3 from models import MemoryItem class MemoryStore: def __init__(self, db_path="memtether.db"): self.conn = sqlite3.connect(db_path) self.conn.row_factory = sqlite3.Row self._init_db() def _init_db(self): self.conn.execute(""" CREATE TABLE IF NOT EXISTS memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, type TEXT, content TEXT, tags TEXT, source TEXT, created_at TEXT, updated_at TEXT, version INTEGER DEFAULT 1 ) """) self.conn.execute(""" CREATE VIRTUAL TABLE IF NOT EXISTS memories_fts USING fts5(content, tags, tokenize='unicode61') """) def write(self, item: MemoryItem) -> dict: tags = ",".join(item.tags) cur = self.conn.execute(""" INSERT INTO memories (type, content, tags, source, created_at, updated_at, version) VALUES (?, ?, ?, ?, ?, ?, ?) """, (item.type, item.content, tags, item.source, item.created_at.isoformat(), item.updated_at.isoformat(), item.version)) self.conn.execute(""" INSERT INTO memories_fts (content, tags) VALUES (?, ?) """, (item.content, tags)) self.conn.commit() return {"id": cur.lastrowid, **item.model_dump()}检索层，这里给出FTS5关键词检索部分。向量检索的实现会额外引用embedder，核心就是先算向量，再排序，这里为了篇幅就不展开了。
# retriever.py class Retriever: def __init__(self, store: MemoryStore): self.store = store def keyword_search(self, query: str, limit: int = 5) -> list: # 这里做了简化的查询词转义，实际使用需要更完整的处理 q = '"' + query.replace('"', '""') + '"' rows = self.store.conn.execute(""" SELECT m.id, m.type, m.content, m.tags, m.source, m.updated_at, bm25(memories_fts) AS score FROM memories_fts JOIN memories m ON m.id = memories_fts.rowid WHERE memories_fts MATCH ? ORDER BY score LIMIT ? """, (q, limit)).fetchall() return [dict(row) for row in rows]最后是FastAPI入口，对外暴露两个核心接口：写入和检索。
# main.py from fastapi import FastAPI from models import MemoryItem from memory_store import MemoryStore from retriever import Retriever app = FastAPI(title="MemTether") store = MemoryStore() retriever = Retriever(store) @app.post("/write") def write_memory(item: MemoryItem): return store.write(item) @app.get("/search") def search_memories(q: str, limit: int = 5): return retriever.keyword_search(q, limit)跑起来之后，接口调用方式非常直观。写入一条记忆：
curl -X POST http://localhost:8000/write \ -H "Content-Type: application/json" \ -d '{"type":"fact","content":"Alpha项目数据库选型为PostgreSQL","tags":["alpha","database"],"source":"chatgpt"}'检索记忆：
curl "http://localhost:8000/search?q=数据库选型&limit=5"这套代码已经能构成一个最小可用的记忆服务。真正接入客户端时，再把向量检索和MCP Server封装加上，体验会再上一个台阶。
4.4 客户端接入的几种真实路径
客户端接入MemTether，我实际操作下来主要走三条路。
第一条是走MCP协议。Claude Desktop、Cursor这类客户端都有MCP配置入口，我可以把MemTether封装成一个MCP Server，里面暴露两个工具：mem_write和mem_search。配置好之后，AI在对话中需要回忆时会自动调mem_search，用户也可以让它把当前讨论的结论写入记忆。这种接入方式对用户最隐形，AI会“自主”使用记忆能力。
第二条是走HTTP API加提示词注入。对于不支持MCP但支持自定义API的客户端（比如我通过OpenAI Action接入ChatGPT，或给本地Ollama套一层代理），做法是在系统提示词里加一段模板：“你可以调用MemTether接口查询背景记忆。查询接口是GET /search?q=关键词，写入接口是POST /write。回答用户问题前，先用查询接口检索相关背景。”这种方案虽然比MCP笨一点，但兼容面广，几乎不需要客户端原生支持什么新协议。
第三条是本地脚本直接调用。我在一些自动化任务里，写一个Python脚本，在调用模型之前先向MemTether查询相关记忆，拼进prompt，再把模型返回的结论写回MemTether。这个过程和客户端无关，完全是程序化的。对做Agent的人来说，这条路径最灵活，记忆系统变成一个随时可存取的数据源。
5. 常见问题速查与避坑心得
5.1 典型问题速查表
用了一段时间，又被早期使用者反馈了不少问题，我把高频的整理成一张表，方便大家对照排查。
| 现象 | 原因 | 解决方案 |
|---|---|---|
| 检索完全搜不到某条记忆 | 中文分词不合适，或查询词和内容字面无关 | 换自定义分词；减少对纯关键词的依赖，启用向量检索 |
| 多个客户端同时写，后一个覆盖前一个 | 没有版本控制，盲目UPDATE | 写入时对比version，冲突时按source优先级取 |
| 记忆越来越多，但检索结果反而越来越差 | 缺少去重和遗忘机制，垃圾条目堆积 | 写入前做相似度去重；定期跑合并脚本 |
| 同一个问题在不同客户端上得到不同答案 | 各客户端只检索到不同片段 | 调整Top-K数量，建议5~10；统一标签体系 |
| 向量检索变慢 | 全量暴力算余弦相似度 | 对向量做主成分压缩；后续可引入独立的向量库 |
5.2 踩过的几个大坑
第一个坑是FTS5和中文的“兼容性”。我一开始天真地以为FTS5开箱即用，结果用unicode61分词后，像“数据库选型”这种词被切得稀碎，存进去和查出来的对齐方式完全对不上，导致很多关键词明明存在却检索不到。后来我改用jieba先分词，把分词后的词序列存进FTS5索引，检索时也走同样的分词流程，问题才解决。如果你也在做中文检索，这块建议提前留出调试时间，别等上线了才发现在分词上栽跟头。
第二个坑是并发写入导致记忆静默丢失。有一次我用两个客户端同时让它们更新同一份技术方案，结果后写的覆盖了先写的，里面有几条重要约定消失了。排查之后就是因为我当初直接UPDATE没有版本控制。后来我把version字段加上，更新时带上IF条件：只有版本号匹配才更新。自那以后就再没发生静默覆盖的问题。
第三个坑是“什么都存”。刚开始用MemTether时，我抱着多多益善的心态，什么对话都往里面写，结果三天后检索返回的前几条全是废话和过期状态。后来我下决心做了两件事：一是给type定义清楚，只有有价值的事实和决策才用fact；二是写了一个每周清理脚本，把零散的summary合并成更高层的条目。核心原则是：记忆系统的价值不在于存得多，而在于记得准。
5.3 关于开源和实际使用的小建议
最后聊几个和项目本身无关、但很实用的心得。
第一，标签体系一定要提前建。我在项目初始阶段没太在意标签，全部靠关键词检索，效果只能说一般。后来给项目定了统一的标签规则，比如project:alpha代表项目、tech:database代表技术栈，检索时先拿标签过滤一轮，准确率直接上了个大台阶。tags这个字段是我最开始设计时觉得最可有可无的，现在反而是最高频的过滤条件。
第二，README就是产品。这个项目在GitHub上开源、用MIT协议发布，但我发现用户愿不愿意尝试，往往取决于README写得够不够直观。我后来狠狠花了一晚上把“它解决什么问题”“怎么快速跑起来”“怎么接入常见客户端”写清楚，star和issue的质量立刻不一样了。开源工具的第一批用户不是因为功能多来的，是因为“我能不能在5分钟内跑起来”来的。
第三，别急着加功能。我的第一版只有写入和关键词搜索两个接口，照样解决了我自己的问题。真正的痛点在于稳定好用，而不是功能炫技。有不少人问我为什么不直接做成浏览器插件，我解释说：插件的自由度太小，一个独立记忆层以后能对接的客户端是无限的，这个定位在初期已经验证是对的。
如果你也在多个AI客户端之间切来切去，体会过那种每次都要重新讲一遍背景的感觉，我建议你试一下这个思路，哪怕不直接用MemTether，也可以自己搭一套记忆服务。核心就一句话：让记忆属于你自己，而不是属于某个AI客户端。这个方向我后续还会继续迭代，目前最想做的，是把记忆的遗忘和合并策略做得更聪明，让工具真正像人一样“记重点”。
