Memory 技术日报 2026-08-04：团队记忆资产、滑窗 KV 与前缀缓存边界

Memory 技术日报 2026-08-04：团队记忆资产、滑窗 KV 与前缀缓存边界

本期用三条窗口内的一手工程更新，拆解团队记忆资产治理、滑动窗口 KV 预取，以及可变 Skill 对前缀缓存边界的影响。

大模型 Memory 技术日报
大模型 Memory 技术日报@wei
本期覆盖 2026 年 8 月 3 日 09:00 至 8 月 4 日 09:00（北京时间）。窗口内没有足够证据支持一篇新的 memory 论文条目，因此只收三条可以回到 GitHub release 或具体 commit 核验的工程更新：TencentDB Agent Memory 把记忆组织成团队资产，LMCache 把滑动窗口约束推进到 KV 预取控制面，Hermes Agent 则调整可变技能在 system prompt 中的位置。
三条不在同一个层次上。第一条回答「哪些经验可以被谁装配」，第二条回答「哪些 KV chunk 在当前窗口内仍然值得持有」，第三条回答「哪一段 prompt 变化时不应击穿稳定前缀」。共同的工程问题是状态边界，而不是简单地把更多 token 塞进上下文。它们都值得复现，但不能合并成一个未经验证的端到端收益结论。

1. TencentDB Agent Memory：把记忆变成可治理的团队资产

变化是什么

TencentDB Agent Memory v2.0.0 的 GitHub release 页面显示发布时间为 8 月 3 日 12:49；对应 release commit 0aff21a2d9f2b8a0354aaa80a2e586aab4054562 的作者和提交者时间是 2026-08-03 11:38:59Z，即北京时间 8 月 3 日 19:38:59。本期以这个可解释的 commit 时间作为窗口锚点。12
这次发布的增量不是再加一个向量检索接口，而是把记忆拆成四类可管理资产：
  • Chat Memory：从 L0 原始对话逐层整理到 L1 事实、L2 场景和 L3 长期认知，用于跨会话保留偏好、决策和交互历史。
  • Skill：带版本、资源文件、触发边界、执行步骤和验证规则的可复用 SOP；v2.0.0 增加了强制归档，减少关键 Skill 只停留在一次任务里的风险。
  • Wiki：把文档整理成结构化页面和链接图谱。
  • CodeGraph：索引符号、文件、调用关系和影响路径，并增加代码库定时同步，供 Agent 修改代码前做影响分析。
Memory Hub 进一步给这些资产加上 Owner、版本、状态、可见性和 Agent Loadout。Proxy 则在每轮请求中按绑定关系，把 L2/L3 memory、匹配到的 Skill、Wiki 或 CodeGraph 内容装配进 system prompt，并通过 Cost Guard 为不同 Agent 配置模型。3
从 memory 系统角度看，重要变化是「记忆」不再等同于一张跨会话聊天表：它同时包含持久事实、可执行经验、文档结构和代码关系，并把「谁能读」「哪个版本有效」「给哪个 Agent」放进装配流程。这个方向更适合团队级 coding agent 或需要在多个 Agent 间复用经验的系统。

适合谁先跟进

适合维护多 Agent 工作流、内部知识沉淀或 coding agent 平台的团队。尤其当问题已经从「能不能召回」变成「共享经验会不会泄露、过期 Skill 会不会继续触发、改代码前能不能看到影响范围」时，Hub 的权限、版本和 loadout 才是主要观察点。

先复现什么

按 release 和仓库安装说明，先做一个最小本地部署：
git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
# 在 .env 中填写 memory group 和 proxy group 两组 LLM 参数
./start-all.sh
启动后打开 http://localhost:8125/，创建 Team 和 Agent，分别导入一份文档、一个代码仓库和一段对话，再检查四类资产的状态、可见性和 Agent Loadout。随后通过 Proxy 发起一轮请求，确认真正进入 system prompt 的是被绑定且可见的资产，而不是整个仓库或整个历史对话。Wiki 与 CodeGraph 是异步构建的，需要等到 ready 后再判断检索和装配结果。安装、迁移和 Proxy 前置条件见仓库中的 INSTALL.md 和 INSTALL_CN.md。3
复现时应把四个问题分开记录：资产有没有成功生成，权限是否正确，检索是否找到目标，最后是否真的注入了 prompt。否则一次「Agent 似乎记住了」无法区分是持久化、检索还是装配起作用。

局限在哪里

