Claude Message Threads 減少重複上傳，不減少 Context 用量

Anthropic 已推出進入公開測試階段的 Claude message threads，讓代理毋須在每次回應前重新上傳整段對話。這項改動針對一個令人困擾的延遲：代理早已接收相關資訊，下一次請求卻再次傳送該些資訊。Anthropic 表示，減少這種重複有助 Claude 更快開始回應，尤其是在長時間工作階段中。

這份日期為 11 月 2 日的公告稱，對於包含 50 萬至 100 萬 tokens 的 Claude Code 請求，中位數首個 token 生成時間降低約 35%。Token 是模型處理內容的單位。首個 token 生成時間衡量的是回應開始前的等候時間。這項結果由公司自行報告，並非由獨立機構重現的基準測試。

核心比較在於：每次請求都重複傳送完整歷史紀錄，與只攜帶新增內容的增量請求之間的差異。Google 已透過其 Interactions API 提供對話延續功能，構成一項有用的業界參考。對開發者而言，Anthropic 的發布帶來一個實際問題：等候時間有多少來自搬運對話歷史，而非生成答案？

Claude Message Threads 改變每輪之間傳送的內容

這項發布改變對話歷史的傳送方式，同時保留 Claude 接收的 context。

根據 message threads 公告，應用程式只需傳送一次對話，後續輪次僅提交新訊息。Anthropic 表示 Claude 仍會讀取完整對話，因此 token 用量維持不變。該公司指出，編碼代理、電腦操作代理及大量文件工作流程均屬相關應用場景。

這個區別令這項發布的意義比泛泛承諾 AI 更快更清晰。代理可能花時間蒐集資料、準備請求、等待回應，以及執行下一項操作。改善對話歷史的傳送，針對的是該流程中的特定環節。

以一個說明性的編碼工作階段為例。開發者要求代理調查失敗的測試、檢查相關檔案、提出修補方案，並評估結果。每項活動均會產生有助解釋下一個決定的資料。即使最新更新很簡短，累積的歷史紀錄仍會成為工作記錄的一部分。

重複上傳會令下一次請求同時攜帶最新更新及先前記錄。增量請求改變了這種關係。最新的測試輸出可被傳送，毋須客戶端再次上傳此前的所有內容。

效益取決於舊有 context 與新資訊之間的關係。簡短交流可消除的重複內容較少。延長的調查則提供更明顯的機會，尤其當最新訊息相對於既有歷史只增加少量內容時。

這亦是為何公告的重要性超出一般聊天。代理應用程式會在模型決策與外部操作之間反覆交替。等待調查完成的使用者，感受到的是整個累積工作流程，包括各項操作之間的停頓。

Anthropic 所報告的 Claude Code 部署，為其說法提供具體的產品情境，但亦限制了讀者應得出的結論。長篇編碼請求的結果，並不能證實在簡短客戶服務交流或文件摘要中會有同等改善。

因此，這項發布應被理解為針對持續進行、內容不斷累積的對話所作的優化。它並不證明每一次 Claude 互動都會按所報告的百分比加快。

對正在評估測試版的開發者而言，這個較收窄的框架很有用。它指出值得關注的工作負載，以及值得量度的體驗環節。首要問題變成：重複傳送歷史紀錄是否對應用程式所觀察到的延遲造成重大影響。

以這種方式界定的發布，也容許出現平淡無奇的結果。部分應用程式由此階段引起的等候時間可能很少。即使功能按設計運作，透過量度得出這項發現也是有效結果。

代理開發者面對更具體的延遲問題

即時壓力落在無法解釋其代理把時間花在何處的團隊身上。

延遲，即操作與其結果之間的等待時間，往往在使用者眼中只是無差別的停頓。然而在內部，代理工作流程包含不同階段。緩慢的外部搜尋，與緩慢的模型回應或過大的請求，構成不同問題。

message threads 測試版令這個區別更難被忽略。團隊在評估它之前，需要先掌握既有工作流程，才能判斷改善幅度。否則，整體完成時間的改變可能掩蓋真正負責的機制。

對工程團隊而言，實際比較是：以相同 context 執行同一項任務，但採用不同的歷史傳送方式。維持任務不變很重要，因為代理行為可以有所差異。較短的執行時間可能反映不同的決策路徑，而非以更快速度處理相同工作。

