第1章 Chat Memory ≠ Spatial Memory——为什么对话记忆撑不起物理世界

1. 一个让人下意识就会答错的问题

把这两个问题放到当前任意一个最强的 Agent 面前：

• 问题 A：“我上周二跟你聊到的那家在静安寺附近的咖啡馆，叫什么名字？”
• 问题 B：“我一小时前把钥匙放在客厅的茶几上，它现在还在那里吗？”

A 是典型的对话记忆题：答案曾出现在过去的对话里，模型只要能在一段历史 token 里检索 / 召回就能答出。它和”长 context + RAG + 向量检索”这一套机制天然契合，是过去三年 Agent 长记忆研究的主战场。

B 看起来也只是”以前看到过 + 现在被问起”的简单版本——但只要把它放到真实的家庭机器人 / 智能管家 / XR 助手里，问题立刻变得完全不同：

• 一小时之间，钥匙可能被人拿走、被丢进抽屉、被另一个相似物体挡住
• 钥匙”看不见”不一定等于”不在了”
• 即使被看到了，也未必是同一把钥匙——也可能是邻居的备用钥匙
• 系统给出的答案必须带置信度，并能回溯到具体证据：哪一次观测、来自哪个传感器、距现在多久

如果系统只是把”一小时前看到钥匙在茶几上”当作一段对话记忆存起来，再用 RAG 召回这段记录回答用户——它会非常自信地告诉你”在茶几上”，而这个回答很可能是错的，且系统不会知道自己错了。

这就是本章要讲清楚的事：对话记忆和空间记忆不是同一个问题的两个版本，它们的结构、更新规律、不确定性来源、证据链形态都根本不同。 把它们混为一谈，是当下 Agent 系统进入物理世界时最容易栽的一个坑。

2. 四类典型查询：空间记忆面对的真实问题画像

把 Spatial Memory 这个抽象名词拆开，最直观的方式是看它到底要回答什么样的问题。我们整理出四类典型查询，几乎覆盖了具身智能、自动驾驶、XR 助手在物理世界中真正会撞上的场景。

2.1 Last-seen：最后一次见到

“我的护照上次出现在哪个位置？大约是什么时间？证据是什么？”

这类查询的特点：

• 答案可能在很久以前——几小时、几天、甚至跨设备 / 跨会话
• 必须给出三件事：位置 + 时间 + 证据指针（哪一帧 / 哪一次扫描 / 哪个传感器）
• 必须给出置信度衰减：1 小时前看到 vs 3 天前看到，可信度截然不同
• 系统必须知道”我没看到”也是一种状态：最近 N 次扫描都没看到这件事本身就是负证据

对话记忆做不到这件事的根本原因：对话历史里没有结构化时间戳和位置坐标，更没有”上一次和这一次之间发生了什么变化”的概念。

2.2 Containment：容器与隐藏状态

“我把螺丝刀放进抽屉之后，它现在仍在抽屉里吗？系统有多确定？”

这类查询的核心是**“看不见 ≠ 不存在”**：

• 物体进入了某个容器（抽屉、柜子、盒子、行李箱）后，从感知上消失，但状态信念应该被维持
• 系统必须区分两件事：「进入容器后正常消失」 vs 「真的不在了」
• 当容器再次被打开时，系统应该主动核查之前的信念是否成立
• 时间越久、容器越长时间未被打开过，可信度衰减得越慢——容器本身就是”对置信度的保护壳”

任何只靠当前帧推理的视觉模型都做不到这个。它会非常自信地告诉你”看不到螺丝刀”——但用户问的不是”现在看得到吗”，问的是”它现在是否存在于某个空间状态里”。

2.3 Change：变化检测与摘要

“从昨晚到现在，玄关区域有哪些对象新增、消失或移动？移动了多远？”

这类查询要求系统在两次状态快照之间做差分：

• 哪些对象从 $t_0$ 时刻消失了？
• 哪些对象在 $t_1$ 时刻新出现？
• 哪些对象只是位置变了？变了多少？
• 哪些”变化”其实是坐标系漂移 / 定位误差导致的假阳性？

