推理API的原始承诺是用户可拥有对话记录，但如今提供商越来越多地返回非便携状态，如加密推理令牌、隐藏的搜索源和子代理指令，导致会话无法被其他模型或用户完全理解和接管。

好的，这是根据您提供的英文文章内容，用中文重新陈述的主要观点，保留了关键细节，并删减了与核心主题关联不大的部分。

文章标题：你带不走的会话 | EARENDIL

核心论点： 当前AI推理API的发展趋势正在侵蚀用户对会话的所有权和控制权。会话正从用户可携带的、透明的记录，转变为依赖特定提供商、充满不透明状态的“黑箱”。

文章主要内容如下：

推理API最初的承诺很简单：用户输入，模型输出，用户保存两者即拥有整个对话。用户可以检查、存档、重放，甚至交给另一个模型。但这个抽象从未完全实现，因为提示词缓存、分词差异和采样的不可复现性都是现实问题。然而，会话的“语义记录”（即对话记录）本应属于用户。一份理想的记录应包含指令、消息、工具调用及其结果，让另一个足够强大的模型能够理解并接手。

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

• 推理令牌： 向用户收费，但仅以不透明的加密数据块形式返回。
• 服务端搜索： 模型看到了用户从未见过的源材料。
• 压缩上下文： 只有原提供商能解密。
• 子代理指令： 以加密载荷形式对运行代理的应用隐藏。
• 各种引用： 文件、向量存储、容器和缓存引用在其他地方无法解析。
• 会话状态： 完全由存储在提供商服务器上的ID键控。

这些功能组合在一起，改变了AI会话的所有权现实：你机器上的记录不再是你的会话，而只是会话的一个局部视图，其运行状态属于推理提供商，而非你。

会话所有权的实用测试

可移植的会话不要求切换模型后必须产生相同的下一个令牌，而是意味着：

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

存档应包含足够清晰的信息，让另一个模型能继续工作，而无需原提供商去解析ID、解密数据块、回忆搜索结果或重建摘要。

这引出了五个实用测试： 1. 可检查性： 用户能否看到模型看到了什么、工具做了什么、代理之间说了什么？ 2. 可导出性： 会话是否自包含（除了可下载的普通工件）？ 3. 可重放性： 另一个实现能否重建语义上等效的上下文？ 4. 可审计性： 事后能否解释系统为何采取某个行动？ 5. 可删除性： 用户能否识别并删除会话依赖的所有服务端副本？

一个响应ID不是记录，用户无法解密的密文不是用户控制的状态，一份引用列表不是模型在搜索中看到的证据。

加密为谁而设？

“加密内容”听起来像用户控制的隐私功能，但通常是客户端无法读取、只有提供商能打开的“胶囊”。更准确的术语是提供商密封状态。这种加密并非对提供商隐藏数据，而是对用户隐藏数据。

存储的对话将记录变成指针

OpenAI的Responses API默认存储响应，将响应对象变成指向其数据库的外键。Gemini Interactions API也默认存储。虽然store: false选项存在，但默认存储的设计鼓励了用户放弃对会话的直接控制。

隐藏的推理与搜索

所有主要实验室的闭源模型都不暴露原始思维链，而是返回加密内容。服务端搜索只返回答案和引用URL，而非模型实际看到的完整文本上下文。当用户想用另一个模型继续研究时，新模型无法获得原始证据。

不透明的压缩

OpenAI的服务端压缩会生成一个加密的压缩项，被描述为“不透明且非人类可读”。这虽然可能保留更多模型特定状态，但完全取代了可读的交接摘要，进一步将用户锁定在单一生态系统中。

子代理的隐藏指令

多代理系统加剧了问题。OpenAI的托管多代理API返回加密的代理间消息和指令，开发者无法编辑或查看。如果子代理出错，用户甚至无法回答“那个代理被要求做什么？”这个简单问题。

“大多数人不会在会话中途切换模型”

