June 26, 2026 · 9:13 AM

Memory 技术日报 2026-06-26：Agent memory 评测、Block-GTQ 与 vLLM Jobs

本期筛出 5 条 memory/context 工程信号：Agent-native memory 评测把长期记忆拆成系统模块，Plans Don't Persist 提醒计划不能只留在上下文里，Block-GTQ 给出 RoPE-aware KV 量化路线，OpenViking 更新暴露 context database 的兼容痛点，HF Jobs 则提供长上下文 serving 的快速试验入口。

大模型 Memory 技术日报 @wei

Research Brief

本期按北京时间 2026-06-25 09:00 至 2026-06-26 09:00 取窗口。今天的口径需要先说清楚：窗口内没有凑出 3 条全新 arXiv v1；论文项主要来自 Hugging Face Papers 在 6 月 25 日的作者提交、上榜或社区讨论，原论文提交日期单独标出。工程项则按官方博客发布时间或 GitHub 提交时间入选。

速览

进展	窗口依据	核心增量	工程动作
Agent-native memory 评测框架	Hugging Face Papers 6 月 25 日 #1 Paper of the day，原 arXiv v1 为 6 月 23 日	论文把 agent memory 拆成表示与存储、抽取、检索与路由、维护 4 个模块，评测 12 个系统和 2 个基线，覆盖 5 类 workload 与 11 个数据集；结论是没有单一架构通吃所有场景。1 2	如果团队已经有长期记忆模块，别只看任务成功率；把抽取、召回、更新正确性和维护成本拆开测。
Plans Don't Persist	Hugging Face Papers 6 月 25 日作者提交，原 arXiv v1 为 6 月 22 日	replay pairing 显示计划信号在 Llama-3.1-70B 上一步后达到 0.453，又在一个 action-observation 步骤后下降 4.1 倍；HotpotQA 下降 12.4 倍。3 4	对长任务 agent，计划、约束和未完成子目标不能只靠「模型会记住」；要作为显式状态重新注入。
Block-GTQ KV-cache 量化	Hugging Face Papers 6 月 25 日作者提交，原 arXiv v1 为 6 月 23 日	Block-GTQ 按 RoPE 频率块给 key cache 分配 bit；在 10 模型诊断中，2/3 b-dim K-only 量化的逐层 MAE 降低 32-80%。5 6	长上下文 serving 团队可以把它放进 KV 压缩复现实验，重点测 128K 以上上下文的质量和显存账。
OpenViking context database	GitHub 在 6 月 25 日晚间连续合入 VikingDB grep、SDK 兼容和 schema 兼容修复	OpenViking 自称是面向 AI agent 的开源 context database，用文件系统范式统一管理 memory、resources 和 skills；6 月 25 日的提交集中在 grep schema 升级、旧实例 SDK 兼容和 VikingDB fallback。7 8 9	这类项目的风险已经从「能不能存」转到「schema 迁移、旧实例兼容、过滤语义是否稳定」。
HF Jobs 跑 vLLM server	Hugging Face Blog 6 月 26 日发布	官方教程用 `hf jobs run` 拉起 OpenAI-compatible vLLM endpoint，并提醒 Qwen3.5-122B 默认 256K context 会让 batch 预算吃紧；示例把 `--max-model-len` 设到 32768、`--max-num-seqs` 设到 256，OOM 或 cache-block error 时优先调低这两个参数。10	它不是新的 memory 算法，但给了一个可复现的长上下文 serving 压力入口：context length、并发序列数和 KV block 预算要一起调。

逐条判断

1. Agent memory 开始被当成数据管理系统评测

「Are We Ready For An Agent-Native Memory System?」的价值不在于又列一个排行榜，而是把 agent memory 从黑盒能力拆回系统模块。论文把记忆系统拆成 representation/storage、extraction、retrieval/routing 和 maintenance，并在 12 个代表性系统与 2 个基线之间比较这些模块的贡献。作者给出的结论也很实用：没有一个 memory 结构在所有 workload 上都占优，效果取决于结构是否对准任务瓶颈。1 2

配套的 MemoryData 仓库把这个方向落成了基准套件：README 写明它统一 4 个 benchmark families、22 个 method presets 和一个 main.py 入口，结果文件、agent state 和日志也按固定目录输出。11 这对工程团队的启发很直接：如果线上 agent 会长期积累偏好、项目背景或工具状态，评测不该只问「最终答对没」，还要问「错误来自抽取、召回、更新，还是维护策略」。

2. 「计划」不是可靠的隐状态，压缩上下文时最容易被误删

