可以支持最新的Antigravity么？

[xiongaox]

[study8677]

你好 @xiongaox，谢谢提出这个问题 🙏

我把 Antigravity 的本地数据看了一遍，结论是：目前还没法支持，瓶颈不在工作量，而是在「落盘加密」。 简单说明一下我看到的情况：

Antigravity 的对话怎么存？

• 每条对话存在 ~/.gemini/antigravity/conversations/<uuid>.pb
• 旁边的 ~/.gemini/antigravity/annotations/<uuid>.pbtxt 只有 last_user_view_time，不含标题
• VS Code 风格的 state.vscdb 里也没有对话标题（chat.ChatSessionStore.index 是空的）

为什么不能像 Claude Code / Codex / Cursor 那样改？
我抽样统计了 .pb 文件的字节频率：分布完全均匀（每个字节出现概率 ≈ 1/256），且首字节在不同文件之间也是均匀的——这是带认证密文（AES-GCM / ChaCha20-Poly1305 之类）的典型特征，每个文件用独立 nonce/IV。不是 protobuf 明文、也不是压缩。

也就是说：

• 没有钥匙，读不到对话内容，自然没法生成新标题；
• 旁边也没有任何明文的标题字段可以更新——侧边栏看到的标题，是 App 在内存里解密出来即时显示的，从来不落盘成明文。

密钥应该是由系统 keychain 托管的（macOS Keychain / Windows DPAPI），只有运行中的 Antigravity 进程能拿到。retitle 是个独立的小工具，绕过这层加密既不安全也不合规。

怎么办？
我已经把调查结果写进了仓库，给后续想接力的人留个清晰起点：

• README / README.zh-CN：新增了一行 Antigravity 的状态（🚫 阻塞）和「为什么还不支持 Antigravity？」小节
• ARCHITECTURE.md：完整记录了 on-disk 布局和加密推断
• CHANGELOG.md 也加了对应条目
• 提交：c256b1b

如果以下任一条件出现，我会立刻加 adapter：

1. Google 给 Antigravity 出一个官方的扩展/API 钩子，能列对话、读标题、改标题（最理想）；
2. 你或社区里有人知道密钥派生方式 / 明文格式，欢迎在这个 issue 下贴一下，或直接发 PR——适配器层就一个文件，四个方法（CONTRIBUTING.md）。

issue 我先留开着追这件事。再次感谢提出来！

[study8677]

所以有什么好办法吗 新版的 我们应该怎么做到能支持rename呢？

@xiongaox 已经 ✅ 支持了 —— commit 52cba23。

我之前一上来就在加密的 .pb 文件上撞墙,结论下太早。重看之后发现 Antigravity 其实把标题和正文分开存的:

内容	位置	状态
对话正文	~/.gemini/antigravity/conversations/<uuid>.pb	🔒 加密(密钥在 keychain)
对话标题	state.vscdb 的 antigravityUnifiedStateSync.trajectorySummaries	📖 明文

侧边栏读的是标题那一行,跟 Cursor 完全是同一个模式(SQLite + 结构化 blob)——不需要破密、不需要写 VS Code 扩展。

做法:

1. 我下载了官方 Antigravity 2.0.3 (darwin-arm) 的 DMG,挂载后从 jetskiAgent/main.js 里反编译出了 FileDescriptorProto,拿到了 CascadeTrajectorySummary 的完整 schema:

   message CascadeTrajectorySummary {
     string summary = 1;           // ← 标题
     uint32 step_count = 2;
     Timestamp last_modified_time = 3;
     string trajectory_id = 4;
     Timestamp last_user_input_time = 10;
     // ...
   }

2. 存储是嵌套的 base64(envelope_proto( entries: { key=uuid, value=base64(CascadeTrajectorySummary) } ))——基本上是把 UnifiedStateSync 的同步包装套了两层 base64。
3. 写了一个 ~80 行的 stdlib protobuf 编解码器(src/retitle/adapters/_proto.py)和一个 ~200 行的 adapter(src/retitle/adapters/antigravity.py)。完全零依赖。
4. 数据安全: BEGIN IMMEDIATE 事务、read 用 query_only、写出错回滚——和 Cursor 适配器一致。

用法:

retitle status                       # 会显示 "Antigravity ... found"
retitle list --tool antigravity      # 看所有 Antigravity 对话
retitle search "支付" --tool antigravity  # 跨工具搜索
retitle once --tool antigravity      # 改名

老实交代两个 caveat(已经写进 README):

