1. 这次更新改变了哪一层
截至2026年11月4日，Claude Platform 的11月2日更新把 Message Threads 作为测试版开放：首次请求发送完整上下文，之后发送新增消息和前一响应标识。它优化历史的传输、校验与分词路径，不会自动扩大模型上下文窗口。11月3日另有文本水印更新；那是不同能力，不能把二者合称会话持久化升级。
已有 OpenAI 应用可用 previous_response_id 串联 Responses，也可建立 Conversations 对象。真正值得比较的是会话状态由谁保存、失败时如何恢复、下一轮继承了什么。本文提出的架构与测试是工程建议，没有在客户数据或生产模型上执行性能测试。
Claude Platform release notes · Claude Message threads · OpenAI conversation state
2. 四种状态方案放在同一张表里
把业务会话、供应商续接标识和实际执行进度分成三个对象。业务会话属于你的应用；供应商标识只是当前适配器的优化；执行进度则记录哪些读取或写入已经完成。让一个 response ID 同时代表这三件事，会在进程重启和供应商切换时产生歧义。
下表比较状态管理契约，不能直接解读为模型能力或隐私优劣排行榜。不同组织的数据控制、可用模型和产品入口仍须独立核对；Messages 的 message thread 也不同于 Claude Managed Agents 的 session thread。
| 方案 | 谁保存上下文 | 续接与恢复重点 |
|---|---|---|
| 应用侧历史 | 应用保存完整记录 | 每轮自行重放；自己决定裁剪与删除 |
| Claude Message Threads | 短期服务端状态＋应用副本 | 5分钟失效；thread_not_found时以完整历史新建 |
| OpenAI previous_response_id | Responses响应链 | 每轮重发instructions；检查存储设置 |
| OpenAI Conversations | 持久会话对象 | 以conversation管理项目内状态；核对其保留规则 |
3. 两轮对话的最小示例
下面示例使用合成工单，不连接真实订单系统。先安装提供对应功能的官方 SDK，固定依赖版本，并在获准 API 项目中配置自己的密钥与可用模型。代码仅用于说明接口结构，本文没有运行它；发送请求会产生费用。
Claude helper 在首轮发送时创建 thread，并自动附带测试版请求头；第二次 send 只发送新增消息。OpenAI 示例每轮都重发 instructions，因为 previous_response_id 不会继承上一轮顶层 instructions。不要把这个差异隐藏在同一个不透明的跨厂商封装里。
# Documentation example only; not executed for this article.
# Use approved API projects and synthetic input. Requests incur API charges.
import os
import anthropic
from openai import OpenAI
rules = "Use only the synthetic fixture and cite its ticket ID."
a = anthropic.Anthropic()
thread = a.beta.messages.thread(
model=os.environ["CLAUDE_MODEL"], max_tokens=256, system=rules
)
thread.send({"role": "user", "content": "SYN-1: delivery is on Friday."})
reply_a = thread.send({"role": "user", "content": "Which day for SYN-1?"})
# Stored-state example: use only where the project's retention policy permits it.
o = OpenAI()
first = o.responses.create(
model=os.environ["OPENAI_MODEL"], instructions=rules,
input="SYN-1: delivery is on Friday.", store=True
)
reply_o = o.responses.create(
model=os.environ["OPENAI_MODEL"], instructions=rules,
previous_response_id=first.id, input="Which day for SYN-1?", store=True
)
Claude Message threads · Anthropic Python SDK thread helper · OpenAI Responses create: instructions
4. 传输少了，账单是否也会少
Thread 与 prompt cache 解决不同问题。Claude thread 不会自动缓存提示词，缓存断点需要另配；OpenAI 链式响应的先前输入仍作为输入计费。请求体变短只能证明上行数据减少，不能证明历史推理免费、首 token 延迟必然降低某个比例，或业务总费用下降。
原创算例：假设第一轮上行文本为8000单位，此后每轮增加700单位，共20轮。全量重传合计为20×8000＋700×190＝293000单位；增量上传为8000＋19×700＝21300单位。这只是忽略回复和协议开销的传输量推导，既不是 token 账单，也不是延迟基准。实际应分别测量 UTF-8 字节、缓存读写、全部重试及完成一个合格任务的总费用。
Claude Message threads · OpenAI conversation state · Claude prompt caching · OpenAI prompt caching
5. 把过期恢复当作正常路径
Claude thread 是尽力而为的短期状态：末次请求后5分钟失效，失效与最终删除不是同一个时点；文档给出的删除上限是末次使用后1小时。应用必须保留完整的消息副本，SDK helper 的内存历史也不能替代跨进程持久化。
首次响应并不保证该轮已被服务端保存。下一次续接可能返回 thread_not_found；这时按业务历史创建新 thread，而不是重复提交同一个已失效的 ID。以下流程是建议的恢复设计：先确认执行进度，再决定补发模型上下文，避免恢复模型会话时重放业务副作用。
- 写入应用会话账本与配置版本
- 获取单写者租约，读取最新续接标识
- 发送新增消息并记录请求关联
- 成功：提交新ID与已完成工具回执
- 失效：从账本新建状态并重放上下文
- 不确定：先对账，再决定是否恢复
6. 并发、超时与重复工具动作
每个 Claude 响应 ID 只可被续接一次。两个工作进程同时继续同一 ID，会遇到 thread_already_continued 或 thread_continue_in_flight；固定参数改变则可能触发 thread_fingerprint_mismatch。官方列出的这些线程校验错误发生在模型执行前，但不能据此把所有网络超时或所有400错误都当成未执行。
建议给每个业务会话加一个单写者队列，用数据库版本号比较后更新最新标识。工具调用另配业务幂等键，并保存已完成动作的回执。请求超时后先核对账本和工具结果：模型续接的幂等性不等于发邮件、扣款或创建工单的幂等性；流式输出中途断开也不能只凭屏幕上最后一个字推断执行状态。
7. 持久化策略决定能接哪种接口
Claude Message Threads 当前不符合 ZDR：会话在服务端内存中以服务端管理密钥加密，不写入持久存储，并在限定时间内删除。不能将“仅在内存”写成“零保留”。OpenAI 的 Responses 状态和 Conversations 也应按各自数据控制说明判断，不能把一个接口的保存期限套给另一个对象。
先确认组织协议和项目设置允许哪一种状态，再选择实现。若必须自己管理历史，应保留重放所需的完整响应项、工具调用关系与受支持的推理状态，而非只存最终文本。对本地会话账本按租户与用户授权读取，删除与到期策略也应覆盖应用自己的副本。
Claude Message threads · OpenAI API data controls · Claude API data retention
8. 如何做一次能够失败的验收
先固定一个已有正确答案的合成任务集：短对话、长对话、工具回合、服务端状态过期、工作进程重启和两次并发发送。第一轮只比较同一模型的全量重放与 thread，后面再比较模型或供应商；一次改多个因素无法定位收益来源。
记录每项任务是否符合验收、总请求数、上行字节、首 token 与完整耗时、输入输出及缓存量、恢复次数、工具重复执行次数和抵扣前费用。单列失败任务的成本。接受条件应在试点前确定：回答引用正确、恢复后历史完整、工具没有重复副作用；平均延迟更低不能抵消这些错误。
9. 从试点走到长期维护
建议先选一个只有读取动作、对话长度确实较长的工作流试用。保留全量重放适配器作为退路，按会话固定供应商和模型配置，记录配置版本。不要在同一个短期 thread 中悄悄更换 system 或 tools，参数变化应创建新状态。
把过期率、恢复率、完成任务成本和正确率放在同一张运行报表里。如果短任务收益很小、恢复频率高或保留策略不匹配，继续使用应用侧历史同样合理。购买聊天订阅、拥有模型调用资格和获准保存服务端会话，是不同决策；应以实际 API 项目与配置验收。