不用每轮都重发整段对话：Claude Message Threads 公开测试，长会话首字延迟中位降约 35%

做长会话的开发者都有过这种体验：对话越长，模型回得越慢。不是模型变笨了，而是每一轮都要把整段对话史重新发一遍。2026 年 11 月 2 日，Anthropic 在 Claude 平台上把 Message Threads 推向公开测试，专门对付这个问题。它的承诺很克制，也正因为克制才值得认真看：它不承诺更便宜，不承诺更聪明，只承诺在长对话里让模型更快开始回答。对每天让 Claude Code 跑几百轮的开发者来说，开始回答的速度，本身就是生产力。

这篇先把官方说法、适用边界和没有说清的部分分开讲。官方公告很短，只有几段话，但几段话里藏着一个关键区分：省的是传输和验证的时间，不是算力账单。把这个区分搞混，后面所有的选型判断都会走偏。

以前为什么越聊越慢

在没有线程之前，Messages API 的调用方式是无状态的。每一次请求，客户端都要把系统提示词、可用工具、此前全部消息和工具结果完整发过去，服务端再逐一校验和分词，然后才开始生成。会话刚开始时这点开销几乎感觉不到，对话跑到几十万 token 之后就不一样了：请求体越来越大，模型开口之前要做的准备工作越来越多，用户看到的第一个字来得越来越晚。

Anthropic 在公告里把这个场景说得很具体：一个编码 agent 在一次会话里可能发出几百次请求，每一次都重发此前所有的消息和工具结果。一旦对话达到几十万 token 的规模，重发本身就成了延迟的主要来源。注意这里的措辞，它说的是重发增加了首 token 之前的等待时间，而不是说模型生成变慢了。生成速度没有变，变的是生成开始之前的那段路。

这也是为什么长会话的卡顿特别容易被误诊。很多人第一反应是换更快的模型，或者调低输出长度，但如果瓶颈在请求体本身，换模型只能缓解一部分，输出再短也救不了开口前的等待。线程要修的正是这一段：让后续请求变小，让服务端更快进入生成状态。

线程到底是怎么工作的

用 Anthropic 自己的话说，做法并不复杂。第一次请求照常发送完整对话，同时带上 thread 参数，这就创建了一个线程。此后每一轮，客户端只发新增的消息和上一条回复的编号，服务端在调用模型之前把其余部分拼回来。也就是说，对话史不再是每一轮都要重新搬运的行李，而是暂时寄存在服务端，由编号索引取回。

对直接调 API 的开发者来说，接入点是 Messages API 的 thread 参数，以及配套的测试版请求头 message-threads-2026-08-12。官方 SDK 提供了专门的辅助函数来处理这些细节，开发者不需要自己维护请求头和编号的对应关系。但这不等于可以把线程当成黑盒：线程有明确的生命周期。Anthropic 说，线程在轮次之间保存在内存里，经过加密，不会写到磁盘；上一轮请求之后如果 5 分钟没有新请求，线程就会过期，客户端必须重新发送完整对话，开启一个新线程。

还有一点必须写在前面：线程是尽力而为的。文档的措辞是 best-effort，意思是服务端会尽量保留线程，但不保证每一次续接都成功。你的程序仍然要自己保存一份完整的对话记录，并且准备好在续接失败时完整重发。把线程当成唯一的对话存档，是这次公开测试里最容易犯的错误。线程省的是重复传输，不是替你保管历史。

覆盖范围方面，公告列出了四个入口：原生的 Claude 平台、AWS 上的 Claude 平台、微软 Foundry 里的 Claude，以及谷歌云上由 Anthropic 管理的 Claude 模型。标准 token 价格和现有限速保持不变。需要留意的是，公告没有给出全面可用的日期，也没有单独给线程定价。它现在就是公开测试，身份是测试版功能，不是正式版服务承诺。

省的是时间，不是钱

这是整篇公告里最重要的一句话，Anthropic 自己也把它写明了：虽然每个请求变小了，但 Claude 每一轮仍然会完整阅读整段对话，所以 token 用量不变。换句话说，线程降低的是首 token 延迟，不是账单。官方给出的数字是：在 Claude Code 默认开启线程的大多数用户那里，50 万到 100 万 token 的请求，中位首 token 延迟大约下降 35%。

