Memory 技术日报 2026-07-07：DPD、RAG 验证与 LLM Wiki

这一天的 memory/context 信号更偏工程底座：AWS 把 prefill 和 decode 拆成可独立扩缩的推理资源池，TDS 把 RAG 答案从「生成完就返回」改成可校验、可拒答、可回路修正的链路；OpenViking 和 LangChain/OpenWiki 则把 agent memory 推向可维护的上下文资产，而不是一堆临时塞进 prompt 的文本。

速览

信号	来源与时间	和 memory/context 的关系	读者该怎么跟
SageMaker HyperPod 支持 Disaggregated Prefill and Decode，长上下文请求走分离路径并通过 EFA + GPU-Direct RDMA 传 KV cache。1	AWS 官方页，发布日为 2026-07-06。	KV cache 不再只是单机显存优化，而是跨 GPU 池传输和调度对象。	关注线上流量里长 prompt、RAG、多轮 agent 是否会拖慢 decode。
TDS 发布 RAG 生成校验长文，主张对 span、quote、schema shape、not-found 和 feedback fields 做后置检查。2	2026-07-06 21:30（北京时间）发布。	把 RAG 的「记忆是否可信」落到逐条证据校验，而不是只看检索召回。	在现有 RAG 输出 schema 里补上可机器检查的 span、quote 和 not-found 分支。
OpenViking 在 X 上被作为 agent context database 再次讨论，项目 README 把 memory、knowledge RAG 和 skills 放进同一个文件系统范式。3 4	X 讨论时间为 2026-07-07 09:00（北京时间）。	agent memory 从「存聊天记录」变成「管理资源、技能、任务经验和检索轨迹」。	如果团队正在做长期 agent，优先评估 memory 的目录、权限、版本和可观测性。
LangChain 预告「LLM Wikis and how to give your agents memory」直播，并说明 OpenWiki 是一个用于创建和维护 LLM Wiki 的开源项目。5 6	X 预告时间为 2026-07-07 00:14（北京时间），直播安排在 7 月 10 日 02:00（北京时间）。	「Wiki」正在变成 agent 长期上下文的一种产品形态。	不要只问怎么自动写文档，要问它能否被 agent 稳定引用、更新和验证。

逐条解读

1. AWS DPD：KV cache 进入跨资源池调度

AWS 这次给 SageMaker HyperPod 增加的 DPD，把 LLM 推理拆成两个资源池：prefill 跑在一组 GPU 上，decode 跑在另一组 GPU 上，中间用 Elastic Fabric Adapter 和 GPU-Direct RDMA 传 KV cache。官方解释的核心问题很直接：长上下文请求如果和短请求共用同一块 GPU，会让正在吐 token 的请求被长 prompt 的 prefill 阶段拖住。1

这对 memory/context 工程的意义，比「又一个 serving feature」更具体。RAG、agentic pipeline、长文分析都会制造很不均匀的输入长度：有的请求只是短问答，有的请求要带上十几页上下文、工具历史或检索片段。DPD 的做法是把这种输入长度差异交给路由层处理，长上下文请求走分离路径，短 prompt 直接进 decoder，避免每个短请求都为 KV 传输付额外成本。1

工程跟进点很明确：如果线上已经用了 prefix cache、KV offload 或 prompt caching，不要只看平均延迟。要拆开看长 prompt 到来时的 decode 抖动、per-token latency，以及不同输入长度下的 goodput。memory 系统省下的 token，最后都要在这个层面兑现。

2. TDS RAG 校验：答案也要有「记忆引用完整性」

Kezhan Shi 的文章把 RAG 生成后的校验写得很细：typed answer 不是 checked answer，模型仍可能引用输入范围外的行、把非原文 paraphrase 当 quote、在只拿到部分证据时把 complete_answer_found 置为 true，或者返回不符合问题形态的结构。文章给出的 validator 会同时检查 shape、evidence 和 format：每个 span 要落在真实行范围内，quote 要能在引用行里被匹配，日期和货币等字段也要符合格式。2

