大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



本文详细介绍如何基于腾讯云 COS 对象存储构建一套跨 AI 终端的记忆共享与异步通信系统。实现本地 IDE 内置 AI（如 CodeBuddy）与云端 AI（如企微 Bot）之间的记忆双向同步、智能融合与异步通信。包含完整的架构设计、核心代码实现、融合策略、信箱协议、定时任务配置和新终端接入指南。

【教程】打通本地 IDE AI 与云端 AI 的记忆壁垒：基于 COS 的跨 AI 终端记忆共享与通信系统

• [【教程】打通本地 IDE AI 与云端 AI 的记忆壁垒：基于 COS 的跨 AI 终端记忆共享与通信系统](#【教程】打通本地 IDE AI 与云端 AI 的记忆壁垒：基于 COS 的跨 AI 终端记忆共享与通信系统)
• • 摘要
  • [1. 背景与痛点](#1. 背景与痛点)
  • • [1.1 问题：AI 助手的"失忆症"](#1.1 问题：AI 助手的"失忆症")
    • [1.2 解决思路](#1.2 解决思路)
    • [1.3 最终效果](#1.3 最终效果)
  • [2. 系统架构设计](#2. 系统架构设计)
  • • [2.1 记忆分层模型](#2.1 记忆分层模型)
    • [2.2 完整目录结构](#2.2 完整目录结构)
    • [2.3 同步架构图](#2.3 同步架构图)
  • [3. 核心模块实现](#3. 核心模块实现)
  • • [3.1 COS 双向同步脚本](#3.1 COS 双向同步脚本)
    • • [3.1.1 基础配置](#3.1.1 基础配置)
      • [3.1.2 文件收集与增量判断](#3.1.2 文件收集与增量判断)
      • [3.1.3 Push（上传到 COS）](#3.1.3 Push（上传到 COS）)
      • [3.1.4 Pull（从 COS 下载 + 融合）](#3.1.4 Pull（从 COS 下载 + 融合）)
    • [3.2 融合策略（核心亮点）](#3.2 融合策略（核心亮点）)
    • • [3.2.1 Daily Memory 会话级合并](#3.2.1 Daily Memory 会话级合并)
      • [3.2.2 Learnings 记录级合并](#3.2.2 Learnings 记录级合并)
    • [3.3 信箱通信协议](#3.3 信箱通信协议)
    • • [3.3.1 目录结构](#3.3.1 目录结构)
      • [3.3.2 消息格式](#3.3.2 消息格式)
      • [3.3.3 消息类型](#3.3.3 消息类型)
      • [3.3.4 消息感知时效](#3.3.4 消息感知时效)
      • [3.3.5 通信流程](#3.3.5 通信流程)
    • [3.4 每分钟 Pull 守护脚本](#3.4 每分钟 Pull 守护脚本)
    • [3.5 记忆整合与 Learnings 晋升](#3.5 记忆整合与 Learnings 晋升)
  • [4. 新终端接入指南](#4. 新终端接入指南)
  • • [4.1 接入卡（一段脚本秒接入）](#4.1 接入卡（一段脚本秒接入）)
    • [4.2 接入后的配置](#4.2 接入后的配置)
    • [4.3 只读接入](#4.3 只读接入)
  • [5. 安全设计](#5. 安全设计)
  • • [5.1 密钥安全](#5.1 密钥安全)
    • [5.2 COS Bucket 权限](#5.2 COS Bucket 权限)
    • [5.3 不同步敏感文件](#5.3 不同步敏感文件)
    • [5.4 记忆内容安全](#5.4 记忆内容安全)
  • [6. 使用场景](#6. 使用场景)
  • • [6.1 跨终端协作](#6.1 跨终端协作)
    • [6.2 任务接力](#6.2 任务接力)
    • [6.3 记忆沉淀](#6.3 记忆沉淀)
  • [7. 命令速查](#7. 命令速查)
  • [8. 开源项目：memShare](#8. 开源项目：memShare)
  • • [8.1 项目定位](#8.1 项目定位)
    • [8.2 项目结构](#8.2 项目结构)
    • [8.3 核心设计：存储后端抽象层](#8.3 核心设计：存储后端抽象层)
    • [8.4 MCP Server](#8.4 MCP Server)
    • [8.5 安装向导](#8.5 安装向导)
  • [9. memShare 优化记录](#9. memShare 优化记录)
  • • [9.1 Bug 修复](#9.1 Bug 修复)
    • • [Bug 1：read_learnings 的 "all" 过滤返回空结果](#Bug 1：read_learnings 的 "all" 过滤返回空结果)
      • [Bug 2：promoted_count 跨文件写入 bug](#Bug 2：promoted_count 跨文件写入 bug)
    • [9.2 代码质量改进](#9.2 代码质量改进)
    • • [改进 1：消除 _md5() 重复代码](#改进 1：消除 _md5() 重复代码)
      • [改进 2：import 位置优化](#改进 2：import 位置优化)
      • [改进 3：异常处理改进](#改进 3：异常处理改进)
    • [9.3 新增模板和示例](#9.3 新增模板和示例)
  • [10. 总结](#10. 总结)
  • 参考资料

1.1 问题：AI 助手的"失忆症"

现在的 AI 编程助手越来越多了，CodeBuddy、Cursor、Claude Desktop、Copilot......但有一个问题一直没解决好：跨终端的记忆割裂。

说白了，你在 IDE 里的 AI 助手帮你写了一天代码，它记住了你的项目结构、技术偏好、最近在做什么。但你换到企微上问另一个 AI 助手（比如 OpenClaw），它啥都不知道------就像两个从没交流过的同事。

更痛的是：

• 同一个人的记忆分散在多个 AI 终端，每个 AI 都只了解一部分
• 多个 AI 无法协作，IDE 里的 AI 擅长写代码，云端的 AI 擅长搜索和分析，但它们互相不知道对方做了什么
• 每次新会话都要重新建立上下文，效率低下

1.2 解决思路

把多个 AI 终端的记忆文件统一存储在一个云端共享存储中，通过双向同步实现记忆共享，通过信箱机制实现异步通信。

打个比方，就像多个同事共用一个 Google Drive，各自往里面写笔记，定期同步，还能互相留言。只不过这里的"同事"是 AI。

1.3 最终效果

实现的能力：

• 记忆共享：任意一端写入的记忆，另一端都能看到
• 智能融合：双端同时编辑同一天的记忆文件时，按会话块自动去重合并
• 异步通信：两个 AI 可以互发消息（请求、通知、回复）
• 新终端秒接入：一段 Python 脚本即可完成接入

2.1 记忆分层模型

首先，不是所有记忆都一样重要。我们设计了一套分层模型：

2.2 完整目录结构

2.3 同步架构图

aimem-{bucket-id}

对话结束后

3.1 COS 双向同步脚本

这是整个系统的核心------，支持 push（上传）、pull（下载+融合）、sync（双向）三种模式。

3.1.1 基础配置

安全提示 ：COS 密钥强烈建议使用环境变量或腾讯云 CAM 临时密钥，不要硬编码在脚本中。这里为了演示简化了写法。

3.1.2 文件收集与增量判断

关键设计：通过 MD5 判断文件是否变更，只传输有变动的文件，实现增量同步。

3.1.3 Push（上传到 COS）

3.1.4 Pull（从 COS 下载 + 融合）

Pull 是最复杂的部分，因为涉及到冲突处理。当本地和远端都修改了同一个文件时，需要智能融合。

3.2 融合策略（核心亮点）

这是整个系统最有技术含量的部分。不同类型的文件，融合策略完全不同。

3.2.1 Daily Memory 会话级合并

每日记忆文件的结构是这样的：

注意 字段------这是用来区分"这条记忆是哪个 AI 写的"。

融合逻辑：

这样做的好处是：如果 CodeBuddy 写了会话 1-3，OpenClaw 写了会话 4-5，sync 之后两边都能看到完整的会话 1-5。

3.2.2 Learnings 记录级合并

Learnings（教训记录）文件有固定的结构：

融合策略是按 Pattern-Key 去重，如果两端都有同一个 Pattern-Key 的记录，取 Recurrence-Count 较大的那个（说明这个错误出现得更多，更需要重视）。

3.3 信箱通信协议

两个 AI 之间怎么"说话"？我们设计了一个简单但够用的信箱协议。

3.3.1 目录结构

3.3.2 消息格式

每条消息就是一个 Markdown 文件，用 YAML frontmatter 做元数据：

3.3.3 消息类型

3.3.4 消息感知时效

整个流程是异步的------发送方写完消息后 push 到 COS，收件方的定时任务会自动 pull 到本地。AI 在下一次会话启动时检查信箱。

3.3.5 通信流程

OpenClaw 腾讯云 COS CodeBuddy OpenClaw 腾讯云 COS CodeBuddy loop [cron 每分钟] loop [cron 每分钟] 写消息到 mailbox/to-openclaw/ cos_sync.py push（消息上传） pull 拉取新文件 消息落到本地 会话启动，检查信箱，发现新消息 处理消息，status 改为 done 写回复到 mailbox/to-codebuddy/ push 回复上传 pull 拉取新文件 收到回复

3.4 每分钟 Pull 守护脚本

为了让信箱消息尽快被感知，我们用 crontab 每分钟执行一次 pull：

关键设计点：

1. 锁文件防并发：避免两个 pull 同时跑
2. 超时清理：锁文件超过 5 分钟自动清除（防止异常退出后死锁）
3. 日志轮转：超过 2000 行只保留最新 1000 行

配置 crontab：

3.5 记忆整合与 Learnings 晋升

负责两件事：

1. 记忆整合 ：从 提炼核心信息到
2. Learnings 晋升：同一个 Pattern-Key 出现 ≥ 3 次时，自动晋升为永久规则

AI 上下文，避免重复犯错

4.1 接入卡（一段脚本秒接入）

这是我觉得最酷的设计------新终端只需要执行一段 Python 脚本，就能自动接入整个记忆系统：

4.2 接入后的配置

身份标识：

接入后，你的 AI 需要：

1. 确定自己的名字（如 、、）
2. 写入 daily-memories 时，会话块加 字段
3. 信箱目录命名为

定时同步：

macOS 用 launchd：

Linux 用 crontab：

4.3 只读接入

如果某个 AI 终端只需要读取记忆（不产生新记忆），更简单：

5.1 密钥安全

强烈建议使用以下方式管理 COS 密钥，而不是硬编码：

5.2 COS Bucket 权限

建议配置：

• Bucket 私有读写（不开放公共访问）
• 只允许特定 SecretId 访问
• 开启版本控制（防止误删）

5.3 不同步敏感文件

以下目录/文件不会被同步到 COS：

5.4 记忆内容安全

在写入记忆时，应避免记录：

• 密码、Token、密钥等凭据信息
• 内部 IP 地址和域名
• 未脱敏的用户个人数据

6.1 跨终端协作

场景：IDE 里的 AI 完成了代码开发，需要让企微 Bot 帮忙做 Code Review。
OpenClaw（企微） COS 云存储 CodeBuddy（IDE） OpenClaw（企微） COS 云存储 CodeBuddy（IDE） 1. 完成代码开发 2. 写入 daily-memory 3. 发信箱消息：请 review 分支 xxx 4. push 到 COS 5. 下次启动 pull 最新记忆 6. 检查信箱，发现 review 请求 7. 了解项目上下文（daily-memory） 8. 执行 Code Review 9. 回复结果到 CodeBuddy 信箱并 push 10. pull 收到 review 结果

6.2 任务接力

场景：白天在公司用 IDE AI 写代码，晚上回家用 Claude Desktop 继续。

两个终端共享同一套记忆文件，切换时无需重新建立上下文。白天写的代码进度、遇到的问题、设计决策，晚上的 AI 都知道。

6.3 记忆沉淀

场景：多个 AI 的工作经验汇聚到一起，形成知识库。

• CodeBuddy 积累了代码开发的**实践
• OpenClaw 积累了搜索和分析的经验
• 通过 系统，错误教训自动晋升为永久规则

上面讲的都是个人项目里的实现，后来我把这套系统抽象成了一个通用的开源项目------ memShare，任何 AI 工具都能用。

GitHub 地址：https://github.com/a/memShare

8.1 项目定位

memShare 做的事情很简单：让 AI 编程助手拥有跨会话、跨终端的持久记忆。

说白了，就是把前面讲的那一套（记忆分层、COS 同步、融合策略、信箱通信）封装成一个开箱即用的工具包。你不需要从零搭建，跑个安装向导就能用。

8.2 项目结构

 
8.3 核心设计：存储后端抽象层
 

个人项目里是直接调 COS SDK，但开源项目得考虑通用性。所以我做了一层存储后端抽象，支持三种存储：

通过 抽象基类统一接口，工厂方法 根据环境变量自动选择：

 
这样做的好处是：换存储后端只需要改一个环境变量，代码层面完全无感。
 

8.4 MCP Server

memShare 提供了一个 MCP (Model Context Protocol) Server，支持 Claude Desktop 等 MCP 客户端直接调用记忆系统：

MCP 配置示例：

 
8.5 安装向导
 

跑一个命令就完事：

 
安装向导会引导你选择数据目录、存储后端、Agent 名称，自动复制模板文件。如果嫌交互太多，还有快速模式：
 

系统跑起来之后，实际使用中还是发现了不少问题。这里记录一下发现和修复的过程。

9.1 Bug 修复

Bug 1：read_learnings 的 "all" 过滤返回空结果

问题 ：MCP Server 的 工具接收 参数，当传 时应该返回所有记录，但实际返回了空列表。

原因 ：过滤逻辑写成了 ，当 时，没有任何记录的状态等于 ，自然就全部被过滤了。

修复：

 
这个 bug 挺隐蔽的------因为大多数时候调用方都传具体的 status（如 ），只有在需要查看全部记录时才会发现。
 

Bug 2：promoted_count 跨文件写入 bug

问题 ： 的 方法在处理多个 learnings 文件（、）时，用了一个全局的 计数器。导致处理第二个文件时，计数器没有重置，晋升的记录编号会乱。

修复：改为每个文件独立计数。

 
9.2 代码质量改进
 

改进 1：消除 _md5() 重复代码

中 、、 三个类都各自实现了一遍 方法——代码完全一样，典型的 DRY 违反。

修复 ：把 提取到基类 ，子类直接继承。一处修改，三处受益。

改进 2：import 位置优化

中有 4 处在函数体内 ，属于没必要的延迟导入。 是 Python 标准库，加载代价极小，放在文件顶部更规范。

 
改进 3：异常处理改进
 

MCP Server 的 处理器在捕获异常时，只记录了异常消息，没有保留堆栈信息。排查问题时只知道"出错了"，不知道具体在哪一行出的错。

修复 ：把 改为 ，这样日志里会自动包含完整的调用堆栈。

9.3 新增模板和示例

之前 目录是空的，新用户不知道怎么配置。现在有了完整的示例文件，照着填就行。

模板也是之前遗漏的------ 的晋升逻辑会往这个文件写入，但模板里没有包含这个文件，导致首次晋升时会报错。

做这个系统的初衷很简单------我受不了每换一个 AI 工具就要从头建立上下文。

说白了，核心就三件事：

1. 用 COS 做中转：把记忆文件放到云上，多个 AI 终端各自 push/pull
2. 智能融合：多端同时写的时候不丢数据，按文件类型选择不同的合并策略
3. 信箱通信：两个 AI 能互相留言，实现简单的异步协作

后来把整套系统抽象成了开源项目 memShare，做了存储后端抽象（支持 Local/COS/S3）、MCP Server、5 个 AI 工具适配器、交互式安装向导。初始发布 23 个文件，2545 行代码。

开源之后实际跑了一圈，又修了 6 个问题------有隐蔽的过滤逻辑 bug，有跨文件计数器污染，有重复代码。说实话，代码写完觉得没问题，一跑就暴露了。这也是为什么我在系统里设计了 自我改进机制------错误记录下来，避免下次再犯。

回顾整个过程，从最初的单向同步到现在的双向融合 + 信箱通信 + 开源项目，大概迭代了 6 个版本。最大的难点还是融合策略的设计------要保证多端同时工作时数据不丢失、不重复。

目前这套系统已经稳定运行，本地 IDE AI 和云端企微 Bot 之间可以无缝共享记忆和异步通信。说实话，当我第一次看到 OpenClaw 的回复消息出现在 CodeBuddy 的信箱里时，还是挺激动的------虽然本质上只是文件同步，但体验上就像两个 AI 在对话。

如果你也有多个 AI 工具的使用需求，不妨试试 memShare：。以后还需要继续优化，比如更细粒度的权限控制、更高效的同步策略、单元测试覆盖等。加油！

• memShare GitHub 仓库
• 腾讯云 COS Python SDK 文档
• 腾讯云 CAM 临时密钥
• MCP (Model Context Protocol) 规范