最后一点尤其难。对一个长期运行的系统而言，**“是物理世界变了”和”是我自己的坐标系飘了”**是两类必须被精确区分的故障——一旦混淆，系统要么把自己的累积误差不断当成外部变化报警，要么把真实变化误判为定位漂移。

2.4 State-Audit：状态核查

“我出门时炉灶关了吗？窗户是否处于关闭状态？”

这类查询的特殊性在于问的是某个特定时刻的状态：

• 它不是”现在怎样”——可能用户已经在车上了，没法再看一眼
• 它不是”上一次看到怎样”——上一次看到可能是几小时前
• 它问的是：在用户离开家的那个时刻，状态是什么？——这要求系统能时间索引到任意历史点上

要能回答 state-audit，系统必须保留带时间戳的关键状态序列，且能在任意时间点上重建出”那时候的世界长什么样”。这已经远远超出 chat memory 能做的事情。

2.5 四类查询共享的结构

把 last-seen / containment / change / state-audit 摆在一起看，会发现它们共享同一种结构：

维度	形态
主体	具体对象（钥匙 / 螺丝刀 / 门 / 行人 / 车辆…）
空间	位置 + 关系（在哪个房间 / 哪个容器 / 距离哪个地标多远）
时间	时间戳 + 时间区间（上次看到 / 这段时间内 / 这一时刻）
证据	证据链（哪次观测 / 哪个传感器 / 哪条轨迹）
不确定	置信度（带衰减 / 带负观测更新 / 带遮挡推理）

这五个维度，每一个都不是 chat memory 自带的。你可以把对话记录里的内容硬塞成”对象-位置-时间”的元组，但你无法让一段语言历史自动维护”置信度衰减”和”证据回溯”。空间记忆要做的，正是把这五个维度变成一等公民。

3. 两类记忆的结构差异

到这里我们可以把对话记忆和空间记忆放在一张表里对比。这一节的目的不是给一个”分类法”，而是让你看清楚为什么 chat memory 的工程设计原则在物理世界里几乎全部失效。

维度	Chat Memory（对话记忆）	Spatial Memory（空间记忆）
组织方式	线性、按 turn / 时间顺序	时空锚定，按对象 / 区域 / 拓扑组织
中心实体	会话 / 用户偏好 / 任务历史	对象 / 地标 / 区域 / 关系 / 事件
更新规律	append-only，新内容追加，旧内容压缩或丢弃	状态可被修正、覆盖、衰减，“看不到”也是一种更新
噪声形态	用户说错了、模型答歪了、表达不清	遮挡、漂移、相似物体混淆、传感器漏检、负观测
不确定性	主要靠 LLM 内部隐式表达	必须显式：置信度、证据链、时间衰减
一致性约束	弱（语言本身就允许多义、矛盾、补充）	强（物理世界有对象恒等 / 容器关系 / 因果不可逆）
召回方式	文本 / 语义 / 向量检索	时空索引 + 对象索引 + 关系图遍历
跨会话稳定性	相对容易（同一段文本可重复读取）	困难（同一物理空间在两次扫描间一定不同）
主要失败模式	召回不到 / 召回错 / 表达模糊	自信地答错——系统不知道自己已经过时

最后一行最关键。Chat memory 的失败往往是”答不上来”——用户能立刻意识到。空间记忆如果做错了，系统会用昨天的状态非常自信地回答今天的问题——这种错误是沉默的、复合的、会污染下游决策的。

4. 为什么”长 context + RAG + 视频帧缓存”也不够

读到这里，工程师常见的反应是：那是不是我把对话记忆扩展一下就够了？比如：

• 更大上下文窗口：1M token 把所有交互都塞进去？
• 加 RAG：用向量检索召回历史相关帧？
• 多模态长记忆：把摄像头视频帧打 embedding 存进向量库？

每一招单独看都有道理，但没有一招能解决空间记忆的核心问题。我们一个一个看。

4.1 长上下文：不是越长越对

模型上下文从 32K → 200K → 1M 的演化，让”塞更多东西进 prompt”变得便宜了。但即使你把过去一周所有的视频帧描述都拼成 800K token 喂进去：

