Latent Cache Flow：LLM 代理間不經文字直接傳遞 KV 快取，8.5× 加速通訊
arXiv:2605.22863 · 2026-05-26
多代理 LLM 系統目前的標準通訊方式是讓模型將訊息輸出為文字，再由下一個模型讀取，這造成資訊損失與延遲。Latent Cache Flow（LCF） 提出直接壓縮並傳遞 KV cache 的方法，在兩模型上下文不同的情況下，達到 23% 更高準確率與 8.5× 通訊加速，所需的 adapter 大小僅為前代方法 Cache-to-Cache（C2C）的 4%。
核心設計
先前的 C2C 方案（論文 arXiv:2503.XXXX）對單一 token 各自翻譯 key/value，需要大型 adapter（956 MB）且要求兩模型使用相同上下文。LCF 的創新是聯合壓縮與翻譯：對 key 和 value 整體操作，同時生成「新資訊的摘要」（summary of new information），讓接收方模型即使上下文不同也能使用傳入的 KV cache。
技術上，LCF 學習一個小型 adapter 網路，將來源模型的 KV 投影到目標模型的 KV 空間，並同步對序列長度做壓縮。13 MB 大小的 adapter 在相同上下文測試中超越 956 MB 的 C2C adapter，差距來自於聯合壓縮消除了大量冗餘表示。
規格細節
| 指標 | LCF | C2C | 文字通訊 |
|---|---|---|---|
| Adapter 大小 | 13 MB | 956 MB | — |
| 不同上下文準確率 | +23% | 不支援 | 基準 |
| 加速比 | 8.5× | — | 1× |
影響範圍
LCF 對多代理管道（pipeline）最有意義：當 agent A 完成某個任務後需要將結果傳給 agent B，目前的文字中繼不僅有延遲，還會喪失模型內部表示中的細節。直接傳遞壓縮 KV cache 可以保留更豐富的語義資訊，同時大幅降低頻寬需求。限制在於 adapter 需要針對特定的模型對（source-target pair）訓練，跨模型通用性尚需進一步研究。
長上下文 LLM 的位置失效：任務移到視窗中段，模型準確率暴跌 88 個百分點
arXiv:2605.23170 · 2026-05-26
研究者審計了 11 個主流長上下文基準測試，發現全部都沒有同時控制任務位置、填充內容與上下文長度這三個變數。在控制實驗中，當目標任務從上下文末端移到中間位置，部分模型準確率下降高達 88 個百分點——這意味著 long-context 排行榜上的高分模型，實際上可能只是擅長處理末端任務。
實驗設計
研究評估了 9 個 LLM，在 GSM8K（數學推理）與 ARC-Challenge（閱讀理解）兩個基準上，系統地將任務插入上下文的不同位置（末端、中間），並控制填充內容（無關文字）的類型。上下文長度固定在 64K tokens，以隔離長度變數。
核心發現
MiMo-v2-Flash 在 64K 上下文、中間位置任務的情況下，準確率從 96% 暴跌至 8%——88 個百分點的絕對差距。錯誤分析顯示：76% 的中間位置錯誤答案與周圍填充文字內容相符，而末端位置只有 22%，表明模型在長上下文中存在填充文字干擾答案（filler-answer interference）的系統性問題。
值得注意的是，近期新模型表現較好：四個廠商新版本中，有三個在 64K 長度下，中間與末端位置的準確率差距在 6 個百分點以內，顯示問題是可以被工程化緩解的。
影響範圍
這項研究直接挑戰了現有 long-context benchmark 的有效性。若要真正評估模型的長上下文能力，必須同時控制任務位置與填充內容類型，而非僅測試「上下文長度達到多少 tokens 時仍能正確回答」。對 RAG 系統設計者，這也意味著文件排序策略（將最相關的文件放在哪個位置）對準確率的影響可能遠超過模型選擇本身。
原始來源：arXiv:2605.23170 — Positional Failures in Long-Context LLMs
Harness、Scaffold、Policy：AI 代理術語混亂的根源與 HuggingFace 的統一定義
Hugging Face Blog · 2026-05-25
HuggingFace 發表 AI 代理術語指南，起因是 ICLR 2026 上不同框架與產品對相同術語有不一致的解釋。文章明確區分了在工程討論中最常被混淆的幾個概念，並指出「目前沒有通用定義——目標是提供一個實用的心智模型」。
關鍵術語區分
最重要的區分是 Scaffolding（鷹架）與 Harness（執行框架）：
- Scaffolding：模型從中工作的內容，包含系統提示、工具描述、回應解析格式、上下文管理策略
- Harness：執行層，呼叫模型、處理工具呼叫回傳值、決定何時停止、讓代理真正「跑起來」的迴圈
- Agent = Model + Harness + Scaffolding，將原始文字生成轉化為可在迴圈中行動的系統
其他常被混用的術語：Policy（代理遵循的行為規則，即在觀察下每個行動的概率分布）、Rollout（一次完整的代理執行，從起始狀態到終止，又稱 trajectory 或 trace）、Reward（可分為可驗證的、學習的、稀疏的、密集的）。
Context Engineering 的定義
Context Engineering 被定義為「設計代理上下文視窗中放置什麼」——這個術語近期在社群中快速流行，因為隨著模型能力提升，向上下文視窗「放什麼」往往比調整模型本身更有效。這包含如何排列工具描述、如何管理長對話歷史的壓縮，以及什麼時候使用 RAG 注入外部知識。
影響範圍
Skills（技能）被定義為「多步驟任務知識的可複用結構化套件」，與 tools 的區別在於 skills 通常包含比單一 API 呼叫更豐富的協調邏輯。文章的價值在於：當工程師跨越不同框架（LangGraph、AutoGen、Claude Code）討論代理架構時，有了一套共同的術語基礎，可以減少「雞同鴨講」的溝通成本。