Claude Message Threads 减少重复上传，但不减少上下文用量

Anthropic 已推出处于公开测试阶段的 Claude message threads，使智能体不必在每次响应前上传完整对话。此次变化旨在解决一个令人沮丧的延迟问题：智能体已经接收过相关信息，但下一次请求仍会再次发送这些内容。Anthropic 表示，减少这种重复有助于 Claude 更快开始响应，尤其是在长时间会话中。

这项日期为 11 月 2 日的公告称，对于包含 50 万至 100 万个 token 的 Claude Code 请求，其中位首次生成 token 的时间降低了约 35%。Token 是模型处理内容时使用的单位。首次生成 token 的时间衡量的是响应开始前的等待时长。这一结果由公司自行报告，并非独立复现的基准测试结果。

核心对比在于：每次重复发送完整历史记录，与仅携带新增内容的增量请求之间的差异。Google 已通过其 Interactions API 提供会话续接功能，可作为有参考价值的行业案例。对开发者而言，Anthropic 的发布提出了一个实际问题：等待时间中有多少来自传输对话历史，而非生成答案？

Claude Message Threads 改变了轮次之间传输的内容

此次发布改变的是对话历史的传输方式，同时保留 Claude 所接收的上下文。

根据 message threads 公告，应用只需发送一次对话内容，后续轮次仅提交新消息。Anthropic 表示，Claude 仍会读取完整对话，因此 token 用量保持不变。该公司将编程智能体、计算机操作智能体和文档密集型工作流列为相关应用场景。

这种区别让此次发布的含义比笼统承诺更快的 AI 更清晰。智能体可能需要花时间收集信息、准备请求、等待响应，并执行下一步操作。改善对话历史的传输，针对的是这一序列中的特定环节。

以一个示例性的编程会话为例。开发者让智能体调查失败的测试、检查相关文件、提出补丁，并评估结果。每项活动都会产生有助于解释下一次决策的材料。即使最新更新很简短，累积的历史记录仍会成为工作记录的一部分。

重复上传会让下一次请求同时携带最新更新和此前的记录。增量请求则改变了这种关系。最新的测试输出可以被传输，而客户端无需再次上传此前的全部内容。

收益取决于旧上下文与新信息之间的关系。简短交流中可消除的重复材料较少。较长的调查则提供了更明显的优化机会，尤其是当最新消息相对于既有历史新增内容不多时。

这也是该公告的意义超出普通聊天场景的原因。智能体应用会在模型决策与外部操作之间反复切换。等待调查完成的用户，会感受到整个工作流的累积过程，其中包括操作之间的停顿。

Anthropic 报告的 Claude Code 部署为其主张提供了具体的产品场景，但也限制了读者应得出的结论。针对长篇编程请求的结果，并不能证明短暂的客户服务交流或文档摘要也会获得同等改善。

因此，这项发布应被理解为针对活跃且持续累积的对话所做的优化。它并不意味着每次 Claude 交互都会按所报告的百分比变得更快。

对于评估该测试版的开发者而言，这种更聚焦的框架很有用。它指出了值得关注的工作负载，以及值得衡量的体验环节。首要问题是，重复传输历史记录是否对应用中观察到的延迟有显著影响。

以这种方式推出的功能，也为平淡无奇的结果留下了空间。一些应用中，等待时间很少归因于这一阶段。即使功能按设计运行，通过测量发现这一点也是有效结果。

智能体开发者面临一个更具体的延迟问题

直接压力落在那些无法解释其智能体时间花在哪里的团队身上。

延迟，即操作与其结果之间的等待时间，往往在用户眼中表现为难以区分的停顿。但在内部，智能体工作流包含多个独立阶段。缓慢的外部搜索与缓慢的模型响应或过大的请求，构成的是不同问题。

message threads 测试版让这种区别更难被忽视。团队在评估它之前，需要先了解现有工作流。否则，整体完成时间的变化可能掩盖真正起作用的机制。

