资讯动态

逆向 Antigravity Conversation Fix:手工解析 protobuf varint 并重建 trajectorySummaries 索引的完整思路

发布时间:2026/10/15 17:02:54 来源:尧图企业网站定制
【免费下载链接】antigravity-conversation-fixFixes missing and unordered conversation history in Google Antigravity项目地址https://gitcode.com/gh_mirrors/an/antigravity-conversation-fix点击查看免费下载Antigravity Conversation Fix是一个专门修复 Google Antigravity 中「对话历史消失、顺序错乱、标题变成占位符」问题的免费开源工具。本文从逆向视角完整拆解它的设计思路不依赖官方 SDK只靠几行protobuf varint解码代码就能读懂并重写 Antigravity 侧边栏背后的trajectorySummaries索引数据库把所有聊天记录「找回来、排好序、配好名」。一、问题定位会话历史到底存在哪里逆向的第一步是回答「数据藏在哪里」。Antigravity 把会话数据分两处存放这正是故障的根源数据位置形式会话本体~/.gemini/antigravity/conversations/各系统路径略有差异*.pb旧或*.db新文件侧边栏索引%APPDATA%\...\state.vscdbSQLiteItemTable中 key 为antigravityUnifiedStateSync.trajectorySummaries的一条记录关键发现索引坏了文件并没有坏。对话文件还静静躺在磁盘上只是 SQLite 里那条索引记录损坏或缺失导致侧边栏「看不见」它们。这条索引的 value 是一段base64 编码的 protobuf 字节流——没有 schema 文件、没有 proto 定义字段号全靠从二进制里「猜」出来。这就是为什么需要手工解析 varint。二、唯一的前置知识protobuf varint 怎么读整个逆向过程的基石只有一个机制varint可变长整数。protobuf 用每字节 7 个有效位存储整数最高位为 1 表示「后面还有」为 0 表示结束0xAC 0x02 → 0b00000010 0b10101100 → 值 300跨 2 个字节而每个字段的「门牌」tag 由公式编码tag (字段号 3) | 线类型。拆开只需两步field_num tag 3wire_type tag 7。rebuild_conversations.py 中的decode_varint只有 10 行这就是全部解码能力def decode_varint(data, pos): result, shift 0, 0 while pos len(data): b data[pos] result | (b 0x7F) shift if (b 0x80) 0: # 最高位为 0 → 结束 return result, pos 1 shift 7 pos 1 return result, pos有了 tag 和 wire_type就能按线类型「跳」过任何字段值参见 skip_protobuf_fieldwire type含义跳过方式0varint再解码一个 varint164 位定长前进 8 字节2长度前缀字符串/嵌套消息读长度前进该长度532 位定长前进 4 字节逆向技巧遇到不认识的字段不用懂语义直接按 wire type 跳过即可。未知字段可以安全忽略这保证了解码的健壮性。三、逐层拆解trajectorySummaries 的三层嵌套结构trajectorySummaries是一个典型的「套娃」protobuf。作者逆向出的结构如下第 1 层顶层流 └─ 字段 1wire 2可重复一个会话条目 └─ 第 2 层条目 ├─ 字段 1conversation_id字符串即 .pb 文件名 └─ 字段 2子消息 └─ 字段 1base64 字符串 ← 注意第二次 base64 └─ 第 3 层inner blob解码后的 protobuf ├─ 字段 1标题 ├─ 字段 3 / 7 / 10时间戳排序靠它 └─ 字段 9workspace 子消息含 file:/// 或 vscode-remote:// URI两个容易踩的坑双重 base64数据库里的 value 先 base64 解码一次第 3 层的 inner blob 又是被 base64 包了一层再塞进字符串字段里的。workspace 子消息内部字段 1 和字段 2 存的是同一个 URIbuild_workspace_field 中可以看到是刻意重复写入的逆向时取其一即可。这套结构的完整还原过程见 extract_existing_metadata——从 SQLite 取值、外层解码、逐条目切分、再逐层深入 inner blob全程没有用到任何 protobuf 库。四、重建管线五步把坏索引「修好」理解了结构修复方案就自然浮现——不是清空重来而是读旧、保元数据、补缺、写回。主流程在 main() 中共五步第 1 步全盘扫描会话文件多文件夹合并 去重_collect_all_conversations 同时扫描antigravity-ide、antigravity、antigravity-backup三个文件夹兼容.pbprotobuf与.dbSQLite两种格式跳过.db-shm/.db-wal日志文件并按 conversation_id 去重新文件夹优先。随后按文件修改时间从新到旧排序——侧边栏的顺序就此确定。第 2 步抢救旧索引里的元数据幂等的核心重跑工具不能把已有信息洗掉。extract_existing_metadata 把旧索引完整解析一遍保存两样东西真实标题排除Conversation (...)这类占位标题后收集数据库里的规范标题inner blob 原始字节workspace、时间戳、工具状态全都藏在这里原样留用。多数据库时「先到先得」extract_existing_metadata_from_paths防止陈旧数据覆盖。第 3 步标题三级优先策略resolve_title 按优先级取名输出时用标记区分来源优先级来源标记1数据库已有标题重跑时保留[~]preserved2brain artifact.md文件的 Markdown 一级标题get_title_from_brain[]brain3兜底Conversation (日期) 短ID日期取自.pb文件修改时间[?]fallback第 4 步外科手术式改写 inner blob这是整个工具最精妙的部分。新条目由 build_trajectory_entry 构建核心思想是只动需要动的字段其余字节原样保留换标题用 strip_field_from_protobuf 精确剥离 inner blob 中的字段 1旧标题再在头部拼入新的字段 1。其余字段包括逆向时没搞懂的字段毫发无损——比「完整序列化再重写」安全得多补 workspace若旧数据没有字段 9则用 build_workspace_field 注入URI 来自 brain 文件扫描infer_workspace_from_brain优先用 Antigravity 自己的workspaceStorage数据做前缀匹配匹配不上再退化为路径深度启发式补时间戳缺失排序依据的条目用 build_timestamp_fields 把文件修改时间注入字段 3、7、10保证「最新在前」排序成立。第 5 步先备份再写回所有数据库write_index_to_database 的防御式设计值得所有「改用户数据」的工具借鉴先把当前索引值写入带时间戳的trajectorySummaries_backup_*.txt备份目录选择 还专门处理了 PyInstaller 临时解压目录导致备份「悄悄消失」的坑备份写失败就拒绝修改数据库——没有退路宁可不修时间戳化的备份文件名保证多次运行不会互相覆盖始终保留「工具介入前」的原始状态可回滚v1.06 起会把重建索引写入所有发现的state.vscdb同时覆盖 Agent 与 IDE 两种安装形态。五、亲手跑一遍从克隆到修复想复现这套逆向成果操作成本极低详见 README.md# 1. 获取源码 git clone https://gitcode.com/gh_mirrors/an/antigravity-conversation-fix cd antigravity-conversation-fix # 2. 彻底关闭 Antigravity 后运行需 Python 3.7零第三方依赖 python3 rebuild_conversations.pyWindows 用户也可直接双击 run.bat它会自动调用同目录下的 rebuild_conversations.py或从 Releases 下载Antigravity_Conversation_Fix.exe免安装运行。运行输出中的图例速查标记含义[]标题来自 brain artifact[~]标题从旧索引中保留[?]兜底标题无可参考来源[WS]workspace 元数据已保留或恢复⚠️务必先完全退出 Antigravity应用退出时可能会把内存中的旧索引写回数据库覆盖你的修复。脚本也内置了进程检测并会主动警告。六、总结这套逆向思路能迁移到哪里Antigravity Conversation Fix 的价值不止于「修一个工具」它示范了一条可复用的二进制索引修复方法论定位存储分清「数据本体」与「索引」确认哪一层坏了最小解码器十行 varint 四类型 wire type 跳过表就能盲解析任意 protobuf保留式重写逐字段剥离与注入而不是全量反序列化未知字段天然安全可回滚的写入先备份、备份失败即中止、幂等可重跑。下次再遇到「应用索引坏了但原始文件还在」的场景——无论是聊天记录、历史列表还是元数据索引——这套「varint 外科手术式改字节」的思路都可以直接搬过去。赞分享【免费下载链接】antigravity-conversation-fixFixes missing and unordered conversation history in Google Antigravity项目地址https://gitcode.com/gh_mirrors/an/antigravity-conversation-fix点击查看免费下载相关推荐Hoppscotch免费开源的 API 测试工具3 种使用形态从单条请求到团队协作Hoppscotch免费开源的 API 测试工具3 种使用形态从单条请求到团队协作 日常联调后端接口最磨人的往往是来回切换改个参数要翻回文档换组 T开发工具接口测试前端后端CLILoki 中的高性能 Protobuf Varint 编解码dennwc/varint 优化实现全解析Loki 中的高性能 Protobuf Varint 编解码dennwc/varint 优化实现全解析 导读 本文深入剖析当前 Loki 仓库中依赖的 git可观测性日志分析后端微服务对象存储云原生Go 高性能 Protobuf Varint 编解码dennwc/varint 的原理与在 Cortex 存储链路中的应用Go 高性能 Protobuf Varint 编解码dennwc/varint 的原理与在 Cortex 存储链路中的应用 本篇技术指南围绕当前仓库中 ven可观测性时序数据库后端指标监控创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