跑长任务的人都熟悉的一种浪费
写过智能体循环的人大概都见过这个画面：任务跑到一半，每一轮请求都要把前面几十万 token 的对话、工具返回结果、甚至截图原样再送一次，模型还没开口，十几秒已经过去。一个编码智能体在单次会话里发几百次请求是常事，会话越长，这段不产生任何新信息的搬运就越重。11 月 2 日，Anthropic 在 Claude Platform 的发布说明里把 Messages API 的消息线程（message threads）放进公开测试，beta 标头是 message-threads-2026-08-12，针对的就是这段等待。
接口改动不复杂，拆成三个动作就够看懂。创建：开头那次请求照旧带完整的 messages、system 与 tools，额外加一个 thread 的 create 字段，服务端把这次会话存在该响应编号下。续接：之后每轮只发新增消息，带上 continue 字段与上一轮响应的 previous_message_id，不必再传 system 与 tools，线程沿用创建时的取值。重放：官方把线程定义为尽力而为，续不上时 continue 会返回 404，客户端得拿完整历史重新创建并换用新编号，SDK 里的 thread helper 会自动做这次重放。文档也点名了三类受益场景：长时间编码智能体、电脑操作智能体，以及文档与图片密集的工作流。
省下的到底是哪一段
官方给出的数字是：在 50 万至 100 万 token 量级的请求上，首字延迟中位数下降约 35%，前提是多数 Claude Code 用户已默认开启该特性。多家媒体报道的长对话单次请求体中位数从约 800 KB 降到 1.8 KB，降幅约 99.8%，这个具体数值未见于官方博客，引用时宜标为媒体口径。Anthropic 同时把边界划得很清楚：模型每一轮仍然读取完整会话历史，token 用量不变，定价、速率限制与提示缓存计费规则都不变。换句话说，这是一次传输层与上下文组装的优化，不是一次降价。
把它和提示缓存放在一起看，位置差别就出来了。缓存省的是重复计算，让模型不必重新处理同一段前缀；线程省的是重复上传与服务端重新校验、分词的开销，模型该读的一个字没少。两者可以叠加，但失效语义完全不同：缓存键变了只是多花一次钱，线程过期却会让这一轮请求直接失败。对正在压长任务成本的团队，这个区别比 35% 更该先记下来。也别把站内 2179 号那篇混进来——那篇讲的是别让每一步都重读全部历史，动的是送进模型的内容；这一篇动的是内容怎么送过去，两条路并不互斥，但账要分开算。
状态交出去之后，又回来了一半
消息线程更值得琢磨的地方，是它把一个原本无状态的接口往有状态服务推了一格。按官方文档，线程在两次请求之间以加密形式驻留内存、不落盘，闲置五分钟过期，最迟在最后一次使用一小时后删除；它不适合零数据保留场景，也不适合 HIPAA 相关工作流。服务端保存的是发给模型的对话、创建请求里的 system 与 tools，以及用于校验后续请求的固定字段指纹；文件按引用保存，用线程期间得让这些文件保持可访问。而 MCP 服务器地址、MCP 授权令牌与容器编号都不保存。
于是客户端并没有真的卸下担子：完整历史副本还得自己留着，404 重放要自己兜住，重放期间的幂等与工具副作用要自己保证。过去排查长任务失败，多半先看模型输出或工具报错；现在多了一类「线程还在不在」的故障。把会话状态交给服务端换来了更短的首字等待，代价是故障模型里新增一个与模型能力毫无关系的变量。这笔交换是否划算，取决于你的会话到底有多长——如果日常请求远没到 50 万 token 量级，那 35% 的收益会明显打折，而重放逻辑的复杂度却一分不少。
冷水：公司口径、公测状态与适用量级
分寸说清楚。35% 是 Anthropic 自述的中位数改善，没有第三方复现，也未见按任务类型、工具数量或网络条件拆分的数据；800 KB 到 1.8 KB 来自媒体转述，官方博客里没有这行。功能仍是公开测试，接口行为与标头可能调整，文档也提示线程属于尽力而为。它可以在 Claude Platform 直接使用，也可经 AWS、Microsoft Foundry 与 Google Cloud 接入，但不同渠道下线程的过期与重放语义是否完全一致，公开材料没有展开说明。
能拿走的是判断方法，不是那个百分比：先量自己智能体会话的 token 分布与轮次，再决定要不要接；接入前把重放、幂等与审计三件事补齐。至于更长的会话能否维持同样的延迟改善、线程与提示缓存叠加后的实际账单，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。