转写说明

本文基于已校验的公开原文进行结构化转写与事实梳理，非原文转载。 转写保留可核验的技术事实，并将工程建议与来源观点明确分开。

核心结论

Observational Memory（OM）是Mastra提出的上下文管理机制，旨在通过分层压缩历史消息来控制对话规模。该机制包含观察、反思、recall三个阶段，可将对话上下文窗口控制在系统提示词加双阈值之和以内。前缀缓存在每个step重新计费，高命中不等于省钱，因为计费频率极高。大部分模型在100k-256k上下文时性能已开始下降，容易出现中间信息被忽略的问题。

能力机制

step对话流程：Agent对话由多个step组成，每个step包含发送消息记录给模型、模型输出reasoning/text/tool-args、回填tool-result或加入用户消息、生成新消息记录再次发送四个环节。

计费差异：三类内容计费方式不同。reasoning输出时计费一次，不进入上下文，不产生后续费用；text和tool-args输出计费一次，回填后每个step作为输入重新计费；tool-result和用户消息仅占输入。

前缀缓存：服务商在每个step用消息记录匹配前缀，命中部分按缓存读取计价（Opus为0.5美元/1M token），未命中新增部分按缓存创建计价（6.25美元）。计费在每个step进行，12个step后缓存命中总费用追上缓存创建价格。

OM压缩机制：观察阶段在未观察消息达到阈值后将消息摘要，追加到之前摘要块；反思阶段在所有摘要达到阈值时压缩为更紧凑的单一摘要；recall阶段允许模型回看历史消息。压缩后消息摘要减少垃圾token，模型输出更精简，计算量和计费均降低。

快速开始

OM的具体使用需参考Mastra官方文档和OM计算器（来源提供）。关键参数包括观察阈值和反思阈值，配置后可自动触发消息压缩。实现层面，OM会破坏前缀缓存机制，但总体缓存读token大幅减少。

适用边界

缓存机制边界：前缀缓存命中率与费用节省不成正比，编程Agent常规任务通常需要120-200 step，缓存计费频率极高导致成本优势不明显。

上下文扩展边界：DeepSeek论文通过稀疏注意力将上下文从256k扩展到1M，中国模型随后跟进。但实际使用中大部分模型在100k-256k时性能开始下降，易出现前后10%信息占据过多注意力、中间部分被忽略的情况。

OM适用场景：需要控制对话规模在256k以下的场景，以及需要减少token消耗和计费的长时间对话。OM不适合需要精确检索历史完整信息的场景，因其采用有损压缩。

核验清单

来源由FanetheDivine发布于Juejin，引用Mastra官方研究文档。来源明确指出OM计算器网址可供验证。稀疏注意力论文来自DeepSeek，但未提供具体论文链接。计费数据（Opus 0.5美元/1M token、缓存创建6.25美元）需在实际使用前通过服务商文档核实，因价格可能随时间调整。观察阈值和反思阈值的具体数值未在来源中给出，需要参考Mastra实现文档或OM计算器。OM对前缀缓存的影响已在来源中说明，但实际性能表现需通过测试验证。

来源与核验

  • 原始文章
  • 页面事实以原始来源及其引用的官方资料为准；版本、星标和模型能力会随时间变化。
  • AI Stack 不公开抓取到的全文快照，只发布独立转写与来源入口。

站内链接

相关文章