你无法带走的会话：推理 API 的便携性困境
推理API最初的设想无比简洁：发送输入，接收输出。只要保存好这两者，你就拥有了完整对话——可以查看、存档、重放，或是交给其他模型处理。
但这种理想化的抽象从未完全实现。比如，提示词缓存存储在他人的GPU上，不同模型的分词规则各异，采样过程也不可复现（而且是刻意设计成这样）。不过，以对话记录形式存在的会话语义信息仍归用户所有。一份合格的对话记录应包含指令、消息、工具调用及工具返回结果。换用其他能力足够的模型，未必能完全复刻后续输出，但至少能理解对话脉络并继续任务。
令人沮丧的是，推理API正逐渐背离这一核心属性，至少在一定程度上如此。它们越来越多地返回文本与供应商绑定状态的混合内容，且刻意设计得无法迁移。具体表现包括：
- 向用户收费的推理令牌，仅以加密二进制大对象形式返回，最多附带毫无用处的摘要
- 模型可获取搜索源内容，但客户端完全无法查看
- 仅原供应商能解密的压缩上下文
- 以加密载荷形式对运行代理的应用隐藏的子代理指令与消息
- 无法在其他平台解析的文件、向量库、容器及缓存引用
- 完全依赖供应商服务器存储的ID来标识的响应与会话状态
每一项功能背后，供应商都能轻易给出看似合理的解释，也能列举对用户有利的理由。但这些功能共同改变了AI会话的所有权现状：你本地保存的对话记录不再是完整会话，而只是会话的局部视图——会话的实际运行状态归推理供应商所有，而非你。
我们不认同这一发展方向，接下来将谈谈这对用户、对我们这些AI工具开发者意味着什么。
会话所有权的实用测试标准
我们所说的"可迁移会话"，并非指切换模型后必须生成完全相同的下一个令牌。这本身就不现实，因为不同模型的能力、训练出的"性格"、上下文窗口大小及工具交互方式都存在差异，且整个过程具有不确定性。可迁移性的定义更务实：
const transcript = session.export();
revokeCredentials(oldProvider);
session = newProvider.continueFrom(transcript);
会话存档应包含足够清晰的信息，让其他模型能继续完成任务。它不应依赖原供应商去解析ID、解密二进制对象、回忆搜索结果或重构摘要。
基于此，我们提出五项实用测试标准：
- 可查看性：用户能否查看模型接收的信息、工具执行的操作，以及代理间的通信内容？
- 可导出性：会话是否具备自包含性，仅需额外下载常规资源即可完整迁移？
- 可重放性：其他实现能否重构语义等价的上下文？
- 可审计性：事后能否由人工解释系统为何采取某一行动？
- 可删除性：用户能否识别并删除会话依赖的所有服务器端副本？
响应ID不等于对话记录（数据存储在服务器上），密文不受用户控制（用户无法解密），引用列表也不等于模型搜索时获取的原始证据（通常无法获取模型看到的 exact数据）。
加密为谁服务？
这些功能的命名与营销话术具有误导性。encrypted_content听起来像是用户可控的隐私保护功能，但实际上它通常是客户端无法读取、仅供应商能解密的"胶囊"。密钥由供应商生成，只有他们的模型能解密内容，且由他们定义数据可在何处重放。
更准确的说法是供应商密封状态。
供应商密封确实能带来一定隐私益处。例如，OpenAI可通过store: false参数向客户端返回加密的推理内容，下次请求时仅在内存中解密，不持久化中间状态。这比要求服务器存储对话记录更优，尤其对零数据保留客户而言。但别忘了，这些数据从一开始就根本不需要加密！
这种加密无法向推理供应商隐藏数据，却把数据对用户藏了起来。
存储式对话：从记录变成指针
OpenAI的Responses API默认存储响应。其文档显示，响应对象默认至少保留30天。store: false参数可用且应被优先使用，这样它的行为更接近补全接口：数据不会存储在OpenAI服务器上。
谷歌新推出的Gemini Interactions API也做出了类似选择，默认store: true。付费 tier的交互记录保留55天，免费 tier保留1天。
显然，将状态存储在服务器上对开发者颇具吸引力：
const first = responses.create({
model: "frontier-model",
input: "调查这次生产故障",
store: true,
});
const second = responses.create({
model: "frontier-model",
previousResponseId: first.id,
input: "现在修复问题",
store: true,
});
应用发送的数据更少，供应商可保留隐藏的推理过程与工具状态，缓存路由也更简单。但如果本地应用仅记录用户消息和最终文本，first.id就成了指向一个不受应用控制的数据库的外键。
推理过程与你无关
所有主流AI实验室都声称，不暴露原始思维链有合理理由。因此，在非开源权重模型中，我们通常无法获取这些推理令牌。
原始推理过程无法通过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..."}
隐藏的搜索过程
服务器端网页搜索是对话记录存在用户不可见缺口的典型案例。客户端搜索工具的行为与其他工具无异：
const result = search(query);
record({
query,
retrievedAt: now(),
results: result.map((item) => ({
url: item.url,
title: item.title,
passages: item.passages,
})),
});
model.send({ toolResult: result });
用户可查看搜索结果排序、提取的文本片段，重新获取页面内容、缓存副本，或将相同证据提供给其他模型。
而托管式搜索中，供应商会执行私有工具循环。OpenAI、谷歌和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的服务器端压缩会返回带有可读content字段的compaction块，允许客户端提供自定义摘要指令，生成的摘要可查看并传递给其他模型。任何供应商都支持客户端压缩。
OpenAI的密封对象可能比普通摘要保留更多模型特定状态，在原模型上表现更优。这是合理的可选优化，但应同时提供可读的迁移摘要，而非取而代之。不过，这类功能还有一个额外"好处"：进一步将用户锁定在自身生态系统中。
子代理的隐藏指令
多代理系统让问题更复杂，因为此时不再只有一份对话记录，而是存在会话树和代理间的消息流。这些消息通常是机器为其他机器生成的提示词，格式与人类编写的类似。
OpenAI的托管式Responses多代理测试版新增了三种条目类型：multi_agent_call、multi_agent_call_output和agent_message。spawn_agent的示例包含加密的message参数，代理间消息仅包含encrypted_content。启用多代理功能后，每个代理都会自动开启服务器端压缩，即便客户端未请求。该API不支持推理摘要，还会注入开发者无法编辑或移除的根代理与子代理指令。
这是一堆不可迁移的状态集合：密封的委托指令、密封的代理消息、独立的自动压缩上下文、隐藏的推理过程，以及供应商托管的编排逻辑。
2026年6月，开源Codex客户端也做出了类似改动。题为"加密多代理v2消息载荷"的提交直接说明了流程：
// Codex保存的父模型工具调用
{
"name": "spawn_agent",
"arguments": {
"task_name": "worker",
"message": "<密文>"
}
}
// 子模型的输入
{
"type": "agent_message",
"author": "/root",
"recipient": "/root/worker",
"content": [{
"type": "encrypted_content",
"encrypted_content": "<密文>"
}]
}
Responses API加密父模型发出的工具参数，Codex转发该参数，API在内部为子模型解密。Codex自身的InterAgentCommunication.content为空，具体任务在可读的部署记录与历史中完全缺失。
这恐怕不只是抽象的模型切换问题。试想，如果子代理修改了错误的文件、泄露了机密、重复了其他代理的工作，或是基于错误假设执行任务，用户根本无法回答一个简单问题：这个代理接到的指令到底是什么？
Codex的一个公开议题要求加密传输时保留单独的可读审计副本，这是最低可接受的设计。更优的方案是，代理间通信默认使用明文。
"大多数人不会在会话中途切换模型"
或许确实如此。就像大多数人不会每周更换操作系统或手机运营商一样。但即便你不使用这项自由，它仍具有重要意义——因为它改变了你与供应商之间的关系，以及供应商对你的态度。
作为用户，你可能因以下原因需要迁移会话：模型被停用、服务中断、价格调整、政策限制了后续请求（比如某些虚构场景）、机密任务必须在本地运行，或是审计需要还原会话过程。此外，代理技术让会话时长大幅增加。一次编码或研究会话可能积累数天的决策与证据，个人助理的会话记录甚至可能回溯数年（目前这类服务还没那么久的历史，但未来可能实现）。
拥有离开的选择权，也能促使供应商保持自律。如果供应商知道用户可随时转投其他平台，就必须在模型质量、价格、可靠性与信任度上展开竞争。若用户积累的上下文仅能被一家供应商解析，就会催生非常糟糕的激励机制。
可迁移推理API应做出的承诺
我们希望推理供应商与代理开发者遵循以下几条规则：
- 本地事件日志为权威来源：服务器存储可作为镜像或加速手段，但客户端无需解析服务器ID即可重构会话。
- 存储需明确选择：
store: false应易于设置、有清晰文档，且优先设为默认值。需要保留数据的功能，应在使用时明确告知用户。 - 不透明对象不能是唯一语义载体：可包含加密推理、压缩结果与工具签名以优化同供应商内的性能，但每项内容都需配有可读的、与供应商无关的迁移表示。
- 托管工具需全保真日志：记录确切的输入、输出、证据、过滤规则、来源、时间戳与内容哈希——不能只保留打磨后的答案与引用。
- 子代理通信需可审计：保存每个代理的可读任务、消息、结果、谱系、模型及工具权限。
- 压缩结果需可查看：返回可读摘要、生成摘要所用的指令，以及足够的谱系信息以说明哪些内容被舍弃。
- 资源需可导出：文件、容器输出、搜索快照与生成的媒体可下载至本地内容寻址存档。
蒸馏技术其实大有裨益
模型层面还存在另一种形式的锁定。
美国一些大型闭源AI实验室对外来蒸馏技术的态度愈发强硬。Anthropic在2026年2月发布的文章中，称DeepSeek、Moonshot与MiniMax的所谓蒸馏行为是"蒸馏攻击"。其商业条款规定客户拥有自己的输出，但禁止用其服务训练竞争AI模型。与此同时，Anthropic在同一篇文章中承认，"当前沿实验室用于自身模型时，蒸馏是一种广泛使用且合法的训练方法"。
Anthropic使用机器人从公共网络收集数据用于模型开发，还曾因扫描书籍内容引发争议。OpenAI同样表示，其模型训练使用公开可访问的互联网内容，并主张训练使用公开互联网材料属于合理使用。两家公司都认为，在内部使用蒸馏技术生成更小模型是正常做法。OpenAI甚至提供了明确的第一方API蒸馏流程，允许用更强的OpenAI模型输出微调更小的OpenAI模型。
这种道德上的双重标准显而易见。这些实验室要求社会接受：机器可以从人类发布在互联网上的海量作品中学习——往往未经提前、单独的许可——却坚称其他机器不能从他们生成的输出中学习。这种原则的最宽泛解读，恰好允许知识流入闭源模型，却禁止流出。
我们认为，对蒸馏技术的默认态度应从敌视转为支持。蒸馏可将昂贵的前沿能力转化为更小、更便宜、更快的模型，使其能在本地、离线环境或受限硬件上运行，完全处于用户控制之下。它能促进竞争，在API消失时保留能力，还能减少常见任务所需的计算资源与能耗。
最基本的自由
用户应能关闭账户、保留会话记录，并将其交给其他模型处理。新模型可能持不同意见、提出问题，或表现更差，但不应面对一堆密文——而原模型看到的却是用户的历史、证据、计划与委托任务。
我们不反对供应商开发更优秀的有状态API，但反对将更好的性能与更少的用户控制权绑定。有状态存储应是可选的，托管工具应具备可观测性，压缩结果应可读，代理通信应可审计，不透明的推理过程要么变得透明，要么至少提供可迁移的替代方案。蒸馏技术应成为能力普及的途径，而非用于构建更高壁垒的禁忌。