這也為產品說法帶來壓力。將代理描述為更快，應說明它是更早開始回應、更早完成操作，還是更早完成整個任務。這些結果彼此重疊，但回應的是不同使用者關注。

觀看代理調查程式碼的開發者，可能更重視更快執行下一項操作，而非更快出現一句解釋。審閱長篇文件的研究人員，可能更關心最終有根據的答案。企業買家則可能優先考慮穩定完成，而非最快的典型回應。

這個區別在應用程式顯示可見活動指示器時尤其重要。介面可以顯示工作已開始，卻未必帶來有用進展。相反，短暫的靜默間隔可以先於一連串有效率的操作。單靠量度介面，無法解決底層效能問題。

Anthropic 的公告讓開發者有理由檢視這個落差。若重複傳送佔用大量時間，增量請求便能處理真正的摩擦來源。若另一個階段佔主導，該功能對使用者察覺到的體驗影響便較小。

這是由該發布引申出的分析含意，而非另一項效能聲稱。公告並未提供代理等候時間的通用細分。應用程式團隊必須建立自己的基準。

更廣泛的產品影響關乎優先次序。團隊經常在增加功能與改善既有功能體驗之間作出選擇。加快熟悉操作之間的轉換可以很重要，毋須改變模型的推理能力或擴展工具組。

它亦可能改變密切監督下的工作流程感受。逐步審閱的使用者會直接遇到這些停頓。對於無人看管的任務，同一項優化需要根據總完成時間及營運可靠性作出評估。

這些差異支持按工作負載採用。一項針對長時間、活躍工作階段的功能，應在長時間、活躍工作階段中進行測試。將一個標題百分比套用到整個產品，會掩蓋令該結果具相關性的條件。

有用的回應是更好的儀表監測：把使用者可見的延遲連結至負責該延遲的應用程式階段的紀錄。這些證據有助團隊決定 message threads 在其他效能投資中的位置。

較小請求與 Prompt Caching 處理不同工作

減少重複傳送與重用先前處理的 context，是兩種不同的機會。

Prompt caching 會重用符合資格的早前 prompt 內容，從而減少重複處理。Anthropic 的 prompt caching 文件介紹自動快取及明確的快取邊界。文件將一致的 prompt 前綴，即請求中不變的開頭，視為重用的基礎。

這個區別很重要，因為應用程式可能在不同階段遇到重複問題。再次搬運舊內容與再次處理舊內容是相關負擔。改善其中一個階段，並不會自動說明另一個階段的結果。

對產品團隊而言，實際後果是評估時須將傳送行為與快取行為分開。否則，測試可能將改善歸因於錯誤功能，也可能忽略現有的配置問題。

Anthropic 的 cache diagnostics說明了這項獨立關注。文件指出，工具重新排序、時間戳變動，以及修改較早訊息，均可能導致快取未命中。這些是請求一致性的問題，而非有關 message threads 基準測試的證據。

設想一個說明性的研究助理，正處理一組技術文件。它的重複指示保持穩定，而每次調查均加入新證據。該應用程式有理由同時檢視其重複 context 的穩定性，以及持續增長對話的傳送方式。

這些問題需要不同觀察。上傳量度描述多少資料從客戶端傳送。快取量度描述重用情況。任務評估則描述最終答案是否滿足使用者。

將這些量度視為可互換，容易得出不良結論。較小請求本身並不證實答案更好。健康的快取並不證實外部工具回應迅速。快速的初始回應亦不證實最終結果更早到達。

這亦解釋了為何這項發布不應成為忽視 context 品質的藉口。代理的工作資料仍須與任務相關。有效率地傳送不相關歷史，並不會令那些歷史變得有用。

這裡的編輯判斷很直接：減少傳輸開銷，有助以更有效率的方式維持既有工作流程。決定甚麼內容應屬於該工作流程，仍是應用程式的決定。這些責任在模型請求中相遇，但並非同一種責任。

對開發者而言，這種分隔可改善除錯討論。效能調查可問：應用程式是否傳送太多、重用太少、等候工具，或進行了不必要操作。每種解釋都指向不同的介入方法。