对工程团队而言，实际比较应是在上下文等价、历史记录传递方式不同的情况下完成同一任务。保持任务一致很重要，因为智能体行为可能存在变化。一次较短的运行可能反映的是不同的决策路径，而非同一工作的处理速度更快。

这同样会对产品表述形成压力。将某个智能体描述为更快时，应说明它是更早开始响应、更早完成操作，还是更早完成整个任务。这些结果彼此关联，但回答的是不同的用户关切。

观察智能体调查代码的开发者，可能更重视更快的下一步操作，而非更快出现的一句说明文字。审阅长文档的研究人员，可能更关心最终答案是否有可靠依据。企业买家则可能优先看重稳定完成，而不是最常见响应速度最快。

当应用展示可见的活动指示器时，这一区别尤其相关。界面可以显示工作已经开始，却未必带来有用进展。反过来，短暂的静默间隔之后可能是高效的操作序列。仅衡量界面，无法解决底层性能问题。

Anthropic 的公告给了开发者审视这一差距的理由。如果重复传输占用了有意义的时间，增量请求就能解决真实的摩擦来源。如果另一阶段占主导地位，同一功能对用户可感知体验的影响就会较小。

这是从此次发布中得出的分析含义，而非另一项性能主张。该公告没有提供智能体等待时间的通用拆分。应用团队必须建立自己的基线。

更广泛的产品影响涉及优先级。团队经常要在增加功能与改善现有功能体验之间取舍。熟悉操作之间更快的切换，即使没有改变模型的推理能力或扩展工具集，也可能很重要。

它还可能改变工作流在密切监督下的感受。逐步审阅每个步骤的用户会直接感受到这些停顿。对于无人值守的任务，同样的优化需要结合总完成时间和运行可靠性来评估。

这些差异支持按工作负载采用。面向长时间活跃会话的功能，应在长时间活跃会话中进行测试。将一个标题中的百分比套用于整个产品，会掩盖让该结果具备相关性的条件。

有用的应对方式是更好的监测：将用户可见的延迟与负责该延迟的应用阶段关联起来的记录。这些证据有助于团队决定 message threads 在其他性能投入中的优先位置。

更小的请求与提示缓存解决的是不同问题

减少重复传输和复用先前处理过的上下文，是两种不同的机会。

提示缓存会复用符合条件的早期提示内容，从而减少重复处理。Anthropic 的 提示缓存文档介绍了自动缓存和显式缓存边界。它将一致的提示前缀，即请求中不变的开头部分，作为复用的基础。

这一区别很重要，因为应用可能在不同阶段遇到重复。再次传输旧材料与再次处理旧材料是相关负担。改善其中一个阶段，并不会自动说明另一个阶段会发生什么。

对产品团队而言，实际后果是评估时应将传输行为与缓存行为分开。否则，测试可能把改进归因于错误的功能，也可能忽视已有的配置问题。

Anthropic 的 缓存诊断说明了这一独立关注点。文档指出，工具重新排序、时间戳变化以及对较早消息的编辑，都可能造成缓存未命中。这些属于请求一致性问题，而非关于 message threads 基准测试的证据。

设想一个示例性的研究助手，正在处理一组技术文档。其重复指令保持稳定，而每次调查都会加入新证据。该应用既有理由检查其重复上下文的稳定性，也有理由检查不断增长的对话如何传输。

这些问题需要不同的观察指标。上传测量描述从客户端传输了多少材料。缓存测量描述了复用情况。任务评估则描述最终答案是否满足用户需求。

将这些测量视为可以互换，会导致不佳结论。仅凭更小的请求，并不能证明答案更好。健康的缓存并不能证明外部工具响应很快。快速的初始响应也不能证明最终结果更早到达。

这也解释了为何此次发布不应成为忽视上下文质量的借口。智能体的工作材料仍需与任务相关。高效传输无关的历史记录，不会让这些历史记录变得有用。

这里的编辑判断很直接：减少传输开销，有助于更高效地维持既有工作流。决定哪些内容属于该工作流，仍是应用层面的决策。这些职责在模型请求处相遇，但并非同一项职责。

