你带不走的 AI 会话：当聊天记录变成供应商的加密保险箱

原文来源：Earendil — 推理 API 正在系统性地把 AI 会话变成供应商专属的加密状态，用户手里的"记录"只是别人服务器上一个无法独立解读的指针

推理 API 诞生时的承诺简单得迷人：发输入，收输出。把两边都存下来，你就拥有了这段对话——可以检查、归档、重放，甚至交给另一个模型。这个抽象从来不是百分之百成立的：prompt 缓存活在别人的 GPU 上，tokenizer 因模型而异，采样本身就不具备可复现性。但至少，会话的语义记录——指令、消息、工具调用、工具结果——属于用户。

如今这个承诺正在被一点点收走。各大厂商的推理 API 越来越多地返回一种"文本 + 供应商专属状态"的混合物，而这种状态是刻意设计成不可移植的：

• 推理 token 计了费，但只以不透明的加密 blob 返回，最多附一段没什么用的摘要
• 联网搜索时，模型看到了客户端永远看不到的原始材料
• 上下文压缩（compaction）之后，只有原供应商能解密
• 子代理的指令和信息以加密载荷的形式藏起来，连运行 agent 的应用都看不到
• 文件、向量库、容器、缓存引用，离开这个生态根本无法解析
• 对话状态完全由存在供应商服务器上的 ID 关联

每一项单独看都有冠冕堂皇的理由，也都有"这对用户更好"的说辞。但合在一起，所有权现实变了：你硬盘上的转录不再是你的会话，而是一个会话的部分视图——这个会话的运行状态属于推理供应商，不属于你。

五个测试判断会话到底是谁的

作者给出了一个实用的可移植性定义：换模型不需要产生相同的下一个 token（模型能力、个性、上下文窗口本来就不一样），但存档里应该有足够多的可理解信息，让另一个模型能接手继续干活——不需要旧供应商去解引用一个 ID、解密一个 blob、回忆一次搜索结果、重建一份摘要。据此有五条测试：

1. 检视：用户能看到模型看到了什么、工具做了什么、agent 之间说了什么吗？
2. 导出：会话是否自包含（除可下载的普通产物外）？
3. 重放：另一个实现能否重建语义等价的情境？
4. 审计：事后人类能否解释系统为什么采取某个行动？
5. 删除：用户能否识别并移除会话依赖的每一份服务器端副本？

对照现实：一个 response ID 不是转录（数据在服务器上）；一段密文不是用户可控制的状态（用户解不开）；一串引文不是模型实际看到的证据（你通常无法重新抓取到模型当时看到的同一份数据）。

"加密"到底是在保护谁

这些功能的命名和营销极具误导性。encrypted_content 听起来像受用户控制的隐私功能，实际上它是一个客户端读不了、只有供应商能打开的胶囊：供应商选密钥、给自己的模型解密、定义数据可以在哪里重放。更准确的说法是供应商封存状态（provider-sealed state）。

供应商封存确实可能带来真实的隐私收益——OpenAI 在 store: false 下返回加密推理，下次请求在内存中解密，不落盘持久化，对 Zero Data Retention 客户更好。但记住：这个加密没有对推理供应商隐藏任何东西，它只是对你隐藏。

存下来的对话：转录变成了指针

OpenAI Responses API 默认存储响应，文档说默认保留至少 30 天；Gemini Interactions API 更甚，付费层保留 55 天，免费层 1 天。服务端存储状态对开发者确实有吸引力：

const first = responses.create({
  model: "frontier-model",
  input: "Investigate this production failure",
  store: true,
});
 
const second = responses.create({
  model: "frontier-model",
  previousResponseId: first.id,
  input: "Now implement the fix",
  store: true,
});

应用少传数据、供应商能保留隐藏推理和工具状态、缓存路由更简单。但如果本地应用只记录了用户消息和最终文本，first.id 就成了一个指向你无法控制的外键——你所谓的"会话记录"只是别人数据库里一行数据的指针。

