Context Lifecycle Management

資料來源#

• Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems
• From Agent Behaviour to Agent-Friendly Documentation
• RCWT: Measuring Task-Budget Displacement from Coordination Content in LLM Calls
• Security Incident INC-2026-07-28-01
• Self-GC: Self-Governing Context for Long-Horizon LLM Agents
• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents
• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking

摘要#

目前大多數已部署的脈絡管理，會把代理程式歷史視為線性 token 緩衝區：執行期間依年限／長度／類型修剪片段，或等到脈絡視窗填滿時請模型摘要。Self-GC（Xubin Hao、Hongjin Meng、Xin Yin、Jiawei Zhu、Chenpeng Cao — Xiaohongshu，arXiv 2607.00692，2026-07-01，empirical）主張這兩種方式採用了錯誤的資料模型。長時程代理程式脈絡是具不同生命週期需求的執行期物件集合：有些已過時，有些重複但在結構上仍有用，有些體積龐大卻必須能夠精確復原。編輯是否安全，不取決於時間順序，而取決於該物件是否會成為未來工作的相依項目。

這個名稱刻意呼應垃圾回收，而這個類比是設計的關鍵：系統不只回收未使用的 token，還會管理物件生命週期——配置（穩定 ID）、狀態（active / folded / masked / pruned），以及對任何移出即時檢視內容的資料提供復原路徑（側車儲存）。

這是本語料庫首篇針對此主題的實測研究；此前相關內容多來自供應商與實務工作者的來源（Context Window Smart Zone、/compact、自動壓縮）。若其測量結果與那些說法相關，應以測量結果為準——見下文與實務工作者說法的測量對照。

三種脈絡管理類型#

類型	機制	損失內容
執行中啟發式方法	按時間順序修剪、遮蔽工具輸出、貪婪刪除工具內容	「便宜但看不見未來相依性」——無法判斷舊工具輸出是否含有後續步驟唯一需要的 URL、表格值、檔案路徑或可編輯本文
視窗結束時自行摘要	模型在接近上限時摘要先前互動	「保留敘事狀態，卻隱藏精確證據、定位資訊與可編輯產物」——壓縮成無法再定位、稽核或還原的散文
物件生命週期（Self-GC）	索引物件 + 規劃器提議折疊／遮蔽／修剪 + harness 強制復原	修剪率：刻意刪除較少（見下方取捨）

Self-GC 與記憶儲存系統（MemGPT、Mem0、A-MEM、HippoRAG）互補——那些系統把知識移出執行流程；此方法則管理執行期間的作用中提示檢視內容。它也位於 KV 層之上：H2O、SnapKV、PyramidKV 等系統會在模型內部淘汰內容；Self-GC 則編輯語意層的作用中檢視內容，只有在節省值得打破快取時才提交。

索引化脈絡物件#

逐字稿會被映射成可定址物件，而非原始訊息文字；ID 由工作階段區域內的單調配置器產生：

• conversation:user:k — 可見的使用者請求及其後續執行片段。ID 位於該回合的標頭中繼資料。
• function:<tool>:n — 工具層級片段，可獨立編輯。ID 是輕量級 XML 邊界標記。
• 助理回合不是一級 GC 目標 — 它們承載銜接文字與工具呼叫封套，因此相鄰物件變更時，harness 會保留或正規化這些內容。（圖 7 明確呈現此點：助理銜接文字完全位於物件模型之外。）

這些 ID 是控制中繼資料，不是助理散文，因此規劃器會指定精確物件，而 harness 則在不使用模糊文字比對的情況下重播、驗證並復原。索引有三項用途：提供規劃器穩定的目標、讓 harness 管理生命週期狀態，以及將復原路徑與摘要文字分開。壓縮後的作用中檢視內容仍可指向位元組完全相同的折疊負載——這正是它與最終摘要的核心差異。

折疊、遮蔽、修剪#

每個物件最多套用一種生命週期操作。圖 3 提供具體的前後對照，本文文字本身沒有詳述：

• 折疊 — 精確負載移至側車檔案（markdown，例如 fold-recover/__webfetch_4.md），並在檢視內容中留下精簡的復原指標。該指標會以 <system-reminder> 控制平面區塊形式注入相關的使用者訊息，而不是助理撰寫的文字——如此可降低後續助理回合仿效內部折疊標籤的機率。折疊適用於大型且穩定的本文，這些內容可能需要具冪等性的復原（例如產生的報告本文、可編輯的 SQL／指令碼區塊）。
• 遮蔽 — 保留物件邊界，省略低訊號的中段。實作會保留本文大約前 10% 和後 10%（圖 3 和圖 7）。適用於重複的日誌類輸出；明確不適用於稀疏表格、堆疊追蹤與差異區塊，因為訊號位於中段。圖 3 也指出，含有影像的工具結果會退化為修剪——影像負載無法透過遮蔽復原。
• 修剪 — 移除過時內容，不保證可復原；投影正規化期間會剝除相符的助理工具呼叫封套。僅用於過時的失敗嘗試與已被取代的讀取結果。

對照代理程式軌跡：失敗的命令日誌會被修剪，重複的瀏覽器快照會被遮蔽，產生的報告本文則必須折疊，以便後續回合能精確引用或修訂。

規劃 → 演練 → 提交#

分工是此設計主張的核心：模型提供對未來價值的語意判斷；harness 則強制執行期不變條件。

1. 規劃（側通道）。 遇到 token 壓力、回合邊界或政策觸發時，harness 會分岔目前的前綴，並附加僅供規劃器使用的指示。規劃器會看到索引物件並輸出 XML——一個 <above_conversation_summary>，以及一個 <gc_plan>，其中列出分組的 fold／mask／prune 目標，且只能指定既有識別碼。它絕不會改寫對話或產生作用中檢視內容。提示是一份物件操作契約，不是摘要提示：依序提供排除 → 相依性 → 粒度 → 操作 → 合理性檢查規則，並搭配少量範例，針對精確錨點、可編輯產物、有效控制代碼與有來源支援的證據進行校準。
2. 演練（本機，在主迴圈之外）。 harness 解析目標、捨棄無效或截斷回合的編輯、正規化重疊操作、產生投影檢視內容，並估算節省量。遭拒的計畫絕不會影響主要代理程式迴圈（圖 6 顯示計畫 #2 在演練階段遭捨棄，時間軸完全不受影響）。
3. 提交（僅在安全回合邊界）。 通過的計畫會維持待處理狀態，直到安全邊界到來；此時 harness 會與目前檢視內容合併、將父系脈絡修復至最近仍存續的祖先、保存側車檔案，並正規化供應商訊息。

最近一回合的保留是由 harness 強制執行，而非仰賴規劃器——稽核說明了原因：規劃器確實會嘗試壓縮最新可見的使用者回合（Qwen3.6-Plus 在 330 份解析計畫中有 25 次，Qwen3.7-Max 有 15 次，GLM-5.1 有 12 次）。提示通常有效；確定性篩選器就是用來處理殘餘風險。

具快取感知的提交#

提交 GC 計畫會改變作用中檢視內容，因此會使部分供應商前綴快取失效——這就是為什麼天真的修剪即使減少 token 數，也可能提高成本。Self-GC 會評估這項決策：

CommitBenefit ≈ N_future · (C − C′) − L_cache_break − L_GC

C／C′ 分別是提交前後的平均輸入成本，N_future 是預期重用次數，最後兩項則是快取中斷與 GC 開銷，包含側通道規劃器呼叫。一項以觀察到的觸發點進行的部署回歸分析發現，預期作用中檢視修剪量超過 0.3 後，立即提交才有正向價值；低於此值時，計畫可以維持待處理狀態，直到快取到期或進入下一個任務邊界。論文明確指出，這是操作政策，而非普遍常數。

圖 6 直接呈現此機制：穩定的前綴快取命中貫穿整個工作階段，提交只會使後綴失效，尾端則重新快取。這正是 Cost-per-Task Over Cost-per-Token 缺少 token 軸的原因——脈絡管理政策就是成本政策，而 token 減量與計費成本可能朝相反方向變動。這也是 Agent Context Files 與 Client-Side Agent Optimization 中快取穩定性警告的量化版本：除非預期節省足以彌補成本，否則不要在工作階段中途打斷前綴快取。

測量結果#

無影響率是關鍵指標，而且是越高越好：給定保留的前綴、候選計畫、前後修補內容，以及真實的未來回合，GPT-5.5 評審會檢查精確 URL、路徑、列值、任務識別碼、可編輯本文，以及有來源支援的證據是否仍可取得。僅有敘事連貫性明確不足以通過。報告採用 Wilson 95% 信賴區間。修剪率是移除的前綴 token 平均比例。

資料集取自生產環境：15,141 筆原始軌跡列 → 9,075 筆由壓縮觸發的軌跡 → 332 個工作階段的 Production Suite 與 33 個工作階段的 Hard Set（持續工具壓力最高，內容偏向瀏覽器／shell／網頁擷取）。

Hard Set (n=33) — 無影響率越高越好：

方法	修剪 %	無影響 %	95% CI
最舊回合	63.45	66.67	[49.61, 80.25]
工具修剪	67.93	69.70	[52.66, 82.62]
工具遮蔽+修剪	61.90	54.55	[37.99, 70.16]
混合式	69.87	57.58	[40.81, 72.76]
Self-GC	43.95	84.85	[69.08, 93.35]

Production Suite (n=332)：

方法	修剪 %	無影響 %	95% CI
最舊回合	40.19	87.46	[83.46, 90.60]
工具修剪	47.76	77.71	[72.93, 81.86]
工具遮蔽+修剪	47.75	80.12	[75.49, 84.06]
混合式	46.28	83.73	[79.38, 87.31]
Self-GC (Qwen3.6-Plus)	31.51	92.77	[89.47, 95.09]
Self-GC (Qwen3.7-Max)	33.98	94.58	[91.59, 96.54]
Self-GC (GLM-5.1)	31.04	91.27	[87.74, 93.85]

