1. 角色分工#

• Actor（行动智能体 / 主意识）： 负责与用户面对面交互、执行 Tool Calls、回答问题。它的视野被切分成两半：前半部分是高密度的静态观察日志，后半部分是当前正在发生的少量原始交互。Actor 自身完全不需要调用“写入记忆”工具，专注推理。
• Observer（观察者 / 潜意识）： 在后台默默监视 Actor 与用户的对话及工具输出。每当未压缩消息积累时，Observer 异步提取关键事件、用户偏好和工具结论，生成高密度日志。
• Reflector（反思者 / 深度睡眠）： 当累积的观察日志自身变得过于庞大时触发。它通览全局，像人类睡眠一样进行记忆重组：合并同类项、消除矛盾、剔除已完成任务的临时过程，重写出下一代（Generation）精简记忆。

2. 上下文窗口的“观察-收缩”振荡（Observe-and-Shrink）#

OM 并不是等到上下文快满时才慌忙压缩，而是通过**异步预缓冲（Async Buffering）**让上下文在一个健康的水位区间内平滑振荡：

1. 常态积累（0 → 30,000 tokens）： 对话正常推进。每当消息增量穿过 bufferTokens: 0.2（即每累积 20% / 约 6,000 tokens）时，后台默默调用一次 Observer，将这 6k 数据预先提炼为切片（Buffered Chunk）暂存入库。此时 Actor 上下文完全不被修改，流式输出零阻塞。
2. 激活收缩（达到 30,000 tokens）： 当下一轮交互检测到总未观察 Token 越过 messageTokens 阈值（默认 30k）时，触发 bufferActivation: 0.8：
   • 预先算好的所有 Chunks 一次性转正，追加进 <observations> 区域；
   • 前 80%（约 24k）已被观察的原始冗余消息瞬间剥离，仅留下最新 20%（约 6k）维持当前任务连贯性；
   • 上下文体积瞬间骤降，完成一次无感收缩。
3. 长期反思（达到 40,000 tokens）： 经过数次收缩循环后，如果 <observations> 观察区文本自身越过 reflection.observationTokens（默认 40k），后台 Reflector 被唤醒，将整篇观察全量重组，压缩回收至 ~8,000 tokens，开始下一代演进。

1. 物理内存布局：从静态到高频变动#

现代 LLM 缓存的核心准则只有一条：前缀字符只要改动 1 个 Token，后面的所有 KV 缓存全部报废。

Mastra 将上下文严密划分为三层，绝不允许动态内容越界：

2. 为什么 Observer 压缩旧消息依然能保住缓存？#

关键在于：Observer 压缩的不是“上下文的前面”，而是把“上下文尾部（Block 3）”的旧消息压缩后，以 Append 的方式追加在“中间持久区（Block 2）”的末尾！

• 日常交互（占 95% 的轮次）： Block 1 不变，Block 2 不变，新消息仅追加在 Block 3 的最末端。全量前缀 100% 命中缓存！
• Observer 触发收缩的时刻（占 5% 的轮次）： Block 1 依然命中，Block 2 中旧的“历史观察 A”依然命中；只有从新增的“新观察 B”开始往后的几千 Token 才发生 Cache Miss。重算成本相比全量 Prefill 降低了 80% 以上。
• Reflector 全局重构的时刻（< 1% 的极低频）： 此时 Block 2 被彻底重写，缓存完全失效。但由于数十万 Token 才触发一次，成本早已被常态下的高命中率平摊。

3. 源码级工程微操：压榨 Cache 的细节设计#

翻阅 Mastra OM 源码，其为了适配大模型底层的 Cache 规则做了诸多深思熟虑的实现：