推理过程：不给你看

所有主流实验室都说有正当理由不暴露原始思维链。结果在非开放权重模型上，用户普遍看不到这些 token。Anthropic 在 signature 字段里返回加密的完整思考，可读的 thinking 文本是另一个模型生成的摘要，不是原始思维链；文档还明确说 thinking blocks 绑定产生它们的模型，换模型时应剥离。OpenAI 的 encrypted_content 客户端必须原样保存重放。所有封闭权重模型都在重复同一套剧本：加密机制让连续性在生态内部成立，但创造不出一份能带到别家模型的便携转录。

一个会话归档可以包含那个 blob，但另一个模型无法使用它的含义：

{"type": "reasoning", "encrypted_content": "gAAAAAB..."}
{"type": "thinking", "thinking": "", "signature": "EqQBCg..."}

隐藏的搜索：转录里最明显的洞

服务端联网搜索是"转录有洞"最清晰的例子。客户端搜索工具的表现像任何其他工具：记录查询、检索时间、结果 URL、标题、段落——用户能检查排序和片段、重新抓取页面、缓存副本、把同样的证据交给另一个模型。

托管搜索则是供应商私有的工具循环：OpenAI、Google、Anthropic 暴露搜索动作、引文，可选地给出一份来源 URL 列表，但不给模型实际看到的完整文本上下文。URL 不是稳定的重放——内容可能已变化，或者模型看到的只是一个更短的片段。

问题在下一轮出现："把第三个来源和第一个对比，重新核对那个有争议的数字，然后用另一个模型继续这项研究。" 新模型只拿到一个答案和几个 URL，拿不到结果排序、提取的段落、被过滤掉的材料、第一个模型使用的确切证据。旧供应商仍然是会话的一部分，即使下一个请求去了别处。

不透明的压缩

长 agent 会话迟早要压缩。客户端可见、客户端控制的摘要是有损的，但至少可检视、可转移——用户可以检查、编辑，或让另一个模型重新生成。

OpenAI 的服务端压缩则生成一个加密的压缩项，文档描述为"不透明，不打算让人可读"。概念上的转变：

// 之前：贵但可移植
let history = [userMessage, assistantMessage, toolCall, fullToolResult, /* 20万token可读历史 */];
 
// 之后：只能由原供应商廉价续写
history = [{ type: "compaction", encryptedContent: "enc_provider_only_state..." }, ...recentItems];

OpenAI 能从这个压缩含义继续，别的供应商看到的是一个不可读字符串加一段后缀。这在技术上并非必要——Anthropic 的服务端压缩返回带可读 content 字段的块，允许客户端提供自定义摘要指令，摘要可检查、可传给其他模型。封存的产物也许保留了更多模型专属状态、在原模型上表现更好——这是个合理的可选优化，但它应该配一份可读的交接摘要，而不是取代它。

子代理带着隐藏指令

多 agent 系统把问题放大了：不再是一个转录，而是一棵树状会话和它们之间的消息流。OpenAI 托管的 Responses Multi-agent beta 返回 multi_agent_call、agent_message 等新条目类型，spawn_agent 示例里就包含加密的 message 参数，agent 间消息只有 encrypted_content；启用 Multi-agent 时，即使客户端没要求，每个 agent 也会隐式开启服务端自动压缩。2026 年 6 月开源的 Codex 客户端提交了"Encrypt multi-agent v2 message payloads"，父模型发出的工具调用参数是密文，Codex 转发，API 内部给子模型解密——Codex 自己记录里的 content 是空的，确切的任务不在任何可读的 rollout 或历史里。

后果很实际：如果子 agent 改错了文件、泄露了秘密、重复了别人的工作、或者基于一个错误假设往下走，用户连"那个 agent 到底被要求做什么"这个最基本的问题都回答不了。GitHub 上已经有人给 Codex 提 issue，要求加密投递保留一份独立的可读审计副本——这是最低可接受的设计，更好的方案是明文 agent 间消息保持为常态。