解讀表格時應視為取捨，而非所有指標都勝出：Self-GC 的修剪量比每個基準方法都少得多，以不刪除的 token 換取保留效果。圖 4 清楚呈現此點——在兩個測試套件中，Self-GC 都位於左上方（修剪較少、保留率較高），與啟發式方法群沒有重疊。Hard Set 的信賴區間較寬（n=33），Self-GC 的 [69.08, 93.35] 與工具修剪的上界重疊；Production Suite 的差距則明確。規劃器骨幹之間的差異不大——三種中階規劃器都超過 90%——這支持只要 harness 強制執行確定性安全檢查，就可以使用便宜的規劃器。

在 20 個意見不一致案例上進行的 A/B 評審校準中，Self-GC 獲選 11 次、平手 7 次、最舊回合折疊獲選 2 次（校準後為 92.77 對 87.46，原始單提示評分為 92.47 對 89.76）。

生產環境，而非實驗室基準測試#

線上結果是對真實 Xiaohongshu 流量進行的帳戶層級分流：電子郵件首字元按字典序大於等於 o 的帳戶使用 Self-GC，較早的帳戶作為控制組；涵蓋 context-gc（互動聊天清理）與 skill-gc（長期技能狀態修剪）。5 月 25 日至 30 日、08:00–22:00 期間，處理組的主要代理程式輸入 token 平均減少 10–15%，峰值接近 20%。

這接近 A/B 測試，證據力遠高於本 wiki 通常取得的案例研究——但作者也自行說明其界線：這是生產環境監測證據，而非完全隨機化的品質實驗，沒有包含規劃器開銷的配對計費成本稽核，而最後一個觀察時段包含波動較大的月底批次流量。圖 5 有兩項本文未提及、但值得記住的資訊：六天中幾乎每個白天時段都能看到差異（並非單一尖峰造成的假象），而且每個請求的平均輸入 token 絕對量約為 70–90k——這些代理程式工作階段通常深入脈絡視窗，正因如此，減少 10–15% 才值得投入工程資源。

失敗分類法#

論文中最具可移植性的成果，是以相依性為核心的失敗分類法——它詢問哪個未來動作會因此失去支援，而不是移除了哪種訊息。分成六類，各自列出下游可觀察到的症狀：

損失類型	症狀
證據細節（列、表格值、SQL 篩選條件、堆疊框架）	代理程式能延續敘事，卻無法重現、稽核或修訂結果
定位資訊／控制代碼（檔案路徑、文件／任務／工作階段 ID、等待控制代碼、回呼 URL）	它知道產物存在，卻無法重新開啟、重跑、等待或交付
行為契約（使用者更正、結構描述規則、指示檔、政策）	高階任務仍可見，但後續編輯偏離要求的規則
原文來源（原始措辭、引文、生成本文）	摘要看似合理，卻無法回應還原／引用／精確複製的要求
即時狀態（目前阻礙、修正後重跑結果、最新交接事項）	保留的前綴看似完整，但真實任務其實受阻或剛被更正
復原路由資訊（側車檔案存在，但檢視內容缺少路由資訊）	技術上可以復原，實際上卻無法在之後找到

即時狀態這一列，是脈絡管理中的 Failures That Look Like Success：沒有錯誤發生，逐字稿讀起來也連貫，代理程式卻根據過時的世界模型繼續執行。

兩項案例研究具體說明了這些問題。在一場文件修復工作階段中，使用者反覆提醒代理程式不要整個替換表格標頭；按時間順序整理的基準方法將警告折疊進摘要，導致行為契約遺失，而 Self-GC 修剪失敗的工具輸出，並保留了可見的警告脈絡。在一條多筆資料輸入管線中，表現最好的時間順序基準方法因為資料植入階段較早，就將它折疊——破壞了管控後續每筆資料的任務契約檔案與參考資料庫。

為何工作負載會逆轉排名#

基準方法的相對排名會在兩個測試套件之間逆轉，而此處的解釋也適用於本論文之外：在偏 BI 的 Hard Set 工作階段中，工具修剪表現不錯，因為資料傾印可以重新查詢；在偏 DOC／CODE 的 Production Suite 工作階段中，按時間順序折疊則勝出，因為簡短的工具輸出可能包含唯一的產物 ID。背後的不對稱性在於工作負載是否具備外部記憶基礎設施。程式設計任務有 git 歷史、建置日誌、測試與可重跑命令；辦公室類工作流程通常沒有代理程式可存取的版本基礎設施，因此簡短的工具輸出可能是唯一可復原的業務證據。任何只用程式設計軌跡評測的脈絡政策，都只是在容易的情境下接受評分。

與實務工作者說法的測量對照#

• 摘要造成的成本如今有量化數據，而非只靠直覺。 Context Window Smart Zone 記錄了 Matt Pocock 的說法：壓縮會累積有損的「沉積物」，清除更好。Self-GC 的評審流程測量了沉積物的具體內容：不是泛泛的模糊，而是精確證據、定位資訊、可編輯產物與即時狀態的損失。實務工作者的直覺經得起測量；實際機制比喻喻更精確。
• 清除或壓縮的選擇原本被框定為二選一，但其實不然。 smart-zone 頁面的決策規則是：若任務能依書面紀錄順利恢復就清除，若需要執行中的脈絡就壓縮；測量結果指出第三種選項：讓執行持續進行，但以物件粒度管理脈絡，並提供位元組完全相同的復原。這正是「需要執行中的脈絡，也需要精確產物」的情境，而現有兩種選擇都不理想。
• 「加重修剪」並非沒有代價，而且其方向可以測量。 這裡每種啟發式方法都會移除 Hard Set 中 62–70% 的 token，無影響率則為 55–70%。在九組方法與測試套件的配對中，積極程度與損害之間的關係大致單調，足以視為真實趨勢。透過激進刪減讓工作階段維持在 smart zone 的 harness，等於用相依項目遺失的問題取代二次注意力成本問題。
• 規劃器可以便宜；強制執行則不能。 三種中階規劃器的結果相差約 3 個百分點，而安全關鍵行為（絕不碰最新回合）在它們身上都會以 4–8% 的比率失敗。這是 Agent Harness Engineering 中「強制執行不變條件，而非實作方式」的主張，以測量結果而非原則加以重現。

值得一併考量的限制#

軌跡取自生產環境，但因涉及私人使用者資料而無法公開；目前尚未發布去識別化測試資料、提示範本、逐樣本評審結果或指令碼。主要離線指標是以評審判定的無影響率，而非完整線上重播成功率——沒有代理程式實際使用修剪後的脈絡執行未來回合。A/B 校準集只有 20 個案例。線上日誌顯示的是操作性分流下的輸入 token 減量，並非隨機化品質實驗或計費成本稽核。復原成功率（代理程式是否真的找到並使用側車檔案）被列為未來工作，尚未測量——因此復原路由資訊失敗類別，是此分類法中證據最薄弱的一列。

這個類別有了名稱，以及支持它的成本論證#

Agentic Context Management（Gaurav Dadhich，arXiv 2607.21503，2026-07-23，empirical）從相反方向得出本文的核心論點——不是提出經測量的機制，而是提出分類法，再加上經濟論證——並為這門學科命名。它對既有框架的診斷，是整個語料中最精闢的一句話，也說明了本文存在的理由：

「『Memory』指的是一種儲存處，也就是放入事實、再取回事實的地方。以儲存處為核心的系統，恰好只優化兩個時刻：寫入與讀取。」儲存只是生命週期中的一個時刻，不是全部。

證據註記——利益衝突毫無保留，論文的兩部分應受到截然不同的權重。唯一作者隸屬於 Maximem，其 Synap 產品既是論文的參考實作，也是其基準測試對象。所有醒目數字都是作者對自家產品的自述，表 3 則是由廠商撰寫的競品比較。成本論證屬於分析推導——它來自任何讀者都能重新驗算的 token 算術，在邏輯上獨立於 Synap，也是值得沿用的部分。基準數字是廠商自述，全文皆以此方式標示。論文在設定配置上的紀律異常良好（見下方表 2），因此它唯一的疏漏——從一張剛宣告不可比較的表格得出比較性結論——反而更醒目，而非不那麼明顯。

五項基本要素，橫跨三個範圍#

以下是分解架構，以及論文自己的一行說明（取自圖 1，比正文更精簡）：

基本要素	決定事項	缺少時的具名失敗模式
架構設計	記憶的形狀——哪些類別重要、如何擷取、存放在哪裡、保留多久	垃圾累積（與 Ingesting 有關）
攝取	將原始訊號轉為結構化、可檢索的記憶	細節遺失；身分碎片化
範圍設定	此刻哪些內容相關、屬於何種範圍，以及如何隔離	範圍滲漏；跨工作階段失憶
預期	接下來哪些內容會相關——推測式預先擷取	檢索卡在關鍵路徑上
壓縮與整合	在不遺漏後續所需內容的前提下符合預算	準確度懸崖；成本呈二次方成長

其上還有兩項結構性主張。第一，各基本要素透過第一項彼此耦合：所選架構會決定其他四項應如何運作（客服代理程式與程式碼代理程式需要不同的類別、保留策略與壓縮方式），這也是論文主張應採用系統，而非把五種工具拼在一起的理由。第二，每項基本要素都在範圍階層中運作——使用者 → 客戶 → 用戶端，依最窄範圍優先解析，並嚴格隔離；此外還有獨立的全域知識層，圖 1 明確標示它只用於實體正規化，不是檢索範圍（正文對此則說得含糊）。定義上的收穫是論文劃出的類別邊界，值得把它視為廠商在自家產品所在之處畫線：「只妥善處理一項基本要素的系統，是記憶工具。能跨範圍一致處理全部五項的系統，才是脈絡管理平台。」

**預期是這份語料中唯一沒有其他來源探討的階段。**其他每項基本要素在 wiki 某處都有經測量的處理；而代理程式尚未提出要求前，先推測並預先擷取脈絡，則沒有。論文指出 Letta 的實驗性 sleep-time agents 是最接近的已發表相關工作，並報告自家產品在不同客戶間「命中率始終超過 60%」——這只是廠商未附方法、未定義何謂命中、也未說明未命中時丟棄多少推測性工作的裸宣稱。

