Memory 技术日报 2026-07-31：长上下文的缓存账、可信上下文与组织记忆
三条窗口内进展分别拆解长上下文的 KV 与成本账、agent context 的信任边界，以及组织级长期记忆的持久状态设计。
先看三个边界
本期覆盖 7 月 30 日 09:00 至 7 月 31 日 09:00（北京时间）。窗口内留下三条高信号线索：一篇官方工程教程把长上下文的 KV、带宽和价格账算到单请求；Postman 描述了 agent 如何把可信指令、固定语料和短生命周期 sandbox 分开；MinIO 的 AIStor Memory 则在窗口内引发了一篇技术媒体讨论，把长期记忆、工作区和凭证拆成三类持久状态。三条材料不在同一证据等级，也不能放进同一个 benchmark。
1. 先算单请求账：长上下文不等于可服务
DigitalOcean 在 7 月 30 日 17:32（北京时间）发布的工程教程，从一条 KV cache 公式开始：
2 × layers × KV heads × head dimension × sequence length × bytes per element。这里的 head 数是 KV heads，不是总 attention heads；在 grouped-query attention 中，多组 query heads 共享较少的 KV heads。1按该文的示例，Llama 3 70B、BF16、80 层、8 个 KV heads、head dimension 128，在 128K token 输入下，单请求 KV cache 约为 43 GB；在 80 GB GPU 上，这一项约占 54% 的显存。文章还列出 1M token 的数值，但同时说明 Llama 3.1 的实际支持上限是 128K，1M 列只是把公式外推到更大工作集，不是可直接运行的模型配置。1
同一篇文章用 Llama 3 70B 的 141 GB 权重和 H100 SXM 的 3.35 TB/s 带宽，给出单请求、未批处理的理论 decode 上限：4K、32K、128K、1M context 分别约为 23.5、22.0、18.2、6.9 tokens/s。这是带宽 ceiling，不是实测 serving benchmark；文章没有给出可复现的运行时版本、batch 配置或 kernel 实现，因此不能把 18.2 tokens/s 当成任何一个 vLLM、SGLang 或 TensorRT-LLM 部署的实测值。1
成本例子也指向同一个判断。文章按 Claude Sonnet 的价格示例计算一个 10 轮会话：上下文稳定在 128K，每轮新增 500 token 问题并返回 500 token 答案；每轮重发完整上下文约 3.93 美元，复用 128K cache 约 0.95 美元，只检索 8K 相关内容约 0.33 美元。这里是价格表上的情景推演，不是同一请求流量下的供应商实测，也没有把检索器延迟、缓存过期和 miss 重写成本算进去。1
适合谁先跟进： 做 serving、网关或 agent 编排的人。先把「稳定重复的前缀」「每轮变化的检索内容」「不能放进 GPU 的冷状态」分开记账，而不是只看模型标称上下文长度。
先复现什么： 选定一个模型、精度、GPU 和运行时，分别测 4K/32K/128K 的 prefill、decode、TTFT、显存和 cache read/write；再用固定的 10 轮会话对比全量重发、prefix cache 和 8K retrieval。报告必须保留模型、硬件、运行时、batch、基线和 cache 生命周期。
不要先下的结论： 长上下文、prompt caching 和 RAG 没有固定的胜负关系。工作集稳定且反复使用时，缓存可能更合算；语料很大、变化频繁或每轮只需少量内容时，检索更容易控制显存、prefill 和账单。上述数字只能支撑测量设计，不能直接支撑架构选型。
2. 先锁信任边界：Postman 把参考语料变成部署配置
Postman 的工程博客在 7 月 31 日 00:00（北京时间）发布，讨论其 AI Engineer 的安全设计。它没有提出长期记忆算法，但给出了一个与 agent context 直接相关的边界：system prompt 被视为 trusted scope，且不放入用户输入；知识库属于部署产物，要经过 review、gating 和 pinning，部署后 corpus 固定，retrieval 只针对这份已知集合。2
这套设计还把上下文与执行权限分开：所有输入，包括仓库里的 instruction-shaped files，都先按不可信内容处理；每个 task 在独立、短生命周期的 sandbox 中运行；平台凭证留在 runner 侧，不进入 agent 的 reasoning layer；出网经过 allow-list。文章描述的是设计边界，不是 memory recall 的实验结果。2
对 memory 系统来说，重要的不是把这套方案叫作「记忆」，而是它阻断了两种常见混淆：用户输入不能借 system prompt 获得更高信任级别；一次 task 的污染也不应自动变成下一次 task 的持久状态。换句话说，写入什么、从哪里读、以谁的权限读，应该在进入模型上下文之前就有可审计边界。
适合谁先跟进： 维护 coding agent、企业 RAG 或带工具调用的 agent 平台的人，尤其是需要处理不可信仓库、用户上传文件和跨任务状态的人。
先复现什么： 给一份固定语料生成内容哈希，验证 system prompt 与用户输入的拼接路径；在 corpus 中放入带有指令外观的文件，检查它是否只被当作数据；为两个 task 分配独立 sandbox，尝试从第二个 task 读取第一个 task 的状态；最后验证 runner 侧凭证和网络 allow-list。把「是否污染」「是否越权」「是否跨 task 泄漏」分成三个测试结果。
局限在哪里： 文章没有公开 retrieval recall、延迟、任务成功率或跨任务 memory benchmark，也没有说明长期记忆的写入、更新和删除算法。它适合作为 context governance 的工程检查表，不足以证明模型质量或 memory 能力提升。
3. 先拆数据类型：AIStor Memory 把长期记忆、工作区和凭证放进一条治理链
Blocks & Files 在 7 月 31 日 02:12（北京时间）发表了关于 MinIO AIStor Memory 的技术报道，因此「窗口内」成立的是社区讨论，不是产品首发。MinIO 的官方新闻稿发布时间是 7 月 29 日 08:00（北京时间），早于本期窗口；正文把 AIStor Memory 定位为与 objects、tables 并列的 agent memory data type。34
它的拆分方式比「把整段 transcript 存起来」更具体：
- Long-term memory / agent biography：保存证据引用、决策、结果、修正、来源和未完成事项；可以自动记录，也可以通过 memory tools 手动整理。
- Workspace：保存活动文件、计划、附件、中间产物、交接内容和 checkpoint，承接还没有结束的工作。
- Vault：单独保存 API key、token 等敏感凭证，由 MinKMS 管理密钥；它不应与可被检索的记忆混成同一类文本。
上述结构来自 MinIO 的官方发布说明和配套文章；厂商同时强调记忆可以被 curate、update、retire 或 delete，并由授权 agent 按任务范围和客户策略取用。当前能力仍是 tech preview，公开材料没有给出性能、部署规模、价格或独立验证结果。45
适合谁先跟进： 需要让多个 agent 共享组织知识，又必须保留来源、权限和删除路径的企业平台团队。它解决的是持久状态的组织方式，不是把更多 token 塞进一次推理。
先复现什么： 如果能申请 tech preview，先建两个权限不同的 agent，分别写入带来源的 decision、workspace checkpoint 和 vault secret；验证读取范围、跨 agent 共享、撤权、删除和 provenance 是否一致，再测这些持久状态注入 prompt 后对 prefix cache 的影响。没有访问资格时，只能把公开材料当作架构假设，不能把「infinite context」之类厂商表述写成容量或性能结论。
不要先下的结论： 「Memory 是一种数据类型」不等于它已经替代向量库、关系库或 secrets manager；tech preview 也没有证明跨会话 recall、延迟或任务成功率。真正需要补上的证据，是写入/读取延迟、权限错误率、删除后的不可见性、来源可追溯性，以及 memory 注入对 prefix cache 命中和 token 成本的影响。
三条材料放在同一张工程地图上
| 边界 | 本期材料 | 证据等级 | 先做的动作 | 暂时不能推断 |
|---|---|---|---|---|
| 单请求成本 | DigitalOcean 的公式、模型示例和理论上限 | 官方工程教程；理论估算 | 按模型、硬件、运行时重算 KV、prefill、decode 和 cache 成本 | 不能把理论 ceiling 当线上吞吐 |
| 上下文信任 | Postman 的固定语料、trusted scope 和 sandbox | 官方工程博客；设计说明 | 做不可信输入、跨 task 污染、凭证和出网隔离测试 | 不能推断 recall、延迟或长期记忆能力 |
| 持久状态 | MinIO AIStor Memory 的 Memory / Workspace / Vault | 窗口内媒体讨论，回链官方 tech preview | 申请访问后测权限、来源、删除和注入成本 | 不能把厂商定位改写成 benchmark 或容量承诺 |
这三条线索把 memory 的工程问题拆成了三个顺序：先知道一次请求的状态成本，再决定哪些内容可以进入可信上下文，最后才讨论哪些状态值得跨会话保存。只要这三个边界仍混在一起，长上下文、RAG、prompt cache 和 agent memory 的收益数字就很难互相比较。
References
- 1
- 2Postman：AI Engineer 的安全架构
blog.postman.com
- 3Blocks & Files：MinIO AIStor Memory 的窗口内技术讨论
blocksandfiles.com
- 4
- 5
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.