最近不少开发者在讨论一件事:把和某个大模型的完整对话导出,想换个模型接着干活。结果新模型收到的只是几串解释不通的字符,加一个ID。
问题不在新模型能力不够。问题在于,你手里那份"聊天记录"从一开始就不完整——推理过程、联网搜索、上下文压缩、多智能体通信,正被主流推理API一层层封装成只有供应商自己能解读的私有状态。
两种"一致",不是一回事
这里要先分清两件事,很多讨论把它们混在一起说。
一是模型输出一致性:同一个模型,下次给出的答案是不是稳定、可复现。二是语义会话可携带性:换一家供应商、换一个模型,对方能不能读懂你留下的记录,直接接手往下做。前者是模型能力问题,后者是数据格式和产权问题——这篇文章只谈后者。
判断标准很朴素:不看新模型下一个字符是否和原来一模一样,只看这份存档够不够自解释。不需要旧供应商解密一段密文、记得一次搜索结果、或重构一份摘要,新模型就能看懂并往下做。检查、导出、重放、审计、删除,五件事现在越来越多做不到。
早年调用推理API很简单:发一段输入,收一段输出,两头都攒在自己手里。现在不一样。据 OpenAI 官方文档描述,Responses API 倾向于把每次请求结果存在服务器上,客户端拿到的常常是一个 response.id,下一轮靠这个ID续接上下文;Google Gemini 的新接口走的是类似路子。Anthropic 的思维过程则以整体密封形式返回,官方文档注明这些密封块绑定在生产它的模型上,换模型时理应丢弃——连 Anthropic 自家生态内部都没打算让它跨模型流通。
| 供应商 | 推理状态怎么给你 | 换模型能不能直接读懂 |
|---|---|---|
| OpenAI(Responses API) | 加密返回,常靠 response.id 续接,历史留在服务器 | 不能,密文与ID绑定 |
| Google Gemini | 类似的服务端状态续接方式 | 不能,同上 |
| Anthropic Claude | 思维过程整体密封,绑定生产模型 | 不能,官方文档明确设计为不可跨模型使用 |
这么设计有真实收益:省流量、方便缓存路由、能保留隐藏的推理状态。但代价是,如果本地日志只记了用户消息和最终文本,那个ID就是指向对方数据库的钥匙。钥匙一丢,会话也就丢了。
加密防的是客户端,不是防供应商
不少字段名字取得讨巧,比如 encrypted_content,听着像是给用户的隐私保护。但要说清楚一点:这种密文通常是客户端打不开、只有供应商自己能解的状态,防住的是客户端读取,不是供应商读取——两者不是一回事。
这些设计也确有真实好处。据文档描述,OpenAI 在 store: false 模式下可以把推理过程加密返回、下次请求在内存里解密而不落盘,对要求"零数据保留"的客户是实打实的收益。缓存效率、隐私隔离、性能优化,都是真实存在的动机,不必默认往恶意锁定去想。但不管出发点是什么,客观效果就是:这份记录离开原供应商,就读不懂了。
具体缺口在三处:
- 托管搜索.模型看到的检索段落、排序、被过滤掉的材料,用户往往只拿到几个引用链接,证据本身留在供应商那边。
- 上下文压缩.服务端压缩结果本身不供人阅读,换供应商接手时能看到的只是一段密文,加一小截最近对话。
- 多智能体通信.子智能体之间的指令和消息以密文传递,母应用留存的审计记录里,"这个子智能体到底被要求做了什么"这一项常常是空的。
谁该在意,接下来盯什么
大部分人不会天天换模型接着聊。但服务中断、模型涨价或退役、企业要求敏感阶段本地处理、出问题后需要审计追责——这些场景不需要"经常"迁移会话,只需要"能"迁移。
两类人最该现在就核对清楚:
给智能体产品做架构的开发者,选供应商时该多问一句"能不能导出原始工具调用记录和检索证据",而不是只看输出质量。做采购和合规的团队,该把"可导出条款"写进合同,而不是等到供应商涨价或停服那天才发现记录读不出来。
能落地检查的底线很具体:本地事件日志要能自成一体,不依赖服务器端ID重建;存储与否该是显式选项,而不是默默打开的默认值;任何密文状态旁边,都该配一份供应商中立、人能读懂的交接记录。
接下来值得盯的变量,是会不会有供应商率先把"可导出工具调用与检索证据"做成公开选项,或者行业里出不出现一份供应商中立的交接格式标准。目前看不到这个苗头,这条线还没人主动去守。
会话看着更长,记忆反而更虚。数据落在谁的服务器上,产权的解释权基本就归谁——你以为存下来的是一段完整记忆,供应商其实留了一手,把最耐用的那部分锁在了自己手里。