Anthropic 向 Claude Messages API 添加了两个密切相关的测试版功能:按需对话压缩和上下文编辑。两者都针对构建助手和代理的开发人员所熟悉的问题:有用的对话通常比模型的实际上下文预算运行时间更长,特别是当工具调用、检索的文档和多轮指令累积时。

重要的变化是 Anthropic 不仅告诉开发人员自己总结旧消息。其 9 月 14 日的平台发行说明描述了一个 API 级压缩路径,通过 compact-2026-09-04 beta 标头启用,该路径返回一个签名的压缩块。该块可以在以后的请求中替换较早的对话历史记录,而最近的对话保持不变。 Anthropic 还在测试版中引入了上下文编辑,最初侧重于当对话接近令牌限制时自动清除旧的工具结果和工具调用。

对于应用程序团队来说,这是一项可用性功能。对于网关运营商、可观测性供应商和规范跨提供商流量的公司来说,这是一种协议变化。紧凑的克劳德对话不再只是较短的提示。它包含由提供商创建的、应按原样保留的先前上下文的签名表示。

Claude Messages API 中的更改

在传统的长时间运行的聊天集成中,当上下文窗口填满时,开发人员通常会面临三个不完善的选项。他们可以放弃旧的回合,生成自己的摘要,或要求用户重新启动。每个选择都可能会破坏连续性、隐藏重要指令或使调试变得更加困难。

Anthropic 的新压缩测试版将部分工作移至 API 中。 API 可以为早期对话内容生成签名压缩块。随后的请求可以发送该块来代替旧消息,同时保留新对话的逐字记录。这种设计很重要,因为它将紧凑的历史与普通的助理撰写的摘要文本区分开来。将块扁平化为字符串、剥离未知字段或将其视为普通用户消息的网关可能会破坏预期的语义。

上下文编辑会攻击令牌增长的相关来源:工具流量。代理应用程序可以积累大量工具输出、中间调用和过时的观察结果。 Anthropic 表示,测试版最初支持在对话接近令牌限制时自动清除旧工具结果和调用。这对于许多工作流程来说都是有意义的,但这也意味着稍后的模型响应可能取决于提供者端规则有意修剪的对话状态。

这对于在多个模型提供者之上构建 AI 治理 层的团队尤其重要。治理系统不仅需要知道发送了什么提示,还需要知道早期上下文的哪些部分被保留、压缩或删除。

为什么网关不能将其视为通用摘要

直接的实施风险是兼容性。许多 API 网关和 SDK 包装器都会根据已知模式验证请求负载。未知的顶级参数可能会被删除。未知的内容块可能会被强制转换为文本。日志记录管道可能会编辑或转换它们无法识别的字段。这些对于普通元数据来说是合理的默认值,但是当未知对象是模型提供者的上下文管理合约的一部分时,它们是危险的。

Claude 感知网关应该保留新的压缩参数和签名块而不重写它们。它还应该清楚地区分原始消息、压缩上下文和最近未经修改的转折之间的痕迹。这种区别不是学术性的。当客户询问代理为何做出决定时,审计跟踪应显示模型是否有权访问原始工具结果、压缩表示,或者两者都没有。

OpenAI 兼容网关产品面临额外的设计问题。 OpenAI 风格的聊天和响应生态系统有自己的上下文管理模式,包括托管代理状态和特定于提供商的会话处理。 Anthropic 的签名压缩块是一个不同的语义对象。如果系统需要保留提供者保证和重放行为,则称为“摘要”或“内存”的单个通用字段是不够的。

同时支持 OpenAI 兼容路由和人类风格 API 的 Model Gate 风格平台可能因此需要特定于提供者的上下文适配器。这并不意味着每个客户都能看到其中的复杂性。这意味着网关应该提供稳定的外部体验,同时在内部保持 Anthropic 的压缩语义完整。

分析、计费和审计跟踪变得更加复杂

发行说明没有说明签名压缩块的计费方式是否与普通消息文本不同。这个未解决的问题很重要。如果压缩块像任何其他输入一样被计数,计费系统可以将其视为另一个带有令牌的请求组件。如果 Anthropic 应用不同的会计,网关将需要在客户发票和使用导出中清楚地表示这种差异。

即使没有特殊定价,压缩也会改变分析的解释方式。对话可能在消息级别上显得较短,但仍然具有先前较长交流的效果。基本令牌图不会回答以下问题:压缩了多少原始上下文、逐字保留了多少最近上下文、调用压缩的频率以及故障是否与自动清除的工具输出相关。

这些问题属于 AI API 使用情况分析仪表板,而不是埋藏在原始日志中。企业客户越来越希望在同一操作视图中看到成本、模型行为和工具使用。对话压缩为该视图添加了另一个状态转换。

还有一个顺从角度。如果受监管的客户询问助理在特定时间可以使用哪些信息,则操作员不能仅从最终请求正文中回答,除非它了解压缩链。签名块可能有助于保持完整性,但它们并不能消除对仔细保留规则、客户可见跟踪和内部调试工具的需要。

谁应该立即采取行动

直接使用 Claude 的开发人员应检查其 SDK、代理或日志记录中间件是否传递 beta 标头、顶级压缩参数和返回的压缩块是否保持不变。他们还应该测试跨部署、区域或请求转换重放压缩块时的故障行为。

网关团队应该在客户遇到静默降级之前添加架构覆盖范围。最低限度的实际工作是停止删除或重写新字段。更好的版本是在日志、痕迹和使用记录中单独标记压缩上下文。对于已经提供统一 AI API 计费的团队,压缩事件应该足够明显,以便支持团队可以协调令牌使用并解释长时间会话行为。

运行支持代理、编码助理、研究工具或销售副驾驶的企业应将其视为具有治理后果的可靠性功能。压缩可以使长时间的对话更加持久,但它也在可见的聊天记录和模型的实际输入状态之间引入了另一个隐藏层。

悬而未决的问题仍然很重要。 Anthropic 尚未透露压缩区块是否会改变计费代币会计。 Beta 标头的长期稳定性也无法得到保证。而且由于上下文编辑最初侧重于旧工具调用和结果,因此开发人员需要验证默认值与工作流程的契合程度,其中旧工具证据在法律或操作上仍然很重要。

不过,更大的方向是明确的。长上下文管理正在从应用程序粘合代码转移到提供者 API。想要可靠地位于客户和模型提供商之间的网关现在必须在协议级别支持这种移动,而不仅仅是转发较短的提示。