1. 系统消息分块（splitObservationContextChunks）： Mastra 没有把整个观察区拼成一段巨型 String，而是按消息边界切分成 System Message 数组。在对接 Anthropic Claude 时，框架可精准将 cache_control: { type: "ephemeral" } 锚定在稳定的 Chunk 边界上。
2. 前缀零时间污染： 许多 Agent 系统喜欢在第一行 System Prompt 注入 Current Time: 2026-09-22 14:02:11，导致每一秒钟所有缓存全部击穿。Mastra OM 严禁在 Block 1 注入动态绝对时间，时间上下文统一通过 Block 2 的观察日志条目和 Block 3 尾部的 <system-reminder> 提供。
3. 剥离 Working Memory： 将原本写在 System Prompt 里的用户画像与工作记忆剥离，改为通过 State Signals 或直接并入追加式观察日志，杜绝 System Prompt 产生动态抖动。

1. 知识覆写与状态迁移（Knowledge Update Conflict）#

• 冲突现象：Day 1 用户声明“全站缓存用 Redis”；Day 5 用户改口“Redis 维护成本太高，已全量切换到 Dragonfly”。传统向量 RAG 检索时因语义相似度相近，模型极易产生“到底是 Redis 还是 Dragonfly”的混乱。
• 防御机制：
  • Observer 强制提取迁移语义（observer-agent.ts）：规则明确要求 Observer 提取状态演进：User switched to Dragonfly (replacing previous Redis setup)。
  • 时序覆盖仲裁律（constants.ts）：Actor 提示词第一准则——Newer observation supersedes the older one，依据绝对日期强制以后发状态为准。
  • Reflector 物理垃圾清理：在反思阶段，Reflector 通读时序，物理删除旧的 Redis 观察，从底层消除脏数据。

2. 相对时间的跨期漂移与自动兑现（Temporal Anchoring）#

• 冲突现象：用户在 1 月 10 日说“我打算下周二上线新模块”；用户在 1 月 25 日再次提问：“新模块上线后监控正常吗？”——模型分不清“下周二”是已经过去还是即将到来。
• 防御机制：
  • 三时间模型（Three-Date Model）：每条观察包含起始记录时间、引用事件时间和相对时间推算： * 🔴 (14:30) User stated they will deploy next Tuesday. (meaning January 16, 2026)
  • 历史计划自动兑现假定：Actor 注入规则明确规定：“若用户过去计划做某事，且该时间点在当前时钟之前，在没有相反证据的前提下，假定该动作已按期完成。”

3. 突发超大 Tool Call 击穿缓冲（blockAfter 熔断）#

• 冲突现象：未压缩消息刚到 25k，Agent 执行了一个排障命令，意外吐出 100,000 tokens 的 Core Dump 日志，瞬间击穿 30k 阈值，且后台异步 Observer 根本来不及预缓冲。
• 防御机制：
  • blockAfter: 1.2 熔断线（即 36,000 tokens）：一旦检测到未压缩消息越过安全水位线，OM 立即中断异步模式，强制转入同步阻塞观测（Synchronous Observation）。
  • 大工具输出剥离（tool-result-helpers.ts）：自动对超大报文执行前缀截断与语义提炼，丢弃中间冗余调用链，确保 Observer 自身不发生溢出。

4. 权威陈述与偶发提问的冲突（Assertion vs Question）#

• 冲突现象：
  • 用户陈述：我使用的是 Node.js 22 LTS（权威事实）。
  • 十轮后用户发问：我之前说我本地跑的是 Node 18 还是 22 来着？（随口发问）。
  • 很多模型会错误总结为：“用户不太确定使用的是哪个 Node 版本”。
• 防御机制：
  • observer-agent.ts 顶层红线规则：User assertions are authoritative。用户是自身事实的绝对权威。用户后续提出的疑问句绝不能降解或推翻此前明确告知的事实，断言记录永久维持 🔴 优先级。

5. 压缩细节丢失与溯源恢复（The Recall Fallback）#

• 冲突现象：Observer 将长达 200 行的报错精简为：* 🟡 Stripe webhook failed with InvalidSignatureError at line 45。稍后用户突然要求：“把当初 Stripe 报错的原始 Header 键值对一字不落地打印出来”。
• 防御机制：
  • 观察分组打标（Observation Groups）：Observer 生成记录时包裹 XML 范围：<observation-group range="msg_042:msg_045">。
  • 挂载 recall 工具：开启 retrieval: true 后，主智能体被赋予 recall 工具。Actor 意识到观察中缺乏字面细节时，可自主执行 recall({ mode: "messages", cursor: "msg_042" })，直接穿透持久化数据库查阅原始微缩胶片。

