語言模型生成一個 token 的計算量，隨它在上下文（context）裡的位置線性增加，所以上下文越長，後面的 token 生成得越慢、占用的記憶體越多，放在雲端服務也越貴。模型的上下文視窗（context window）卻越做越大：Claude Opus 4.5 是 20 萬 token，GPT 5.6 Sol 到了 105 萬。需要這麼長的上下文，常見的理由有兩個：任務附了很長的輸入，或任務要做很多步，對話歷史一路累積。NVIDIA 的研究者在一份技術報告裡問：這兩種任務真的需要長上下文嗎？作者的答案是不需要。讓 agent 經常壓縮（compaction）自己的工作紀錄，再把長輸入存成檔案讓它挑著讀，Opus 4.5 和 GPT 5.6 Sol 在長步驟（long-horizon）與長輸入（long-input）任務的評測上分數大致維持，單次呼叫用到的最長上下文（尖峰上下文）卻短得多；伺服器把上下文視窗縮小，整體的輸出吞吐量也跟著上升。
這份報告是〈You don’t need long context〉，作者是 Peter Belcak、Saurav Muralidharan、Pavlo Molchanov 等十二位 NVIDIA 研究者，2026 年 11 月 3 日上傳到 arXiv。它標明是技術報告（technical report），31 頁，沒有經過同儕審查，也沒有附上作者自建執行框架（harness）的程式碼。下文的數字都是作者自己測的，目前沒有第三方重現。
agent 怎麼用短上下文做長任務？
所有實驗都用極簡的 ReAct 迴圈，也就是讓模型交替推理與行動的 agent 迴圈：任務放在第一則使用者訊息，模型每一步只下一個 Bash 指令，指令和它的結果附加到對話裡。軟體工程和終端機任務用公開的 mini-swe-agent（v2.4），其他評測用作者把它一般化而成的 mini-agent，迴圈和 Bash 介面相同，只換掉各評測的指示、環境與提交規則。
在這個迴圈上，作者比較三種上下文管理方式：
- 全歷史累積（Full-History Accumulation，FHA）：每個動作和觀察都留在同一段對話裡，直到任務結束。這是 mini-swe-agent 的預設，也是比較的基準。
- 對話結束壓縮（End-of-Conversation Compaction，EoCC）：照常累積，等對話長度越過壓縮門檻，就請模型在對話裡寫一份壓縮後的狀態；執行框架再開一段新對話，只放原始任務和這份狀態，接著做下去。門檻之上另有總上限，留空間給壓縮這一輪，壓縮沒及時寫完就終止對話。論文把兩個數字寫成「總上限／壓縮門檻」：24K/18K 就是對話接近 1.8 萬 token 時壓縮，任何時候都不超過 2.4 萬。
- 單動作壓縮（Single-Action Compaction，SAC）：每段對話只拿到任務和目前的語意狀態（semantic state），也就是一段用自然語言寫的工作進度，做一個動作、看結果、更新狀態，然後整段丟掉，下一個動作再開新對話。
長輸入任務另外用選擇性讀取（selective input reading）。長輸入不貼進對話，存成 agent 檔案系統裡的文件（例如 input01.txt），任務訊息只說有哪些檔案，agent 用 grep、sed、awk、head 這類標準工具自己找、自己讀。附錄 E 的系統提示另外提供有上限的讀取指令 doc-read，每次預設讀 6,000 字元、最多 8,000，並要求 agent 只讀需要的部分。例如 LongBench v2 的第一題要翻譯一句 Kalamang 語，附的文法書約 100 萬字元、1.9 萬行；agent 先 grep 句子裡的一個詞，再依回傳的行號讀出 36 行上下文。讀長輸入因此變成一連串動作，長輸入任務就化成長步驟任務，可以用同樣的壓縮處理。
好的壓縮要寫什麼？
作者在附錄 A 說明，他們起初想找最便宜、又最能維持自主軟體工程任務準確率的壓縮方式，結果發現把壓縮當成摘要（summarization）來寫效果不好：語言模型做摘要，傾向平均對待輸入裡的每個事實，還容易過度強調 agent 紀錄裡重複出現的片段，不管它們對後面的工作有沒有用。最能維持準確率的壓縮，是替接下來的工作挑選事實的交接（handoff），內容有：
- 原始任務，逐字或接近逐字照抄；
- agent 目前在做什麼、打算怎麼做、下一步是什麼；
- 跟後續執行直接相關的產物：從任務拆出來的計畫、怎樣才算完成的條件，以及跟這兩者相關的資訊或指向相關檔案的指標。
作者說，不論壓縮多頻繁，這個結構維持的準確率都最高，而且能延伸到軟體工程以外的任務；他們在全部評測都用同一個結構。mini-swe-agent 用的壓縮提示收在附錄 G.1，在對話越過門檻時以使用者訊息送出，大括號是依評測填入的欄位：
Stop work. Write only a concise handoff recap; do not run commands or call tools.
The conversation will reset to the system prompt, task, and this recap.
{persistence}
Record:
1. Objective - one line describing the required result.
2. Established facts - exact paths, relevant symbols or commands, observed values,
and important errors/output. Separate observations from unverified ideas.
3. Applied changes - each changed/created file, what changed, and whether verified.
4. Verification - exact checks run, outcomes, failures, obstacles, and workarounds.
5. Dead ends - failed approaches that should not be repeated.
6. Remaining plan - outstanding subgoals, in execution order; the immediate next
command or edit; and the condition for completion.
{handoff_details}
If needed output was truncated, give a narrow command to retrieve it.
{submission_reminder}縮小上下文視窗，吞吐量差多少？
作者用三個開放權重模型，在 H100 上以 vLLM 服務來測。每種上下文視窗大小下，請求長度在視窗內均勻抽樣，輸入已經在 KV 快取（KV cache）裡，每個請求生成 1,024 個 token；逐步提高同時請求數，取沒有發生 KV 快取搶占（preemption）時最高的整體解碼吞吐量（decode throughput）。視窗從 256K 縮到 16K，同樣硬體每秒解出的 token 數變成：
| 模型 | 部署 | 16K 相對 256K 的吞吐量 |
|---|---|---|
| GLM 5.2 | 16 張 H100，INT4 專家權重、BF16 活化值 | 3.6 倍 |
| Kimi K2.6 | 16 張 H100，INT4 專家權重、BF16 活化值、FP8 KV 快取 | 5.6 倍 |
| Qwen3 Coder Next | 8 張 H100，BF16 | 7 倍 |
這 7 倍是伺服器滿載時的整體服務容量：視窗設在 16K、請求都比較短時，同樣 8 張 H100 每秒產出的 token 總數是 256K 時的 7 倍，單一請求並沒有快 7 倍。作者再用 Nebius 2026 年 9 月每 GPU 小時 3.85 美元的隨需價格，把吞吐量換算成每百萬輸出 token 的成本，論文摘要裡「後面的 token 成本差距可達 7 倍」就是這樣算出來的。
單一請求也會隨上下文變慢。作者在一台 DGX Spark 上一次只跑一個請求，量了幾個開源模型的生成速度和記憶體占用怎麼隨輸入長度變化。論文說，其中幾個模型後面的 token 生成時間約是前面的兩倍，記憶體占用也變大；正文沒有寫明是哪幾個模型，只附了圖。
上下文變短，分數有什麼變化？
長步驟任務用六項評測：SWE-bench Verified、SWE-bench Multilingual、Terminal-Bench 2.1、FRAMES、τ²-bench 和 BFCLv3。前四項測 48K/36K 到 16K/12K 四種設定，BFCLv3 測 24K/18K 到 12K/8K，τ²-bench 測 16K/12K 到 8K/6K，每個模型共 22 組設定。和 FHA 相比，EoCC 讓 Opus 4.5 的分數變動 −3.7 到 +5.6 個百分點，GPT 5.6 Sol 是 −3.3 到 +4.4。照附錄 C 的表格數，掉超過 2 個百分點的設定，GPT 5.6 Sol 有 5 組，Opus 4.5 有 1 組，其中 4 組在 FRAMES：這項要串起多份資料才答得出的多跳問答，在每一種設定下都低於基準，Opus 4.5 低 1.3 到 3.7 個百分點，GPT 5.6 Sol 低 1.5 到 3.3。作者估算，縮短上下文後，Opus 4.5 的成本降到原本的 1/2.2 到 1/8.8，GPT 5.6 Sol 降到 1/2.4 到 1/5.0。這個估算假設 API 依上下文視窗大小計價、視窗越小單價越低；現行 API 按每百萬 token 的固定單價收費，所以它不是實際帳單，算法見最後一節。作者也說，頻繁壓縮讓 agent 重做做過的事、總 token 多到抵銷節省的情況，大致沒有發生；不過每段新對話都要重送任務和交接，附錄 C 的表格裡，快取命中的輸入 token 通常減少，未快取的輸入和輸出 token 通常增加。
長輸入任務用七項評測：LongBench v2、LOONG、AA-LCR 三項真實文件問答，加上 NIAH、RULER、Counting-Stars、BABILong 四項找針式（needle-style）測驗，也就是在很長的輸入裡埋入少數關鍵事實，看模型能不能找出來並加以運用，輸入長度從幾千 token 到上百萬。基準把整份輸入貼進對話，對照組用選擇性讀取，壓縮只當備援。Opus 4.5 的分數變動 −0.4 到 +40.0 個百分點，GPT 5.6 Sol 是 +1.0 到 +30.9；只有 Opus 4.5 在 LongBench v2 低於基準，67.6 對 68.0。找針式測驗的增幅最大：NIAH 上兩個模型都到 100%（基準是 60.0% 和 80.0%），RULER 的平均召回率從 62.5% 和 65.5% 升到 95.7% 和 96.4%。作者指出壓縮次數的中位數接近零；在 LongBench v2 和 LOONG 上，Opus 4.5 處理的文件長度跨了好幾個數量級，對話總長度大致落在同一帶。照同樣的估算，成本降到 Opus 4.5 原本的 1/6.5 到 1/54.6、GPT 5.6 Sol 的 1/4.4 到 1/233.3。Opus 4.5 的視窗只有 20 萬 token，NIAH、RULER、BABILong 卻都有超過 20 萬 token 的輸入（最長 50 萬到 100 萬），論文沒有說明全文基準遇到放不下的輸入怎麼處理，所以 +40.0（NIAH）這種增幅有多少來自基準本身讀不完，從論文看不出來。
每個動作都壓縮的 SAC，只在 mini-swe-agent 上測了 SWE-bench Verified 和 Terminal-Bench 2.1（Table 2）。分數是解決任務的百分比；尖峰上下文是單次呼叫最長的上下文，以千 token 計，寫成中位數／最大值；最佳 EoCC 是幾組設定裡分數最高的一組：
| 評測 | 模型 | FHA | 最佳 EoCC | SAC | 尖峰上下文 FHA | 尖峰上下文 SAC |
|---|---|---|---|---|---|---|
| SWE-bench Verified | Opus 4.5 | 70.0 | 74.8（24K/18K） | 70.2 | 32/200 | 8/16 |
| Terminal-Bench 2.1 | Opus 4.5 | 47.2 | 52.8（32K/24K） | 51.8 | 27/130 | 9/19 |
| SWE-bench Verified | GPT 5.6 Sol | 84.4 | 88.8（48K/36K） | 82.4 | 18/173 | 7/15 |
| Terminal-Bench 2.1 | GPT 5.6 Sol | 87.6 | 88.8（48K/36K） | 84.3 | 17/133 | 8/37 |
Opus 4.5 用 SAC，SWE-bench Verified 持平，Terminal-Bench 2.1 高 4.6 個百分點；GPT 5.6 Sol 兩項分別低 2.0 和 3.3。SAC 的尖峰上下文中位數只有 7K 到 9K，最大值從 130K 到 200K 降到 15K 到 37K。
SSSM 是什麼構想？
SAC 每一步只帶著一段自然語言狀態也做得下去，作者由此提出語意狀態空間模型（semantic state space model，SSSM）的構想：一種經過後訓練的模型，讀一段描述對話狀態的自然語言，推理下一步，採取行動，記下結果，再更新那段狀態，讓另一個推論實例能接手做完。Mamba 這類狀態空間模型（state space model，SSM）在生成 token 之間保存黑箱的神經狀態；SSSM 在對話回合之間保存一段可讀、可解釋的自然語言狀態，「語意」一詞由此而來。作者推測這種模型訓練起來更省資料，也看不出它為何比不上累積全歷史的模型；不過論文沒有訓練或評測任何 SSSM，它目前只是構想。
用之前要知道哪些限制？
- 省多少錢是估算。作者從三個開放模型量到 16K 對 256K 的成本比，取平均 0.20，再假設前沿模型在完整視窗時收現行定價、視窗縮到 16K 時只收兩成，中間線性內插，稱為「估算最佳化零售成本」（estimated optimized retail cost）。作者也指出，現行 API 按每百萬 token 的固定單價收費，不隨上下文長度變動。照論文表格裡按現行價格算的名目成本，長步驟任務有升有降：SWE-bench Verified 上，Opus 4.5 從 420 美元降到 296 到 380 美元，GPT 5.6 Sol 卻從 168 美元升到 184 到 203 美元，原因就是前面說的未快取輸入與輸出 token 變多。長輸入任務少讀了大量 token，按名目成本也明顯便宜，例如 LOONG 上 Opus 4.5 從 1,367.50 美元降到 498 到 534 美元。
- 開放權重模型的耐受度不一。附錄 D 用五個量化過的開放權重模型測 SWE-bench Verified 和 Terminal-Bench 2.1：Qwen 3.6 27B 和 MiniMax M2.7 比較穩；Gemma 4 31B、Step 3.7 Flash，尤其 Qwen3 Coder Next，預算一緊就掉得多。Qwen3 Coder Next 在 SWE-bench Verified 從 53.0% 掉到 16K/12K 的 3.6%，作者認為主因是它的操作紀錄太冗長，兩次壓縮之間剩不下空間推進工作。到了 16K/12K，五個模型在 SWE-bench Verified 都低於自己的基準。主要結果建立在 Opus 4.5 和 GPT 5.6 Sol 兩個閉源前沿模型上。
- 只測了自主完成的任務。τ²-bench 和 BFCLv3 有模擬的使用者，其餘評測都是一次交代任務，讓 agent 跑到結束；有真人在旁邊、會中途修正方向或說明偏好的協作，論文沒有測。作者在附錄 A 也承認，在有人參與的軟體工程流程裡，壓縮後常會遺失關鍵資訊，甚至丟掉使用者先前指示裡的偏好；他們的壓縮結構是為自主工作調出來的。
- 壓縮會丟資訊。作者在 3.1 節舉例：agent 有個擲硬幣工具，每次回報結果，壓縮的預算固定，遲早會丟掉某幾次的結果，之後要查第 i 次擲出什麼就一定答錯。他們的解法是讓執行框架保留每一則訊息的完整紀錄，再讓 agent 用選擇性讀取去查，查歷史就變成長輸入任務；論文提出這個做法，但沒有實測。
- 作者沒有排除真正需要長上下文的任務。結論寫明，這些證據不排除有任務能從長上下文得益，也沒有證明所有任務都能用短上下文完成；它們只表示「輸入很長」和「步驟很多」這兩個常見理由不足以支持長上下文。
參考資料
- Peter Belcak、Saurav Muralidharan、Pavlo Molchanov 等，〈You don’t need long context〉，arXiv.05306（HTML 全文 v1），2026 年 11 月 3 日；NVIDIA 技術報告，31 頁。