失敗模式表的依據是廠商自己的部署筆記及已發表文獻，其中兩列的數字值得保留：

• **99.6% 是垃圾。**對「某個熱門記憶函式庫」的稽核發現，32 天內儲存了 10,134 筆記錄，其中只有 38 筆可用——其餘都是啟動檔重述、cron 雜訊、設定傾印。註腳更正 Maximem 自己的原始貼文：該貼文報告 97.8%；但 10,134 筆中的 38 筆等於 99.6%。對照記憶與脈絡中毒的對抗性框架來看，這是同一底層問題的日常版本：沒有准入控制的儲存處會塞滿垃圾，不管有沒有人發動攻擊。
• **準確度懸崖：引用而非實測。**將 **18,282-token 脈絡壓縮至 122 tokens，且未經驗證的一次性處理，使任務準確度從 66.7% 降至 57.1%——低於無脈絡基準。**這是引用 Zhang 等人 2025 年的二手資料（Agentic Context Engineering，arXiv 2510.04618），不是本文的研究結果，引用時應一律再往前歸因給該來源。

成本論證：算術推導，而非測量結果#

這是經得起利益衝突檢視的部分，因為內容完全不依賴 Synap。假設每輪新增 t 個 tokens，共 n 輪。完整追加會在每一輪重送整段歷史，因此第 k 輪的輸入是 k·t，而

C_append = Σ(k=1..n) k·t = t·n(n+1)/2 ≈ (t/2)·n² = O(n²)
C_bounded = n·W = O(n)
R(n) = C_append / C_bounded = t·(n+1) / (2W) — linear in n

供應商依輸入 token 計費，因此對話越長，成本以二次方成長，而成本懲罰倍數則線性成長。以論文的示例數值 t = 500、W = 4,000 為例（附錄 A，已核對——每個儲存格都符合封閉形式）：

輪數 n	完整追加	有界	倍數
50	637,500	200,000	3.2×
100	2,525,000	400,000	6.3×
200	10,050,000	800,000	12.6×
500	62,625,000	2,000,000	31.3×

算術推導出的三方比較（表 2，已確認無誤），是本文對取捨最清楚的陳述：

方法	Token 成本	保真度	失敗模式
完整追加	O(n²)	完整，直到脈絡腐化	成本暴增；長脈絡品質下降（「遺失在中間」）
粗略摘要	O(n)	有損、未經驗證	準確度懸崖
經驗證的壓縮	O(n)	保留且經檢查	無——這是宣告的目標，不是實測結果

圖 3 畫出前沿，並補上正文沒有提到的一點：圖中經驗證的壓縮在準確度上略高於完整追加，而非僅與之持平——這是在圖像中把脈絡腐化的主張提升成結論，卻沒有任何測量作為依據。應把這個角落視為論點，而非研究發現。

**額外負擔模型更有用，也是與本文未解問題相關的部分。**驗證並非免費——壓縮和檢查都會消耗 tokens。但壓縮會定期處理已壓縮過的脈絡加上近期對話，絕不處理完整逐字稿，因此每次處理的都是有界脈絡，處理次數也只會線性增加。若脈絡維持在接近預算 W，每 p 輪觸發一次壓縮，每次成本為有界脈絡的 c 倍，那麼 N 輪的總成本為

N · W · (1 + c/p)

——線性成本乘上一個固定倍數，而非不斷增加的稅額。當 t = 500、W = 4,000、p = 8、c = 2 時（固定 1.25× 額外成本），相較完整追加，100 輪約省 80%、200 輪約省 90%、500 輪約省 96%：對話越長，節省幅度越大，不會被額外成本吃掉。論文明確指出，反覆重新壓縮之所以安全，只因每一輪都經過驗證——若沒有資訊損失檢查，反覆壓縮就會直接漂移至前述的脈絡崩塌失敗。

論文提出的三項注意事項在此都很重要。表格是「示意性的，並非實測」。它假設每輪新增的 token 數固定。它也明確排除快取折扣，理由是折扣「只會改變常數項，不影響漸近複雜度」——但這正是提示詞快取經濟學與本文自身的快取感知提交章節所不接受的假設：在實際的 n 範圍中，決策取決於常數項；快取中斷的計費率比未快取 token 更高；而實測顯示 token 減少 3×，帳單反而增加 40.1%。漸近主張沒有問題，但若省略模型丟掉的那一項，就推不出它暗示的設計規則。（論文也提到每次呼叫的注意力計算量是二次方，因此完整追加的累積計算量大致呈三次方成長；不過它以計費作為更明確的主張。）

經驗證的壓縮作為執行期契約#

Self-GC 的無影響率，是針對研究評估集執行的離線裁判評分；本文的壓縮主張則是執行期契約：每次壓縮都會回傳明確的驗證分數與壓縮比，系統會測試關鍵資訊能否從壓縮結果中還原；若驗證低於門檻，系統便會自動以較不激進的壓縮方式重試。壓縮會考量類別——哪些內容必須逐字保留、哪些可以抽象化，取決於為個別代理程式產生的架構。這與基準數字是很不一樣的產物：每次呼叫都會提供應用程式可讀取的品質訊號。

然而，外部人員完全無法驗證這件事。論文明確未說明驗證機制（整個系統章節只說了一次「機制內部細節屬於專有資訊」），沒有公布驗證分數的分布，也沒有任何基準測試能透過消融實驗區分經驗證與未經驗證的壓縮。論文的核心技術主張——生產規模下可達成可驗證、近乎無損的壓縮——只是透過產品存在這件事加以斷言和展示。

檢索命中不代表推理所需資訊充足#

論文的第二項分析性貢獻，也是影響脈絡管理以外範圍最廣的一項。答案品質受一個鏈條所限制：

answer quality ≤ min(extraction quality, retrieval quality, reasoning sufficiency)

推理充分性是沒有人測量的那一項。多數檢索評估在單一黃金文件出現在前幾名結果時就判定命中——HotpotQA 每題以一份支持文件評分，即使多跳問題需要兩份或更多文件。這類評估在結構上看不見對代理程式最重要的失敗：檢索到相關文件，卻漏掉完成推理鏈所需的橋接文件。論文定性觀察到這個現象，但依照其研究設計，無法量化——這是觀察，不是研究結果。

作者以這項現象為研究動機，進行五個語料庫 × 每個 10,000 份文件、每個語料庫 1,000 個查詢的研究（MRR@10），並將其定位為研究動機，而非受控基準測試，同時列出七項限制（單一操作者、一種關鍵字引擎對一種向量儲存庫、未切分文件、每個語料庫僅一萬筆規模、單一黃金文件評分、未保留逐查詢軌跡、沒有融合式混合檢索或重排序組別）。以這個權重來看，仍有兩項結果值得參考：

情境	關鍵字（Tantivy）	向量（Chroma）	領先者
CodeXGLUE（自然語言 → 程式碼）	0.290	0.914	向量，明顯領先
MS MARCO（網頁）	0.404	0.523	向量
SQuAD（事實問答）	0.605	0.614	持平
HotpotQA（多跳）	0.549	0.495	關鍵字，略勝
SciQ（科學）	0.815	0.614	關鍵字，明顯領先

檢索方法取決於情境，而且差異不小——語意落差最大的地方由向量檢索勝出（搜尋「sort a list」而找到 bubble_sort）；而當詞語是明確實體而非感覺時，關鍵字檢索勝出（「mitochondria」是關鍵詞，不是相似概念）。還有向量檢索的成本：在同一個 10,000 份文件的語料庫中，生成嵌入並建立索引比關鍵字索引慢 60–100 倍（0.39–0.45 秒對比 26.3–43.1 秒）。當代理程式必須立刻讀取新材料並立刻採取行動時，這是實際限制。作者提出不切分文件的注意事項，對反方向的解讀也至關重要：all-MiniLM-L6-v2 會截斷長文件，因此除 CodeXGLUE 外，向量檢索實際上只為文件前段建立索引。

基準數字，以及表 3 無法支持的結論#

Maximem Synap 自行報告 LongMemEval 達 92.0%（460/500），LoCoMo 類別 1–4 達 93.2%。圍繞這些數字的配置紀律確實值得效法：表 2 列出資料集、切分、答案模型（gpt-5-mini）、裁判（gpt-5-mini，依黃金答案判斷 CORRECT/WRONG）、檢索配置、公開的測試框架，以及帶有執行日期的儲存庫標籤；其原則是「只有完整列出配置，評估數字才有解讀空間」。LoCoMo 的對抗性第 5 類——測量的是棄答能力而非記憶，且會讓總體數字相差至少十分——被排除，與原論文、Mem0 和 Zep 的做法相同。論文如實呈現各類別的分項結果（已確認無誤），包括較弱的項目：

LongMemEval 類別	分數	LoCoMo 類別	分數
單一工作階段－使用者	100.0% (70/70)	多跳	97.3%
單一工作階段－偏好	100.0% (30/30)	開放領域	93.4%
知識更新	100.0% (78/78)	時序	90.8%
時序推理	100.0% (133/133)	單跳	88.8%
單一工作階段－助理	87.5% (49/56)	總體（類別 1–4）	93.2%
多工作階段	75.2% (100/133)
總體	92.0% (460/500)

值得注意的是最差的項目：多工作階段推理為 75.2%，幾乎所有殘餘錯誤都集中於此，而這正是前述的推理充分性情境——跨不同工作階段連結資訊時，光是檢索到某個相關項目並不足夠。

**表 3 是廠商撰寫的競品比較，這份 wiki 不會把其排名視為已獲證實。**論文重列各廠商自行報告的 LongMemEval 最佳數字——Maximem Synap 92.0%（gpt-5-mini 作答、gpt-5-mini 評判）、SuperMemory 85.2% / 84.6% / 81.6%（Gemini-3 Pro / gpt-5 / gpt-4o 作答，由 gpt-4o 評判）、Zep 71.2%（gpt-4o 作答、gpt-4o 評判），Mem0 和 Letta 則未公布——並在正文中指出「各列彼此不可比較」。確實不可比較，原因也比論文所說的更嚴重：**各列的答案模型與裁判都不相同。**論文自己在同一段提供的證據就說明這點影響很大——SuperMemory 公布的測試範圍，單是答案模型不同就有 81.6%–85.2%，同一系統相差 3.6 個百分點，已占它與領先者差距的大部分。