对开发者而言，这种划分可以改善调试讨论。性能调查可以询问：应用是否发送了过多内容、复用得过少、等待某个工具，或执行了不必要的操作。每种解释都指向不同的干预方式。

它也能抑制对“记忆”的模糊描述。对话记录、可复用的提示前缀和经过整理的知识集合，各自服务于不同目的。将它们都称为记忆，可能掩盖其中涉及的操作选择。

对这一区别感兴趣的读者，可以将 个人知识库作为另一项参考。为未来检索整理材料，回答的是与加速活跃模型对话不同的问题。

Google 提供了参考，但并未决定比较结果

服务端会话续接是一种成熟的设计选择，因此实现细节比新颖性主张更值得关注。

服务端状态意味着提供商会保留可供后续请求引用的信息。Google 的 Interactions API 通过 previous_interaction_id 支持这种模式。其文档还介绍了一种无状态操作选项，即请求不依赖已存储的交互。

这为 Anthropic 的发布提供了有用的参照。两种方法都让应用能够引用先前的对话内容。这种相似性确立了行业参照，而非证明两套系统具有等同的行为。

对于买方而言，类似机制的存在改变了评估问题。有效的比较应聚焦应用的需求：连续性、可恢复性、数据处理、配置灵活性和可观察到的性能。一个共享的功能标签无法回答这些问题。

对于维护不同提供商集成的开发者，同样需要保持谨慎。通用接口可以暴露一个泛化的对话标识符。在应用将不同后端视为可互换之前，仍需审查其周边行为。

一个示例性的智能体框架可能同时支持增量请求和完整历史请求。其产品团队随后需要决定会话在这些路径之间意味着什么。这一决定会影响调试、客户支持和迁移规划。

这一比较也避免得出缺乏依据的竞争结论。Anthropic 的公告并未包含与 Google 对应的基准测试。Google 的文档也未独立验证 Anthropic 所称的延迟数据。两份来源都不足以在等效智能体工作负载中判定速度胜者。

更有力的行业观察在于提供商竞争的方向。模型访问不止包含生成的答案。周边接口决定应用如何将上下文从一个操作延续到下一个操作。

当开发者围绕该接口构建行为时，这一接口尤为重要。应用对延续性的假设会成为其运行模型的一部分。团队应在这些假设变得难以改变之前理解它们。

这并非反对由提供商管理状态，而是主张将其作为应用架构的一部分进行评估。当其行为与工作负载相匹配时，便利性具有实际价值。

无状态操作则有不同的吸引力。应用可以明确构建其提交的历史记录，使该历史在请求边界处可见。应根据应用实际承受的开销来评估这种权衡。

本文的主要比较仍是完整历史传递与增量传递。Google 为这一选择提供了背景。将文章扩展为广泛的模型竞争，会分散对 Anthropic 所发布机制的关注。

对于企业采购而言，这种更窄的比较也更具可操作性。团队可以描述所需行为并直接测试，无需从笼统的提供商排名中推断应用适用性。

由此形成了一个更扎实的竞争框架：提供商提供不同的对话承载方式，开发者必须决定哪一种符合其运营需求。

Beta 版本需要恢复规划和谨慎解读基准测试

有利的中位数结果仍留下重要的应用问题未解。

中位数代表一组测量结果中的中间观测值。它有助于描述典型结果，但并不能描述每一次请求。团队不应将 Anthropic 报告的改进视为每个会话的预期结果。

已发布的公告未提供足够细节，无法独立复现其 Claude Code 结果。读者无法获得对测量请求样本和测试条件的完整说明。恰当的解读仍应是：一项由公司报告、具有明确上下文范围的生产环境观察结果。

消息线程文档 也设定了运行边界。线程在五分钟内没有新请求后会过期；最迟会在最后一次使用后一小时内删除。应用必须保留对话历史，并在延续失败时通过完整历史请求恢复。

Anthropic 描述该功能采用加密的仅内存存储，并且不符合零数据保留资格。零数据保留是在其适用条款下不保留客户内容的数据处理承诺。延续窗口过期与完成删除是不同事件。

