你无法随身带走的会话

对隐藏状态与会话锁定的担忧

• 许多评论支持文章的核心担忧：提供商正越来越多地隐藏会话的一部分内容（推理 token、子代理消息、服务器端工具、压缩处理），并将其绑定到单一供应商。
• 这破坏了检查、导出、重放和审计，也让把一个“活着的”会话迁移到另一个模型或提供商变得困难。
• 一些人认为这是一种刻意构建护城河的做法，并是在用户足够被锁定之后走向未来“烂掉化”的铺垫。

技术与成本考量

• 关于 KV cache 的讨论：长上下文很昂贵；缓存未命中会迫使重放历史记录。有人认为用户不应该被迫重新发送完整对话；也有人指出缓存管理本质上就是有成本的。
• 有人抱怨会被收取“思考” token 的费用，而这些 token 既不可见也无法验证。
• 一些人指出，OpenAI 更新的 API（Responses、reasoning effort levels、server-side compaction）很可能嵌入了专有编排逻辑，难以在客户端复现。

安全性、对齐与推理可见性

• 一派引用“role confusion”/prompt-injection 研究以及蒸馏风险，认为隐藏推理有现实理由。
• 另一派认为，隐藏痕迹只能非常有限地缓解这些攻击；对痕迹签名或验证、以及更好的训练方式，会比把它们加密隐藏起来更诚实。

开源模型、本地托管与 Harness

• 一股强烈倾向是转向 open-weight 和本地模型：它们被视为持久、可检查，而且不会遭遇突然变卦。
• 一些用户已经在多个模型之间路由（包括中文模型），并重视能在会话中途切换，即便要付出一些缓存成本。
• 工具和 harness（例如终端 UI、基于 MCP 的系统、自定义路由器）正在被专门构建出来，以保持会话可移植、日志留在客户端。

用户变通办法与替代模式

• 有人保存自己的对话记录，为过往会话建立搜索，或者使用类似 git 的归档来保存上下文。
• 还有人把重要状态放进单独的工件中：笔记、“basis” 文档（意图、设计、蓝图）、工单或任务数据库，这样新会话或新模型就能接手工作，而无需依赖不透明的提供商日志。

怀疑与反驳

• 少数人认为会话可移植性被过度看重：对话本来就很嘈杂，上下文窗口是有限的，而真正的资产是最终生成的代码或文档，它们可以自由迁移。
• 也有人强调，复杂的账户系统和托管工具很难构建；把这些交给提供商（包括“Sign in with Google”和服务器端工具）往往更实际，即使这会增加依赖。

标准、中间层与市场动态

• 多条评论呼吁开放、与提供商无关的会话格式或 API（可能通过 MCP 或中立路由器），以减缓碎片化并保留可移植性，即使隐藏推理无法恢复也是如此。
• 另一些人预测，随着 API 分化和隐藏状态增长，完整的会话可移植性将变得越来越不可行，使得谨慎设计 harness 或把提供商切换视为明确的“迁移”变得至关重要。

元话题：AI 写作指控

• 一些工具把这篇文章标记为 AI 生成；另一些人对此表示异议，并批评检测器的可靠性。
• 作者（根据讨论串）描述了一种工作流：让 LLM 帮助进行结构组织和文案编辑，但否认让它直接执笔全文，强调“AI 辅助”与“AI 生成”之间的界限已经变得多么模糊。