release 和 README 没有给出同时包含模型、硬件、运行时和基线的 v2 新功能 benchmark，因此本条不能证明召回质量、延迟或成本改善。README 中的 PersonaMem 数字也缺少本期要求的完整实验口径，不纳入结论。当前 Wiki 与 CodeGraph 的构建是异步的，CodeGraph 对私有仓库和 SSH 凭据仍有限制，自动化路由也仍在迭代。这个 release 证明的是资产模型、治理和接入路径变得更完整，不是证明所有 Agent 都会因此表现更好。

2. LMCache：滑动窗口开始决定哪些 KV 可以被提前释放

变化是什么

LMCache commit 75e6083f12d6f08f84463c99932024e087656b64 的作者和提交者时间是 2026-08-03 18:16:11Z，即北京时间 8 月 4 日 02:16:11；提交标题为「Prefetch sliding window 3/3: Prefetching / load only KV cache in sliding window」。4
这次改动针对的是混合 attention 场景下的 KV 预取边界。代码和设计文档明确了几件事：
  1. 位图布局改为 chunk-major / group / rank-minor。同一个 chunk 会按 object group 和 KV rank 组织，fold 先判断每个 group 能否服务某个前缀长度，再找出所有 group 共同可服务的最长前缀；unfold 把这个长度还原成各 group 的保留 mask。
  2. 预取先锁 L1，再查 L2。预取控制器先把 L1 中可观察到的 key 变成锁持有状态，再计算 L1 与 L2 合并后的命中和最终保留集，避免出现「已经算进命中、但尚未锁住，随后被并发淘汰」的时间缝隙。
  3. 窗口外的旧 chunk 可以提前释放。如果某个 chunk 已经落在 L1 命中窗口左侧，L2 只会把命中向右延长，最终窗口不会重新覆盖它，所以可以在慢速 L2 查询期间释放这部分资源。
  4. L2 预留失败采用全有或全无。遇到 OOM 或竞争时，整次 L2 load 放弃，回退到 L1 命中；失败不会被伪装成一个部分成功的扩展命中。
  5. 锁与 LRU 更新解耦。锁定或解锁不再自动刷新淘汰新鲜度，完成阶段只 touch 实际保留、真正服务请求的 key。
这组变化的价值不在于宣称「滑窗一定更快」，而在于把 attention 的窗口规则、分布式 rank 布局、L1/L2 锁状态和可淘汰范围放进同一个可检查的状态机。对 KV 系统来说，知道某个 token 在逻辑上可用，还不等于知道它在物理层仍被保留。

适合谁先跟进

适合维护 LMCache 分布式预取、混合 attention 或分层 KV 存储的工程师。也适合正在把远端 KV、L1/L2 cache 和滑动窗口放在一起的人，因为这条提交把「命中多少」和「为命中需要保留什么」明确分开了。

先复现什么

在固定 commit 上安装并先跑控制器测试：
git clone https://github.com/LMCache/LMCache.git
cd LMCache
git checkout 75e6083f12d6f08f84463c99932024e087656b64
pip install -e .
pytest -q tests/v1/distributed/test_prefetch_controller.py
重点看提交中对应的三类回归：并发淘汰不能缩小已经承诺的前缀，L1 后缀与 L2 前缀可以拼成连续命中，以及滑动窗口外的 key 能在第一次淘汰机会被释放。随后再检查 tests/v1/distributed/test_bitmap_ops.py、test_distributed_storage_manager.py 和多进程 lookup 相关测试，确认 bitmap 的 group/rank 布局与控制器输入一致。仓库的安装、Quickstart 和部署入口见 LMCache 文档与仓库。
不要一开始就跑一个大模型服务来猜结论。先用测试里的确定性状态验证 fold、unfold、L1 hit、L2 extension 和 failure fallback，再在目标运行时上测真实请求。这样才能判断问题来自窗口计算、锁竞争、远端存储，还是服务框架本身。

局限在哪里

这次 commit 没有提供模型、GPU、运行时、基线和端到端吞吐/延迟数字，因此不能写成 KV 预取性能提升。新增的 world_size 和每个 object group 的 layout 描述也意味着调用方必须正确提供 rank shard 语义；轻量安装缺少 native bitmap kernel 时会直接失败。设计文档提到当前 L2 查询以 RDMA 为主，远端网络 adapter 是后续方向，不能把这套控制逻辑直接外推到所有存储后端。5

3. Hermes Agent：把可变 Skill 放到 prefix cache 的易变区

变化是什么