6. 反思膨胀与退化死循环（5 级自适应降级）#

• 冲突现象：某些模型在执行 Reflector 时“越总结话越多”，把 40k 的观察反思成了 45k；或者陷入自言自语的复读死循环。
• 防御机制：
  • 5 级阶梯式压缩提示词控制器（CompressionLevel 0 ~ 4）：
    • Level 0：标准反思。若不降反增，进入重试。
    • Level 1：温和压缩（8/10 细节），要求头部深度提炼。
    • Level 2：激进压缩（6/10 细节），强制合并同模块多轮调用弧线。
    • Level 3：关键压缩（4/10 细节），彻底斩断过程细节，仅留结论与决策。
    • Level 4（Extreme）：极限压缩（2/10 细节），同日合并至多 2 条，除核心偏好外一律强制概括。
  • 退化检测器（detectDegenerateRepetition）：算法检测到连续重复行时立即熔断，强制回退到历史最小合法候选版本。

7. 跨线程任务串扰（Thread Attribution）#

• 冲突现象：开启全局记忆后，用户在 Thread A 里重构数据库（等待脚本确认），新开 Thread B 问前端 CSS。Thread B 错误继承了 Thread A 的待办，在回答 CSS 时顺嘴催促数据库审批。
• 防御机制：
  • XML 线程隔离：全局通用事实（偏好、画像）置于根节点；特定任务收纳进 <thread id="..."> 标签。
  • Continuation Hints 归属绑定：<current-task> 和 <suggested-response> 强绑定至产生它的 threadId，跨会话读取时自动屏蔽局部待办。

1. 为什么 30k 消息 / 40k 观察是黄金平衡点？#

• 40k 观察日志 ≠ 40k 对话： 由于 5~40x 的高压缩比，40,000 tokens 的观察日志实际上封存了 200,000 ~ 400,000+ tokens 的真实世界交互，已经相当于一本沉甸甸的技术专著。
• 保障后台智能体自身的智商： Observer 和 Reflector 本身也是 LLM。让 Observer 消化 30k 数据，它能做到近乎 100% 的要点提取；如果堆到 150k 才提取，Observer 自身也会产生注意力衰退，漏掉关键信息。
• 冷启动 Prefill 延迟控制： 发生 Cache Miss 时，30k 的预填充耗时通常在 0.5 ~ 1 秒；而 200k+ 的预填充在任何集群都需要 8 ~ 15 秒，对话体验直接崩塌。

2. 既然控在 70k，那 256k 和 1M 模型还有区别吗？#

有，而且非常显著：

角色选型最佳工程组合：

• Actor（主交互）：选代码能力最强、逻辑最硬的模型（如 Claude 3.7 Sonnet / GPT-5-mini），256k 物理窗口完全足够。
• Observer / Reflector（后台潜意识）：必须选 1M 级别的长窗口轻量模型（首选 Gemini 2.5 Flash），成本廉价、吞吐极高、具备吸收突发脏数据的深水池。

1. 存储设计：单例持久化模型#

在底层的存储表（mastra_observational_memory_records）中，当处于 resource 作用域时，threadId 物理置为 NULL，以 resourceId（即 User ID / 租户 ID）作为单例主键：

1
// 摘自 observational-memory.ts
2
getStorageIds(threadId: string, resourceId?: string) {
3
  if (this.scope === 'resource') {
4
    return {
5
      threadId: null, // 全局单例，解除具体线程绑定
6
      resourceId: resourceId ?? threadId,
7
    };
8
  }
9
  return { threadId, resourceId };
10
}

2. 数据库才是 Single Source of Truth#

在整个生命周期中，内存上下文（messageList）只是大模型在当前推理轮次的一份动态瞬时快照，数据库记录才是真正的单一真实来源：

