你的AI会话，为何无法带走？
The Session You Cannot take with you
推理API最初承诺的简单交互正在悄然变质。如今，OpenAI、Anthropic和Google等厂商 increasingly 返回混合了文本与专有状态的数据，其中包含加密的推理令牌、隐藏的搜索源以及仅能在其服务器端解析的上下文压缩。这意味着你本地保存的转录本不再是完整的会话，而只是部分视图，真正的操作状态仍被厂商牢牢掌控。文章提出了会话所有权的五项实用测试：检查、导出、重放、审计和删除。如果无法通过，说明你的数据并未真正属于你，而是被困在了厂商的生态系统中。
这种加密机制允许在生态系统内部实现连续性，但无法创建可携带到其他厂商模型的会话转录本。
HN 评论区
218- solarkraft
这是一篇很重要的文章。我还没意识到情况已经恶化到这种地步。就像一只青蛙在享受温暖的温水……
> 大多数人也不会每周更换操作系统或手机运营商。但即使你没有行使这种自由，它依然很重要，因为它改变了你与服务商的关系，以及服务商与你的关系。
这就是为什么行使你的自由如此重要。千万不要让自己被锁定在某个特定的生态系统中（这也是我为什么要为 OpenCode 开发手机应用的原因）。
这篇文章让我重新考虑是否要在我的家庭环境中使用最近刚买的 Codex 订阅。我从来就不喜欢他们隐藏推理过程，但不知为何因为性能太好，我强行克服了这种认知失调。然而，这种无法审计性本身已经是个巨大的问题了。
- hsaliak
Agent API 的现状很糟糕。completions API（被承诺无限期支持）但不支持推理。OpenAI 的推理 API 起步不错，但正朝着文章中描述的方向发展。Anthropic 的 messages API 也很奇怪。它包含了一些变更，比如最近引入的可以在对话中途注入的 system messages，但这些功能并非所有模型都支持（例如 sonnet 5）。所以你面对的是一个相当碎片化的状态。对于代码 Agent 来说，务实的做法是专注于把某一种 API（比如推理 API）做好，然后让路由器/提供商帮你处理转换。
也许，让事实上的标准 API 不是来自 OpenAI 的 Reasoning API，而是来自某个中立方的 API 会更有价值？
也许是一个定义完善的开放标准，它能封装这些 API 并获得广泛采用。
要实现这一点，倡导该 API 的方需要具备一定的流量捕获能力——也许是 OpenRouter，或者一群这样的路由器联合起来？
虽然这解决不了前沿实验室加密载荷的问题，但至少能防止这些 API 最终沦为仅仅是来回传输加密载荷的通道。
- skeledrew
我认为解决方案的一部分是尽可能将事务移出带外（out of band）。将子 Agent 的调用转化为对该 Agent 的工具调用。将工具调用本身外部化为 CLI 工具，也许甚至完全屏蔽原生工具（无关但相关的是，我前几天刚把 AskUserQuestion 工具加入了全局黑名单，因为 Claude 偶尔会忘记遵守我优先使用纯文本的既定指令，而这个工具非常烦人，因为它会在对话中制造断层），转而使用第三方替代方案。/compact 的退化也非常恼人，所以做一个替代方案，实现相同功能并将摘要保存到普通文件中。也许也值得提示 LLM 将其推理过程保存到文件中，即使这会多花几个 token，而且保存的也不是真正的推理 token。
话虽如此，我可能已经有东西可以至少帮助解决子 Agent/工具调用的问题了。我原本没有明确的时间表（或坚定的发布意图），但随着这些乱象增多，现在就是发布的好时机。
- hobofan
我认为这篇文章很好地概述了一个大多数 AI 用户很少评估或不得不面对的问题。
在许多“前沿推理提供商”中，确实存在令人惊讶的耦合度。许多强大的非 LLM 扩展功能（如网络搜索、代码执行）在表面上被打包成简单的“工具”，从而构建了很高的护城河。理论上，这些部分是可以与推理 API 分离的，并可以通过 MCP 服务器外部化，但推理提供商通常不提供这样的服务，而且往往只能从其他提供商那里获得功能稍弱的变体。
在构建一个本地部署、提供商无关的 Chat UI & 平台 [0] 时，我们反复遇到这个问题。即使是给终端用户添加一个简单的聊天内图片生成工具（这在 OpenAI Responses API 中只是一个内置工具），也变得相当棘手（尽管部分原因是因为 MCP 规范目前缺少原生的文件传输协议 [1]）。
不过我还是很乐观，随着近期兴趣转向开源权重模型，将有更多机会让公司提供更容易即插即用的替代实现。
[0]: https://github.com/EratoLab/erato
[1]: https://github.com/modelcontextprotocol/modelcontextprotocol...
- theturtletalks
这正是 Pi 会赢的原因。它允许你在某个模型表现不佳或干脆拒绝任务时热切换模型。而且由于它可以在 Claude Code 之外的任何子环境中运行，你可以用它来在 OpenCode Go 订阅甚至 OpenRouter 上尝试不同的模型。
至于子 Agent 的提示词和结果被混淆的问题，我只是让 Pi 生成新的 Agent。通过使用技能和扩展，我本质上利用 Pi 和一个自定义的终端复用器构建了一个软件工厂。
遗憾的是，像 T3 Code 和其他终端应用 UI 这样的应用不支持 Pi，我很高兴能使用终端，而不是那些让我进一步被锁定的应用。
- wamatt
不知为何，我早起时的迷糊大脑，原本以为博客标题会是一个通向存在主义的引子。
- pshirshov
我有一个所谓的“解决方案”——我的进程将真正重要的状态（想想“面向 Agent 的 JIRA”）保存在一个单独的数据库中（可通过 MCP 访问）。本质上，我可以终止当前会话，在一个不同的 harness 中用不同的模型开启新会话，然后以最小的损失继续工作。对于子 Agent，我有一个自定义的 dispatch_agent 工具，它本质上就是执行 shell 命令。
- skybrian
我在实践中并不认为这是个大事。对话中本来就有大量垃圾内容，所以从上下文中移除它们通常是个好事。
在我的仓库里，我有一个 notes 目录。我会让 AI 写一个 markdown 文件，记录它学到了什么、完成了什么工作以及还剩下什么。在下一个对话中，我可以问另一个模型从这里继续。有时我会先编辑一下笔记。