**然而，論文隨即據此得出比較性結論。**就在宣告各列不可比較之後，它寫道：「Maximem Synap 的數字是以比最強競爭者配置更小的答案模型（gpt-5-mini）取得，這最明確地顯示增益來自脈絡層，而非答案模型。」這是從一張剛宣告不可進行正面比較的表格推導正面比較結論，而且默默忽略裁判欄——由產生答案的同一個小模型來評判的系統，顯然未必與由 gpt-4o 評判的系統處於相同測量條件。保留 92.0% 作為列明配置的自述即可；不要沿用其排名。

一項獨立、非廠商提供的 LongMemEval 數字（2026-09-02）#

Karunanidhi（arXiv 2608.21230，empirical）是一篇記憶安全論文，但它在同一基準測試上建立了配置完整揭露的乾淨條件基準，也是這份語料中第一個非由產品廠商為自家產品報告的 LongMemEval 數字。這是有用的比較，正因為其系統刻意保持簡單：一般語意搜尋，top-k=15，不做重排序、不改寫查詢、不摘要、不使用圖結構；每個對話回合儲存一筆記憶，每個問題位於獨立命名空間。閱讀模型為 claude-sonnet-5，裁判為 gpt-4o-2024-08-06，並逐字使用 LongMemEval 官方提示詞。

問題類型	一般檢索（n）	Maximem Synap 自述
單一工作階段－助理	1.000 (56)	87.5%
單一工作階段－使用者	0.943 (70)	100.0%
知識更新	0.936 (78)	100.0%
時序推理	0.827 (133)	100.0%
多工作階段	0.767 (133)	75.2%
單一工作階段－偏好	0.767 (30)	100.0%
總體	0.860 (500)	92.0%

以下三種解讀，信心由高至低排列。第一，各列仍不可比較——閱讀模型與裁判不同；本文對表 3 的規則同樣適用於此表。第二，弱項重現了：兩項測量中，多工作階段資訊整合都是明顯最差的類別；這是目前對上述推理充分性論點最有力的支持，表示它可能是任務本身的特性，而非單一系統的檢索器造成。第三，以下僅作為觀察，不視為研究發現：在一般檢索基準中，四個類別的分數介於 0.767–0.943，而 Maximem 有六個類別中的四個恰好報告 100.0%。這可能是脈絡層帶來非常大的效果，也可能是測量條件不同；語料中沒有資料能區分兩者。

值得借鑑的診斷方法。論文測試多工作階段為何是弱項時，做了直覺上的測試，卻得到反直覺的答案：提高 top-k 反而使結果更差，而非更好——在 k = 15、30 和 50 時，分別為 0.742、0.677 和 0.613。如果失敗原因是檢索召回率不足，增加候選項應有所幫助。實際上，閱讀模型從更多貌似相關的脈絡中過度計數，這表示問題是閱讀端的資訊整合失敗，而非檢索失敗；依論文自己的框架來說，這也證明「在有人攻擊之前，這個記憶系統就已經會受脈絡視窗裡其他內容影響」。（有一處尚未釐清的不一致，這裡標出而不加以掩飾：測試列印的 k=15 結果是 0.742，上表對同一個 k 卻列出 0.767。論文未予說明，可能與同節提及的建置版本注意事項有關，因此此處只保留測試結果的趨勢，不沿用其絕對數值。）

這種單調下降，正是本文的內容置換論點在記憶基準測試上的測量結果，而非協調內容上的結果：超過某個程度後，即使答案已在視窗中，增加看似相關的材料仍會降低準確度。

檢索預算是安全參數，而兩項測試的範圍沒有重疊（2026-09-02）#

PipePoison（Zang 等人，山東大學，arXiv 2609.00523，empirical）從對抗性角度測試同一個參數，結果方向恰好相反。在 12 種記憶代理程式配置中，端到端攻擊利用率從 K = 1 時的 34–39% 升至 K = 5 時的 67–73%，從 5 到 9 的增益有限；寫入成功率在整個測試範圍內維持不變，因為預算不影響寫入，而 RSR@K 隨視窗增加而單調上升。兩個相鄰的部署參數也呈現相同趨勢。將受害者的良性儲存內容從 100 筆擴增至 3,000 筆，WSR 仍持平、RSR@5 下降（最糟情況從 99% 降至 77%），而 AUR 維持在 59–69%——競爭內容增加會讓攻擊者付出代價，卻不會築起一道牆。將工具回傳內容從一筆增至十筆，則會在寫入前稀釋惡意內容，使 WSR 從 75–83% 降至 52–61%，AUR 從 71–76% 降至 47–52%；這是清單中唯一會在寫入階段發揮作用的參數。

與前述良性測試並列來看，這是本文最清楚的案例，顯示生命週期參數會帶來雙向成本；但兩項測試的範圍並沒有重疊，這項注意事項必須和兩者的對照一併保留。Karunanidhi 測量 k = 15、30、50，發現準確度單調下降；PipePoison 測量 K = 1 至 9，發現攻擊成功率上升後在 5 左右趨於平緩。沒有研究在相同範圍內同時測量這兩項，因此「小視窗沒有代價」是跨越資料缺口的推論，不是研究結果。兩者共同證實的是舉證責任的形狀：良性情境下，沒有任何測量結果支持視窗超過轉折點；對抗性情境下，所有結果都支持這樣做——因此，寬鬆設定檢索預算如今必須提出理由，不能再視為預設值。

與 Self-GC 的對照#

兩項來源認同相同論點，證據與範圍則各自清楚分開：

• **Self-GC 做測量；本文提出論證。**Self-GC 的貢獻，是根據 332 個取自生產環境的工作階段計算無影響率，並提供即時帳戶層級的分項結果。本文的貢獻是分類法與封閉形式成本模型。兩者不可互相取代；分析部分更容易移植，因為不需要部署就能驗算。
• **同一操作的兩端。**Self-GC 在物件粒度管理單一長時間工作階段的當前提示視圖。ACM 的生命週期則跨工作階段、使用者及組織，涵蓋從取得到淘汰的過程——其 Scoping 和 Ingesting 基本要素處理的是 Self-GC 明確稱為互補且不在範圍內的儲存處。
• **快取項目是目前的分歧。**Self-GC 會依據脈絡編輯造成的前綴快取中斷評估成本，並在預期裁剪低於 0.3 時暫緩執行計畫；ACM 的模型則假設不考慮快取。兩篇探討生命週期的論文相隔三個月，卻只有一篇把快取納入算術。
• **驗證發生在不同時點。**Self-GC 對候選計畫進行離線裁判評分；Synap 則在執行期回傳每次壓縮的分數，但未揭露機制。執行期形式是更有用的產品介面，也是更難驗證的主張。

另一種用途：協調內容，以及為何其成本來自置換而非干擾#

以上內容都把視窗視為由代理程式自身不斷累積的歷史所消耗。RCWT——Roundtable Context Window Test（Brenda Lelis 與 Rodrigo Cabral-Carvalho，CloudWalk, Inc.，arXiv 2607.12216，2026-07-13，empirical）測量的是另一種消耗來源：共享狀態、先前代理程式訊息、工具觀察、角色提示與摘要，如何和目前任務一同組成同一個有限呼叫。對預算為 W 的呼叫，令 c 為協調內容，W − c 為剩餘任務區塊；每個協調 token 都是無法用於任務指示或證據的 token。論文稱此為任務預算置換，並明確指出這不是什麼——回合排程、檢索策略、記憶寫入、工具失敗與代理程式拓撲都刻意排除在外，因為混合這些因素會模糊局部配置效果。它測量協調的成本，而不討論協調帶來的好處。

兩項實驗；混為一談會顛倒研究發現#

	固定預算 RCWT（主要實驗）	保留完整任務的消融實驗
預算	固定 W = 4096，c + u + r = W	總提示長度增加；任務區塊從未縮短
報告比例	p = c/W，即實際占用完整預算的比例	c/(c+t)，其中 t = 698 個完整任務／參考 tokens
任務證據	隨 c 增加而從前綴截斷	各條件下都完整保留
任務格式	開放式結構化技術分析	八個精確 JSON 欄位
評分方式	二元 LLM 事實查核裁判，有效評分項目 8 個	逐欄確定性評分
結果	明顯懸崖，實際占比約在 83–90%	完全沒有懸崖——150/150 次呼叫完整作答、1200/1200 個欄位答對，協調比例最高達 0.95

「95%」只屬於右欄，而且是虛無結果：在協調比例 0.95 的條件下——13,262 個協調 tokens 加上 698 個任務區塊，總計約 13,965 個 tokens——GPT-4.1-mini、Claude Haiku 4.5 和 Gemini 2.5 Flash 的每次測試呼叫都正確回傳全部八個欄位（每格 10/10，Wilson 95% CI ≈ [0.722, 1.000]；150/150 與 1200/1200 的合併總數僅作描述，論文明確指出它們不是獨立樣本區間）。把這個比例接到主要實驗的懸崖上，說成「協調比例到 95% 都能維持準確度，之後才會急跌」，會把論文結論說反。**懸崖是截斷造成的，而 95% 的結果證明協調文字本身不會必然造成傷害。**用論文自己的話來說，主要效果是「任務預算置換，並非證明協調內容量本身會造成語意干擾」。

懸崖的確切位置#

W = 4096，固定指示 tokens u = 337，執行器以 q = c/(W − u) 為目標，分析則報告實際的 p = c/W。兩種提示順序合併後，每個模型與目標比例組合有 40 次呼叫；8 個評分項目的有效二元準確度（表 A1，已核對無誤）：