它亦避免對記憶作出模糊描述。對話記錄、可重用的 prompt 前綴，以及經整理的知識集合，各自服務不同目的。將它們全都稱為記憶，可能掩蓋當中的營運選擇。

有興趣了解這個區別的讀者，可將 個人知識庫作為另一個參考點。為日後檢索整理資料，回答的是與加快活躍模型對話不同的問題。

Google 提供參考，但未能定論比較結果

伺服器端對話延續已是既有設計選擇，因此實作細節比新穎性聲稱更值得關注。

伺服器端狀態指供應商保留可供後續請求參照的資訊。Google 的 Interactions API 透過 previous_interaction_id 支援此模式。其文件亦說明無狀態操作選項，讓請求不依賴已儲存的互動記錄。

這為 Anthropic 的發布提供了有用的比較基準。兩種做法均讓應用程式可參照較早前的對話內容。這種相似性確立了業界參考，而非證明兩個系統具有等同的行為。

對買方而言，存在類似機制會改變評估問題。值得比較的是應用程式的需求：連續性、可復原性、資料處理、設定彈性及實際觀察到的效能。共用的功能標籤無法回答這些問題。

對維護不同供應商整合的開發者而言，同樣需要謹慎。通用介面可公開一個通用對話識別碼。然而，應用程式在將不同後端視為可互換前，仍需檢視其周邊行為。

一個示例性的代理框架或會同時支援增量請求及完整歷史記錄請求。其產品團隊便須決定工作階段在這兩條路徑中的含義。這項決定會影響除錯、客戶支援及遷移規劃。

這項比較亦不應得出欠缺根據的競爭結論。Anthropic 的公告未有包含與 Google 對應的基準測試。Google 的文件亦未有獨立驗證 Anthropic 的延遲數字。兩個來源均不足以在等效代理工作負載下判定速度勝方。

較有力的業界觀察在於供應商競爭的方向。模型存取不只包括生成的答案。周邊介面決定應用程式如何把上下文由一項操作帶到下一項操作。

當開發者圍繞該介面建立行為時，這個介面尤其重要。應用程式對延續性的假設會成為其營運模式的一部分。團隊應在這些假設變得難以改變前加以理解。

這並非反對由供應商管理狀態，而是主張將其視為應用程式架構的一部分來評估。當行為配合工作負載時，便利性便具有實際價值。

無狀態操作則有另一種吸引力。應用程式可明確建構所提交的歷史記錄，令該歷史記錄在請求邊界清晰可見。這項取捨值得根據應用程式實際承受的額外負擔作出評估。

本文的主要比較仍是完整歷史記錄傳送與增量傳送。Google 為此選擇提供了背景。將文章轉化為廣泛的模型競爭，會分散對 Anthropic 所發布機制的注意力。

對企業採購而言，這種較聚焦的比較亦更具可操作性。團隊可描述所需行為並直接測試，無須從一般供應商排名推斷應用程式是否適用。

結果是更踏實的競爭框架：供應商提供不同方式來延續對話，而開發者必須決定哪一種符合其營運需要。

Beta 版需要復原規劃及審慎解讀基準測試

有利的中位數結果仍留下重要的應用程式問題未解。

中位數代表一組測量中的中間觀察值。它有助描述典型結果，但並不代表每一項請求。團隊不應將 Anthropic 所報告的改善視為每個工作階段均可預期的結果。

已發布的公告未有提供足夠細節，讓外界可獨立重現其 Claude Code 結果。讀者缺乏對被測請求群組及測試條件的完整說明。較恰當的解讀仍是：這是公司報告的生產環境觀察，並附有特定上下文範圍。

訊息串文件 亦列明營運界限。若五分鐘內沒有另一項請求，訊息串便會到期；最後一次使用後最遲一小時內會被刪除。當延續失敗時，應用程式必須保留對話歷史記錄，並透過完整歷史記錄請求復原。

Anthropic 表示採用加密、僅記憶體儲存，並指出此功能不符合零資料保留資格。零資料保留是在適用條款下不保留客戶內容的資料處理承諾。延續視窗到期與完成刪除是不同事件。

