Observational Memory(OM)是Mastra提出的上下文管理机制
基于step的AI对话
Agent 的对话由一连串 step 组成，流程是：
- 合法的
消息记录发给模型； - 模型输出 reasoning、text、tool-args；
- 回填tool-result，或者加入新的用户消息；
- 新
消息记录再次发给模型，开始下一个 step。
三类内容的计费方式不同：
| 内容 | 输出 token | 输入 token |
|---|---|---|
| reasoning | ✅ | ❌（不回填上下文） |
| text / tool-args | ✅ | ✅（模型输出不等于自动创建缓存） |
| tool-result / 用户消息 | ❌ | ✅ |
reasoning 只在输出时计费一次，不进入上下文，不产生后续费用。text 和 tool-args 作为输出计费一次，回填后成为上下文的一部分，此后每一个 step 都要作为输入重新计费。tool-result 和用户消息从一开始就只占输入。
前缀缓存
服务商在每个 step 开始时，用本次消息记录匹配前缀，
- 命中的部分，按缓存读取计价,opus是0.5$/1M token；
- 没命中的新增部分，按缓存创建计价,6.25$
需要注意的是，计费是每个step进行的，每增加一个step，之前的消息都会被计费一次。
即使缓存命中价格很便宜，但在12个step之后，就追上缓存创建的价格了，而编程Agent一次常规任务都是120-200 step
总之，缓存命中率高不等于省钱，因为缓存计费的频率极高
百万上下文
DeepSeek 有一篇关于"稀疏注意力"的论文，可以将原本256k的上下文扩大到1M，在1M token的输入中检索关键词的准确性>80%，高于Claude；在这篇论文后，中国模型也增加了1M上下文
有理由推测，大部分模型都采用了类似的机制拓展上下文
不过事实上，大部分模型在 100k - 256k 的上下文时，性能便已经开始下降，而且很容易出现上下文前后10%占据太多注意力而中间部分被忽略的问题
OM
OM的机制：
- 观察（observe）：未观察消息达到阈值后，将这些消息摘要，追加到之前的摘要块中。
- 反思（reflect）：当所有摘要达到反思阈值，把全部块再次压缩合并为一条更紧凑的摘要。
- recall：模型可以回看历史消息
优点
- 理论上模型的对话的上下文窗口不大于
系统提示词+观察阈值+反思阈值，很容易把对话规模控制在256k以下 - 消息摘要后，减少垃圾token，模型的输出更好，完成任务的输出token更少
- OM虽然会破坏前缀缓存，但是会话的缓存读token也大幅减少了，计费和token都更少，计算参考OM计算器