长对话提速 35%：Claude 上线消息线程，代理不用再每轮重发全部历史

跑长任务的 AI 代理有个隐形成本：每一轮请求，都要把之前的对话和工具结果重新发一遍。上下文越长，等第一个字的时间就越久。

Anthropic 本周在 Claude Platform 上线 message threads（消息线程）公开 beta：会话只发一次，之后每轮只传新增内容。

核心看点

• 只发增量：Messages API 新增 thread 参数，首轮带全量历史开启线程，后续请求只带新消息和上一次响应的 ID。
• 数字很直接：在 Claude Code 多数用户默认开启的情况下，50 万到 100 万 token 的请求，首字延迟（TTFT）中位数下降约 35%。
• 内存态、会过期：线程在内存中加密保存、不写磁盘，最后一次请求后 5 分钟失效。
• 价格不变：每轮请求体积变小了，但 Claude 仍然读完整上下文，token 用量维持原样。

详细解析

为什么长任务会越跑越慢

一个编码代理在一次会话里可能发出几百次请求：读文件、改代码、跑测试，每一步都要把之前所有的消息和工具结果再发一遍。当对话累积到几十万 token，光是”把历史传过去”就占了相当一部分等待时间，模型还没开始说话，用户已经在等。

消息线程怎么工作

第一次请求照旧带完整对话，并开启一个线程；从第二轮开始，客户端只需要发新产生的消息，加上上一次响应里返回的线程 ID。服务端自己接上之前的上下文。

三个细节值得注意。第一，线程保存在内存里并加密，不落盘。第二，线程是”短命”的：最后一次请求之后 5 分钟过期，客户端要重新发全量历史来开新线程——这适合持续活跃的会话，不适合隔很久才说一句的聊天。第三，省下的是传输时间和首字延迟，不是 token：Claude 每一轮依然会读完整个上下文，计费口径没变。

谁最该用

官方点名三类场景：长时间运行的编码代理（每个工具结果、每次文件修改都在堆上下文）；computer use 类代理（截图留在会话里，不用每轮重传）；文档和图片密集的工作流（请求体积能明显缩小）。一句话，上下文带得越多，收益越大。

在哪能用

目前覆盖原生 Claude Platform，以及 AWS 上的 Claude Platform、Microsoft Foundry 里的 Claude，和 Google Cloud 上 Anthropic 托管的 Claude 模型。标准 token 价格与现有速率限制不变。

总结

消息线程不是什么新模型能力，而是一次针对”代理工程学”的优化：把重复传输的历史砍掉，让长会话的第一个字更快出现。35% 的 TTFT 降幅对交互式编码工具是实打实的体验差异，而对成本敏感的团队来说，账单不会因此变便宜——省下的是时间和带宽，不是 token。

这也透露出 Anthropic 近期的重点：模型本身的迭代之外，越来越多功夫花在”让代理跑得更顺”上。毕竟真正的长任务，瓶颈往往不在智商，而在每一轮的等待。