這些細節使復原成為採用決策的一部分。應用程式必須考慮各種中斷，包括人們監督代理時常見的正常停頓。相關問題是，當偏好的延續路徑不可用時，整個工作流程如何運作。

設想一個示例性的審核步驟。代理提出變更，然後等待開發者檢查結果。下一項操作仍屬於同一使用者工作，即使其時間安排與不間斷迴圈不同。

具代表性的評估應包括這種行為。只測試持續活躍的代理，會為圍繞人工審批建立的產品留下缺口。問題在於工作負載是否適配，而非否定此功能的理由。

資料處理同樣值得使用精確的語言。暫時、加密及僅記憶體等詞語描述不同特性。買方應將每項特性對照預定部署的要求。

該評估不應從另一項功能借用資格。平台可為不同能力提供不同的資料處理安排。相關審查應針對應用程式實際啟用的能力。

效能測試亦需要比典型請求更廣闊的視角。團隊應檢視異常緩慢的回應、復原事件及已完成的工作成果。這些觀察有助說明，在使用者遇到的條件下，改善是否仍然有用。

具說服力的評估亦應保留答案質素。若一次執行開始得較快，卻遺漏所需工作，便已改變了工作結果。這會令單純的速度比較產生誤導。

因此，Beta 版帶來的是有界限的機會。開發者可測試特定的額外負擔來源，同時維持更廣泛的應用程式契約完整。除了初始回應延遲外，他們亦應評估連續性及正確性。

這個標準不需要戲劇性的失敗情境。一般中斷、多種上下文大小及熟悉的使用者行為，已能提供具意義的壓力測試。最有用的證據將來自貼近實際使用情況的工作負載。

留意可重現的結果、復原行為及採用情況

下一批證據應把較小請求與真實代理工作負載中可靠的改善連結起來。

第一個訊號是 Anthropic 公告以外可重現的效能證據。未來數月，開發者評估應識別工作條件、上下文大小、快取設定及被計時的階段。這些細節會令結果更容易解讀及比較。

跨不同上下文範圍的證據尤其有用。它有助確立效益在哪個範圍開始變得明顯，以及在哪裡另一種延遲來源佔主導。若與 Anthropic 所報告的模式一致，便會加強針對性採用的理據。

不一致的發現亦會改善理解。一項功能可對長時間的編程調查具有價值，卻在其他情況下影響較小。報告這個界限，比起提出脫離應用程式行為的通用平均值更有用。

第二個訊號是已部署應用程式中的復原行為。團隊應觀察延續失敗如何影響使用者可見的進度及整體工作完成情況。若頻繁復原抹去了預期效益，便會削弱這些工作負載的實際理據。

可靠的復原則會支持另一個結論。它會顯示應用程式可善用增量傳送，而不會令連續性依賴不間斷的工作階段。這對涉及審核、批准及外部服務的工作流程很重要。

公開實作報告會在這方面有所幫助，前提是它們能區分觀察到的行為與假設。對周邊應用程式的描述，其價值可與醒目的速度數字相若。它說明為何結果適用於某些團隊而不適用於其他團隊。

第三個訊號是代理框架及企業部署中的採用情況。框架支援可令一項能力更容易評估，而部署報告可揭示哪些工作負載特徵可預測成功。任何一個訊號本身均不能證明存在效能優勢。

最具資訊價值的採用報告會說明團隊為何啟用此功能，以及其後有何改變。它們應將決定與已量度的應用程式需要連結起來。功能比較中的核取方塊提供的證據少得多。

對知識工作者而言，面向使用者的問題仍然具體：助理是否以更少等待時間、同樣質素完成一項熟悉的工作？對開發者而言，相應問題是量度到的收益能否經受中斷及正常營運變化。

從團隊已了解的工作流程開始。比較等效工作、保留上下文，並記錄初始回應時間及完成結果。加入一次有普通停頓的受監督工作階段。檢查當應用程式遵循其慣常復原路徑時，改善是否仍然可見。解讀結果時，應將知識整理與對話傳輸分開看待。Claude 訊息串提供特定機會，以減少回合之間的重複工作。根據使用者實際體驗評估這個機會，然後決定量度到的效益是否值得為該工作負載啟用此功能。