Claude 终于不用每句话都把聊天记录从头重发一遍了

Claude 终于不用每句话都把聊天记录从头重发一遍了图1

Claude 官方演示视频片尾：message threads 已在 Claude 平台公测（图源：@ClaudeDevs 官方视频）

先介绍下主角：Anthropic 是 Claude 系列大模型背后的美国 AI 公司，开发者通过它的 Messages API（消息接口）调用 Claude。

北京时间 11 月 3 日凌晨 3 点 06 分，官方开发者账号 @ClaudeDevs 宣布：Message threads（消息线程）在 Messages API 上开启公测。以前调用接口，每一轮都得把完整聊天记录重新发一遍；现在服务器会在两轮之间替你暂存对话，你只需发新消息 + 上一条回复的 id，Claude 也能更快开始回答。

官方文档

https://platform.claude.com/docs/en/build-with-claude/message-threads

Claude 终于不用每句话都把聊天记录从头重发一遍了图2

@ClaudeDevs 官方原帖（图源：X @ClaudeDevs）

Claude 终于不用每句话都把聊天记录从头重发一遍了图3

官方文档「Message threads」页面（截图：platform.claude.com）

为什么要做这个？

Messages API 本来是"无状态"的：服务器不记事，每次请求都要带上全部历史。对话一长，尤其是跑几十上百轮的智能体，每轮都要重新上传、校验、切分整段对话。官方文档的说法是：有了线程，请求更小，首字延迟（time to first token）在对话变长时也能保持更低、更稳，长时间运行的智能体循环受益最大。

Claude 终于不用每句话都把聊天记录从头重发一遍了图4

官方视频：第 87 轮时，绝大部分内容其实都是"发过的"（图源：@ClaudeDevs 官方视频）

Claude 终于不用每句话都把聊天记录从头重发一遍了图5

有了线程，之后只发新的部分，完整对话由服务器短暂保管（图源：@ClaudeDevs 官方视频）

怎么用？只加一个 thread 参数

以下细节均来自官方文档：

1. 打开测试开关。每个请求都要带请求头 anthropic-beta: message-threads-2026-08-12。

2. 第一轮"创建"。像平常一样发完整对话、系统提示词和工具，再加上 "thread": {"type": "create"}。服务器会把这段对话连同 Claude 的回复存在这条回复的 id 下。

3. 之后"续上"。只发上一轮之后的新消息，加上 "thread": {"type": "continue", "previous_message_id": "上一条回复的 id"}。系统提示词和工具不要再发，线程会沿用创建时的设置；就算传个空值也会报 400 错误。每次都用最新回复的 id 接着往下，一个 id 只能被续一次，线程只能往后追加。

Claude 终于不用每句话都把聊天记录从头重发一遍了图6

官方文档 cURL 示例·第 1 轮：创建线程（代码摘自 Anthropic 官方文档）

Claude 终于不用每句话都把聊天记录从头重发一遍了图7

官方文档 cURL 示例·第 2 轮：只发新问题和上一轮回复的 id（代码摘自 Anthropic 官方文档）

官方 SDK 还提供了封装：client.beta.messages.thread(...) 建好线程后，反复调用 thread.send(...) 就行，测试请求头自动加上；线程失效时它会自动用完整对话重发一次。

要注意的几个"坑"

只存 5 分钟。线程在最后一次请求后 5 分钟过期，每存下一条新回复就重新计时；最晚在最后一次使用后 1 小时内删除。

尽力而为，别当数据库。线程过期或不可用时，续接请求会返回 404（thread_not_found），你得用完整对话重新创建。官方强调，完整聊天记录仍要由你自己的应用保存，而且也没有接口可以列出、读取或删除线程。

价格和限速都不变。文档写明，线程不改变计费和速率限制。官方博客解释：Claude 依然要"读"完整对话，所以 token 用量和以前一样，省下的是传输和处理时间。

提示词缓存要自己开。线程本身不会帮你缓存提示词。想每轮都命中缓存，要在每个请求里加顶层 "cache_control": {"type": "ephemeral"}（如上方示例）。缓存断点最多 4 个，超了会报错。

有些设置不能中途改。模型、tool_choice、thinking、MCP 服务器、输出配置、顶层 cache_control、测试开关集合等，每次请求都必须和创建时一致，否则报 thread_fingerprint_mismatch。

数据处理。线程只放在内存里、用服务器管理的密钥加密，不写入持久存储；但它不支持零数据保留（ZDR），也不支持 HIPAA。批处理（Message Batches）、token 计数、对话压缩等功能也暂不能和线程一起用。

哪里能用、哪些模型。Claude API、AWS 上的 Claude Platform、Google Cloud 上的 Claude 模型（Anthropic 托管）和 Microsoft Foundry 都已支持。模型方面，文档列出了 Fable 5.1 / 5、Mythos 5.1 / 5 / Preview、Opus 5.5 / 5 / 4.8 / 4.7 / 4.6 / 4.5、Sonnet 5.5 / 5 / 4.6 / 4.5、Haiku 5.5 / 4.5 等。

Claude 终于不用每句话都把聊天记录从头重发一遍了图8

Claude 平台更新日志 11 月 2 日条目（截图：platform.claude.com）

效果有多大？

官方博客给出的数字：对于 50 万到 100 万 token 的超长请求，首字延迟的中位数降低约 35%；目前多数 Claude Code 用户已默认开启线程。这是 Anthropic 自己公布的数据，我们未独立验证。

和 OpenAI 的 previous_response_id 很像

熟悉 OpenAI 的读者会觉得眼熟：OpenAI 的 Responses API 也能用 previous_response_id 接上一轮回复，不用自己重发历史。我们之前写过一篇「认识 OpenAI Response API ，DeepSeek做了哪些适配？」，聊的就是这种"服务端记对话"的接口形态。

从官方文档看，两者思路一致，但 Claude 这版更像一个短时加速缓冲：只存 5 分钟、最长 1 小时、只能往后追加、一个 id 只能续一次，也不能取回内容，主打的是降延迟，而不是帮你长期保管对话。（这一对比是我们基于双方文档的解读，并非 Anthropic 的说法。）

一句话看点

对跑长任务的智能体来说，这是个"白捡"的提速：加一个参数，每轮少传一大段历史，价格不变。只是别忘了，记录还得自己存好，过期了要能重发。