長對話只傳新訊息：Anthropic Message Threads 省下的是等待，不是帳單

跟 AI 代理聊得越久，每一輪等待的時間就越長，這件事多數開發者都遇過。原因很直白：傳統 Messages API 的每一輪請求，都要把此前的完整對話重新送一次。對話累積到幾十萬 token，每一輪都在重複上傳、驗證、切分同一段歷史。Anthropic 在 2026 年 11 月初公開的 Message Threads，就是針對這個重複做工而來。

機制：把對話暫存在伺服器端

用日常一點的比喻，傳統做法像是每次回診都把整本病歷重抄一份帶去；Message Threads 則是醫院把病歷建了檔，你回診只要報上病歷號碼，說明這次的新症狀就好。

實際流程分成兩步。第一次請求帶上 thread: {"type": "create"}，連同完整訊息、system prompt（系統提示）與 tools（工具定義）一起送上，回應會附帶一個 ID。之後每一輪改用 thread: {"type": "continue", "previous_message_id": "上一個回應 ID"}，只附新增訊息。

有兩個細節容易踩坑。其一，system prompt 與工具定義只能放在 create 請求，continue 時就算傳空值也會收到 400 錯誤。其二，這個機制做的是減少傳輸與前置處理，模型仍然讀取完整對話脈絡，它不是對話摘要，也不是只看最後幾句。

對建置程式代理、客服代理或文件分析流程的團隊來說，這代表狀態責任的重新分配：對話的一部分脈絡現在存在服務端，應用程式需要處理逾時回放與資料保留的問題，官方 SDK 的 helper 可以代為管理 thread 的建立與延續，自行呼叫 API 則要在每次請求帶上 beta 標頭。

35% 這個數字，量的是特定場景

Anthropic 公布的數據是：在 Claude Code 的 50 萬至 100 萬 token 請求中，首個 token 等待時間（TTFT）中位數約降低 35%。這是廠商自行公布、經 The Decoder 等媒體轉述的數字，公開資料並未附上足以重現結果的測試方法、網路條件或快取設定。

這個限制很重要。50 萬至 100 萬 token 是相當極端的請求長度，一般客服對話或數千 token 的問答，改善幅度沒有依據直接類推。Anthropic 文件將電腦操作代理、文件與圖片密集的工作流列為可能受益的情境，但未逐類提供獨立成效數據。換句話說，這份文件能告訴你哪裡值得測，不能告訴你測了會得到多少。

另外要分清楚的是，少傳資料不等於少付錢。模型仍然讀取完整脈絡，計費的 token 計算邏輯並未因此改變。省下的是每一輪的前置處理與傳輸時間，換算成的是等待體驗，直接連結到 API 帳單的折扣並不存在。這與我們先前分析模型降價競爭比的是單任務成本時的邏輯一致：能力、延遲與帳單是三條不同的軸，一條改善不代表另外兩條跟著動。

導入前該驗收的三件事

對正在評估的團隊，從可確認的資訊整理幾個檢查點。

第一，量自己工作負載的 TTFT，而不是引用 35%。用實際對話長度分布做對照測試，短對話與長對話分開量，才知道改善落在哪裡。如果請求多在一萬 token 以下，這項功能對體驗的影響可能有限。

第二，確認對話狀態的失敗處理。thread 存在服務端，逾時之後如何回放、continue 失敗時能否退回完整重送，這些回退路徑要在導入前跑過一次，而不是等線上事故才發現。這一類「紀錄存在但要能稽核」的課題，在Claude Code 的回答紀錄與稽核差距分析中也曾出現過類似的模式。

第三，釐清資料保留政策。長對話暫存在服務端，涉及客戶資料或內部文件的場景，需要先確認保留期限與刪除機制是否符合自家合規要求。這部分的細節，導入團隊應直接以 Anthropic 官方文件的最新條款為準。

判斷的落點

Message Threads 解決的問題具體而明確：長對話每一輪重送歷史的成本。如果你的應用程式會累積大量上下文，例如反覆帶上程式碼與工具結果的程式代理，或螢幕畫面不斷累積的電腦操作代理，值得排一次實測。至於 35% 這個數字，把它當成廠商在特定場景釋放的訊號就好，採購評估的數字，永遠要用自己的工作負載重測一次。