Anthropic · 官方文章与 API 文档 · 阅读原文
发现渠道：AIHOT · 精选线索
长时间运行的编程 Agent 每完成一次工具调用，往往就把此前的对话、工具结果和图片再发送一遍。历史越来越长，客户端上传、服务端校验和分词都会增加等待。Anthropic 将 message threads 开放公测：首轮发送完整会话，后续只发送新增消息与上一轮响应的 ID，由服务端接回已有对话。
官方称，Claude Code 中50万至100万 token 请求的首 token 等待时间中位数下降约35%。这是这一长度区间的等待指标，并非整个任务耗时下降35%。线程以加密形式暂存在内存，距上次请求5分钟后到期；应用仍须保存完整历史，在无法续接时重新创建线程。模型每轮看到的完整对话没有变，token 使用量也不因少上传而减少。
文档还区分了两种经常混淆的复用：线程保存消息，prompt caching 则需要另行设置缓存控制。前者不会自动打开后者。线程只能追加，每个响应 ID 只能继续一次；改系统提示、工具定义或旧消息，需要用完整历史开启新线程。这让活跃、连续的长会话更轻，却要求客户端从开始就设计好回放路径。
可信度 65 · 重要性 78 · 新颖度 72
技术与主题
Agent 系统 · 系统与效率 · 消息线程 · 首token延迟 · 请求回放 · 提示缓存
0xtechdean
9月30日针对Claude Code 2.1.282的公开使用报告；不是本次公测的独立性能测试。
忠实转述（非原句）：作者用同任务、同仓库比较默认连接与透传代理，发现代理路径同时丢掉 dispatch 和 message threads，出现并行工具调用的会话从6/6变成1/7。单独恢复线程的4次测试仍没有并行调用。他要求合规网关能保留相同行为，也希望有明确的全历史请求选项。样本很小，两个特性互相影响，不能把差异全算给线程。
编辑评读
这项改动的价值来自把“重复搬运”和“模型计算”分开。假如一个Agent每轮只多一小段工具结果，却反复上传很长的旧历史，缩小请求确实能改善交互；如果主要时间花在工具执行或生成答案上，同样的接口变化对最终交付帮助可能很小。使用前先看时间分布，比把官方的35%直接代入总耗时更可靠。
线程过期或续接失败时，客户端还得把会话恢复出来。服务端线程只是暂存副本，应用保留的完整会话才负责跨进程恢复。可以在测试环境安排一次超过有效期的停顿，核对新线程是否恢复了相同消息，并分别记录正常续接与回放的等待。代理网关还应检查实际发送的字段，不能只看SDK方法名。下述旧版本问题报告说明集成路径可能改变行为，但它同时变动多个特性，无法证明线程单独决定并行工具调用。
需要留意
- 官方聚合延迟数据未提供本地独立复测。
- 旧版本代理问题不代表当前所有接入路径；本期未测试该问题是否仍可复现。