要点
- Claude Platform 宣布 Message Threads 公开测试：Agents 不必每轮重发完整对话历史，只需发送自上一轮以来的新增内容，以降低长会话的 time to first token（TTFT）。
- 对多数 Claude Code 用户默认开启；文称 500k 到 1M tokens 的请求，中位 TTFT 约下降 35%。用法：Messages API 增加 `thread` 参数；首请求带全量对话开线程，后续只带新消息与上一响应 ID。
- 线程在轮次间驻留内存、加密且不落盘；距上次请求 5 分钟过期后需重传全量。Claude 每轮仍读取完整对话，故 token 用量与既有费率/限额不变；已在原生 Claude Platform 以及 AWS、Microsoft Foundry、Google Cloud（Anthropic managed）上提供。
Message Threads 解决的是长程 agent 的传输与排队摩擦：编码 agent 动辄上百轮，每轮重传数十万 token 的历史会拖慢「模型开始说话」之前的时间。它不是上下文压缩，也不是降价。
可证伪读法：若独立测量在 500k–1M 上下文、可比网络条件下无法接近约 35% 的中位 TTFT 降幅，或生产中因 5 分钟过期频繁全量重传而抵消收益，则 2026-11-02 公告应主要读作平台传输优化说明，而非长程 agent 成本结构改变；若延迟收益在多云默认路径上可复现，则应上修对「协议层减重」作为 agent 基础设施的权重。
[1]硬事实来自 Claude 官方文章（published 2026-11-02）：public beta；适用长运行编码 agent、computer use（截图留在线程内免每轮重传）、以及文档/图像密集工作流。机制是服务端在轮次间持有线程状态；客户端用上一响应 ID 续写。
明确边界：While each request is smaller with message threads, Claude still reads the full conversation on every turn, so token usage stays the same. Standard Claude token rates and existing rate limits apply。
[1]证据是厂商产品说明加一条内部延迟统计（500k–1M，中位 TTFT ~35%）。未给出测量环境、样本量、P95/P99、对照基线或开源复现脚本。
钢人论证：对以工具循环堆上下文的 agent，首 token 时延是体感与吞吐的真实瓶颈；把历史留在加密内存线程里、只上传增量，是比改模型更直接的系统层修复。钢人之外，5 分钟过期把「长暂停」工作流踢回全量重传；「仍读全量」意味着账单与上下文窗口压力并未消失——优化的是线路，不是智能或价格。
[1]最强钢人：若 Claude Code 默认路径上 35% TTFT 降幅可被外部复现，长会话 agent 的交互密度会上一个台阶，尤其对截图密集的 computer use。
钢人风险：公测范围与多云一致性细节有限；内存驻留线程的故障/迁移语义未展开；开发者若误读为「省 token」，会在成本模型上犯错。
[1]对 agent 构建者，这是延迟工具而非计价工具；对平台竞争，说明长上下文产品开始比拼协议与会话态，而不只是窗口数字。对采购方，合同与容量规划仍应按全量 token 读取计价，把 TTFT 改善单独记为体验项。
[1]短期应用外部 TTFT 复测与真实暂停/恢复工作流检验：若 35% 只在理想连线上成立，或 5 分钟过期频繁吞掉收益，则记为有条件的传输优化；若多云默认路径稳定兑现，Message Threads 会成为长程 agent 的标准会话原语之一。
【No.2】
[1]