长对话的成本和延迟，正在从"模型能力问题"变成"接口设计问题"。
发生了什么
Anthropic 为 Messages API 推出了名为 Message Threads 的机制。它的核心改动很朴素：过去每一轮对话，客户端都要把整段历史重新发给模型；现在智能体只传输发生变化的部分。
官方给出的量化结果是，在 50 万到 100 万 token 这一量级的请求上，首字延迟（time to first token）下降约 35%。这个区间值得注意——它不是普通聊天场景，而是长上下文智能体任务才会触及的规模。
为什么重要
无状态 API 是当前主流大模型接口的基本假设：服务端不记住你，每次请求自带全部上下文。这让接口简单、易于横向扩展，但代价随对话变长而线性累积——每一轮都要重新上传、重新计费、重新做前缀处理。
对短对话，这个代价可以忽略；但对跑几十轮工具调用的编码智能体、长文档分析、多步研究流程，重发历史会同时推高延迟和 token 消耗。首字延迟尤其敏感，因为它决定了用户感知到的"卡不卡"，也决定了智能体循环的整体节奏。
Message Threads 本质上是把"会话状态"从客户端负担部分转移到服务端管理，让增量传输成为默认路径。这与行业内围绕上下文缓存、前缀复用的一系列优化方向一致：模型本身没变，变的是喂给模型的方式。
影响与看点
对开发者而言，最直接的影响是长会话智能体的响应体感和调用成本结构可能同时改善，尤其是那些每轮都要携带大量工具定义和历史结果的 agent 工作流。但这也意味着接口语义更复杂：线程如何创建、状态存在哪里、失败重试和并发写入如何处理，都会成为新的工程细节。
值得观察的点有三个。其一，35% 是特定 token 区间的数字，短请求和超长请求上的收益曲线是否同样明显，官方尚未展开。其二，状态托管会引出数据保留与隔离的问题，企业客户会关心线程数据存多久、能否关闭。其三，如果增量传输成为标配，围绕"会话状态管理"的中间层和工具链可能出现新的机会。
一个判断：这次更新的信号意义大于参数意义——长上下文竞争的下一阶段，比拼的不只是窗口有多大，而是长窗口用起来有多便宜、多快。
