特性请求: 对多代理情景的并行写手支持

□ 问题

Memvid的单文件架构对于AI代理内存来说是完美的,但目前对单笔写作机的局限仅为多代理系统制造了挑战,其中多会话需要写入同一份内存文件.

QQ 使用案例:AI代理的大脑项目

我们正在为AI代理建立一个持久的记忆系统(OpenClaw),其中:

1. ** 主代理会议**(Cass)撰写回忆、思考和见解
2. ** 附属届会** (为任务而生)也产生记忆
3. 背景过程(梦想、合并)定期编写
4. ** 所有会话需要从同一个内存文件中读出**

目前,我们需要实施中央写作服务或写出队列系统,这增加了复杂性并打倒了梅姆维德的"零基础设施"价值命题.

□ 建议的解决办法

将支持 ** 当前作者 ** 添加到单个文件中 。 可通过下列方式予以实施:

QQ 选项A: 基于文件的锁定

• 作者活动时的文件
• 并行访问的等待/重试逻辑
• 获得/释放原子锁

备选B:咨询锁定(锁定/fcntl)

• OS级文件锁定
• 跨平台(Linux、macOS、Windows)
• 在SQLite和其他嵌入式数据库中已经进行了战斗测试

备选 C: WAL 合并进程

• 多个WAL文件(每个作者一个会话)
• 背景合并进程将它们结合在一起
• 类似SQLite处理并行写法

QQ 选项 D: 撰写进程(构建)

• 管理写作的可选轻量级守护进程
• 作为背景进程运行
• 通过 IPC 发送会话( Unix socket / named pione)
• Memvid SDK 自动处理连接

∮为什么这很重要∮

多种代理系统正在成为规范:

• ** LangGraph** 多工人的特工
• AutoGen 多代理人对话
• ** OpenClaw** 主干件+副干件建筑
• CrewAI 团队工作流程

所有这些将受益于多个代理可以同时写入的共享记忆层.

□ 当前的工作

我们正在考虑PostgreSQL + Memvid混合:

• PostgreSQL 手柄并行写作
• 定期为时间旅行制作记忆快照

但是这失去了梅姆维德的单文件方法的优雅,引入了我们宁愿避免的复杂性.

□ 请求

请考虑在未来版本中增加并行的写作支持. 即使是简单的文件锁定机制,也足以使许多案件使用。 "单一过程,单一写作"的束缚,是阻止我们采用"Memvid"作为主要记忆底物的唯一因素.

谢谢你为AI记忆创造了如此优雅的解决方案!