Memory 技术日报 2026-07-06：可编程 KV、legal-kb 与代码图谱 MCP

本期按 2026-07-05 09:00 至 2026-07-06 09:00（北京时间）取材。过去 24 小时里，memory/context 方向没有足够多可核验的全新论文首发；今天收缩成 3 条窗口内工程与社区信号。每条都把「窗口内发生了什么」和「原始项目/论文什么时候发布」分开写，避免把旧材料说成今天首发。

Bojie Li 的长帖把一个常见线上问题说得很直：agent 每轮都要把系统提示、工具定义、检索文档和历史消息重新送进模型；prompt caching 只在前缀完全共享时省钱，一旦早期字段变了，后面的 keys/values 往往都失效。1 这不是一个抽象成本问题。客服 agent 改了一个订单状态，可能就要重新 prefill 1 万 token。

更有意思的是他的因果解释：如果只刷新那个字段自己的 KV，模型仍可能按旧值回答，因为 prefill 阶段已经把「字段条件下的结论」写到了聚合 token、分隔符 token 等后续位置。长帖称，字段自身 KV 对决策的贡献低于 1%；KV cache 更像一份已写好的笔记，而不只是注意力计算的副产物。1

这会改变工程判断。过去我们把 memory 分成外部记忆、检索记忆、对话摘要和 KV/prefix cache，通常把最后一类当性能优化。这个视角下，KV cache 已经参与了状态表达。长帖给出的方向是 append-only erratum：不重算整份「笔记」，而是追加一条纠错说明，让新结论覆盖旧结论；他还提到在 vLLM benchmark 中维持 98.5% cache hit-rate，并把 p90 time-to-first-token 降低 53-398 倍。1

这里还不能把单帖数字当成通用结论。更稳的跟进动作是：在自己的多轮 agent 服务里构造一个小测试，把早期字段、用户状态、检索片段依次改动，比较 full recompute、prefix cache、局部 KV 刷新和追加纠错四种路径的回答一致性。只看 TTFT 不够，还要看陈旧状态是否漏进最终答案。

LlamaIndex 的 legal-kb 在窗口内被技术媒体和社区继续讨论。MarkTechPost 把它描述为一个公开参考应用：基于 LlamaIndex Index v2，让 agent 用 retrieve、findFiles、readFile、grepFile 这类工具访问法律文档知识库。4 GitHub README 也显示，它是一个 TanStack Start Web app，每个项目会镜像成 LlamaCloud Index v2，上传文件后自动解析和索引，聊天 agent 再实时查询该 index。5

它的重点不是「法律」本身，而是 RAG 的操作接口。README 列出的工具包括 hybrid search、按名称查文件、读取原文内容和 grep。5 一位中文开发者在 7 月 5 日 23:54（北京时间）的转发里概括得更接近工程要点：知识库接给 AI，别只做一次语义搜索就让它回答，更稳的是先找文件、读原文、查关键词，再带着证据回答。6

这和传统 RAG 的区别很实在。一次向量检索通常只回答「哪些 chunk 相似」；legal-kb 这类 retrieval harness 更像给 agent 一个只读文件系统。agent 可以先确定目录，再语义检索，再读取原文窗口，最后用 grep 校对精确措辞。对合同、法规、技术手册这类内容来说，这比把 top-k chunk 直接塞进 prompt 更容易审计。

要注意两个落地成本。第一，README 显示项目依赖 WorkOS、PostgreSQL、Prisma、LlamaCloud Index v2、OpenAI/Anthropic key 等组件，用户 API key 会用 AES-256-GCM 加密保存。5 这不是「拉下来就能本地跑完」的小工具。第二，项目 README 里 license 仍标为 TBD。5 如果要纳入生产路线图，先把授权、数据驻留和索引服务依赖核清楚。

Reraflow 的 GitHub Weekly Trending 报告把 DeusData/codebase-memory-mcp 列为 AI 相关榜单第 3，称其本周新增 9,517 stars，总 star 约 26.7k。7 这个指标来自第三方周报，不应当当作 GitHub 官方统计；但它解释了为什么这个项目值得继续看：coding agent 的 memory 正在从「把更多文件塞进上下文」转向「先维护一张代码结构图」。

项目 README 的核心卖点很明确：单个静态二进制，解析 158 种语言，用 tree-sitter AST 和部分 Hybrid LSP 类型解析构建函数、类、调用链、HTTP routes、跨服务链接等知识图谱；它还提供 14 个 MCP 工具，覆盖架构概览、结构搜索、调用路径、diff 影响面和 Cypher-like 查询。8 README 引用的预印本称，在 31 个真实仓库上，图谱探索相比逐文件探索减少 10 倍 token、减少 2.1 倍工具调用，回答质量为 83%。8

AI Builder Club 的工程文也给了一个更贴近使用者的解释：coding agent 默认会 grep、读文件、跟 import，再把关系临时拼回上下文；Codebase Memory MCP 的做法是把函数、类、调用链、路由和跨仓库连接做成持久图谱，agent 查询结构而不是重复读平文本。9 文中提到，在一个 monorepo 的两轮结构问题里，启用图谱后 token 从约 38,000 降到约 11,000，第二个累计问题从约 64,000 降到约 33,000。9

这个方向对团队有两个可验证价值。第一是成本：大型代码库里的「读仓库」不是一次性开销，agent 每次改跨模块逻辑都在重建同一张心理地图。第二是正确性：PR 影响面、隐式锁、跨服务 HTTP 调用这些问题，grep 很容易只拿到样本，图谱至少给了一个可查询的结构边界。

但别急着把它当银弹。代码图谱的价值取决于解析覆盖、类型解析质量、增量更新稳定性和 agent 是否真的使用它。README 提到它通过 agent 配置、instruction 和 pre-tool hooks 接入多种 coding agent。8 真正上线前，应该用自己仓库里的 5-10 个历史 bug 或 PR 做回放：看它能否找到人工 review 当时漏掉的调用路径，而不是只看 token 省了多少。

今天这 3 条指向同一个变化：memory 不再只是「把事实存起来」。KV cache 侧在讨论怎样编辑已经写入中间状态的结论；RAG 侧在把知识库变成可追路径的工具循环；代码 agent 侧则把仓库结构维护成长期图谱。

对工程团队来说，下一步不是追一个统一的「memory layer」名词，而是把 memory 放置位置拆开验证：哪些状态在外部库里，哪些状态在 retrieval harness 里，哪些状态已经进了 prefill/KV，哪些结构应该变成图谱。放错位置，轻则多花 token，重则让 agent 拿着过期上下文继续推理。