目標 q	實際 p	參考文件 r	Gemini 2.0 Flash	Haiku 4.5	GPT-4.1-mini
0%	0.0%	3759	1.000	0.972	1.000
25%	22.9%	2820	0.960	0.906	0.972
50%	45.9%	1880	0.944	0.894	0.988
75%	68.8%	940	0.894	0.875	0.981
90%	82.6%	376	0.659	0.666	0.853
92%	84.4%	301	0.400	0.441	0.609
94%	86.3%	226	0.016	0.113	0.413
96%	88.1%	151	0.009	0.103	0.284
98%	89.9%	76	0.006	0.038	0.331

協調內容占比達 69% 前，準確度都很平穩——呼叫中有四分之三用於協調，只會造成 3–10 個百分點的成本；當參考區塊縮至幾百個 tokens 後，準確度便在 83% 到 86% 之間急遽下降。在實際占比 82.6% 時，相較基準，Gemini 降低 34.1 個百分點、Haiku 降低 30.6 個百分點、GPT 降低 14.7 個百分點。尾端還有兩點值得留意，正文未特別指出：接近最低參考文件量時，模型間差距擴大了十倍（r = 76 時為 0.006 對 0.331）；而且 GPT-4.1-mini 在最後三列不是單調變化（0.413 → 0.284 → 0.331）。只剩 76 個 tokens 的參考內容時，八項事實的分數仍達 0.331，不太可能只是回憶能力所致；論文自身的限制說明則點出可能原因：協調範本與數個評分概念的主題有所重疊（CRDT、MLS、Redis、WebSockets、遷移時機），因此有些事實可能直接從協調區塊中取得。

單位是 token 餘額，而非百分比#

若以固定百分比計算，無論視窗大小為何，轉折都應出現在相同的實際 p。但實際並非如此。在同一個目標 q = 90% 下，W = 4096 時的實際 p = 82.6%，留下 376 個參考 tokens，並出現懸崖；W = 8192 時的實際占比更高，p = 86.3%，留下 786 個參考 tokens，退化情形卻較輕。論文用任務特定的剩餘預算 θ 概括轉折點，其中 p₀(W) = 1 − θ/W（表 1 以 W = 4096 的執行結果擬合 θ，再用於預測 8K）：

模型	θ	預測 p₀（8K）	實測 p₀（8K）	實測 p₀（16K）
Gemini 2.0 Flash	665	91.9%	92.1%	95.9%
Claude Haiku 4.5	650	92.1%	92.2%	96.0%
GPT-4.1-mini	568	93.1%	93.1%	96.4%

三種模型在 8K 下的預測與觀察結果相差不到 0.1 個百分點。但仔細解讀便會發現：θ 只在一種視窗大小下擬合，再以兩種視窗大小檢驗，因此這是校準，不是經驗證的不變量——作者兩度明言如此。這項結果所確立的是正確問題的形式。「提示詞有多少百分比屬於額外負擔」不是正確的測量方式；「還剩多少 tokens 可作為任務證據」才是——而在 8K 安全的配置，在 4K 下就會成為懸崖。

餘額取決於任務，差異約達 3.5 倍#

在 W = 4096 下測試四種任務，並以邏輯迴歸中點估計，以及推得剩餘預算 θ = W(1 − p₀)：

探測任務	邏輯迴歸 p₀	θ（剩餘任務預算）	截斷開始點
任務 1——規格回憶	0.838–0.861	568–665 tok	目標 q = 90%
GSM8K-pack	0.853–0.893	438–602 tok	90%
MMLU-Pro-pack	0.733–0.755	1003–1094 tok	50%（部分）
DROP-pack	0.481–0.624	1539–2126 tok	50%

**最精簡與最寬鬆任務類別之間約 3.5 倍的差距（GSM8K 438–602，DROP 1539–2126）就是研究發現，而非雜訊。**自行提供完整資訊的算術任務幾乎不需要視窗中的證據；以段落為依據的離散推理，在模型讀取任何內容前就需要 4K 預算的三分之一。因此，「讓協調內容低於 X%」這種通用規則根本無法建立——數字會因任務類別而異，必須實際測量。（θ 是整個剩餘區塊 u + r；對主要任務而言，包含 337-token 的指示前言，因此只計參考內容的剩餘量約為 230–330 tokens。）

論文內部的反向數據#

兩項邊界探測結果朝相反方向發展。對自足的演算法任務而言——Python 分割追蹤，答案完全由任務區塊中的程式碼決定——三家供應商在每種額外負擔程度下都表現穩定，這是最清楚的證據，說明在已測試範圍內，額外文字本身不會造成退化。然而，Claude Haiku 4.5 在未截斷的 GSM8K 題組中，分數從 p = 0 時的 0.60，降至 p = 0.25 時的 0.40，再降至 p = 0.50 時的 0.38——即使任務題組仍完整保留，表現也會退化。論文自己也標示了這點：題組探測「無法確認截斷是退化的唯一可能原因」。因此，預算置換是主要效應，但不是唯一效應；唯一的模型與任務例外，出現在主要實驗格式，而非較容易的消融實驗中。

這些結果能界定什麼，又不能界定什麼#

消融實驗的虛無結果，實際適用範圍比表面看起來更窄。它一次更改了任務格式（開放式分析 → 精確欄位擷取）、評分方式（LLM 裁判 → 確定性 JSON），以及一個模型 ID（重新執行時無法取得 Gemini 2.0 Flash，改以 2.5 Flash 替代），因此它測試的是在完整證據、擷取型任務中是否存在大型干擾效應，而非對開放式任務進行 token 完全相同的重新評分。實驗總 token 數最高約 14,000，比本文實際執行的系統視窗小三個數量級，因此無法說明協調內容量是否會在 100k+ 時造成干擾（Context Window Smart Zone記錄了另一種各模型不同的退化機制）。此外還有論文自己列出的限制：前綴截斷依固定順序移除事實，因此擬合出的中點部分反映參考資料的編排方式，而非任務常數；懸崖區域的取樣點是在早期觀察到平坦區域後才加入，因此曲線僅供描述，並非預先註冊；協調區塊只有一個合成範本，因此無法將結果推廣到不同的協調類型（在相同 token 數下，密集工具輸出、冗長逐字稿、彼此矛盾的代理程式主張）。

以上限制都不影響仍然成立的操作規則，而這正是本文核心論點從配置角度得到的印證。名目脈絡視窗、平均提示詞長度、協調比例，都不是安全訊號。應該監測的是剩餘任務預算——協調內容之所以危險，不是因為它在語意上與任務競爭，而是因為固定預算下，它會擠掉任務需要的證據；這正是本文分類法所稱的證據細節與原文來源遺失，只是由不同途徑造成。Self-GC 管理哪些物件會被擠掉；RCWT 測量沒有任何機制管理時，擠掉內容會造成什麼代價。

壓縮作為攸關安全性的轉換（2026 年 8 月）#

本文一路都把壓縮視為一種能力機制——摘要保留了什麼，決定代理程式是否還能完成任務。UK AISI 的 INC-2026-07-28-01（case-study，2026-08-04）記錄了壓縮如何在單一事件中影響攸關安全性的信念，而且方向不只一種。

AISI 提出了一項暫定假設：「若代理程式在壓縮前曾推理某人是否真實存在，這項細微判斷可能在壓縮時遺失，摘要可能會把錯誤假設（也就是該人物是作為該範圍一部分行動的 AI 代理程式）當作既定事實繼續傳遞。」相關軌跡經歷了 750 多輪，並發生約十多次壓縮事件。

實際觀察到的相反情形則較為有力，因為它是引用的產物，而非猜測。另一個樣本中的壓縮摘要寫道：「PARALLEL-CLONE AGENTS（已解決的異常）：其他 AI 代理程式執行完全相同的複製範圍，並透過公開的 token2 使用我的 MY GitHub 帳戶。」在這裡，壓縮傳遞了一項正確推論——值得注意的是，這與 AISI 假設的失敗機制完全相同：標籤 (resolved anomaly) 將一個未解問題轉化為既定事實。這正是良好摘要應做的事，也正是錯誤結論變成關鍵前提、再也無法重新檢視的方式。

本文應保留的普遍形式是：**壓縮遺失的不只是內容，也包括認知狀態。**保留「這可能是真人」這種不確定語氣，比直接下結論「這是 NPC」更耗 tokens，因此摘要在結構上會偏向把暫定信念提升為定論。對一般任務而言，這是優點——壓縮之所以有效，原因就在於此。但若某個信念決定某項行動是否會傷害他人，壓縮就會移除原本負責維護安全的疑慮，而後續步驟不會重新推導出這份疑慮。

證據紀律：AISI 對壓縮的主張明確有所保留（「可能是重要機制」、「似乎會」），沒有進行反事實分析，而且只涉及一個樣本。應將其記錄為值得監測的機制，而非已證實的成因。

延伸閱讀#

