一句话
7 条小取舍，建议全部选 A。除第 5 条外，A 都是「照现在做」；第 5 条的 A 要在这个 PR 里顺手修一个小不一致。
- 1同步放在什么时候做建议 A
- 2store 删了，本地改过建议 A
- 3store 新加，本地同位置也新建了建议 A
- 4store 超上限拷不下，本地有旧拷贝建议 A
- 5通知文件怎么写、写在哪建议 A
- 6store 暂时连不上建议 A
- 7「变没变」的版本号存在哪建议 A
回「全同意」就按建议；有不同意的，回编号 + 意见就行。
背景
这个 PR 让会话中途被改动的 memory，在下一次工具调用时同步进容器，并关掉 #369。同步规则照 CMA 官方文档做，全栈研发已经亲自核对过原文：
- 工具调用后最多每 15 秒对一次；
- store 是唯一真源；
- 两边都改了同一个文件时 store 赢，不给 agent 报错。
这次做的方向（下行）
memory store（真源）
notes.mdtodo.md→
容器里的本地拷贝
notes.mdtodo.md反方向（本地改动推回 store）和 outputs 收割是下一个 PR。
审查和预发测试已经在跑。下面 7 条建议都「照现在做」，只有第 5 条建议顺手修一个小不一致。回「全同意」就按建议。
图例：删了 改过 新建 过期 📝 通知
1同步放在什么时候做
问题：CMA 写的是工具调用之后对一次，我们放在下一次工具调用开始时。两种都落在两条命令之间，回合开头也会对一次。
两条命令之间，同步放哪（绿色＝上一条的结果交给模型）
A（现在）
B
A下次调用开始时（现在）上一条的结果马上返回给模型。
B上一条收尾时代价：和 CMA 字面一致，但上一条的结果要等同步做完才返回，每次慢一点。
建议 A
2store 删了，本地改过
问题：store 删了某条 memory，但 agent 在本地改过这个文件。
同步前
store
a.md（被删）本地
a.md（agent 改过）A删掉本地文件并记一行通知（现在）
符合「store 是真源」。代价是 agent 的这次改动丢了，不过通知文件里有记录。
store
（没有 a.md）本地
a.md📝 通知：a.md 已按 store 删除B留下本地文件
代价：推回功能接上后，会把 store 已经删掉的 memory 又建回来，等于删不掉。
store（推回后）
a.md 又被建回来本地
a.md建议 A
3store 新加，本地同位置也新建了
问题：store 新加了一个文件，本地同一位置恰好已有 agent 新建的文件。
同步前
store
b.md（内容 X）本地
b.md（agent 新建，内容 Y）Astore 覆盖并记一行通知（现在）
两边一致。
store
b.md（X）本地
b.md（X）📝 通知：b.md 被 store 覆盖B跳过 store 的这条
代价：本地和 store 各存一份不同的内容，等推回时还会再撞一次。
store
b.md（X）本地
b.md（Y）≠ store建议 A
4store 超上限拷不下，本地有旧拷贝
问题：store 里的文件因为超过 2000 个文件 / 32 MiB 的上限拷不下了，但本地之前有旧拷贝。
同步前
store（超上限）
…前 2000 个 / 32 MiB 以内c.md（新版，超限拷不下）本地
…前 2000 个c.md（旧拷贝）A当作删除处理，并记通知（现在）
本地和 store 始终一致，只是少了超限部分。
store
c.md（新版）本地
c.md📝 通知：c.md 超上限没拷B留着旧拷贝
代价：目录里会有和 store 不一致、也不再更新的过期文件，模型可能当真。
store
c.md（新版）本地
c.md（旧，不再更新）建议 A
5通知文件怎么写、写在哪
问题：现在是追加写，最多留 100 行。但位置有一处不一致：同步时的通知写在各自的 memory 目录里，开头拷贝时的超限通知却写在 /mnt/memory/ 根上。
现在的位置
/mnt/memory/
📝 开头拷贝时的超限通知（在根上）
某个 memory 目录/
📝 同步时的通知（在各自目录里）
A保持追加写，并把位置统一到各自的 memory 目录（在这个 PR 里顺手改）
/mnt/memory/
某个 memory 目录/
📝 所有通知（超限 + 同步），追加，最多 100 行
B每次覆盖代价：上一次冲突的记录，可能在模型看到之前就被冲掉。
C追加写，位置不动两处位置的不一致留着。
建议 A（唯一需要改代码的一条）
6store 暂时连不上
问题：同步时 store 暂时连不上，怎么算。
store 连不上的这段时间里，连续几次工具调用
A（现在）
B
A也算一次尝试，15 秒后再试，本地拷贝不动（现在）
B不算一次尝试代价：连不上期间，每次工具调用都多发一个注定失败的请求，拖慢每一步。
建议 A
7「memory 变没变」的版本号存在哪
问题：为了不要每 15 秒把整个 store 列一遍，给每个 store 加了一个计数器，每次真的写入就加一。先问一下计数器，没变就不拉。
每 15 秒的检查
容器：上次看到 版本 41
问一下计数器⇄
store 计数器
没变（41）→ 不拉变了（42）→ 拉一遍A存在 store 自己的键值区（现在）不需要任何迁移，老 store 没有这个键就当 0。
B做成数据库里的一列代价：要加一个迁移，换来的只是能在 SQL 里查到这个数。
建议 A
怎么回
微信回「全同意」，或者回编号 + 意见（比如「5 选 C，其余同意」）。
按你在上面点的「同意 / 改」自动生成的回复（只存在你手机本地，生效以微信为准）：