agy remote-control serve 启动后历史会话全丢了怎么搞

如果你在使用 agy cli 的远程控制模式，升级到 1.3.6 或 1.4.0 版本后发现侧边栏的历史记录消失了，或者新开的聊天在重启浏览器后不见了，这大概率不是你的配置问题，而是这个版本自带的两个 Bug 在搞鬼。简单来说，就是后台服务在重启后不读缓存，而且在执行后台任务时会把会话标题给抹掉。

为什么历史记录在重启后会消失

这个问题出在 agy remote-control serve 的启动逻辑上。当你启动这个 headless daemon 时，它其实会扫描 ~/.gemini/antigravity-cli/conversations/ 目录下的所有 .db 和 .pb 文件。
从日志里能看到，系统确实执行了 reconcileSummaries 操作，比如在 cli.log 中会显示同步了 49 条记录，并把它们缓存到了 conversation_summaries.db 里。但坑点在于，当 Web 或移动端客户端调用 GetAllCascadeTrajectories 或者 SearchConversations 这两个 RPC 接口来请求会话列表时，服务端只返回当前内存中（resident）的轨迹。
因为重启后内存是空的，即使磁盘缓存里有记录，只要你没有手动调用 LoadTrajectory 传入具体的 UUID，侧边栏就永远显示为空。除非你每次都手动加载，否则这些历史记录在界面上就是不可见的。

后台任务会导致会话标题被清空

除了启动时的加载问题，还有一个更隐蔽的「覆盖 Bug」。当你使用了 schedule 工具跑定时任务，或者有其他后台任务向 conversations/<cascadeId>.db 写入步骤时，fsnotify 文件监听器会触发 recomputeAndStore 重新计算摘要。
这里的逻辑缺陷是：它在重建摘要时只读取了 SQLite 的 .db 文件，完全忽略了 annotations/<cascadeId>.pbtxt 里的元数据。结果就是原本有标题的会话，在后台写入一次后，标题直接被重置为 ""（空字符串），来源也被强行改成了 CORTEX_TRAJECTORY_SOURCE_CLI。
如果你发现自己的聊天记录突然变成了无名会话，大概率就是被这个机制给覆盖了。

具体的排查与验证步骤

如果你想确认自己的环境是否触发了这两个问题，可以按照这个逻辑走一遍：

1. 检查本地路径 ~/.gemini/antigravity-cli/conversations/ 下是否存在 .db 文件。
2. 重启 agy remote-control serve 服务。
3. 观察 cli.log，寻找类似 reconcile checked 49 conversations, restored 0, cached 49 这种字样。如果看到了这个，说明数据在，但没被加载到内存。
4. 尝试通过接口调用 LoadTrajectory 并传入具体的 cascadeId。如果此时会话重新出现了，就证实了是 GetAllCascadeTrajectories 忽略了缓存的问题。

怎么看待这种同步机制

这种设计在分布式或远程控制场景下很常见，但处理得太粗糙。一个正常的流程应该是：请求列表 → 检查内存 → 内存没有则查缓存数据库 → 返回结果。而现在的逻辑直接跳过了缓存库，导致用户感知上像是数据丢失了。
至于标题被抹除的问题，本质上是读写不一致。把标题存在 .pbtxt 而把内容存在 .db，但在触发更新时只读 .db，这在架构上就是个漏洞。
对于开发者来说，在等待官方修复之前，最稳妥的办法是尽量减少对 schedule 工具的依赖，或者在重启服务后不要依赖侧边栏的自动加载。