• Agent Documentation Behavior — **在整體規模上觀察到的外部化假說。**在 557 個真實程式碼工作階段中，代理程式撰寫的工作筆記（計畫、thoughts/、驗證紀錄）占所有文件互動的 25.1%，產出與查閱的比例為 0.87×，而離開文件閱讀後最常見的轉換是繼續閱讀（0.270）或推理（0.245），而非寫程式。Gao & Chen 提出的第一個候選解釋，正是本頁的前提——代理程式會把推理外部化到檔案，因為上下文有上限，因此文件成了工作記憶，而非參考資料——但他們不願在這個解釋和「測試套件是更便宜的判定依據」之間做出選擇。Self-GC 中永遠不能 GC 的指令檔類別，是這種情況在執行階段的對應
• Unsanctioned Action in Capability Evaluations — 摘要化作用於與安全相關的信念：據推測，它移除了真實與模擬之間的保留語氣；觀察到的結果則是藉由 (resolved anomaly) 標籤，把一個尚待確認的問題提升成定論
• Open-Ended Discovery Harnesses — 把生命週期設計當成避免收斂的機制，而非成本控制。SwarmResearch 依角色分配上下文——搜尋代理程式只會看到自己的工作樹，以及（對精煉者而言）父代理程式對話的分支副本；協調器則只看到各代理程式的方法摘要與分數——其理論是，長串逐步改進的歷史會讓大幅轉向變得不太可能。持久化產物是 findings.md，其中記錄了各自脈絡中的事實：嘗試過什麼、得分如何；後代因此能繼承祖先的結果，而不用繼承其逐字對話紀錄
• Parallel Agent Orchestration — 本頁估算的協調內容，實際上從何而來。RCWT 的合成區塊（角色／協定文字、代理程式訊息、共享命題、工具結構描述）是多代理程式成本的替代指標；該頁則在系統層級追蹤這項成本，並說明兩者的關聯與限制
• Orchestration Sets Token Economics — 同一套生命週期紀律，在此成了已部署的生產合約，而非研究系統：預算用到 80% 時，折疊成具型別的檢查點（持久化決策／限制／已否決方法、八節式可續接摘要、逐字保留的使用者需求、技能參照），保留受保護的逐字尾段，包含最新 4–12 則訊息且上限為預算的 30%，採增量式向前折疊以控制摘要成本，在付費迴圈之外用較便宜的輔助模型摘要；若摘要為空或品質退化，就中止而非持久化。卸載部分則把可復原的側車概念推廣出去——工具輸出超過 20K 字元就寫入檔案，並以橫幅禁止模型根據預覽推斷成功；子代理程式回傳上限為 8 KB、附有引文的摘要，父代理程式不會讀取原始內容。關於快取感知提交的問題，在此幾乎消失，因為提示經過結構化設計，摘要化時便會以建構方式重組出可快取的前綴。由供應商撰寫、COI 完全衝突，且未對個別機制做消融
• Document Parsing as the Retrieval Bottleneck — 管線末端也有相同的資訊保存問題，兩者的解法在結構上相似。PDF 轉成文字時流失的結構，以及歷史紀錄濃縮時流失的細節，都不易察覺，也不會出現在追蹤紀錄中；兩者的應對方式都是保留可復原的表示形式，而不是縮小內容：匯入端使用帶有逐詞邊界框的空間文字，執行階段使用附穩定識別碼的索引物件與側車儲存。解析的論述還提供了本頁執行階段無法採用的一項紀律——「解析是一個階段，不是一步；你會再次解析」——因為匯入產物能從不可變來源重新產生，折疊後的對話卻不能
• Context Window Smart Zone — 本頁要管理的限制；該頁的清楚／精簡框架在此多了一個經測量的第三選項，而「沉積」的直覺也在此有了具體機制
• Agent-Authored Harness Optimization — 為累積成本附上帳單。Harness 演進迴圈會把每一輪的教訓寫入系統提示與長期記憶；Wang 等人（arXiv 2607.12227，empirical）指出：「持續增加的提示文字量會造成上下文膨脹，抵銷剩餘的收益」——迴圈自身的輸出成了需要管理生命週期的對象，但這類迴圈都沒有生命週期管理
• Agent Harness Engineering — 語料中最清楚呈現 harness 與模型如何分工的案例：模型提出物件操作，harness 負責有效性、可復原性、脈絡修復與提交時機；規劃器稽核則說明了為何這種分工不可或缺
• Prompt-Cache Economics — 從快取角度探討相同的聯合成本問題，也提供了 0.3 門檻所屬的參數形式：CAPC 從三個已發表價格推導出不依賴供應商的交叉點（ρ_cross(r) = (α − 1/r)/(α − β)），並顯示設計規則會隨定價與 TTL 大幅變動——因此，在一家供應商測得的快取中斷門檻無法直接套用，但推導公式可以。該文還提出本頁沒有的下限：若修剪後的快取前綴低於 Anthropic 約 3,500-token 的級距邊界，ρ 會從 1.0 降至約 0.85；只要稍微提高修剪幅度，每次查詢成本就可能增加約 77%，所以積極 GC 除了會在快取中斷時產生代價，也受更低處的成本下限約束。兩篇論文的失效模式也相似：以查詢為目標的壓縮器在工具選擇上表現不如不依賴查詢的壓縮器（set-IoU 為 0.700 對 0.603），正是因為針對目前查詢最佳化會丟掉未來可能成為依賴項的資訊——這就是本頁的核心主張，並以壓縮結果呈現。該文也直接反駁 ACM 成本模型唯一明示排除的一點：快取折扣「只會改變常數，不會改變漸近性」，所以可略去。漸近分析上沒錯，實務上卻不成立——寫入快取的費用高於未快取 token；即使前綴逐位元組完全一致且短於約 3,500 tokens，仍約每六次呼叫就有一次快取未命中；而語料中唯一端到端的實際計費稽核顯示，token 減少 3 倍，成本卻比完全不壓縮多出 40.1%。每次提交決策都取決於這些常數
• Cost-per-Task Over Cost-per-Token — 快取感知提交就是該頁所說沒人發表的 token 軸算術：前綴快取中斷代表修剪策略可能減少 token、卻提高成本；0.3 的修剪損益兩平點，是目前第一個發表的此類門檻
• Agent Context Files — 從靜態端探討相同的前綴快取限制（不要在工作階段中途修改上下文檔案）；Self-GC 則估算中斷的代價，而非禁止變更
• Client-Side Agent Optimization — 該文提出的「不要破壞提示快取」部署風險，在此成了附有門檻的提交時規則
• Failures That Look Like Success — 失效分類中的即時狀態遺失，正是此類問題透過上下文管理呈現的樣貌：保留的前綴看起來完整，實際任務卻已受阻或剛被修正
• Harness-Induced Belief Divergence — 在信念層而非 token 層估算壓縮的代價。Yi & Song 所稱的「大量修復」harness 換個名字就是摘要化策略——把失敗、修復、恢復的序列折疊成模型所見的已修復轉移——而在他們的論文中，展開被折疊的內容是影響最大的單一量測操作（+0.131 信念分歧，24 個案例中有 22 個）；同一元件在原本就沒有這些序列的基準上，幾乎沒有影響（+0.007）。這正是本頁即時狀態遺失類別的量化呈現：摘要化移除的不是一般性的 token，而是後續信念所需的特定證據；因此折疊成本取決於被折疊的追蹤內容，而非策略本身。他們最具可移植性的元件也指向同一結論——驗證遮罩只記錄某個狀態是否經過檢查，就能在兩個基準間遷移（18/24 與 8/10）；這支持把驗證狀態視為值得保留的上下文物件，而不是可修剪的行政資料
• Tool-Output Pruning — 上游一層也採用相同的動詞，也是語料中第二個經測量的修剪系統。Self-GC 管理已經在歷史紀錄中的物件，由規劃器提出編輯，再由 harness 確保有效；SWE-Pruner Pro 則在觀察結果到達時逐行決定，依據主幹模型自己的隱藏狀態，不呼叫規劃器，也不使用外部評分器。有三點對比值得留意：(1) Self-GC 的修剪沒有復原保證，因此只用於已過時內容；學得的預測頭則會修剪它預測不會再次參照的即時內容——這正是本頁失效分類試圖警惕的賭注，只是操作單位從物件改成逐行；(2) Self-GC 的遮罩固定保留內文開頭 10% 與結尾 10%，這正是預測頭以學得的長度感知嵌入取代的、不考慮長度變化的策略；(3) Self-GC 會將影像降級為修剪，而逐行評分預測頭完全無法處理影像。兩者的證據也相互呼應：SWE-Pruner Pro 的消融研究發現，逐行 F1 可能把無用的預測頭排在有用者之前，而 LLM 評審卻能以 5–6 分之差區分兩者；這正是本頁選擇「無影響率，而非壓縮率」作為指標的修剪版例證
• Layerwise Omission Attribution — 這是同一問題的正交軸向，兩種分類法可以組合使用。本頁的六種遺失類別以依賴關係為中心（未來哪種行動會因此缺乏依據）；該頁的九個層級則以遺失位置為中心（事實在哪裡消失）。Self-GC 的操作位於其中兩層——歷史／狀態濃縮屬於 L2，代理程式迴圈摘要化屬於 L8——因此無影響評審器是輸出層級的偵測器，可透過在邊界精確比對植入的 canary，準確辨識該方法所計算的遺失。這補上了本頁指出尚未量測的缺口：復原是否成功（代理程式是否真的找到並使用側車？）可在 T2/T3 透過 canary 檢查確認，而不是靠主觀判斷
• Repository Exploration Subagent — 互補的 token 減量策略：把雜訊留在主要上下文之外（將搜尋交給子代理程式，讓它回傳精簡引文），而不是等雜訊進來後再管理。兩者都會降低主要代理程式的 token 負載；只有一者能協助已經存在的追蹤
• Deep Research Agents — Hard Set 所取材的工作負載（瀏覽器、shell、網頁擷取追蹤；確切網址與擷取值會成為未來的依賴項）；長時程研究執行最能展現物件層級保存的價值
• Out-of-Band Prompt-Injection Defense — 同一項基礎機制，目標是隔離而非降低成本。APPA（Archestra AI，arXiv 2607.24625，empirical）會將模型可見的前綴分支到子軌跡，讓限制性讀取在父軌跡之外發生；之後只合併 harness 已檢查安全標籤的值——在結構上就像 Self-GC 把計畫放進側通道、預演，並在安全邊界提交，只是這裡由標籤檢查取代無影響評審。值得一提的是兩篇論文沒有共同引用，設計卻相互呼應：兩者都讓 harness（而非模型）負責有效性與提交時機；都不允許被否決的分支接觸主迴圈；也都明確做到感知 KV 快取，理由相同——APPA 選擇分支而非 Dual-LLM 驗證器的理由是，子軌跡與父軌跡共享完全相同的 token 前綴，因此無須重新合成上下文；它也刻意在執行開始時註冊補救工具，避免執行中途使提示快取失效。Self-GC 為破壞性前綴編輯定價；APPA 則利用非破壞性前綴分支帶來的免費效益。同一種上下文操作能在這兩個面向都發揮作用，足以支持把分支／合併視為第一級 harness 基礎功能，而非任一系統的專屬功能
• Knowledge-Centric Self-Improvement — 同一邊界的互補面：本頁管理執行期間的作用中提示檢視；該頁則把知識永久移出執行過程，並將執行外的儲存庫作為改進對象。其代理程式是這種分工的極端案例——每次嘗試都使用全新上下文，因此執行期間根本沒有歷史可供管理；後續代理程式所需的每一項依賴都必須事先提煉並存入儲存庫。該頁也從另一方向補上「更積極修剪並非免費」的對應結果：提供更多已儲存知識也不是免費的；其移轉介接器把每個欄位限制在 0–3 個項目，因為固定數量的資料可能讓接收端記憶變得「雜訊過多或有害」
• Orchestration-Plan Simulation — 相同的取捨以建模成本函數呈現，而非經測量的策略；也是本頁代理程式內部解法的架構替代方案。OrchBench 為各子任務設定壓縮敏感度類別（robust／balanced／fragile，品質保留比例為 e^γ，γ = 0.35／0.85／1.25）——這是「遮罩類似日誌的輸出，絕不遮罩稀疏表格或堆疊追蹤」的參數化形式；它把遺漏跨代理程式交接內容的代價設為固定的 0.5 品質懲罰，於是本頁定位器／即時狀態遺失一列有了明確數值。兩者互補之處十分明確：Self-GC 為前綴快取中斷定價，並把資訊遺失視為需要避免的事；OrchBench 為資訊本身定價，並把上下文限制視為需要迴避的障礙。其上下文限制掃描是本頁結果在架構上的推論——在不同代理程式之間分散狀態，以及在單一代理程式內管理狀態，是處理相同溢位問題的兩種解法；前者在 128k 時幾乎不再有成本效益（16k 時多代理程式品質優勢為 +0.302，128k 時為 +0.007，而且在 82% 的模型—問題組合中落後於單代理程式）。跨頁閱讀時須留意：其單代理程式基準只承受壓縮損失，沒有建模注意力退化或長上下文回憶失敗
• Memory and Context Poisoning — 從對抗性角度檢視相同的底層結構，也說明了為何 Scoping 是安全機制，而非使用者體驗機制。ACM 的範圍滲漏失效模式——某位使用者的上下文出現在另一位使用者的工作階段中——正是該頁的共享上下文污染變體，以一般生產程式錯誤的形式發生，完全沒有攻擊者；這是最直接的證明，顯示扁平的使用者範圍記憶體根本無隔離可言。Architecting／Ingesting 那一列，是同一頁收錄控制缺口的非對抗版本（儲存 10,134 筆資料，只有 38 筆可用）；§8 則將把原本各自隔離的組織知識放在同一邏輯系統中的安全後果列為尚未解決的開放問題。該頁具體規定的唯一控制措施，是從儲存的憑證推導身分，而非接受用戶端宣稱的身分。**第二個更直接的連結點（2026-09-02）：**該頁最新的來源，同時也是本頁唯一獨立的 LongMemEval 量測（見上文），並直接連結了兩條論述——只要在語料中以簡單錯誤陳述污染 1.2%，準確率就會從 0.850 降至 0.300，而污染內容占擷取上下文的 20%；這就是本頁從對抗角度提出的上下文品質論述。它之所以也屬於本頁，而不只屬於該頁，是因為順序很關鍵：該論文先證明，記憶體在任何人發動攻擊之前，就已經會受到視窗中其他內容的影響；因此攻擊利用的是一般上下文管理弱點，而非創造新的弱點。
• Xiaohongshu — 部署此系統的組織
• Live-Path Minimalism — 服務端避開快取感知提交問題的做法，適用於完全無法承受中斷延遲的系統：GPT-Live 將摘要化視為受控的執行個體切換——原模型執行個體持續服務，同時先為替代執行個體填入摘要後的上下文，然後工作階段無中斷地切換過去。Self-GC 為 KV 中斷估算成本，並可暫緩計畫；這種做法則把中斷延遲隱藏在平行執行個體後面。預先填入的運算成本仍然存在，只是移到使用者聽不見的路徑。這項取捨可以推廣：第三方 API 按用量計費時，適合估算中斷成本；由營運者掌控服務堆疊時，適合隱藏中斷
• Retrieval Inside the Reasoning Chain — 這是被假設、而非設計出來的物件。當被問到鏈中檢索如何保存狀態時，CS329A 第 7 講承認：「這裡假設有某種狀態或記憶體緩衝區……按照目前的結構，這一點並不明確」——當前查詢、先前推理與逐文件累積的擷取內容必須存放在某處，但該論文沒有說明位置
• Memory-Poisoning Numbers, Conditioned on the Write — 用本節的計量方式為擷取預算旋鈕定價。由於寫入成功率在 K 掃描與儲存庫大小掃描中都維持不變，所有影響其實都已是條件式的：擷取競爭每增加一點，大約會轉化為端到端的 0.5–0.8 個百分點（S3：RSR@5 從 99% 降至 77%，給定寫入成功時的 AUR 從 96% 降至 79%）；因此預算縮減是記憶體語料中少數能直接作用於攻擊者尚未付出代價去克服之階段的控制措施