「Plans Don't Persist」把 long-horizon agent 的一个老问题量化了：计划写在前面，但执行很多步之后，模型未必真的把计划变成持久状态。论文用 replay pairing 比较「历史里保留计划」和「移除计划」两种轨迹的 hidden-state cosine distance；在 Llama-3.1-70B 上，计划信号在计划后一步达到 0.453，随后一个 action-observation 步骤就下降 4.1 倍。3 4

更刺眼的是压力测试：naive plan eviction 让 ALFWorld 成功率下降 34.7 个百分点，probe-gated re-surfacing 也没把损失补回来。4 这说明「把历史摘要一下」不等于记忆治理。coding agent、browser agent 或数据分析 agent 需要显式保存计划、约束、未完成检查项，并在关键步骤重新注入；否则压缩器看似省了 token，实际是在删任务状态。

3. Block-GTQ 把 KV 量化从 flat vector 改成 RoPE block 问题

Block-GTQ 的切入点很具体：低 bit KV-cache quantizer 往往把 cached key 当成平铺向量，但 RoPE 下 key 对未来 attention logit 的贡献会分解到位置相关的二维频率块。Block-GTQ 因此按每层、每个 KV head 的 RoPE block 能量来分配整数 bit，而不是均匀量化。5 6

论文和仓库给出的数字足够进入复现队列：K2V2 下，Llama-3.1-8B-Instruct 的 6-task NIAH average 从 70.6 提到 97.4，LongBench-EN average 从 36.87 提到 53.31；单 H800 上 Qwen2.5-3B-Instruct 的 packed K3V3 达到 3.24 倍 KV-cache 压缩，128K context 下比 fp16 FlashAttention2 快 1.34 倍，峰值显存从 56.31 GB 降到 19.85 GB。6 12

需要注意的是，仓库也写清楚 fused decode kernel 目前 benchmarked 的后端是 Hopper/H800，Turing 和 Apple MLX 还在 planned 状态。12 所以它更像「先在 CUDA/Hopper 路径验证质量和显存收益」，还不是一个可以直接覆盖所有部署环境的通用加速包。

4. OpenViking 的更新暴露了 context database 的真实工程痛点

OpenViking 不是本窗口才出现的项目，但窗口内的提交有增量。官方仓库描述里，它是给 AI Agents 使用的 context database，用文件系统范式统一管理 memory、resources 和 skills。7 6 月 25 日晚间，项目合入了几类偏底层的修复：legacy collections 兼容 grep schema upgrade、Python SDK 对旧实例省略 null/empty request fields、VikingDB grep fallback 与 1MB text field byte limit。8 9 13

这类更新不显眼，但很像 agent memory 基础设施真正会遇到的问题。记忆数据一旦跨版本、跨 SDK、跨存储后端，检索字段、过滤条件和 schema 兼容比 demo 里的「能召回」更重要。准备引入外部记忆层的团队，应该把 schema migration、旧客户端行为和 fallback 语义写进验收，而不是只跑 happy path。

5. HF Jobs 给了长上下文 serving 的快速试验入口

Hugging Face 这篇教程不是 memory 论文，但它直接碰到了 serving 里的 context budget。教程用官方 vllm/vllm-openai 镜像在 HF Jobs 上拉起一个 OpenAI-compatible endpoint，并给出 Qwen3.5-122B on 2×H200 的示例；由于该模型默认 256K context 会挤压 vLLM 的 batch 设置，示例把 --max-model-len 设为 32768，把 --max-num-seqs 设为 256。10

这条值得放进 memory 日报，是因为它把「长上下文」翻译成了一个可调的系统账本：context length、并发序列数、KV cache block、硬件 flavor 和 endpoint 生命周期。教程还写到，如果模型启动时遇到 out-of-memory 或 cache-block error，先调低 --max-model-len 和 --max-num-seqs。10 对要复现 Block-GTQ、prefix cache 或 agent memory backend 的团队来说，这种临时 serving 环境可以作为便宜的预实验场。

今天的工程判断

做 agent memory 评测时，先拆模块。一个长期记忆方案如果只给端到端准确率，很难解释它在抽取、召回、更新还是维护上出了问题。
做长任务 agent 时，计划、约束和未完成事项要当成任务状态存储。上下文压缩器不能默认删掉「看起来已经说过」的计划。
做长上下文 serving 时，KV 压缩与 context length 调参要放在同一张账上。Block-GTQ 给了 KV 侧的压缩路线，HF Jobs/vLLM 给了快速压力测试入口。
引入 context database 时，评审重点不只看 API 漂亮不漂亮。schema 升级、旧客户端兼容、检索 fallback 和字段限制，才是上线后最容易咬人的地方。