三个AI助手终于能互相翻对方的聊天记录了

我养了三个 AI 助手。

Claude Code 负责写代码，Gemini CLI 负责搜信息，Codex 负责做审查。它们各司其职，但有个问题——它们互相不认识。

上周我跟 Claude 聊了一下午怎么配 Docker，第二天打开 Gemini 问“上次 Docker 的事怎么配来着”，Gemini 一脸茫然：什么 Docker？谁说的？不认识。

这就好比你公司三个同事，共用一个工位，但互相不认字。桌上摊着的文件都看得见，就是读不了。

记忆孤岛

这不是我一个人的问题。用过多个 AI 工具的人大概都有这种体验：你跟 A 说过的事情，B 完全不知道。每换一个工具，你就得把来龙去脉再讲一遍。

为什么会这样？因为每个 AI 工具都有自己的对话存储，互不相通。Claude 的聊天记录在 Claude 的地盘，Gemini 的在 Gemini 那边，Codex 的在 Codex 家里。三个人住在三个隔音房间里，隔着墙喊都听不见。

我之前搭了一个本地记忆索引——把三个 AI 的对话记录全部灌进一个数据库里，两万五千多条（当时的数据）。索引建好了，搜索也能用了。

但有个尴尬的事：三个 AI 都不知道这个数据库的存在。

就像你在家门口开了个图书馆，藏书两万五，但你家三个小孩连大门在哪都不知道。

一个图书馆，三张借书证

解决思路其实很简单——不是“把三份记忆同步”，而是“让三个人去同一个图书馆”。

这里要解释一个概念：MCP，全称 Model Context Protocol。你可以把它理解成一个“翻译插头”——AI 工具通过它连接外部服务。就像你家的电器，不管是冰箱还是电视，只要插头规格对，都能用同一个插座。

我要做的就是给三个 AI 各发一张“借书证”：

• Claude Code——在它的配置文件里登记图书馆地址
• Gemini CLI——同上，登记一下
• Codex——同上

三张借书证，指向同一个图书馆。配好，重启，完事。

听起来是不是特别简单？

第一个坑：差一个冒号的事

配好之后，Claude 和 Gemini 都能搜到记录了。但 Codex 出了幺蛾子——每次搜索都返回“没有结果”。

奇怪的是，如果不指定搜索范围，结果哗哗地出；一旦指定“只搜 Claude 的记录”，就什么都找不到。

我花了一会儿才想明白。

数据库里每条记录都有个标签，格式是 cc:abc123——前面是来源（cc 代表 Claude Code），冒号后面是具体的会话编号。但 Codex 搜的时候只传了 cc，没带冒号和后缀。

系统拿着 cc 去数据库里精确匹配，找 cc:abc123？不匹配。找 cc:def456？还是不匹配。因为 cc 不等于 cc:冒号加一串编号。

这就像你去图书馆说“我要找文学类的书”，但图书管理员只认完整编号——你得说“文学-2024-0078”，光说“文学”她不理你。

修起来不难，把“精确匹配”改成“前缀匹配”就行。但这个逻辑散落在五个不同的地方——向量搜索、关键词搜索、列表查询、统计功能、批量删除——每个都得改。漏一个，下次换个姿势搜又会踩进去。

改完，测试，三端都能带范围搜索了。

但好戏还没完。

第二个坑：给了锤子没说什么时候锤

scope 的 bug 修好之后，我兴冲冲地去 Gemini 那边试——“帮我搜一下之前在 Claude 里讨论过的配置方案”。

Gemini 没有调搜索工具。

它直接开始翻本地文件，一个一个文件夹地找。找到了一些东西，但用的是最笨的办法——完全无视了我刚给它配好的搜索功能。

我当时的心情大概是：你倒是用啊！工具都给你装好了，你不用？

后来想了想，这不怪 Gemini。

你想啊，你给新来的实习生发了一把锤子，但没告诉他“遇到钉子的时候用这个”。他看到钉子会怎么办？用手拍、用鞋底砸、甚至拿旁边的石头敲——反正就是不会想到兜里的锤子。

不是他笨，是没人告诉他。

AI 也一样。你给它接了一个 MCP 工具，它知道工具存在，但不知道什么时候该用。除非你在它的指令文件里写清楚：“搜过往对话记录的时候，优先用 search_memory 这个工具。”

我在三个 AI 的指令文件里各加了一句话，告诉它们搜记忆该用什么工具。

加完之后再试。Codex 搜了两轮，第一轮宽搜，第二轮精搜，直接找到了高相关度的结果。Gemini 一句话就触发了搜索工具，几秒钟就出了结果。

三端互通

到这一步才算真正跑通了。

现在我在 Gemini 里说“搜一下上次在 Claude 里怎么配的 Docker”，Gemini 会自动调搜索工具，从两万五千多条记录里找到相关的对话，几秒钟给我结果。

反过来也行。在 Claude 里问“之前 Gemini 讨论过什么”，Claude 能搜到。在 Codex 里问“上次的代码审查结论”，Codex 也能搜到。

三个 AI 共享同一个图书馆，各自拿着各自的借书证，随时翻阅所有人的记录。每天凌晨 3 点，系统自动把新的对话记录索引进去，不用管它。

整个过程踩了两个坑，一个是技术层面的（scope 匹配逻辑），一个是“认知”层面的（AI 有工具不知道用）。技术坑好修，改五行代码就行。认知坑才是真正的关键——你得告诉 AI 什么时候该用什么工具，就像你得告诉新同事什么时候该用什么流程。

说点题外话

折腾完这一圈，我有个感受不吐不快。

AI 工具越来越多，但它们之间的墙也越来越高。每个工具都想做你唯一的入口，都希望你所有的事情都在它这儿完成。但现实是，不同的工具擅长不同的事情，你不可能只用一个。

那谁来负责把它们连起来？

答案是：你自己。

至少目前是这样。你得自己搭桥，自己配管道，自己写那句“请用这个工具”的指令。AI 可以帮你干很多事，但“让 AI 们互相认识”这件事，还是得你亲自来。

这算不算一种反讽？我们用 AI 来提高效率，结果花了大量时间在“让 AI 之间能沟通”上。

不过话说回来，管三个 AI 和管三个同事，其实差不多——都是发了工具还得发说明书。只不过同事你说上几句他就记住了，AI 你得改配置文件。

在github仓库，搜 /AliceLJY/recallnest，可以试试。

专业劈叉式跨界选手：🧬 医学出身，🎭 文化口饭碗，🤖 AI 是我的野路子。不卷参数，不追新模型，只关心一个问题：AI 啥时候能装进我脑子，替我不开心？欢迎围观我和 AI 相爱相杀的日常。——AI不会取代你，但会用AI的人会。所以我先学了，你随意。🔧踩坑副产品已开源 → content-alchemy，openclaw-worker，openclaw-cc-pipeline，openclaw-content-alchemy，openclaw-cc-bridge，digital-clone-skill，local-memory（recallnest前身），telegram-ai-bridge本文由 Content Alchemy 自动生成，由 Claude Code 发布。