它最有用的地方不是代码片段本身，而是把 RAG 的失败分成了可执行分支：校验失败可以 retry、flag for review 或 reject；文档里没有答案时，items=[] 和 answer_found=False 是正常输出，不应该让模型硬编一个值；如果答案不完整，complete_answer_found=False 可以触发扩大检索范围。2

这给 enterprise RAG 一个很实在的检查表：别把「引用了来源」当成可信。可信要落到行号、quote、schema、not-found 和 retry 条件上。尤其是合同、合规、财务这类场景，系统能诚实说「没找到」比给出顺滑但假的答案更重要。

3. OpenViking：agent memory 被包装成 Context Database

OpenViking 的官方 README 把自己定义为面向 AI agents 的 open-source Context Database，用文件系统范式统一管理 memories、resources 和 skills。它明确批评传统 RAG 的 flat storage 缺少全局视图，也强调 retrieval trajectory 的可视化，让开发者能看到检索链路为什么失败。4

窗口内的 X 讨论把这个定位说得更直白：OpenViking 试图把 memory、knowledge RAG 和 skills 统一在一个上下文数据库里，让 agent 跨 session 记住东西，并随着使用自我迭代。3 这不是论文式的新概念，但它代表了一个很强的工程方向：memory 不再只是「把对话摘要塞回 prompt」，而是要像文件系统一样被组织、检索、压缩、审计和迁移。

项目最近的 v0.4.7 release 也印证了这个方向：更新点包括 MCP compact description mode、自动摄入本地文件上传、OpenClaw tool parts 以 assistant messages 保存，以及多版本管理、加密写入和 QueueFS 稳定性修复。7 这些听起来分散，但都指向同一件事：当 agent memory 进入真实工作流，文件、工具调用、身份、版本和权限都会变成 memory 的一部分。

4. LangChain/OpenWiki：Wiki 重新回到 agent memory 入口

Harrison Chase 在 X 上预告了 LangChain 的 LLM Wiki 直播，称 OpenWiki 在不到一周内接近 7k GitHub stars，并把主题直接写成「how to give your agent memory」。5 活动页进一步说明：LLM Wikis 正在成为给 agent 提供上下文的常见模式，例子包括 DeepWiki、AutoWiki 和 Karpathy 提到的 LLM Wikis；OpenWiki 是 LangChain 新近推出的开源项目，用于创建和维护自己的 LLM Wiki。6

Wiki 这个词容易让人误以为只是自动生成文档。对 agent 来说，关键不在文档是否漂亮，而在它能不能被机器稳定使用：页面是否有结构，事实是否能更新，引用是否可追，代码库变化后旧结论是否会失效。把代码库、产品知识、用户偏好和历史决策做成 Wiki，本质是在给 agent 准备一层可读、可维护、可检索的外部记忆。

这条线和 OpenViking 可以放在一起看：一个偏上下文数据库，一个偏 Wiki 抽象。前者更像存储与检索底座，后者更像人机都能消费的知识界面。接下来要观察的是，Wiki 能不能和真实执行轨迹连起来。只靠静态页面，agent 很快又会回到「读到的都是过期上下文」这个老问题。

工程判断

今天的 4 条信号都在提醒同一件事：memory 不是单点能力。它一头连着推理系统的 KV cache 和资源调度，一头连着 RAG 的证据完整性，还要连到 agent 长期上下文的组织方式。

对工程团队来说，短期可以做三件事。

把 RAG 输出从纯文本改成 typed answer，并要求每个事实带 span、quote 或可回放证据。
在 serving 指标里拆分 prefill、decode、KV cache 命中和长 prompt 对短请求的干扰，不只看总延迟。
评估 agent memory 时，把目录结构、版本、权限、可观测性和更新机制列为一等指标，不要只比较向量检索效果。

真正能上线的 memory 系统，最后比拼的不是记住多少，而是记得是否可控、可查、可更新。