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