• 因为我们读不到加密的正文,LLM namer 没法自动生成更好的标题——引擎的「实质内容」闸门默认会跳过 Antigravity 的自动 rename。Antigravity 本身已经会做自动改名了,我们不想盖掉它。
• trajectorySummaries 是云同步的存储,你本地改的标题可能被云端覆盖,或者反过来推到你其他设备上。运行中改了之后,在 App 里刷一下侧边栏才能看到。

测试 50 → 55,新增 5 个 Antigravity round-trip 测试(全部用虚构的 UUID/标题,没有任何真实数据)。如果你试用之后觉得 set_title 行为有什么不对,继续在 issue 里留言。

[xiongaox]

所以有什么好办法吗 新版的 我们应该怎么做到能支持rename呢？

@xiongaox 已经 ✅ 支持了 —— commit 52cba23。

我之前一上来就在加密的 .pb 文件上撞墙,结论下太早。重看之后发现 Antigravity 其实把标题和正文分开存的:

内容 位置 状态
对话正文 ~/.gemini/antigravity/conversations/<uuid>.pb 🔒 加密(密钥在 keychain)
对话标题 state.vscdb 的 antigravityUnifiedStateSync.trajectorySummaries 📖 明文
侧边栏读的是标题那一行,跟 Cursor 完全是同一个模式(SQLite + 结构化 blob)——不需要破密、不需要写 VS Code 扩展。

做法:

1. 我下载了官方 Antigravity 2.0.3 (darwin-arm) 的 DMG,挂载后从 jetskiAgent/main.js 里反编译出了 FileDescriptorProto,拿到了 CascadeTrajectorySummary 的完整 schema:
   message CascadeTrajectorySummary {
   string summary = 1; // ← 标题
   uint32 step_count = 2;
   Timestamp last_modified_time = 3;
   string trajectory_id = 4;
   Timestamp last_user_input_time = 10;
   // ...
   }
2. 存储是嵌套的 base64(envelope_proto( entries: { key=uuid, value=base64(CascadeTrajectorySummary) } ))——基本上是把 UnifiedStateSync 的同步包装套了两层 base64。
3. 写了一个 ~80 行的 stdlib protobuf 编解码器(src/retitle/adapters/_proto.py)和一个 ~200 行的 adapter(src/retitle/adapters/antigravity.py)。完全零依赖。
4. 数据安全: BEGIN IMMEDIATE 事务、read 用 query_only、写出错回滚——和 Cursor 适配器一致。

用法:

retitle status # 会显示 "Antigravity ... found"
retitle list --tool antigravity # 看所有 Antigravity 对话
retitle search "支付" --tool antigravity # 跨工具搜索
retitle once --tool antigravity # 改名
老实交代两个 caveat(已经写进 README):

• 因为我们读不到加密的正文,LLM namer 没法自动生成更好的标题——引擎的「实质内容」闸门默认会跳过 Antigravity 的自动 rename。Antigravity 本身已经会做自动改名了,我们不想盖掉它。
• trajectorySummaries 是云同步的存储,你本地改的标题可能被云端覆盖,或者反过来推到你其他设备上。运行中改了之后,在 App 里刷一下侧边栏才能看到。

测试 50 → 55,新增 5 个 Antigravity round-trip 测试(全部用虚构的 UUID/标题,没有任何真实数据)。如果你试用之后觉得 set_title 行为有什么不对,继续在 issue 里留言。

[xiongaox]

好像没法搞，他是加密的

[study8677]

@xiongaox 谢谢截图,这几张图特别有价值!但 Antigravity 内嵌的 AI 给你的那个结论——「正文加密了所以做不了」——不对。它和我第一次看的时候犯了同样的错(只看到加密的 .pb 就放弃了)。

它漏掉的关键线索

Antigravity 的 agent 自己在工作时,会把任务/计划/工作总结写成明文 markdown,放在:

~/.gemini/antigravity/brain/<uuid>/
├── task.md                          ← agent 写的任务说明
├── task.md.metadata.json            ← 里面有明文 summary
├── implementation_plan.md           ← 实施计划
├── implementation_plan.md.metadata.json
├── walkthrough.md
└── ...

我在自己的 Antigravity 数据上验证过:100 个对话里有 35 个生成了 brain artifacts(就是那些长一点、有真实工作内容的对话——也恰好是标题最容易跑偏的那类)。其余短对话没 artifacts 是合理的:没素材也起不出更好的名字。

已经处理好,刚推了 809617d

read_transcript 现在会:

1. 扫 brain/<uuid>/*.metadata.json 的 summary 字段(短而精,agent 自己写的)
2. 读 brain/<uuid>/*.md 前 1200 字符(完整工作文档)
3. 当作 user 消息喂给 namer

这样:

• ✅ 自动 rename 对 Antigravity 也工作了 —— 有 brain artifacts 的对话会被 daemon 自动改名
• ✅ 没 brain artifacts 的短对话仍然跳过(尊重 Antigravity 自己的自动命名)
• ✅ 跟其他三个工具行为完全一致

一个误会要澄清

你看到的"Antigravity 自己改了 retitle 源码"——那是 Antigravity AI 在你的本机上做的临时修补。我仓库里没有那份补丁。如果你下次 pipx upgrade retitle,会拿到我刚推的官方版本,Antigravity AI 的修改会被盖掉(没关系,我的版本应该更稳一些)。

但你提到了一个重要的新情况:你用的是 Companion App(独立客户端),数据存在
C:\Users\Admin\.gemini\antigravity\agyhub_summaries_proto.pb——这跟 IDE 版的 SQLite
不一样。我现在的实现只适配了 IDE 版的 state.vscdb。你要是愿意,可以把那个
agyhub_summaries_proto.pb 文件前 200 字节用 Format-Hex 或类似工具贴出来(只
是文件头,不含会话内容),我加一个 Companion App 的解析路径。

最后,我在 README 里加了对你的致谢——这个 issue 是整个适配器的起点。再次感谢 🙏。

[xiongaox]

agyhub_summaries_proto.zip

[study8677]

@xiongaox 谢谢 zip!上一秒还在请你贴 200 字节文件头,你直接把整个文件传上来了——直接解决问题 🚀

刚下载分析完,Companion App 的支持已经做好了,commit d0a6190。

你的 .pb 文件长这样

不是加密的——是裸 protobuf(没有 base64,也没有外层 envelope)。结构比 IDE 版还简单:

agyhub_summaries_proto.pb         ← 文件就是这个 message,直接写在硬盘上
  repeated TopEntry {
    string uuid                @ 1
    CascadeTrajectorySummary   @ 2     ← 跟 IDE 版同一个 schema
  }

跟 IDE 版的差别就一个:Companion 不套那两层 base64。所以 IDE 版的:

base64( envelope( Wrapper { base64( CascadeTrajectorySummary ) } ) )

在 Companion 里被直接展平成 CascadeTrajectorySummary,字段 1 (summary) 还是标题。

已经做的事

1. _companion_pb():看 ~/.gemini/antigravity/agyhub_summaries_proto.pb 在不在
2. _parse_pb_entries():解析裸 protobuf(复用了同一个 ~80 行的 stdlib codec)
3. _rewrite_pb_summary():改写指定 uuid 的 summary 字段,其他字节完全不动
4. set_title() 在 IDE 和 Companion 两条路径之间分发——前者走 SQL UPDATE,后者走「写临时文件 + os.replace 原子 rename」
5. read_transcript() 不需要改:它读的是 ~/.gemini/antigravity/brain/<uuid>/,这个目录在 Companion App 下也是同一个位置,所以自动 rename 在 Companion App 上也能用

验证

我用你传的 .pb 做了 round-trip 测试:7 个 entry,改第 0 个的标题,其他 6 个字节级一致。这个测试只在我本地跑(用真实数据验证),代码库里的测试全部用虚构 UUID 和虚构标题——你应该不会希望我把你 Desktop 上那些工作内容传到公开仓库里。

测试:55 → 63(新增 6 个 Companion App 的 round-trip 测试),全绿;ruff 全清。

用法

升级后:

pipx upgrade retitle
retitle status                       # 现在会同时识别两个 store
retitle list --tool antigravity      # IDE + Companion 的对话都列出来
retitle once --tool antigravity      # 改名

如果你两个版本(IDE + Companion)都装着,两边的对话都会出现在列表里,各自带 meta.store = "vscdb" | "companion" 区分(对你来说只是看到更多对话,不需要做任何事)。

⚠️ 一个 Windows-only 的小 caveat

Companion App 是 Windows 桌面端。如果你正开着 App 的同时让 retitle 改名,Windows 可能因为 App 持有独占文件句柄而拒绝 rename。这种情况下要么关掉 Companion 再跑 retitle,要么等它空闲(我们只在会话 idle 之后才碰)。已经写进 README 和 ARCHITECTURE。

接下来

我这边没法直接测 Windows——你升级之后帮我验证一下就完美了。如果改名后 Companion 里的标题没刷新,通常是要在 App 里点一下那个会话才会重新加载。

再次感谢——这一次又是你的数据直接解锁的功能 🙏