• 注意力会被稀释：lost-in-the-middle 现象在 200K 以上的窗口里非常明显
• prefill 成本爆炸：$O(n^2)$ 的注意力计算让 TTFT 直接进入秒级
• 行为面攻击扩大：上下文里的任何内容都可能被模型误读为隐式指令
• 核心问题没解：长上下文是”被动展示历史”，不是”主动维护当前状态”——你给它看 800K 的历史，它依然不知道哪些信息已经被新观测推翻了

长 context 在 chat 场景里能续命，是因为对话历史本身就是只读的——而物理世界是可写的、会变的、会被推翻的。

4.2 RAG / 向量检索：召回不等于状态

把过去的帧描述、对话片段、感知日志做成向量库，按相似度召回——这是当前 Agent 长记忆最主流的方案。它确实解决了”找回历史相关内容”的问题，但召回相关 ≠ 维护状态：

• 向量检索只能告诉你”过去某些时刻有过这个对象”，不能告诉你”现在它最可能在哪”
• 召回的多条相关记录之间可能互相矛盾（10:00 钥匙在桌上，11:00 钥匙在抽屉里）——RAG 不知道哪个更新、哪个有效
• 没有显式的对象身份对齐——召回到的”钥匙”可能是三天前那一把，也可能是今天新看到的另一把
• 没有负观测——“过去三次扫描都没看到”这种最重要的状态信息在向量库里根本不存在

向量检索是把对话记忆做大、做快、做并行的工具，它不是状态机。它解决的是”信息的存取”，不是”信念的维护”。

4.3 视频帧缓存：高保真不等于可用状态

第三种思路是”把摄像头视频原样存下来，需要的时候反查”。这条路在监控行业很成熟，也最接近”完整证据”——但放在 Agent / 具身系统里有三个致命缺口：

• 存储成本：家用机器人 7×24 录像每月 TB 级，绝大多数家庭都不可接受
• 隐私问题：原始视频里包含的远不止”钥匙在哪”——它还有所有人的脸、所有人在干什么、什么时候不在家。这是隐私法规的高压区
• 查询根本性低效：用户问”钥匙在哪”，系统去回放过去 24 小时的视频找钥匙——这不是智能，是无底线的搜索

更深层的问题是：视频帧是世界的影子，不是世界的状态。模型可以非常擅长描述每一帧，却仍然不能在帧之间维护对象身份、容器关系和置信度衰减。把视频帧扔进向量库或 LLM 上下文，本质还是 chat memory 的延伸——它只是把”语言历史”换成了”视觉历史”，没有改变”我从来没真正维护过状态”这件事。

4.4 三条路结合也不够：缺的是状态层

把三条路全部叠起来——长 context + RAG + 视频帧库——可以让一个 Agent 的”记忆 demo”看起来很丰富：能召回老对话、能反查视频、能引用历史片段。但只要任务变成”我的钥匙现在在哪 / 这个状态从昨天到今天有什么变化 / 我出门时炉灶关了吗”，整个系统会集体陷入猜测。

原因很简单：这三条路解决的都是**“如何快速找到与当前问题相关的历史素材”，而空间记忆要解决的是”如何在新观测和旧信念之间持续校准”——这是两类完全不同的工程问题。前者是检索系统，后者是有状态的信念更新机器**。

5. 空间记忆要做的，是一件结构上不同的事

把上面的讨论汇总成一句话：

空间记忆不是 chat memory 的扩展，也不是视频检索的升级，而是 AI 系统进入物理世界时必须新建的一层”时空状态维护层”。

这一层至少要承担五件事：

1. 对象级状态维护：每个被 perceived 的物体有稳定身份、位置、关系、容器归属
2. 跨时间信念更新：随着新观测进来，每个对象的状态有显式置信度变化（包括因为没看到而衰减）
3. 可解释的查询接口：last-seen / containment / change / state-audit 四类查询都能直接回答，且每个回答带证据指针
4. 可校准的不确定性：置信度不是装饰，必须随时间和观测频度可被检验、可被纠错
5. 跨会话 / 跨设备 / 跨尺度稳定性：系统重启、用户换设备、从房间扩展到楼层，状态层不能崩