1. Observer 预缓冲：生成新切片后，首先调用 storage.setBufferingObservationFlag 并持久化写入数据库的 buffered_observation_chunks。此时内存完全不改动。
2. 激活收缩：调用数据库事务 storage.swapBufferedToActive，将缓冲切片在 DB 层面合并入 active_observations，清退旧记录，更新水位线。随后将 DB 最新文本投射进 Actor 上下文。
3. Reflector 反思：调用 storage.createReflectionGeneration，直接用精炼日志覆盖重写 active_observations，generation_count 自增 +1。

这种架构赋予了系统在云原生容器调度、Serverless 扩缩容下的绝对无状态（Stateless）高可用——无论下一次交互落在哪个 Pod 上，只要通过 resourceId 查一次库，整套长期记忆立即在毫秒级完美苏醒。

方案对比矩阵#

生产环境开箱即用代码#

在实际工程中，通过 @mastra/memory 与 @mastra/core 即可极其优雅地启用这套先进的观察式记忆引擎：

1
import { Agent } from "@mastra/core/agent";
2
import { Memory } from "@mastra/memory";
3
import { LibSQLStore } from "@mastra/libsql"; // 也可替换为 @mastra/pg (PostgreSQL)
4

5
// 1. 初始化存储（持久化单一事实来源）
6
const storage = new LibSQLStore({
7
  id: "agent-storage",
8
  url: "file:./memory.db",
9
});
10

11
// 2. 组装具备 OM 机制的长期记忆体
12
const memory = new Memory({
13
  storage,
14
  options: {
15
    observationalMemory: {
16
      // 记忆作用域：设为 'resource' 即可激活跨会话用户终身记忆
17
      scope: "resource",
18

19
      // 后台潜意识模型：首选拥有 1M 上下文且极度廉价高效的 Gemini Flash
20
      model: "google/gemini-2.5-flash",
21

22
      // 观测阈值策略控制
23
      observation: {
24
        messageTokens: 30_000,    // 累积未压缩消息达 30k 时触发收缩
25
        bufferTokens: 0.2,         // 每 20% (6k) 在后台异步静默计算切片
26
        bufferActivation: 0.8,     // 激活时清退 80% 旧消息，保留 20% 垫底
27
        manageWorkingMemory: true, // 托管 Working Memory，移出 System Prompt
28
      },
29

30
      // 反思收敛策略控制
31
      reflection: {
32
        observationTokens: 40_000, // 累积观察达 40k 时触发全局反思 GC
33
      },
34

35
      // 开启溯源检索模式与 recall 工具（遇到精准代码排查时可调取原文）
36
      retrieval: true,
37

38
      // 开启时间间隔断点提示（对话暂停超 10 分钟后自动注入时间感知）
39
      temporalMarkers: true,
40

41
      // 共享预算池：会话初期允许消息区自由向上借用额度
42
      shareTokenBudget: true,
43
    },
44
  },
45
});
46

47
// 3. 构建主交互智能体
48
export const codingAgent = new Agent({
49
  id: "production-engineer",
50
  name: "Senior Software Engineer",
51
  instructions: "You are a pragmatic, elite senior full-stack developer.",
52
  model: "openai/gpt-5-mini", // 主模型专注强大推理
53
  memory,
54
});
55

56
// 4. 调用：传入相同的 resourceId，即可跨 Thread 永久沉淀用户偏好
57
await codingAgent.generate("以后我们所有的后端接口，强制采用 Hono + Drizzle ORM，严禁使用 Prisma。", {
58
  memory: { resource: "user_developer_tom", thread: "thread_session_01" },
59
});

Mastra Observational Memory 的出现，标志着 Agent 记忆工程正从“依赖外部工具与概率检索的外挂形态”，走向“深度结合大模型 KV-Cache 物理特性的内生仿生架构”。它以近乎偏执的克制与优雅，为下一代长生命周期、全自主 Agent 的落地构建了极其坚固的基石。