这个数字要按字面理解。中位不是平均，更不是保证；50 万到 100 万 token 是一个特定的区间，不是所有对话规模。短对话本来就没有多少重发开销，线程带来的提升会小得多，甚至感觉不到。长对话的收益最大，但前提是会话真的活跃、轮次真的密集。如果你的 agent 每轮之间要隔很久才动一次，线程可能在下一轮到来之前就已经过期，收益会被重发吃掉一部分。

把线程和提示词缓存放在一起比较，能更清楚它的位置。缓存处理的是重复内容少算账的问题，线程处理的是重复内容少传输的问题。前者影响成本，后者影响等待。两者可以配合，但不能互相替代。指望线程把账单打下来的人，一定会失望；指望它让长会话的手感变顺的人，才是它的目标用户。

对 vibe 开发者来说，这个区分还有一层实际意义。很多个人项目不是 token 花不起，而是等不起：agent 在修一个跨文件的 bug 时，每一轮都要等模型先把几十万 token 的上下文重新过一遍，开口慢会直接打断调试节奏。线程不改变模型能力，但它把这种等待缩短了，调试循环的体感会明显变好。体感不是虚荣指标，在需要连续判断的长任务里，体感就是效率。

谁最先受益，谁可以先观望

Anthropic 点了三类最适合的场景。第一类是长运行的编码 agent，每一次工具结果和文件修改都会让对话变长；第二类是计算机操作 agent，截图本来就占体积，留在线程里就不用每轮重新上传；第三类是文档和图片密集的工作流，请求体同样会被迅速撑大。这三类有一个共同点：上下文不是一次性的背景资料，而是在会话中不断生长的工作现场。

Claude Code 用户是第一批直接受益的人。公告说，线程已经对大多数 Claude Code 用户默认开启，不需要手动改配置。这句话的边界也值得注意：是大多数，不是全部；是默认开启，不是所有人、所有版本都已覆盖。公告没有给出最低客户端版本号，也没有说服务端开关之外还需要做什么。如果你发现自己的长会话没有变快，先别急着怀疑公告，很可能是你还没落在默认开启的那批用户里，或者会话规模还没到收益明显的区间。

对自己搭建 agent 的团队来说，判断标准可以更直接。先看会话长度：常规对话在几万 token 以内，线程的收益有限，不值得为它重构请求层；再看轮次密度：轮次之间间隔常常超过 5 分钟，线程会频繁过期，收益同样打折；最后看延迟敏感度：如果是后台批量任务，首 token 晚几秒根本不重要，那就更没有必要急着接入。反过来，如果你的 agent 一次会话要跑几百轮、上下文经常冲到几十万 token、用户就在屏幕前等着下一步，那线程就是值得优先试的改动。

还有一类用户应该先观望：对数据留存有特殊要求的团队。文档说明，线程不适用于零数据留存配置和 HIPAA 相关组织，流式输出时也需要等到 message_stop 事件之后再用上一条回复的编号续接，否则可能拿到 404。这些限制不是边角料，它们决定了线程能不能进你的生产环境。合规边界没搞清楚之前，不要把线程写进默认路径。

别把线程当存档，也别把它当缓存

线程的设计里有两个容易误读的点，值得单独拎出来。第一个是过期机制。5 分钟这个数字看起来很短，但它是按上一轮请求来算的，不是按会话开始算的。只要会话保持活跃，线程就会一直续着；一旦人去开会、去吃饭、去处理别的事，回来时线程很可能已经没了。这意味着线程只适合活跃会话，不适合跨越长时间中断的工作流。需要断点续跑的长任务，仍然要靠你自己的持久化存储。

第二个是删除机制。线程保存在加密内存里，不写磁盘，过期后最迟在一小时内被删除。这个设计对隐私是好事，对调试却不友好：线程没有办法通过 API 列出、读取或删除，你不能事后去翻服务端保存的那份对话，也不能主动清理它。调试时如果出现续接失败，你手里唯一可靠的东西还是客户端自己保存的那份完整记录。换句话说，线程越好用，你越不能丢掉自己的那份记录，因为一旦出问题，恢复全靠它。

从工程角度看，正确的姿势是把线程当成加速层，而不是存储层。请求层做两件事：正常情况下走线程，只发新增内容；续接失败时自动回退到完整重发，对用户透明。还要给线程失败单独记日志，否则你会分不清延迟改善到底来自线程，还是来自网络波动。公开测试阶段尤其需要这种可观测性，因为服务端行为还可能调整。