尚待解答的問題#

• 納入側通道規劃器呼叫與前綴快取中斷的費用後，輸入 token 減少是否仍能通過同條件計費稽核？論文回報提示表面的影響，並明確不宣稱這一點。部分解答（2026-08-03）：Prompt-Cache Economics 提供了這類別的稽核，但沒有針對 Self-GC——CAPC 將實測 API 支出與 Anthropic 帳單核對，誤差在 1% 以內，並發現一種減少 token 的技術（查詢感知壓縮，token 減少 3 倍），在 τ-bench retail 上的成本卻比完全不壓縮多出 40.1%。因此，這個問題所隱含的疑慮確實存在，而且已有實測；但目前仍沒有 Self-GC 專屬的計費成本稽核。補充說明（2026-08-04）：Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems 為其中一半提供了解析上界，另一半則明確不處理。額外開銷方面：由於每次壓縮都會作用於已壓縮上下文加上近期回合，壓縮次數只會線性增加，總成本為 N·W·(1 + c/p)——固定的乘數，而非逐漸增加的稅負（論文以 p = 8、c = 2 為例，約為 1.25×）。若 Self-GC 的側通道規劃器呼叫也遵循相同模式，規劃器開銷在漸近上就不會吞噬節省。至於快取部分，論文直接假設不計，理由是「忽略快取折扣；它們會改變常數，但不改變漸近性」；然而那正是本問題所問的項目。因此，這只把問題縮小到快取中斷，卻沒有提供任何測量來回答
• 立即提交時預期修剪的 0.3 損益兩平點可以移植到其他環境嗎？還是它只是某家供應商的快取定價與 TTL 所造成的結果？原文將它列為單一部署回歸測試中的作業策略。部分解答（2026-08-03）：Prompt-Cache Economics 原則上解決了可移植性問題——類似的門檻只取決於寫入溢價與讀取折扣，其形式為 ρ_cross(r) = (α − 1/r)/(α − β)；而且會隨供應商與 TTL 大幅變動（Anthropic 的 5 分鐘快取中 α = 1.25，1 小時快取中 α = 2.0；OpenAI 的 α = 1.0、β = 0.5）。綜合而言，數值無法移植，推導方式則可以。如今只要綜合 wiki 中已有的頁面，就能依這種參數化方式重新推導 0.3
• 在相同追蹤上，物件層級 GC 與清除後重新開始相比如何？語料中沒有來源直接比較兩者，而且它們最佳化的目標不同——GC 保留執行期間的依賴項，清除則重設注意力品質。
• 除了供應商之外，有人測量過經驗證的摘要化是否確實比粗略摘要更能保留忠實度嗎？整個三區間論證都取決於一個資料格——線性成本，且經檢查確認忠實度——但語料中沒有來源單獨檢驗這一點。Maximem 的 92.0%／93.2% 是對話記憶基準上的端到端系統分數，沒有摘要化消融；其驗證機制未公開；Self-GC 的無影響評審器評估的是離線候選計畫，而非回傳的驗證分數。可反證的實驗形式是：用同一套摘要器、相同追蹤資料，分別開啟與關閉資訊遺失檢查，再以後續任務成功率評分。
• 在代理程式實際使用的提示長度下，「協調內容量不會造成語意干擾」這個虛無假說還成立嗎？RCWT 的原任務消融在協調比例達 0.95 時仍維持天花板表現，但其最大條件約為總計 14,000 tokens；而本頁其他來源測得的工作階段中，每次請求平均輸入 70–90k tokens。可反證的實驗形式是：保留相同的 698-token 任務區塊，並在周圍加入 100k、250k、500k 的協調內容，重新執行原任務消融；選用的模型應是 Context Window Smart Zone 顯示其實際上限並非由宣稱的視窗長度所預測的模型。如果虛無結果在這種情況下仍成立，位移效應就是全部原因；若不成立，就有兩種機制，而語料目前把兩者都歸因於同一種機制。
• 代理程式記憶體失效中，有多少屬於推理充分性問題，而非檢索失敗——也就是缺少橋接文件，但其實已返回相關文件？語料中的每個記憶體基準，都只依據單一標準答案目標來評分命中，因此它們在結構上都無法測量這個數值；唯一相關資料是 LongMemEval 的多工作階段類別（75.2%）幾乎涵蓋某系統所有殘餘錯誤。值得關注的訊號：Maximem 表示，未來將推出一套同時測量準確率、延遲、token 效率與抗上下文腐化能力的基準。部分解答（2026-09-02）——機制已被單獨辨識，比例仍未知。Karunanidhi 執行了本項目暗示的區分實驗：在 LongMemEval 最弱的類別中，提高 top-k 會讓準確率單調下降（k = 15、30、50 時分別為 0.742 → 0.677 → 0.613）。增加候選內容反而有害時，檢索回想率就不可能是主要瓶頸；因此至少在多工作階段殘餘錯誤中，問題是讀取端彙整失敗，而非橋接文件缺漏——而且這項測量來自獨立、非供應商的系統，完整設定也有公開。之所以仍只能算部分解答，有兩個原因。首先，它只在一個類別辨識出機制，並未量化本問題詢問的比例；基準依舊只依單一標準答案目標評分，無法標記個別失敗究竟發生在檢索端或讀取端。其次，同一論文的安全性部分顯示，兩者原本就不容易明確切分：只要在語料中加入 1.2% 的受污染回合，準確率就會從 0.850 降到 0.300，而污染內容占擷取上下文的 20%——檢索器先失敗，接著讀取器因看似合理的上下文而過度計數；這仍是同一種機制。
• **兩條 top-k 曲線會在哪裡交叉？**無害情況下的準確率隨 k = 15、30、50 單調下降（Karunanidhi）；攻擊利用率則從 K = 1 上升到 5 後趨於平緩（PipePoison）。兩者使用不同系統，測量範圍也不重疊，因此語料只有兩條半截曲線，沒有交叉點。這項實驗可以反證，且用任何一種已公開的測試架構執行都很便宜：使用一個檢索器、一個讀取器和一份受污染語料，測試 K = 1、3、5、10、15、30、50，並在同一座標軸回報乾淨準確率與 AUR。如果無害情況下的準確率在 K = 5 前就已持平，檢索預算就是免費的安全旋鈕，語料也應如此說明；如果仍在上升，K = 1 防禦就會犧牲實際效用，而目前還沒有人為此定價。

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation — Gao & Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。此處僅引用 §5.2 的外部化機制（「代理程式可能因上下文視窗有上限，而將推理外部化至檔案，使文件成為工作記憶的一部分，而非參考資料」）、§4.1.2／表 1（工作筆記占 25.1%，3,033 個事件中有 760 個）、§4.1.3（產出 1,401，為查閱 1,615 的 0.87 倍），以及讀取後接續閱讀／推理的轉換。論文測量的是磁碟上的檔案，而非上下文視窗；因此只能佐證本頁所採紀律的動機，無法測量其任何機制。Agent Documentation Behavior 提供完整分析

• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents — Zang、J. Wang、Chen、Meng、L. Wang、Gao、Z. Li 與 Guo（Shandong University），Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents，arXiv 2609.00523 v1，2026-09-01，empirical，無 COI。這是一篇記憶體安全論文，此處僅引用 §4.4.3（受害者端敏感度研究：無害記憶體規模 100–3,000，見圖 8；檢索預算 K = 1–9，見圖 9；工具回傳數量 1–10，見圖 10）。圖 8–10 沒有資料標籤；此處引用的數值均取自重述圖表結果的正文。完整解析筆記與安全性分析見 Memory and Context Poisoning

• Self-GC: Self-Governing Context for Long-Horizon LLM Agents — Hao、Meng、Yin、Zhu 與 Cao（Xiaohongshu），Self-GC: Self-Governing Context for Long-Horizon LLM Agents，arXiv 2607.00692，2026-07-01，empirical。框架（索引物件、折疊／遮罩／修剪、規劃—預演—提交、快取感知提交及其含 0.3 門檻的 CommitBenefit 表達式）、表 1–4（資料集管線、線上切分規則、Hard Set 與 Production Suite 結果及 Wilson 信賴區間）、表 5–7（提示安全性對應、執行階段設定、失效分類）、規劃器穩健性稽核、限制。依圖像雙重檢視規則檢視全部 7 張圖：圖 1（共享追蹤上的物件圖與 token 緩衝區比較；圖內標為「ReCoG」）、圖 2（非同步側通道規劃器、待處理計畫、延後提交）、圖 3（折疊／遮罩／修剪前後的具體 JSON——<system-reminder> 折疊指標、保留開頭與結尾各 10% 的遮罩、影像降級為修剪）、圖 4（取捨散佈圖，Self-GC 在兩套測試中都位於左上方）、圖 5（六天日間輸入 token 數，絕對值約 70–90k，幾乎每個時段的處理組都低於對照組）、圖 6（前綴快取時間軸：穩定命中、提交時後綴失效、重新快取；預演後丟棄的計畫不會進入主迴圈）、圖 7（ContextObject 資料模型：id/span/state/action/recovery，GC 目標不包含助理的銜接文字）

• Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems — Gaurav Dadhich（唯一作者；Maximem——聯絡信箱 gaurav@maximem.ai），Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems，arXiv 2607.21503，2026-07-23，empirical。完全存在供應商利益衝突：論文的參考實作與唯一基準測試對象都是作者自有產品 Maximem Synap，且表 3 是供應商撰寫的競品比較。§2（五項基本機制、以架構處理耦合的論述、使用者／客戶／用戶端範圍階層、記憶體工具與平台的類別邊界）；表 1（依缺少的基本機制對應生產環境失效模式——資料已核對且無誤：10,134 筆資料／38 筆可用／99.6% 垃圾資料率，以及 token 數從 18,282 降至 122、準確率從 66.7% 降至 57.1% 的斷崖式下滑；後者是二手引用 Zhang 等人 2025 年的研究，arXiv 2510.04618，並非本論文結果）；§3.1 加附錄 A（O(n²) 推導、R(n) = t(n+1)/2W 及示例敏感度表；每個儲存格均依封閉形式獨立重算，結果正確）；§3.2 加表 2（三種情境比較，核對無誤）；§3.3 加附錄 B（推理充分性鏈、五個領域的檢索研究及列出的七項限制；表 B1／B2 已與正文核對，內容無誤）；§4（依合約說明 Synap 的元件，並聲明內部實作屬專有資訊；供應商宣稱命中率達 60% 以上的預測）；§5（壓縮額外成本模型 N·W·(1+c/p) 及約 80／90／96% 的節省幅度，已重新計算且前後一致）；§6.1–6.2 加表 2 的設定揭露與各類別細分（核對無誤；LongMemEval 數量合計為 500 與 460）；§6.3（範圍與限制——沒有延遲、每項任務 token 成本或上下文腐化測量，僅可依要求提供逐次執行產物）；§8（決策層級的上下文前沿，以及對其列出的未解問題所加註的「雖然我們已解決大部分」說法）。 解析警告。表 3（供應商比較表）中的儲存格遭合併——Maximem Synap 與 SuperMemory 兩列合併為一列——因此未引用其解析結果；上文引用的數值是在匯入時還原並核實（Synap：92.0%，由 gpt-5-mini／gpt-5-mini 評分；SuperMemory：85.2%／84.6%／81.6%，由 Gemini-3 Pro／gpt-5／gpt-4o 評分，並以 gpt-4o 擔任評審；Zep：71.2%，由 gpt-4o／gpt-4o 評分；Mem0 與 Letta 未公開結果）。表 4（系統 × 基本機制涵蓋率）在解析時嚴重錯亂——涵蓋符號與註腳標記跨欄串接，無法還原任何一列，且未在任何地方引用。僅有外觀問題：docling 將行內變數名稱中的底線跳脫（bubble\_sort），論文圖內 ID（F1、F3、F4、F7）與圖說編號（圖 1–4）不一致。依圖像雙重檢視規則檢視圖 1–4；兩者都包含正文未提及的內容——圖 1 將全域知識層標示為僅供實體正規化，不作為檢索範圍；圖 3 則將經驗證的摘要化準確率畫得略高於完整附加內容，而非與其持平；後者把未經測量的上下文腐化主張放進圖表中。圖 5–6（區塊架構、各類別長條圖）重述了正文與表格已有的內容

• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking — Arulnidhi Karunanidhi（Quantify Labs Ltd——Aegis 的開發商；Aegis 是受評估的記憶體層；論文未聲明 COI），Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking，arXiv 2608.21230 v1，2026-08-21，empirical。此處僅引用無污染情況下的部分：§5.2（LongMemEval_S 重播協定——每個對話回合儲存一筆記憶、各問題使用不同命名空間、top-k=15、不重新排序或改寫查詢、逐字使用官方評審提示），以及 §6.1 與表 2（各類別基準、multi-session 的 top-k 掃描，以及兩個基準的注意事項——n=500 時為 0.860，n=120 重測為 0.850，McNemar p=0.45）。**表 2 已與 pdftotext -layout 核對，解析完整無誤。**安全性部分——污染結果與來源排序分析——見 Memory and Context Poisoning

• RCWT: Measuring Task-Budget Displacement from Coordination Content in LLM Calls — Brenda Lelis 與 Rodrigo Cabral-Carvalho（巴西聖保羅的 CloudWalk, Inc.），RCWT: Measuring Task-Budget Displacement from Coordination Content in LLM Calls，arXiv 2607.12216，2026-07-13，empirical。§3.1（固定預算協定：c + u + r = W、u = 337、cl100k_base 建構方式、執行器目標 q = c/(W−u) 與回報的 p = c/W、8 個有效評分項目及排除的 2 個地板效應項目）；§3.2（logistic 形式與殘餘預算參數 θ，並附作者提出的「精簡插值，不是普遍定律」提醒）；§3.3（原任務消融——t = 698、比例 0／0.50／0.75／0.90／0.95、每個順序 N=5，合併為 10 次呼叫與每個資料格 80 個欄位判定、以確定性 JSON 評分；因 2.0 Flash 無法使用而改用 Gemini 2.5 Flash）；§4.1–4.4（斷崖效應、視窗縮放論述、消融虛無結果、自成一體的演算法探測，以及 Haiku／GSM8K 例外）；§5–6（範圍、明確拒絕語意干擾的解讀、協調內容的異質性及完整限制清單）；附錄 A。依圖像雙重檢視規則檢視圖 1——它確認表 A1、將斷崖區域從約 83% 起標色，並顯示正文未提及的 GPT-4.1-mini 非單調尾端。解析警告：表 2（依任務而變的 logistic 中點）中的儲存格遭合併——四個探測列全併成一列，每格都含四個串接數值——因此未引用其解析結果；上文引用的各探測對應資料於匯入時還原，且以 θ = W(1 − p₀) 獨立交叉核對，四列的誤差都在一個 token 內

• Security Incident INC-2026-07-28-01 — UK AI Security Institute，2026-08-04（case-study，第一方自行揭露）：§4.2.1 的保留語氣摘要化假說、圖 5 中 750 回合時間軸上的摘要化事件標記，以及 圖 7a 引述的 PARALLEL-CLONE AGENTS (resolved anomaly) 摘要