Claude API 增量传递对话，降低长上下文延迟

长对话调用 Claude 时，等待可能不只发生在模型生成阶段，也发生在把历史记录再次传过去的过程中。Anthropic 推出的 Message Threads 公测功能，允许后续请求只传变化的内容。按官方说法，在 500,000 到 1,000,000 tokens 的请求中，首个 token 等待时间约缩短 35%。

对持续运行的 AI 编程助手，这个方向有实际价值。但它优化的是传输环节，Claude 仍然读取完整历史，因此不能把延迟下降理解成 token 用量下降。

只传新增内容，为什么还能读完整对话

按原文描述，此前每次 API 请求都要重新发送完整对话历史。对话越长，重复传输的内容就越多，尤其是包含大量文档或图片的工作流。

Message Threads 把会话历史保留在服务端，后续请求只传自上一条消息以来发生变化的内容。可以把它理解成：双方已经保存的对话记录，不必每轮再上传一次。

这里需要分清两个范围：客户端本轮发送多少内容，以及 Claude 本轮读取多少上下文。

Message Threads 减少重复传输，但不减少 Claude 读取的历史，也不改变 token 用量。

因此，它解决的不是「如何让模型少读一点」，而是「如何避免把已有内容反复传过去」。原文没有提供 API 名称、请求参数或代码示例，具体接入方式无法仅凭这篇报道确定。

35% 的改善，适用于什么请求

官方给出的数字有明确范围：对于 500,000 到 1,000,000 tokens 的请求，首个 token 等待时间（time to first token，TTFT）约缩短 35%。

TTFT 指请求发出后，到收到第一个输出 token 的等待时间。它关系到用户多久能看到回答开始出现，但不能直接代表整段回答完成得有多快。

所以，这个数字不能直接套到普通短对话，也不能理解为任务总耗时下降 35%。原文没有给出测试环境、样本数量、绝对耗时，或不同长度请求之间的对照结果。这是 Anthropic 披露的数据，报道没有提供独立复测。

Anthropic 认为，受益最多的是 coding agents、computer-use agents，以及处理大量文档或图片的工作流。它们的共同点是上下文容易积累，后续步骤又会继续沿用已有内容。对 AI 编程助手来说，持续多轮执行任务的场景，比一次性问答更贴近这项功能的目标。

五分钟失效，决定了它适合连续工作

Message Threads 会在请求之间将线程加密保存在内存中，但连续五分钟没有活动就会过期。

这个限制会影响使用方式。连续执行的 agent 可能频繁发出请求，而人参与的对话可能停下来读代码、讨论方案，再过一段时间继续。两者能否持续复用线程，条件并不相同。

线程在内存中暂存，不能据此把它当作长期会话存储。

原文没有说明过期后的恢复流程，也没有交代持久化、跨线程复用或其他缓存机制之间的关系。

可用渠道方面，报道列出了 Claude platform，以及 AWS、Microsoft Foundry 和 Google Cloud。但没有展开各渠道的具体接入差异，不能据此假设配置方式完全一致。

我的判断

我认可它针对的问题：如果客户端不断重发大量已有历史，减少重复传输就是直接的优化方向。它也保留了完整上下文，不要求应用先删掉历史内容。

不过，这和裁剪历史、生成摘要解决的是不同问题。后两者会改变交给模型的上下文；Message Threads 保持完整历史，主要调整请求传输方式。若团队的目标是减少 token 用量，仅靠它达不到目的。

35% 值得关注，但目前只能视为带条件的官方测试结果。对国内开发者，自己的网络路径、接入渠道和请求间隔都需要纳入测量。原文没有这些对照数据，不能替一般团队预先认定收益。

能拿来做什么

• 如果正在维护多轮 AI 编程助手，可以记录上下文长度、请求间隔和 TTFT，先判断重复上传历史是否值得优化。
• 如果通过 Node 服务调用 Claude，可以在公测评估中分别观察首个 token 等待时间、完整响应耗时和 token 用量，避免把三种指标混在一起。
• 如果工作流包含人工确认步骤，应检查停顿是否经常超过五分钟，并在接入前查清线程过期后的处理方式。
• 如果主要需求是降低 token 用量，应继续评估历史裁剪或摘要方案，不能用传输优化替代上下文管理。