长会话每轮都重传全部历史：Claude Message Threads 公测，请求从 800KB 压到 1.8KB

11 月 2 日，Anthropic 把 Message Threads 推到了 Messages API 公测。它解决的是长会话 agent 一个很实在的痛点：以前每一轮都要把全部对话历史重新上传一遍，API 再全部校验、分词一遍，会话越长，每轮越慢。现在第一次请求正常发完整对话并建一个 thread，之后每轮只发新消息和上一条回复的 ID，服务器端负责把上下文拼回去。

官方在 Claude Code 上的实测数字值得单独拎出来：50 万到 100 万 token 的请求，首 token 延迟中位数约降低 35%；长对话场景下，单次请求大小中位数从约 800KB 降到 1.8KB。开启方式是一个 beta 请求头和一个新增的 thread 字段，Claude Code 多数用户已默认开启。覆盖范围包括原生 Claude 平台、AWS、Microsoft Foundry 和 Google Cloud 上的 Anthropic 管理模型。

但有三个边界必须先说清，否则很容易用错。第一，它省的是传输和重复校验，不是 token 账单：Claude 每一轮仍然读完整对话，输入 token 照常计费，价格和速率限制不变。第二，thread 是尽力而为的短期缓存，5 分钟无请求就过期，内容只放内存、加密、不落盘，最晚在最后一次使用后 1 小时内删除；过期了就得重发完整对话建新 thread。第三，它不适用零数据留存和 HIPAA 配置，也不兼容 Message Batches、token 计数和按需压缩等功能。

我的判断：这是一个延迟优化，不是成本优化。对长会话编码 agent、带截图的计算机操作 agent、文档和图片密集的工作流，它值得开；对短对话、偶尔聊两句的场景，它几乎没有感知。真正容易踩的坑不是接不接入，而是把服务器端的 thread 当成对话的唯一存档——Anthropic 自己也要求应用保留完整副本，因为它没有提供查询和管理已存 thread 的接口。

怎么用起来：接入时把“自己存一份完整对话”写进设计里，thread 只当加速层；SDK 自带的 thread 助手会在特定续跑错误时自动重发一次完整对话，但无服务器、队列 worker 这类会重启的环境，还是要自己持久化消息。流式场景下，等到 message_stop 事件之后再用新回复 ID 续跑，否则可能拿到 404。

这个结论在什么情况下不成立：如果你的 agent 每轮间隔经常超过 5 分钟，或者合规要求零数据留存、HIPAA，那么这个功能要么频繁重建、收益打折，要么根本不能用——先看合规和会话节奏，再谈延迟收益。