"大多数人不会中途换模型"

大概率如此。但大多数人也不会每周换操作系统或手机运营商。自由不用，不等于自由无意义——它改变的是你和供应商之间的关系。

而且你完全可能因为别的原因需要迁移会话：模型退役、服务宕机、价格变动、政策拦截下一个请求、某个保密阶段必须本地跑、审计需要重建发生了什么。agent 正在让会话变得极长：一次编码或研究会话可以累积数天的决策和证据，个人助手的会话转录可以回溯数年。离开的选项本身就是纪律——如果供应商知道用户能去别处继续，它就得在模型质量、价格、可靠性和信任上竞争；如果用户积累的上下文只有一家供应商能解读，激励就变得非常糟糕。

可移植推理 API 应该承诺什么

作者给出了七条规则，我认为每一条都值得任何认真做 AI 产品的团队抄进自己的 API 设计文档：

1. 本地事件日志为准。服务器存储可以镜像或加速它，但客户端不需要解引用服务器 ID 就能重建会话。
2. 存储是显式的。store: false 应该简单、有文档、最好默认；需要留存的功能应该在使用的点上说明。
3. 没有哪个不透明条目是意义的唯一载体。加密推理、压缩、工具签名可以存在以换取同供应商质量，但每项都要有可读、供应商中立的交接表示。
4. 托管工具保留全保真日志。记录确切的输入、输出、证据、过滤、来源、时间戳、内容哈希——不只是漂亮的答案和引文。
5. 子代理通信可审计。为每个 agent 持久化确切可读的任务、消息、结果、血缘、模型和工具权限。
6. 压缩可检查。返回可读摘要、生成摘要所用的指令、足够了解丢弃了什么的血缘信息。
7. 产物可导出。文件、容器输出、搜索快照、生成媒体都能下载进一个内容寻址的本地归档。

蒸馏的双标

还有一层相关的锁定发生在模型层面。几家最大的封闭权重实验室越来越敌视外部蒸馏——Anthropic 2026 年 2 月把 DeepSeek、Moonshot、MiniMax 的蒸馏行为称为"蒸馏攻击"，商业条款允许客户拥有输出但禁止用服务训练竞品模型；同一篇文章却承认"蒸馏是广泛使用且合法的训练方法"——当前沿实验室对自己的模型这样做时。OpenAI 一边说训练用的是公开互联网内容、是合理使用，一边提供第一方 API 蒸馏工作流，用强模型输出微调更小的自家模型。

道德不对称很难忽视：实验室要求社会接受机器可以学习人类放在互联网上的海量作品——往往没有事先的、个别的许可——同时坚持其他机器不得从它们生成的输出中学习。这个原则的宽泛版本恰好允许学习流入封闭模型，却不允许流出。作者的态度旗帜鲜明：对蒸馏的默认态度应该从敌视转向支持——蒸馏能把昂贵的前沿能力变成更小、更便宜、更快的模型，能在本地、离线、受限硬件上运行，能在 API 消失时保留能力，还能减少常见任务的计算和能源消耗。

最低限度的自由

用户应该能关闭账户、保留会话、把它交给另一个模型。新模型可能不同意、会提问、表现更差——但它不应该面对旧模型看到用户历史、证据、计划、委派工作时所面对的同一片密文。

作者没有反对供应商构建更好的有状态 API。反对的是把更好的性能与更少的用户控制捆绑在一起：有状态存储应该是可选的，托管工具应该可观测，压缩应该可读，agent 通信应该可审计，不透明的推理要么不透明、至少要有可移植的交接。蒸馏应该成为能力更易获取的路径，而不是用来筑更高墙的禁忌。这条底线，值得每个认真把 AI 当生产力工具的人记住——因为今天你在会话里积累的一切，明天可能就锁在别人家的保险箱里。