--- layout: post.njk source: https://yage.ai/share/anthropic-message-threads-conversation-state-20261112.html web_feed: articleId: cmwe6uwjc0003n9yes6ah88i9 feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/anthropic-message-threads-conversation-state-20261112.html sourceUrl: https://yage.ai/share/anthropic-message-threads-conversation-state-20261112.html speaker: yage.ai title: |- 从 800 KB 到 1.8 KB，账单却一分不减：为什么英伟达劝你砍掉长上下文，Anthropic 却帮 100 万 Token 修高速路 date: '2026-11-12' summary: 文章讨论了在利用 Claude Code 等工具进行长对话时，如何通过 Message Threads 增量传输协议来优化上下文处理，以解决长对话首字等待时间过长的问题。该协议将长对话单次上传的请求包中位数从约 800 KB 降至 1.8 KB，但模型每轮仍读取完整历史。同时，文章对比了英伟达关于长上下文扩展带来的硬件成本增加的实验结果，并分析了 Anthropic 采用的轻量级内存暂存协议的工程限制，以及与 OpenAI 长连接模式在处理上下文和合规性方面的差异。文章总结了在构建智能体时，应根据算力成本和合规边界选择不同的技术路线，如使用锯齿波模式结合增量传输和上下文压缩，或优先考虑不落盘设置的 WebSocket 长连接模式。 area: tech-engineering category: ai-application tags: - long-context-optimization - incremental-transfer - ai-tooling - context-management - model-efficiency people: [] companies_orgs: - Anthropic - NVIDIA - OpenAI products_models: - Claude Code - Message Threads - SGLang media_books: [] draft: true status: evergreen --- 在利用 Claude Code 对一段复杂的代码进行了几十轮的修改、累计几十万词元之后，很多用户都会遇到一个问题。虽然已经开启了前缀缓存，将前面几轮的计算结果存在显卡显存上复用，但每次只输入继续两个字，还是会等个几秒钟才出来第一个字。为了解决这个问题，Anthropic 在 2026 年 11 月 2 日发布了 Message Threads 增量传输协议，并在 Claude Code 中默认开启了这个功能。 这个改进把长对话单次上传的请求包中位数从 约 800 KB 降到 1.8 KB，让长对话的首字等待时间明显缩短。但官方专门注明，模型每轮仍然会读取完整的对话历史，词元消耗量与账单金额丝毫不减。 巧合的是，仅一天后，英伟达研究院发布了一项 唱反调的实验结果，指出将活跃上下文长度扩展到 25.6 万词元会导致显卡生成每个新词元的硬件成本最高增加到 7 倍，并建议开发者定期压缩旧记录。为何在长对话记录不断变厚的情况下，这两家巨头在同一周做出了相反的决策呢？ ## 显卡里明明已经有前缀缓存，砍掉的那 35% 等待时间藏在哪？ 既然显卡显存里已经有了之前计算好的前缀缓存，为什么后面只发两个字还是慢呢？这是因为前缀缓存只节省了请求到达显卡之后的矩阵计算时间，但管不到显卡大门外的接口网关。 传统无状态接口下，大门口的接口网关对每次请求都是失忆的。聊到深处，客户端必须把之前的历史文本、系统提示词和工具定义重新传一遍。对于每步抓屏的电脑操控任务，StackOne 首席技术官做过计算：走无状态接口连续几十步要累计传 191 MB，改用增量传输只要 7.5 MB。 更隐蔽的延迟出现在服务端接收到数据包以后。Claude 官方接口文档指出，在网关收到请求后，每轮它都必须从头对所有历史消息块做一次格式校验。显卡只认数字编号，于是网关得把几十万词元从头到尾再跑一遍切词器，才能转成数字编号拿去跟显卡里的前缀缓存比对。省去网关层的重复上传、格式校验和重新切词以后，50 万到 100 万词元请求的首字等待时间中位数下降了约 35%。 Message Threads 的解法是在网关内存里加一层有效期 5 分钟的加密缓存。首轮请求发送完整历史并拿到回复编号后，后续轮次只需传上一轮的编号和新增的那句话，连系统提示词和工具定义都不允许重传。如果用户离开太久导致网关内存过期，下一轮请求会收到 404 状态码，客户端再拿本地保存的完整历史重新发起全量请求。 在传统无状态接口下，每轮请求都要重新上传 800 KB 历史并重跑全量校验与切词，而增量传输在网关内存暂存 5 分钟已处理前缀，使首字等待时间缩短 35%，但后端显卡仍读取全量历史。 ## 为什么服务端设 5 分钟闲置过期且只准追加，结果带来四个工程限制？ 既然在服务端存储状态非常有效，为什么 Anthropic 不把聊天记录长久地存储在数据库里，而要做成一个闲置 5 分钟就过期、只能向后追加的临时列表呢？从部署形态看，这套轻量设计与多云分发的工程条件高度契合。 Message Threads 从发布第一天起就同时支持 Anthropic 自己的平台以及亚马逊云、微软云和谷歌云。采用网关内存暂存的轻量协议，客户端自己保留一份完整的草稿，需要时可以重传，各家云平台接入时都无需依赖跨云持久存储。服务端在响应里甚至不会告诉你这一轮存没存上，等到下一轮客户端收到 404 状态码时，再把完整草稿重发一遍。 这个轻量级的协议同时规定了网关内存中的历史消息列表只能向后追加新的轮次，不能修改旧的轮次。一方面，后续的续写请求只传递上一轮回复的编号和本轮新增的消息，服务端没有实现查询、修改或删除旧消息的接口，只是根据编号从内存中取出快照，然后将新消息拼接到末尾。另一方面，网关之所以能省掉重复校验和切词的时间，是因为内存里存好了前几十轮已处理的上下文前缀；如果需要修改旧内容，协议要求直接在客户端修改草稿后，重新发送全量请求以创建新线程。 这种只能增加不能修改旧轮次的规定与 Anthropic 现有的机制有四个直接的冲突。第一是容易导致前缀缓存的手动标记超限。虽然网关会缓存聊天历史，但是显卡不会自动帮你做前缀缓存，所以开发者需要手动告诉显卡缓存到哪一句。传统的做法是在每一轮最新的消息中加一个 cache_control 缓存标记，因为接口的限制，一次请求最多只能出现 4 个这样的标记，所以开发者每次重发整段历史时会把之前轮次的标记删掉，只留下最新的这一个标记。换成增量线程以后，前面发出去的消息无法回头删改；如果首轮系统提示词和工具定义已经占了几个标记，或者等到 5 分钟超时重发整个本地草稿时忘记写代码删掉之前轮次留下的旧标记，一旦单次请求里的标记超过 4 个就会直接返回 400 错误。为了避免这个问题，需要使用全局自动缓存参数，这样服务器会自动将缓存位置移到最后一轮。 第二是跟上下文压缩和上下文清理完全互斥。不论是把历史对话浓缩成文字摘要的上下文压缩功能，还是自动清理旧工具输出与旧思考块的上下文编辑功能，它们本质上都需要在服务端重写历史消息列表。但这跟只允许往后追加的内存列表直接冲突，同时开启会立刻报 400 错误；即使模型在某一轮触发拒答需要删掉该消息，也必须废弃当前线程并重传全量历史。 第三是在服务端主模型拥堵自动切换到备用模型时出现的退化问题。每个线程只绑定了一个模型，主模型拥堵切换到备用模型时，备用模型的回复一律不会存入线程内存。偏偏服务端为了复用备用模型的缓存，在大约 1 小时的粘性路由期内可能会把后续新建线程的请求直接分给备用模型，而且每次回复都会刷新这 1 小时计时，导致官方开发套件在这段时间内可能退化成每轮都重传全量历史。 第四是触犯了金融和医疗客户的零数据留存红线。Message Threads 会把对话内容、系统提示词与工具定义跨请求加密保存在服务端内存中，闲置 5 分钟后过期，最长 1 小时内彻底清除。由于数据跨独立请求留存在服务端内存里，官方明确将这项功能排除在零数据留存和医疗合规的适用范围之外。 相比之下，OpenAI 的 Responses 接口的长连接模式采用了一种不同的连接方式。客户端不再每轮对话都断开重连，直接与服务器建立一个最长可保持 60 分钟不断开连接的 WebSocket 通道。在整个几十步的连续工具调用过程中，最近一次响应状态保存在当前活跃连接的本地内存缓存中，每轮只需发送新增内容，20 步以上工具调用的整体执行速度最高可提升约 40%。同时还可以直接在连接内触发服务端的自动上下文压缩，压缩后无需重传历史。开启不落盘设置后，连接一断开内存缓存即随之销毁，不会写入持久存储，因此可以直接兼容零数据留存的要求。 ## 英伟达刚证明长上下文让显卡贵 7 倍，为什么生产环境还在挂着 50 万词元跑？ 既然长上下文如此笨重，而英伟达研究院又刚刚证明频繁压缩窗口既快又省钱，为什么实际写智能体的团队没有每隔几轮就执行一次压缩，反而还需要 Anthropic 的长上下文增量传输？我们先得算清楚英伟达那篇论文里的显卡物理账。 前缀缓存确实避免了输入阶段的预计算，但在模型开始逐字输出回答的解码阶段，每生成一个新词元，显卡都要把整个历史上下文的前缀缓存从显存里完整读出来。英伟达在数据中心显卡上的聚合吞吐测试显示，把活跃上下文从 1.6 万词元拉长到 25.6 万词元，每生成一个输出词元的显卡成本会飙升 3.6 倍到 7 倍；在桌面级工作站的单请求测试里，部分模型后半程生成单字耗时也会拉长到约两倍。在旗舰闭源模型上通过定期压缩把窗口控制在短范围内，不仅总词元消耗大幅下降，代码修复任务的准确率还能与全量长上下文大致持平。 既然压缩这么划算，那为什么生产环境里的智能体不能频繁压缩呢？工程上的原因出在上下文压缩对多模态内容与历史缓存的破坏性代价上。根据 Anthropic 的 按需上下文压缩文档，一旦触发压缩，服务端会调用模型写一段纯文本摘要来替换旧消息，把此前攒下的所有屏幕截图、图片、PDF 文档和容器上传文件彻底抹除。更麻烦的是，新生成的摘要文字替换了原本的历史消息数组，会让系统提示词之后原本攒好的消息历史前缀缓存作废，下一轮必须重新写入缓存。 所以在实际工程中，长链条智能体更合理的运行轨迹是一条锯齿波。它在集中解决某个子任务的连续几十轮对话里不进行压缩，通过 Message Threads 和前缀缓存逐轮追加，从而保留历史截图、复用显存缓存；等到上下文涨到几十万词元、当前子任务告一段落，它才主动跳出当前线程做一次上下文压缩，把长历史折叠成简短总结，然后开启新线程进入下一段爬坡。 商业上的原因则藏在接口的定价结构里。企业自己买显卡部署开源模型，长上下文让解码变贵烧的是自己的显卡电费，所以英伟达站在算力买方立场劝大家赶紧压缩。但在调用 Anthropic 的商业接口时，输出词元按固定单价计费，解码阶段多烧的显卡带宽成本由接口厂商自己消化；反过来，长对话每轮读取几十万历史词元都要按标准输入单价的 0.1 倍缴纳缓存读取费，挂着几十万词元连续跑几十轮，光重读旧缓存就要交数千万词元的费用。以前长对话每次按回车多卡好几秒，会倒逼开发者写代码截断旧历史；现在 Anthropic 用网关内存治好了卡顿，客观上也减少了开发者主动删减历史的动力，让每轮数十万词元的缓存读取计费得以保留。 生产级智能体在子任务内部依靠增量传输与前缀缓存连续追加几十轮以保留图片与缓存，到达阶段节点后再跳出线程执行一次上下文压缩重置，呈现锯齿波轨迹。 ## 两周内冒出四条对话状态路线，我们写 Agent 时该怎么选？ 把最近这几项技术放在一起看，大家其实是在智能体调用链的不同环节上各自解决自己的痛点。10 月下旬 开源推理引擎 SGLang 将会话状态收进推理服务层，专门对付实时语音对话里的随时打断，让取消信号真正到达计算发生的节点并按播放进度裁剪历史。文本和工具调用场景里，Anthropic 用 5 分钟过期的网关内存省掉重复上传和切词；OpenAI 改用不断开的 WebSocket 通道，任务期间只传增量，配合不落盘设置就能兼容零数据留存合规；英伟达则用定期压缩省下显卡逐字输出时的显存开销。 看清这四条路线的分工后，团队在搭智能体时就能按自己的算力成本和合规边界来做选择。如果团队自己买显卡或租算力跑开源模型，解码阶段的显存开销就是真金白银的瓶颈，应当参考英伟达验证过的有界窗口思路，结合具体模型的压缩耐受度设定短窗口上限（注意部分开源模型压到 1.6 万词元时准确率会大幅下跌，需实测选定阈值）并定期做压缩。 如果团队直接调用 Claude API 来开发长链条的工具型智能体，建议立刻把代码里每轮手动添加的缓存标记改成全局自动缓存参数，并使用锯齿波模式：在单个子任务的执行期内启用 Message Threads 减少长会话的首字等待，等到子任务切换时再主动跳出线程进行一次上下文压缩。而对于那些受零数据留存或医疗合规严格约束、同时工具调用超过 20 步的金融和医疗应用，应该避开跨请求留存内存的 Message Threads，优先评估开启不落盘设置的 OpenAI WebSocket 长连接模式，或者在客户端本地进行上下文裁剪与状态管理。