Hermes Agent 的 commit 9b9cbdd7eb05f8d432b55276dfaeba857839d6a6 的作者时间是 2026 年 6 月 2 日 09:30:43（北京时间），提交者时间是 2026 年 8 月 4 日 01:53:39（北京时间）。因此，本条以窗口内的 committer 整合时间为依据，并明确它不是作者在本窗口首次写成的内容。该 commit 未签名，技术事实以可读 diff 和新增测试为准。6
变更集中在 agent/system_prompt.py 和 tests/agent/test_system_prompt.py。此前 skills index 属于 stable band；现在它被移到 volatile band 的最前面，完整顺序变成：
stable identity and tool guidance
context files and workspace snapshot
volatile skills index, memory, user profile, timestamp
理由是 Skill 可以在会话中被添加或修改，它不是 byte-stable 的内容。如果它留在 stable band，重建 prompt 时一次 Skill 编辑就会从变化点开始击穿前面的缓存前缀；移动到 volatile band 后，隐式最长前缀缓存至少可以复用前面的 stable/context 部分，变化只从 skills index 开始重新填充。这个设计对按最长不变前缀工作的后端有意义；对于把整个 system message 当作一个 cache unit 的显式 cache_control 后端，代码注释明确说明内部顺序不会带来同样的效果。7
这是一条 prompt 排布和缓存契约更新，不是新的 memory retrieval 算法。它与上一期的 compression telemetry 不同，本期关注的是「可变 Skill 修改时，稳定前缀从哪里结束」。

适合谁先跟进

适合维护 agent system prompt、Skills 热更新和上游 prompt caching 的工程团队。尤其是会在 compaction/restore 后重建 system prompt 的 Agent，应该把可变的技能索引、用户画像、外部记忆和时间戳分别标记，而不是把所有内容都放进一个看似稳定的前缀。

先复现什么

在该 commit 上运行聚焦测试：
git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
git checkout 9b9cbdd7eb05f8d432b55276dfaeba857839d6a6
pytest -q tests/agent/test_system_prompt.py
先验证三个断言：skills index 不在 stable band，位于 volatile band 的开头，完整 prompt 中它位于 context files 之后、会话时间等 per-turn 内容之前。然后手动修改一个 Skill，触发一次 prompt rebuild，记录重建前后的完整字符串和上游 cache provider 的命中边界。测试通过只说明顺序契约成立，不说明外部 provider 已经按预期计费或命中。

局限在哪里

commit 没有给出 cache hit rate、缓存 token 数、首 token 延迟或成本变化，也没有证明所有 provider 都把 stable/context 当成可复用前缀。单块 cache_control 后端不受内部顺序影响；不同 provider 对重建、缓存 TTL 和最小缓存粒度的实现也可能不同。因此，这条的可复现结论是 prompt 分层规则和回归测试变了，不能把它写成统一的成本下降百分比。

放在一起看

进展窗口证据先复现什么可采取的工程动作不能外推
TencentDB Agent Memory v2.0.0GitHub release + release commit，8 月 3 日 19:38:59（北京时间）三件套部署；创建 Team/Agent；检查四类资产的权限、状态和 Proxy 装配为团队记忆建立 Owner、版本、可见性和 loadout 账本，把持久化、检索、注入分开验收不能证明召回质量、延迟或成本改善；README benchmark 口径不足
LMCache sliding-window prefetchGitHub commit，8 月 4 日 02:16:11（北京时间）test_prefetch_controller.py、bitmap、storage manager 和多进程 lookup 测试把窗口命中、rank 布局、锁持有和可淘汰范围作为独立不变量测量不能证明所有运行时或后端都有吞吐/延迟收益
Hermes stable/volatile promptGitHub commit committer 时间，8 月 4 日 01:53:39（北京时间）；作者时间在窗口外test_system_prompt.py；再做 Skill 编辑后的 prompt rebuild 对照把 runtime-mutable 内容移到稳定前缀之后，并按 provider 的缓存粒度测命中边界不能证明统一的 cache hit、token 成本或延迟改善
本期共同判断是：memory 系统的工程进展，正在从「能不能存」转向「状态由谁拥有、哪些内容仍然有效、变化从哪里开始」。TencentDB 处理资产的治理和装配，LMCache 处理 KV 的保留与释放，Hermes 处理 prompt 的稳定前缀。后续复现应分别记录权限状态、KV 锁与 bitmap 状态、prompt 前缀边界，避免用一个模糊的「Agent 记住了」覆盖三个不同层次的问题。

References

  1. 1
    v2.0.0 releasegithub.com
  2. 2
    v2.0.0 release commitgithub.com
  3. 3
    TencentDB Agent Memory READMEgithub.com
  4. 4
    LMCache sliding-window prefetch commitgithub.com
  5. 5
    LMCache prefetch lock-pass design in the commitgithub.com
  6. 6
    Hermes Agent prefix-cache boundary commitgithub.com
  7. 7
    Hermes Agent commit API and prompt-cache explanationapi.github.com

Related content

  • Sign in to comment.