Claude Message Threads：让长对话少重复上传，恢复责任仍在应用

长任务为什么越来越像重复搬运

一个 Agent 读取资料、调用工具、分析结果，再继续下一步。传统无状态调用通常需要再次携带整段消息历史，随着记录增长，上传与请求处理也会变重。11 月 2 日发布记录提出的 message threads，正是要减少后续轮次重复发送的内容。[1]

文档说明，线程在服务器暂存对话，并在调用模型前重建它。[2] 因而增量发送不等于模型从此只看到新消息，也没有自动缩小上下文窗口中的历史。它主要改变客户端与服务端之间如何交接对话；判断收益时，应先把网络、验证与分词开销，同模型生成和工具等待区分开。

封面为 Token4AI Cloud 原创概念插画：对话卷轴保留在透明容器里，一张新页面跨过桥梁，表示增量传输。它不是产品架构实景、硬件照片或实测延迟图。本文没有进行性能实测，不为公测功能预设固定加速倍数。

创建一次，后续沿响应 ID 继续

文档给出的创建方式，是在正常 Messages 请求中加入 thread 的 type=create，同时发送完整消息、system 与 tools。继续时改为 type=continue，附 previous_message_id，只发送新增消息，并省略 system 与 tools。[2] 关键是沿最新响应 ID 前进，而不是重复使用最初的 ID。

这里存在两类配置责任：system 和 tools 由创建请求建立，模型及若干推理、输出相关设置必须维持文档要求的一致性。若要改变固定字段，应带完整历史创建新线程。[2] 对产品而言，运行中切换模型或替换工具清单，属于需要明确迁移的状态变化，不能简单套上一个继续请求。

工具结果仍属于对话的一部分。应用要把返回内容与前次工具调用正确关联，完整保留消息结构；一次响应生成完毕，并不说明外部动作已经成功。接入 API 服务时，可以把线程支持、请求字段与错误处理列为单独能力，避免从“兼容 Messages”直接推定所有公测特性都被支持。

五分钟过期，不是一小时可继续

官方规定线程在最后一次请求后五分钟过期，最后使用后一小时内删除；这两个时间分别描述继续使用的期限与数据删除期限。[2] 用户停下来思考，或者一个工具运行较久，都可能跨过可继续窗口。应用不能把“尚未删除”理解为线程仍然可用。

文档还说明，服务端保存属于尽力而为，每个响应不会单独确认该轮一定已经存下；通常到下一次继续时才知道是否可用。[2] 所以应用必须保留自己的完整消息副本。SDK helper 会在对象存在时保留内存副本，但如果进程结束后还需要恢复，仍需应用自己的持久化。

当线程无法继续时，恢复方法是用本地完整历史创建新线程，再沿新响应 ID 继续。[2] 但文档提醒，不存在的模型也可能返回 404，不能对所有 404 盲目重放。可设计一次停顿超过有效期的演练，检查错误细节、恢复链路和历史是否完整；这是验证建议，不是本站测试结果。

对话线程，不负责外部动作的恰好一次

线程是追加式结构，每个响应 ID 只能继续一次；已在进行中的继续请求、重复继续和配置不一致都有相应错误。[2] 多个后台任务若同时推进同一对话，容易争用相同位置。应用需要安排单一推进者，或者在确实需要分支时，用完整历史建立独立线程。

更隐蔽的场景是网络中断：客户端不知道请求是否完成，也可能不知道一个外部工具动作是否已经执行。重建对话本身无法撤销发信、写入数据库或提交订单。因此，应在工具系统保留独立的操作标识和结果记录，重试前先检查真实状态，让对话恢复与业务动作恢复各有依据。

在长任务产品中，持久化记录应包括消息、响应 ID、工具调用关联和实际产物位置。若由 Agent 托管服务安排执行，这些记录也应能跨进程恢复。线程减少重复传输的收益，不应以丢失任务审计或引入重复副作用为代价。

费用、缓存与留存，要分别阅读

文档明确指出线程不改变价格与速率限制，prompt caching 需要另外配置。[2] 请求体变小，不等于历史 token 免费，也不等于自动获得缓存命中。评估账单时，应同时查看模型使用量与缓存相关记录，不能把客户端上传字节数直接当作计费 token 数。

数据方面，线程内容在服务器内存中以服务端管理的密钥加密，不写入持久存储，并在规定窗口内删除；该功能不符合 ZDR 条件，也没有列举、读取或主动删除线程的 API。[2] 这些是实际功能边界。选择是否使用时，应对照业务的数据要求，不能用“暂存”一词代替具体留存约定。

一个有意义的评估应比较相同消息、工具与模型设置下，短对话、长对话和中途停顿后的首字延迟，同时记录重放次数、总耗时与成本。若主要时间耗在外部工具，传输优化的总体收益可能有限。先确认瓶颈，再验证恢复质量，才能判断这项公测是否适合当前 Agent 工作流。