11 月 2 日，Anthropic 在 Claude 平台上线 message threads 公开测试。一句话概括：以前每一轮请求都要把整段对话历史和工具返回结果重发一遍，现在服务器替你暂存几分钟，下一轮只发新消息和上一条回复的 ID。
这条新闻在中文圈被传成「长对话速度提升 35%」。数字没错，但被压缩得太狠了——35% 是中位 TTFT（从发出请求到收到第一个 token 的等待时间），只在 50 万到 100 万 token 这个量级上成立，而且它省的既不是 Token 也不是钱。这篇把事实拆开，再讲讲它对做 Agent 的人意味着什么。
事实梳理：官方说了什么
- 开放范围：原生 Claude 平台、AWS 上的 Claude、Microsoft Foundry 里的 Claude、Google Cloud 上的 Claude 模型，均为公开测试版。
- 调用方式：首个请求带完整对话、系统提示词与工具定义，标记为新建线程；之后每轮只发新消息 + 上一条回复的 ID。请求头里带 beta 标识（
message-threads-2026-08-12）。 - 效果数据：50 万到 100 万 token 的请求，中位 TTFT 降低约 35%；长对话中单次请求体积的中位数从约 800 KB 降到 1.8 KB。Claude Code 已在公告时对大多数用户默认开启。
- 线程生命周期：每轮之间存在内存里，加密，不写磁盘；最后一次请求后 5 分钟失效，此后请求返回 404，客户端必须重发完整对话重建线程。
- 不减少 Token 消耗：Claude 每轮仍然要读完整对话，所以 token 数和以前一样，标准价格与速率限制不变。
- 约束：线程存续期间不能改系统提示词和工具定义，模型与思考设置也要与首轮一致，要改就得重开线程；不支持零数据保留（ZDR）与 HIPAA；批处理接口暂不支持。
- 未说明：公开测试转正式版的时间表、是否有更长的有效期、企业版的数据留存政策细节。
影响一：延迟这笔账，要拆成四段看
一次 Agent 请求的等待时间大致由四段构成：上传（把请求体送到模型厂商）、排队（厂商侧调度）、预填充（模型读完整上下文）、解码（吐第一个 token）。
threads 只削第一段。所以 35% 这个数字能成立的前提是大上下文——50 万 token 的对话历史是几百 KB 到几 MB，上传本身就要吃掉可观的时间，尤其是在跨境链路上。反过来，一个几千 token 的短对话，开不开 threads 差别小到测不出来。
这也解释了为什么公告里最值钱的数字其实是「800 KB 降到 1.8 KB」，而不是「快 35%」。前者告诉你瓶颈在哪：长会话的延迟有相当一部分不在模型上，在网络上。这个判断对国内团队更有用——调海外 API 的，跨境链路的 RTT 会把上传这一段放大；而如果上下文是本地 RAG 拼出来的几 MB 文本，光序列化和传输就要几秒。
影响二：它和提示词缓存是两件事，别互相替代
最容易混的一点：threads 和 prompt caching 解决的完全是不同层面。
- 提示词缓存：服务端把读过且没变的前缀留在计算层，下一轮不用重算——省的是算力和钱，命中部分按更低价格计费。
- 消息线程：客户端不用重传历史——省的是上传与往返时间，一分钱不省。
官方说明里写得很直白：线程不会自动帮你做缓存，缓存断点还得自己设，示例里两者是一起用的。也就是说，只开 threads 不开 cache，账单一分不变；只开 cache 不开 threads，每次还得传几百 KB。想两头都省，两个都要配。成本口径的完整算法见 Token、工具调用和模型切换的省钱清单，这里只补一条：把「传输开销」也当成成本项，以前大家都忽略了它。
影响三：API 从无状态变有状态，工程债回来了
Messages API 原本是彻底无状态的：你给我全量，我给你回复，服务器不留东西。这是它好扩展、好重试、好做多副本的根本原因。threads 把这个前提改了——服务端要记住这个线程的首轮快照。
由此带来的老问题一个不少：会话亲和（同一个线程的请求要落到能读到它的地方）、断线重连、过期重建。官方给的 5 分钟 TTL 是个硬约束，工程上必须接受一个事实：线程只是加速通道，本地那份完整对话仍然是唯一真相源。客户端要随时能在拿到 404 之后无缝重发全量、重建线程，并且这次重建会打回原形——那一轮就是慢的。
把这件事和 11 月 1 日 DeepSeek 公开的 Super-agent 架构放在一起看，很有意思：那套架构走的是存算分离、端侧无状态 Daemon，把状态推回端侧；Anthropic 这一手是把会话状态收回服务端内存。方向相反，但对，因为优化目标不同——前者优化的是多任务并发与上下文隔离，后者优化的是单会话的往返延迟。
换句话说：上下文放在哪，取决于你优化什么，不存在统一答案。这条对做自研 Agent 网关的人尤其重要，别看到哪家这么做就照搬。
影响四：不能中途改系统提示词，逼你做「稳定前缀」
线程存续期间不能改系统提示词和工具定义，模型和思考设置也必须与首轮一致。这条看着像限制，实际上是在逼一个工程习惯：把每轮都不变的部分（角色、规则、工具清单）和每轮都变的部分（用户输入、工具返回、环境状态）分开。
很多 Agent 现在的做法正好相反：每轮动态拼系统提示词，把当前时间、当前用户、可用工具、待办列表全塞进去。这种写法在无状态 API 下没问题，一开线程就每轮作废、每轮重建，等于白开。
而「稳定前缀 + 变动尾部」这个结构，恰好也是提示词缓存要求的同一种结构。所以这件事的长期价值不在延迟，在于它把上下文工程从「随手拼字符串」推向「分层设计」。分层怎么切、哪些该进常量区、哪些该按需注入，上下文管理那一整套解法 里讲得更细。
老达点评
第一，35% 是 TTFT，不是总时长。一个跑 40 步工具调用的 Agent 任务，每步省下的首 token 等待加起来可能是几十秒，但任务总时长的大头在工具执行和串行等待上。谁要拿这个数字对外宣传「快 35%」，被追问一句「端到端呢」就露了。
第二，不省 Token 这件事是刻意的。省 Token 就等于降收入，厂商没有动力改计费口径；而降低等待时间、让 Agent 用起来更顺，是纯体验收益，不伤收入。看一家厂商在优化什么，比看它发布什么更能判断它的处境。
第三，800 KB → 1.8 KB 是这次最硬的信息。它顺带说明了一件事：很多所谓「模型慢」，其实慢在把几 MB 的历史传过去。这一条对我们自己搭 Agent 的启发很直接——先量一遍请求体大小，再谈要不要换模型。
第四，5 分钟过期是设计而不是缺陷。不做持久化，就不用回答「这些对话存在哪、存多久、谁能看」的一堆合规问题，顺便也绕开了 ZDR 与 HIPAA 的麻烦（代价是这两类场景直接不能用）。这是典型的用产品边界换合规成本，很聪明，但医疗、金融、法务这些行业的企业级 Agent 短期内指望不上。
第五，这是把一个老问题重新提上台面：会话到底该由谁持有。过去两年大家在端侧拼命做记忆、做摘要、做状态机，就是因为 API 无状态；现在厂商开始收回一部分，端侧的活不会消失，只是从「每次都要传」变成「过期了要能重建」。该做的上下文压缩、摘要、分片，一件都少不了，见 记忆设计 那一篇。
对国内团队的三点可用
- 自建网关可以照抄这个模式。大多数国产模型 API 还是无状态的，但你完全可以在自己的网关层做「会话 ID + 增量消息」：客户端只传新消息，网关拼全量再发给模型。省的是你自己客户的流量和你自己内网的 RTT，尤其在移动端弱网场景收益明显。
- 把 TTL 做成可配置，并且一定做降级。网关侧缓存会话，过期或重启之后要能凭客户端带来的全量重建。不做降级，一次网关重启就是一片 500。
- 先量再改。把请求体大小、TTFT、端到端时长分开埋点。很多团队一上来就换模型，结果发现瓶颈在传 3 MB 的图片和 PDF 上——这类问题换什么模型都没用。
没回答的问题
正式版什么时候来、TTL 会不会放长、能不能和批处理配合、企业版对线程数据怎么算留存、以及一个更实际的问题：如果线程中途工具清单变了（比如按需加载工具），除了重开线程还有没有别的路。这几点公告都没说，等后续更新。
最后落一句：这次更新没有让模型变强，它只是承认了一件事——Agent 的体验瓶颈，有一半不在模型里。承认这一点，比发一个新版本更有价值。
