速读#
Pi 背后的 Earendil Engineering 发出了一封关于 Session Portability 的公开信。它讨论的不是哪个模型更强，而是一个更基础的问题：当推理状态、搜索材料、上下文压缩和子 Agent 消息逐渐被封装在供应商内部，用户导出的究竟是完整会话，还是一份无法继续工作的聊天记录？
这封信提出的可迁移也不是换个模型还能生成完全相同的下一句话，而是换掉供应商后，新模型仍能读懂之前发生了什么，并继续完成任务。
这封信在反对什么#
原文 The Session You Cannot Take With You 发布在 Earendil 官网，邮件头署名 Earendil Engineering；Pi 官网标注 Earendil Inc.，安装包也发布在 @earendil-works 名下。因此这里所说的“Pi 的公开信”，指的是 Pi 背后的团队对 AI 会话所有权这条行业方向的公开表态，不是 Pi 的版本更新或产品公告。公开信写给提供推理 API 的模型供应商、构建 Agent 的开发者，以及正在把长期工作交给 AI 的用户。
过去对推理 API 的理解很简单：发送输入，得到输出，把两边保存下来，就大致拥有了这次对话。这个抽象从来不完全准确，不同模型的分词、采样、缓存和工具实现都不一样，但至少主要语义仍在本地；另一套模型未必会做出相同选择，却能知道此前的指令、工具调用和结果。现在越来越多能力把这条边界变得模糊，一次完整会话还可能依赖：
- 用户无法读取、只有原供应商能够继续使用的推理状态；
- 只返回引用链接、不返回查询与关键材料的托管搜索；
- 只有原供应商能够解释的压缩上下文；
- 被封装的子 Agent 任务、消息和工具结果；
- 依赖服务端 ID 的文件、容器、向量库与缓存；
- 只存在供应商数据库里的任务状态。
这些能力并非没有价值，它们可以降低传输成本、改善缓存、减少持久化，并让 Agent 编排更方便。公开信反对的不是有状态 API，而是性能优化与更少的用户控制权被绑定在一起，并让供应商状态逐渐成为会话意义的唯一载体。它的核心判断很直接：
本地聊天记录如果只是一张指向供应商状态的索引，用户就没有真正拥有这次会话。
聊天记录为什么不等于会话#
屏幕上能看到的聊天记录只是表层。对一个 Coding Agent 来说，真正决定下一步的内容还包括它读过哪些文件、执行过哪些命令、测试为什么失败、压缩时保留了哪些判断，以及父 Agent 给子 Agent 分配了什么任务。如果这些信息没有进入可读记录，本地导出的就不是完整会话，而是一张指向供应商状态的索引。
公开信给出了一组很实用的判断，可以整理成五个问题：
| 检查项 | 要回答的问题 |
|---|---|
| 可检查 | 我能否看到模型看到的材料、工具做过的事和 Agent 之间的消息？ |
| 可导出 | 导出文件是否自包含，不需要原供应商再解析某个 ID？ |
| 可继续 | 另一套实现能否重建语义等价的上下文并继续工作？ |
| 可审计 | 任务出错后，人能否解释某个动作为什么发生？ |
| 可删除 | 我能否知道服务端保留了什么，并通过明确机制或合同承诺删除？ |
这五项比“有没有导出按钮”更接近真正的所有权。一个 response ID 不是会话记录，一段用户无法解密的密文不是用户控制的状态，几个来源 URL 也不等于模型当时实际读到的证据。
会话最容易在哪里被锁住#
供应商封装状态#
在某些推理 API 中，类似 encrypted_content 的字段很容易被理解成“数据由用户自己的密钥保护”。实际情况可能是密钥仍由供应商掌握，内容也由供应商解密后交给同一生态里的模型继续使用；用户能够保存密文，却不能理解它，也不能交给另一家模型恢复语义。原文把这类信息称为 provider-sealed state，即“供应商封装状态”，这个名称比单纯强调加密更接近它的控制边界。
这不一定是坏设计。它可以减少服务端长期存储，同时保留原模型下一轮所需的状态，对不希望会话长期落库的用户可能有实际隐私收益；但减少持久化不代表数据对供应商不可见，同一生态内的连续性也不等于跨供应商迁移。更合理的形态是让供应商封装状态负责优化原模型，同时生成一份可读、供应商无关的交接摘要，避免会话的主要语义只存在于密文中。
托管搜索#
托管搜索最容易暴露这个问题。模型完成检索后，最终回答可能只留下几个引用链接，没有查询词、结果排序、实际摘录、抓取时间和过滤过程；网页又可能修改、下线，或者因为地区和登录状态返回不同内容。下一轮若换模型继续核对某个数字，新模型拿到的是答案与链接，而不是上一轮真正使用过的证据。
这并不意味着每次随手搜索都要建立取证系统。普通聊天保留引用通常已经够用；研究、审计和长期 Agent 任务则至少应保存查询、时间、来源与关键摘录。任务越重要，记录就越应该接近工具的真实输入输出，而不是只留下经过润色的最终结论。
上下文压缩与多 Agent 委派#
长会话一定会遇到上下文压缩。可读摘要虽然有损，却能检查、修改并交给另一套模型；供应商专属的压缩块可能保留更多内部状态，在原生态里效果更好，但另一套模型只会看到无法解释的内容。因此压缩的最低要求不是“完全无损”，而是留下可以继续工作的交接：
- 当前目标与完成标准；
- 已完成的工作和对应产物；
- 关键决策与没有选择其他方案的原因；
- 失败记录、未解决问题和下一步；
- 需要继续引用的文件、命令与证据。
多 Agent 系统会把缺口进一步放大。Graph 中的每个节点都需要知道自己的输入、范围、工具权限、产物和退出条件；父 Agent 派了什么任务、子 Agent 返回了什么结果、为什么修改某个文件，如果这些信息只存在于不可读消息中，任务失败后就无法判断是规划、委派还是执行出了问题。对多 Agent 来说，可审计不是企业附加项，而是基本调试能力，至少应该留下：
- 任务原文与发起者；
- 使用的模型和工具权限；
- 读取与修改的范围；
- 返回结果和验证状态；
- 与父任务的关系。
模型可以临时，委派记录不能临时；但可审计也不等于永久保存所有原始提示词和敏感数据。密钥、个人信息和无关上下文仍应脱敏，并设置与任务风险相称的保留期限。
怎么把可迁移性落到开发工作#
这封信并不要求每个人先造一套庞大的“统一会话格式”。对实际开发工作，先把真正影响交接的状态留在已有工程载体里就够了：
- 代码、配置和规则留在仓库；
- 任务目标、边界与阶段状态写成可读文件；
- 修改通过 Git diff 和 commit 留痕；
- 工具命令、测试结果和失败原因保留在任务记录；
- 研究引用保存关键摘录，而不只存链接；
- 压缩时生成可读交接摘要；
- 子 Agent 的任务与结果能够回看；
- 生成文件可以下载，不只留下服务端引用。
一份最小交接文件甚至不需要专用工具，可以直接随项目保存在仓库或工作目录中：
# Session handoff
目标与完成标准：已完成工作与产物：关键决策及原因：读取或修改的文件：执行过的命令与验证结果：失败记录和未解决问题：下一步：这和 Trellis、AGENTS.md、任务计划以及 Git 的价值连在一起：目的不是永久保存全部聊天，而是把真正属于项目的状态从聊天产品里拿出来。代码和配置由仓库保存，修改由 diff 与 commit 留痕，命令和测试结果进入任务记录，研究材料保留关键摘录，压缩和委派则生成可读交接。
供应商托管状态仍然可以使用，它在缓存、延迟和长上下文连续性上可能更高效。边界只有一条：它可以加速会话，但不能成为会话唯一可理解的版本。
能离开，才真正拥有#
大多数人不会在一段对话中途频繁切换模型，但可迁移性仍然重要。服务会故障，模型会退役，价格和政策会变化，敏感阶段可能需要转到本地，长期任务也可能跨越多个工具。
真正可带走的不是每一个 Token，更不是保证另一模型无缝复刻原模型。它应该是一份足够完整、可读、可审计的语义记录：新模型能接手，人能解释，用户能删除。
把这封公开信放回 Hermes、Loop 和 Graph 这些长任务场景，会看到同一件事的另一面：额度决定 Agent 能跑多久，会话所有权决定它跑到一半时能不能离开。任务越长，越不能只问“还能不能继续”，还要问“离开这里之后，能不能继续”。
会话所有权最简单的测试：关掉原账户，手里留下的东西，是否足够让另一个模型接着做。
封面使用原文公开 OG 图。