2026 年 11 月 2 日，Anthropic 在 Claude 官網發布了〈Make long-running agents faster with message threads〉，宣布 Claude message threads 進入公開測試。它讓長對話後續請求只傳新增內容；最值得讀懂的，是「少重傳」與「少付 token 費」之間的距離。
依同日官方版本紀錄，這次公開測試涵蓋 Claude API、Claude Platform on AWS、Claude in Microsoft Foundry，以及 Claude Models on Google Cloud（Anthropic managed）。下面先還原原文主張，再核對 API 邊界，最後判斷哪些 Agent 工作值得導入。
一、Claude message threads 改的是「再寄一次」
想像你與同事一起修一份很厚的文件：每次補一句話，都把整份文件重新寄出。檔案越積越厚，等待也可能越長。Message threads 讓伺服器短暫保留先前內容，下次帶著上一個回覆的識別碼，補上新訊息即可。這個比喻裡，變少的是重新寄送的包裹，不是同事需要理解的背景。
The more context an agent carries, the more message threads can reduce time to first token.
中文：Agent 攜帶的上下文越多，message threads 能減少的首 token 等待時間就越多。
Anthropic，message threads 發布文章
原文同時說明，Claude 每輪仍讀取完整對話，token 用量維持相同。它把長時間寫程式、電腦操作，以及文件或圖片多的工作列為適用情境。共同點是每一輪只增加一點資料，歷史卻已很大。若你的工作主要是短問短答，先量出等待發生在哪裡，才知道這項改動值多少。
二、35% 量的是首 token 等待，不是整個任務
Anthropic 自報：在 Claude Code 中，對含 50 萬至 100 萬 tokens 的請求，首 token 等待時間（TTFT）中位數約下降 35%。公告也說，多數 Claude Code 使用者預設已啟用。這是特定產品、特定長度區間的公司測量；本文沒有獨立重測該數據，不能把它換寫成「所有 Agent 都快 35%」。
TTFT 問的是「多久開始有輸出」，完整任務時間還可能包括後續生成、工具執行、重試與驗收。假設一輪原本等 10 秒才開始輸出，之後還要 20 秒；若只有前面那段縮短 35%，總時間會從 30 秒降到 26.5 秒，約減少 11.7%。這是說明指標差異的假設算例，並非 Anthropic 或 AlphaLab 的實測。
這不代表改善很小。當任務由許多相依的小步組成，一輪結束才能決定下一輪要做什麼，每輪開始前的空等會一再出現。值得追的問題因此是：你的任務到底有多少時間耗在這一段，以及改善後成功交付一次工作要多久。
三、Claude message threads 與快取，要看不同的帳
Message threads 文件把兩件事分得很清楚：thread 本身不替你啟用 prompt caching，價格與速率限制也維持原規則。Prompt caching則透過重用提示前綴減少重複處理；compaction處理的是長上下文的整理。把它們混在一起，容易把上傳量當成計費量。
| 方法 | 主要改變 | 驗收時看什麼 |
|---|---|---|
| Message threads | 後續請求少傳舊內容 | 請求大小、TTFT、重建對話次數 |
| Prompt caching | 重用已快取的提示前綴 | 快取讀寫量、未快取輸入、成本 |
| Compaction／摘要 | 改變後續保留的上下文內容 | 資訊是否保留、任務品質、上下文長度 |
例如，官方價格表分列一般輸入、快取寫入與快取讀取。看 token 報表時，也要依快取計量說明把 input_tokens、cache_creation_input_tokens、cache_read_input_tokens 一起看；單獨看到第一欄下降，不能認定完整輸入已等比例變少。
因此，「Claude message threads 讓帳單變便宜」不是這份公告所證明的事。你可以同時使用傳輸優化與快取，但測試時要固定快取設定，才能辨認哪一層帶來差異。
四、五分鐘到期，與一小時內刪除，是兩個時鐘
官方11 月 2 日版本紀錄確認：thread 在最後一次請求後五分鐘到期，最後使用後最多一小時內刪除該 thread。五分鐘是續接期限，一小時是刪除上限，不能說成「五分鐘後資料一定已刪光」。
Your application stays the source of truth for the conversation.
中文：你的應用程式仍是對話紀錄的權威來源。
Claude Platform，Message threads 文件
依續接與 replay 說明，thread 採盡力保存；應用程式要保留完整對話，續接失敗時用它重建。SDK helper 的副本放在程序記憶體中；若要跨重啟恢復，應用程式還得另行持久保存。首次請求建立 thread，後續帶上一個回覆 ID 與新增訊息。使用自行組裝的請求時，需要 message-threads-2026-08-12 beta header。這個 header 裡的日期是識別字，不應拿它當公開上線日期。
資料處理也要另查。官方資料保留資格表將 message threads 列為不適用 ZDR（零資料保留）與 HIPAA 資格：對話在記憶體中加密保存、不寫入持久儲存，該 thread 最多一小時內刪除；這不是所有 API 或 Files 資料的統一刪除承諾。對有這些資格要求的工作，這會直接影響能否採用；「只放記憶體」不能替代資格核對。
五、AlphaLab 的判讀：值得採用的，是更順的循環
1. 對話越厚，越值得查清傳輸在等多久
這項更新提醒我們：使用者感覺到的「模型慢」，可能包含模型開始工作前的成本。若團隊只看每秒生成多少 token，就可能錯過每一輪重複搬運資料的等待。改善這一段，能讓程式代理更快取得下一個決策，也讓人在互動時少等一點。它值得量測，卻不能單靠一個百分比替整套系統下結論。
2. 伺服器幫忙保留，不代表產品可以不保存
把 thread 當成捷徑比較合理：捷徑走不通時，你還有完整地圖。應用程式若只保存最後一個 ID，卻丟掉原始訊息與工具結果，就把可恢復性押在短暫狀態上。對要中斷、交接或跨程序工作的 Agent，能否重建對話，應與延遲一起驗收。
3. 品質與費用，仍要有自己的成績單
少搬一次資料可以改善體驗，卻不能由此推導模型更會寫程式、少犯錯，或讀取的歷史已變短。更值得追蹤的是：相同任務是否用更少等待完成、失敗是否仍可恢復，以及每次成功交付的總成本。這三個答案，決定它對你的系統有沒有價值。
我同意的，是把重複傳輸視為長 Agent 循環值得優化的部分；我存疑的，是把公司在特定區間測得的 35%，直接外推成所有工作負載的收益。要檢驗原文「長上下文更受益」的期待，就把相同任務分成不同對話長度，再比較完整延遲分布，而不是只挑最快的一次。
六、下一步：先留一份能對帳、能重建的紀錄
如果你在開發 Agent，先挑一組有固定答案的測試工作，用相同模型、輸出設定與快取配置，比較有無 thread 的請求大小、TTFT 中位數與高延遲尾端、整體完成時間、token 分項與成功率。想把測試接進日常工作，可接著看AI Evals 驗收方法；若困擾是 session 越長越慢，Session 與 Cache 變慢排查能幫你分層定位。再故意安排一次超過五分鐘的停頓，及一次程序重啟，確認應用程式保存的紀錄足以恢復；先用假資料驗證資料流。
如果你主要使用 Claude Code，把注意力放在自己的長任務是否更順即可；公告的「多數預設啟用」不代表你需要手動改 SDK。少等多久，交付有沒有變穩，帳單怎麼算，分開記錄，才是讀懂這次更新的方式。
接著閱讀
左右滑動查看更多推薦
