AI会话的不可移植性：提供商如何锁定你的推理数据

推理API的承诺与现实

推理API最初承诺的抽象非常简单：发送输入，接收输出。用户只要保存输入输出，就拥有了整个对话，可以检查、归档、重放或交给其他模型。但这个抽象从未完全成立：提示缓存存在于别人的GPU上，分词方式因模型而异，采样结果不可复现。然而，会话的语义记录——即转录文本——理论上仍应属于用户。一份转录应包含指令、消息、工具调用及其结果。另一个足够强大的模型虽然无法完全一致地继续，但至少能理解发生了什么并接手。

如今，推理API正令人沮丧地偏离这一特性。它们越来越多地返回文本与提供商绑定状态的混合体，这些状态有意设计为不可移植。具体表现包括：

• 推理令牌（reasoning tokens）对用户计费，但只以不透明的加密块返回，最多附带无用的摘要。
• 网络搜索中，模型看到了源材料，客户端却从未看到。
• 上下文压缩（compaction）只有原提供商能解密。
• 子代理指令和消息以加密载荷形式隐藏，运行代理的应用无法读取。
• 文件、向量存储、容器和缓存引用无法在其他地方解析。
• 响应和会话状态完全由存储在提供商服务器上的ID索引。

每个功能都有提供商轻易给出的基本理由，以及“这对用户有利”的论证。但所有这些加在一起，改变了AI会话的所有权现实：你机器上的转录不再是你的会话，而是会话的部分视图，其操作状态属于推理提供商，而非你。

会话所有权的实用测试

可移植会话并不意味着切换模型时必须产生相同的下一个令牌——模型能力、训练个性、上下文窗口和工具使用方式本就不同，且非确定性是常态。可移植性意味着更谦逊的目标：

const transcript = session.export();
revokeCredentials(oldProvider);
session = newProvider.continueFrom(transcript);

存档应包含足够可理解的信息，让另一个模型能继续工作，而不需要旧提供商去解析ID、解密块、记住搜索结果或重建摘要。这给出了五个有用的测试：

• 检查：用户能否看到模型看到了什么、工具做了什么、代理之间说了什么？
• 导出：会话是否自包含（除可下载的普通工件外）？
• 重放：另一个实现能否重建语义等价的上下文？
• 审计：事后人类能否解释系统为何采取某个行动？
• 删除：用户能否识别并移除会话依赖的每个服务器端副本？

响应ID不是转录（数据存储在服务器上），密文不是用户可控的状态（用户无法解密），引用列表不是模型上下文中的证据（你通常无法获取模型看到的相同数据）。

加密为谁？

围绕这些功能的命名和营销可能具有误导性。“encrypted_content”听起来像是用户可控的隐私功能，但实际上它是一个客户端无法读取、只有提供商能打开的胶囊。提供商选择密钥、为自己的模型解密内容，并定义数据可在何处重放。更恰当的术语是“提供商密封状态”（provider-sealed state）。

提供商密封确实有真正的隐私好处。例如，OpenAI可以返回加密推理给客户端（使用store: false），然后在下一个请求时在内存中解密，而不持久化中间状态。这比要求服务器端会话存储更好，尤其对零数据保留客户。但请记住，一开始并没有什么需要加密！这种加密并非对推理提供商隐藏数据，而是对用户隐藏数据。

存储对话：将转录变成指针

OpenAI的Responses API默认存储响应，文档说响应对象至少保留30天。store: false选项可用，应使用它，使其更像completions：数据不存储在OpenAI服务器上。新的Gemini Interactions API也做了类似选择，默认store: true，付费层保留55天，免费层1天。

服务器端存储状态的想法很有吸引力：应用发送更少数据，提供商能保留隐藏推理和工具状态，缓存路由更容易。但如果本地应用只记录用户消息和最终文本，first.id就成了一个它无法控制的数据库的外键。

没有推理给你

所有主要实验室都声称有正当理由不暴露原始思维链。因此，在非开放权重模型上，我们通常看不到这些令牌。原始推理通过API不可见。使用存储响应时，先前推理可通过previous_response_id恢复。使用store: false时，API返回encrypted_content，客户端必须保存并重放。即使reasoning.context: "all_turns"允许后续样本使用，持久化的推理仍然不透明。

Anthropic在签名（signature）字段中返回加密的完整思考。可读的思考文本（如果启用）是由另一个模型生成的摘要，而非原始思维链。思考块在工具使用回合中必须原样传递。Anthropic文档还说思考块与产生它的模型绑定，切换模型时应剥离。因此这些推理痕迹甚至不试图在Anthropic内部可移植。

