Claude 上线消息线程：长对话不再每轮重传，首字延迟直降三成五

写过长跑 Agent 的人都熟悉这种体验：任务跑到一半，每一轮请求都要把前面几十万 token 的对话、工具结果、截图原封不动再发一遍，模型还没开口，十几秒已经过去了。Anthropic 本周在 Claude Platform 上线公开测试的 message threads（消息线程），针对的就是这个长期被默默忍受的浪费。

核心看点

• 只传增量：首轮发完整对话开一条线程，之后每轮只发新增消息加上一轮响应的线程 ID，不必重传历史。
• 延迟实打实下降：对大多数 Claude Code 用户默认开启后，50 万到 100 万 token 量级的请求，首字延迟（TTFT）中位数下降约 35%。
• 不省钱但省时间：Anthropic 明确说明 token 用量不变——Claude 每轮仍然完整读一遍对话，优化的是「把历史搬过去」这一段等待。
• 线程只在内存里：加密存放、不落盘，最后一次请求后 5 分钟过期；过期后客户端重新发完整对话即可开新线程。

为什么会有这个痛点

一个编码 Agent 在一次会话里发出几百个请求是常态。每个请求都携带此前所有消息和工具结果，随着上下文涨到几十万 token，光是把这些内容送进模型就要消耗可观的时间。这部分时间不产生任何新信息，却直接压在用户等待的第一秒上。上下文越长，浪费越明显——这正是长任务体感「越跑越慢」的技术根源之一。

它是怎么做的

用法并不复杂：在 Messages API 请求里加上 thread 参数。第一个请求照旧带完整对话，同时开启一条线程；后续请求只放新消息和上一轮响应的 ID。服务端在轮次之间把线程留在内存中，加密保存且不写入磁盘，最后一次请求结束 5 分钟后自动过期；一旦过期，客户端重新发送完整对话就能续上一条新线程。

换句话说，Anthropic 把「重复传输」换成了「服务端暂存」。计算量没有减少，省下的是网络传输与服务端组装上下文的开销，而这恰恰是首字延迟里最容易被忽视的一块。

哪些场景最受益

• 长时间编码 Agent：每个工具结果、每次文件编辑都在给对话加料，增量传输的收益随轮次累积。
• 电脑操作类 Agent：截图留在线程里，不必每轮重新上传，带宽和延迟双降。
• 文档与图片密集的工作流：请求体积显著变小，弱网环境下体感差异尤其明显。

反过来，如果只是偶尔做一次短对话，线程带来的差别基本可以忽略——它天生是为「长会话、高轮次」设计的。

几个需要留意的细节

• 不是成本优化：计费口径没变，token 照常消耗，别把它当成省钱手段。
• 5 分钟过期是硬约束：交互节奏慢的场景（人工审批、长时间等待）容易踩到过期，客户端要具备自动回退到全量重发的逻辑。
• 可用范围：目前为公开测试，覆盖原生 Claude Platform，以及 AWS 上的 Claude Platform、Microsoft Foundry 中的 Claude、Google Cloud 上的 Claude 模型（Anthropic 托管版），按标准 token 价格和既有速率限制执行。

总结

消息线程谈不上颠覆，但它解决的是一个非常具体的工程摩擦：上下文越长，重复搬运的成本越高。把这段搬运搬到服务端内存里，换来三成以上的首字延迟改善，对天天挂着长跑 Agent 的开发者来说，属于「上线就该打开」的默认优化。真正值得观察的是后续——当线程可以跨更长时间存活、甚至跨会话复用时，Agent 的交互范式可能会再往前走一步。