接入之前，先回答五个问题

第一个问题是，你的会话到底有多长。不要凭感觉回答，去日志里看一眼真实分布：如果绝大多数会话在十万 token 以下就结束了，线程带来的首 token 提升可能只有几百毫秒，用户根本感知不到；如果经常冲到五十万 token 以上，线程才值得排进开发计划。没有数据支撑的优化，很容易变成为了新功能而新功能。

第二个问题是，轮次之间隔多久。线程的 5 分钟过期是按上一轮请求算的，不是按会话总时长算的。连续调试、连续改代码的场景最适合它；需要人工审批、需要等外部系统回包、需要人中途去开会的场景，线程会在你回来之前过期。这时候要算的不是单轮省了多少时间，而是重发发生的频率有没有把收益吃掉。

第三个问题是，失败时怎么办。续接失败不是异常情况，而是这个功能设计里本来就存在的一条路径。你的代码必须能自动完整重发，而且重发不能丢工具结果、不能打乱消息顺序、不能让用户看到重复回答。如果你的请求层现在还没有这套回退逻辑，接入线程的第一步不是加参数，而是先把回退逻辑补齐。

第四个问题是，哪些请求不能走线程。文档列出的限制要一条一条对：零数据留存、HIPAA 相关组织、消息批次、按需压缩等场景都不在适用范围内。流式输出也要特别注意，必须等到结束事件之后再续接。这些限制现在看起来是细节，上线之后每一条都可能变成一次线上故障。

第五个问题是，怎么证明它真的变快了。上线之前先记下基线：同样规模的会话，首 token 延迟的中位和分位是多少；上线之后按会话规模分段对比，不要只看整体平均。公开测试阶段的服务端行为还可能调整，没有分段数据，你很难判断一次变慢到底是线程的问题，还是网络和模型负载的问题。把这五个问题答清楚，线程才算真正接进了你的系统，而不是只接进了你的代码。

判断：基础设施的一小步，长会话的一大步

单看公告，Message Threads 不是那种能上头条的大发布。它没有新模型，没有新价格，没有新界面，只是一个 API 参数和一段服务端逻辑。但长会话恰恰是 agent 从演示走向日常工作的瓶颈所在。演示可以只有十轮，日常工作动不动就是几百轮；演示的上下文可以很小，日常工作的上下文只会越来越大。一个只解决开口等待的功能，在演示里看不出价值，在真实工作里却每天都会被感受到。

它的克制也是一种信号。Anthropic 没有把线程包装成省钱方案，没有夸大 35% 的适用范围，也没有掩饰尽力而为和 5 分钟过期这些限制。这种写法让开发者可以做出诚实的预期：它能让长会话更快开始回答，但不能让账单变小，不能替你保存历史，也不能保证每一次续接都成功。把预期放在这个位置上，线程就是一个扎实的改进；把预期放得更高，它一定会让人失望。

对个人开发者和一人团队来说，建议也很简单。先用 Claude Code 的默认体验感受一下长会话有没有变顺，这是零成本的一步。不要一上来就重构自己的请求层，先在真实任务里验证收益是否存在，再决定投入多少工程量。再决定要不要在自己的 agent 里接 thread 参数：会话够长、轮次够密、延迟够敏感，就接；否则先放着，等它从公开测试走向正式版再说。基础设施的改进不怕晚一步，怕的是在没搞清边界的情况下把它写进关键路径，然后在过期和续接失败时付出比延迟更大的代价。

最后留一个值得继续盯的点：线程会不会成为下一代 agent 协议的默认形态。现在的做法仍然是每个厂商各自解决重发问题，线程、缓存、压缩各有各的接口。如果这种服务端暂存对话的模式被证明稳定，下一步很可能是更长的保留时间、更明确的续接语义，甚至跨会话的上下文管理。但在那之前，11 月 2 日这个版本只解决了一个问题：让正在进行的长对话，不用每一轮都从头再讲一遍自己的历史。这个问题很小，小到很容易被忽略；但对每天和长会话打交道的人来说，它恰恰是那种每天都会遇到的摩擦，修掉它，工作的手感就完全不一样了。