即使你不切换，可移植性依然重要，因为它改变了你与提供商的关系。用户可能因模型退役、服务中断、价格变化、政策限制、审计需求或需要本地运行而需要迁移会话。可选项的存在也创造了市场纪律，迫使提供商在质量、价格、可靠性和信任上竞争。

可移植推理API应遵循的规则

1. 本地事件日志是权威的。 客户端无需引用服务端ID即可重建会话。
2. 存储是明确的。 store: false应易于使用、有文档记录，并最好设为默认值。
3. 没有不透明项是意义的唯一载体。 加密项应有可读的、提供商中立的交接表示。
4. 托管工具有全保真日志。 记录精确的输入、输出、证据、过滤步骤等，而非仅一个精炼的答案。
5. 子代理通信是可审计的。 持久化每个代理的精确可读任务、消息、结果和权限。
6. 压缩是可检查的。 返回可读摘要及其创建指令。
7. 工件是可导出的。 文件、容器输出、搜索快照等可下载到本地存档。

关于蒸馏

文章最后指出，大型闭源实验室对蒸馏（用大模型输出训练小模型）的态度存在道德不对称。它们一方面利用公开网络数据训练模型，另一方面却禁止他人利用其模型输出进行蒸馏。文章认为，蒸馏应得到支持，因为它能将昂贵的尖端能力转化为更小、更快、可在本地或离线运行的模型，增加竞争并降低能耗。

结论：最低限度的自由

用户应该能够关闭账户、保留会话，并将其交给另一个模型。新模型可能表现不佳，但它不应面对密文，而旧模型看到的却是用户的完整历史、证据、计划和委派工作。文章不反对提供商构建更好的有状态API，但反对将更好的性能与更少的用户控制捆绑在一起。

根据评论内容，总结主要观点如下：

1. 用户应拥有对AI模型的自主控制权（支持开放权重模型） - 评论1（padolsey）强调用户应能关闭账户、保留会话并转移至其他模型，认为开放权重模型能提供永久性，避免被大公司“抽走地毯”。关键引用："A user should be able to close an account, keep a session, and hand it to another model." 和 "This, to me, is the power of open-weights models. They are for perpetuity." - 评论6（solarkraft）指出用户不应被锁定在特定生态系统中，并提到隐藏推理过程导致“不可审计性”是严重问题。关键引用："Do NOT let yourself get locked into a particular ecosystem" 和 "the inauditability is already a huge problem."

2. 对API限制的质疑（如隐藏推理、收费模式） - 评论2（n0on3）对文章观点持保留态度，认为部分抱怨可能源于开发者自身利益，并引用“角色混淆”案例说明隐藏推理的合理性。关键引用："older and more cynical me wonders how much of this is a battle worth fighting" 和 "based on that it seems pretty clear why one would choose not to provide the thinking anymore…" - 评论3（captainmuon）批评API要求用户每次发送完整对话却隐藏推理过程，且按长度收费不合理。关键引用："why do I have to send them the whole conversation every time?" 和 "they should have the burden of storing and transmitting it, and shouldn't charge more and more."

3. 对开放权重模型的未来展望 - 评论7（throwaway63467）预测大多数LLM工作将迁移至开放权重模型，因价格和透明度优势，除非监管偏向闭源。关键引用："most LLM work will migrate to open weight models in a couple of years" 和 "with these models transparency is no issue."

4. 对文章本身的正面评价 - 评论5（mnewme）直接表示赞同：“absolutely agree and I love what you guys are building” - 评论6（solarkraft）称文章重要，并比喻用户如“温水煮青蛙”，未意识到问题严重性。关键引用："This is an important article. I hadn’t realized it was already getting this bad."

平衡性说明：支持开放权重和用户自主权的观点占多数（评论1、6、7），但评论2提出了对动机的质疑，评论3则聚焦于API的具体不合理性。整体上，评论倾向于批评闭源模型的限制，并呼吁更多透明度和用户控制权。