所有闭权重模型都是同样的故事。这些加密机制允许在生态系统内连续，但不会创建可带到其他提供商模型的可移植转录。会话存档可以包含块，但另一个模型无法使用其含义：

{"type": "reasoning", "encrypted_content": "gAAAAAB..."}
{"type": "thinking", "thinking": "", "signature": "EqQBCg..."}
{"type": "thought", "summary": [], "signature": "EpoGCp..."}

隐藏的搜索

服务器端网络搜索是转录出现空洞的最清晰例子之一。客户端搜索工具的行为像任何其他工具：记录查询、检索时间、结果（URL、标题、段落），然后发送给模型。用户可以检查排名和段落、重新获取页面、缓存副本或向另一个模型提供相同证据。

而托管搜索中，提供商执行私有工具循环。OpenAI、Google和Anthropic暴露搜索动作、引用和可选的源URL列表，但不提供用于生成答案的完整文本上下文。URL不是稳定的重放——其内容可能已更改，或在模型看到之前已被缩减为更短的片段。最终答案可能很好，但问题出现在下一轮：“比较第三个来源和第一个，重新检查有争议的数字，用另一个模型继续这项研究。”新模型收到一个答案和几个URL，但没有收到结果排名、提取的段落、过滤掉的材料或第一个模型使用的确切证据。即使你有引用并重新获取，也无法重现精确数据。托管搜索应有一个全保真导出模式，包含查询、结果元数据、检索段落、时间戳和保留内容。简洁的引用可以保留为用户界面，但不应是唯一记录。

不透明的压缩

长代理会话最终需要压缩。可见的、客户端控制的摘要是有损的，但至少可检查、可转移。用户可以审查、编辑或让另一个模型生成另一个摘要。OpenAI的服务器端压缩则发出一个加密压缩项，文档描述为“不透明且不打算人类可解释”。独立的/responses/compact端点返回一个“规范的下一个上下文窗口”，客户端被指示原样传递。概念上，转换如下：

// 之前：昂贵但可移植
let history = [
  userMessage, assistantMessage, toolCall, fullToolResult,
  // ... 20万令牌的可理解历史
];
// 之后：仅对原提供商便宜
history = [
  { type: "compaction", encryptedContent: "enc_provider_only_state..." },
  ...recentItems,
];

OpenAI可以从压缩含义继续，但不同提供商看到的是不可读字符串加最近后缀（当然，我们永远不会将这类信息传递给另一个提供商）。这在技术上并非必要。Anthropic的服务器端压缩返回一个带有可读内容字段的压缩块，允许客户端提供自定义摘要指令，生成的摘要可检查并传递给另一个模型。客户端压缩也可在任何提供商上实现。OpenAI的密封工件可能比普通摘要保留更多模型特定状态，并在原模型上表现更好。这是一个合理的可选优化，但应附带可读的交接摘要，而不是取代它。同样，这很多方面还有额外好处：进一步将你锁定在一个生态系统中。

子代理带来隐藏指令

多代理系统使问题复杂化，因为不再只有一个转录，而是一棵会话树和它们之间的消息流。通常这些消息就像人类写的提示，只是现在由机器为机器编写。OpenAI的托管Responses Multi-agent测试版返回三种新项目类型：multi_agent_call、multi_agent_call_output和agent_message。spawn_agent的示例包含加密消息参数，代理间消息只包含encrypted_content。启用Multi-agent时，即使客户端未请求，也会隐式启用每个代理的自动服务器端压缩。不支持推理摘要，API还会注入根代理和子代理指令，开发者无法编辑或移除。

这是一捆不可转移的状态：密封委托、密封代理消息、各自自动压缩的上下文、隐藏推理和提供商托管的编排。2026年6月，开源Codex客户端也出现了相关变更。提交标题为“Encrypt multi-agent v2 message payloads”，直接解释了流程：

// 父模型的工具调用，由Codex持久化
{
  "name": "spawn_agent",
  "arguments": {
    "task_name": "worker",
    "message": "<ciphertext>"
  }
}

结论

推理API正从简单的输入输出模型转向复杂的、提供商绑定的状态管理。加密推理、隐藏搜索、不透明压缩和加密子代理消息共同构成了一种新的锁定形式。用户表面上拥有转录，但实际上会话的操作状态完全依赖提供商。文章呼吁更开放的设计：会话应可检查、可导出、可重放、可审计、可删除。提供商应提供全保真导出模式，而非仅提供密封块。用户应能真正拥有自己的AI会话，而不是成为提供商生态中的囚徒。

原标题：The session you cannot take with you。 HN 原始发布时间：2026年7月31日星期五。当前记录为 760 分、218 条评论。

阅读原文 · 查看 HN 讨论