这些细节使恢复成为采用决策的一部分。应用必须考虑中断，包括人们监督智能体时常见的普通暂停。相关问题是：当首选的延续路径不可用时，整个工作流如何表现。

设想一个示例性的审查步骤。智能体提出一项变更，随后等待开发者检查结果。尽管时序不同于不间断循环，下一个操作仍属于同一项用户任务。

有代表性的评估应包含这种行为。若只测试持续活跃的智能体，就会为围绕人工审批构建的产品留下缺口。问题在于工作负载适配性，而不是否定该功能的理由。

数据处理同样值得使用精确的语言。临时、加密和仅内存等术语描述的是不同属性。买方应将每种属性映射到目标部署的要求。

这项评估不应从另一项功能借用资格。一个平台可以为不同能力提供不同的数据处理安排。相关审查应针对应用实际启用的能力。

性能测试也需要比典型请求更广泛的视角。团队应检查异常缓慢的响应、恢复事件和已完成的任务结果。这些观察有助于说明，在用户实际遇到的条件下，改进是否仍然有用。

有说服力的评估还应保持答案质量。一次更快开始但遗漏了必要工作的运行，已经改变了任务结果。这会使简单的速度比较产生误导。

因此，这个 Beta 版本带来了有限范围内的机会。开发者可以测试一种特定的开销来源，同时保持更广泛的应用契约不变。他们应在初始响应延迟之外，同时评估连续性和正确性。

这一标准并不需要戏剧性的失败场景。普通中断、不同的上下文规模和熟悉的用户行为即可提供有意义的压力测试。最有用的证据将来自接近实际使用的工作负载。

关注可复现结果、恢复行为和采用情况

下一步证据应将更小的请求与真实智能体工作负载中的可靠改进联系起来。

第一个信号是 Anthropic 公告之外可复现的性能证据。在未来几个月中，开发者评估应明确任务条件、上下文规模、缓存配置和计时阶段。这些细节将使结果更易于解读和比较。

覆盖不同上下文范围的证据尤其有用。它有助于确定收益从何处开始明显，以及何处由其他延迟来源占主导。若与 Anthropic 报告的模式一致，将强化针对性采用的理由。

不同的发现同样能增进理解。一项功能可能对长期编码调查很有价值，而在其他场景中影响较小。报告这一边界，比给出一个脱离应用行为的普遍平均值更有用。

第二个信号是已部署应用中的恢复行为。团队应观察延续失败如何影响用户可见的进展和任务总完成情况。若频繁恢复抹去了预期收益，将削弱这些工作负载的实际价值主张。

可靠的恢复则会支持不同的结论。它将表明，应用可以利用增量传递，而无需让连续性依赖于不间断会话。这对涉及审查、审批和外部服务的工作流尤为重要。

公开的实施报告会对此有所帮助，前提是它们区分观察到的行为与假设。对周边应用的描述，其价值可以不亚于醒目的速度数据。它解释了为什么某个结果适用于一些团队而不适用于其他团队。

第三个信号是在智能体框架和企业部署中的采用情况。框架支持可使能力更易于评估，而部署报告可揭示哪些工作负载特征预示成功。单独任何一个信号都不能证明存在性能优势。

信息量最大的采用报告应说明团队为何启用该功能，以及随后发生了什么变化。它们应将决策与已测量的应用需求联系起来。功能对比中的一个复选框所提供的证据要少得多。

对于知识工作者，面向用户的问题依然很具体：助手是否能以更少的等待时间和相同质量完成熟悉的任务？对于开发者，对应的问题是，测得的收益能否经受中断和正常运营变化的考验。

从团队已经理解的工作流开始。比较等效任务，保留上下文，并记录初始响应时间和完成结果。加入一次带有普通暂停的受监督会话。检查当应用遵循其常规恢复路径时，改进是否仍然可见。解读结果时，应将知识组织与对话传输分开。Claude 消息线程提供了一个特定机会，可减少轮次之间的重复工作。请根据用户实际拥有的体验评估这一机会，然后决定测得的收益是否足以证明为该工作负载启用它。