这五件事不是任何一个现有视觉模型 / 语言模型 / 向量检索系统能”自然涌现”的——它必须被作为独立的系统层单独设计、独立评测。

6. 这一层放在系统架构的什么位置？

在后续章节我们会把空间记忆放进 感知 - 认知 - 记忆 三层架构里详细讨论（第 4 章）；把它和 World Model 的 M 层做对照（第 5 章）。这里先给一个最朴素的位置描述：

┌─────────────────────────────────────┐
│  应用层 (规划 / 决策 / 对话 / UI)    │
└──────────────────┬──────────────────┘
                   │  查询接口（last-seen / containment / change / audit）
┌──────────────────▼──────────────────┐
│  Spatial Memory（空间记忆 / 状态层）│
│  - 对象表 / 关系图 / 置信度 / 证据指针│
│  - 跨时间信念更新 + 自洽性校准        │
└──────────────────┬──────────────────┘
                   │  观测流（结构化）
┌──────────────────▼──────────────────┐
│  认知层（对象抽取 / 关系推断 /       │
│         区域归属 / 拓扑组织）        │
└──────────────────┬──────────────────┘
                   │  原始观测（图像 / 点云 / 声音 / 触觉）
┌──────────────────▼──────────────────┐
│  感知层（视觉 / 雷达 / IMU / 触觉）  │
└─────────────────────────────────────┘

这张图传达的核心信息是：

• 空间记忆位于感知和应用之间——它不是感知的缓存，也不是应用的便签
• 它向下接收的是结构化观测（不是裸像素，也不是 token 流）
• 它向上提供的是带证据、带置信度的查询响应
• 它的内部维护逻辑是”在新观测和历史信念之间持续校准”——这是它和”存储 + 检索”系统本质的不同

后续章节会把每一层的工程实现拆开讲。

7. 章节小结

本章核心结论：

1. 物理世界中的”记忆”天然是空间性 + 时间性的——last-seen / containment / change / state-audit 四类典型查询共享同一组维度：对象、空间、时间、证据、不确定性。
2. Chat memory 和 Spatial memory 在结构上是两类不同的东西——组织方式、更新规律、噪声形态、不确定性表达、失败模式都不同。最危险的差异是：chat memory 的失败是”找不到”，spatial memory 的失败是**“非常自信地答错”**。
3. 长 context + RAG + 视频缓存这三条路的组合也代替不了空间记忆——它们解决的是”找回相关历史素材”，而空间记忆要解决的是”在新观测和旧信念之间持续校准”。
4. 空间记忆必须被作为系统中的独立层——不是感知模块的缓存，也不是 LLM 上下文的延伸。它要承担对象级状态、信念更新、可解释查询、可校准不确定性、跨会话稳定性。
5. 下一章预告：我们将沿着百年认知科学线索（Tolman 认知地图 / place / grid cells / predictive map / 昆虫导航）梳理这层能力的理论根基，并指出哪些经典发现可以直接迁移到工程系统。

思考题

1. 在你正在做的系统里，挑出最近一次”agent 自信地答错”的实例。重新分析一次：错误来自 chat memory 应该处理的部分，还是 spatial memory 缺位的部分？这两类错误的修复路径完全不同——前者改 prompt / 召回排序，后者必须新建状态层。
2. 把 last-seen / containment / change / state-audit 四类查询套到你当前的 Agent 上：每一类，系统能不能回答？答案是否带证据 / 带时间戳 / 带置信度？哪一类最薄弱？
3. 如果让你只用 4KB 数据存储一间房间的”空间记忆”，你会保留什么？这其实是在问：在你的工程直觉里，“对象 + 关系 + 时间戳 + 置信度”中哪些维度是不可压缩的？

---

下一章我们沿着 Tolman 的迷宫实验、place / grid cells、predictive map 和昆虫导航这条百年研究线索，把”为什么空间能力天然是一种独立的基础计算”讲清楚。这不是为了讲科学史，而是为了让我们在第 4 章建立工程架构时，有一组扎实的设计原则可以参照。