LLM 0.32rc1 的发布说明里，最先出现的三个名字是 gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna。但往下翻两段就会发现，这次真正动的不是模型列表，是消息存储的底层结构：每条消息的 ID，从自增数字换成了内容寻址哈希。
这个改动不是装饰性调整。旧版 LLM 用自增 ID 记录每条 prompt 和 response，只能排成一条直线，问一句、答一句，顺序往下记。新版把 ID 换成基于内容本身算出的哈希值，同一段内容对应同一个哈希，理论上不用在数据库里重复存两份；消息之间也能形成分支，一次对话拆出几条路径，各自独立记录。这是从 0.32a0 就开始的重构，这次 RC 把新 schema 做到了可以正式测试的程度。
新旧结构差在哪
| 维度 | 旧版结构 | 0.32rc1 新结构 |
|---|---|---|
| 消息 ID | 自增数字 | 内容寻址哈希 |
| 重复内容 | 各自占一条记录 | 官方称可去重，未给出具体比例 |
| 对话结构 | 线性，只能顺序追加 | 可分叉成树，支持多分支路径 |
| Schema 变更 | — | 新增表，不改旧表 |
| 升级前动作 | — | 建议先执行 llm logs backup |
这套结构目前解决的是"存储层能不能表达分支"，不是"去重能省多少空间"——官方说明没给出去重比例、数据库体量变化或迁移耗时，这块目前只能看功能描述，看不到实测数字。
备份是这次唯一没有例外的动作
Simon Willison 在说明里写得很克制：这次改动只新增表，不碰旧表，理论上旧数据不受影响。但他同时给出了明确的备份命令：
llm logs backup logs-backup.db这是 RC 阶段，"不受影响"目前是承诺，不是验证过的结果。对长期用 llm logs 维护本地记录、经常在同一个对话里改问法重新提问的开发者，这条命令比三个新模型名字更该记住——先备份，再升级，出问题还有退路。单纯调用 API 做一次性问答的用户，基本感觉不到这次变化。
判断：骨架换了，账本还没结清
三个新模型是常规跟进，谁家都会加，不是这次的重点。真正体现判断力的是把聊天记录从流水账升级成可去重、可分叉的树——这对做多轮对话实验的人是刚需，不用再担心重问一次就变成一条断掉的新记录。
但几个问题目前还看不清：插件生态是否已经跟上新 schema、旧记录在未来正式版里会不会被牵动、去重实际能省下多少空间。这些都不是这次说明里能回答的。
接下来最该盯的，是 0.32 从 RC 转正式版时，备份建议会不会保留下来，以及第一批升级用户反馈的数据库体量变化——这比模型名单更能说明这次改动扎不扎实。
【锐评】温故而知新，先把旧账本理顺，再谈新模型才算数。